Wine Traffic #55 For 7 Aug 2000
Table Of Contents
Introduction
This is the 55th 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).
Wine 20000801 has been released. The main changes are:
- OS binary support should work again.
- Addition of a kernel message table for FormatMessage.
- The usual assortment of common controls improvements.
- A lot of stuff moved around for proper dll separation.
- Lots of bug fixes.
Mailing List Stats For This Week
We looked at 95 posts in 515K.
There were 40 different contributors.
21 posted more than once.
20 posted last week too.
The top posters of the week were:
- 10 posts in 20K by Alexandre Julliard <julliard@winehq.com>
- 8 posts in 27K by Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
- 7 posts in 15K by Marcus Meissner <marcus@jet.franken.de>
- 6 posts in 13K by Veksler Michael <mveksler@techunix.technion.ac.il>
- 5 posts in 9K by Ove Kaaven <ovehk@ping.uio.no>
- Full Stats
1.
Wine and MFC
29 Jul 2000 - 31 Jul 2000
(4 posts)
Archive Link: "RFC - Winelib constructor init problem"
People:
Jeremy White,
Following BROKEN KCREF,
Jeremy White finally had MFC compile and run under Wine. This required
some modification in Wine startup code.
As already explained, MFC, as a C++ library is allowed to, has global
objects, whose constructor is called before the WineLib init sequence
is called, leading to some crashes.
Jeremy gave the current outlook of the possible solutions:
The problem: MFC (and other C++ code) calls Windows APIs from
C++ constructors. A Winelib port of MFC then breaks because Wine is
not able to provide Windows APIs until after main() has been called,
because Wine is not initialized until then, and the C++ constructors
are invoked (on Linux) during the processing of the ctors list, which
occurs on library load.
The solutions:
- Make all Winelib apps into DLLs. This approach works today, and (I
think?) is preferred by Alexandre. Instead of foo.cpp building into a
Linux executable foo, it builds into foo.so. Then, foo.spec is built
into an executable foo, which gains control when main() is invoked,
does a LoadLibrary() on foo, a GetProcAddress of WinMain, and then
invokes it. I am not aware of any significant flaws with this approach
(but I'd love to hear anyone who can think of any, because I find it
strangely unsatisfying <g>).
- Make Wine constructors initialize Wine during the ctors processing
This approach is what I'm proposing and am a proponent of. The key
known flaw is that during ctors processing, we don't have access to
argc/argv, so Wine initialization cannot use command line arguments
(i.e. no -display, no -window, for startup purposes).
- Intercept ctors processing. In this case, best demonstrated by
Berthos, I believe, you intercept the ctors process of your target
library (say, MFC). You stash a pointer to the ctors chain somewhere,
and then force the glibc processing code to return immediately. Later,
during 'normal' library initialization (invoked after main()), you
walk the rest of the ctors chain.
Bertho explained in more details his solution, but no choice has been
made on the option to be implemented.2.
Wine HOWTO
31 Jul 2000
(1 post)
Archive Link: "Wine-HOWTO second location"
People:
, Jutta Wrage
Because her main site (Westfalen.de) had been down for a couple of
weeks, Jutta Wrage announced that the Wine HOWTO is now mirrored at
http://www.la-sorciere.de.
Please update your bookmarks if needed.3.
Shared heaps
30 Jul 2000 - 1 Aug 2000
(7 posts)
Archive Link: "HeapCreate flags and shared heaps"
People:
Peter Ganten, Alexandre Julliard,
Peter Ganten, while implementing PE DLLs shared sections (a piece of
memory shared by all processes loading the same DLL with this
feature), found out an interesting issue:
During my PE shared sections experiments I have found the following
behavior of most native system dlls like for example commdlg32:
- When the library is loaded the first time, it creates a global
heap using CreateHeap and the undocumented flag 0x4000000.
- On win95 this flag has the effect, that the resulting heap is
visible and usable in the address spaces of all processes immediately.
- If another application load the dll, it retrieves a pointer to
that shared heap from a shared section of the dll and starts using
that heap. This is also the explanation of the crashes, I described in
a previous mail.
Now the question is, if we want to support that 0x4000000 flag in WINE
and if yes, how this can be done. I am not sure and would like to
know, if this flag is supported under NT/2000, maybe somebody can
enlighten me here?
4.
Wine in the press
2 Aug 2000
(1 post)
Archive Link: "Press: ZDNET: A toast to wine for running windows apps"
People:
Marcus Meissner, eWeek, , ZDNet
Marcus Meissner pointed out to some Wine related article:
Sharon And Joy