New Wine Gecko
jacek at codeweavers.com
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