https://bugs.winehq.org/show_bug.cgi?id=12231
Justin Chevrier jchevrier@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jchevrier@gmail.com
--- Comment #15 from Justin Chevrier jchevrier@gmail.com --- It appears that Druki IPS will freeze when trying to load the form from the Z: drive. If you copy the form to the C: drive and try to open it from there the app loads the form as expected, or at least it does here.
I have run across another 16-bit application (TFR3000, a custom traffic flow monitoring application) that throws up the same "Operation not supported on selected printer" error message so I did some debugging on this. In my application it was easier to see that:
0027:Call KERNEL.95: LOADLIBRARY(12f7af24 "wineps.drv.DRV") ret=127f:3835 ds=12f7 ... 0027:Call KERNEL32.LoadLibraryA(0077c954 "wineps.drv.drv16") ret=7e8af5d9 0027:Ret KERNEL32.LoadLibraryA() retval=00000000 ret=7e8af5d9
was the cause of the issue.
Both of these applications assume that the supplied printer driver is just a name without extension and indiscriminately append '.DRV' to the supplied printer driver name. In addition, because we return the 32-bit version of wineps (wineps.drv), it won't work in the 16-bit applications anyway. I'm attaching a patch (hack) that detects this and forces loadmodule to load the 16-bit version of wineps (wineps16.drv) instead. I tried hacking around in winspool to modify the code to store 'wineps16' in win.ini and the registry instead of this hack, but I was concerned that switching it in those areas may break 32-bit applications. Maybe someone with more experience in this area can comment. I'm happy to work towards modifying the stored values in win.ini and/or the registry if that's a more correct fix.