XPCOM Startup:Changes for developers

Changes to binary components

Binary commponents will change in the following way:

instead of exporting a function named "NSGetModule", binary components will export a data symbol "NSModule". This will be a C++ structure contained tables of CIDs, contracts, and category entries provided by the component, as well as function pointers to actually create those CIDs.

It will be possible to make a single binary component which is compatible with both Firefox 3.6 and Firefox 4 by exporting both NSModule and NSGetModule. However, it is highly recommended that if extensions need binary modules, they consider switching to ctypes, which will be a more stable interface as the Mozilla platform continues to change.

Changing existing modules to the new data tables cannot be done automatically. I have some emacs macros which helped me to reformat the data "by hand", which I can post so that mailnews/seamonkey/etc will have an easier time adapting to the new format. I welcome anyone with emacs or python smarts turning my fragile macros into something more resilient.

Changes to JS components

JavaScript components will change in the following way:

JS components will no longer register themself. Instead, JS components wil register CIDs, contracts, and categories by adding lines to chrome.manifest. See https://wiki.mozilla.org/XPCOM/Bootstrap#Registration for design docs and examples. JS components will export a single toplevel function, NSGetFactory. If components currently use XPCOMUtils.generateModule, this change may be as simple as patching a few lines to switch to XPCOMUtils.generateNSGetFactory

It will be possible to make a single JS component/extension which is compatible with both Firefox 3.6 and Firefox 4. This may cause some additional warnings about "unknown chrome registration directive" to appear in the error console.

APIs and version numbering

This change affects the following frozen APIs: nsIModule (removed) NSGetModule (standard component entry point, unused) NS_InitXPCOM3 (removed, static component registration changed)

Because of this, we are considering bumping the gecko version number to "2.0" when this lands, or tomorrow after the developer preview has been tagged. If you see any reason we shouldn't do this, please let me know ASAP.

This may lead us to the odd position of building Firefox 4 on the hg.mozilla.org/releases/mozilla-1.9.3 branch with a gecko version number of 2.0. If that hurts your brain too much, I'm sorry!