Wine Traffic #24 For 3 Jan 2000

By Eric Pouech

Table Of Contents

Introduction

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.

Mailing List Stats For This Week

We looked at 149 posts in 574K.

There were 41 different contributors. 26 posted more than once. 24 posted last week too.

The top posters of the week were:

1. GCC issues

 Archive Link: "gcc woes"

People: , 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:

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

2. DC and first bitmap

 Archive Link: "best way to handle gdi objects cleaning"

People: Gérard Patel, Patrik Stridvall, , 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:

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

3. TEB and different Windows versions

 Archive Link: "more TEB problems"

People: Jürgen Schmied, 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.

 

 

 

 

 

 

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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.