February 2005 - Wine-devel - list.winehq.org

Fwd: Invitation to the mediation manual
by Duane Clark 24 Feb '05

24 Feb '05

Oops, I inadvertently deleted this from the queue, sorry. Robert Schuster wrote: Dear Wine developers, I wrote some guidelines that should help FOSS projects getting more lively and lowering the barrier for new developers to join. You can find them in form of a small manual here http://projects.mi.fu-berlin.de/w/bin/view/SE/ThesisFOSSIMMediationManual. These ideas are the result of work for my bachelor thesis and have been used successfully at the GNU Classpath project. If the topic is of interest to you, I would be happy to receive criticism and comments concerning the manual or the general idea. For further discussion I have set up a mailing-list (use http://lists.spline.inf.fu-berlin.de/mailman/listinfo/mediation_manual to subscribe or mediation_manual(a)lists.spline.inf.fu-berlin.de to post unsubscribed). Please send your feedback to this list but if you have reasons to contact me directly then just reply to this mail. In case you answer to your project's mailing list please CC me. Best regards Robert Schuster

1 0

Re: Poor performance when using Texas Instruments code generation tools in Wine
by Jan Tore Korneliussen 24 Feb '05

24 Feb '05

We found a simple solution (workaround?) to make this application perform well under WINE. Typical running time of the linking process is down from 30min to 15sec (!). A short explanation: The TI linker allocates and frees a lot of small buffers, typical size 24-32 bytes - but we have not seen allocation of buffers smaller than 24 bytes. Due to fragmentation of the heap in WINE, the number of free buffers smaller than 24 bytes gradually increases. Since the free buffers are organized in 4 lists based on their size, the small (<24 bytes) buffers will go in the first list (which in the current version holds buffers of size <= 32), and each new allocation will have to search past these small buffers. After a while this consumes all processor time, due to the large number of allocations done by the linker. A sufficient fix for this particular application is to introduce a new free list for buffers smaller than 24 bytes. In this way the small buffers will simply be skipped for each allocation, keeping allocation time relatively constant. Note that this is a custom fix for this application, but maybe introducing more free list for small buffers can help other applications which allocate a lot of small buffers. I guess one has to collect data from a lot of apps to make a good tradeoff here. Anyway it was a good thing for us that the heap is "tunable". The diff is with respect to Wine-20050211.tar.gz dlls/ntdll/heap.c -- Jan Tore Korneliussen R&D Engineer TANDBERG Phone +47 6783 8514 mail jan.tore.korneliussen(a)tandberg.net 85c85 < #define HEAP_NB_FREE_LISTS 5 /* Number of free lists */ --- > #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ 90c90 < 0x10, 0x20, 0x80, 0x200, ~0UL --- > 0x20, 0x80, 0x200, ~0UL

1 0

Re: SHELL32: fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes
by Alexandre Julliard 24 Feb '05

24 Feb '05

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes This is causing some test failures (and also some extra successes, I guess we are on the right track...) shelllink.c:177: Test succeeded inside todo block: path_to_pidl returned a NULL pidl shelllink.c:197: Test failed: GetPath returned 'C:\nonexistent\file' shelllink.c:234: Test succeeded inside todo block: GetIconLocation failed (0x00000000) shelllink.c:236: Test failed: GetIconLocation returned 'c:\windows\system\shell32.dll' shelllink.c:238: Test succeeded inside todo block: GetIconLocation returned 0 -- Alexandre Julliard julliard(a)winehq.org

1 0

Fix recently introduced SEGV in DOCFILE IStorage implementation
by Troy Rollo 24 Feb '05

24 Feb '05

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 23 Feb '05

23 Feb '05

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 23 Feb '05

23 Feb '05

----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 23 Feb '05

23 Feb '05

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 23 Feb '05

23 Feb '05

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 23 Feb '05

23 Feb '05

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 23 Feb '05

23 Feb '05

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