Hi list.
A friend of mine and myself, have been exploring expanding a (currently, 32bit only) winelib app to support 64bit plugins in wine (64). The app is called FSThost, which is used to host win32 VST instruments and effects (.dll) as a standalone app in Gnu/linux. Webpage: http://sourceforge.net/projects/fsthost/
We currently have a example/test app in the source code, which compile as test64.exe / test.exe.so ... you then use the exeutable 'foo'. ~ in this case 'foo' could be /path/to/your/64bitVSTplugin. Currently, the code fails to load the 64bit dll. We are not sure exactly why it is failing, but suspect a couple of reasons. this is where we at at;
1) LoadLibrary - OK 2) GetProcAddress (get address of VSTPluginMain function from DLL library) - OK 3) Initialize plugin - i.e. call VSTPluginMain function from library - FAIL.
Potential reasons: - Vestige mismatch - Wine GetProcAddress on 64 bit platform
My friend thought someone more familiar with Wine / WinAPI could take a look on this 64bit DLL and at least confirm that address returned by GetProcAddress is correct. (or give us good tips and/or adive). Since, i am already subbed (to wine-devel), i thought i would see if any one was interested in having a look and/or giving us some pointers, tips, etc.
Here's an example (with WINEDEBUG="+relay'), full ouput: http://pastebin.com/5b5srr2a
A little snippet: 0042:Call ntdll.RtlEncodePointer(002c4620) ret=18002d9aa 0042:Ret ntdll.RtlEncodePointer() retval=c90b263e5a54eb02 ret=18002d9aa 0042:Ret PE DLL (proc=0x18002f27c,module=0x180000000 L"Automaton.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0042:Ret KERNEL32.LoadLibraryA() retval=180000000 ret=7f77bb394167 0042:Call KERNEL32.GetProcAddress(180000000,7f77bb3950b0 "VSTPluginMain") ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182 Revive plugin: Automaton 0042:Call KERNEL32.UnhandledExceptionFilter(0023e7f0) ret=7f77bbf1fc1a wine: Unhandled page fault on read access to 0x0000022f at address 0x22f (thread 0042), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module
(goto pastebin for the rest / just scroll to bottom of page)
If you want to take a look and/or test the code yourself (you need latest code): svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code
the source tree is small (like 2 seconds to download). Makefile64 is used to compile the test app (test.c). (just use 'make -f makefile64' from /src dir). alternatively, on sourceforge you can view the test64 app / source code online / here; http://sourceforge.net/p/fsthost/code/154/
(there are several commits following this one, but i believe this one is the most relevant.
then to run it (from source dircetory); './test64.exe /path/to/64bitVSTplugin
You can get a 'tester' 64bit VST (.dll) to load into test64.exe from here: http://kunz.corrupt.ch/products/tal-elek7ro
anyway, any of your insights, help, tips, comments, etc would be both appreciated and helpful.
thanks.
Jordan
Given that Wine uses winelib for its builtin exe's and dll's, and that the way it works is not much different from a PE exe or dll, I don't think winelib is likely to be at fault here. My guess is that you are running into an ordinary Wine bug relating to your specific dll (and probably Wine's 64-bit support, since that's a little-used feature).
I think the best thing you can do is file a Wine bug and simplify your test case as much as you can.
Are there any freeware 64-bit Windows programs that would be able to load your plugin dll? If so, do they work in Wine?
How hard would it be to write a simple program that does just enough to reproduce the crash? If that works, you could recompile it as a PE exe and see if that makes a difference (I don't think it will).
Do you have the source code of the dll that crashes? If not, maybe you should write your own stub plugin that you can compile for 64 bits. That way, you can at least verify that you ported your application correctly, and that it can work for a 64-bit dll that's not affected by Wine bugs.
Hey Vincent,
First thank you for your input :)
On Mon, Apr 1, 2013 at 11:57 AM, Vincent Povirk madewokherd@gmail.com wrote:
Given that Wine uses winelib for its builtin exe's and dll's, and that the way it works is not much different from a PE exe or dll, I don't think winelib is likely to be at fault here. My guess is that you are running into an ordinary Wine bug relating to your specific dll (and probably Wine's 64-bit support, since that's a little-used feature).
Well, do you have any recommendations on how to debug this further, to know whether or not that is the case? (bug in Wine64). Many of the 64bit VSTs/DLLs that i load into our test64.exe (winelib app) can be loaded into SAVIHOST (64bit) and run just fine in Wine64 ~ they just aren't useful, since i need jack-audio-connection-kit support, but do not crash either.
So i don't think this is a case of Wine's 64bit support being poor. ~ i have run many 64bit proaudio apps in Wine, before even attempting/exploring trying to support it in FSThost. ie: I've tested several dozen 64bit apps or 64bit dlls hosted by SAVIhost, none of them crashed.
I think the best thing you can do is file a Wine bug and simplify your test case as much as you can.
Are there any freeware 64-bit Windows programs that would be able to load your plugin dll? If so, do they work in Wine?
You've got it backwards, we are laoding 64bit dlls into our app, not the other way around. But as explained above, Yes, the 64bit VSTs (.dll) do load in SAVIhost 64 ~ and 'standalone versions of various plugins (ie: an .EXE not .DLL). Also run in 64bit Wine.
How hard would it be to write a simple program that does just enough to reproduce the crash? If that works, you could recompile it as a PE exe and see if that makes a difference (I don't think it will).
I'll look into this. It doesn't sound hard to do.
Do you have the source code of the dll that crashes? If not, maybe you should write your own stub plugin that you can compile for 64 bits. That way, you can at least verify that you ported your application correctly, and that it can work for a 64-bit dll that's not affected by Wine bugs.
I might be able to get source code for a 64bit VST/dll - but ideally, i need the one's that don't have any source code to run ;)
I'll look into this as well / pass on the info.
Thanks.
Jordan
PS: if anyone else has comments, tips, etc - don't hesitate to jump into the conversation! ;)
probably Wine's 64-bit support, since that's a little-used feature).
This is a little off-topic from the original thread, but I think 64-bit Wine works pretty well. Our ArcGIS Server on Linux is exclusively 64-bit and is in use by some large organizations
Hi Daniel
This is a little off-topic from the original thread, but I think 64-bit Wine works pretty well. Our ArcGIS Server > on Linux is exclusively 64-bit and is in use by some large organizations.
..and those 'large organizations' are not the only one's out there using Wine64. ;)
I think people generally still think of Wine's 'current status' as being that of 2008-2010. But i think Wine has improved quite a bit since that time. I know that for my machines, i am using a win64/wow64 prefix ~ even if i do tend to be using 32bit applications, because of the limitations of apps that i rely on, only having access to jack-audio-connection-kit via WineASIO (32bit only, no 64bit port, yet) and FSThost - also 32bit...
But, I still do in fact, use a wine 64bit prefix. i have/do run windows 64bit apps on my machines, they seem to run okay. i have even produced sound out of them. ~ but since i do not have an ALSA soundcard and use FFADO (firewire audio interface). In order to test ALSA in Wine, I had to use a 'alsa to jack' wrapper/bridge -> more specifically zita-a2j. the sound was bit choppy (as expected in this case) and only really useful to test to see if the 64bit apps would produce sound, accept midi input, etc and not crash.... But obviously, the whole point here, is to port FSThost to 64bit, so that we can use windows 64bit VSTs, natively with Jack/linux.
NOTE: I forgot to explain what 'SAVIhost' is, in my post to you Vincent... SAVIhost is a windows application for hosting VSTs (.dlls) as standalone apps. The 64bit version of SAVIhost does load the 64bit VSTs in Wine64. (but again, not of much use beyond that, since our ASIO driver, WineASIO doesn't have a 64bit port).
SAVIhost: http://www.hermannseib.com/english/savihost.htm
(64bit versions, halfway-to-bottom ofthe page, you also need Microsoft Visual C++ 2008 SP1 Redistributable Package (x64) also found on page),
So clearly, the windows app can load the 64bit VSTs / dll just fine (in Wine64), while in FSThost (so far) we are failing... So, I guess my original question still stands;
Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe??
I've also heard from my friend, he doesn't think it has anything to do with our vestige headers, which was the other possibility / conclusion we came to as a potential issue.
thanks for everyone's input so far.
Jordan
Am 01.04.2013 19:56, schrieb jordan:
Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe??
I doubt that's the problem, but to really confirm it i'd need a: winedump -j export yourvst.dll
Hi Andre,
Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe??
I doubt that's the problem, but to really confirm it i'd need a: winedump -j export yourvst.dll
Okay, I am trying to load Automation.dll with our test64.exe ... Here is the output from winedump on Automation.dll;
winedump -j export '/home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll' Contents of /home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll: 773120 bytes
Exports table:
Name: Automaton.dll Characteristics: 00000000 TimeDateStamp: 4EFB9DFA Wed Dec 28 17:53:46 2011 Version: 0.00 Ordinal base: 1 # of functions: 2 # of Names: 2 Addresses of functions: 00062858 Addresses of name ordinals: 00062868 Addresses of names: 00062860
Entry Pt Ordn Name 00012900 1 VSTPluginMain 00012900 2 main
Done dumping /home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll
..now, if you doubt this is the issue, do you have any recommendations / suggestions on what might be the problem?
Thanks.
Am 01.04.2013 20:28, schrieb jordan:
Hi Andre,
Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe??
I doubt that's the problem, but to really confirm it i'd need a: winedump -j export yourvst.dll
Okay, I am trying to load Automation.dll with our test64.exe ... Here is the output from winedump on Automation.dll;
...
Entry Pt Ordn Name 00012900 1 VSTPluginMain 00012900 2 main
so with:
0042:Call KERNEL32.GetProcAddress(180000000,7f77bb3950b0 "VSTPluginMain") ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182
it looks as expected :)
..now, if you doubt this is the issue, do you have any recommendations / suggestions on what might be the problem?
Same as Vincent, do what he told you.
Hi Andre,
Entry Pt Ordn Name 00012900 1 VSTPluginMain 00012900 2 main
so with:
0042:Call KERNEL32.GetProcAddress(180000000,7f77bb3950b0 "VSTPluginMain") ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182
it looks as expected :)
Okay, so that is ruled out and i learned something in the process. (thanks!)
..now, if you doubt this is the issue, do you have any recommendations / suggestions on what might be the problem?
Same as Vincent, do what he told you.
Okay, I'll look into that then. Thanks again :)
Jordan
-
André Hentschel -
Daniel Lehman -
jordan -
Vincent Povirk