http://bugs.winehq.org/show_bug.cgi?id=19400
Summary: Quicken Will Maker 2007 crashes wine Product: Wine Version: 1.1.26 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ToddAndMargo@verizon.net
Hi All,
Just as soon as you start Quick Will Maker 2007, it crashes. I have included the following trace from the FAQ
WINEDEBUG=+relay,+seh,+tid wine qwp.exe &> /home/temp/qwp.trace.txt
-T
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #1 from Todd Chester ToddAndMargo@verizon.net 2009-07-20 21:14:44 --- Created an attachment (id=22490) --> (http://bugs.winehq.org/attachment.cgi?id=22490) Quicken Will Maker 2007 crash trace
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #2 from Andrew Nguyen arethusa26@gmail.com 2009-07-21 18:31:16 --- Created an attachment (id=22517) --> (http://bugs.winehq.org/attachment.cgi?id=22517) Quicken WillMaker Plus 2007 relay log (lzma compressed)
I'm confirming with wine-1.1.26-82-gda86ab7. The backtrace is:
Backtrace: =>0 0xb7cdd07a strcmp+0xa() in libc.so.6 (0x0032f448) 1 0x7dd974d2 PSDRV_ExtDeviceMode+0x22(lpszDriver=0x0, hwnd=0x7dd80000, lpdmOutput=(nil), lpszDevice=0x0, lpszPort=0x0, lpdmInput=(nil), lpszProfile=0x0, dwMode=0) [/home/andrew/wine-git/dlls/wineps.drv/driver.c:338] in wineps (0x0032f508)
Since dwMode is zero, it seems that Quicken WillMaker Plus is trying to query for the size of the driver's DEVMODE structure, but is passing in NULL arguments that wineps.drv expects to be non-NULL. The crash can be worked around by preventing wineps.drv from loading.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #3 from Todd Chester ToddAndMargo@verizon.net 2009-08-05 21:38:13 --- Hi All,
Disabling wineps.drv did indeed stop the crashing. Unfortunately, with it disabled, Word Pro can not see my printer (gives a pop up when Word Pro starts up) and Word Pro can not print.
Is there a way to disable wineps.drv from the command line?
Many Thanks, -T
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #4 from Andrew Nguyen arethusa26@gmail.com 2009-08-05 21:58:30 --- You can either declare the WINEDLLOVERRIDES environment variable or use winecfg to make the setting for wineps.drv app-specific.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #5 from Todd Chester ToddAndMargo@verizon.net 2009-08-05 22:15:03 --- Thank you! My new Xfce launcher string:
sh -c "/usr/bin/aplay -q /home/linuxutil/KDE_Notify.wav; cd /home/wine/drive_c/Program\ Files/Quicken\ WillMaker\ Plus\ 2007; WINEDLLOVERRIDES=wineps.drv=n /usr/local/bin/wine ./qwp.exe"
-T
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #6 from Nate Eldredge nate@thatsmathematics.com 2009-11-07 22:15:37 --- Created an attachment (id=24585) --> (http://bugs.winehq.org/attachment.cgi?id=24585) Quicken Will Maker Plus 2010 log and backtrace
http://bugs.winehq.org/show_bug.cgi?id=19400
Nate Eldredge nate@thatsmathematics.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nate@thatsmathematics.com
--- Comment #7 from Nate Eldredge nate@thatsmathematics.com 2009-11-07 22:20:21 --- Confirmed with wine 1.1.32 (ubuntu 9.04 package) and Quicken Will Maker Plus 2010. Attaching the log.
As suggested, disabling wineps.drv allows the application to run, but printing does not work. This is inconvenient as the whole point of the program is to generate legal documents that you can print out and sign. There is an option to export RTF, but they require manual reformatting as matters such as page breaks are legally significant.
I get the following messages on attempting to print:
err:dc:CreateDCW no driver found for L"WINEPS.DRV" err:dc:CreateDCW no driver found for L"WINEPS.DRV" err:commdlg:PRINTDLG_ChangePrinterA DocumentProperties fails on "lj1200" fixme:commdlg:PRINTDLG_UpdatePrintDlgA No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandA Update printdlg was not successful!
Any suggestions on a fix that could preserve the ability to print? I might start whacking at the relevant functions.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #8 from Nate Eldredge nate@thatsmathematics.com 2009-11-08 09:24:37 --- I added a hack to PSDRV_FindPrinterInfo where, if passed a null pointer for `name', it uses the value from an environment variable instead. The call to ExtDeviceMode then succeeds. The application GlobalAlloc's and GlobalLock's a block of the appropriate size and passes it to FindPrinterInfo with wMode == DM_COPY which also succeeds. It GlobalUnlock's it, and then crashes. Trace attached.
It looks like this time the crash is coming from inside application code, so it may be harder to debug. I will probably keep looking at this when I have a chance.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #9 from Nate Eldredge nate@thatsmathematics.com 2009-11-08 09:26:15 --- Created an attachment (id=24592) --> (http://bugs.winehq.org/attachment.cgi?id=24592) Trace after hack added to make FindPrinterInfo(NULL) work
http://bugs.winehq.org/show_bug.cgi?id=19400
Nate Eldredge nate@thatsmathematics.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24592|0 |1 is obsolete| |
--- Comment #10 from Nate Eldredge nate@thatsmathematics.com 2009-11-08 18:58:50 --- Created an attachment (id=24610) --> (http://bugs.winehq.org/attachment.cgi?id=24610) Trace after hack added to make FindPrinterInfo(NULL) work (the correct version)
Sorry, uploaded the wrong file before.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #11 from Nate Eldredge nate@thatsmathematics.com 2009-11-09 22:28:39 --- After some single stepping I found the problem. PSDRV_ExtDeviceMode is defined as CDECL but the application expects ExtDeviceMode to be STDCALL and pop its own arguments off the stack. The result, obviously, is that the stack pointer isn't where the application expects. What happens is not a crash exactly. The application has some sort of stack sentinel feature which I think is supposed to catch buffer overruns. But the sentinel is addressed relative to esp, so this check fails and it attempts to invoke the debugger.
I wasn't sure of exactly the right way to make the change, but I changed the definition of PSDRV_ExtDeviceMode to
INT WINAPI PSDRV_ExtDeviceMode
and I changed the corresponding line in wineps.drv.spec to
@ stdcall ExtDeviceMode(ptr long ptr ptr ptr ptr ptr long) PSDRV_ExtDeviceMode
The previous change to PSDRV_FindPrinterInfo that causes ExtDeviceMode to do something sensible when lspzDevice is NULL is also needed and still in effect.
After these changes, qwp runs without crashing, and printing works! So maybe someone who knows better than me can implement these changes in a good way and commit.
Another mystery regarding ExtDeviceMode: it is currently defined as
INT WINAPI PSDRV_ExtDeviceMode(LPSTR lpszDriver, HWND hwnd, LPDEVMODEA lpdmOutput, LPSTR lpszDevice, LPSTR lpszPort, LPDEVMODEA lpdmInput, LPSTR lpszProfile, DWORD dwMode)
Some MSDN links I found on Google suggest that the first two arguments should be reversed (google "extdevicemode"). However, qwp calls ExtDeviceMode with a first argument of 0 and a second argument of 0x7db40000, which seems more likely to be a hwnd than a string (it doesn't point to a meaningful looking string either). I wonder if there is some more authoritative documentation available, which might also confirm which calling convention is to be used. Perhaps if so, the other functions in wineps should be checked as well.
It might also be good if there is documentation that can be checked about the correct interface for
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #12 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-09 23:03:16 --- Except ExtDeviceMode is not declared as WINAPI in PSDK. So it could be application's bug:
LONG ExtDeviceMode( IN HWND hWnd, IN HANDLE hInst, OUT LPDEVMODEA pDevModeOutput, IN LPSTR pDeviceName, IN LPSTR pPort, IN LPDEVMODEA pDevModeInput, IN LPSTR pProfile, OUT DWORD fMode );
Where you right is the order of the parameters. Indeed Wine's declarations is: INT CDECL PSDRV_ExtDeviceMode( LPSTR lpszDriver, HWND hwnd, LPDEVMODEA lpdmOutput, LPSTR lpszDevice, LPSTR lpszPort, LPDEVMODEA lpdmInput, LPSTR lpszProfile, DWORD dwMode);
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #13 from Nate Eldredge nate@thatsmathematics.com 2009-11-09 23:28:33 --- Hmm. Well, have a look at the following article: http://support.microsoft.com/kb/112641
It appears that ExtDeviceMode doesn't have a prototype. Instead, you are supposed to get its address from GetProcAddress (FWIW, that's what this application does) and cast it to type LPFNDEVMODE. I don't know how LPFNDEVMODE is defined, and I didn't find documentation for it, but it could be that it is a pointer to a stdcall function. Would it be kosher to examine the Windows header files to find out? Or alternatively, to compile and execute some code on a Windows machine to see what it does?
I'm inclined to suspect that stdcall is correct, because the application runs correctly under Windows (at least I assume it does, I don't have a real Windows box to test, but it's a well-regarded commercial app so I assume it isn't totally broken ;-). If it tried to call this function using the wrong calling conventions it would surely crash or otherwise fail (e.g. the stack sentinel I mentioned). So either the documentation is wrong and it is in fact stdcall, or the application has got it wrong but for some reason under Windows the erroneous code never runs (seems unlikely).
Similar issue with respect to the first two arguments. The documentation disagrees with what Wine does, but it looks like the application is expecting Wine's behavior (though I don't know enough to be sure). Again, could we check what real Windows does, in case it is misdocumented?
Thanks for looking at this. I'm new to wine hacking and it's good to have someone else thinking about the issue.
http://bugs.winehq.org/show_bug.cgi?id=19400
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev@web.de
--- Comment #14 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-10 00:16:53 --- (In reply to comment #13)
I don't know how LPFNDEVMODE is defined
typedef UINT (CALLBACK* LPFNDEVMODE)(HWND, HMODULE, LPDEVMODE, LPSTR, LPSTR, LPDEVMODE, LPSTR, UINT);
but it could be that it is a pointer to a stdcall function.
Indeed: #define CALLBACK __stdcall
Would it be kosher to examine the Windows header files to find out?
See above.
Or alternatively, to compile and execute some code on a Windows machine to see what it does?
This would be better. PSDK headers had issues, especially when it comes to poorly documented areas. And as you see here they do conflict as well.
Similar issue with respect to the first two arguments. The documentation disagrees with what Wine does, but it looks like the application is expecting Wine's behavior (though I don't know enough to be sure).
Can't tell you much here, except that Wine doesn't use what it thinks first parameter -lpszDriver. And second (hwnd) won't affect anything if it's wrong. Should be easily verifiable with +psdrv trace looking at the first two params of the PSDRV_ExtDeviceMode() call.
Also adding Detlef he might have some insight on this.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #15 from Nate Eldredge nate@thatsmathematics.com 2009-11-10 18:36:36 --- Okay, so to summarize, there are three issues.
1. PSDRV_ExtDeviceMode is declared as CDECL, but MS KB says it should be CALLBACK (because it should be called through a pointer of type LPFNDEVMODE) and qwp.exe seems to expect this too. I think they are right and this is a wine bug. I'd submit a patch but I'm not sure of exactly the right way to update the specs file, or if any other changes are needed. (If nobody else does this I'll attach a patch anyway, just for posterity and so that people can run this application.)
2. qwp.exe calls ExtDeviceMode with lpszDevice == NULL and dwMode == 0, expecting to get the size of a buffer for a DEVMODE. This looks like a bug in qwp since this behavior is nowhere documented to work; you are supposed to pass a device name for lpszDevice. This can be worked around in wine either by having it fill in an appropriate device name somehow (e.g. environment variable) or just by having it return an arbitrary "large enough" size. Someone with a Windows box might test what Windows does (sample code at http://support.microsoft.com/kb/112641 could be adapted), and if we can understand it we could try to match its undocumented behavior.
3. Meaning of the first two arguments to ExtDeviceMode is in question.
MSDN (http://msdn.microsoft.com/en-us/library/aa506558.aspx) says: LONG ExtDeviceMode(IN HWND hWnd, IN HANDLE hInst, [...]). Arguments described as:
hWnd Handle to the parent window for the printer-configuration property sheet. hInst Not used. Handle to the module instance of the device driver.
KB (http://support.microsoft.com/kb/112641) says ExtDeviceMode(hWnd, hDriver, [...]). hDriver is a value returned by LoadLibrary().
Wine has PSDRV_ExtDeviceMode(LPSTR lpszDriver, HWND hwnd, [...])
FWIW, qwp calls ExtDeviceMode from two places. The first time it does:
ExtDeviceMode(0, 0x7db40000, [...])
where 0x7db40000 is a value returned from GetModuleHandleA. This is maybe consistent with the MSDN definition.
The second time it does:
ExtDeviceMode("WINEPS.DRV", 0, [...])
which really doesn't make much sense at all.
On the other hand, qwp seems to work fine with the wine code as it is. So maybe it is not worth fixing what isn't broken, if we don't understand how it ought to be anyway.
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #16 from Nate Eldredge nate@thatsmathematics.com 2009-11-14 20:10:40 --- Created an attachment (id=24744) --> (http://bugs.winehq.org/attachment.cgi?id=24744) Patch that lets Quicken Will Maker Plus 2010 run
This patch implements the fixes and workarounds discussed. It changes PSDRV_ExtDeviceMode to be declared as CALLBACK instead of CDECL. It also makes it so that when PSDRV_ExtDeviceMode is called with lpszDevice == NULL and dwMode == 0, it returns the "large enough" size 65536. With this fix, Quicken Will Maker Plus 2010 runs without any special settings needed, and printing works.
http://bugs.winehq.org/show_bug.cgi?id=19400
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=19400
--- Comment #17 from Austin English austinenglish@gmail.com 2013-11-13 16:50:46 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=19400
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #18 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=19400
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org