Hi,
Please open a bug at our bugzilla (bugs.winehq.org). Attaching screenshots of the problem would help. We discourage you from working around Wine bugs, because if we fix the bug, we'll break your app in the process. Better to fix Wine.
I 100% agree, but I wasn't sure if wine team is willing/able to help with this. Will do.
- Windows drivers. We use DLL that depends on some Win32 drivers.
Linux driver is available with similar API, so it's not a big problem to change our application to use Linux library. I understand that clearest way how to solve this problem is to make .dll.so file, but it's quite complicated for this particular application and I would prefer much more to add few if conditions to our Windows code that would recognize Wine under Linux and load native .so file (not .dll.so!). Is this possible? How to deal with different calling conventions between gcc and Visual C++ 2003 ?
I'm not sure what you mean by different calling conventions; gcc supports the __stdcall convention, at least, and VC++ supports __cdecl. If you're using __fastcall you'll need to change it to one of the others, I think.
Unfortunately I cannot change calling convention for one of DLLs as it's closed-source 3rd party file.
As far as detecting Wine, again we prefer you don't. Would it be any great problem to ship a Linux version that called the Linux drivers, and a Windows version that called the Windows drivers?
Having two versions of Win32 executable is IMHO not very practical, as 99% of the code would be same for both applications.
The original question was about loading Linux .so files directly from .exe. How do we load (dlopen, dlsym) a .so library from .exe running under Wine ? This would solve our problem.
Martin