Wine Traffic #24 For 3�Jan�2000
Table Of Contents
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:
- 18 posts in 55K by Patrik Stridvall <firstname.lastname@example.org>
- 12 posts in 30K by 'Juergen Schmied' <email@example.com>
- 10 posts in 32K by Lionel Ulmer <firstname.lastname@example.org>
- 10 posts in 30K by Huw D M Davies <email@example.com>
- 8 posts in 19K by Ulrich Weigand <firstname.lastname@example.org>
- Full Stats
�Archive Link: "gcc woes"
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).
- gcc 2.95 does not produce the error
- using gcc 2.91 without the -O2 option also works around the
DC and first bitmap
�Archive Link: "best way to handle gdi objects cleaning"
G�rard Patel,�Patrik Stridvall,�,�Patrik Stridval
G�rard Patel pointed out an interesting issue:
G�rard and Patrik Stridvall started then discussing ways of fixing
Patrik quoted the MS documentation of CreateCompatibleDC:
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.
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
- 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
TEB and different Windows versions
�Archive Link: "more TEB problems"
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