Alex -
Thanks for the good info. As far as not needing an X server, when I try to run my exe under wine without one, I get:
wine: Could not load graphics driver 'x11drv'. Make sure that your X server is running and that $DISPLAY is set correctly.
but yes, the regedit /? trick works fine.
I wonder if there is something obvious I'm missing in the compilation and linking of my EXE? Where might I look to make sure it doesn't think it needs a display.
My exe and the wrapped DLL do use sockets and I know that sockets in windows often need a window handle to do their thing...
My DLL is a true DLL as far as I know, I currently link to it using the accompanying .lib, but I think I could link dynamically to it.
Ken
Alex Villacís Lasso wrote:
Ken Larson wrote:
I'm using wine to access a particular proprietary DLL (I don't have the source for it) on Linux. The way I'm doing this is to write an EXE that wraps the DLL, and makes all of the functions available via socket request and response messages. My linux program has access to the functions of the DLL by sending socket messages to the EXE running under wine. 2 questions:
- My DLL/EXE uses no calls to pop up graphical windows, so
theoretically no display is needed. Of course wine needs a display because it does not know that an EXE won't make such calls. Is there a way to run wine with a null or dummy display - so that it is effectively running headless?
- The sockets trick was the simplest way I could figure out how to do
IPC between a linux process and a wine process. However, is there are any better or faster way to do this? As far as I know I can't use winelib because I don't have the source to the DLL.
Thanks,
Ken Larson
If your program is a console-only app, it can run without an X server. For example, the command "regedit /?" works without defining a DISPLAY variable, even in a text console. If you write interesting information to a logfile instead of the screen, you could even do "wine wrapper.exe &" on the shell and put your app in the background.
About winelib, you could try making a winelib app that loads the DLL dynamically. But this would only work for a true DLL (for example "propietary.dll") on which you can call LoadLibrary(). If your library is a static one such as "propietary.lib", with no companion DLL file to load, then all the interesting code is in the LIB file itself and cannot be loaded dynamically.
About faster communication, you could try running the Linux app, which would fork(). One process runs your GUI or sets up your service, and the other could then exec() the winelib wrapper. Before the fork, you should set up a pair of pipes, or use socketpair() for communication. If you are careful, this can even work for a pure Windows app linked with a static LIB file, by connecting your pipe/socket to the stdin/stdout of the wine process (see the manpage on dup2() for details).
Hope this helps.
Alex Villacís Lasso