Re: [9fans] Gecko based web browser

[Andy Newman <atrn@zeta.org.au>]

Christopher Browne wrote:
>Those two "code bases" represent a _mite_ more than 250k of code, and
>I suspect that the Plan 9 port would be, um, challenging...

(Some sanity at last!)

I've been "inside" Mozilla quite a deal and I can guarantee,
1000%, that any port is a decidely non-trivial undertaking.
We're talking about millions of lines of code here guys (my build
of it on FreeBSD takes up 1.5GB of disk and I leave out half of
the bloody thing). And there's pretty much zero documentation on
its internals. Most of the comments from people here seem to indicate
a very casual acquaintance with Mozilla, either that or a naive belief
in the project hype. So here's some tips on a Plan 9 Mozilla port from
some one who's been in the guts of the program in question...

First thing you need to do is write (or port :) a half decent C++
compiler.  Thankfully Mozilla doesn't ask a lot of the library, it
has its own (which needs porting).  But there's no cheating and
going inventing some Plan 9 C++. It has to compile Mozilla which
uses mosts of the bits and pieces C++ has to offer. So when you've
written or ported your C++ compiler you can think about just getting
the build system functional This may need Perl and bash ports and it
may be better and easier rewriting the whole thing rather than mash it
(high brucee) into Plan 9.  The next week can be spent getting the code
compiled without errors.  There's a few thousand souce files and associated
headers, oh, and the IDL compiler will need to be made to work before
compiling anything, I guess I just saw that as part of the build system.
Linking anything correctly is a bonus at this stage. The lack of shared
objects and ld.so may present some issues with the component system
and needs a good looking at. But just getting XPCON going will take
some doing and there's a little assembler in there which will depend
on the compiler's implementation of virtual functions. Needs a good
testing session.  The remaining platform specific stuff might be quite
easy compared to the previous load of work.  An implementation of a
graphics backend, the portable widgets replace the need for any Plan
9 GUI toolkit to be invented, some sort of embedding shell needs to
be implemented (a la the gtk_moz_embed the 250K program uses - the
Mozilla shared libs will add many MBs to the real code and its
run-time memory footprint measures in the tens to hundreds of MB
depending on page complexity). I've left out loads of things that
need porting considerations - JavaScript, the thread library, various
codecs etc...

So get going people, bit of work to do.