September 2005 - Wine-Devel

Re: headless question, and IPC question

by 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 > > > >

Sept. 30, 2005

Re: freedce-win32 - progress!

by Jakob Eriksson

Luke Kenneth Casson Leighton wrote: >i am making the "amateur" version of progress: i just had >echo_server.exe run for the first time on win32: echo_client.exe >has been running successfully since this morning. > > That's really great! //Jakob

Sept. 30, 2005

Off-topic, Was: Re: headless question, and IPC question

by Jakob Eriksson

Alex Villacís Lasso wrote: > > > 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. > You can also run a VNC server on the virtual X server. Then you can leave and connect to your session from any client computer, without shutting down your running X programs. regards, Jakob

Sept. 30, 2005

WWN: Rpm's for Fedora Core 4

by Dieter Komendera

Hi people, I read in the today's Wine Weekly News something about rpms for Fedora Core 4. In august I begann building some for FC 4. I built rpm's for the july and the august version. The rpm's were based on Vincent Beron's. They were downloaded about 700 times from my server. There is also a mirrorserver that also hosts my rpms. In fedoraforums.org just one guy reported a problem with the rpm. They can be downloaded here: http://komi.bluezones.org/wine/fc4/ I'll build also rpms for the coming cvs drop out. In this, I will take care of things I read in the WWN. Any comments, improvements, suggestions are very welcome! Regards, Dieter Komendera

Sept. 30, 2005

Subject: Re: Newsleecher Installer Failing

by josephblack

For information on debugging, these official docs may help http://www.winehq.org/site/docs/wine-devel/debugging http://www.winehq.org/site/docs/wine-devel/index http://wiki.winehq.org/DebuggingTutorials there is an unofficial list of examples from the mailing lists, here. http://wine-wiki.org/index.php/Debugging_Wine if you see or think of something that could be added to the official documents - please send a suggestion to the wine-devel list. -- Joseph Black

Sept. 30, 2005

Re: Problem Resolve

by Rob D

At 09:40 AM 9/29/2005, Brian Vincent wrote: >On 9/29/05, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > > That said, it seems a bit rude that the 20050830 CVS drop is *still* > > on the front page of http://www.winehq.com/, even after everyone knows > > that it's missing a patch to compile cleanly. <snip> Are you referring to a multiple defined struct option in winedump? I spent quite a while trying to compile this drop on Solaris 9 this morning. The multiple defined struct was easy to find/fix, but assembler having BIG troubles. Pretty sure it is using gas, since I renamed as and made a symlink to gas. </snip> >3. Binary packages are highly recommended unless you prefer to muck >around occasionally with source code. That probably doesn't apply to >you since you're reading wine-devel, but for 99% of the people in the >world they should use the binaries. In theory we'll catch things at >that point. > >-Brian If I could find a Solaris 9 binary of ANY wine version in the last year or so, I would be VERY happy!!! Google found a couple links to Solaris 9 binaries a couple years old or so, but the link didnt even work. Rob D

Sept. 30, 2005

Re: headless question, and IPC question

by Alex Villacís Lasso

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

Sept. 29, 2005

Re: Problem Resolve

by Krzysztof Foltman

Molle Bestefich wrote: > If not, and that one's going away in two days, then it's probably not worth it.. Well, assuming that nobody cares about the hundreds of (potential) users put off during those two days :-) Isn't it possible to post a previous version or remove it completely? Is it lots of work, or something rather easy? (the question is genuine, I don't know anything about insides of Wine release process) Krzysztof

Sept. 29, 2005

Re: Problem Resolve

by Molle Bestefich

On 9/29/05, Brian Vincent <brian.vincent(a)gmail.com> wrote: > On 9/29/05, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > > That said, it seems a bit rude that the 20050830 CVS drop is *still* > > on the front page of http://www.winehq.com/, even after everyone knows > > that it's missing a patch to compile cleanly. > > > > Why not just add the patch to the package and slap it up as '20050830-1' ? > > Or add a link to the bugzilla entry to the front page ? > > 1. Adding the Bugzilla entry as a news item is a good idea. However, > we're possibly close to a September drop, so at this point it's > probably easiest to just wait for that. I'm very open to adding news > items to the front page, so definitely feel free to drop me an email > when you think of things like that. How about WWN coverage instead? Depends.. Is the CVS drop distributed through other channels than the winehq front page? If not, and that one's going away in two days, then it's probably not worth it.. I'd be happy to write up a few lines for WWN if you want something in there (albeit my english does suck, so beware :-)). > 2. CVS drops are just that - drops. They haven't been compiled on a > bizillion systems or tested with real-world applications to ensure > things aren't massively broken. Furthermore, no work was done to > stabilize the release other than normal bug fixes. Instead, it > represents a point in time where Alexandre ran the regression tests, > things worked for him, and a tarball was made. There was discussion > of that process changing after a beta release is made. > > 3. Binary packages are highly recommended unless you prefer to muck > around occasionally with source code. That probably doesn't apply to > you since you're reading wine-devel, but for 99% of the people in the > world they should use the binaries. In theory we'll catch things at > that point. Thanks for the clarifications. I'm super newbie so I don't know how these things work - sorry! Just thought I'd point it out since it seemed noone else had :-/.

Sept. 29, 2005

Re: headless question, and IPC question

by Ken Larson

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: >> >> 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 > > > >

Sept. 29, 2005