Wine Traffic #55 For 7�Aug�2000

By Eric Pouech

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:

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:

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:
  1. 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>).
  2. 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).
  3. 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:

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?

Alexandre Julliard tested this behavior was not supported under Windows NT, and thus accepted Peter's proposal to use the system heap when a native DLL requests a shared heap.

Later on, Peter also reported some nasty results of anonymous mapping with some specific options. When (at least) two processes open the same mapping, after the first process commits some pages, those are automatically committed into the second process address space.

This has been successfully tested on Win95 and on Win NT, but Wine doesn't provide such a mechanism (Peter reported that MS Office 97 was using such a mechanism).

So, some more work will be required on the memory management issues.

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:
ZDNet eWeek has a brief article on us, mostly talking about the Lotus Notes client: href="http://www.zdnet.com/eweek/stories/general/0,11011,2607357,00.html (http://www.zdnet.com/eweek/stories/general/0,11011,2607357,00.html)

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.