My comments. The gcc DLL is made dynamic so that some C/C++ machinery could work across DLLs (e.g. exceptions). And no, mozft libraries are not statically linked into XUL.DLL — since FF 24 beta 4 we we link against our fntcfg2 / freetyp6 DLLs (which are pretty much the same as mozft but they have standard names and are used by a variety of other OS/2 apps out there).
In general, the all-in-one approach (best deployed by Apple on Mac) has its own benefits, for sure (especially from the end user's POV). But you have to pay the price of increased memory usage for that. On Mac, it's not a big issue because it allows to handle much more memory than OS/2 and its memory management is apparently superior to that on OS/2 (and it can handle its memory usage patterns pretty well). Besides, the majority of Mac apps is written using Apple's own toolkits and these toolkits are provided as DLLs by the system (so a typical native Mac app rarely needs anything besides the system libraries). Going further, OS/2 has never had this all-in-one approach implemented to a smooth degree: IBM-provided hacks like LIBPATHSTRICT are clear evidences of that. So it's simply not correct to say that it's the OS/2 way to deploy apps. And I do remember a lot of DLL hell in the past with various OS/2 applications.
Putting it all together, the lack of proper DLL management on OS/2 doesn't allow apps to have their own, private versions of DLLs. The lack of proper memory management doesn't allow to have them all built statically. We have major problems with private / shared memory arenas which get quickly exhausted if one uses a couple of heavy apps in parallel (e.g. Firefox and OOo and/or a Qt app). All this leaves us only one choice: put as much common code to DLLs as possible and make as much apps use these DLLs as possible. Of course this isn't a way to go w/o a decent package manager that ensures DLL integrity and this is where we came to YUM/RPM.
And if you take the modern user's perspective, it doesn't really matter what the application does under the hood as long as you have the application store where you just type its name to smoothly install or remove it. This is basically what Apple Store does on Mac and a respective application manger on any other modern OS (including mobile devices). And if you go with the YUM/RPM approach provided by BWW, OS/2 differs from those only by the fact that on OS/2 the application manager has no handy GUI yet so you have to use the command line. But given that an average OS/2 user is not unfamiliar with the command line and that Yum command line is very simple to use (for basic things like installing an application), it doesn't look like a big price for the convenience for both the developer and the end user. More over, a Yum GUI is on its way so this will make things even more user friendly when it's out.
Firefox will become an RPM installable with Yum very soon too. For this reason, we are trying to reuse DLLs already provided by RPM/YUM as much as possible with each FF release (and will even create more of such DLLs in the future).
