Fizzilla or, for the boring, "Mozilla for MacOS X" by Mike Pinkerton last modified on 2/23/2000

What is it?

As some of you may know (and most of you probably don't), Apple is currently developing MacOS X, a replacement to MacOS based on top of Mach3 and BSD but with the traditional Macintosh look and feel. In order to allow developers to quickly port their existing MacOS-based applications to MacOS X, Apple has created a portability layer named Carbon. Carbon takes the nearly 9000 MacOS APIs, trims the dead weight, adds some new stuff, and offers the remaining 6000 APIs for use on top of MacOS X. All developers need to do is tweak their existing MacOS code to fit the new Carbon API and their apps will run in a separate process, taking full advantage of MacOS X's memory protection and pre-emptiveness.

Around May, 1999 (Mozilla milestone 5, or M5) we made those modifcations to Mozilla and created a single binary that ran on both MacOS 8.5 and MacOS X. The resulting app, code named Fizzilla, made its public debut onstage at the MacOS X Session at Apple's WWDC '99. People liked it.

The New Direction

In the time between May and December, 1999, Apple did a significant amount of profiling work on MacOS X using Fizzilla as a test application. Their findings set us in a new direction which we believe will yield the best possible solution for many of the problems which have traditonally plagued our MacOS products.

Instead of relying fully on Carbon for the entire app, we have decided to take a hybrid approach. For the front-end and drawing code, we'll use the same MacOS code on top of Carbon that the MacOS 8/9 product uses. However, on the backend, we'll leverage the fact that MacOS X is BSD Unix under the hood and use our Unix codebase for threading and networking. While this means that while we no longer have a single, "SuperFat" binary that runs on all MacOS platforms, Fizzilla will be much faster than its MacOS counterpart. Using the Unix code on the backend also has more benefits. It allows us to take advantage of the threading libraries present in BSD as well as Quartz, neither of which are available through the Carbon APIs.

Since we're building the Unix code in addition to Carbon code, we also have to modify our build system. On MacOS X, Fizzilla will build using gmake, just like our linux client. While it pains us to give up the IDE, sharing as much as we can with the unix build system will reduce the likelihood that Fizzilla will bitrot and not be able to build anymore.

Where Are We Now?

Apple has provided patches for our M12 release which I am trying to get worked into our build, though my own time is limited. While our test-app "Viewer" builds and runs, it does not actually render anything yet. The three major steps to getting Fizzilla back to its WWDC status are:

• Fix a problem with libIDL and constants in headers generated from IDL all being zero
• Port xptCall to allow XPConnect to work under Mach-O.
• Complete an entire build. Right now it stops in editor somewhere, which is enough to launch "Viewer," but not "Mozilla."
• Get "Viewer" to render content. We think this is just some events getting dropped somewhere.

These issues and other remaining issues are covered in a What's Remaining document. This is where you (the average Mozilla citizen) can help out!!

How Do I Build?

Here you go: Setting up the build environment

Note that there are still problems and since I haven't checked in the patches, so it's sort of moot.

Why not base Mozilla on Cocoa (Yellow Box)?

No one wants to write in objective-C. [For the humor impaired, this is a joke]

More importantly, however, I don't believe that obj-c can easily be fit into the Mozilla codebase without an adaptor layer between the c++ and the obj-c at every calling site. Once you go there, what's the point? There is already such little amounts of native (OS-specific) code in Mozilla, it really isn't worth it.

That said, we are not going to stop anyone from trying!! Obj-C implementations of Widget at GFX might be an interesting exercise.

Special Thanks

Many thanks to the following people at Apple for helping out: Eoin Norris, Dave Evans, Curt Rothert, John Signa, Christine O'Sullivan, and John Chang.