Wine 20010112 has been released. Main changes are:

• Many fixes for Winelib support on Sparc.
• Major DirectDraw restructuration.
• Unicode combobox and listbox.
• New MSVCRT dll.
• Lots of bug fixes.

Gav State submitted a patch to fix a regression introduced by the huge DDraw reorganization made by the TransGaming folks (previous issue).

Alexandre Julliard got annoyed because the patch made use of an internal USER function from outside the USER DLL.

Since Gav had in mind several other areas where this feature had to be used (like getting at the drawable to set up a glX context for 3D, he asked whether options exist.

Alexandre proposed several ways, like exporting a Wine only function from USER, or store some Wine attributes for a window as Windows' properties (like the X11 window matching the Wine one); this would help using those attributes throughout the code (when needed).

Ove Kaaven proposed a rather different approach Instead of loading up dlls/ddraw with driver-dependent code, perhaps we should consider driver separation not only in dsound (like it's done now, with IDsDriver in the wineoss driver), and like I want to do with dinput (IDiDriver in winmm's joystick driver etc), but also in ddraw?

So the x11drv (and any future graphics drivers) would export a IDdDriver-or-whatever-it's-called COM interface, that dlls/ddraw could then build upon, just like in windoze. All the DGA, DXGrab, and GLX code would then have to be moved into the x11drv, obviously, so it'd be a lot of work, but it'd certainly give us some advantages as well...

Alexandre before entering another big files shuffling liked to know if it was completely acceptable (he was worried with creating new interfaces, and hoped MS had already defined such interfaces ; he also didn't like interface that didn't provide the relevent abstraction level).

However, Gav was really in favor of the proposal: On further reflection, it does sound like this is the Right Thing(tm) to do. After all, Windows' display and input drivers have DirectX hooks in them, so why shouldn't Wine's?. Gav, Ove and Patrik Stridvall exchanged some views on the best way to handle it.

Gav also was happy to sign us (EdNote: TransGaming)up to do this kind of restructuring, but there are some other things that are higher on our priority list at the moment. , and put the real implementation on hold for a couple of weeks.

So be prepared to get some more DDraw code modification in the future weeks.

John R Sheets wrote a patch that provides basic stubs for the IWebBrowser interface. My test case was a simple MFC application with the IE browser control imported. The application comes up now in Wine, with a blank browser control of course. I'm not sure of the best way to actually implement the renderer (perhaps the Mozilla control...?).

As John put it, rewritting a full COM object that handles Web rendering would be a huge task (and a project of his own).

James Hatheway replied with some bits of a solution: We (Macadamian) have done some research on that topic, using Mozilla as our rendering engine. We haven't actually completed the work required, and have put development on it on hold for a while. Since it seems like you are ready to leap into development now, if you need any info about issues of tying Mozilla to Wine, feel free to ask.

No reply made its way to wine-devel, but it's not impossible that some work has started on the matter of integrating Mozilla into Wine to implement the IWebBrowser COM interface in the shdocvw DLL.