headless question, and IPC question

Ken Larson x1 at larsontechnologies.com
Thu Sep 29 15:46:22 CDT 2005

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.


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:
>> 1. 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?
>> 2. 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

More information about the wine-devel mailing list