Wine Traffic #47 For 12�Jun�2000

By Eric Pouech

Table Of Contents


This is the 47th 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). runs a Wine introduction ( .

Mailing List Stats For This Week

We looked at 130 posts in 294K.

There were 57 different contributors. 26 posted more than once. 33 posted last week too.

The top posters of the week were:

1. Strange API conventions

2�Jun�2000�-�8�Jun�2000 (10 posts) Archive Link: "Missing prototypes (courtesy of winapi_check)"

People: Francois Gouget,�Andreas Mohr,�

Francois Gouget, still toying with winapi_check and ports of Windows apps with WineLib) sent a patch to mimic better the way Windows splits the definitions across the header files.

One point of peculiar interest was the MCIWndCreate function (Francois fix was:
MCIWndCreate conflicts with the corresponding A/W macro

As a side note, since the introduction of UNICODE strings in Windows, most APIs exist in two flavors when strings come into play: - an ANSI version - an UNICODE one.

Usually, the ANSI version is postfixed by A (fooA) and the UNICODE with W (fooW) (for Wide characters). In the header file, depending whether the manifest constant UNICODE is defined, foo is either #defined as fooW or fooA.

Francois Gouget went further on some tentative explanations:
When I say that the DLL had three APIs I checked with windows and saw that they do use the usual macro for MCIWndCreate. So, I assume that they created MCIWndCreate first and then realized that it should really have an A and a W version, added those but did not remove the original one to not cause compatibility problems. So I assume one is not supposed to use the old one anymore. Of course if one really wants to use the old one all one has to do is to use GetProcAddress.

After lots of people complained about this reminiscence of the bad coding habits, the discussion evolved into the prototypes for such function. Andreas Mohr also pointed out that WINSPOOL.DeviceCapabilities{A|W} might suffer from the same symptoms and may require the same treatment, but no one replied.

2. Problem with gcc-2.95.2 and -O6

6�Jun�2000 (2 posts) Archive Link: "Problem with gcc-2.95.2 and -O6"

People: Lionel Ulmer,�Ulrich Weigand,�

Lionel Ulmer reported some IRC discussion he had:
By discussing with a Wine user on #nvidia, we found out that when compiling 'scheduler/sysdeps.c' with gcc 2.95.2 and -O6, the function 'SYSDEPS_DoCallOnStack' is undefined
nm sysdeps.o | grep DoCallOnStack
gives 'U SYSDEPS_DoCallOnStack').

After some discussions with Ove, he thought that it was because gcc was inlining this function.

Lionel asked for hints on ways to tell gcc not to inline this function.

Ulrich Weigand tried to help:
Well, I had hoped the __attribute__(__unused__) that I attached to the declaration would suffice ... I'm not aware of any other pragma or attribute that could be used.

The proper solution for gcc would IMO be to replace the ASM_GLOBAL_FUNC hack by proper GNU inline assembly, specifying the procedure address as input argument. This way, gcc would be aware that it is used. Unfortunately, Patrik won't like this as it breaks non-gcc compilation :-/

Anyway, Ulrich proposed a dirty hack (removing the static attribute). The moral of this story might be not too use heavy optimization with bleeding edge compilers...

3. Making Star Money 2.0 to work

8�Jun�2000�-�9�Jun�2000 (13 posts) Archive Link: "Star Money 2.0 crash"

People: Alexandre Julliard,�G�rard Patel,�Andreas Mohr,�

Andreas Mohr reported a crash while running Star Money 2.0. He also started digging into the traces, and reported some bad behavior between windows handles and menu id. Speaking after himself, Andreas smelled some mismatch between windows IDs and menu IDs. Alexandre Julliard pointed back to
the recent changes to SetParent which do not clear wIDmenu when making the window a top-level one.

As a side note, Windows (at least in CreateWindow) uses the same parameter for two different uses:

Alexandre also suggested that
we should probably have separate fields for id and menu to avoid this problem.

A naive Andreas asked whether he should do the work, and Alexandre slapped the impetuous:
I want the patch in my mailbox in 10 minutes. That will teach you what happens to people who dare to find bugs. ;-)

Andreas missed the deadline but G�rard Patel sent the proper fix in SetParent that all of them suspected to be the culprit.

G�rard gave also some more details on his fix:
The combo listbox is now created like a child window in controls/combo.c But this 'strange little beast' is not keeping its style when it's reparented in the wnd.c file (because of the code removed by my patch). So, the style is turned from child to neither child nor popup - hence, overlapped (main window). An overlapped window can have a menu and has, of course, no child Id. A child has an Id, but can't have a menu. With my patch, the id can't be handled as a menu handle in the (rather special) case of the combobox.

It's an incredibly bad design, of course, but being compatible with Windows and having a good design is a challenge.

4. Feature: The X11 driver by Ove K�ven

People: ,�Patrik Stridvall

Most Wine users run Wine under the windowing system known as X11. During most of Wine's history, this was the only display driver available, but in recent years, parts of Wine has been reorganized to allow for other display drivers (although the only alternative currently available is Patrik Stridvall's ncurses-based ttydrv, which he claims works for displaying calc.exe). The display driver is chosen with the "GraphicsDriver" option in the [wine] section of wine.conf/.winerc, but I will only cover the x11drv in this article.

x11drv modes of operation

The x11drv consists of two conceptually distinct pieces, the graphics driver (GDI part), and the windowing driver (USER part). Both of these are linked into the module, though (which you load with the "GraphicsDriver" option). In Wine, running on X11, the graphics driver must draw on drawables (window interiors) provided by the windowing driver. This differs a bit from the Windows model, where the windowing system creates and configures device contexts controlled by the graphics driver, and applications are allowed to hook into this relationship anywhere they like. Thus, to provide any reasonable tradeoff between compatibility and usability, the x11drv has three different modes of operation.
The default. Window-manager-independent (any running window manager is ignored completely). Window decorations (title bars, borders, etc) are drawn by Wine to look and feel like the real Windows. This is compatible with applications that depend on being able to compute the exact sizes of any such decorations, or that want to draw their own.
Specified by using the --managed command-line option or the Managed wine.conf option (see below). Ordinary top-level frame windows with thick borders, title bars, and system menus will be managed by your window manager. This lets these applications integrate better with the rest of your desktop, but may not always work perfectly. (A rewrite of this mode of operation, to make it more robust and less patchy, is highly desirable, though, and is planned to be done before the Wine 1.0 release.)
Specified by using the --desktop command-line option (with a geometry, e.g. --desktop 800x600 for a such-sized desktop, or even --desktop 800x600+0+0 to automatically position the desktop at the upper-left corner of the display). This is the mode most compatible with the Windows model. All application windows will just be Wine-drawn windows inside the Wine-provided desktop window (which will itself be managed by your window manager), and Windows applications can roam freely within this virtual workspace and think they own it all, without disturbing your other X apps.

The [x11drv] section

Applies only if you have a palette-based display, i.e. if your X server is set to a depth of 8bpp, and if you haven't requested a private color map. It specifies the maximum number of shared colormap cells (palette entries) Wine should occupy. The higher this value, the less colors will be available to other applications.
Applies only if you have a palette-based display, i.e. if your X server is set to a depth of 8bpp. It specifies that you don't want to use the shared color map, but a private color map, where all 256 colors are available. The disadvantage is that Wine's private color map is only seen while the mouse pointer is inside a Wine window, so psychedelic flashing and funky colors will become routine if you use the mouse a lot.
This option only determines whether fast X11 routines or exact Wine routines will be used for certain ROP codes in blit operations. Most users won't notice any difference.
Applies only to multi-depth displays. It specifies which of the available depths Wine should use (and tell Windows apps about).
This specifies which X11 display to use, and if specified, will override both the DISPLAY environment variable and the --display command-line option.
Wine can let frame windows be managed by your window manager. This option specifies whether you want that by default.
This specifies whether you want DirectDraw to use XFree86's Direct Graphics Architecture (DGA), which is able to take over the entire display and run the game full-screen at maximum speed. (With DGA1 (XFree86 3.x), you still have to configure the X server to the game's requested bpp first, but with DGA2 (XFree86 4.x), runtime depth-switching may be possible, depending on your driver's capabilities.) But be aware that if Wine crashes while in DGA mode, it may not be possible to regain control over your computer without rebooting. DGA normally requires either root privileges or read/write access to /dev/mem.
If you don't want DirectX to use DGA, you can at least use X Shared Memory extensions (XShm). It is much slower than DGA, since the app doesn't have direct access to the physical frame buffer, but using shared memory to draw the frame is at least faster than sending the data through the standard X11 socket, even though Wine's XShm support is still known to crash sometimes.
If you don't use DGA, you may want an alternative means to convince the mouse cursor to stay within the game window. This option does that. Of course, as with DGA, if Wine crashes, you're in trouble (although not as badly as in the DGA case, since you can still use the keyboard to get out of X).
Applies only if you use the --desktop command-line option to run in a desktop window. Specifies whether to create the desktop window with a double-buffered visual, something most OpenGL games need to run correctly.

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.