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

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards May 13, 2005

May 13, 2005

Hi, --- Francois Gouget <fgouget(a)free.fr> wrote: > No, that should not happen. If an application links with a library that > exports funcA() and funcB() but it only calls funcA(), then it will only > import funcA() and it will work on a system where that library only > exports funcA(). OK maybe I am thinking of a bug in binutils or something. There were a few of them caused problems when building on mingw which result in me having to hack Winebuild a bit. Thanks Steven Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

Re: winefile temporary allocations
by Francois Gouget May 13, 2005

May 13, 2005

On Fri, 13 May 2005, Martin Fuchs wrote: > Changelog > use macros for platform dependent temporary allocations [...] > +#define TMP_ALLOC(s) HeapAlloc(GetProcessHeap(), 0, s) > +#define TMP_FREE(p) HeapFree(GetProcessHeap(), 0, p) > +#else > +#define TMP_ALLOC(s) alloca(s) > +#define TMP_FREE(p) > #endif Why is this needed? Doesn't HeapAlloc work on any 'Win32' platform? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

3 2

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

May 13, 2005

Peter wrote: > I see. > Of course I have Acrobat 7 installed. The problem is Adobe does not > supply the DRM plugin (Yea I know some of you do not like DRM and I have > too some reservations but we should have the choice, shouldn't we?) > Since the only other way to get DRM support beside wine is VMware wich > is more ugly to set up. > > I would like to have a working Acrobat reader with DRM support on wine > since this is less trouble (and more efficent) then the VMware solution > people use atm. > > Maybe I can get Acrobat reader 5 with DRM support up and running. > Adobe has a very confusing policy of giving away information what > Version can on which Plattform. > I send them a note already but i fear (like always) I am ignored. :( > > cheers > Peter > > Am Donnerstag, den 12.05.2005, 11:46 -0400 schrieb gslink: > >>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. >> > > > The only difference between talking to a telephone pole and talking to Adobe is that if you drink enough the telephone pole will answer. In reality almost nothing of any importance currently runs on Wine without some setup. What you probably need to do is to experiment with replacing some of the dlls or adding some from Windows. This is usually what is necessary. You may also need to install the software in a Windows machine and then copy it over. Start trying things and something will probably work. I have been getting on the Wine people because this feature of Wine makes it useless for the average user. There needs to be some easy way for someone to report what is necessary to get a new version of something running or there needs to be a good configurator written. Wine is a very good program but the Wine group is making a classic programming error in forgetting the user interface. It doesn't make any difference how good it is if you can't get at it! In this case you can't.

2 1

Re: Looking for win9x/ME testers
by Saulius Krasuckas May 13, 2005

May 13, 2005

* On Thu, 12 May 2005, Hans Leidekker wrote: > * On Thursday 12 May 2005 00:14, Kevin Koltzau wrote: > > The ole32_test.exe file is linked to missing export NTDLL.DLL:atoi. > > This patch fixes it. ... > Changelog: > Don't import from ntdll. Can someone explain me, please, where would atoi() function be linked now to? I still have not installed MinGW package, so cannot cross-compile winetest and cannot check this myself. :-/

2 1

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards May 13, 2005

May 13, 2005

Hi Michael, I really like the idea of trying to tie the apps in better for users of Winelib applications but I have a few problems. (I should have spoken up when the first of the Unixfs stuff was going in to shell32 because I feel it should have been a shellext outsite of shell32 but now I am off the subject) --- Michael Lin <mlin(a)corvu.com.au> wrote: --- dlls/commdlg/comdlg32.spec +@ stdcall UnixFSGetOpenFileNameA(ptr) +@ stdcall UnixFSGetOpenFileN Is there anyway for us to have these functions inlined or something rather than exported all the time is there? The reason I ask is that being able to build applications using Wine on Windows and Mingw helps with testing and if we building on Windows using Wine headers and link to the Wine import libs the application will fail running the application on Windows because the Windows dll wont export these functions. +BOOL WINAPI UnixFSGetSaveFileNameW( + LPOPENFILENAMEW ofn) /* [in/out] address of init structure */ +{ + BOOL win16look = FALSE; + + if (ofn->Flags & (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE)) + win16look = (ofn->Flags & OFN_EXPLORER) ? FALSE : TRUE; + + if (win16look) + return GetFileName31W(ofn, SAVE_DIALOG); + else You should not need any of this for a Winelib app. Office97 does this where it creates a 32bit dialog with a Win16 look and its needed for backwards compatiblity only. No new application should depend on this behavior and clearly not one that you have the source code to in Winelib. I already broke this in Wine once. Just return GetFileDialog95W. + return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE); } Thanks Steven Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

2 1

ERROR_NOT_READY (21) in ne_module.c
by Felix Nawothnig May 13, 2005

May 13, 2005

Since bug 2131 was closed I'll paste it here again: ne_module.c explicitly sets errorcode 21 (ERROR_NOT_READY) when ( LoadLibraryA()ing the owner of a 16bit dll failed or the search for the 16bit dll returned a real (.so) dll and not a symlink to the owner ) and trying to load a native version of the 16bit dll failed with ERROR_FILE_NOT_FOUND. (dlls/kernel/ne_module.c:1218) Anyone knows the reason for that behavior? -flx

3 5

Re: Support for binaries that were abandoned by M$, and maintenance hell?
by Steven Edwards May 13, 2005

May 13, 2005

--- Francois Gouget <fgouget(a)free.fr> wrote: > Furthermore a lot of '32bit applications' actually use 16bit code either > directly or indirectly (although that may be getting less common these > days). What this means is that if you remove 16bit support it's quite > likely a lot of 32bit applications will stop working. I do wish we could change it though. We could share more code with ReactOS with less hassle on merges if we could figure out a way to split the Win16 code out better for say the edit control. Thanks Steven Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/

1 0

Re: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
by Dmitry Timoshkov May 13, 2005

May 13, 2005

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > According to native messages sent to app we should redraw window > inside SetActiveWindow. If you have a test app then it should be converted into a Wine message test, there is no other way to prove that your patch is correct. > @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd > > if (IsWindow(hwnd)) > { > - SendMessageW( hwnd, WM_NCACTIVATE, (hwnd == GetForegroundWindow()), (LPARAM)previous ); > + SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous ); Active and foreground windows in win32 are not necessary the same window. -- Dmitry.

3 4

Support for binaries that were abandoned by M$, and maintenance hell?
by Dustin Navea May 12, 2005

May 12, 2005

The discussion on 16-bit support for cards.dll led me to an interesting theory. If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right? The only reason I can come up with is because they dont have the resources (or maybe just the desire) to maintain 2 separate trees (1 16-bit and 1 32-bit), and soon to be 3 trees including 64-bit.. We have the desire to allow any windows program to run, whether it runs in a current version of windows or not. The problem with this is that over time, dos support has faded damatically, as well as win16 support. Soon we will start writing more win64 conformance code, and less win32. Where will that leave all of the people that dont jump on the 64-bit bandwagon any time soon? <flame war first shot> I think we are getting to that point, from a maintenance perspective, where we should seriously consider reorganizing the project into a more hierarchal (sp?) structure, where we have some people that can take some time off from contributing 32 or 64-bit code when need be, to contribute some 16-bit code for a user who wants to use an older program. Possibly (just an idea) we should make a dedicated project page on sourceforge specifically for 16-bits. As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time. Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16.... </flame war first shot> Comments? Suggestions? Flames??? Bring it ;-) Dustin

4 3

Bug 2931 (again)
by Dustin Navea May 12, 2005

May 12, 2005

Ok, the author has posted a link to the commit.. http://www.winehq.org/hypermail/wine-cvs/2004/10/0376.html Seems to be what broke it, per regression testing. I dunno if this maybe caused a bug somewhere else to show up or what, but I figure someone could look at it.. Dustin

5 8

CVS compilation problem
by Uwe Bonnes May 12, 2005

May 12, 2005

Hallo, I updated yesterday and today. Compiling with todays CVS gives: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput -L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32 -L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 joystick.o(.text+0x543): In function `EnumJoysticks': /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined reference to `c_dfDIJoystick' joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: undefined reference to `c_dfDIJoystick2' collect2: ld returned 1 exit status Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Re: info please part 2
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) ? I should mention that the wine documentation is somewhat out of date, so generally if you don't already know how to do the things mentioned above, they will give you a rough idea, but some of the parameters have changed (especially on setting debug flags for tracing). While you can still apply, the users who already know how to do the above will obviously have a greater chance to be recruited. Dustin

1 0

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

[Bug 2932] - copy / paste to openoffice
by Dustin Navea May 12, 2005

May 12, 2005

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

May 12, 2005

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

May 12, 2005

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