- Wine-Devel - list.winehq.org

Fix recently introduced SEGV in DOCFILE IStorage implementation
by Troy Rollo Feb. 24, 2005

Feb. 24, 2005

After changing StorageBaseImpl, StorageInternalImpl was not updated to reflect the change. ChangeLog: Fix SEGV in IStorage implementation due to structure mismatch between StorageBaseImpl and StorageInternalImpl.

1 0

pcmconverter.c question
by Jeremy White Feb. 23, 2005

Feb. 23, 2005

The attached patch fixes all remaining test failures in winmm when run in interactive mode on my box with Wineoss. It does so by making msacm conversions start aligned (which lets them finish aligned for my test cases). However, it's clear that Robert Reif intended them not to be aligned. My question is: why? Cheers, Jer

2 1

Re: Re: World Of Warcraft
by fenix＠club-internet.fr Feb. 23, 2005

Feb. 23, 2005

----Message d'origine---- >De: Colin Wright <c.d.wright(a)tesco.net> >A: Raphael <fenix(a)club-internet.fr> >Sujet: Re: World Of Warcraft >Date: Mon, 21 Feb 2005 21:07:14 +0000 > >Raphael wrote: > >> Ouppsss >> >> better patch >> >> sorry >> >> Regards, >> Raphael >> >> On Monday 21 February 2005 09:58, Alex Woods wrote: >>> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote: >>> > can you try this patch ? >>> >>> Yes, doesn't look any different though. I did notice that with either >>> patch I get this though: >>> >>> 0009:warn:opengl:wglGetProcAddress Did not find extension >>> wglGetExtensionsStringARB in either Wine or your OpenGL library. >>> >>> Whereas without the patches I get this: >>> >>> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) >>> 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90) >>> 0009:trace:opengl:wglGetCurrentDC () >>> 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8 >>> - Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB () >>> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string" >>> >>> So something must be broken ;) > >I have absolutely no understanding of this but in the list at the >end of your patch mailed to the list there is... > > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, > >and 5 lines later > > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL} > >Since it's the only entry where the string and >pointer/function/object/structure/whatever don't match I wondered it >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather >than. > You are right Seems that lionel made a typo :) Thx Regards, Raphael

4 6

Cygwin X11 server, notepad and message boxes
by Krzysztof Foltman Feb. 23, 2005

Feb. 23, 2005

I'm trying to run notepad on WINE, with DISPLAY environment variable pointing to Cygwin (X Server 6.7.0.0-12) running on my Windows XP machine. It works rather OK-ish, but when I try to close Notepad, it gets stuck in GetMessageW function call after displaying a "text changed, do you want to save ?" dialog box: trace:msg:GetMessageW (1117) mask=0000007f, bits=00000000, changed=00000000, waiting 0009:Call kernel32.ReleaseThunkLock(406ce6f8) ret=409b79a3 0009:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409b79a3 0009:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403893f4,ffffffff,00000000,00000000) ret=409b79c7 0009:Call kernel32.WaitForMultipleObjectsEx(00000001,403893f4,00000000,ffffffff,00000000) ret=40ce1838 0009:Call ntdll.NtWaitForMultipleObjects(00000001,406ce32c,00000000,00000000,00000000) ret=404e8989 I guess the bug is not in notepad, but in Wine message handling, as it's not the only program, that freezes after displaying a dialog box. It doesn't happen when MessageBox is called from WM_KEYDOWN handler, but it DOES happen when MessageBox is called from WM_CLOSE handler, but only if WM_CLOSE was sent by system after clicking Close or presing Alt+F4, and not sent or posted by application itself. http://foltman.com/wintest-dlginclose.zip Any idea what it may be ? deadlock ? The version of Wine I'm using was grabbed a couple of hours ago from anonymous CVS. Krzysztof

2 1

Re: rsabase: Make rsabase a wrapper around rsaenh
by Jonathan Ernst Feb. 23, 2005

Feb. 23, 2005

Le mercredi 23 février 2005 à 13:50 +0100, Michael Jung a écrit : > Ok, that makes rsabase a really trivial dll. Please remove dlls/rsabase/main.c > from cvs (Is there any way to capture this in a diff?) diff -u dlls/rsabase/main.c /dev/null >> rsabase.diff

4 4

Wrong keycodes ?
by George Ginden Feb. 23, 2005

Feb. 23, 2005

Hi do you guys know anything about that already ? It looks like some keys are not mapped correctly: grep -r VK_* * | grep include/winuser.h include/winuser.h:#define VK_LEFT 0x25 include/winuser.h:#define VK_UP 0x26 include/winuser.h:#define VK_RIGHT 0x27 include/winuser.h:#define VK_DOWN 0x28 These keys are the directional arrows, not the numpad keys... Now look at what wine thinks about those keys when block num is not kicked in: tail -f /projects/tmp/winetrace.log | grep keyboard trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 83 (0x53) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff96 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 80 (0x50) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff97 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 85 (0x55) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff98 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 88 (0x58) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff99 Kickin'in the block num: trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 100 (0x64) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff51 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 98 (0x62) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff52 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 102 (0x66) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff53 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 104 (0x68) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff54 What's wrong ? Oh, and this output is when using within a edit control. Last but not least, any test against VK_UP VK_DOWN, VK_LEFT, VK_RIGHT fails ... Regards.

2 4

Re: advapi32: Add RegCreate/DeleteKey tests and fixes
by Alexandre Julliard Feb. 23, 2005

Feb. 23, 2005

James Hawkins <truiken(a)gmail.com> writes: > + /* a key cannot be created directly beneath HKEY_LOCAL_MACHINE or HKEY_USERS */ > + if ((hkey == HKEY_LOCAL_MACHINE || hkey == HKEY_USERS) && !strchr(name, '\\')) { > + *retkey = NULL; > + return ERROR_INVALID_PARAMETER; > + } > + if (!(ret = RegOpenKeyExW( hkey, name, 0, KEY_ENUMERATE_SUB_KEYS, &tmp ))) > { > + /* check for any subkeys > + * a key cannot be deleted if it has any subkeys > + */ > + RegQueryInfoKeyW(tmp, NULL, NULL, NULL, &numSubKeys, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + if (numSubKeys != 0) { > + if (*name) RegCloseKey(tmp); > + return ERROR_ACCESS_DENIED; > + } These kinds of checks should be done in the lower level functions, not in advapi32 (and in the case of the delete, are done already AFAICT). -- Alexandre Julliard julliard(a)winehq.org

2 4

unixfs.dll: shell namespace extension for the unix filesystem
by Michael Jung Feb. 23, 2005

Feb. 23, 2005

Hi, this is a first rough cut version of a shell namespace extension to access the unix filesystem from wine. It's primary use-case is for winecfg's drive-mapping propery sheet. It already works for this purpose. It would be cool if 'the COM guys' could take a look at the code, since this is the first time I did something COM'ish. It would be nice if possible miss-conceptions could be found early on. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

RE: [ros-dev] RE: Collection of wine tools on windows
by Rolf Kalbermatter Feb. 23, 2005

Feb. 23, 2005

"Casper Hornstrup" <ch(a)csh-consult.dk> wrote: >Yes, but then you need to publish the sources for the non-free application under the LGPL. >When using headers to build your application, you create a derived work of those headers. > >http://www.fsf.org/licensing/licenses/lgpl.html > >"A "work based on the Library" means either the Library or any derivative work under copyright >law: that is to say, a work containing the Library or a portion of it, either verbatim or with >modifications and/or translated straightforwardly into another language. (Hereinafter, translation >is included without limitation in the term "modification".)" > >"4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in >object code or executable form under the terms of Sections 1 and 2 above provided that you accompany >it with the complete corresponding machine-readable source code, which must be distributed under >the terms of Sections 1 and 2 above on a medium customarily used for software interchange." This is rubish. LGPL is understood by most in such a way, that you can use a library in a closed source application as long as you do not make that library a static dependency in your app, meaning that the user could replace that LGPLed library with a newer, compatible version of his and your app still works. Shared libs (or DLLs) clearly are not a static dependency. You are obliged to provide to users of your closed source app and other interested parties the (possibly modified) sources of the LGPL library only, either directly on the media where you distribute your app with or under reasonable terms on request. A download link to Wine seems a very reasonable term to me as long as you didn't make modifications to it, or took care to at least provide a patch with those modifications to the project in question. With public headers for a library, it could be argued that they do not really provide any code (in most cases) and therefore are even less protectable in the interest of portability and interoperation compatibility. If it wouldn't be that way nobody could possibly write a closed source application to run under Linux as the kernel and it's headers are under the even more "restrictive" GPL license and every app has to link to the OS kernel (and use the appropriate headers) in some ways to be operable. Rolf Kalbermatter

2 1

Re: winmm/wineoss: use DSP_POST to flush the frag buffers
by Jeremy White Feb. 23, 2005

Feb. 23, 2005

Don't apply this; more survey of alternate sound cards shows that DSP_POST does not work as well as advertised everywhere. Jer Jeremy White wrote: > When we get down to the last fragment or two in our output > to the DSP, we should use the SND_DSP_POST ioctl to let the > sound card know to flush those fragments. This allows us to > precisely know when the buffer is empty, and fixes another > set of winmm tests. > > > ------------------------------------------------------------------------ > > Index: dlls/winmm/wineoss/audio.c > =================================================================== > RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v > retrieving revision 1.152 > diff -u -r1.152 audio.c > --- dlls/winmm/wineoss/audio.c 28 Jan 2005 17:21:07 -0000 1.152 > +++ dlls/winmm/wineoss/audio.c 22 Feb 2005 22:17:22 -0000 > @@ -1665,12 +1665,13 @@ > > /* input queue empty and output buffer with less than one fragment to play > * actually some cards do not play the fragment before the last if this one is partially feed > - * so we need to test for full the availability of 2 fragments > + * so we need to test for full the availability of 2 fragments ; the DSP_POST ioctl > + * will let the card know to play out the rest of the fragments > */ > if (!wwo->lpPlayPtr && wwo->dwBufferSize < availInQ + 2 * wwo->dwFragmentSize && > !wwo->bNeedPost) { > - TRACE("Run out of wavehdr:s...\n"); > - return INFINITE; > + TRACE("Run out of wavehdr's, requesting a POST...\n"); > + wwo->bNeedPost = TRUE; > } > > /* no more room... no need to try to feed */

1 0