MS compatible interface to xulrunner?
jacek at codeweavers.com
Mon Jul 19 10:11:10 CDT 2010
On 7/19/10 3:29 PM, Thomas Kaltenbrunner wrote:
> I am interested to port the wine interface to the xulrunner back to
> mswindows to access the xulrunner via a IE compatible interface. So it
> would be easy to replace an embedded IE with the gecko-engine.
> After some code browsing I thing it will be some of the "DLLs",
> especially mshtml and shdocvw.
> I just wanted to hear from you an opinion about that project.
> What will be the main changes to the wine code - besides renaming of the
> Where do you see problems?
> Did somebody else worked on that or implemented it already?
The main problem is that what we need (and we need it because apps need it)
doesn't belong to XULRunner. Wine's IE libs implementation needs an
architecture compatible with MS implementation. We do ugly things with
Gecko to make it work. For example we don't use necko for loading
documents. We use urlmon.dll instead. An app may register its own protocol
handlers, overwrite an existing handler or simply depend on us using
wininet for http. We also allow using our jscript instead of Gecko JS. This
is needed to allow scripts written for IE work as well as interaction
between script and app. There are more smaller things we have to do because
applications need them. I think none of them makes sense to be in XULRunner
There was a project (no longer maintained AFAIK) in Mozilla called Mozilla
ActiveX control. It was kind of a replacement for WebBrowser control - a
high level part of IE embedding API. It can work for some simple
applications, esp if they are prepared to use it. I think it's a good
compromise between having anything like that in XULRunner and not having
things that don't belong there.
In my opinion, if your goal is to make embedding Gecko easier, it would be
better to work on Gecko embedding API itself. Currently, although it's easy
to do simple HTML embedding, if you want to do anything more complicated,
you have to go through semi-internal, not backward compatible interfaces.
Some things like interacting with scripts from the pages are not possible
at all (although recently introduced ctypes might have changed it). It's
far from being nice for developers IMO. Mozilla is getting rid of backward
compatibility for mozilla2 (Firefox 4). It will surely hurt apps using
XULRunner for embedding, but it may be also good time to rethink the API to
be more friendly.
More information about the wine-devel