Wineserver
From Wine-Wiki
Contents |
Introduction
The wineserver is an integral part of wine but wineserver has nothing to do with an X server.
A Programmer noted: When wine exits, wineserver keeps running and finishes a second or two later. It rewrites the config files (registry) AFTER the command completion.
A. Julliard: Yes, it's on purpose. You can reduce the timeout by using the -p option to wineserver, but there will be a race in any case. You really shouldn't be manipulating the registry files directly, you should call regedit from your scripts. And running wine immediately after exiting should work fine. [Wine Archive]
Troubleshooting
Using the command line:
Stopping the wineserver
wineserver -k
A poster asked: When installing IE6 (from my own script) I see wineboot is being forked and gets running right after the "./wine IE6SETUP.EXE /q" statement returns me a control. I would like to wait untill "wineboot" finishes. How it can be achieved in my bash script? V. Margolen: wine archive
- wineserver -w
Wineserver Documentation
[Sept05] Initial version of a wineserver man page was added to CVS.Patch: http://cvs.winehq.org/patch.py?id=20452
Forum Comments
R. Shearman [Jun 06]: [When asked: Are long-running functions requiring I/O (hal_device_get_property_...()) allowed in wineserver (which seems to be event-driven)? ] Absolutely not. Any long-running functions will cause all of the user's winelib applications to freeze until the server unblocks. wine archive
A. Julliard [Jun 06]: [With a review of code] make[ing] the server wait on the client to execute the code, [...] that's a big no-no, the server can't trust the client. wine archive
Coding Hints:wineserver
Understanding and then altering the servers design and API is not for the faint hearted. Questions arise over
- server protocol design decisions
- adding server functions
- protocol.def: @REQ, @REPLY, @END
- protocol.def: VARARG...when to use it, syntax etc
- why we use DECL_HANDLER and what should go in it
- why there is a function and then its counterpart DECL_HANDLER
However, this is an area deep, deep into Wine's internals, and even a minor change can have far reaching consequences.
M.McCormack: If you want to modify Wine's internals, then... take the time to thoroughly read and understand the code.
J.Lang Added: It's not commented because the comments can become out of date and misleading. He also reinforced M. McCormacks comments: If you want to modify Wine's internals, then you'd better take the time to thoroughly read and understand the code.
A. Julliard, the man with the key to Wine's cvs explained his rational: protocol.def itself is the documentation of the protocol, there is no need for more. It's pretty much self-explaining anyway, and people who can't figure it out by reading the code have no business messing around with the server protocol. Consider it as the entrance exam for server hacking ;-)
update: there is a man page for the wineserver
Nov 08 bug 9787 contains a discussion about changing the wineserver as Alexandre commented a patch was modifying the wineserver more than it should. The sender of the patch commented:
There is a lot of code that gets modified. A Lot. The basic patch is just under 300 lines of code. The code with the modified wineserver is over 1000. Check the file sizes. Andrey Turkin's code is the basic implementation. Just over 11KB. My partial is only a little over 16KB. Then once I figured out how to modify the wineserver it jumps to over 36KB. Here is the basic problem.
- Alexander believes The wineserver works.
- The wineserver does work,for everything until this point.
- A new feature is added and it doesnt work because something doesn't work as specified.
Essentially, I, a relative unknown, am telling someone who has been working on this a long time that something is broken. If a man came in off the street and said that your product is broken, you don't always take him in hand and say he is right.
Under the hood:
The wineserver has an asynchronous operation structure in place. When an asynchronous command finishes, the next one is queued to start. This is what is supposed to happen. It doesn't(for sockets). I don't have the foggiest idea why. My solution was to rewrite a set of if statements that allows commands to
be executed without waiting for previous statements to finish. It also allows for random removal of events from the queue. This breaks a paradigm that the asynchronous queue was built upon. Thus the patch is considered wrong.
The wineserver is so poorly documented that I didn't know I was breaking a paradigm when I did it. I thought I was fixing it (from what comments are in the code). It happened to work, but it may be a case of 'I got lucky.' and I don't have strong evidence to support my case, other than "hey it works now".
However J. Hawkins pointed to a way to potentially help progress: Have test cases been written for all of these supposed deficiencies?
Some Code Questions
V Lipatov: There is hardcoded path to /tmp for wine server directory, and [asked if the TMPDIR environment variable could be used].
A. Julliard: No, the server directory has to be in /tmp so that all instances use the same lock file. If you take into account environment variables there is no guarantee that all server invocations will use the same value.
A User asked: I need to find a way to enumerate all the handles in the system, any ideas?
M. Hearn: Kernel handles are maintained in the wineservers handle tables: you could add a new request to handle.c and sum up the handles in the global table and all the process tables. Wine Archive Link
