Wine Traffic #9 For 20�Sep�1999

By Eric Pouech

Table Of Contents


This is the ninth release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

1. Winsock (cont'd)

�Archive Link: "Winsock (cont'd)"

People: Ulrich Weigand,�Alexandre Julliard,�,�Ove K�ven

The discussion regarding implementation of Winsock continued (see last week's WWN article for more information).

Several issues have been addressed:
  1. How to split functions between the wineserver and the client side ?
  2. How to handle the asynchronous operations ?
  3. Where to store the data (client side, server side, mixed) ?
  4. How to detect when a socket has been closed ?

Alexandre Julliard proposed to store the handle to the socket in the server, but to retrieve the attached Unix fd each time it's needed on the client side (mainly because other threads may have changed its state, or even deleted it).

The tricky part lies in how the client side will be notified of the changes on the unix sockets fd. A first track was to let the socket handles be selectable in WaitFor... functions. Ove K�ven reported that Winsock 2 doesn't allow it, but Ulrich Weigand said
on Win95 at least WSOCK32 uses a trick to be able to wait on sockets using WaitForMultipleObjects: there's an undocumented KERNEL32 routine CreateSocketHandle which returns a handle to a K32OBJ of type K32OBJ_SOCKET (== 17).

This solution had some drawbacks: bad behavior when several threads asynchronously wait on the same socket handle; the client (or the service thread) cannot determine when to clean-up the allocated data (they are not aware of handle deletion).

Ove, Alexandre and Ulrich tried some other solutions, and ended with this one: the wine-server will be enhanced so that it can associate an event to a unix (socket) fd. When, in the select() loop on the wine-server, the fd receives an action, it will trigger the event; the service thread, on the client side, will then be able to do its job. This allows both to solve the issue "can socket handles be WaitFor...:ed", and also to clearly define which actions the fd must wait on. Is this case, the socket handles will have the same behavior as file handles with respect to WaitFor... functions.

Most of the operations (recv/send...) shall be done on the client side, but a new wine server command will be introduced to both re-enable the sockets in the select loop, but also to detect which ones may have been deleted, so that the correct deallocation can occur.

Ove estimates that one week is the needed time to get something working: you can watch progess on his project page ( .

2. Future of Window Manager

�Archive Link: "Future of Window Manager"

People: Dennis Bj�rklund,�Ulrich Weigand,�

Dennis Bj�rklund sent out some bits reguarding the evolution of X11 Window Managers, along with some issues he had with current Wine windows managing features:
Couldn't we tell the window manager that we don't want any decorations and paint our own window (look at xmms for example). If we run wine without -managed the look is correct, but not the behaviour.

Ulrich Weigand said this could be done with
modifying the unmanaged mode (or maybe add a new mode) so it doesn't set override-redirect on top-level windows, but instead lets the WM manage those windows just like in managed mode, except it uses some (yet to be defined) hints to tell the WM to remove all frame decorations. Except for that, all painting would be done exactly like in the unmanaged case...
Ulrich was sure that not all window managers would correctly support the needed hints, and this would lead to bad behavior:
of course, we could always rely on the user to select that mode only if supported by the WM, but some kind of automatic fall-back would still be nice...

Dennis then reported the undergoing work for KDE, Gnome and other window managers to better specify what the WMs are supposed to provide (in other words an improved version of the ICCCM). Undergoing work can be found here ( (some of the links there seem to be broken: but you can browse the directory content ;-) ). From the list of participants (or willing to participate or "being willed" to participate), this is something Wine developpers should follow up.

3. Fonts

�Archive Link: "Fonts"

People: Gavriel State,�Douglas Ridgway,�Alexandre Julliard,�,�Patrik Stridvall

One of the favourite Wine discussion issues popped up once again: Fonts !!

Gavriel State posted:
We've been looking at the font issue quite closely for the last few weeks, and we have explored a couple of possibilities.

First of all, here are the primary problems we see with fonts on WINE:

  1. Can't get at the outline data to support GetGlyphOutline call
  2. Various font sizing and metrics issues
  3. No support for antialiasing
  4. X font system is very confusing and hard to set up for the average user.
Gav' then introduced several options to tackle the issues he brought up:
A/ Link directly to FreeType (note that FreeType 2.0 supports Type1 fonts in addition to TrueType).

We've already done some experimentation along these lines and we have a preliminary implementation of GetGlyphOutline that works using direct calls to FreeType.

FreeType would solve (1) and (2) quite easily - we would just get the info directly from FreeType. It would introduce another problem though: if we use FreeType to get metrics and outlines, but X to render the fonts (through something like xfsft), subtle differences crop up between the X-rendered font and the numbers we get back from FreeType.

We could solve this by using FreeType for rendering as well, which would also solve issue (3), but at the expense of making remote display much slower than it has to be. If we did that, we would also solve issue (4) since all the TT fonts would be in a standard place such as /usr/share/fonts/truetype. If we didn't, the user is still stuck with configuring an X server.

Finally, there's the TrueType patent issue which has yet to be resolved. (Please put up your hand if you hate software patents)

B/ Encourage development of extensions to the X Font Server protocol that would enable us to get access to the font outlines.

This would solve (1) and (2), while leaving (3) and (4) unresolved. Note that there was some work done on the 'XAnti' extension for XFree 4.0, but I believe that it was abandoned.

We've actually had some contact with a vendor that has a font server that implements these kind of extensions along with an SDK for getting at the outlines. The code would not be free though. Their work also solves issue (4) in a different way.

How do people feel about adding optional support for a non-free library that provides this functionality? Alexandre, if we did work to support such a library (ifdefed, of course), would you allow that work into CVS, or would we have to keep a seperate branch ourselves?

My hope is that the vendor would be willing to release the information about the protocol they're using so that XFree and other X server developers could support the extension protocol themselves in the future....

Patrik Stridvall proposed, for option B/, to put all the related material inside a driver (instead of using #ifdef), because it makes Alexandre Julliard happier (Patrik reported some bad adventures he had with patches full of #ifdef:s being rejected by Alexandre), but also it's easier to setup (and also enable and disable) and can even allow to hook up another driver to support a (specific) protocol to another TrueType enabled font server. Later on, Patrik also sent the URL for a mini-HOWTO ( dedicated to TrueType server setup for the Debian distribution.

Douglas Ridgway also commented option B/:
As far as getting font outlines and doing font management, there's an alternative to building the added functionality into an XFS protocol extension. You can talk to the font server via a side channel. When I last looked at this, I thought there was enough flexibility in an unmodified xfs (with tt support) for our purposes, managing fonts by changing the config file and directing xfs to reread it, and maintaining a table of font file to Windows font correspondances, to allow things like outlines. I never got to a proof of concept however. My understanding of the commercial offerings was that they use a side channel as well, rather than building an extension to the XFS protocol, but I could be wrong.

4. Clipboard (cont'd)

�Archive Link: "Clipboard (cont'd)"

People: Noel Borthwick,�,�Patrik Stridvall

Noel Borthwick reported he's almost done with the clipboard server and

1) sent out a quick overview of the server implementation:

The server is a standalone pure XLib application. The makefile builds a target called "wineclipsrv". wineclipsrv takes one command line argument which is a bit mask of the selection types to be acquired. Currently we just support two selections PRIMARY (internal mask value 1) and CLIPBOARD (internal mask value 2). If no argument is supplied the server aquires all selections. (mask value 3)

When the server is started it first queries the current selection owner of the specified selections for the TARGETS selection target. It then proceeds to cache all the formats exposed by TARGETS. If the selection does not support the TARGETS target, or if no target formats are exposed, the server simply exits. Once the cache has been filled, the server then actually acquires ownership of the respective selection and begins fielding selection requests. Selection requests are serviced from the cache. If a selection is lost the server flushes its internal cache, destroying all data previously saved. Once ALL selections have been lost the server terminates.

Now when Wine terminates, we check if Wine owns any selections. If it does we spawn the server with the appropriate selection masks. This captures the selection data from Wine and takes over the selection.

2) and asked for help in order to integrate his development into the Wine tree (especially the needed Makefiles for a good cross platform support).

Patrik Stridvall then discussed some details of the implementation with Noel. Patrik main concerns were around the fact that the clipboard server is spawn when a Wine process exits: Noel implementation lets the process, when running, handle all the X11 and Windows clipboard operations; but, when the process exits, if it owns some clipboard selection, it then spawns this very server, in order to let this selection being available (either to X11 or to Windows clipboard) after the process has exited. Patrik didn't like the idea of spawning the server, and would better see a server running all the time; Patrik and Noel agreed that, if this proposal had to be implemented, this server should hold the selection all the time, which would led the windows clipboard implementation to grasp data from it (current implementation caches the clipboard content inside the process). In order to provide an efficient implementation, shared memory shall be used between the Wine processes and this server.

Both agreed that Noel's work was a very acceptable short term solution, and that this discussion was the long term roadmap the clipboard implementation shall follow.

5. DGA 2.0 and Wine

�Archive Link: "DGA 2.0 and Wine"

People: Lionel Ulmer,�Ulrich Weigand,�,�Patrik Stridvall

Lionel Ulmer started integrating DGA 2.0 into Wine. Nevertheless, there were some issues to solve:
I started some days ago to add DGA 2.0 support to DirectDraw (to use the new possibilities like depth / resolution switching and hardware blits with and without transparencies).

By doing a small test program, I found out that, whatever I do, when I start using DGA, all mouse movements reported by XMotionEvents are relative movements.

The game I am testing with (Baldur's Gate) uses DirectDraw for its graphics but standard USER calls for its mouse input (to be more precise, USER.17 GetCursorPos16).

When I test the game with DGA, the mouse does not move at all. This is because as long as DGA is enabled, XQueryPointer always returns the position of the mouse before entering DGA.

As GetCursorPos16 calls EVENT_QueryPointer, I concluded that I need to add a new driver specific to this case that would use all the XMotionEvents to compute the absolute mouse position by adding all the relative events and clip to the screen size.

Ulrich Weigand proposed:
to fix this in our USER itself, instead of hacking the driver: on real Windows, USER must cope with whatever it gets passed to its mouse_event routine. In particular, USER must cope if the mouse_event routine is called only with relative events. In this case it is the task of USER to add up the relative events so as to track the absolute position!

So, what would you say to this solution: throw out completely the EVENT_QueryPointer routine. Instead, create USER-global variables holding the current mouse position; at all places where QueryPointer is currently called, use those variables instead. The variables are filled in the mouse_event routine, which is furthermore changed to cope with both absolute and relative mouse events. In the case of absolute events, it simply sets the global variables to the given values, while in the case of relative events, it keeps adding them up.

Next, modify the X11DRV_EVENT driver to send relative mouse events if DGA is active (it should know that ...), and absolute mouse events whenever possible (just like now).

Lionel noted that some remaining points needed to be solved:

Patrik Stridvall and Lionel also discussed some other issues related to hot-swap drivers in Wine for keyboard, mouse, screen.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.