- Wine-Devel - list.winehq.org

Re: info please
by Dustin Navea May 12, 2005

May 12, 2005

juan melgarejo wrote: > Is there any document or how-to showing: > how to run a backtrace using the wine debugger > how set debug parameters for wine tracing of program execution > how to submit bugs to bugzilla (how to report, content) > How to Know proper settings for bugs > (when a bug should be a blocker, which bug depends on which other bug, > etc) ? > > Regards, > Juan > The Wine FAQ at http://winehq.org/site/docs/wine-faq/index The Wine User Guide at http://winehq.org/site/docs/wine-user/index The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index How to help get applications working in Wine at http://winehq.org/site/helping-applications Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet Those are the best resources. You can also check the wine wiki (although I don't have the address).. Dustin

1 0

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink May 12, 2005

May 12, 2005

Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 under Wine isn't worth the trouble. Acrobat Professional is a different matter. The latest Acrobat Professional that will work on Wine is 5. Both 6 and 7 require dlls that must be supplied from Windows. Seven has copy protect features that actually discourage use on any machine. With some trouble you can probably get 6 to work. It will currently install and with the addition of the missing dlls almost work. If someone wants to patch Wine so that 6 runs it would probably see considerable use.

1 0

Now Recruiting
by Dustin Navea May 12, 2005

May 12, 2005

Please do not reply to this email with this same subject line unless you are notifying myself that you would like to have an interview. If you need to discuss this more with me, use a subject of "Discuss - Now Recruiting" Attention all users of wine! Have you ever run into a situation where "it worked before, but now it doesnt"? Have you ever wanted to help out the wine project, but either don't know how to program, or don't know how to get started? Have you reported bugs on bugs.winehq.com and gotten frustrated because of the response time? You are not alone! The Wine Project is proud to announce that we are now recruiting for Maintainer/Janitor positions on the Bugzilla Database! Bugzilla Maintainers should: Have a good working knowledge of Linux Know how to run a backtrace using the wine debugger Know how set debug parameters for wine tracing of program execution Know how to submit bugs to bugzilla Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) Have strong interpersonal communication skills, and outstanding customer service skills Programming knowledge/experience is a BIG Plus, but is not required Being able to set aside a minimum of 7 hours a _week_ to work on bugs is a BIG Plus, but is not required This position is for the most part unsupervised, and strictly voluntary, meaning you will not be compensated/paid in any way. An interview does not create any form of contract either express or implied between you and The Wine Project, nor any of it's developers, contributors, subsidiaries, sister projects, or other users. If you feel that you have what it takes, and would like to apply, please reply to this message, and send it to Dustin Navea (Speeddymon at gmail dot com) Thanks and good luck! Wine Developers

1 0

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

May 12, 2005

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 May 12, 2005

May 12, 2005

"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 May 12, 2005

May 12, 2005

>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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

"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