Hello,
I would like to run some of our (win32-based) applications under Linux using Wine. At this time it is only for my personal use, but maybe someday some of our users will like to have it on Linux like me.
I have managed to get all of them running, showing at least first dialog/window. But there are some problems:
1) User interface stuff. We are using dialogs (MFC CDialog) that have non-default font size (i.e. Times New Roman, 12 ). The font is displayed correctly under Wine, but dialog window has wrong size (it's smaller and some parts of dialog, mainly buttons at bottom, are not visible). I can send more info on this. How to solve this problem (other way than detecting Wine and resizing window manually) ?
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 ?
3) Windows service. We use a windows NT service (which can easily be ported to Linux,btw), an application communicates with the service using named pipe. Is it possible to communicate from "wined" application with some Linux program using technique other than TCP or Unix socket ? If no - is it possible to open Unix socket from our win app ?
Hi Martin,
- User interface stuff. We are using dialogs (MFC CDialog) that have
non-default font size (i.e. Times New Roman, 12 ). The font is displayed correctly under Wine, but dialog window has wrong size (it's smaller and some parts of dialog, mainly buttons at bottom, are not visible). I can send more info on this. How to solve this problem (other way than detecting Wine and resizing window manually) ?
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.
- 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.
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?
- Windows service. We use a windows NT service (which can easily be
ported to Linux,btw), an application communicates with the service using named pipe. Is it possible to communicate from "wined" application with some Linux program using technique other than TCP or Unix socket ? If no - is it possible to open Unix socket from our win app ?
It's certainly possible to open a Unix socket from a winelib app. (Wine itself does so.) Using a named pipe from a regular (not winelib) Linux app won't work.
Hope that helps, --Juan
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
Having two versions of Win32 executable is IMHO not very practical, as 99% of the code would be same for both applications.
That wasn't exactly what I intended. You said in your original email,
We use DLL that depends on some Win32 drivers.
My question is, could you ship a Linux version of this DLL (.so) that calls the Linux drivers instead?
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.
You can't exactly. If you make your app a winelib app, then you can, but you won't be able to link such a beast for Windows, that is, as a .exe rather than a .exe.so.
Again, my suggestion is to have a Windows version of the DLL that calls the Windows drivers, and a Linux version of the same .dll that is a winelib dll (.dll.so) that calls the Linux drivers. The rest of the code would remain the same, but you could either install the appropriate version depending on whether you're running in Linux, or use some DLL override magic to specify which to use in Wine.
Hope that helps, --Juan
-
Juan Lang -
Martin Hinner