| thingkcp |
Monday 15 July 2013 at 18:29
|
thingkcp
|
I'm trying to run a proprietary program called Snap in Wine using POL. I am running Ubuntu 12.04 with KDE.
I have a number of versions of this program. Version 9 works fine in POL as long as I set the Wine version to 0.9.61. If I try to use a later version the program does not crash but will not function: if I try to do anything that involves opening a MDI window it just says 'Cannot open window'.
After much digging I have established the following:
1. The program works ok with Wine versions up to 1.1.15 but fails for 1.1.16 and higher. 2. The problem lies with user32.dll: if I copy user32.dll from Wine 1.1.15 to 1.1.16 the program works ok.
The difficulty for me is that Snap9 is out of date - they are up to Snap11 now - and later versions need features of Windows that cannot be installed in Wine 1.1.15.
I know that it is not possible to override user32.dll, so I am a bit stuck. I'm posting here on the off chance that someone might know more about this topic than I do (which would not be difficult):
- Is there any information anywhere on what changed in user32.dll from Wine 1.1.15 to 1.1.16?
- Given the fact that Snap does not throw an error that would show in the POL debug log, is there any way I can get it to tell me exactly what it is not happy with?
- If I could somehow locate the problem, would I be able to compile my own version of user32.dll?
Just for the record, Snap9 works fine in Windows (I have version 7 but it also runs in earlier versions).
Any ideas would be most welcome.
|
| Ronin DUSETTE |
Monday 15 July 2013 at 18:46
|
Ronin DUSETTE
|
You need to download the wine source code from winehq.org, and make a patch for it. You dont override that, as its not from windows, but a special wine version of user32.dll. You can turn on more debugging symbols from the command line. http://www.winehq.org/docs/winedev-guide/dbg-controlIf you go through that dev-guide on their site, you will find a lot of information, but in order to write a patch, you need to be fluent in C++ If it works in Windows 7, you may need to install .NET and a few other things, as well. Post the full debug output for that, and lets see if anything relevant is hiding in there.
|
| petch |
Monday 15 July 2013 at 19:53
|
petch
|
Changelog: http://www.winehq.org/announce/1.1.16 To investigate further, you could grab yourself the sources of Wine as DJYoshaBYD said (see http://wiki.winehq.org/GitWine) on a system you can easily compile its sources on (32bit system preferred, can be a VM). There have been 476 commits between 1.1.15 and 1.1.16 (git log wine-1.1.15..wine-1.1.16|grep '^commit '|wc -l), 29 involving files below dlls/user32/ (git log wine-1.1.15..wine-1.1.16 dlls/user32|grep '^commit '|wc -l). Using git bisect you should be able to pinpoint a problematic commit in 9 or 10 recompilations (there could be more than one). That said, 1.1.16 is old (Feb 2009), the commits won't apply on recent versions without serious massaging, if at all... Edited by petch
|
| Ronin DUSETTE |
Monday 15 July 2013 at 20:41
|
Ronin DUSETTE
|
Oh yeah. If you do compile from source, you HAVE TO compile it on the arch your trying to build it for. A simple chroot environment in 32 bit form will work fine for that. Thats how I build mine.
|
| thingkcp |
Tuesday 16 July 2013 at 0:46
|
thingkcp
|
Oh yeah. If you do compile from source, you HAVE TO compile it on the arch your trying to build it for. A simple chroot environment in 32 bit form will work fine for that. Thats how I build mine.
Thanks both for your help on this. At the moment I'm a long way away from being able to compile a patched version of user32.dll. It's taken me a long time just to narrow the problem down to this dll - it would be easier if Snap would just crash :-)
Snap9 does not need .NET (later versions do). I have a working installation in Wine 1.1.15 and a working version in Wine 1.1.16 with user32.dll copied over from 1.1.15. I'm sort of hoping that if I can work out why the newer dll fails then I can find a workaround (possibly with the assistance of the Snap developers).
I've been trying various WINEDEBUG flags with POL, most of them generate a huge amount of output whether the program fails or not. I can't find a way to show only where user32.dll returns an error. The best I have managed so far is to set +msgbox,+relay. At the crucial point where Snap fails to open a window the log shows the following:
0009:Call dialog proc 0x7eca0340 (hwnd=0x2003c,msg=WM_SETTEXT,wp=00000000,lp=0032ceb4) 0009:Ret dialog proc 0x7eca0340 (hwnd=0x2003c,msg=WM_SETTEXT,wp=00000000,lp=0032ceb4) retval=00000000 result=00000000 0009:Ret window proc 0x7ec59d30 (hwnd=0x2003c,msg=WM_SETTEXT,wp=00000000,lp=0032da84) retval=00000001 0009:Ret user32.CallWindowProcA() retval=00000001 ret=7c173adb 0009:Ret window proc 0x7c173a6e (hwnd=0x2003c,msg=WM_SETTEXT,wp=00000000,lp=0032da84) retval=00000001 trace:msgbox:MSGBOX_OnInit L"Cannot open window"
I'm a bit out of my depth here, as you will have noticed, but I'm guessing that those two instances of retval=00000001 indicate that something has gone wrong.
|
| Ronin DUSETTE |
Tuesday 16 July 2013 at 1:05
|
Ronin DUSETTE
|
ok, so, like I said, you cannot switch out the user32.dll like that. Thats not how it works. If 1.1.15 works, then you need to grab the source code for the user32.dll file, and compare it to what you are trying to use, and see where the difference is, merge the code (using diff to tell whats changed) from one to the other, recompile, and hope it works.
It's taken me a long time just to narrow the problem down to this dll Again, Im going to emphasize that you cannot really just swap that out. There are a bunch of source files that create that dll, so you need to find out what is different with those sources and use diff to create a patch. The wine development pages are a great place to start learning about that. It will actually explain what all of that dialog means. http://www.winehq.org/docs/winedev-guide/index
|
| thingkcp |
Tuesday 16 July 2013 at 10:05
|
thingkcp
|
ok, so, like I said, you cannot switch out the user32.dll like that. Thats not how it works.
Thanks again for your help. I realise that I can't solve the problem by swapping the versions of user32.dll; that was just a diagnostic test which showed me that it was precisely in there that the problem was occurring.
As far as I can see at the moment, Snap9 makes calls to user32.dll in order to open MDI windows, and these calls return valid responses in 1.1.15 but invalid (or unusable) responses in 1.1.16 and later. It's worth noting that other features, such as menus and dialog boxes, work fine in both versions.
As you say, I'm going to have to learn how to compile my own user32.dll from the sources and trace the change that stops Snap9 from working. Where I go after that is another matter, but I'll cross that bridge when I get to it. |
| Ronin DUSETTE |
Tuesday 16 July 2013 at 20:31
|
Ronin DUSETTE
|
Word. :) Again, its not too hard to compile software once you do it a few times.
|
| thingkcp |
Wednesday 24 July 2013 at 15:42
|
thingkcp
|
Ok, I have made some progress on this.
1. I have identified the commit (between wine-1.1.15 and wine-1.1.16) that causes Snap to fail.
2. I have successfully compiled the latest stable version of Wine (1.6) on my machine.
What I need to do now is install Snap under this version of Wine and test it. If it fails, as I suspect it will, I can try applying a patch. However, I do not want to install the latest version of Wine on my system - instead I want to install it in PlayOnLinux so that I can use it for a separate wineprefix. Is there any way I can do this?
|
| petch |
Wednesday 24 July 2013 at 17:13
|
petch
|
Just use ./configure --prefix=$HOME/.PlayOnLinux/wine/linux-x86/1.6-myversion (or whatever name you want) so that make install puts it in the right place... That should be all
|
| Ronin DUSETTE |
Wednesday 24 July 2013 at 20:09
|
Ronin DUSETTE
|
|
| thingkcp |
Wednesday 31 July 2013 at 16:21
|
thingkcp
|
Thanks for the advice on installation. I have now finally traced and fixed the underlying problem. It turns out it was not the commit I thought it was, but another one between 1.1.15 and 1.1.16 that altered the system menus. To trace it I had to persuade wine to compile completely right back to 1.1.15.
I now have a simple patch that makes 1.6 work with Snap.
The offending commit is already the subject of a bug report that is still open (http://bugs.winehq.org/show_bug.cgi?id=21879). The patch recommended there does not work for me, but does not conflict with my own patch. I'm going to file a bug report.
I'll see if I can install my own version for POL using your instructions.
|
| Ronin DUSETTE |
Wednesday 31 July 2013 at 16:24
|
Ronin DUSETTE
|
Word. Make sure that you: ./configure --prefix=$HOME/.PlayOnLinux/wine/linux-x86/1.6-myversion when you do it, so it installs it properly, and so its available in POL. If it works well for you, we can get a feature request and pull request open to get this built and added to the list of wine versions in our repository.
|
| thingkcp |
Wednesday 31 July 2013 at 16:54
|
thingkcp
|
Yes, that works. Thanks! I now have Snap working on POL on wine-1.6.
I'm not sure I am quite ready to submit my patch, though. A side-effect of the patch is that the system menu on MDI client windows has two menu items labelled 'Next'. Not quite sure why.
The next mountain I have to climb is to get more recent versions of Snap working. The one I have working is version 9 and they are up to 11 now. The later versions require things like Visual C++ and .NET. With my patch, Snap10 installs and mainly works, but there are problems with some key dialog boxes. That's another story, though.
I'll get back to you when/if I can work out how to avoid the duplicate menu item.
|
| Ronin DUSETTE |
Wednesday 31 July 2013 at 17:07
|
Ronin DUSETTE
|
visual C++ is not an issue at all. You can install that through wine and it will work fine. Also, wine-mono actually has almost full compatibility (according to version 2.10.8 on mono's website), and comes installed with 1.6 (if it didnt install, you can force it), as well as the fact that if that doesnt work, this version of wine has been optimized for .NET 4.0. If you want to try .NET 4 in there, you will need to remove wine-mono from: playonlinux -> Configure -> select virtual drive -> Wine -> wine uninstaller -> uninstall wine-mono Then install .NET 4 into that virtual drive and see if that helps. What are the dialog boxes doing? Post your debug output from that virtual drive, as well, so that we can see what its doing. Hopefully you compiled it with all of the needed dependencies (you should always run sudo apt-get build-dep before building). Also, I hope you built if for 32 bit (in an actual 32 bit environment), as they never build right in mixed environments (building 32 bit on a 64 bit system). when you did ./configure blahblahblah did it give errors saying that you are missing build dependencies?
|
| thingkcp |
Wednesday 31 July 2013 at 18:47
|
thingkcp
|
All sorted, I think.
I installed .NET 2 and 3, with Service Packs, and vcrun100, and both Snap 10 and Snap 11 installed ok and seem to be running properly. The dialog boxes are working now (the original problem was that some fields were inaccessible, but that problem has gone away now that I have installed the necessary libraries). My mountain turned out to be a molehill.
I did not get any missing dependencies with my Wine build, at least not after installing the build dependencies for Wine 1.4 and libhal-dev. ./configure did not come up with any problems. The compilation of wine 1.6 with my patch seems to run fine and the install to POL has worked.
Running Snap9 gives the following output from the debugger:
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0x86e654 0x86e644
fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0x86e650 0x86e640
fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0x86e650 0x86e640
fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0x86e694 0x86e684
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0x86e654 0x86e644
No major problems there as far as I can see.
The only glitch I have left is that POL complains on startup that it can't find the OpenGL libraries. I think that started when I installed libhal-dev. I am reluctant to try to fix that because I don't want to break anything. Recently I made a change to my display settings and ended up having to re-install Ubuntu, so I don't want to tinker as long as things are working.
|
| Ronin DUSETTE |
Wednesday 31 July 2013 at 18:53
|
Ronin DUSETTE
|
Dont reinstall your system. This isnt windows :) If it cannot find those libraries, you will not have graphic acceleration. Reinstall your graphics cards drivers with the newest ones from the manufacturers website, and if asked during install, make sure you install the 32 bit libraries, as well (Nvidia installs do ask this). After restart of your computer, you shouldnt see those errors anymore. The err CoRelease stuff is .net based, but if its not causing errors, I wouldnt worry about them. I believe thats an InstallShield error, but if it installed fine then dont sweat it.
|