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

Re: New breakages
by gerard patel May 3, 2001

May 3, 2001

At 08:42 AM 03/05/2001 -0700, you wrote: <snip> > Do you have a backtrace >for the crashes? Not completely, but here is what I can do for now. Note that I am not sure yet that these bugs are not related to the environment (x server, window manager, glibc, etc) Gerard - Crash with Eudora 4 when exiting : Unhandled exception: page fault on read access to 0x00000048 in 32-bit code (0x40a49529). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40a49529 (X11DRV_GetBitmapBits+0x185 [bitmap.c:213]): movl 0x48(%eax),%eax 213 *tbuf |= XGetPixel(image,w,h)<<(7-(w&7)); Wine-dbg>bt bt Backtrace: =>0 0x40a49529 (X11DRV_GetBitmapBits+0x185(bmp=0x403f375c, buffer=0x403f3ae4, count=0x80) [bitmap.c:213]) (ebp=40474298) 1 0x40a49e28 (X11DRV_BitmapBits+0x64(hbitmap=0x21c4, bits=0x403f3ae4, count=0x80, flags=0x2) [bitmap.c:427]) (ebp=404742b8) 2 0x40738a53 (GetBitmapBits+0x15f(hbitmap=0x21c4, count=0x80, bits=0x403f3ae4) [bitmap.c:280]) (ebp=404742e8) 3 0x4069c07a (CURSORICON_CreateFromResource+0x5aa(hInstance=0x0, hObj=0x0, bits=0x406d7380, cbSize=0x2e8, bIcon=0x1, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [cursoricon.c:639]) (ebp=40474370) 4 0x4069c3e7 (CURSORICON_Load+0x263(hInstance=0xde, name=0x7f03, width=0x20, height=0x20, colors=0x100, fCursor=0x0, loadflags=0x8040) [cursoricon.c:768]) (ebp=404743c0) 5 0x4069ed17 (LoadImageW+0x12f(hinst=0x0, name=0x7f03, type=0x1, desiredx=0x20, desiredy=0x0, loadflags=0x8040) [cursoricon.c:2263]) (ebp=404743f4) 6 0x4069df80 (LoadIconW+0x28(hInstance=0x0, name=0x7f03) [cursoricon.c:1782]) (ebp=40474418) 7 0x40692fa5 (STATIC_LoadIconW+0x2d(wndPtr=0x40371038, name=0x7f03) [static.c:154]) (ebp=40474430) 8 0x40693292 (StaticWndProc_locked+0x272(wndPtr=0x40371038, uMsg=0x81, wParam=0x0, lParam=0x40474854, unicode=0x1) [static.c:259]) (ebp=40474498) 9 0x406934f1 (StaticWndProcW+0x31(hWnd=0x9dcc, uMsg=0x81, wParam=0x0, lParam=0x40474854) [static.c:376]) (ebp=404744c4) 10 0x406cf237 (WINPROC_wrapper+0x17) (ebp=404744e8) Unhandled exception: page fault on read access to 0x00000048 in 32-bit code (0x40a49529). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40a49529 (X11DRV_GetBitmapBits+0x185 [bitmap.c:213]): movl 0x48(%eax),%eax 213 *tbuf |= XGetPixel(image,w,h)<<(7-(w&7)); >From the code, XGetImage returns 0 (fails). I have tried the obvious --- bitmap.c.orig Mon Jan 15 23:30:51 2001 +++ bitmap.c Fri Apr 27 23:12:27 2001 @@ -194,6 +194,12 @@ image = XGetImage( display, (Pixmap)bmp->physBitmap, 0, 0, bmp->bitmap.bmWidth, bmp->bitmap.bmHeight, AllPlanes, ZPixmap ); + if (!image) + { + wine_tsx11_unlock(); + ERR("XGetImage failed\n"); + return 0; + } bmp->bitmap.bmHeight = old_height; /* copy XImage to 16 bit padded image buffer with real bitsperpixel */ but it failed later. - crash when starting Visual Basic 3 : no backtrace available, the stack is trashed :-/ Here is a trace instead : Call USER.232: SETWINDOWPOS(0x1264,0x0000,0x0245,0x0121,0x00e2,0x00e2,0x0014) ret=0317:13ca ds=043f Call x11drv.SetWindowPos(40756d70) ret=40957c09 tid=081c29b8 trace:win:X11DRV_SetWindowPos hwnd 1264, swp (581,289)-(807,515) flags 00000014 trace:win:X11DRV_SetWindowPos current (0,222)-(180,568), style 86ce0000 CallTo16(func=035f:176c,ds=043f,0x1264,0x0046,0x0000,0x0097,0x009c) ss:sp=043f:8d04 AX=043e BX=0000 CX=0000 DX=0000 SI=0000 DI=0000 BP=8d2e ES=043f FS=0000 Call USER.107: DEFWINDOWPROC(0x1264,0x0046,0x0000,0x0097009c) ret=035f:1d52 ds=043f CallTo16(func=035f:176c,ds=043f,0x1264,0x0024,0x0000,0x0097,0x00c0) ss:sp=043f:8c80 AX=043e BX=0000 CX=0000 DX=0000 SI=0000 DI=0000 BP=8caa ES=043f FS=0000 Call USER.107: DEFWINDOWPROC(0x1264,0x0024,0x0000,0x009700c0) ret=035f:1d52 ds=043f Ret USER.107: DEFWINDOWPROC() retval=0x00000000 ret=035f:1d52 ds=043f CallTo16() ss:sp=043f:8c80 AX=0000 BX=00c0 CX=0000 DX=0000 BP=8caa SP=8c80 trace:win:WINPOS_GetMinMaxInfo 800 600 / 0 0 / 800 600 / 180 112 Ret USER.107: DEFWINDOWPROC() retval=0x00000000 ret=035f:1d52 ds=043f CallTo16() ss:sp=043f:8d04 AX=0000 BX=8d00 CX=0000 DX=0000 BP=8d2e SP=8d04 CallTo16(func=035f:176c,ds=043f,0x1264,0x0083,0x0001,0x0097,0x009c) ss:sp=043f:8d04 AX=043e BX=0000 CX=0000 DX=0000 SI=0000 DI=0000 BP=8d2e ES=043f FS=0000 Call USER.107: DEFWINDOWPROC(0x1264,0x0083,0x0001,0x0097009c) ret=035f:1d52 ds=043f Ret USER.107: DEFWINDOWPROC() retval=0x00000000 ret=035f:1d52 ds=043f CallTo16() ss:sp=043f:8d04 AX=0000 BX=8d00 CX=0000 DX=0000 BP=8d2e SP=8d04 trace:win:WINPOS_SendNCCalcSize 581,289-807,515 trace:event:EVENT_ProcessAllEvents called (thread 81c29b8). trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event ConfigureNotify for hwnd 1264 trace:event:__get_top_decoration 03400430 -> 03400430 trace:event:__get_top_decoration 0340047c -> 020005c6 trace:event:__get_top_decoration 034003fa -> 020005ba trace:win:EVENT_ConfigureNotify 1264 restacking from after 1800 to after 0fd0 Call x11drv.SetWindowPos(40756a78) ret=40957c09 tid=081c29b8 trace:win:X11DRV_SetWindowPos hwnd 1264, swp (581,289)-(807,515) flags 80000013 trace:win:X11DRV_SetWindowPos current (581,289)-(807,515), style 86ce0000 CallTo16(func=035f:176c,ds=043f,0x1264,0x0046,0x0000,0x0097,0x009c) ss:sp=043f:8d04 AX=043e BX=0000 CX=0000 DX=0000 SI=0000 DI=0000 BP=8d2e ES=043f FS=0000 Call USER.107: DEFWINDOWPROC(0x1264,0x0046,0x0000,0x0097009c) ret=035f:1d52 ds=043f Ret USER.107: DEFWINDOWPROC() retval=0x00000000 ret=035f:1d52 ds=043f CallTo16() ss:sp=043f:8d04 AX=0000 BX=8d00 CX=0000 DX=0000 BP=8d2e SP=8d04 warn:win:SWP_DoOwnedPopups (1264) hInsertAfter = 0fd0 Call x11drv.SetWindowPos(407568d0) ret=40957c09 tid=081c29b8 trace:win:X11DRV_SetWindowPos hwnd 1d88, swp (0,0)-(0,0) flags 00002413 trace:win:X11DRV_SetWindowPos current (0,0)-(276,72), style 84000000 warn:win:SWP_DoOwnedPopups (1d88) hInsertAfter = 0fd0 fixme:pthread_kill_other_threads_np (winedbg starting...) 0x003bbdfc: *** Invalid address 0x003bbdfc -- no code -- Wine-dbg>bt bt Backtrace: =>0 0x003bbdfc (ebp=4074f722) Wine-dbg>

1 0

Re: PATCH: glu32 generation
by Alexandre Julliard May 3, 2001

May 3, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Create a GLU32.DLL on compile time by parsing GL/glu.h and > libGLU.so, create an empty one if the latter are not present. It doesn't seem to work here: "nm: /usr/lib/libGLU.so: no symbols". The library is probably stripped. Anyway, is there a reason we cannot ship the generated .spec and .c files like with opengl, instead of having every user re-generate them? It would be much more robust. Also note that a .so file must contain exactly one Win32 dll, so you cannot put glu32.spec inside libopengl32.so, you need a separate libglu32.so. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine server protocol error running Notes
by Alexandre Julliard May 3, 2001

May 3, 2001

David.Goodenough(a)dga.co.uk writes: > I am getting an intermittent error when I run Notes under Wine (February > drop). The error I get reads: > > protocol error: 0x8064159: copy_req_path: invalid length 51/0 > > Is this a known problem, if not where do I start looking to try to track > down the problem? A -debugmsg +server,+reg would be a good start. But get the latest Wine version first, there have been some fixes in this area. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: New breakages
by Alexandre Julliard May 3, 2001

May 3, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > Excellent, this is fixing the painting problems. > Now, all I have to do is to find the tooltip bug, the Eudora combo display problem > and the 2 remaining crashes and my toy test suite will be in as good shape as > before :-) The tooltip bug will be fixed when I commit the rest of the window management changes, so don't spend time on it. Do you have a backtrace for the crashes? maybe I have already fixed these too. -- Alexandre Julliard julliard(a)winehq.com

1 0

setupx dll
by Christopher Morgan May 3, 2001

May 3, 2001

Can we move the setupx files from dlls/setupapi into dlls/setupx? I was wondering why we have a setupx directory with nothing in it ;-) Chris

2 1

wine server protocol error running Notes
by David.Goodenough＠dga.co.uk May 3, 2001

May 3, 2001

I am getting an intermittent error when I run Notes under Wine (February drop). The error I get reads: protocol error: 0x8064159: copy_req_path: invalid length 51/0 Is this a known problem, if not where do I start looking to try to track down the problem? This only seems to occur during shutdown of Notes, and it returns control to the command line but leaves the Notes client window up on the screen, with at least one wine <defunct> process and one other wine process listed in ps.

1 0

Re: New breakages
by gerard patel May 3, 2001

May 3, 2001

At 05:46 PM 02/05/2001 -0700, you wrote: >could you please give this a try? <snip> Excellent, this is fixing the painting problems. Now, all I have to do is to find the tooltip bug, the Eudora combo display problem and the 2 remaining crashes and my toy test suite will be in as good shape as before :-) Gerard

1 0

Wine and NetBSD
by Bang Jun-Young May 2, 2001

May 2, 2001

Hi, For the last couple of weeks I spent some time doing porting Wine to NetBSD (there used to be a port but was too out of date). After applying patches my own, it has been successfully compiled and started running. The most serious problem occurs, however, whenever I try to run a Windows binary with it: $ wine c:\\windows\\sol.exe No built-in EXE module loaded! Did you create a .spec file? Obviously sol.exe doesn't need a .spec file to run. When/Why do I get such an error? Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

3 4

Re: New breakages
by Alexandre Julliard May 2, 2001

May 2, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > [patch snipped] > > I got the following results : > > Word viewer 32 bits, 16 bits, Lotus Notes (AFAICT), Statview, QuattroPro 1, and a > few old 16 bits apps I have display more or less as well as before (some crud for WW32 > that was not before, though :-/) Thanks a lot for tracking this down; I think I found the real bug, could you please give this a try? Index: windows/dce.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/dce.c,v retrieving revision 1.53 diff -u -r1.53 dce.c --- windows/dce.c 2001/04/24 23:28:52 1.53 +++ windows/dce.c 2001/05/03 00:37:31 @@ -671,7 +671,12 @@ * means that we have to recompute the visible region. */ if( dce->DCXflags & DCX_DCEBUSY ) + { + /* Dirty bit has been cleared by caller, set it again so that + * pGetDC recomputes the update region. */ + SetHookFlags16( dce->hDC, DCHF_INVALIDATEVISRGN ); USER_Driver.pGetDC( dce->hwndCurrent, dce->hDC, dce->hClipRgn, dce->DCXflags ); + } else /* non-fatal but shouldn't happen */ WARN("DC is not in use!\n"); break; -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: New breakages
by gerard patel May 2, 2001

May 2, 2001

At 02:30 PM 25/04/2001 +0200, I wrote: >At 09:30 AM 25/04/2001 +0200, I wrote: > >Also several apps are not erasing parts of the screen : among others the word viewer 97 >(freeware downloadable). A few other strange crashes. Still talking to myself... I feel I'm soon one of these sad cases talking alone in the street ;-) I have found one way to fix a lot of the ugliness that the evil patch of 24 april has done; by doing : --- dce.c.orig Thu May 3 00:02:35 2001 +++ dce.c Wed May 2 23:49:19 2001 @@ -551,7 +551,7 @@ dce->DCXflags &= ~DCX_DCEDIRTY; hdc = dce->hDC; - if (bUpdateVisRgn) SetHookFlags16( hdc, DCHF_INVALIDATEVISRGN ); /* force update */ + if (bUpdateVisRgn) flags |= 0x8000; if (!USER_Driver.pGetDC( hwnd, hdc, hrgnClip, flags )) hdc = 0; and --- winpos.c.orig Wed Apr 25 01:28:52 2001 +++ winpos.c Wed May 2 23:49:01 2001 @@ -355,7 +355,8 @@ TSXSetClipOrigin( display, physDev->gc, dc->DCOrgX, dc->DCOrgY ); #endif - updateVisRgn = (dc->flags & DC_DIRTY) != 0; + updateVisRgn = (flags & 0x8000) != 0; + dc->flags &= ~DC_DIRTY; GDI_ReleaseObj( hdc ); if (updateVisRgn) I got the following results : Word viewer 32 bits, 16 bits, Lotus Notes (AFAICT), Statview, QuattroPro 1, and a few old 16 bits apps I have display more or less as well as before (some crud for WW32 that was not before, though :-/) Doing things in such a way is more conforming to the way they were done before - and it seems more simple that the SetHookFlags trick IMHO ;-) Gerard

1 0

Re: Script to get committed patches
by gerard patel May 2, 2001

May 2, 2001

At 08:04 PM 01/05/2001 +0200, you wrote: >as of today, the added files are marked with the &&& mark (instead of >the +++ and --- for the diffs), which of course causes some issues when >you use the whole file as a patch (normally, all the added files are at >the end; so the "easy" way of doing it is to remove that part, apply the >patch, and then create the new files) <snip> >I'd say it's a documented feature ;-), Documented ? Oops, I missed completely this part. This weekend I have browsed the wonderful Wine user manual for the first time , since I have now a computer with a working db2html - now I know what *is* the Wine user manual ;-) I have not seen where this info is hiding. Maybe it was in one of your (defunct) WWN. I tried to read them but I probably was lazy too. Btw, your successor has problems to get in the game; I noticed on LinuxToday that the last Kernel Cousin Wine was showing a 'slow week' - the week where Marcus posted CUPS support - IMHO the more interesting patch since months for all non-games apps. He is not following wine-patches and wine-cvs it seems :-/ > I'll try to give it a look later >on I see no reason for you to work on this rather trivial matter. All that is needed is to know the problem. I should have guessed it but I was probably too stressed by the idea of having this 200k patch to look at ;-( Now it's done, thanks for the tip. Gerard

4 4

Re: FreeLibrary() library freeing
by Alexandre Julliard May 2, 2001

May 2, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > If you remember, there are glibc problems with dlclose. Alexandre Julliard > said that it was not a problem because FreeLibrary was not doing anything. > So I guess that people with 'old' glibc could have now new crashes. Actually we still cannot dlclose builtin libraries; the change I made is to free memory used by PE dlls. Freeing builtins properly will require dll separation to be completed first. And once this is done we will no longer rely on glibc dlclose reference counting so the bug shouldn't impact us. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: FreeLibrary() library freeing
by gerard patel May 2, 2001

May 2, 2001

At 11:23 PM 01/05/2001 +0200, you wrote: <snip> >I believe the potential problems that this can cause are way more important >than some claims that "there are some problems with library freeing". >I've had that FreeLibrary() #if hack removed for a long time, >and I haven't see any adverse effects (not that it's too easy to spot >and attribute to this problem probably, though). If you remember, there are glibc problems with dlclose. Alexandre Julliard said that it was not a problem because FreeLibrary was not doing anything. So I guess that people with 'old' glibc could have now new crashes. Gerard

2 1

Re: FreeLibrary() library freeing
by Alexandre Julliard May 2, 2001

May 2, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > I for one would truly like to see it fixed ASAP. > > If FreeLibrary() has a problem, then we need to fix it. > Running away from the problem by implementing strange hacks does no good > to anybody. Agreed; I have uncommented the VirtualFree, and you are hereby volunteered to track down and fix any crash caused by this ;-) -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Quickbooks 5 and printing
by Alexandre Julliard May 2, 2001

May 2, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Please try the attached patch. It tries to solve the root of the problem: > for now Wine Postscript Driver lives in wineps.dll, but should be in wineps.drv. I'm not sure this is correct. The app is trying to load a 16-bit driver, so giving it the 32-bit dll is probably not a good idea. Maybe we should simply rename wineps16.dll to wineps.drv? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: FW: Notes and Java test on 20010216 drop
by Alexandre Julliard May 1, 2001

May 1, 2001

"Nerijus Baliunas" <nerijus(a)users.sourceforge.net> writes: > why the following patch is not applied? I don't think it was ever submitted; but anyway, it's quite ugly to check the callouts on every module load/unload. The right fix is to get rid of the Callout structure and do a GetProcAddress at the time we need a specific function. -- Alexandre Julliard julliard(a)winehq.com

1 0

FreeLibrary() library freeing
by Andreas Mohr May 1, 2001

May 1, 2001

Hi all, can't we just free the libraries for real now in FreeLibrary() ? I just got a report from someone who had an InstallSh***** installer say this: Call kernel32.192: CreateFileA(40566cf4 "C:\\WINDOWS\\uninst.exe",c0000000,00000001,00000000,00000004,00000080,00000000) ret=0044364e fs=008f trace:file:CreateFileA C:\WINDOWS\uninst.exe GENERIC_READ GENERIC_WRITE FILE_SHARE_READ OPEN_ALWAYS trace:dosfs:DOSFS_GetFullName C:\WINDOWS\uninst.exe (last=0) trace:string:lstrcpynA (0x40566148, "/home/jnu/.wine/fake_windows", 1024) trace:dosfs:DOSFS_FindUnixName /home/jnu/.wine/fake_windows,WINDOWS\uninst.exe trace:dosfs:DOSFS_FindUnixName (/home/jnu/.wine/fake_windows,WINDOWS\uninst.exe) -> Windows (WINDOWS) trace:dosfs:DOSFS_FindUnixName /home/jnu/.wine/fake_windows/Windows,uninst.exe warn:dosfs:DOSFS_FindUnixName 'uninst.exe' not found in '/home/jnu/.wine/fake_windows/Windows' trace:dosfs:DOSFS_GetFullName returning /home/jnu/.wine/fake_windows/Windows/uninst.exe = C:\WINDOWS\uninst.exe warn:file:FILE_CreateFile Unable to create file '/home/jnu/.wine/fake_windows/Windows/uninst.exe' (GLE 32) Ret kernel32.192: CreateFileA() retval=ffffffff ret=0044364e fs=008f . . . Call kernel32.943: lstrcpyA(40566834,40380370 "Setup Initialization Error") ret=00403322 fs=008f Ret kernel32.943: lstrcpyA() retval=40566834 ret=00403322 fs=008f trace:string:wvsnprintfA 0x40566960 1024 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "... trace:string:wvsnprintfA "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "... Call user32.425: MessageBoxA(00000000,40566960 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "...,40566834 "Setup Initialization Error",00000010) ret=00403402 fs=008f This happened because the program did some FileVersionGet*() calls before on uninst.exe, which do LoadLibrary()/FreeLibrary() internally, but of course the file handle didn't get freed any more. I believe the potential problems that this can cause are way more important than some claims that "there are some problems with library freeing". I've had that FreeLibrary() #if hack removed for a long time, and I haven't see any adverse effects (not that it's too easy to spot and attribute to this problem probably, though). Besides, Musicmatch Jukebox used zillions of MB (yes, that's a leak for you) due to that Wine "feature". I for one would truly like to see it fixed ASAP. If FreeLibrary() has a problem, then we need to fix it. Running away from the problem by implementing strange hacks does no good to anybody. Andreas Mohr -- Microsoft Windows: Made for the Internet The Internet: Made for Unix

1 0

Script to get committed patches
by gerard patel May 1, 2001

May 1, 2001

I have tried to retrieve this patch : http://cvs.winehq.com/patch.py?id=9881549330718504618853331 It does not look as a regular diff ??? I suspect a problem in the script. I have absolutely no knowledge of the language used in this script, so I can't do more than report. Here is quoted a small part of the beast, cut & paste from Netscape. Gerard --- /opt/cvs-commit/wine/dlls/x11drv/x11drv.spec 2001/01/15 20:23:06 1.7 +++ /opt/cvs-commit/wine/dlls/x11drv/x11drv.spec 2001/04/24 23:28:52 1.8 @@ -11,8 +11,6 @@ # USER driver -@ cdecl Synchronize() X11DRV_Synchronize -@ cdecl CheckFocus() X11DRV_CheckFocus @ cdecl UserRepaintDisable(long) X11DRV_UserRepaintDisable @ cdecl InitKeyboard() X11DRV_InitKeyboard @ cdecl VkKeyScan(long) X11DRV_VkKeyScan @@ -24,8 +22,6 @@ @ cdecl Beep() X11DRV_Beep @ cdecl GetDIState(long ptr) X11DRV_GetDIState @ cdecl GetDIData(ptr long ptr ptr long) X11DRV_GetDIData -@ cdecl GetKeyboardConfig(ptr) X11DRV_GetKeyboardConfig -@ cdecl SetKeyboardConfig(ptr long) X11DRV_SetKeyboardConfig @ cdecl InitMouse(ptr) X11DRV_InitMouse @ cdecl SetCursor(ptr) X11DRV_SetCursor @ cdecl MoveCursor(long long) X11DRV_MoveCursor @@ -34,6 +30,16 @@ @ cdecl GetScreenSaveTimeout() X11DRV_GetScreenSaveTimeout @ cdecl SetScreenSaveTimeout(long) X11DRV_SetScreenSaveTimeout @ cdecl LoadOEMResource(long long) X11DRV_LoadOEMResource +@ cdecl CreateWindow(long) X11DRV_CreateWindow +@ cdecl DestroyWindow(long) X11DRV_DestroyWindow +@ cdecl GetDC(long long long long) X11DRV_GetDC +@ cdecl EnableWindow(long long) X11DRV_EnableWindow +@ cdecl SetFocus(long) X11DRV_SetFocus +@ cdecl SetParent(long long) X11DRV_SetParent +@ cdecl SetWindowPos(ptr) X11DRV_SetWindowPos +@ cdecl SetWindowRgn(long long) X11DRV_SetWindowRgn +@ cdecl SetWindowIcon(long long long) X11DRV_SetWindowIcon +@ cdecl SetWindowText(long wstr) X11DRV_SetWindowText @ cdecl IsSingleWindow() X11DRV_IsSingleWindow @ cdecl AcquireClipboard() X11DRV_AcquireClipboard @ cdecl ReleaseClipboard() X11DRV_ReleaseClipboard &&& wine/dlls/x11drv/window.c /* * Window related functions * * Copyright 1993, 1994, 1995, 1996, 2001 Alexandre Julliard * Copyright 1993 David Metcalfe * Copyright 1995, 1996 Alex Korobka */ #include "config.h" #include "ts_xlib.h" #include "ts_xutil.h" #include "winbase.h" #include "wingdi.h" #include "winuser.h"

2 1

FW: Notes and Java test on 20010216 drop
by Nerijus Baliunas May 1, 2001

May 1, 2001

Hello, why the following patch is not applied? -----Original Message----- From: David.Goodenough(a)dga.co.uk [mailto:David.Goodenough(a)dga.co.uk] Subject: RE: Notes and Java test on 20010216 drop The Java problem I had with the last drop (the problem with Callout not being initialised) is still there, so obviously the fix that was generated and which fixes the problem has not made it into the CVS. The good news is that now Java works (if the patch is applied). Now the fonts display correctly. I am not sure what you have done guys, but it works a treat. Now for some more testing with some of the things I wanted to run but could not because of the Java support. Interestingly both the Sun and the IBM JREs now work, where last month with the fix the Sun one produced the wrong output but at least ran to completion, while the IBM one locked up somewhere. Now both run to completion properly. I was sent this (I think on wine-develop but it might have been directly). It fixes the Callout problem. I forget who originally sent it to me, but I could find out if that is necessary. diff -ur wine-cvs/if1632/thunk.c wine-uw/if1632/thunk.c --- wine-cvs/if1632/thunk.c Wed Jan 3 22:51:30 2001 +++ wine-uw/if1632/thunk.c Mon Jan 29 00:35:49 2001 @@ -166,7 +166,7 @@ NE_MODULE *pModule; hModule = GetModuleHandleA( "user32.dll" ); - if ( hModule ) + if ( hModule && !Callout.PeekMessageA ) { #define GETADDR( name ) \ *(FARPROC *)&Callout.name = GetProcAddress( hModule, #name ) @@ -185,10 +185,24 @@ GETADDR( MessageBoxW ); #undef GETADDR } - else WARN("no 32-bit USER\n"); + if ( !hModule && Callout.PeekMessageA ) + { + Callout.PeekMessageA = NULL; + Callout.GetMessageA = NULL; + Callout.SendMessageA = NULL; + Callout.PostMessageA = NULL; + Callout.TranslateMessage = NULL; + Callout.DispatchMessageA = NULL; + Callout.RedrawWindow = NULL; + Callout.WaitForInputIdle = NULL; + Callout.MsgWaitForMultipleObjects = NULL; + Callout.WindowFromDC = NULL; + Callout.MessageBoxA = NULL; + Callout.MessageBoxW = NULL; + } pModule = NE_GetPtr( GetModuleHandle16( "USER.EXE" ) ); - if ( pModule ) + if ( pModule && !Callout.FinalUserInit16 ) { #define GETADDR( var, name, thk ) \ *(FARPROC *)&Callout.var = THUNK_GetCalloutThunk( pModule, name, \ @@ -201,5 +215,12 @@ GETADDR( UserSignalProc, "SignalProc32", word_lllw ); #undef GETADDR } - else WARN("no 16-bit USER\n"); + if ( !pModule && Callout.FinalUserInit16 ) + { + Callout.FinalUserInit16 = NULL; + Callout.InitThreadInput16 = NULL; + Callout.UserYield16 = NULL; + Callout.DestroyIcon32 = NULL; + Callout.UserSignalProc = NULL; + } } diff -ur wine-cvs/loader/module.c wine-uw/loader/module.c --- wine-cvs/loader/module.c Tue Jan 16 00:29:27 2001 +++ wine-uw/loader/module.c Mon Jan 29 00:30:20 2001 @@ -1432,6 +1432,9 @@ /* decrement the dependencies through the MODULE_FreeLibrary call. */ pwm->refCount++; + /* Update the kernel Callout tables */ + THUNK_InitCallout(); + RtlReleasePebLock(); SetLastError( err ); /* restore last error */ HeapFree ( GetProcessHeap(), 0, filename ); @@ -1526,6 +1529,9 @@ HeapFree( GetProcessHeap(), 0, wm->short_filename ); HeapFree( GetProcessHeap(), 0, wm ); } + + /* Update the kernel Callout tables */ + THUNK_InitCallout(); } /*********************************************************************** diff -ur wine-cvs/miscemu/main.c wine-uw/miscemu/main.c --- wine-cvs/miscemu/main.c Wed Jan 10 02:42:49 2001 +++ wine-uw/miscemu/main.c Mon Jan 29 00:36:05 2001 @@ -34,7 +34,6 @@ MESSAGE( "Cannot load user32.dll\n" ); ExitProcess( GetLastError() ); } - THUNK_InitCallout(); if ((instance = NE_StartMain( main_exe_name, main_exe_file )) < 32) { diff -ur wine-cvs/scheduler/process.c wine-uw/scheduler/process.c --- wine-cvs/scheduler/process.c Sun Jan 28 18:58:09 2001 +++ wine-uw/scheduler/process.c Mon Jan 29 00:36:17 2001 @@ -346,9 +346,6 @@ MODULE_DllProcessAttach( NULL, (LPVOID)1 ); RtlReleasePebLock(); - /* Get pointers to USER routines called by KERNEL */ - THUNK_InitCallout(); - /* Call FinalUserInit routine */ if (Callout.FinalUserInit16) Callout.FinalUserInit16();

1 0

Re: InstallShield and ole question...
by juergen.schmied＠debitel.net May 1, 2001

May 1, 2001

> As for doing the 10k+ lines of coding myself, I have experience in > (de)marshalling and network coding, spent many years doing it, it's more a > matter of available time and learning the com wire protocols, neither of which > are currently available to me. Here's to hoping someone is already working on > it ;). For local marshalling we could use our own protocol and even our own way of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one? For networking - the dcom protocoll is documented (IMHO). juergen

5 4

Quickbooks 5 and printing
by Sean A. Walberg May 1, 2001

May 1, 2001

After a long break, I'd like to figure out why quickbooks 5 can't print. wineps works, ie I can print in notepad, but QB seems to implement its own printing mechanism. --debugmsg +psdrv,+print,+winspool produces no output. Adding +font spits out a lot, but no errors that I can see. This all used to work until wineps was moved from graphics to a dll about a year ago. I can see from +dosfs that it's accessing some files (WPR.DAT/WPR.INI) which contain information on printers. There is also a QBWPR.DLL file that gets loaded. Any hints on where to start would be appreciated. Thanks, Sean -- Sean A. Walberg <sean(a)ertw.com> http://www.ertw.com *updated!* Join the weekly brainbuzz.com Linux newsletter for news and resources! Send a blank email to: join-linuxnews(a)list.brainbuzz.com

5 8

Re: STATUS_* codes
by David Howells May 1, 2001

May 1, 2001

STATUS_INVALID_EXECUTABLE_IMAGE should have read: STATUS_INVALID_IMAGE_FORMAT and I'm told that the value is 0xC000007B. Cheers, David

1 0

Re: Quickbooks 5 and printing
by gerard patel April 30, 2001

April 30, 2001

At 09:44 AM 28/04/2001 -0500, you wrote: >Okay, here are the traces. Here >(ftp://sourceharvest.com/pub/wine_qb4.log.gz) is the QB4 trace. QB4 >printing works. > >The other (ftp://sourceharvest.com/pub/wine_qb5.log.gz) is the QB5 trace. >QB5 printing doesn't work. The 2 traces are showing the same problem : the 2 versions of your app are trying to loadlibrary on the Wineps driver. This is not working in both cases. The difference comes from the app itself : QB4 is proceding anyway to a call to CreateDC (that's the usual way of printing after all) and this call succeeds - because Wine has been coded for this case- , while QB5 don't want to continue. My impression is that QB5 is a more sophisticate application that is actually *testing* the errors returned by the system. Unfortunately, that is also breaking its capability of printing under Wine. I am not sure why this LoadLibrary fails (it returns 2, file not found). I have done a quick and dirty LoadLibrary("WINEPS.DRV") in a winelib application : it fails. LoadLibrary("WINEPS.DLL") succeeds. So this is the problem it seems. LoadLibrary should be tweaked. I think that the code to patch is in library/loader.c, line 96 /* check for .dll or .exe extension to remove */ if (ext && (!strcmp( ext, ".dll" ) || !strcmp( ext, ".exe" ))) p = ext After the name problem is solved, the following problem is probably loading a 32 bits builtin library from 16 bits code. I don't remember clearly now (it's past 2 am for me) but the problem has already occured for other dlls. I think it was you who asked about the difference between 16 and 32 bits code; while you got a correct answer, there is also a first glance trick, useful when in one application you have transitions between 16 and 32 bits code : the 16 bits calls to the Api are shown in uppercase, the 32 bits are in lowercase. Gerard

1 0