Wine Traffic Eric Pouech This is the twenty fourth 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).

Many thanks to Zack Brown for putting up a KC edition last week while I was lingering on vacation. Anyway, for those of you who missed last week's KC Wine, here's a summary of the past two weeks.

I also take the opportunity to wish you a very pleasant new year.

Eric Pouech Eric Pouech reported that gcc 2.91 did produce erroneous code while compiling Wine (symptoms were that when moving windows around, they all ended up with a y=0 coordinate).

It turned out that:

  • gcc 2.95 does not produce the error
  • using gcc 2.91 without the -O2 option also works around the issue

As a conclusion, it is STRONGLY recommended not to use gcc 2.91 (or as a fall-back, to use it without the -O2 option).

Patrik Stridval Gérard Patel pointed out an interesting issue:

First, a reminding of the problem I have seen on the Word97 viewer: when displaying a file (the readme.doc present with the product, in fact) in 'online layout' mode, scrolling the text part (to the right) by clicking in the scrollbar soon gives strange display problems (patches of black, overlaying of text)

The immediate reason is the hFirstBitmap handle; as far as I understand, this parameter has been added to the dc structure to avoid a leakage when deleting the DC. Unfortunately, when the application itself cleans this handle, by calling DeleteObject on the handle it gets after a SelectObject on a bitmap in the (memory) DC, the hFirstBitmap stays as a dangling reference to a deleted object. When the DC is destroyed, whatever object that happens to have the same handle value is destroyed; in this case it's usually the handle of the visible region of the main window.

Gérard and Patrik Stridvall started then discussing ways of fixing this issues.

Patrik quoted the MS documentation of CreateCompatibleDC:

A memory device context is a device context that exists only in memory. When the memory device context is created, its display surface is exactly one monochrome pixel wide and one monochrome pixel high. Before an application can use a memory device context for drawing operations, it must select a bitmap of the correct width and height into the device context. This may be done by using CreateCompatibleBitmap specifying the height, width, and color organization required in the function call.

and stressed the word "must", in the sentence "Before an app...", suggesting that this first bitmap may have some strange behavior.

After some testings under Windows NT, Gérard announced that Patrik's suggestion was a very good one:

  • the first bitmap in a DC can still be accessed (no error returned) after it has been destroyed (DeleteObject returns TRUE) (!!!)
  • the handle of this first bitmap is the same for all the applications (trying to access the handle even without getting it with as a return value of SelectObject() works (!!!))
  • modifying the dimensions of this bitmap works (and the changes are also seen from other applications (!!!)).
  • Gérard didn't try to see if setting bits into this bitmap enables a new interapplication communication mechanism

So the correct fix would be to create a unique first bitmap (monochrome) for all the applications and to prevent its destruction in DeleteObject().

Andreas Mohr Alexandre Julliard Eric Pouech Jürgen Schmied reported some more issues regarding the TEB layout. The TEB (Thread Environment Block) is the internal Windows structure where all the informations related to a thread are stored. Win 9X and Windows NT have different layout for this structure. Microsoft also decided to have this structure live in user space (???), so some applications (especially the ones from MS, or MS DLLs) directly access this structure, thus requiring Wine to behave in a similar way.

Currently, Wine's TEB implementation is rather Win 9x centric (but not all the fields are present). Some recent patches (from Jürgen Schmied and Eric Pouech) tried to alleviate those problems (for example, NT uses a 4k TEB whereas Win 9x's is much smaller - a few dozen bytes), but more on more seem to show up.

Alexandre Julliard suggested to extend the Wine's current Win 9x centric TEB by adding, when appropriate, the needed Win NT fields.

Jürgen then pointed out a mismatch: Windows 9 stores at offset 0xC4 of the TEB the TLS array whereas Win NT puts the current locale setting. Jürgen suggested to a better solution is to use a union of the 3 (win95/nt/wine) TEBs and accessing fields with eg. teb->win95.fieldname. This would not help solving the clashes on the fields by themselves, but at least to know which TEB layout is referred to.

Inn another thread, Andreas Mohr reported a crash while running a Win NT application, which was also due to this type of clash. No easy fix has been foreseen, but trying to run native NT psapi.dll or rpcrt4.dll demonstrates the problem.

Anyway, it would be very astonishing if this issue didn't pop up again in the next weeks.