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
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
"Dan Engel" <dengel(a)sourceharvest.com> 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.
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
"Dan Engel" <dengel(a)sourceharvest.com> 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).
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
"Dan Engel" <dengel(a)sourceharvest.com> 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.
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+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
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
participants (5)
-
Dan Engel -
Dan Engel -
Dmitry Timoshkov -
eric pouech -
Sean A. Walberg