Quickbooks 5 and printing

[Sean A. Walberg]

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

[Dan Engel]

Sean A. Walberg wrote:
> 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.

I would like to figure it out, too.  Here's what I've done so far:

Using "--debugmsg warn+all,+relay,+text,+string" I found that it's trying 
to load "wineps.drv.dll" which translates into "libwineps.drv.so".  This 
doesn't work, and it appears that the QB code is what's adding the .DRV to 
the WINEPS print driver name.

I hacked around that by checking for WINEPS.DRV at the beginning of 
BUILTIN_LoadModule and replacing it with WINEPS.

After that the .so file was being loaded but the dll, "wineps.dll" couldn't 
be found (again, according to BUILTIN_LoadModule).

Doing some more hacking shows that the __wine_dll_register is being called 
for wineps.dll.  It seems to me that this means that the name (wineps.dll) 
should be registered and therefore the dll should be found.

I'll be hacking on this some more, as time allows.  I'm extremely new to 
Wine code--I'm hoping that something I've done makes the problem obvious to 
a more seasoned veteran. . .  :-)

-Dan Engel

[Dmitry Timoshkov]

"Dan Engel"  wrote:
> Using "--debugmsg warn+all,+relay,+text,+string" I found that it's trying 
> to load "wineps.drv.dll" which translates into "libwineps.drv.so".  This 
> doesn't work, and it appears that the QB code is what's adding the .DRV to 
> the WINEPS print driver name.
>
> I hacked around that by checking for WINEPS.DRV at the beginning of 
> BUILTIN_LoadModule and replacing it with WINEPS.

First of all, you didn't tell what type of application is QB: 16 or 32 bit.
16-bit applications nearly always look for printer driver themself.
They look at win.ini in the following sections:
[devices], [PrinterPorts] or just [windows].device=

Starting from Win3.1, where common dialogs were introduced, applications
started just call common dialog, which allowed easy printer selection.

Vast majority of 32-bit applications also use common dialogs, but some "advanced"
(read - stupid) appications try do read registry or even use old Win3.x
method described above.

You should look at all places (win.ini and registry), find all references
to WINEPS and remove any extension from it (be it .DRV or .DLL). If that
will not help, post somewhere a +relay,+module trace.

[Dan Engel]

Dmitry Timoshkov wrote:
> First of all, you didn't tell what type of application is QB: 16 or 32

I guess I don't really know--how would I tell?  I know QB5 installed a 
bunch of *16.DLL files in c:/windows/system, but I don't know if that would 
indicate it's a 16-bit app, or that it's a 32-bit app wanting to maintain 
16-bit compatibility.

What trace would tell me what kind of app it is?
> bit. 16-bit applications nearly always look for printer driver themself.
> They look at win.ini in the following sections:
> [devices], [PrinterPorts] or just [windows].device=
>
> Starting from Win3.1, where common dialogs were introduced, applications
> started just call common dialog, which allowed easy printer selection.
>
> Vast majority of 32-bit applications also use common dialogs, but some
> "advanced" (read - stupid) appications try do read registry or even use
> old Win3.x method described above.
>
> You should look at all places (win.ini and registry), find all references
> to WINEPS and remove any extension from it (be it .DRV or .DLL). If that
> will not help, post somewhere a +relay,+module trace.

Interesting you should point that out.  I had already found that QB was 
adding ".DRV" to the driver name it found in win.ini.  I even opened up the 
DLL with hexedit and replaced all instances of ".DRV" with "".  That didn't 
help (although the trace indicated that it had "taken").

I don't believe my earlier noting of the error message from 
BUILTIN_LoadModule (err:module:BUILTIN_LoadModule loaded .so but dll 
wineps.drv still not found) indicates the problem.  The same error shows up 
for Quickbooks 4, yet QB4 printing works.

Here's a diff between corresponding sections of a QB4 and a QB5 trace.  The 
diff shows clearly how they stay in parallel up to a point, and then 
diverge.

At the point of divergence, QB4 goes on to set up its Print setup dialog.  
QB5 goes on to try (and fail) to load the driver 3 more times, and then 
shows a message box indicating that the printer driver is messed up.

--- wine_qb4_print_compare.log  Thu Apr 26 05:50:50 2001
+++ wine_qb5_print_compare.log  Thu Apr 26 05:49:51 2001
@@ -1,9 +1,9 @@
 trace:module:MODULE_LoadModule16 Trying built-in 'WINEPS.DRV'
-trace:string:lstrcpynA (0x411e14c5, "wineps."..., 7)
-trace:string:lstrcpynA (0x41475534, "wineps.dll", 11)
+trace:string:lstrcpynA (0x41746e21, "wineps."..., 7)
+trace:string:lstrcpynA (0x417713ac, "wineps.dll", 11)
 trace:string:lstrcpynA ((nil), ""..., 0)
-trace:string:lstrcpynA (0x41475534, "wineps.dll", 11)
-trace:string:lstrcpynA (0x411e1240, "wineps.dll", 11)
+trace:string:lstrcpynA (0x417713ac, "wineps.dll", 11)
+trace:string:lstrcpynA (0x41717bd8, "wineps.dll", 11)
 trace:string:lstrcpynA (0x40795e6c, "wine", 128)
 trace:module:GetModuleFileNameA wine
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
@@ -22,8 +22,8 @@
 warn:dosfs:DOSFS_FindUnixName 'test\user32.dll' not found in '/tmp'
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
 warn:dosfs:DOSFS_FindUnixName 'user32.dll' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
-trace:module:MODULE_LoadLibraryExA Already loaded module 'user32.dll' at 
0x40926000, count=15, 
+trace:string:lstrcpynA (0x41745c0c, "C:\WINDOWS\SYSTEM", 260)
+trace:module:MODULE_LoadLibraryExA Already loaded module 'user32.dll' at 
0x40926000, count=16, 
 trace:string:lstrcpynA (0x40795e6c, "wine", 128)
 trace:module:GetModuleFileNameA wine
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
@@ -42,7 +42,7 @@
 warn:dosfs:DOSFS_FindUnixName 'test\gdi32.dll' not found in '/tmp'
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
 warn:dosfs:DOSFS_FindUnixName 'gdi32.dll' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
+trace:string:lstrcpynA (0x41745c0c, "C:\WINDOWS\SYSTEM", 260)
 trace:module:MODULE_LoadLibraryExA Already loaded module 'gdi32.dll' at 
0x409ea000, count=9, 
 trace:string:lstrcpynA (0x40795e6c, "wine", 128)
 trace:module:GetModuleFileNameA wine
@@ -62,7 +62,7 @@
 warn:dosfs:DOSFS_FindUnixName 'test\winspool.drv' not found in '/tmp'
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
 warn:dosfs:DOSFS_FindUnixName 'winspool.drv' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
+trace:string:lstrcpynA (0x41745c0c, "C:\WINDOWS\SYSTEM", 260)
 trace:module:MODULE_LoadLibraryExA Already loaded module 'winspool.drv' at 
0x40fc4000, count=3, 
 trace:string:lstrcpynA (0x40795e6c, "wine", 128)
 trace:module:GetModuleFileNameA wine
@@ -82,8 +82,8 @@
 warn:dosfs:DOSFS_FindUnixName 'test\kernel32.dll' not found in '/tmp'
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
 warn:dosfs:DOSFS_FindUnixName 'kernel32.dll' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
-trace:module:MODULE_LoadLibraryExA Already loaded module 'kernel32.dll' at 
0x40603000, count=23, 
+trace:string:lstrcpynA (0x41745c0c, "C:\WINDOWS\SYSTEM", 260)
+trace:module:MODULE_LoadLibraryExA Already loaded module 'kernel32.dll' at 
0x40603000, count=24, 
 trace:string:lstrcpynA (0x40795e6c, "wine", 128)
 trace:module:GetModuleFileNameA wine
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
@@ -102,38 +102,29 @@
 warn:dosfs:DOSFS_FindUnixName 'test\ntdll.dll' not found in '/tmp'
 trace:string:lstrcpynA (0x40795f3c, "/home/dan", 1024)
 warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
-trace:module:MODULE_LoadLibraryExA Already loaded module 'ntdll.dll' at 
0x4005e000, count=21, 
-trace:module:load_library loaded wineps.dll 0x4145dda4 414b5000
+trace:string:lstrcpynA (0x41745c0c, "C:\WINDOWS\SYSTEM", 260)
+trace:module:MODULE_LoadLibraryExA Already loaded module 'ntdll.dll' at 
0x4005e000, count=22, 
+trace:module:load_library loaded wineps.dll 0x41717700 417f5000
 err:module:BUILTIN_LoadModule loaded .so but dll wineps.drv still not found
-Ret  KERNEL.95: LOADLIBRARY() retval=0x0002 ret=08b7:00c4 ds=090f
-Call GDI.53: CREATEDC(09f7:0290,09f7:01fa,09f7:023a,0000:0000) 
ret=08a7:0587 ds=090f
-trace:string:lstrcpynA (0x40795fc8, "C:\WINDOWS", 1024)
-trace:string:lstrcpynA (0x407963c8, "/work/wine", 1024)
-trace:string:lstrcpynA (0x40796c6c, "WINEPS,LPT1:", 300)
-trace:string:lstrcpynA (0x407961d4, "wine", 128)
-trace:module:GetModuleFileNameA wine
-trace:string:lstrcpynA (0x407962a4, "/home/dan", 1024)
-trace:string:lstrcpynA (0x407962ae, "tmp", 1014)
-trace:string:lstrcpynA (0x407966a7, "TMP", 1021)
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in '/home/dan/tmp'
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in 
'/work/wine/windows/system'
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in 
'/work/wine/windows'
-trace:string:lstrcpynA (0x407962a4, "/work/wine", 1024)
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in 
'/work/wine/windows'
-trace:string:lstrcpynA (0x407962a4, "/work/wine", 1024)
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in 
'/work/wine/windows/system'
-trace:string:lstrcpynA (0x407962a4, "/tmp", 1024)
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in '/tmp'
-trace:string:lstrcpynA (0x407962a4, "/tmp", 1024)
-warn:dosfs:DOSFS_FindUnixName 'test\WINEPS.dll' not found in '/tmp'
-trace:string:lstrcpynA (0x407962a4, "/home/dan", 1024)
-warn:dosfs:DOSFS_FindUnixName 'WINEPS.dll' not found in '/home/dan'
-trace:string:lstrcpynA (0x4145d9dc, "C:\WINDOWS\SYSTEM", 260)
-trace:module:MODULE_LoadLibraryExA Already loaded module 'WINEPS.dll' at 
0x414b5000, count=2, 
-trace:module:MODULE_DllProcessAttach (wineps.dll,(nil)) - START
-trace:module:MODULE_InitDLL (wineps.dll,PROCESS_ATTACH,(nil)) - CALL
-trace:relay:PE_InitDLL 
CallTo32(entryproc=0x414bd3e0,module=414b5000,type=1,res=(nil))
-trace:module:MODULE_InitDLL (0x4145dda4,PROCESS_ATTACH,(nil)) - RETURN 1
-trace:module:MODULE_DllProcessAttach (wineps.dll,(nil)) - END
-Call kernel32.MultiByteToWideChar(00000000,00000000,415f2f34 "Wine 
PostScript Driver",ffffffff,00000000,00000000) ret=40fc7054 tid=0806ee00
+Ret  KERNEL.95: LOADLIBRARY() retval=0x0002 ret=08af:12bb ds=09d7
+Call KERNEL.58: GETPROFILESTRING(0x08e7062d "devices",0x2cbf079e "Wine 
PostScript Driver",0x09d72a34 "",01ef:c082,0x0040) ret=08e7:07d0 ds=09d7
+trace:string:lstrcpynA (0x4079615c, "C:\WINDOWS", 1024)
+trace:string:lstrcpynA (0x4079655c, "/work/wine", 1024)
+trace:string:lstrcpynA (0x4037179a, "WINEPS,LPT1:", 64)
+Ret  KERNEL.58: GETPROFILESTRING() retval=0x000c ret=08e7:07d0 ds=09d7
+Call KERNEL.88: LSTRCPY(0x01efc06c,0x2cbf0880 "Wine PostScript Driver on 
LPT1:") ret=08af:11eb ds=09d7
+Ret  KERNEL.88: LSTRCPY() retval=0x01efc06c ret=08af:11eb ds=09d7
+Call KERNEL.58: GETPROFILESTRING(0x09d7063e "devices",0x01efc06c "Wine 
PostScript Driver",0x09d72a34 "",01ef:bfc6,0x0064) ret=08af:1248 ds=09d7
+trace:string:lstrcpynA (0x4079615c, "C:\WINDOWS", 1024)
+trace:string:lstrcpynA (0x4079655c, "/work/wine", 1024)
+trace:string:lstrcpynA (0x403716de, "WINEPS,LPT1:", 100)
+Ret  KERNEL.58: GETPROFILESTRING() retval=0x000c ret=08af:1248 ds=09d7
+Call KERNEL.88: LSTRCPY(0x01efbfb6,0x01efbfc6 "WINEPS") ret=08af:1296 
ds=09d7
+Ret  KERNEL.88: LSTRCPY() retval=0x01efbfb6 ret=08af:1296 ds=09d7
+Call KERNEL.89: LSTRCAT(01ef:bfb6 "WINEPS",0x08af1131 ".DRV") 
ret=08af:12a1 ds=09d7
+Ret  KERNEL.89: LSTRCAT() retval=0x01efbfb6 ret=08af:12a1 ds=09d7
+Call KERNEL.90: LSTRLEN(0x01efbfc6 "WINEPS") ret=08af:12ac ds=09d7
+Ret  KERNEL.90: LSTRLEN() retval=0x0006 ret=08af:12ac ds=09d7
+Call KERNEL.95: LOADLIBRARY(0x01efbfb6 "WINEPS.DRV") ret=08af:12bb ds=09d7
+trace:string:lstrcpynA (0x40796c94, "WINEPS.DRV", 260)
+trace:module:MODULE_GetLoadOrder looking for WINEPS.DRV

[Dmitry Timoshkov]

"Dan Engel"  wrote:
> > First of all, you didn't tell what type of application is QB: 16 or 32
>
> I guess I don't really know--how would I tell?  I know QB5 installed a 
> bunch of *16.DLL files in c:/windows/system, but I don't know if that would 
> indicate it's a 16-bit app, or that it's a 32-bit app wanting to maintain 
> 16-bit compatibility.
>
> What trace would tell me what kind of app it is?

Well, if you can't distinguish 16 from 32 bit application by eyes (PE and NE
files are very different), then look at relay trace: if an application does calls
to kernel, user and gdi, it is 16 bit one, if it calls kernel32, user32 and gdi32,
then it is 32 bit. Your trace shows that QB5 is a 16-bit application.

[...]
> Here's a diff between corresponding sections of a QB4 and a QB5 trace.  The 
> diff shows clearly how they stay in parallel up to a point, and then 
> diverge.

[useless diff snipped]

Diffs are nearly always show nothing to anybody, except who really knows why
he did that diff and expect to see some results in it.

As I already asked, please do +relay,+module trace, compress it, put somewhere on
the net and post an url here. (Also please do not add any other debugging switches
without additional request).

[Dan Engel]

Dmitry Timoshkov wrote:
> As I already asked, please do +relay,+module trace, compress it, put
> somewhere on the net and post an url here. (Also please do not add any
> other debugging switches without additional request).

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.

-Dan

[Dmitry Timoshkov]

"Dan Engel"  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.

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.

Changelog:
    Rename wineps.dll to wineps.drv. Replace all occurences of wineps by wineps.drv
    in the sources and documentation.

[eric pouech]

Dan Engel wrote:
> Sean A. Walberg wrote:
> > 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.
>
> I would like to figure it out, too.  Here's what I've done so far:
>
> Using "--debugmsg warn+all,+relay,+text,+string" I found that it's trying
> to load "wineps.drv.dll" which translates into "libwineps.drv.so".  This
> doesn't work, and it appears that the QB code is what's adding the .DRV to
> the WINEPS print driver name.

I wonder if QB5 doesn't assume that all printer drivers must be .drv
files
(not .dll), and gets the name with basic heuristics...
we should perhaps build wineps as wineps.drv (for now it's built as
wineps.dll)

A+

[Dan Engel]

eric pouech wrote:
> I wonder if QB5 doesn't assume that all printer drivers must be .drv
> files
> (not .dll), and gets the name with basic heuristics...

QB5 does just that.  There's a call STRCAT-ing the .DRV extension to the driver
name (WINEPS) just before trying to load the module.  I can make it cat an empty
string instead (by hexedit-ing the qbwpr.dll file), and the STRCAT is clearly
using an empty string now, instead of '.DRV', but the result is still the same
(i.e., the printer doesn't work, and the same message box is given.)
> we should perhaps build wineps as wineps.drv (for now it's built as
> wineps.dll)
> A+
>
> Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
> "The future will be better tomorrow", Vice President Dan Quayle