WineLib does not support Win16. Removed references to Win16 and Win

3.x in the introduction. Standardized capitalization of Wine and
WineLib. Added documentation for compiling a simple "Hello World"
WineLib program.

documentation/HOWTO-winelib

@@ -1,5 +1,5 @@
 WineLib HOWTO
-Version 04-Jun-2000
+Version 11-Jun-2000
 
 AUTHOR: 
 Wilbur Dale
@@ -17,23 +17,26 @@ basis until it is complete.
 
 Table of Contents
 
-  I. Introduction: Wine vs. WineLib
+   I. Introduction: Wine vs. WineLib
 
- II. Legal Issues
+  II. Legal Issues
 
-III. How Much Work?
+ III. How Much Work?
 
- IV. Compiling A Simple Win32 Program 
+  IV. File Format Conversion
 
-  V. Compiling A Win32 Program With Resources
+   V. Compiling A Simple Win32 Program 
 
- VI. DLLs
+  VI. Compiling A Win32 Program With Resources
+
+ VII. DLLs
     A. Native DLL.
     B. so DLL.
-    C. elfdll.
+    C. elfDLL.
+    D. resource DLL.
 
-VII. How to use MFC
+VIII. How to use MFC
-    A. Using a native MFC dll
+    A. Using a native MFC DLL
     B. Compiling MFC
 
 VIII. Trademarks
@@ -50,45 +53,44 @@ All other trademarks are the property of their respective owners.
 
 I. Introduction: Wine vs. WineLib
 
-Wine/Winelib provides the Win32/Win16 API's to a non-Microsoft
+WineLib provides the Win32 API to a non-Microsoft operating
-operating system. The wine/winelib Win32/Win16 functions use X11
+system. The WineLib Win32 functions use X11 functions to perform the
-functions to perform the actual drawing on the screen. Wine and
+actual drawing on the screen. Wine and WineLib are based on the same
-winelib are based on the same set of functions that implement the
+set of functions that implement the Win32 API. The difference between
-Win32/Win16 API. The difference between wine and winelib is the type
+Wine and WineLib is the type of executable that is loaded into memory
-of executable that is loaded into memory and executed. If an
+and executed. If an executable and any associated DLLs were compiled
-executable and any associated DLLs were compiled for x86 hardware
+for x86 hardware running the Windows 95, 98, or Windows NT (TM)
-running the Windows 3.x, 95, 98, or Windows NT (TM) operating systems,
+operating systems, then Wine can use a special binary loader to load
-then Wine can use a special binary loader to load the program and the
+the program and the libraries into memory and execute it. WineLib on
-libraries into memory and execute it. Winelib on the other hand allows
+the other hand allows you to take the source for such a program and
-you to take the source for such a program and DLLs and compile it into
+DLLs and compile it into the native format of a x86 Unix or Linux
-the native format of a x86 Unix or Linux operating system. Winelib
+operating system. WineLib also allows you to partially compile the
-also allows you to partially compile the program and DLLs into the
+program and DLLs into the native format. For example, if you use a DLL
-native format. For example, if you use a DLL from a vendor to provide
+from a vendor to provide some functions to your program and the vendor
-some functions to your program and the vendor does not give you
+does not give you source, then you can use the Windows version of the
-source, then you can use the Windows version of the DLL to provide the
+DLL to provide the functions and compile the rest of your program in
-functions and compile the rest of your program in the native form for
+the native form for your system. [1]
-your system. 
 
 Windows compilers assume a different structure than standard
 compilers. For example, standard compilers assume that the function
 main() exists and is the entry point of the program. On the other
 hand, windows compilers create a main() that issues an error message
 that states that windows is required for executing the program and the
-real entry point is the function WinMain(). As a result, winelib
+real entry point is the function WinMain(). As a result, WineLib
 provides certain aids to generate code so that your program can be
-compiled and run as written for windows. For example, winelib
+compiled and run as written for windows. For example, WineLib
 generates a main() to initialize the windows API, to load any
-necessary DLLs and then call your WinMain(). Therefore you need to
+necessary DLLs and then call your WinMain(). Therefore, you need to
 learn four basic operations to compile a windows program using
-winelib: compiling a simple program, compiling resources, compiling
+WineLib: compiling a simple program, compiling resources, compiling
-libraries, and compiling MFC. These skills are operations are
+libraries, and compiling MFC. These skills or operations are explained
-explained in later sections of this HOWTO.
+in later sections of this HOWTO.
 
-Before you start porting your windows code to winelib, you need to
+Before you start porting your windows code to WineLib, you need to
-consider whether you are allowed to port your program to winelib. As
+consider whether you are allowed to port your program to WineLib. As
-you compile your program using winelib, you will be combining software
+you compile your program using WineLib, you will be combining software
 from several sources and you need to ensure that the licenses for the
-components is compatible. Hence in the next section, we will examine
+components are compatible. Hence, in the next section, we will examine
 several legal issues.
 
 II. Legal Issues
@@ -98,7 +100,7 @@ you aware of potential legal problems. Be sure to read your licenses
 and to consult your attorney.
 
 During the compilation of your program, you will be combining code
-from several sources: your code, winelib code, code from your vendor's
+from several sources: your code, WineLib code, code from your vendor's
 DLLs (if any), and Microsoft MFC code (if used). As a result, you must
 ensure that the licenses of all code sources are obeyed. What you are
 allowed and not allowed to do can vary depending on how you compile
@@ -112,11 +114,11 @@ you cannot statically link your program to MFC and distribute it, but
 you can dynamically link your LGPL code and MFC code and distribute
 it.
 
-Wine/Winelib is distributed under an X11-like license. It places few
+Wine/WineLib is distributed under an X11-like license. It places few
-restrictions on the use and distribution of Wine/Winelib code. I doubt
+restrictions on the use and distribution of Wine/WineLib code. I doubt
-the Wine license will cause you any problems. On the other hand MFC is
+the Wine license will cause you any problems. On the other hand, MFC
-distributed under a very restrictive license and the restrictions vary
+is distributed under a very restrictive license and the restrictions
-from version to version and between service packs.
+vary from version to version and between service packs.
 
 If you plan on using MFC, there are three hurdles to legally using
 MFC. The first hurdle is how to legally get MFC source code on your
@@ -129,6 +131,8 @@ Studio. Since Visual Studio is installed on the computer, you have not
 broken it into its components. There may be other solutions, but I
 think this is the easiest.
 
+FIXME: quote relevant sections of EULA in above paragraph.
+
 The second hurdle for MFC is the legality of compiling MFC on a
 non-Microsoft operating system. This varies with the version of MFC.
 
@@ -141,7 +145,7 @@ MFC license from Visual Studio 6.0:
     to operate in conjunction with any Microsoft operating system
     product. [Other unrelated stuff deleted.]
 
-So it appears you cannot compile MFC for Winelib using this
+So it appears you cannot compile MFC for WineLib using this
 license. On the other hand, Visual Studio 6.0 service pack 3 (Visual
 Studio 5.0 is similar):
 
@@ -151,7 +155,7 @@ Studio 5.0 is similar):
     developing, and testing your software product(s). [Other unrelated
     stuff deleted]
 
-So it appears you can compile MFC for Winelib using this license.
+So it appears you can compile MFC for WineLib using this license.
 
 The third hurdle is your legal right to distribute an MFC
 library. Check the relevant section of the license on redistributables
@@ -160,53 +164,58 @@ the right to distribute binaries of the MFC library if it has no debug
 information and if you distribute it with an application that provides
 significant added functionality to the MFC library.
 
+FIXME: quote relevant sections of EULA in above paragraph.
+
 Once you have examined the licenses for all of the sources used in
 compiling your program and have decided you can legally compile you
-program using winelib, you should probably experiment with your
+program using WineLib, you should probably experiment with your
-program running under wine to determine how much work will be involved
+program running under Wine to determine how much work will be involved
 in the port. The next section will give advice on estimating the
-amount of work required for porting your program to winelib.
+amount of work required for porting your program to WineLib.
 
 III. How Much Work?
 
-Wine and winelib use the same functions to implement the windows API;
+Wine and WineLib use the same functions to implement the windows API;
-hence, if your program correctly runs under wine, it should run under
+hence, if your program correctly runs under Wine, it should run under
-winelib. However, wine/winelib is incomplete. You may have trouble
+WineLib. However, Wine/WineLib is incomplete; you may have trouble
-running your program under wine. Many people have successfully run many
+running your program under Wine. Many people have successfully run many
-programs under wine, so there is a good chance you will have no
+programs under Wine, so there is a good chance you will have no
 trouble.
 
 Wine executes the binary program that was compiled for a windows
 operating system. There are differences between the windows operating
-system and Unix/Linux operating systems. For example, in Windows 3.x,
+system and Unix/Linux operating systems. For example, in Windows 95
-Windows 95, and Windows 98, the program has direct access to the
+and Windows 98, the program has direct access to the hardware. A copy
-hardware. A copy protection program that you purchased for your
+protection program that you purchased for your windows executable may
-windows executable may use direct hardware access to write data to the
+use direct hardware access to write data to the disk. Hence, you may
-disk. Hence, you may need to disable the copy protection in order to
+need to disable the copy protection in order to test your executable
-test your executable under wine.
+under Wine.
 
 As a specific example, CrypKey is a copy protection program we use at
-Lumin Software. Our program does not execute under wine with the copy
+Lumin Software. Our program does not execute under Wine with the copy
 protection enabled. We disabled the copy protection, recompiled the
 windows executable, and our program works fine. CrypKey also works for
-Windows NT where it creates a service. Using wine with the --winver
+Windows NT where it creates a service. Using Wine with the --winver
 nt40 option "almost" gets the our program working with copy
 protection. At a later date, we intend to either implement the system
-calls in wine that are missing for CrypKey or to use another copy
+calls in Wine that are missing for CrypKey or to use another copy
 protection program that does work under Linux.
 
-During the execution of your program, wine prints error messages to
+During the execution of your program, Wine prints error messages to
 standard error. These error messages include "stubs", which are
 windows API functions that have not been completely
 implemented. Depending on the the system call, these could be harmless
 or crash your program. Most of the common windows API functions have
 already been implemented, so you should have no missing API functions
 or only a few missing functions. If you intend to continue with the
-port to winelib, you will need to implement these API
+port to WineLib, you will need to implement these API
 functions. After running your program for a while, you should have a
 good feel for the number of windows API functions that you need to
 implement. 
 
+FIXME: give info on Wine command line options to control error
+messages. 
+
 It is not necessary for you to implement the entire documented
 behavior of an API function in order to get your program to work. For
 example, many API functions have pointer parameters that are NULL in
@@ -217,36 +226,149 @@ parameter. If you do this, make sure you test if the parameter is
 non-null and issue a warning for the non-null case. Also document in
 the source that the API function is incomplete.
 
+FIXME: give info on the FIXME (macro/function?) for partially
+implemented API functions.
+
 Once you have implemented an API function, submit the change back to
-the wine project so the next person to need the same function does not
+the Wine project so the next person to need the same function does not
 need to repeat your work. Remember, someone else wrote all of the
 other API functions that you are using, so you are benefiting from
 their work. Let other people benefit from your work as well. If you
 work for a company, you may need your company's permission to "give
 away" your work.
 
-IV. Compiling A Simple Win32 Program 
+IV. File Format Conversion
 
-Wine and Winelib are written in C as is the MS Win32/16 API; thus, if
+Before you can compile your program, you must deal with one major
+difference between Windows and WineLib. Window sources are in DOS
+format with carriage return / line feed at the end of each line of
+text while WineLib files are in Unix format with only line feed at the
+end of each line of text. Before you compile your sources, you will
+need to convert you DOS format sources to Unix format. There are
+several tools such as dos2unix and tr that are available to convert
+the format.
+
+FIXME: explain about line continuation in macros with CR/LF lines.
+
+FIXME: get more info on dos2unix, tr, and all other such tools and
+give example commands. Until I do [3] is a good source.
+
+FIXME: is CR/LF conversion necessary for gcc 2.95 ?
+
+V. Compiling A Simple Win32 Program 
+
+Wine and WineLib are written in C as is the MS Win32 API; thus, if
 have a program that calls only the Win32 API directly, you can compile
-the program using a C compiler and link it with some of the
+the program using a C compiler and link it with some of the WineLib
-wine/winelib libraries. For examples of how to do this, see the
+libraries. There are several simple examples of WineLib programs in
-directory libtest/ in the wine source tree.
+the directory libtest/ in the Wine source tree. We shall examine one
+of these to show you how to compile a WineLib program.
 
-FIXME: to be continued.
+The example we shall examine is hello2. If you examine hello2.c, you
-Describe spec file.
+will see it is a windows program that pops up a message box that says
-Go through hello world example 1 and 2.
+"Hello, hello!". It can be compiled and run using a windows compiler
+just like any other windows program. However, it can not be compiled
+and run with a non-windows compiler. As mentioned previously, windows
+programs have an entry point called WinMain(), while non-windows
+compilers use an entry point of main(). Hence, we need some "glue" to
+glue the main() entry point to the WinMain() in the windows program.
 
-V. Compiling A Win32 Program With Resources
+In WineLib, the glue is provided by the spec file. Spec files are used
+in several places in Wine and WineLib to provide glue between windows
+code and code for non-windows compilers. WineLib provides a tool
+called build in the tools/ directory that converts a spec file into a
+C file that can be compiled and linked with the windows source
+files. If you examine hello2.spec, you will see the following:
+
+name	hello2
+mode	guiexe
+type	win32
+init	WinMain
+
+Name is the name of the application. Mode is the type of "glue" that
+build needs to create. Possible modes are 'dll' for a library,
+'cuiexe' for a console application, and 'guiexe' for a regular
+graphical application. Type is the type of API, either win32 or
+win16. Win16 is supported only in Wine, not WineLib, so you should use
+win32. Init is the function to call for initialization: in this case,
+WinMain.
+
+FIXME: tools/build-spec.txt appears out of date. No "mode" is in the
+documentation. 
+
+During compilation of the hello2 executable, the following command is
+executed. 
+
+../tools/build -pic -o hello2.spec.c -spec hello2.spec
+
+The program build will generate the output file hello2.spec.c (option
+-o hello2.spec.c) from the spec file hello2.spec (option -spec
+hello2.spec). The output file contains some assembly directives and
+these directives are position independent code (option -pic). The
+build program is used in several places in Wine as well as WineLib;
+however, only the -spec option will be used in WineLib. The output
+file hello2.spec.c contains main() and the glue code to initialize
+WineLib and call WinMain().
+
+FIXME: for WineLib users -- is there ever a need to not specify -pic?
+
+Now the compilation of hello2 can proceed as any other compilation for
+a program.
+
+gcc -c -I. -I. -I../include -I../include -g -O2 -Wall  -D_REENTRANT \
+-I/usr/X11R6/include -o hello2.o hello2.c 
+
+FIXME: -D_REENTRANT why?
+FIXME: explain compiler options
+
+to compile the window program itself and 
+
+gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -D_REENTRANT \
+-I/usr/X11R6/include -o hello2.spec.o hello2.spec.c
+
+to compile the main() and the glue code. Finally,
+
+gcc -o hello2 hello2.o hello2.spec.o -L../dlls  -L.. -lwine -lncurses
+-lm  -lutil -ldl                                 
+
+FIXME: explain linker options
+
+will link the files into an executable. All of the steps are automated
+with the makefile, so "make hello2" will execute all of the steps for
+you. 
+
+Thus, you now have the basics of compiling a simple windows
+program. There are two more things to learn for compiling more complex
+windows programs: windows resources and DLL dependencies. Window
+resources are described in the next section. DLL dependencies are
+handled by linker magic with windows compilers. Thus, you will need to
+provide information about which DLLs your program depends. This
+information is given in the spec file. For example, if our hello2
+program had a .wav file that it played, it would need the multi-media
+DLL winmm. Our spec file would then be
+
+name	hello2
+mode	guiexe
+type	win32
+init	WinMain
+import  winmm
+
+If you need to list multiple DLLs, then the import specification can
+appear multiple times.
+
+FIXME: can multiple libraries appear on one import line?
+
+VI. Compiling A Win32 Program With Resources
 
 FIXME: to be continued.
 Describe wrc.
 Go through hello world example 3.
 
-VI. DLLs
+VII. DLLs
     A. Native DLL.
     B. so DLL.
     C. elfdll.
+    D. resource DLL
 
 FIXME: to be continued.
 QUESTION: what are so DLL and elfdll. I think I have been doing so
@@ -254,23 +376,73 @@ DLL.
 
 Go over an example similar to edrlib in Petzold.
 
-VII. How to use MFC
+VIII. How to use MFC
-    A. Using a native MFC dll
+    A. Using a native MFC DLL
     B. Compiling MFC
 
 FIXME: to be continued.
 
 =====================================================================
-The information included here is from various wine-devel posting and
+References
+
+Until this HOWTO is complete, I will document who gives me what
+information. 
+
+Reference [1] 
+From: Patrik Stridvall <ps@leissner.se>
+To: "'wilbur.dale@lumin.nl'" <wilbur.dale@lumin.nl>,
+Date:   Mon, 5 Jun 2000 14:25:22 +0200 
+
+First of all WineLib suppport for Win16 has been discontinued
+for quite some time, because:
+
+1. It is difficult for us to support and it is impossible
+   to do so prefectly without special compiler support,
+   because of memory layout issues. For example Win16 int
+   is 16-bit and data is aligned 16-bit.
+2. It is in almost all cases easier to port a
+   Win16 application to Win32.
+
+A minor detail, I personally would prefer that Wine and WineLib
+was always used in the uppercase W and uppercase L variant,
+instead of, as in your document, sometime one variant, sometimes
+another.
+
+Reference [2] 
+From: michael cardenas <mbc@deneba.com>
+To: wilbur.dale@lumin.nl
+Date:   Mon, 5 Jun 2000 13:19:34 -0400
+
+a few things you should mention...
+
+- you can compile resources as a dll under windows and then load the dll
+with wine. That's what we do for canvas. This is probably not ideal, but
+most of my problems porting were in the code. We very seldomly have to
+change the resources for the porting process. But wrc does work for most
+cases...
+
+- the error messages can be turned off or turned up with options to
+configure like --enable-trace-msgs=wireoff or --enable-trace-msgs=wireon .
+Take a look at configure.
+
+- you probably want to compile your WineLib with --disable-debugger, at
+least for the release version of your app.
+
+Reference [3] 
+http://fgouget/wine/winelib-en.shtml
+
+=====================================================================
+
+The information included here is from various Wine-devel posting and
 private e-mails. I am including them so that any one starting on MFC
 will have some documentation. Glean what you can and good luck.
 
 Before I write more detailed info on compiling MFC I have three
 questions. The info I have mentions three problems:
 
-    1. wine header files---what is the status of this? Do changes need
+    1. Wine header files---what is the status of this? Do changes need
     to be made in the headers and if so, do I submit the changes back
-    into wine cvs? Do the changes need #ifdef for C vs. C++
+    into Wine cvs? Do the changes need #ifdef for C vs. C++
     compilation? 
 
     2. DOS format files <CR/LF> and no case distinction in
@@ -288,7 +460,7 @@ If you have info that needs to be added, send me email at
 THANKS
 
 Most of the information in this file came from postings on
-<wine-devel@winehq.com> and from private e-mails. The following people
+<Wine-devel@Winehq.com> and from private e-mails. The following people
 contributed information for this document and I thank them for their
 time and effort in answering my questions. I also want to thank them
 for encouraging me to attack the MFC problem. 
@@ -306,7 +478,7 @@ Subject: Re: WineLib and MFC
 
 "Wilbur N. Dale" wrote:
 
-> What is the status of MFC under winelib?
+> What is the status of MFC under WineLib?
 
 I don't know precisely. Corel has done more MFC work than anyone (all
 of their applications which they are porting are MFC-based), and
@@ -323,12 +495,12 @@ fiddling with the headers for MFC 6 (from Visual C++ 6.0 Service Pack
 3). Most of the stuff my patch addressed was for newer IE 5-related
 features, so I'd guess MFC 5 (VC++ 5.0) is likely what they used.
 
-> Is there any documentation on how to compile MFC for winelib?  If so
+> Is there any documentation on how to compile MFC for WineLib?  If so
 > where?
 
 Not that I know of.
 
-> I have started to compile programs using winelib (hello.c last
+> I have started to compile programs using WineLib (hello.c last
 > Sunday) and expect to be ready to start compiling MFC in a couple of
 > weeks. If documentation is not available on compiling MFC, I am
 > willing to write it.
@@ -356,7 +528,7 @@ path, as MFC apps typically use #include <> to access them rather than
 compile on a case-insensitive filesystem :)
 
 - When you make install Wine it seems not to include all it's headers
-in /usr/local/include/wine. To have any chance at getting MFC going
+in /usr/local/include/Wine. To have any chance at getting MFC going
 you'll want to use -I to add the include/ directory from the Wine
 source tarball to the path so it can grab everything.
 
@@ -374,7 +546,7 @@ Subject: Re: RFC: Wine 1.0
 > > a modest set of changes to it, even with older
 > > versions of g++.
 > 
-> Lumin Software is about to use winelib to port a window program to linux. A
+> Lumin Software is about to use WineLib to port a window program to linux. A
 > couple of years ago we thought we had to make a modification to MFC for one
 > of our projects and we had problems getting MFC to compile under MS Visual C++.
 > After much wailing and gnashing of teeth, we gave up and did things another
@@ -385,7 +557,7 @@ Subject: Re: RFC: Wine 1.0
 had working versions of MFC with Wine have working versions any
 longer. So, it may be a bit trickier than I led you to believe.
 
-    We have it working pretty reliably with Twine, but not 
+    We have it working pretty reliably with TWine, but not 
 quite so cleanly (yet) with Wine. However, it really shouldn't
 be too difficult, and this is what I can remember of the process:
 
@@ -535,14 +707,14 @@ Hi,
 
 I manage to build mfc42 as .so library and a application using it (as
 a .so library too). I execute it using simple loader which is linked
-to wine and I load my application in it's WinMain routine. The
+to Wine and I load my application in it's WinMain routine. The
 problem is how clearly to unload mfc and my application (to invoke
 mfc's destructors before loader is terminated) All is fine except that
 there is a "zombi" reference to code in shared library which is
-invoked in wine code and generate GPF. debugger stops somewhere in
+invoked in Wine code and generate GPF. debugger stops somewhere in
 aplication's InitInstance !!! - and the stack is broken so I can't
 catch where exactly the problem is. Any hints are welcome. I'm using
-wine-2000517 shapshot downloaded form wine.datapary.no 
+Wine-2000517 shapshot downloaded form Wine.datapary.no 
 
 TNX.
 
@@ -566,7 +738,7 @@ mfcdll.rc
     PRODUCTVERSION    6,0,0,0
 
 Hints:
-    1. wine include files
+    1. Wine include files
 
 In some of them you will find error about '__attribute__' all kinds of
 similar errors can be fixed using proper typedefs first example :
@@ -606,7 +778,7 @@ extern inline P_TEB WINAPI NtCurrentTeb(void);
 Those conversions are semanticaly the same as above but g++ compile
 them and generate proper code to invoke __stdcall kind of functions
 
-in some of wine/obj_XXX.h files: wine/obj_base.h - there are a lot of
+in some of Wine/obj_XXX.h files: Wine/obj_base.h - there are a lot of
 defines's that are used to declare a COM interfaces
 
 #define ICOM_METHOD(ret,xfn) \
@@ -632,7 +804,7 @@ void* which can be replaced simply by LPVOID.
 qthere are several errors related to anonymous structs and unions but
 they can be avoided with proper - #ifdef __cplusplus
 
-This is all about wine headers I think. If you find something that I
+This is all about Wine headers I think. If you find something that I
 miss type a line of mail to me.
 
 2. MFC
@@ -664,7 +836,7 @@ compile MFC
 
 -DTWINE_NO_CMONIKER \ -- this is related to exclude
 CMonikerFile 
--D__urlmon_h__ \ -- wine didn't have URL interfaces 
+-D__urlmon_h__ \ -- Wine didn't have URL interfaces 
 -D_AFX_NO_OLEDB_SUPPORT \
 -D_WIN32  \
 -DNOWIN98  \ -- this is used to exclude all
@@ -686,7 +858,7 @@ unimplemented classes from commctrl
 -DLONGHANDLES
 
 may be you will try to enable some of features of mfc I tested only
--D_AFX_NO_OCC_SUPPORT but got missing interfaces from wine
+-D_AFX_NO_OCC_SUPPORT but got missing interfaces from Wine
 
 in file afxcom_.h
 - _CIP<_Interface, _IID>::~_CIP<_Interface, _IID>()
@@ -715,7 +887,7 @@ and all releated errors can be fixed in this way.
     use -rdynamic wnen link libmfc.so to get ARGV and
 ARGC from loader
     
-5. I didn'n build a extention dll with wine but I suspect that there
+5. I didn'n build a extention dll with Wine but I suspect that there
 will be some problems releated to a chaining Runtime classes form MFC
 to a new dll
 
@@ -797,22 +969,26 @@ MFC
 Regards 
 Damyan.
 
- LocalWords:  elfdll wrc devel cvs ifdef CR LF Corel gcc Damyan Ognyanoff app
+ LocalWords:  WineLib HOWTO Jun vs DLLs DLL MFC NT FIXME CrypKey Kenonic API TM
- LocalWords:  Gavriel MFC's Wine's IE VC underdocumented Google fromdos GCCs SP
+ LocalWords:  WinMain GPL LGPL EULA winver nt dos unix tr CR LF gcc libtest dll
- LocalWords:  fpermissive whereever apps symlink filesystem tarball RFC linux
+ LocalWords:  guiexe init cuiexe pic lwine lncurses lm lutil ldl wav winmm wrc
- LocalWords:  Urk misspoke structs DNO XXX Microsofts occassionaly WineHQ Gav
+ LocalWords:  elfdll edrlib Petzold Patrik Stridvall int michael cardenas msgs
- LocalWords:  TransGaming alright hairball Jer Visi IMHO MSVC EULA mfc mfc's rc
+ LocalWords:  wireoff msgs wireon app devel cvs ifdef Corel Damyan Ognyanoff IE
- LocalWords:  destructors zombi GPF aplication's InitInstance shapshot TNX RBLD
+ LocalWords:  Gavriel MFC's Wine's VC underdocumented Google fromdos GCCs apps
- LocalWords:  Bulid afxbld mfcdll FILEVERSION PRODUCTVERSION BOOL CALLBACK HWND
+ LocalWords:  fpermissive whereever symlink filesystem tarball RFC linux Urk SP
- LocalWords:  DLGPROC UINT WPARAM LPARAM WINAPI SomeFunction param TYPEPtr TEB
+ LocalWords:  misspoke TWine structs DNO XXX Microsofts occassionaly WineHQ Gav
- LocalWords:  TYPERef struct NtCurrentTeb semanticaly stdcall obj defines's COM
+ LocalWords:  TransGaming alright hairball Jer Visi IMHO MSVC nonexclusive mfc
- LocalWords:  ICOM ret xfn ifdef's ISomeInterfase IUnknown MethodName DWORD int
+ LocalWords:  mfc's destructors zombi GPF aplication's InitInstance shapshot rc
- LocalWords:  dwParam LPVOID qthere cplusplus AFXAPI nSize commctrl DTWINE URL
+ LocalWords:  TNX Bulid afxbld RBLD mfcdll FILEVERSION PRODUCTVERSION BOOL HWND
- LocalWords:  CMONIKER CMonikerFile urlmon AFX OLEDB DNOWIN DHTML SYNC OCX DAO
+ LocalWords:  CALLBACK DLGPROC UINT WPARAM LPARAM WINAPI SomeFunction param TEB
- LocalWords:  OCC INET RICHEDIT DLONGHANDLES afxcom CIP IID afxtempl ARG rValue
+ LocalWords:  param TYPEPtr TYPERef struct struct NtCurrentTeb semanticaly obj
- LocalWords:  const typename releated rsrc ptr rdynamic wnen libmfc ARGV ARGC
+ LocalWords:  stdcall obj defines's COM ICOM ret xfn ifdef's ISomeInterfase URL
- LocalWords:  didn'n extention iint winMain HINSTANCE LPSTR cdecl splitpath SW
+ LocalWords:  IUnknown MethodName DWORD dwParam LPVOID qthere cplusplus AFXAPI
- LocalWords:  LPCSTR makepath lpszCmdParam hInstance hins hlib htst hform himag
+ LocalWords:  nSize commctrl DTWINE CMONIKER CMonikerFile urlmon AFX OLEDB SYNC
- LocalWords:  hexe retv LoadLibrary CRTDLL GetProcAddress COMCTL COMDLG dlopen
+ LocalWords:  DNOWIN DHTML OCX DAO OCC INET RICHEDIT DLONGHANDLES afxcom CIP SW
- LocalWords:  libmxformatslib mxformatslib libmxpaint mxpaint FreeLibrary init
+ LocalWords:  IID CIP IID afxtempl ARG rValue const typename releated rsrc ptr
- LocalWords:  dlclose guiexe
+ LocalWords:  rdynamic wnen libmfc ARGV ARGC didn'n extention iint winMain hins
+ LocalWords:  HINSTANCE HINSTANCE LPSTR cdecl splitpath LPCSTR makepath hlib
+ LocalWords:  lpszCmdParam hInstance htst hform himag hexe retv LoadLibrary
+ LocalWords:  CRTDLL GetProcAddress COMCTL COMDLG dlopen libmxformatslib
+ LocalWords:  mxformatslib libmxpaint mxpaint FreeLibrary dlclose