WWN Issue 47

This is the 47th release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

About.com runs a Wine introduction .

This week, 130 posts consumed 294 K. There were 57 different contributors. 26 (45%) posted more than once. 33 (57%) posted last week too.

The top 5 posters of the week were:

10 posts in 17K by Alexandre Julliard
8 posts in 13K by Ove Kaaven
7 posts in 13K by Bertho Stultiens
7 posts in 10K by Marcus Meissner
7 posts in 14K by Uwe Bonnes

Strange API conventions	02 Jun 2000 00:00:00 -0800	Archive
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.

Strange API conventions

02 Jun 2000 00:00:00 -0800

Archive

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.

Problem with gcc-2.95.2 and -O6 06 Jun 2000 00:00:00 -0800 Archive

Problem with gcc-2.95.2 and -O6	06 Jun 2000 00:00:00 -0800	Archive
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...

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

Making Star Money 2.0 to work	08 Jun 2000 00:00:00 -0800	Archive
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: if the window is a child/popup window, then this parameter is a child ID (which helps uniquely identify a child among his siblings) if the window is not a child window (overlapped...), this parameter is an ID to a menu control 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.

Making Star Money 2.0 to work

08 Jun 2000 00:00:00 -0800

Archive

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.

Feature: The X11 driver by Ove Kåven
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. <h3>x11drv modes of operation</h3> 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 libx11drv.so 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. Unmanaged/Normal 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. Managed 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.) Desktop-in-a-Box 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. <h3>The [x11drv] section</h3> AllocSystemColors 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. PrivateColorMap 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. PerfectGraphics 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. ScreenDepth Applies only to multi-depth displays. It specifies which of the available depths Wine should use (and tell Windows apps about). Display This specifies which X11 display to use, and if specified, will override both the DISPLAY environment variable and the --display command-line option. Managed Wine can let frame windows be managed by your window manager. This option specifies whether you want that by default. UseDGA 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. UseXShm 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. DXGrab 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). DesktopDoubleBuffered 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.

Feature: The X11 driver by Ove Kåven

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.

<h3>x11drv modes of operation</h3> 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 libx11drv.so 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.

<h3>The [x11drv] section</h3>

World Wine News