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. > > 2) 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