Wine Web Browser
|Installing Wine • Business • Games • Internet • Multimedia • System and Utilities|
|• Education • Other|
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 http://google.com 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 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]:
- In theory, do you think your implementation when finished could be replacing the "Mozilla ActiveX control" on windows (and ReactOS).
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.
- Are you intending to produce a PE Gecko installer maintained by you or are you using a ready made package?
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.
- Will this package be updated from time to time when Gecko is updated? and kept as current as possible?
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
- You will, however, need an alternative GUID for windows if needed to run alongside IE.
J. Caban: that's our goal to replace these objects, not to give an app an alternative implementation.
- Will/are you in contact with Mozilla.org people to support us in this task. (Updates, chromes, settings, plugins ...)
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 wine_gecko.cab file available to download. Dimi Paun and J. Ernst quickly provided assistance with this. J. Ernst: This is now live at: http://source.winehq.org/winegecko.php
- Some have wondered if it should be included in the wine package. J. Caben [Feb 08 wine devel]: Compiling the package is quite tricky. I've compiled it on Windows XP using MSVC. There is no other way ATM, so I think that my Gecko package should be included as is in Linux packages. [...] The source available is on Wine's SourceForge site. A user commented: Time to get rid of the download, and just bundle gecko outright. J. Caben: I'd agree, but we need Gecko packages. AFAIK only Gentoo supports it ATM.
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 wine_gecko-0.1.0.cab]
$ sudo mkdir /usr/share/wine/gecko $ sudo mv wine_gecko-0.1.0.cab /usr/share/wine/gecko
From then on, whenever you run:
$ wine iexplore http://www.winehq.org In any wine prefix, it'll get wine gecko from/usr/share/wine/gecko rather than re download it each time.
Instructions for installing Gecko are at: http://wiki.winehq.org/Gecko
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.
- [dec 08 J. Caban]: 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.
- Dec 08 wine bugzilla J. Caban: The package (including source code and debug build) is on SourceForge and patches to the new Gecko are in Wine. As soon as these patches will be applied, Wine will use only the new Gecko. Also building instruction is on Wiki. What remains to do:
- put the code to public Git
- Clean up the code (I've sent only a minimal patch for the release)
- Add support for debug build. Currently it's working, but hard to use because manual setting of environment variables is needed. I will send a patch as
soon as current patches will be committed.
- Also new Gecko means need for all packager to update packages. We should setup some way for announcing new releases as not all packagers follow Wine-devel.
- Dec 07 wine devel J. Caban: As you probably have noticed, downloading Gecko on first use confuses users. Now, with last week patches, there is an other way to do it, transparent for users. MSHTML code looks for cab file in $data_dir/gecko (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine from build dir, it looks for $build_dir/../gecko. Wine checks it both in wineprefixcreate and, if Gecko is not installed, on first usage. It means that if you download wine_gecko-0.1.0.cab from SourceForge and put it in the right place, you will no longer have to care about installing Gecko.
D. Timoshkov noted : http://source.winehq.org/winegecko.php 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 http://source.winehq.org/winegecko.php?v=0.1.0 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.
- Nov 07 wine devel a discussion arose: A. Julliard: The idea would be that there should be an easy way to uninstall it, so if Gecko is installed the app will try to use that, and if it doesn't work we can tell users to uninstall Gecko and let the app install IE instead. Ultimately of course the goal is that they never need to do that.
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.
- V Kamuju [Aug 07 bugzilla] If there are any new frequently use command line options, we can open bugs for those. We need to find the frequently used ie options and fix them.
- [May 07] J. Caben: It's time to update our Gecko package. [...] I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download:
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.
- Expected visible difference should be: - Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) - Pages that require plugins will render like there was no plugin instead of offering downloading one (that doesn't work anyway)
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 184.108.40.206, which has the same source as Firefox 220.127.116.11. 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.
- [Jun 06] M. Hearn replied to this question: can wine fake internet explorer, so i don't need to install the real thing?...: Mostly yes, but that area of code is still being worked on quite heavily. We're supposed to be able to use Mozilla but last time I tried running "wine iexplore" it told me it couldn't load Gecko so I'm not sure what's going on there .... Right now we don't set the registry key saying we have IE installed, even though many of the DLLs the app probably needs are there and functioning correctly. I think the plan is to add this reg key after the last of Jaceks IE work is merged but only the big J himself could comment on that. wine archive
- J. Ernst: you don't need mozilla, but the Mozilla ActiveX control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though. At least it used to prompt the user and download the Mozilla ActiveX control when needed by other apps before.
- [Apr 06] M. McCormack: when Jacek has finished off moving the Mozilla interface into mshtml we should be able to advertise IE as being installed. wine archive
- [Mar 06] A. Julliard: it's not in the path, but running it with 'wine explorer' should work no matter where it's installed. wine archive
- [Suggested Summer of Code project Mar 06] Complete the Wine Web browser (aka. Internet Explorer) frame (menu/toolbar/status bar) in shdocvw. We currently have code to render HTML, thanks to Jacek's Mozilla work, and a frame with no controls.
- W. Ogburn [Apr 06] It doesn't yet have things like a location bar or any control mens or buttons, but you can pass in a URL on the command line, like wine archive
- cd wine/programs/iexplore
- ./iexplore www.google.com
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 wine_gecko-0.9.0.cab 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 http://source.winehq.org/winegecko.php, so I did it myself:
w get http://source.winehq.org/winegecko.php cabextract wine_gecko.cab and then mv wine_gecko ~/.wine/drive_c/Program Files/ wineboot rm wine_gecko.cab
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 : http://source.winehq.org/mozactivex [...] The user interface is not done yet, you have to supply an URL from the command line (wine iexplore www.google.com for example). wine archive
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.