Wine Traffic #55 For 7 Aug 2000 By Eric Pouech Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Mailing List Stats For This Week * Threads Covered 1. 29 Jul 2000 - 31 Jul 2000 (4 posts) Wine and MFC 2. 31 Jul 2000 (1 post) Wine HOWTO 3. 30 Jul 2000 - 1 Aug 2000 (7 posts) Shared heaps 4. 2 Aug 2000 (1 post) Wine in the press 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 * 8 posts in 27K by Uwe Bonnes * 7 posts in 15K by Marcus Meissner * 6 posts in 13K by Veksler Michael * 5 posts in 9K by Ove Kaaven * 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: 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 ). 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: * 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. 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.