March 2006 - Wine-Devel - list.winehq.org

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: > I made some fixes to correct work. > > Changelog > add --with-fontdir parameter to configure for set WINE fonts > placement. Sorry, what is broken with my patch? http://www.winehq.org/pipermail/wine-patches/2006-February/024535.html -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: KERNEL32: Improve descriptions

by Marcus Meissner

On Sun, Mar 05, 2006 at 07:39:04PM +0300, Vitaly Lipatov wrote: > On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > > LPWSTR lpTempFileName ) > > > > *Please* don't change nice readable parameter names into the > > horrible Hungarian line noise format. > Sorry, I thought we need to fix parameter names according to > MSDN :( > Have we some policy about it? Will I change Hungarian notation to > readable names when possible? Just don't change the name. The *types* should be the same as MSDN, the *names* do not need to. Ciao, Marcus

March 5, 2006

fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Hello, wine-0.9.9 still does not display folders correctly in a file select box (Lotus Notes in this case). Folders and files are displayed with the file symbol. It seems to be only a display issue, clicking on folders still opens them. A screenshot is here http://www.winehq.org/pipermail/wine-devel/attachments/20060223/9f1675d7/fi… shows an example for rd at silverboxy:~/test$ ls -l insgesamt 4 drwxr-xr-x 2 rd rd 4096 2006-02-23 17:08 dir -rw-r--r-- 1 rd rd 0 2006-02-23 17:08 file rd at silverboxy:~/test$ The console shows this log fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:process:GetProcessWorkingSetSize (0xffffffff,0x4075d768,0x4075d76c): stub fixme:process:SetProcessWorkingSetSize (0xffffffff,33554432,33554432): stub - harmless when opening a file select box. Causes this one fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented this wine glitch? Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 5, 2006

Re: KERNEL32: Improve descriptions

by Vitaly Lipatov

On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > LPWSTR lpTempFileName ) > > *Please* don't change nice readable parameter names into the > horrible Hungarian line noise format. Sorry, I thought we need to fix parameter names according to MSDN :( Have we some policy about it? Will I change Hungarian notation to readable names when possible? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by H. Verbeet

On 05/03/06, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Hallo, > > compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL > etc undefined. Same problem for me. http://www.winehq.org/pipermail/wine-devel/2006-March/045297.html > It seems that a patch from Vitaly regarding wined3d_gl.h from > yesterday evening as notor only partial applied. Well, no, the patch is just like that. It assumes GL_STENCIL_BACK_FAIL, GL_STENCIL_BACK_PASS_DEPTH_FAIL and GL_STENCIL_BACK_PASS_DEPTH_PASS are defined, which is not guaranteed. > Appended patch lets me circumvent that problem. I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are interchangeable, but more importantly it makes the same kind of assumptions about what's going to be defined.

March 5, 2006

Re: DirectDraw -> WineD3D patch

by Stefan Dösinger

> That's indeed the reason. Simple fix is to set the rendertarget usage also > for ddraw offscreen surfaces.Not sure if there are any possible sideeffects > of this, but until now i haven't seen any. That looks a bit more complex. I changed the way ddraw and WineD3D interact some time ago, but I didn't update the palette code for that change. I think I have to re-write the palette setting code, it's pretty crappy ATM.

March 5, 2006

[Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by Uwe Bonnes

Hallo, compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL etc undefined. It seems that a patch from Vitaly regarding wined3d_gl.h from yesterday evening as notor only partial applied. Appended patch lets me circumvent that problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/wined3d/device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.145 diff -u -r1.145 device.c --- wine/dlls/wined3d/device.c 4 Mar 2006 17:10:57 -0000 1.145 +++ wine/dlls/wined3d/device.c 5 Mar 2006 14:47:13 -0000 @@ -3773,9 +3773,9 @@ GLint action = StencilOp(Value); - glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); - glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); - glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); + glGetIntegerv(GL_STENCIL_BACK_FAIL_ATI, &stencilFail); + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL_ATI, &depthFail); + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS_ATI, &stencilPass); if(WINED3DRS_CCW_STENCILFAIL == State) { stencilFail = action;

March 5, 2006

World of Warcraft 0.10 Public Test Realm (PTR)

by Tomas Carnecky

At a certain point the screen just turns black, it's always at the same point, and when looking through the +x11drv trace I can see these messages at that point: trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil)) trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40) trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60) trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8) also, these messages don't appear in version 1.9.4 (which is the 'live' version). So I suspect that Blizzard added something related to this function to the 0.10 version which breaks something. When the screen turns black, its just the screen, everything else works, keyboard for sure, I can press 'Esc' to get out of the game, not sure about the mouse though.. Does anyone have an idea how to fix this? tom

March 5, 2006

Re: shell32: Unicode'ify ISFHelper interface

by Michael Jung

Hey Vitaliy, thanks for the comments. I've sent an updated version. On Saturday 04 March 2006 20:26, Vitaliy Margolen wrote: > Here > > +++ b/dlls/shell32/shfldr_fs.c > > + if (uLen < lstrlenW (wszNewFolder) + 4) > and here > > +++ b/dlls/shell32/shfldr_unixfs.c > > + if (uLen < sizeof(wszNewFolder)/sizeof(WCHAR)+3) > Why 4 in one place and 3 in the other? That's because the sizeof expression counts the terminating zero, while strlen does'nt. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

March 5, 2006

WineFile improvements

by John Len

Hello! I am now preparing patch, which should add unimplemented functionality. While preparing the patch, I've got a couple of questions: 1. There is a menu item "Associations". Should I implement it as a control panel applet? Anyway, it's pretty clear, it shouldn't be an integral part of winefile, as it isn't winefile specific. 2. Should Find File be a stand-alone application? 3.What library should pack/unpack use? Should it use zip/unzip utilities or some dll? Thanks for answering any of these questions Yours Truely, Evgeny F

March 5, 2006

Re: KERNEL32: Improve descriptions

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR buffer ) > +UINT WINAPI GetTempFileNameW( LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, LPWSTR lpTempFileName ) *Please* don't change nice readable parameter names into the horrible Hungarian line noise format. -- Alexandre Julliard julliard(a)winehq.org

March 5, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Stefan Dösinger

Hi, > No, it isn't. AFAIK this patch modifies DirectDraw and Direct3D 7 Correct. I started sending 2 header patches, and they were merged. I'll steadily send small WineD3D patches until WineD3D is ready for the ddraw merge, then I'll provide a last patch for testing. If it works fine and AJ likes it, it can be merged. Don't know if it will be in Wine 1.0, depends on the time and how many regressions occur. There's a high number of ddraw / d3d7 apps which work, so regressions are likely. Stefan

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Roderick Colenbrander

> Yes I noticed that the new code was always 1c4 as well, but hadn't > gone back to see what the old code was doing. But 1c4 definitely > seems wrong since the vertex coordinates are all messed up and invalid > according to MSDN. For example z is supposed to be [0,1] but I get > large values, and rhw is also supposed to be between [0,1/MaxVertexW] > but I was getting negative values. I'll look into the FVF code more. I think that those 'wrong' values appear in the cases where 0x1c4 shouldn't be used. The fvf is set by the SetFVF call which is called from d3d8's SetVertexShader. (the comment in drawprim.c saying that the fvf needs to be set in the stateblock from d3d's SetVertexShader can be ignored I think as it appears that's already done by this call) The FVF received by SetFVF is the vertex shader itself. I think something goes wrong with selecting the vertex shader but I haven't looked at this yet. Roderick -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

March 5, 2006

GL_STENCIL-related build failures in dlls/wined3d/device.c

by Gerald Pfeifer

The recent changes to dlls/wined3d/device.c cause the following build failures for me on FreeBSD 5.4, though I assume this is in fact not related to FreeBSD but to xorg 6.8.2 or libglut 6.4.1 on this system. device.c: In function `IWineD3DDeviceImpl_SetRenderState': device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this function) device.c:3776: error: (Each undeclared identifier is reported only once device.c:3776: error: for each function it appears in.) device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use in this function) device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use in this function) gmake[2]: *** [device.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/wined3d' gmake[1]: *** [wined3d] Error 2 The most straightforward patch would be the one below, but it leaves three "variable may be used uninitialized" warnings in the first of the two affected spots. Gerald Index: device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.145 diff -u -3 -p -r1.145 device.c --- device.c 4 Mar 2006 17:10:57 -0000 1.145 +++ device.c 5 Mar 2006 08:35:52 -0000 @@ -3226,9 +3226,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen GLint action = StencilOp(Value); +#ifdef GL_STENCIL_FAIL glGetIntegerv(GL_STENCIL_FAIL, &stencilFail); +#endif +#ifdef GL_STENCIL_PASS_DEPTH_FAIL glGetIntegerv(GL_STENCIL_PASS_DEPTH_FAIL, &depthFail); +#endif +#ifdef GL_STENCIL_PASS_DEPTH_PASS glGetIntegerv(GL_STENCIL_PASS_DEPTH_PASS, &stencilPass); +#endif if(WINED3DRS_STENCILFAIL == State) { stencilFail = action; @@ -3773,9 +3779,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen GLint action = StencilOp(Value); +#ifdef GL_STENCIL_BACK_FAIL glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); +#endif +#ifdef GL_STENCIL_BACK_PASS_DEPTH_FAIL glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); +#endif +#ifdef GL_STENCIL_BACK_PASS_DEPTH_PASS glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); +#endif if(WINED3DRS_CCW_STENCILFAIL == State) { stencilFail = action;

March 5, 2006

Re: Wine 0.9.9 and instalation of AutoCAD 2000

by Boaz Harrosh

Vitaliy Margolen wrote: > Please submit bug reports to http://bugs.winehq.org/ instead of sending > e-mails here. > Bug report aside, he is a developer and he wants to fix this. What he's asking is if any one remember an issue concerning: "map_image Section .rsrc"

March 5, 2006

Re: Wine 0.9.9 and instalation of AutoCAD 2000

by Vitaliy Margolen

Saturday, March 4, 2006, 11:11:35 PM, Dimitry Naldayev wrote: > Hi all, > When I try to install AutoCAD 2000 on Wine 0.9.9 (hmm... it is cvs checkout > about 04 march 2006 21:00 GMT+0500 PERM. I do not remember precise time) > I get error in console: > err:module:map_image Section .rsrc too large (f000+e000/1c000) > and installation programm draw error box with message > "Cannot load c:\windows\temp\_ISTMP0.DIR\iutil.dll" > but the file is present... Please submit bug reports to http://bugs.winehq.org/ instead of sending e-mails here. Thank you. Vitaliy.

March 5, 2006

Wine 0.9.9 and instalation of AutoCAD 2000

by Dimitry Naldayev

Hi all, When I try to install AutoCAD 2000 on Wine 0.9.9 (hmm... it is cvs checkout about 04 march 2006 21:00 GMT+0500 PERM. I do not remember precise time) I get error in console: err:module:map_image Section .rsrc too large (f000+e000/1c000) and installation programm draw error box with message "Cannot load c:\windows\temp\_ISTMP0.DIR\iutil.dll" but the file is present... Any ideas where to dig? --- Dimitry

March 5, 2006

Re: DirectDraw -> WineD3D patch

by Peter Beutner

Hi > I'll look at this, the whole palette code is a bit messy. My suspicion is that > IDirectDrawPaletteImpl_SetEntries / IWineD3DPaletteImpl_SetEntries doesn't > update all surfaces that use a palette. That's indeed the reason. Simple fix is to set the rendertarget usage also for ddraw offscreen surfaces.Not sure if there are any possible sideeffects of this, but until now i haven't seen any. f005d3af1e8f4cacf1211c6fc3952acbd4766332 diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c index 34d91da..4b44035 100644 --- a/dlls/ddraw/ddraw.c +++ b/dlls/ddraw/ddraw.c @@ -1788,8 +1788,8 @@ IDirectDrawImpl_CreateNewSurface(IDirect PixelFormat_WineD3DtoDD(&pDDSD->ddpfPixelFormat, Mode.Format); Format = Mode.Format; - /* If it's a off-screen D3D device, set the rendertarget usage */ - if(pDDSD->ddsCaps.dwCaps & DDSCAPS_3DDEVICE) + /* If it's a off-screen D3D/DDraw device, set the rendertarget usage */ + if(pDDSD->ddsCaps.dwCaps & ( DDSCAPS_3DDEVICE | DDSCAPS_OFFSCREENPLAIN) ) Usage |= WINED3DUSAGE_RENDERTARGET; } }

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Aric Cyr

On 3/5/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > On 3/4/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > I installed AOM (trial) here and I think the issue is related to the FVF. > The function initializeFVF is only partially implemented and in case of the > new code with my patch I see values '0x1c4 / 0x2' while using the old code I > see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look > there and check what the old code did. (the code is quite differently) Yes I noticed that the new code was always 1c4 as well, but hadn't gone back to see what the old code was doing. But 1c4 definitely seems wrong since the vertex coordinates are all messed up and invalid according to MSDN. For example z is supposed to be [0,1] but I get large values, and rhw is also supposed to be between [0,1/MaxVertexW] but I was getting negative values. I'll look into the FVF code more. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

March 5, 2006

Re: wined3d: Implemented fallback for separate stencil operation in WINED3DRS_CCW_STENCIL*

by H. Verbeet

On 04/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > + glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); > + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); > + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); device.c: In function `IWineD3DDeviceImpl_SetRenderState': device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this function) device.c:3776: error: (Each undeclared identifier is reported only once device.c:3776: error: for each function it appears in.) device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use in this function) device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use in this function)

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Roderick Colenbrander

> On 3/4/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't > work > > using wined3d yet. Last week I experimented a bit with it and I managed > to > > get some simple vertex shader examples working (for instance > > http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the > dolphin > > sample from sdk although with small issues). If I run bigger apps like > > 3dmark2001 and others there are huge drawing issues. I'm not very > familiar > > with the shader/drawing code (and vertex shaders in general) so it is > very > > difficult for me to debug. You can try the patch attached to this email > but > > it is far from complete. If you or someone else with enough experience > can > > look at it, you're welcome as my time is limited. > > Thanks for the patch and info Roderick. > > I'll take a look and see if I can get things working a bit better. > Using your patch and the old d3d8 code I hope to whip something > together. I installed AOM (trial) here and I think the issue is related to the FVF. The function initializeFVF is only partially implemented and in case of the new code with my patch I see values '0x1c4 / 0x2' while using the old code I see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look there and check what the old code did. (the code is quite differently) Roderick -- "Feel free" mit GMX FreeMail! Monat f�r Monat 10 FreeSMS inklusive! http://www.gmx.net

March 4, 2006

Re: shell32: Unicode'ify ISFHelper interface

by Vitaliy Margolen

Saturday, March 4, 2006, 10:35:54 AM, Michael Jung wrote: > ChangeLog: > Unicode'ify shell32 internal ISFHelper interface and it's implementors. > dlls/shell32/shellfolder.h | 4 ++- > dlls/shell32/shfldr_fs.c | 55 > +++++++++++++++++++++--------------------- dlls/shell32/shfldr_unixfs.c | > 32 ++++++++++++++---------- > dlls/shell32/shv_bg_cmenu.c | 6 ++--- > 4 files changed, 51 insertions(+), 46 deletions(-) Few questions: > - if (uLen < strlen (szNewFolder) + 4) > + if (uLen < lstrlenW (wszNewFolder) + 4) Probably should use sizeof(wszNewFolder)/sizeof(WCHAR) + 4. A bit awkward but compiled into single number. And it looks like that's what you used in shfldr_unixfs.c <g>. > - _ILSimpleGetText (pidl, szText, MAX_PATH); > - if (0 == strcasecmp (szText, lpName)) { > - sprintf (lpName, "%s %d", szNewFolder, i++); > + _ILSimpleGetTextW (pidl, wszText, MAX_PATH); > + if (0 == lstrcmpiW (wszText, pwszName)) { > + sprintfW (pwszName, wszFormat, wszNewFolder, i++); To be safe probably should use snprintfW instead. > + if (This->sPathTarget) > + lstrcpyW(wszNewDir, This->sPathTarget); Kind of the same thing. Here > +++ b/dlls/shell32/shfldr_fs.c > + if (uLen < lstrlenW (wszNewFolder) + 4) and here > +++ b/dlls/shell32/shfldr_unixfs.c > + if (uLen < sizeof(wszNewFolder)/sizeof(WCHAR)+3) Why 4 in one place and 3 in the other? Vitaliy Margolen

March 4, 2006

Re: WRT: winetest-latest is outdated

by Hans Leidekker

On Saturday 04 March 2006 12:34, Saulius Krasuckas wrote: > And that is done by issuing "make crosstest", which currently fails on my > box using most recent RPMs provided by Hans Leidekker. I've created an updated set of RPMs that allow me to cross build all Wine tests again. Find them here: http://mirzam.it.vu.nl/mingw/ -Hans

March 4, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Olaf Leidinger

Hello! > Is this patch included in Wine-0.9.9 ? No, it isn't. AFAIK this patch modifies DirectDraw and Direct3D 7 Ciao, Olaf

March 4, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Dimitry Naldayev

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > Hi, > I've brought my DirectDraw over WineD3D patch in a form where I want to show > it to the public for review. I've uploaded it to > http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below > the game list). > > If there are no fundamental objections against it, I'll start sending patches > for WineD3D. The changes I'll make in small patches :) are: > > -> Header fixes, that wined3d_interface.h can be included with d3d.h > -> Adding methods to WineD3D for DirectDraw rendering > -> Adding the 2D only surface implementation to WineD3D > > When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and > wine-user for a broad regression testing, and when the regressions are out, > the ddraw can be replaced(From my POV, AJ has the last word of course ;) ) > Is this patch included in Wine-0.9.9 ? The summary for Wine-0.9.9 say "+ Direct3D 8 and 9 now use the same code" or this is separate thing from yours patch ? -- Dimitry

March 4, 2006