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