June 2008 - Wine-Devel - list.winehq.org

RE: DX6 more compatibility.

by Michael Karcher

Am Freitag, den 27.06.2008, 18:24 +0200 schrieb Stefan Dösinger: > On a sidenode, I think it is impossible to QueryInterface > IDirectDrawSurface7 from IDirectDrawSurface < 7, or vice versa, but I am not > sure. Nope. You can sucessfully query IDirectDrawSurface{,2,3,4,7} from IDirectDraw{,2,3,4,7} without problems, at least on DirectX 9. Wine matches Windows behaviour here. Windows (DirectX 9) has seperate refcounts for seperate IDirectDrawSurfaceX, as it also has for IDirectDrawX. Wine does not have it. This means that we need different vtables for all IDirectDrawSurface versions, as DDraw does, too. Regards, Michael Karcher

June 29, 2008

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.

by Dylan Smith

On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov <phil.krylov(a)gmail.com> wrote: > Of course this looks most sane. But I'm asking if you're going to make > use of the dwEmulatedVersion other than "< 0x200"? That is, under what > circumstances we should emulate version 2 or 3 when we have support > for version 5? It's interesting to me, because it seemed to me that > the native versions (starting with 2.0) are very compatible to each > other. > > -- Ph. I know that versions 2 and 3 are very compatible with, since they register the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, which means that programs would need to explicitlydecide which version they are using depending on which dll they load and which class they specify. Certainly there are differences between richedit 3 and 4.1, but I don't know if programs would depend on these differences.

June 29, 2008

Re: sound3d patch

by Chris Ahrendt

Maarten Lankhorst wrote: > Hi Martin, > > 2008/6/27 Martin <martin.marsan(a)gmail.com>: >> Hi. >> >> I am working on a patch to fix a bug which prevents certain games from >> starting. The bug will make wine spit out: >> >> fixme:dsound3d:IDirectSound3DListenerImpl_QueryInterface Unknown IID >> {31efac30-515c-11d0-a9aa-00aa0061be93} right before it crashes(see bug >> 12240). >> >> I am working on implementing the ability to return this interface by calling >> the function that fails(IDirectSound3DListenerImpl_QueryInterface()) >> with an already acquired (dsound?) interface and IID being IKsPropertySet. >> I was able to make a patch which helped me get around this bug in one game, >> but I don't have very deep knowledge of how wine works internally. Because >> of that, >> I am not sure if I should implement something more to prevent other issues. >> Also, I don't know if I need to make some changes to make the patch more >> "correct" or complete. >> If somebody could have a look at the patch, or try it out or give me any >> other feedback, that would be appreciated. > If you aren't sure, try creating a simple test for it. > > Cheers, > Maarten. > > This would probably be a better patch: int nobuff = This->device->nrofbuffers - 1; char *buffer = NULL; if (nobuff < 0) nobuff = 0; else if (!nobuff) nobuff = 1; if (!( This->device->buffers[no buff] )) { ERR(" no device\n"); return false; } buffer = This->device->buffers[no buff]; if (This->device->buffers) IKsBufferPropertySetImpl_Create(nobuff,(&This->device->buffers[nobuff]->iks)); Chrisb

June 29, 2008

OFN_ENABLESIZING support in standard dialogs

by Chris Howe

Bugs 5034, 10284 and 10394 relate to un-resizable file open dialogs in various programs - to be honest I came across this discrepancy running native NOTEPAD.EXE. The file open dialogs are implemented in comctl32, specifically filedlg.c and the templates live in cdlg_xx.rc In Windows, to make them resizable one uses the OFN_ENABLESIZING flag, which is amongst Wine's UNHANDLED_FLAGS, so it has no effect in Wine. Reading the history this flag has been available in all versions of Windows from 98 up. I am wondering how to go about supporting this flag though, weather the dialog templates need changing, or if we could add the support purely in the dialog creation code? -- Chris

June 29, 2008

Re: shell32/tests: Add test for SHFileOperation [resend]

by Vitaly Perov

> You didn't set the FOF_MULTIDESTFILES flag. I use &shfo2. In shfo2 this flag is always set. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

June 29, 2008

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.

by Phil Krylov

2008/6/27 Dylan Smith <dylan.ah.smith(a)gmail.com>: > Currently msftedit.dll is implemented by loading riched20.dll and then > riched20.dll registers the classes that msftedit.dll normally register. > Native msftedit.dll appears to be a full implementation of the richedit > controls, rather than a wrapper. > > Here are the options that I can think of: > 1. We could continue to implement msftedit.dll as a wrapper around > riched20.dll. This patch would be a step in that direction. Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than "< 0x200"? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other. -- Ph.

June 29, 2008

Bad links in 1.1.0 announce

by Alexei

There are two links: http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.0.tar.bz2 http://prdownloads.sourceforge.net/wine/wine-1.0.tar.bz2 in http://winehq.org/?announce=1.1.0, but it's stable version, normal link is: http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.1.0.tar.bz2

June 29, 2008

RFC: Adding tests for windowless richedit services

by Austin Lund

I've sent versions of this to wine-patches in the past. In this version, I've stripped out most of the tests except those for the initial creation of the ITextServices object. All tests in this patch succeed under wine currently.

June 29, 2008

Re: quartz Rewrite the avi splitter so that video and sound run in separate threads, with tests

by Maarten Lankhorst

Hello Detlef, 2008/6/28 Detlef Riekenberg <wine.dev(a)web.de>: > On Do, 2008-06-26 at 22:58 -0700, Maarten Lankhorst wrote: >> there are still some things I need to figure out with avi. > > Is avifil32.dll usable for that? > Does Windows reuse avifil32.dll or did MS again lots of code > duplication? It's slightly impossible to re-use the existing code as it expects a file based backend. The avi filter in wine should also be able to use a http, or any other backend. The issues are more in handling of certain operations like seeking and stop/start/stop, which I haven't fully handled well yet. Cheers, Maarten.

June 29, 2008

Re: quartz Rewrite the avi splitter so that video and sound run in separate threads, with tests

by Detlef Riekenberg

On Do, 2008-06-26 at 22:58 -0700, Maarten Lankhorst wrote: > there are still some things I need to figure out with avi. Is avifil32.dll usable for that? Does Windows reuse avifil32.dll or did MS again lots of code duplication? The current Problem in Wine is the correct importlib: avicap32 + avifil32 + msvfw32 => vfw32 ( http://bugs.winehq.org/show_bug.cgi?id=14085 ) -- By by ... Detlef

June 28, 2008