April 2001 - Wine-Devel - list.winehq.org

Re: Quickbooks 5 and printing

by 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+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

April 26, 2001

Re: InstallShield and ole question...

by Mike Bond

On Thu, Apr 26, 2001 at 12:55:30PM -0400, Gavriel State wrote: > The fix we put into the TransGaming tree was from Andreas Mohr, and it > fixed some problems related to previous versions of InstallSheild. We > haven't made any progress on v6. > > We'd certainly like to see it get done, but our resources are somewhat > limited at the moment, and we're concentrating on the DirectX work. I understand how that works. > Something that's interesting about the InstallShield objects is this: > They seem to expose a fair amount of their interfaces through OLE > Automation. I don't know for certain, but I have a recollection that > some work was done to support Automation for WordPerfect. I can't > remember whether that work was actually completed, or bypassed through > the use of dde for scripting instead. Hmm, would be interesting to get more details of what became of that work. > If automation does work, then perhaps it's enough to simply run the > InstallShield ikernel.exe and see if the user-side of the installer > works through automation rather than requiring marshalling. Unfortunately I had already tried that, first thing that came to mind once I realized what was going on. -- TTFN MikeB

April 26, 2001

Re: InstallShield and ole question...

by Gavriel State

Mike Bond wrote: > > This getes me back to the other part of the question, is anyone currently > working on this? I know people at CodeWeavers supposedly were working on > getting the various mutations of InstallShield working, this error seems > to be pretty common across all InstallSheild v6 based installers I've seen. > I had also heard there was progress getting Alice install working at > TransGaming, is that InstallSheild v6 based? The fix we put into the TransGaming tree was from Andreas Mohr, and it fixed some problems related to previous versions of InstallSheild. We haven't made any progress on v6. We'd certainly like to see it get done, but our resources are somewhat limited at the moment, and we're concentrating on the DirectX work. Something that's interesting about the InstallShield objects is this: They seem to expose a fair amount of their interfaces through OLE Automation. I don't know for certain, but I have a recollection that some work was done to support Automation for WordPerfect. I can't remember whether that work was actually completed, or bypassed through the use of dde for scripting instead. If automation does work, then perhaps it's enough to simply run the InstallShield ikernel.exe and see if the user-side of the installer works through automation rather than requiring marshalling. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

April 26, 2001

Re: InstallShield and ole question...

by Jeremy White

> This getes me back to the other part of the question, is anyone currently > working on this? I know people at CodeWeavers supposedly were working on > getting the various mutations of InstallShield working, this error seems > to be pretty common across all InstallSheild v6 based installers I've seen. > I had also heard there was progress getting Alice install working at > TransGaming, is that InstallSheild v6 based? AFAIK, no one is actively doing this. We're working hard on the installers, including everything up to the point of actually diving of the COM/DCOM cliff. Jeremy

April 26, 2001

Re: Quickbooks 5 and printing

by Dmitry Timoshkov

"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).

April 26, 2001

Re: InstallShield and ole question...

by Mike Bond

On Wed, Apr 25, 2001 at 10:24:26PM +0200, Juergen Schmied wrote: > > > > > My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER > > > > in compobj.c:CoGetClassObject, or have plans to work on this in the near > > > > future? If not, I may go back to trying to figure out what is happening > > > > with the 'native' configuration. > > > > > > This will require a lot of work, basically you will need to implement > > > all of the OLE out of process, marshalling, rpc stuff. > > > > > > This is not a trivial 100 line patch, its more like 20000+ lines. > > > > The CLSCTX_LOCAL_SERVER is used for function calls in another process > > on the same machine. So you wouldn't need any rpc, and I wouldn't think > > you would need marshalling .. In the case of InstallShield v6 it isn't > > really requesting anything from another process. It's requesting an > > object from an EXE, instead of a DLL. > Ok, not rpc but lpc so we might get along with 10000+ lines. ;-) > Mashalling is nessesary in any case since the function calls have to go from one > process to an other. The com object in the exe is likely an automation server. This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based? Unfortunately I've hit crunch time at work so all non-work related efforts have been paused. Hopefully in a week I'll get back to trying to figure out what was up with the 0x80070008. I think it my just be because I need to use native com dlls as well as the ole ones, but that is pure speculation at this point. As for doing the 10k+ lines of coding myself, I have experience in (de)marshalling and network coding, spent many years doing it, it's more a matter of available time and learning the com wire protocols, neither of which are currently available to me. Here's to hoping someone is already working on it ;). -- TTFN MikeB

April 26, 2001

Re: Quickbooks 5 and printing

by 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

April 26, 2001

dll-separated lzexpand doesn't work

by Ove Kaaven

At least not on debian unstable... I've tracked the problem down to: lzexpand_main.c, function LZCopy, line 525: xread=(_readfun)LZRead; assembles as: movl LZRead(a)GOT(%ebx),%edx movl %edx,-1012(%ebp) so it reads out the address of LZRead out of the GOT. The final result in liblz32.so becomes: 5eb7: 8b 93 44 00 00 00 mov 0x44(%ebx),%edx 5ebd: 89 95 0c fc ff ff mov %edx,0xfffffc0c(%ebp) but because of the -symbolic linker switch, there's no such GOT entry. CRASH! The GOT entry for LZRead should be at 00007d64 in the dynamic relocation table, as far as I can tell from objdump and peeking at the GOT, but in the relocation table there's only this... ... 00007d60 R_386_GLOB_DAT __dso_handle 00007d68 R_386_GLOB_DAT __deregister_frame_info ... What can be done about this? Submit bug reports on ld?

April 26, 2001

Re: Using config.status to recreate current setup

by Francois Gouget

On Wed, 25 Apr 2001, Matthew Cline wrote: > According to the comments at the start of config.status, I can run that file > to recreate the current setup. However, if I use it, it appears to delete > the makefile in wine/dlls/wintrust, causing "make depend" to fail; if I just > copy the configure command that config.status has and run that on the command > line, everything works fine. Am I doing something wrong? It seems to work here. Which version of Wine do you use? When wintrust was added it was missing in some places so that its Makefile was not being run. Maybe there's some remnant of that time in your config.status file or somewhere else in your build system. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

April 26, 2001

Using config.status to recreate current setup

by Matthew Cline

According to the comments at the start of config.status, I can run that file to recreate the current setup. However, if I use it, it appears to delete the makefile in wine/dlls/wintrust, causing "make depend" to fail; if I just copy the configure command that config.status has and run that on the command line, everything works fine. Am I doing something wrong? Thanks in advance. -- Matthew Cline | Suppose you were an idiot. And suppose that matt(a)nightrealms.com | you were a member of Congress. But I repeat | myself. -- Mark Twain

April 25, 2001