Ladislav Sladecek lsla@post.cz writes:
If you run the binary in the Windows, you will see two properly sized red rectangles on a white background. If you run the same binary in Wine, you will see only one large red child but no white parent background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed from my example, both Windows and Wine give identical results.
Yes, there were a number of problems with the flags handling in GetDCEx. I think the behavior with the current CVS should now be correct in all cases; please give it a try.
Alexandre Julliard wrote:
Yes, there were a number of problems with the flags handling in GetDCEx. I think the behavior with the current CVS should now be correct in all cases; please give it a try.
Thank you for the fix. The example works fine but the original app ( 16 bit _prowin.exe from Progress RDBMS] ceased to work at all. After the menu is drawn, the application stops responding and complains about some illegal string operations and then about unknown driver ,, in GetDCA.
err:string:lstrcpyA (0x40a2e75e, (nil)): page fault occurred ! Caused by bug ? err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,,
I tried also --debugmsg +all; several houndreds lines of the trace are attached. I do not know if the problem is somewhat connected with your fix or is created by some other patch.
Ladislav Sladecek
On Thu, Aug 02, 2001 at 11:50:42PM +0200, Ladislav Sladecek wrote:
Alexandre Julliard wrote:
Yes, there were a number of problems with the flags handling in GetDCEx. I think the behavior with the current CVS should now be correct in all cases; please give it a try.
Thank you for the fix. The example works fine but the original app ( 16 bit _prowin.exe from Progress RDBMS] ceased to work at all. After the menu is drawn, the application stops responding and complains about some illegal string operations and then about unknown driver ,, in GetDCA.
err:string:lstrcpyA (0x40a2e75e, (nil)): page fault occurred ! Caused by bug ? err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,,
I tried also --debugmsg +all; several houndreds lines of the trace are attached. I do not know if the problem is somewhat connected with your fix or is created by some other patch.
No, it's not. Wine is not guilty at all, AFAICS. It's a totally dainbread application, that's why.
It checks win.ini [windows] device=XXX
and as this entry doesn't exist (it's "HP LaserJet 5M,PCL5EMS,LPT1:" here), the app does all sorts of very strange things: 0806c1f0:Call KERNEL.89: LSTRCAT(0667:e736 "",0x121f0190 ".DRV") ret=0ff7:0c29 ds=121f 0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Ret KERNEL.89: LSTRCAT() retval=0x0667e736 ret=0ff7:0c29 ds=121f 0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Call KERNEL.95: LOADLIBRARY(0x0667e736 ".DRV") ret=0ff7:0c34 ds=121f 0806c1f0:Ret KERNEL.95: LOADLIBRARY() retval=0x0002 ret=0ff7:0c34 ds=121f ^^^^^^ not too surprising
0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Call KERNEL.107: SETERRORMODE(0x0000) ret=0ff7:0c42 ds=121f 0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Ret KERNEL.107: SETERRORMODE() retval=0x8000 ret=0ff7:0c42 ds=121f 0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Call KERNEL.50: GETPROCADDRESS(0x0002,0x121f0195 "EXTDEVICEMODE") ret=0ff7:0c57 ds=121f ^^^^^^ eh ??
0806c1f0:trace:module:GetProcAddress16 0000 'EXTDEVICEMODE' 0806c1f0:trace:global:GlobalHandle16 015f 0806c1f0:Ret KERNEL.50: GETPROCADDRESS() retval=0x00000000 ret=0ff7:0c57 ds=121 could have told you before... ^^^^^^^^^^ f
My guess is that this application exhibits so braindead, non-checking behaviour since this win.ini entry is absolutely expected to exist.
Unfortunately I can't see from this short log why it checks the printer at all. We might want to make sure that in case we get asked for a printer, we also have a device= line in place, and if this isn't the case, then issue a fat warning to the end user. So OTOH Wine is probably guilty by not making sure that there is a device= line in case of psdrv or something.
What happens if you run this program on a windoze box without any printer installed ? (and thus the device= line should not exist, there, too...) Does it fail the same way or does it seem to recognize somehow that there is no printer installed ?
On Pá, 03 srp 2001, Andreas Mohr wrote:
It's a totally dainbread application, that's why.
I agree (no news for me:-) ) but this does not explain why the application worked fine on 2001/07/26. I looked into the change log and found
* dlls/wineps/init.c, dlls/wineps/wineps.spec, dlls/x11drv/x11drv.spec, graphics/Makefile.in, graphics/driver.c, graphics/win16drv/init.c, graphics/x11drv/bitmap.c, graphics/x11drv/init.c, graphics/x11drv/oembitmap.c, include/gdi.h, include/x11drv.h, objects/dc.c, dlls/gdi/Makefile.in, dlls/gdi/driver.c, dlls/gdi/gdi_main.c, dlls/ttydrv/bitmap.c, dlls/ttydrv/dc.c, dlls/ttydrv/ttydrv.spec: Build the DC function table by using GetProcAddress on the graphics driver module. Moved driver support to dlls/gdi.
I think that the problems were started by this patch. (I do not say that the patch is wrong, maybe the patch only found some stupid bug in the app). Thus I did
cvs -diff -D 20010727 -D 20010728
I do not pretend that I do understand the code but some coincidences exist. For example the crash is near the code which get changed, drivers and DCs are involved etc. Please look at this:
Index: dlls/gdi/gdi_main.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/gdi_main.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- dlls/gdi/gdi_main.c 2001/03/05 19:30:18 1.10 +++ dlls/gdi/gdi_main.c 2001/07/27 19:37:31 1.11 @@ -17,14 +17,7 @@ BOOL WINAPI MAIN_GdiInit(HINSTANCE hinstDLL, DWORD reason, LPVOID lpvReserved) { if (reason != DLL_PROCESS_ATTACH) return TRUE; - - /* GDI initialisation */ - if(!GDI_Init()) return FALSE; - - /* Create the Win16 printer driver */ - if (!WIN16DRV_Init()) return FALSE; - - return TRUE; + return GDI_Init(); }
And this:
Index: graphics/win16drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/win16drv/init.c,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- graphics/win16drv/init.c 2001/07/22 23:13:09 1.34 +++ graphics/win16drv/init.c 2001/07/27 19:37:32 1.35 @@ -144,17 +144,16 @@ };
- - - +/* FIXME: this no longer works */ +#if 0 /********************************************************************** * WIN16DRV_Init */ BOOL WIN16DRV_Init(void) { return DRIVER_RegisterDriver( NULL /* generic driver */, &WIN16DRV_Funcs ); - } +#endif
Maybe the printer driver never gets initialised? (Just a stupid speculation).
What happens if you run this program on a windoze box without any printer installed ? (and thus the device= line should not exist, there, too...) Does it fail the same way or does it seem to recognize somehow that there is no printer installed ?
I tried just now and the application worked fine, no problems. It did not tell anything about missing printer; which is OK as I did not start to print.
I have installed the application several houndred times previously, sometimes to boxes with no printers and never noticed similar problems on windoze.
Thank you for your advice.
Ladislav Sladecek
-
Alexandre Julliard -
Andreas Mohr -
Ladislav Sladecek