New Wine Gecko

Jacek Caban jacek at
Sun Dec 28 19:24:21 CST 2008


As there will be a new Gecko release soon, I'd like to give you a good 
background over what's going on as I feel that there is some 
misunderstanding on it that I'd like to clarify. I'm sorry for the long 

First, let me give you a short history of the Gecko package.
As we started using Gecko in our MSHTML implementation, we had to 
provide our own package and an easy way for its installation. I've 
prepared a package that actually was a temporary solution. It was a 
SeaMonkey build that had some files manually removed and modified to 
reduce its size. It was, of course, hacky and ugly but, as there was no 
urgent need for changing it, we used it for over a year.

The next version was built by me. The build process was long and ugly - 
it needed a Windows installation and MSVC6. Except that I had to try 
many versions before finding one that worked fine for Wine, as it had 
both to compile with MSVC6 (back then they were switching to a newer 
compiler that needed actctx) and work with Wine (there were a few APIs 
that were not implemented in Wine that they started using). Also, there 
was the XULRunner project that looked promising but proved to not be 
good enough for us. I ended up with building the SeaMonkey target and, 
again, modifying and removing some files afterwards.

Now, not only because of CS4 but because we really should follow new 
Gecko versions as well, the time to release a new package has come. The 
first decision was to try again by building with MinGW on Windows. I've 
tried it with limited success and then I found that Mozilla developers 
have recently worked on building Mozilla with MinGW under Linux (for 
code analyzers). That was something I hoped to do some day, so I gave it 
a try and it came out that it works better than compiling on Windows! 
Also XULRunner project has matured so that we may use it, avoiding other 
pains from previous packages.

But not all is so good. Some changes introduced in the recent Gecko have 
prevented Wine from working correctly. It was unnoticed for long time 
because we were using the 1.8 branch, while the newest is 1.9. Because 
of it, I had to add serious patches (previous build had only minor 
changes in code) to fix it. I'm working with Mozilla developers to get 
these patches to official Gecko. We definitely want to avoid  
maintaining such differences.

There are other advantages that will come with the new Gecko. I'm going 
to make a debug build that seems to work really well on Wine. Although 
it causes an assert in dbghelp that I didn't look at deeper, for one 
build I was even able to step through Gecko code with winedbg. Hopefully 
Valgrind will be happy with it.

Also, I'm going to put the code to Git and provide a good building 
instruction. It's not trivial to build the package, but hopefully with 
some efforts everyone will be able to succeed with it. In this place I'd 
like to note: if you're not planning to work on Gecko (I mean not even 
MSHTML, but Gecko itself), there is no reason to do it. Also I know that 
some package maintainers would be interested in building it. Please, 
don't do it! You will realize that it is not possible with a fresh Linux 
installation without manually setting up environment. Also, due to its 
complexity, I'm worried about broken builds. I don't really see the 
reason to do it. If it's a matter of trust policy... well, you've 
trusted my builds for over three years now, so I'd like to ask you to 
keep trusting me...

Also, I didn't really have a clear idea about version numbering. The 
first, temporary, package was numbered 0.0.1. The next one was 0.1.0 
with plans to release 0.1.x if we'd release a new package on the same 
code base (there was 0.1.1 candidate that was never released). My plan 
was to release a package compiled under Linux as 1.0.0, and until then 
release next 0.x.y builds. Now that we compile the new package on Linux, 
I still don't like to call it 1.0.0, because of patches needed in our 
build. I'd prefer to wait with 1.0.0 hoping to fix the difference for 
next major release. I don't feel strongly about it so if anyone has any 
suggestion, I'm happy to change the plan.

I plan to put Wine Gecko code into a public Git so developing it will be 
easier. Now releasing a new version should be much easier (as long as we 
won't find a new blocker, but if we'll find it quicker, it will be 
easier to fix).

I'm happy with releasing the build I've written about a few days ago. I 
got feedback from Mozilla developer about things we could get to Mozilla 
tree and I'm going to try to get some patches to Mozilla. That shouldn't 
delay our release IMO, so I'm going to release tomorrow unless there are 
any objections. I hope to have another release in a few months that well 
be closer to main stream Gecko.

Please let me know if you have any suggestion or question.


More information about the wine-devel mailing list