Following a recent discussion, 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.

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.

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?

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.

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