Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #78 For 15 Jan 2001

By Eric Pouech

Table Of Contents

Introduction

This is the 78th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 104 posts in 360K.

There were 38 different contributors. 22 posted more than once. 22 posted last week too.

The top posters of the week were:

1. Headlines

 

People:

Wine 20010112 has been released. Main changes are:

2. DirectDraw reorganization (cont'd)

12 Jan 2001 (11 posts) Archive Link: "Reenable DXGrab"

People: Gavriel State, Ove Kaaven, Alexandre Julliard, , Gav State, TransGaming, Patrik Stridvall

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

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.

3. WebBrowser DLLs

13 Jan 2001 (2 posts) Archive Link: "Initial stubbing of shdocvw.dll (IWebBrowser)"

People: John R Sheets, James Hatheway, 

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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.