Wine Web Browser

Jump to: navigation, search
This article is part of the HOWTO series.
Installing Wine Business Games Internet Multimedia System and Utilities
Education Other

Warning: This HOWTO comes with no explicit or implicit warranty whatsoever. Use at you own risk!

Wine now has a Web Browser (aka Internet Explorer) application. This was announced with the release of wine 0.9.12: New Winelib Internet Explorer application (all 5 lines of it).

Now just to be sure there is no confusion, we are not referring to a Microsoft program, but the Wine Developers Efforts.

A user asked:how to invoke this IE explorer?

wine iexplore.exe
(or wine iexplore for short)

[May 05](it doesn't have all the UI yet, so you'd better call it like wine iexplore.exe for example).

[Jan 09] A suggestion was raised that packagers add a Wine Internet Icon for testing Wine's web browser, but the consensus was that wine was not ready for this by January 2009. J. Caban: Wine builtin iexplore.exe is far from being usable for users and improving it is low priority. We have enough problems with apps using IE to render HTML that we should take care of. [Ed, this is an Open Source Project so if you want to help with this and can code - you can]


Gecko improvements

Gecko has now had two releases and is a matter of the proverbial watch this space. Wine has continued to improve and gecko has kept apace. If you package wine, due to improvements and work in this area you now can and should look at including a gecko package for wine. J. Caban dec 10: On the next Gecko release, we will change it to use MSI file and all goodies of more standard installation.

A. Julliard: it would be even nicer to pack everything inside the msi file, then we wouldn't need a self-extractor at all...H. Leidekker: Yes, we considered that. It means we need to be able to create a cabinet file, which needs to be done with open source tools if we want distributions to include the packages. Wine itself seems to be about the only option there, but we don't support compression. A. Juliard: If we already need Wine to create the msi file then it shouldn't be an issue to use it to create the cabinet. Compression shouldn't be hard to add.

Gecko and the goal of replacing Internet Explorer

The change was noted in wine.cvs [Jul 3 06]: shdocvw: Get rid of Mozilla ActiveX control dependency.

Wine now uses gecko. J. Caban [Jun 06]:[...] Sometimes (if the app uses HTMLDocument directly, not via WebBrowser, like iexplore does) only [the gecko] option works. [...] [the Wine project uploads] the package to SourceForge and add a script that directs download of it). That will allow us to get rid of Mozilla ActiveX control.

This led to some Q&A from the list [jun 06]:

J. Caban: The plan is to replace IE libraries, not Mozilla ActiveX control. This means replacing the use of Mozilla ActiveX control in Wine (and ReactOS) but it's not an option for apps that want to embed Gecko. BTW if someone wants to embed Gecko, raw Gecko API is a better choice (and perhaps GTK wrapper for Linux) IMO.

J. Caban: I have a cab file that contains all the needed libraries. This is SeaMonkey with some files removed or changed to reduce its size. It would be better to build the package ourselves in the future, but it's not so important ATM. The code that installs Gecko will be in our MSHTML so that no more installers will be needed.

J. Caban: Yes, that's the plan. [...later he added] We want to hide Gecko before user. All settings have to be set the way IE does it and automatically passed to Gecko. Updates can be useful, but it's not really important ATM. And it can be done automatically so there is no need for a new tool for this. wine archive

J. Caban: that's our goal to replace these objects, not to give an app an alternative implementation.

J. Caban: We'll provide our own package so we'll have to do updates ourselves. There are some changes I'd like to do in Gecko to allow better MSHTML implementation and to remove some hacks, but it has nothing to do with packaging and it's not the thing for near future. [...] I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?). That's why MSHTML uses Windows Gecko.

Shortly afterward he informed the list: Wine Gecko installer is in the tree, we have to enable it. All we have to do on Wine side is set one registry value, but first we need to have file available to download. Dimi Paun and J. Ernst quickly provided assistance with this. J. Ernst: This is now live at:

Saving downloading Gecko again

You can use winetricks, or A. English posted [jan08] I was trying to save bandwidth/time while testing/triaiging bugs. Easiest way to do it is [download from sourceforge]

$ sudo mkdir /usr/share/wine/gecko
$ sudo mv /usr/share/wine/gecko

From then on, whenever you run:

$ wine iexplore In any wine prefix, it'll get wine gecko from/usr/share/wine/gecko rather than re download it each time.

Gecko locations

Instructions for installing Gecko are at:

Winehq Bugzilla entry 18421 These state that Wine looks for it at /usr/share/wine/gecko. [...] for my distribution of Wine 1.1.20 the location is [also] specified by an entry in 'user.reg'.

A. English: that's only used if /usr/share/wine/gecko doesn't have it.

Forum Comments

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.

soon as current patches will be committed.

D. Timoshkov noted : still points to an old Gecko package (0.0.1). J. Caban: We can't change it due to compatibility with older Wine versions. We encode Gecko version in URL instead, so will do what you want.

Boaz: Do you have a magic param to download the latest one available? something like: winegecko.php?v=latest J. Caban: No, we don't have, but it sounds like a good idea. It's easy to add.

How about the attached patch? It adds registration code to iexplore.exe, so user may run

$ wine iexplore -unregserver

or even better, just for sure:

$ WINEDLLOVERRIDES=shdocvw,iexplore.exe=b wine iexplore -unregserver to unregister iexplore.

It would be wine specific as native doesn't support self registration in iexplore.exe.

A. Jullard: Yes, I think that's a good idea.

if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it otherwise extract the package and set GeckoPath variable of HKCU\Software\Winde\MSHTML registry key to its location. Then run an app and check if it still works. Note that you have to use current Git, older Wine is not compatible with the new Gecko.

From [a] technical point of view this version differs [a lot from previous ones. The] Previous version was just a SeaMonkey with [..] some files [ manually removed and changed]. This one is [..] built from source (I will create a page on wiki about how to do so). It's based on XUL Runner, which has the same source as Firefox After testing it, I will change [the] Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge.

cd wine/programs/iexplore


Feb 09 J Caban: The last [quite recent] release of Wine Gecko caused a few regressions. Thanks to Alexandre, we've found the reason. The bad news is that the fix requires a new package. [...] I'm planning to do the release tomorrow, so it will be in Git on Friday. One user found a bug and J. Caban explained: Gecko can't find fonts when Wine in ran from build dir. As a temporary workaround you may copy content of fonts directory to fonts directory in build dir.

He was asked: Is this version compatible with Wine 1.0.1 by chance? J. Caban:No, it's technically impossible.

He was then asked: Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko or will we have to wait until 1.2 (that is the next stable release)? J. Caban: No, it would require too much risky changes. The fact that we need a bugfix release proves that it's a bad idea.

D. Kegel: IMHO we should leave the 1.0 branch alone, and just get on with 1.2.

Debug Version of Gecko

D. Kegel asked jan 09 wine devel:can we have a debug version of the gecko download so we can give more useful backtraces?

J. Caban: We already have it, it's on SourceForge. To use it you have to replace existing Wine Gecko installation in c:\windows\gecko\0.9.0 or replace before creating Wine prefix.

D. Kegel noted: WINEDEBUG=+gecko seems to turn on assertions in gecko. Can you add a note about that in the wiki page, if it's true?

Installing Gecko on an older version of Wine
[Dec 06 wine user] I am currently trying to make an app work under wine, and it needs gecko. The automatic installer pop-up, but can't download anything. I think it's because I'm behind a proxy.[...] I looked at the source code, and the installer just download the file from, so I did it myself:

w get cabextract and then
mv wine_gecko ~/.wine/drive_c/Program Files/ wineboot

I also had to add a key in the registry, using regedit : in HKCU/Software/Wine/MSHTML, the key GeckoPath with the value C:\Program Files\wine_gecko.

wine and x86_64 Linux

$ wine iexplore
fixme:shdocvw:IEWinMain "" 1
fixme:ole:CoResumeClassObjects stub
Could not load Mozilla. HTML rendering will be disabled.

the user reported [Jun 06]: I use Firefox/Opera. Why do we have to install Mozilla? I'm using wine in 64-bit linux, though, so that probably has something to do with it.

Another user noted: I would guess you probably need a 32bit version of mozilla.

J.Earnst clarified: You don't need mozilla, but the Mozilla activex control : [...] The user interface is not done yet, you have to supply an URL from the command line (wine iexplore for example). wine archive

Proxy Server

A user asked how to set a HTTP (or otherwise) proxy server in Wine's iexplore at the moment?

J. Caban [wine devel Nov 07]:There are two ways. First is to set these Gecko settings at runtime, depending on IE settings. The right way would be to use wininet to handle http/https/ftp connections. It's something we have to do sooner or later and, while fixing other bugs, we are slowly getting to that state. This is one of many problems that will be solved by it.


Personal tools