mshtml #2: Added warning if a wrong Wine Gecko package version was found.

Jacek Caban jacek at
Thu May 31 10:19:23 CDT 2007

Alexandre Julliard wrote:
> Jacek Caban <jacek at> writes:
>> Yes, that's my plan, but I'm not sure why it's important for this patch.
>> Currently Wine downloads always the same Gecko version that was never
>> updated, so this check should work with current Wine. It will change
>> once we will switch to the new version. I have patches that will use
>> query encoded in URL to specify the package version and it will use the
>> same defined version string as version check in this patch, so switching
>> to the new Gecko won't be much more than one line patch.. It requires
>> changes both in Wine and redirecting php script. I have patches for both
>> and this was the first patch in this direction. I only have to test the
>> rest of patches and send them (hopefully I will find the time to do it
>> tonight).
> My concern is that this sort of thing needs to be planned correctly to
> work in the long run, and it's not clear what the purpose of that
> version check is. Is there a dependency that would make Wine require a
> specific version?  What happens if you use a new Gecko with an old
> Wine?  Can you make different versions coexist?

The plan is to pass the version in URL query. Then the redirecting
script will take care on choosing the correct file from SourceForge.
It's backward compatible as older Wine won't pass the version so script
will assume that an old Gecko is requested. The new Gecko doesn't work
with old Wine (that's why we have to guaranty that it will download an
old Gecko). It's because we depend on some Gecko behaviors that have
changed. It's both due to Wine (we have to do some not nice tricks, to
not say ugly hacks, to make loading document work correctly) and not
perfect backward compatibility of Gecko. Also it's not guarantied that
newer Wine will work with older Gecko. Currently it will work, that's
why I think simple message is enough for now to not force people to
download over 5MB if their apps work without it. But we have to use some
unfrozen interfaces and they may change in the future preventing
backward compatibility. Although we probably could add some workarounds
when it will happen, I would be painful to support few Gecko version. So
if it will happen in the future, then we can change this check to never
use older Gecko (and perhaps add a nice updater).
By coexisting different versions you mean in one Wine prefix? Yes, it
would be possible, but I don't see much point of it. If you think it
should be done this way, I may implement so (it prevents current
patches, these changes would be in another peace of code).

>> We are very far from being able to support other archs, so I thought
>> it's not worth to care about it ATM.
> But then there's no sense in adding #ifdefs for it. Putting the
> architecture in the request wouldn't be much harder, and would avoid
> hardcoding in the client knowledge about what files are available on
> the server.

I've sent patches that replace previous ones. There are removed #ifdefs.
We may back to arch problem later, just like we do now with different


More information about the wine-devel mailing list