wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

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

23 Feb '05

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

23 Feb '05

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

23 Feb '05

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

ole/storage: Problems with 'Myst Uru Demo'
by Paul Vriens 23 Feb '05

23 Feb '05

Hi, eventhough Michael withdrew his patch (http://www.winehq.org/hypermail/wine-devel/2005/02/0687.html) I've tried it, and it crashes in the ole/storage area. I've added some TRACE's and this is the output: 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage (0x77ece0f8, L"ID_9", (nil), 1012, (nil), 0, 0x28de68) 000b:trace:storage:StorageBaseImpl_OpenStorage Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:IEnumSTATSTGImpl_Construct 0xa2f7c0 / 10680096 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IStorage_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IEnumSTATSTGImpl_Reset 000b:trace:storage:IEnumSTATSTGImpl_Destroy Calling IStorage_Release(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageInternalImpl_Construct 000b:trace:storage:StorageInternalImpl_Construct Calling StorageBaseImpl_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageBaseImpl_AddRef(0x77e96a80) 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012793 000b:trace:storage:StorageBaseImpl_OpenStorage <-- 00000000 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012794 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28dd14) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:StorageBaseImpl_Release (0x77e96a80/0x77e96a80) decremented refcount to 2012012793 000b:trace:ole:GetErrorInfo (0, 0x28e12c, (nil)) 000b:fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e95528): not verifying image 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28df4c) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct wine: Unhandled exception (thread 000b), starting debugger... the refcount with values of 2012012793 look a bit suspicious. Any ideas where to look? Cheers, Paul.

1 1

A call to fix the BeginPaint issue
by Nick Hornback 23 Feb '05

23 Feb '05

Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well. http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations: DeusEx Trickstyle Foobar2000 Zoo Tycoon 1 demo This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do. --Nick __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

6 8

Re: rsabase: Make rsabase a wrapper around rsaenh
by Alexandre Julliard 23 Feb '05

23 Feb '05

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > As suggested by Alexandre, I removed all implementation code from rsabase and > made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's > unicows.dll to do so. You don't need that, you can forward directly in the spec file. Unicows has to do it differently because of the way it's loaded, but other dlls can use normal forwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Poor performance when using Texas Instruments code generation tools in Wine
by Dan Kegel 23 Feb '05

23 Feb '05

Anders wrote: > We have been using TI code generation tools (compiler and linker) on > Wine, and it has worked well. However, when we started evaluating newer > versions of the codegen tools, the linking time was dramatically > increased (from 20 sec to 30 minutes...). > > We have done some profiling using oprofile, and found that most of this > time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll > module. The time needed to locate a free heap block increases gradually, > from a few iterations up to about 15000 in the project we are building. Wow, that's worth looking into! Can you write a small C program that has the same behavior? That would help us reproduce the problem and then solve it. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

richedit (ro): "Select all" or "Copy" crashes wine
by Tobias Burnus 23 Feb '05

23 Feb '05

Hi, in Diamond 2.x (http://www.codeweavers.com/compatibility/browse/name?app_id=865) there is a structure-data richedit (read-only). (Under Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_info.png; it's on the right side; Wine looks similar, but the background is grey and it is not that sleek.) I can flawlessly select some text using the mouse or the keyboard, but if I use the context menu and choose either of - "Select all" - "Copy" (after selecting something) it crashes with: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x451e158b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:451e158b ESP:406dfb98 EBP:406dfbb4 EFLAGS:00210246( - 00 -RIZP1) EAX:40425b70 EBX:451eecec ECX:40b77600 EDX:451f2c50 ESI:00000000 EDI:40425b70 Stack dump: 0x406dfb98: 4058a80e 4058a80e 451eecec 00000000 0x406dfba8: 451eecec 404240d8 00000111 406dfbe8 0x406dfbb8: 451e3ba8 40425b70 00000000 00000000 0x406dfbc8: 00000111 00000000 00000301 00000301 0x406dfbd8: 44b68a14 40b6a450 00000000 00020048 0x406dfbe8: 406dfc0c 40ae88f7 00020048 00000111 Backtrace: =>1 0x451e158b RTFSetEditStream in riched32 (0x406dfbb4) 2 0x451e3ba8 RICHED32_WindowProc in riched32 (0x406dfbe8) 3 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfc0c) 4 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfc50) 5 0x40aef2c5 CallWindowProcA in user32 (0x406dfc94) 6 0x00563a90fixme:dbghelp_msc:pe_load_debug_directory This guy has FPO information in diamond (+0x163a90) (0x406dfcb4) 7 0x005641c2 in diamond (+0x1641c2) (0x406dfcd4) 8 0x00562ed9 in diamond (+0x162ed9) (0x406dfd40) 9 0x005631e5 in diamond (+0x1631e5) (0x406dfd5c) 10 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfd80) 11 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfdc4) 12 0x40aef2c5 CallWindowProcA in user32 (0x406dfe08) 13 0x40ad26f2 DispatchMessageA in user32 (0x406dfe34) 14 0x00567cb7 in diamond (+0x167cb7) (0x005f3d50) 15 0x00000001 (0x005ab278) 16 0x00464520 in diamond (+0x64520) (0x00589f71) 0x451e158b RTFSetEditStream+0x2b in riched32: movl 0x0(%esi),%eax A WINEDEBUG=+relay,+seh,+tid gives the following (excerpt): (This is with Meissner's wine-20050211-1.1 and CXOffice-nightly 05-02-21 and occurs also with earlier versions of WINE. The excerpt below comes from wine-20050211-1.1 with "Select all".) [...] 0009:Call window proc 0x5631b9 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call user32.CallWindowProcA(451e38b0,00020048,00000111,000000b1,00000000) ret=00563a90 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32.GlobalGetAtomNameW(0000c043,406df99c,0000003c) ret=40aba1ba 0009:Ret kernel32.GlobalGetAtomNameW() retval=00000008 ret=40aba1ba 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call window proc 0x451e38b0 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call user32.GetWindowLongW(00020048,00000004) ret=451e38e2 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Ret user32.GetWindowLongW() retval=404240c0 ret=451e38e2 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x451e158b 0009:trace:seh:EXC_RtlRaiseException info[0]=00000000 0009:trace:seh:EXC_RtlRaiseException info[1]=00000000 0009:trace:seh:EXC_RtlRaiseException eax=40425b30 ebx=451eecec ecx=00000000 edx=451f2c50 esi=00000000 edi=40425b30 0009:trace:seh:EXC_RtlRaiseException ebp=406df9ec esp=406df9d0 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210246 0009:trace:seh:EXC_CallHandler calling handler at 0x562f3e code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x54c1e0 code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:Call kernel32.UnhandledExceptionFilter(406df57c) ret=0054e15a 0009:Call kernel32.IsBadCodePtr(41036a10) ret=005503a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=005503a1 0009:Call kernel32.IsBadCodePtr(1000a670) ret=410386a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=410386a1 0009:Call ntdll.NtCreateEvent(406df240,001f0003,406df408,00000001,00000000) ret=404c574f 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=404c574f wine: Unhandled exception (thread 0009), starting debugger... 0009:Call ntdll.RtlInitUnicodeString(406df238,40568a80 L"Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug") ret=404c 57e0 [...] Tobias

1 0

Checking Wine's spec files
by Francois Gouget 23 Feb '05

23 Feb '05

The recent problems with -noname in shell32.spec got be to dig up an old script I had which reads spec and dumpbin files and processes them. I then retrofitted it so it could do some hopefully useful checks for this kind of issues. So this script works by comparing the output of winedump or dumpbin on the Windows dlls for as many platforms as are available (I have 7 so far) with the contents of Wine's spec files. It then applies a number of rules to try to detect problems. However the information we can extract from the Windows dlls is incomplete so this script uses heuristics. This means the problems it reports should be treated with a grain of salt. Running the check script To download and run the check script, see the instructions are on my web site: http://fgouget.free.fr/wine/checkspec-en.shtml Then you can run it as follows: ./check_spec --verbose ~/wine/dlls/shell32.spec And here is a description of the checks it performs so far, illustrated with the output for shell32.dll. Comments and suggestions for more checks or improvements are welcome. I'll wait a bit (and then start sending some patches unless someone else wants to tackle this (could be a nice janitorial project). Notes: * It would be nice if winedump could dump the Platform SDK's .lib files. These files must have an explicit mention of which entry points have the -noname property so this would give us a more reliable source of information than the heuristics in this script. * dumpbin will something special when an API is being forwarded: 40 [NONAME] (forwarded to shlwapi.PathIsRelativeW) But winedump prints nothing special. It would be nice to add this functionality to winedump. -noname vs. ordinal internal consistency ----------------------------------------- This check verifies that all APIs which have the '-noname' property, also have an explicit ordinal. This is the only check which does not depend on dumps of the Windows dlls. No problem found here. APIs which should not have an explicit ordinal ---------------------------------------------- The script scans the Wine spec file for APIs which have both a name and an explicit ordinal. For each of these, the script looks up the API by name on the Windows platforms and collates a list of the corresponding ordinals. If it finds more than one ordinal then it considers the API should not be given an explicit ordinal. In that case it reports how many times the API was found with the right ordinal on Windows, and how many different values were found. If the former is 0 or 1 then it's clear the API should not be given an explicit ordinal. If the latter is 2 then things are maybe not so clear. These 64 APIs should not have an ordinal: SHGetDataFromIDListA (correct 0 times, found 5 values) StrChrIW (correct 0 times, found 3 values) SheGetCurDrive (correct 0 times, found 5 values) ShellAboutW (correct 0 times, found 5 values) SheFullPathA (correct 0 times, found 5 values) DllGetClassObject (correct 0 times, found 5 values) SheGetDirA (correct 0 times, found 5 values) SheGetPathOffsetW (correct 0 times, found 5 values) SheGetDirW (correct 0 times, found 5 values) DragFinish (correct 0 times, found 5 values) StrCmpNW (correct 0 times, found 3 values) StrNCmpA (correct 0 times, found 3 values) StrCmpNIA (correct 0 times, found 3 values) ShellExecuteW (correct 0 times, found 5 values) SheChangeDirW (correct 0 times, found 5 values) Shell_NotifyIconW (correct 0 times, found 5 values) StrCpyNA (correct 0 times, found 3 values) SheRemoveQuotesW (correct 0 times, found 5 values) StrCmpNA (correct 0 times, found 3 values) ShellExecuteExA (correct 0 times, found 5 values) StrRStrIA (correct 0 times, found 3 values) StrStrA (correct 0 times, found 3 values) StrStrW (correct 0 times, found 3 values) StrChrA (correct 0 times, found 3 values) SheShortenPathA (correct 0 times, found 5 values) StrNCmpIW (correct 0 times, found 3 values) StrRChrIA (correct 0 times, found 3 values) StrChrIA (correct 0 times, found 3 values) SheConvertPathW (correct 0 times, found 5 values) StrNCpyW (correct 0 times, found 3 values) DragAcceptFiles (correct 0 times, found 5 values) StrRStrIW (correct 0 times, found 3 values) StrNCmpIA (correct 0 times, found 3 values) Shell_NotifyIconA (correct 0 times, found 5 values) ShellExecuteA (correct 0 times, found 5 values) ShellExecuteEx (correct 0 times, found 5 values) SheChangeDirA (correct 0 times, found 5 values) StrStrIA (correct 0 times, found 3 values) SheChangeDirExA (correct 0 times, found 5 values) ShellAboutA (correct 0 times, found 5 values) SheChangeDirExW (correct 0 times, found 5 values) ShellExecuteExW (correct 0 times, found 5 values) StrNCmpW (correct 0 times, found 3 values) StrChrW (correct 0 times, found 3 values) DragQueryFile (correct 0 times, found 5 values) StrRStrW (correct 0 times, found 3 values) StrCpyNW (correct 0 times, found 3 values) DragQueryFileA (correct 0 times, found 5 values) StrNCpyA (correct 0 times, found 3 values) DragQueryFileW (correct 0 times, found 5 values) Shell_NotifyIcon (correct 0 times, found 5 values) StrStrIW (correct 0 times, found 3 values) SHGetDataFromIDListW (correct 0 times, found 5 values) SheGetDirExW (correct 0 times, found 5 values) SheFullPathW (correct 0 times, found 5 values) SheRemoveQuotesA (correct 0 times, found 5 values) SheShortenPathW (correct 0 times, found 5 values) StrRStrA (correct 0 times, found 3 values) StrCmpNIW (correct 0 times, found 3 values) StrRChrW (correct 0 times, found 3 values) SheSetCurDrive (correct 0 times, found 5 values) StrRChrIW (correct 0 times, found 3 values) DragQueryPoint (correct 0 times, found 5 values) StrRChrA (correct 0 times, found 3 values) APIs which have the wrong ordinal --------------------------------- This check collates a list of Windows ordinals for the API exactly as above. But it emits a warning about the API only if it found a single ordinal value on Windows and that ordinal does not match Wine's ordinal. These 1 APIs have the wrong ordinal: ReadCabinetState (is 654 on api2003es) (may be best to ignore this one) APIs which should have the -noname property -------------------------------------------- Again this check concerns APIs which have both an explicit ordinal and a name. This time it counts the number of Windows platforms where the API is not exported by name but which still have an entry point with the right ordinal and no name. If more than one such platforms were found, the script considers the API should have the '-noname' property. These 28 APIs should have the -noname property: SHRegOpenKeyW (507 has no name on api95 api98 apint4) SHGetNetResource (69 has no name on all) DAD_SetDragImageFromListView (177 has no name on all) ReceiveAddToRecentDocs (647 has no name on api95 api98 apime apint4 api2000) SHRegQueryValueExW (511 has no name on api95 api98 apint4) PifMgr_GetProperties (10 has no name on api95 api98 apime apint4 api2000 apixp) SHChangeRegistrationReceive (646 has no name on all) RestartDialogEx (730 has no name on apixp) SHRegQueryValueA (508 has no name on api95 api98 apint4) SHWaitOp_Operate (648 has no name on all) SHNetConnectionDialog (160 has no name on all) InvalidateDriveType (65 has no name on all) SHRegCloseKey (505 has no name on api95 api98 apint4) SHHandleDiskFull (185 has no name on all) SHFindComputer (91 has no name on all) SHRegQueryValueW (510 has no name on api95 api98 apint4) SHGlobalDefect (197 has no name on all) PifMgr_OpenProperties (9 has no name on api95 api98 apime apint4 api2000 apixp) SHRegQueryValueExA (509 has no name on api95 api98 apint4) PifMgr_SetProperties (11 has no name on api95 api98 apime apint4 api2000 apixp) SHCreatePropSheetExtArrayEx (194 has no name on all) RealDriveTypeFlags (525 has no name on all) SHChangeNotifyReceive (643 has no name on all) SHRegOpenKeyA (506 has no name on api95 api98 apint4) SHIsBadInterfacePtr (84 has no name on all) SHRegDeleteKeyW (512 has no name on apint4) PifMgr_CloseProperties (13 has no name on api95 api98 apime apint4 api2000 apixp) DragQueryInfo (76 has no name on all) APIs which should not have the -noname property ------------------------------------------------ This the same check as above but with a different analysis of the results. Namely, the script considers the API should not have the -noname property if one of the following two conditions is met: * the API is exported by name on all platforms * the API's ordinal corresponds to another API on one of the platforms. These 33 APIs should not have the -noname property: FileMenu_AppendItem (115 has other names on apixp api2003es) FileMenu_Create (114 has other names on apixp api2003es) DragFinish FileMenu_DeleteItemByFirstID (141 has other names on apixp api2003es) FileMenu_DrawItem (105 has other names on apixp api2003es) FileMenu_DeleteAllItems (104 has other names on apixp api2003es) FileMenu_DeleteItemByCmd (117 has other names on apixp api2003es) FileMenu_DeleteItemByIndex (140 has other names on apixp api2003es) FileMenu_DeleteSeparator (142 has other names on apixp api2003es) FileMenu_ReplaceUsingPidl (113 has other names on apixp api2003es) FileMenu_MeasureItem (112 has other names on apixp api2003es) ILAppend (154 has other names on api2003es) FileMenu_AppendFilesForPidl (124 has other names on apixp api2003es) DragAcceptFiles FileMenu_InitMenuPopup (109 has other names on apixp api2003es) FileMenu_AbortInitMenu (120 has other names on apixp api2003es) FileMenu_GetLastSelectedItemPidls (107 has other names on apixp api2003es) FileMenu_EnableItemByCmd (143 has other names on apixp api2003es) FileMenu_HandleMenuChar (108 has other names on apixp api2003es) Shell_GetImageList (71 has other names on api2003es) FileMenu_GetItemExtent (144 has other names on apixp api2003es) FileMenu_TrackPopupMenuEx (116 has other names on apixp api2003es) DragQueryFile FileMenu_FindSubMenuByPidl (106 has other names on apixp api2003es) FileMenu_Invalidate (111 has other names on apixp api2003es) DragQueryFileA DragQueryFileW FileMenu_AddFilesForPidl (125 has other names on api95 api98 apime apint4 api2000 apixp api2003es) FileMenu_Destroy (118 has other names on apixp api2003es) ShellDDEInit (188 has other names on api95 api98 apint4) DragQueryPoint FileMenu_InsertUsingPidl (110 has other names on apixp api2003es) IsUserAdmin (680 has other names on api2003es) Missing APIs ------------ The script only reports an API as missing if it is present on all platforms but missing from Wine's spec file. That's per Wine's policy to not add APIs that are only present on newer platforms unless we have a good reason to. These 2 APIs are missing: SHInvokePrinterCommandW SHInvokePrinterCommandA -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

2 5

Re: Should winecfg drive detection create device symlinks
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 08:40, Paul van Schayck wrote: > <mjung(a)iss.tu-darmstadt.de> wrote: > > I think winecfg does this already. Take a look at the function > > apply_drive_functions in drive.c. Does'nt it work for you? > > As far as I can tell it does not. We do not store the device node path > in the detect functions so I see no way we make symlinks from > dosdevices/ to device nodes. Sorry, I misunderstood you. > Yeah, the auto detect works here just fine (symlinks are created). > Just one problem I haven't come up with a sollution yet. My floppy has > as fs type in fstab 'auto'. This means my floppy comes up as a fixed > harddrive. I have the same problem for my cdrom. As a heuristic, how about the following: If fs type is auto and the referenced device node is /dev/fd*, we assume it's a floppy. If fs type is auto and the referenced device node is not /dev/fd*, we assume it's a cdrom. Are floppies always mapped to /dev/fd* or are there other valid device nodes? How about BSD/Solaris? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: advapi32: Don't free csp dll when a container is deleted
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 00:04, Michael Jung wrote: > Changelog: > Don't unload Cryptographic Service Provider DLL when a key container is > deleted. There might still be open handles. Don't apply this patch, please. It fixes the crash in the "Uru Demo" installer only by coincidence. We really have to implement a reference counting scheme to solve this problem properly. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: msi: detect registry keypaths
by Alexandre Julliard 23 Feb '05

23 Feb '05

Aric Stewart <aric(a)codeweavers.com> writes: > - FIXME("Only working for installed files, not registry keys\n"); > - if ( GetFileAttributesW(path) != INVALID_FILE_ATTRIBUTES ) > - rrc = INSTALLSTATE_LOCAL; > + if (path[0]=='0') > + { > + FIXME("Registry entry.. check entry\n"); > + if (path[0]) > + rrc = INSTALLSTATE_LOCAL; > + else > + rrc = INSTALLSTATE_ABSENT; > + } Since path[0] is first checked against '0' this test doesn't seem to make much sense. What are you trying to do here? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: status of wine dll's
by Juan Lang 22 Feb '05

22 Feb '05

Alexandre wrote: > I'm not convinced we want to remove it completely, there just might be > an app somewhere that looks for it explicitly, and it doesn't cost > anything to keep it. If so, that app won't work on windows; most versions of windows only ship with rsaenh.dll. The only ones that have rsabase are really old versions, and those that are sold in the crypto-export-restricted countries. I think removal makes more sense, keeping rsabase costs a little confusion. --Juan __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

Re: dlls/gdi: fix GetGlyphOutline(resend)
by Huw Davies 22 Feb '05

22 Feb '05

On Tue, Feb 22, 2005 at 11:31:30PM +0900, TANABE Hiroshi wrote: > @@ -2903,7 +2901,8 @@ > TM.tmStruckOut = font->strikeout; > > /* Yes TPMF_FIXED_PITCH is correct; braindead api */ > - if(!FT_IS_FIXED_WIDTH(ft_face)) > + if(!FT_IS_FIXED_WIDTH(ft_face) && > + (pOS2->version == 0xFFFFU || pOS2->panose[3]!=9)) > TM.tmPitchAndFamily = TMPF_FIXED_PITCH; > else > TM.tmPitchAndFamily = 0; Isn't this a bug in FreeType? If we have to have this in Wine, could you use the defines in wingdi.h instead of the '3' and the '9'? Huw. -- Huw Davies huw(a)codeweavers.com

1 0

regression
by Oliver Stieber 22 Feb '05

22 Feb '05

Hi, I've had a regression with Creatures 2 between and 2005-02-03 and 2005-02-19.. Creatures 2 makes heavy use of out-of-process COM for it's components, the main screen used to work ok (but the components didn't). Now it starts up and I get the error. "err:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported" I'll try to find out what patch caused the regression. 1 0x405168ec RaiseException 2 0x5f45394berr:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported ?? in mfc42 (0x406ffcd8) 3 0x5f40d992 ?? in mfc42 (0x0047ceb8) ...stack missing. other threads are waiting for ConnectNamedPipe,sync.c:1311 RPCRT4_Receive,rpc_message.c:312 RPCRT4_process_packet,rpc_server.c:316 ... RPCRT4_server_thread, rpc_server.c:506 User_update_thread, dsurface/user.c:515 RPCRT4_worker_thread, rpc_server.c:353 ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 4

Poor performance when using Texas Instruments code generation tools in Wine
by Anders Rønningen 22 Feb '05

22 Feb '05

Hi ! We have some performance problems with Wine that we could use some help on.. Here's the story: We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...). We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms. We do not have the same problem when building the code under Windows, so we tried to use the native ntdll.dll from Windows instead of ntdll.dll.so, hoping that this would solve the performance issue. We are aware that this is not recommended, but wanted to give it a try anyway. We added the dll file to the global dll-override section in the config file under ~/.wine/config, but it seems like Wine just looks for the builtin dll. We see from strace that we access the correct config file at startup. Is override of ntdll not supported, or have we missed something? If it is supported, is it likely that it is going to work? We have read some posts in the newsgroup about the heap issues. It seems that people agree that the heap should be improved, either by tweaking the existing code, or by using another heap implementation. Is any work planned on this? -- Regards / Mvh - Anders Rønningen Engineer R&D TANDBERG Phone: +47 67 125 125 Direct: +47 67 838 584 Mobile: +47 97 791 217 Fax: +47 67 125 234 mailto:anders.ronningen@tandberg.net http://www.tandberg.net

6 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel