headless question, and IPC question

[Ken Larson]

Well I am actually using a command-line with CL to compile it, but it 
was true that I had a WinMain instead of main.

I've changed the WinMain to main, but this doesn't seem to be the issue.

The issue appears to be initializing winsock.  The following simple main 
program, when compiled with CL, and run with wine, requires an X display:


#include <windows.h>
#include <winsock.h>


int main(int argc, const char *argv[])
{
         WORD sockVersion;
         WSADATA wsaData;

         sockVersion = MAKEWORD(1, 1);

         WSAStartup(sockVersion, &wsaData);

}

Remove the call to WSAStartup, and the program requires no X display.

As I said, I know winsock uses hidden windows handles to do some things, 
  which is pretty ugly architecturally.  However, it seems like it 
should be possible to not have a display in this case.  any ideas?

I do like the idea of using winelib and having my wrapper be compiled 
under linux in winelib, but the proprietary DLL I am using also uses 
winsock so I would expect to have the same problem.

Thanks,

Ken


Alex Villací­s Lasso wrote:
> Ken Larson wrote:
> 
>> 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
> 
> It seems that you are using VisualC++ to compile your app. There is a 
> wizard to create a new application, in which the user can select to 
> create a "console app", one that runs from main() instead of WinMain(). 
> Try creating such a skeleton app and running it from Wine. Once you 
> succeed, you can start adding source files from your previous app into 
> the skeleton console app. This would be the "blind" way of doing this - 
> I don't remember much about the options available for creating a console 
> app out of an arbitrary project in VisualC++. I know for a fact that 
> console apps run without an X server in Wine, because I have just tested 
> cl.exe from MS VisualStudio in a raw text console in Linux, after 
> resolving a missing dll.
> 
> If the above *still* does not solve your problem (even after upgrading 
> to the latest Wine CVS), you might try using a virtual framebuffer X 
> server:
> 
> (output of yum xorg-x11-Xvfb):
> Name   : xorg-x11-Xvfb
> Arch   : i386
> Version: 6.8.2
> Release: 37.FC4.49.2
> Size   : 1.6 M
> Repo   : updates-released
> Summary: A X Windows System virtual framebuffer X server.
> Description:
> Xvfb (X Virtual Frame Buffer) is an X server that is able to run on
> machines with no display hardware and no physical input devices.
> Xvfb simulates a dumb framebuffer using virtual memory.  Xvfb does
> not open any devices, but behaves otherwise as an X display.  Xvfb
> is normally used for testing servers.
> 
> You can try installing and configuring this X server. It will not output 
> anything or use a console, but will behave otherwise like a valid X 
> server. Then you should point the DISPLAY environment variable to this X 
> server, and this will keep your app happy. However, I *strongly* 
> recommend to try and create a true console-mode app before trying the 
> virtual-framebuffer X server, because it will consume precious memory.
> 
> Alex Villacís Lasso
> 
> 
> 
>