From ceecf12384008958b8b71d215c458231d9dbfabe Mon Sep 17 00:00:00 2001 From: "Dimitrie O. Paun" Date: Tue, 27 Jan 2004 20:09:46 +0000 Subject: [PATCH] Remove obsolete info about wrappers, they are no longer necessary. --- documentation/winelib-porting.sgml | 78 ------------------------------ documentation/winelib-user.sgml | 2 +- 2 files changed, 1 insertion(+), 79 deletions(-) diff --git a/documentation/winelib-porting.sgml b/documentation/winelib-porting.sgml index a4c440013fa..4acef00a653 100644 --- a/documentation/winelib-porting.sgml +++ b/documentation/winelib-porting.sgml @@ -149,84 +149,6 @@ - - Initialization problems - - Initialization problems occur when the application calls the Win32 API - before Winelib has been initialized. How can this happen? - - - Winelib is initialized by the application's main - before it calls the regular WinMain. But, in C++, - the constructors of static class variables are called before the - main (by the module's initializer). So if such - a constructor makes calls to the Win32 API, Winelib will not be - initialized at the time of the call and you may get a crash. This - problem is much more frequent in C++ because of these class - constructors but could also, at least in theory, happen in C if you - were to specify an initializer making calls to Winelib. But of - course, now that you are aware of this problem you won't do it :-). - - - Further compounding the problem is the fact that Linux's (GNU's?) - current dynamic library loader does not call the module - initializers in their dependency order. So even if Winelib were to - have its own initializer there would be no guarantee that it would be - called before the initializer of the library containing this static - variable. Finally even if the variable is in a library that your - application links with, that library's initializer may be called - before Winelib has been initialized. One such library is the MFC. - - - The current workaround is to move all the application's code in a - library and to use a small Winelib application to dynamically load - this library. Tus the initialization sequence becomes: - - - - - the wrapper application starts. - - - - - its empty initializer is run. - - - - - its main is run. Its first task is to - initialize Winelib. - - - - - it then loads the application's main library, plus all its - dependent libraries. - - - - - which triggers the execution of all these libraries initializers - in some unknown order. But all is fine because Winelib has - already been initialized anyway. - - - - - finally the main function calls the WinMain - of the application's library. - - - - - This may sound complex but Winemaker makes it simple. Just specify - or on the command line - and it will adapt its makefiles to build the wrapper and the - application library. - - - VC's native COM support diff --git a/documentation/winelib-user.sgml b/documentation/winelib-user.sgml index f1ce9e68eee..26e798b6c5b 100644 --- a/documentation/winelib-user.sgml +++ b/documentation/winelib-user.sgml @@ -13,7 +13,7 @@ Winelib User's Guide + we can't really include it -->