31 Jul
2001
31 Jul
'01
12:39 a.m.
Ladislav Sladecek <lsla(a)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
julliard(a)winehq.com
2 Aug
2 Aug
9:50 p.m.
New subject: CS_PARENTDC with WS_CLIPSIBLINGS
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
3 Aug
3 Aug
10:38 a.m.
New subject: CS_PARENTDC with WS_CLIPSIBLINGS
On Thu, Aug 02, 2001 at 11:50:42PM +0200, Ladislav Sladecek wrote:
Alexandre Julliard wrote:
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 ?
--
Andreas Mohr
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.
5 Aug
5 Aug
11:23 p.m.
New subject: CS_PARENTDC with WS_CLIPSIBLINGS
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
8312
days inactive
8317
days old
3 comments
3 participants
participants (3)
-
Alexandre Julliard -
Andreas Mohr -
Ladislav Sladecek