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
