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

Re: comctl32: Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg
by Rein Klazes 12 May '05

12 May '05

On Thu, 12 May 2005 02:59:38 -0500, you wrote: > Hey, > > This is a patch for the WM_LBUTTONUP msg problem, but I've taken the > advice of Dmitry and now all messages are dispatched. > > Changelog > * Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg. Patches like this have been proposed before. They are wrong: Windows *does* eat the WM_LBUTTONUP in the mouse track message loop. There are cases when in Wine this mouse tracking is entered, where they are not under Windows thus causing loss of messages. http://www.winehq.org/hypermail/wine-devel/2004/05/0159.html http://www.winehq.org/hypermail/wine-devel/2004/09/0072.html Rein.

1 0

Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg
by Dmitry Timoshkov 12 May '05

12 May '05

"James Hawkins" <truiken(a)gmail.com> wrote: > You were right about having the NM_CLICK msg sent in > LISTVIEW_LButtonUp, and the problem was that a WM_LBUTTONUP msg was > never sent. This fixes the problem where you had to double click an > item in the drives list to select it. > > Changelog > * Make sure a WM_LBUTTONUP msg is dispatched after tracking a WM_LBUTTONDOWN msg > --- dlls/comctl32/listview.c 6 May 2005 15:44:32 -0000 1.409 > +++ dlls/comctl32/listview.c 12 May 2005 05:04:06 -0000 > @@ -7948,6 +7948,9 @@ static LRESULT LISTVIEW_TrackMouse(LISTV > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + if (msg.message == WM_LBUTTONUP) > + DispatchMessageW(&msg); Why WM_LBUTTONUP should be different from other kinds of messages? I.e. why all messages could not be passed to DispatchMessage? What if just move DispatchMessageW call right right after PeekMessageW? -- Dmitry.

2 1

Getting rid of LOCAL_ exports
by Dimi Paun 12 May '05

12 May '05

>From a cursory look at the problem, it seems we can turn things upside down. Right now LOCAL_*() functions (Wine specific) are equivalent to the Local*16() functions (Windows exports), with the exception that they take a selector as first argument (which makes them more general). As a result, Local*16() functions are implemented on top of the LOCAL_*() ones. This is only half of the story. In fact, the Local*16() functions do take the segment as input, but in a more awkward manner: as the value of the DS register. So we can actually implement the LOCAL_*() functions on top of the Local*16() ones by messing with the DS register. Doing so would hopefully get rid of the LOCAL_*() exports from kernel. I've taken a stab (prototype level) at the LOCAL_Alloc() function (patch included below). Would such an approach be acceptable? Index: include/local.h =================================================================== RCS file: /var/cvs/wine/include/local.h,v retrieving revision 1.6 diff -u -p -r1.6 local.h --- include/local.h 28 Aug 2003 21:43:35 -0000 1.6 +++ include/local.h 10 May 2005 18:20:03 -0000 @@ -23,12 +23,22 @@ #include <windef.h> #include <wine/windef16.h> +#include <stackframe.h> /* These function are equivalent to the Local* API functions, */ /* excepted that they need DS as the first parameter. This */ /* allows managing several heaps from the emulation library. */ +static inline HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ) +{ + HANDLE16 oldDS = CURRENT_DS; + HLOCAL16 ret; + + CURRENT_DS = ds; + ret = LocalAlloc16 (flags, size); + CURRENT_DS = oldDS; + return ret; +} -extern HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ); extern HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, UINT16 flags ); extern HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL16 handle ); Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /var/cvs/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.148 diff -u -p -r1.148 kernel32.spec --- dlls/kernel/kernel32.spec 10 May 2005 15:22:10 -0000 1.148 +++ dlls/kernel/kernel32.spec 10 May 2005 18:22:10 -0000 @@ -1167,7 +1167,6 @@ # Wine dll separation hacks, these will go away, don't use them # @ cdecl DOSMEM_AllocSelector(long) -@ cdecl LOCAL_Alloc(long long long) @ cdecl LOCAL_Compact(long long long) @ cdecl LOCAL_CountFree(long) @ cdecl LOCAL_Free(long long) Index: dlls/kernel/local16.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/local16.c,v retrieving revision 1.10 diff -u -p -r1.10 local16.c --- dlls/kernel/local16.c 24 Mar 2005 21:01:38 -0000 1.10 +++ dlls/kernel/local16.c 10 May 2005 17:56:15 -0000 @@ -1150,15 +1150,13 @@ HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL /*********************************************************************** - * LOCAL_Alloc - * - * Implementation of LocalAlloc(). - * + * LocalAlloc (KERNEL.5) */ -HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD flags, WORD size ) +HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) { + HANDLE16 ds = CURRENT_DS; + HLOCAL16 handle = 0; char *ptr; - HLOCAL16 handle; TRACE("%04x %d ds=%04x\n", flags, size, ds ); @@ -1171,7 +1169,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD if(size) { if (!(hmem = LOCAL_GetBlock( ds, size + MOVEABLE_PREFIX, flags ))) - return 0; + goto exit; } else /* We just need to allocate a discarded handle */ hmem = 0; @@ -1180,7 +1178,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD WARN("Couldn't get handle.\n"); if(hmem) LOCAL_FreeArena( ds, ARENA_HEADER(hmem) ); - return 0; + goto exit; } ptr = MapSL( MAKESEGPTR( ds, 0 ) ); plhe = (LOCALHANDLEENTRY *)(ptr + handle); @@ -1199,10 +1197,11 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD } else /* FIXED */ { - if(!size) - return 0; - handle = LOCAL_GetBlock( ds, size, flags ); + if(size) handle = LOCAL_GetBlock( ds, size, flags ); } + +exit: + CURRENT_STACK16->ecx = handle; /* must be returned in cx too */ return handle; } @@ -1595,17 +1594,6 @@ HLOCAL16 LOCAL_Handle( HANDLE16 ds, WORD /*********************************************************************** - * LocalAlloc (KERNEL.5) - */ -HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) -{ - HLOCAL16 ret = LOCAL_Alloc( CURRENT_DS, flags, size ); - CURRENT_STACK16->ecx = ret; /* must be returned in cx too */ - return ret; -} - - -/*********************************************************************** * LocalReAlloc (KERNEL.6) */ HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Installing Adobes Acrobat Reader 7.0 (Windows XP Version I think)
by Peter 12 May '05

12 May '05

Hello, I try to install the Adobes Acrobatreader 7.0. Now this didn't work it gave me a quite odd message that an unexpected error occured with a long number. I tried to run wine with the debug Variable +all. I never done this before so can anybody help me? Is the ntdll missing something or is it an bug? thx in advance Peter winedebug geave me at the same point this: 0009:Ret PE DLL (proc=0x7f510000,module=0x7f500000 L"imm32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Call kernel32.__wine_unregister_dll_16(76e39680) ret=76de7872 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000007 ret=76de7872 0009:Call kernel32.__wine_unregister_dll_16(76e39698) ret=76deaa02 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000008 ret=76deaa02 0009:Call kernel32.__wine_unregister_dll_16(76e396b0) ret=76deace2 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000009 ret=76deace2 0009:Ret PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Ret PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Call ntdll.RtlEnterCriticalSection(77bde5c0) ret=77b4e3e5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b4e3e5 0009:Call ntdll.RtlLeaveCriticalSection(77bde5c0) ret=77b4e3f5 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b4e3f5 0009:Ret PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Ret PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Ret ntdll.LdrShutdownProcess() retval=00000000 ret=77b484a2 0009: terminate_process( handle=0xffffffff, exit_code=1150 ) 0009: terminate_process() = 0 { self=1 } 0009: *killed* exit_code=1150

2 1

Re: msvcrt: implement signals, take 2
by Alexandre Julliard 12 May '05

12 May '05

Juan Lang <juan_lang(a)yahoo.com> writes: > + switch (sig) > + { > + /* Cases that fall through to signal(2) */ > + case SIGABRT: > + case SIGFPE: > + case SIGILL: > + case SIGSEGV: > + ret = signal(sig, func); > + break; You can't do that, this will cause major trouble. MSVCRT signals should be generated from Win32 exceptions. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: tools/widl
by Ge van Geldorp 12 May '05

12 May '05

I'm wondering what happened to the reworked widl patch at http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't been applied yet, does that mean there's no interest on the Wine side and I can drop it from my TODO list? Best regards, Ge van Geldorp.

2 1

Re: user32.dll fix and test ShowOwnedPopups
by Dmitry Timoshkov 12 May '05

12 May '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > ShowOwnedPopups should handle none WS_POPUP style windows as well. > And actually show/hide windows. > Match names for WM_SHOWWINDOW status codes to MSDN > @@ -2701,6 +2701,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_SHOW, SW_PARENTOPENING); > + ShowWindow(win_array[count], SW_SHOW); > continue; > } > } > @@ -2715,6 +2716,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_HIDE, SW_PARENTCLOSING); > + ShowWindow(win_array[count], SW_HIDE); Then each owned window will receive 2 WM_SHOWWINDOW messages. Are you sure that Windows does it that way? I'd advise to write a message test to verify it. -- Dmitry.

2 2

[Bug 2932] - copy / paste to openoffice
by Dustin Navea 12 May '05

12 May '05

Basically, before 01/11/05, copying and pasting to OO worked, and after said date, it doesn't. The Bug is at: http://bugs.winehq.org/show_bug.cgi?id=2932 The patch causing it is at: http://www.winehq.org/hypermail/wine-cvs/2005/01/0276.html It looks like the patch removed W->A calls from the clipboard code. All other relevant information is posted in the bug Dustin

2 1

Borland software patent restricting Wine development
by Ingrid Marson 12 May '05

12 May '05

I'm writing an article today following Dimitri O. Paun's talk at the Wine Developer conference in Stuttgart. He said that Winelib development is restricted due to a Borland software patent. Borland's software patent means that an important feature to the Gnu Compiler Collection project cannot be applied. Winelib support would depend on that patch. The FFII has written an article on this: http://wiki.ffii.org/WineConf050501En I am keen to find out more about this issue. Does anyone know about this issue, or know how I can contact Dimitri? (I have tried to find his email address using Google but haven't had any success). Thanks for your help. Regards, Ingrid Ingrid Marson Reporter ZDNet UK www.zdnet.co.uk T: +44 (0)20 7903 6835

3 2

Wine test question: How to test for messages send?
by Tobias Burnus 12 May '05

12 May '05

Hello, I'm trying to write a conformance test for user/edit.c: EDIT_EM_ReplaceSel(). While I figured out how to send messages, call functions etc. I don't know how to check whether a message has been sent. But I need to know whether Windows sends one as a EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT") causes my Origin to crash. Background: Origin crashes since a patch was introduced in Wine which sends this message. Origin (at least under Wine) seems to create a 7px wide edit control which is then trys to fill with "10" (being 20px wide). Since not even "1" fits in there, the content of the edit control is "" and a EN_MAXTEXT is sent. While removing the EDIT_NOTIFY_PARENT line helps, this is surely not the right solution; Lauri Tulmin (author of mentioned patch) suggested to test for it: "From what I understand, the program crashes when it receives EN_MAXTEXT notification. You should figure out why the textbox is too small to contain the text. Or maybe this notification shouldn't be sent at all, although MSDN says it should be, but maybe there are some exceptions. Probably you'll need to write some test's to figure out what exactly goes wrong." For details, see bug 2813. http://bugs.winehq.org/show_bug.cgi?id=2813 Tobias

2 1