CS_PARENTDC with WS_CLIPSIBLINGS

[Andreas Mohr]

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 ?

-- 
Andreas Mohr