https://bugs.winehq.org/show_bug.cgi?id=12231 Justin Chevrier <jchevrier(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jchevrier(a)gmail.com --- Comment #15 from Justin Chevrier <jchevrier(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.