WineLib HOWTO
Version 28-Dec-2000

AUTHOR: 
Wilbur Dale
Lumin Software BV
Zandheuvel 52 B
4901 HW Oosterhout (NB)
The Netherlands

wilbur.dale@lumin.nl

WARNING: This HOWTO is incomplete. I expect to add to it on a weekly
basis until it is complete.

=====================================================================

Table of Contents

   I. Introduction: Wine vs. WineLib

  II. Legal Issues

 III. How Much Work?

  IV. File Format Conversion

   V. Compiling A Simple Win32 Program 

  VI. Compiling A Win32 Program With Resources

 VII. DLLs
    A. Windows executable and Windows DLL.
    B. Windows executable and WineLib DLL.
    C. WineLib executable and Windows DLL.
    D. WineLib executable and WineLib DLL.

VIII. How to use MFC
    A. Using a native MFC DLL
    B. Compiling MFC

VIII. Trademarks
Windows 3.x, Windows 95, Windows 98, Windows NT are trademarks of
Microsoft Corporation. 

Unix is a trademark of ???? FIXME: who has the trademark this week?

CrypKey is a trademark of Kenonic Controls Ltd.

FIXME: Codewright copyright ???

All other trademarks are the property of their respective owners.

=====================================================================

I. Introduction: Wine vs. WineLib

WineLib provides the Win32 API to a non-Microsoft operating
system. The WineLib Win32 functions use X11 functions to perform the
actual drawing on the screen. Wine and WineLib are based on the same
set of functions that implement the Win32 API. The difference between
Wine and WineLib is the type of executable that is loaded into memory
and executed. If an executable and any associated DLLs were compiled
for x86 hardware running the Windows 95, 98, or Windows NT (TM)
operating systems, then Wine can use a special binary loader to load
the program and the libraries into memory and execute it. WineLib on
the other hand allows you to take the source for such a program and
DLLs and compile it into the native format of a x86 Unix or Linux
operating system. WineLib also allows you to partially compile the
program and DLLs into the native format. For example, if you use a DLL
from a vendor to provide some functions to your program and the vendor
does not give you source, then you can use the Windows version of the
DLL to provide the functions and compile the rest of your program in
the native form for your system. [1]

Windows compilers and linkers generate executables with a different
structure than standard compilers. Windows has two executable formats:
the NE format and the PE format. The NE executable format provides for
two entry points and the PE format provides for three entry points
while a standard executable has a single entry point. Usually, a NE or
a PE executable will use one of the entry points for your program and
the other entry points will print an error message and exit. However,
a linker can link 16 bit objects into one or both of the alternate
entry points of a NE or PE executable.

Standard compilers assume that the function main() exists. The entry
point for a standard program is constructed from the C runtime
library, initialization code for static variables in your program, the
initialization code for your classes (C++), and your function main().
On the other hand, windows compilers assume WinMain() exists. The
entry point for a windows program is constructed from the C runtime
library, initialization code for static variables in your program, the
initialization code for your classes (C++), and your function
WinMain(). [4]

Since main() and WinMain() have different type signatures (parameter
types), WineLib provides certain aids to generate code so that your
program can be 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
learn four basic operations to compile a windows program using
WineLib: compiling a simple program, compiling resources, compiling
libraries, and compiling MFC (if you will be using MFC). Each of these
skills or operations are explained in later sections of this HOWTO.

Before you start porting your windows code to WineLib, you need to
consider whether you are allowed to port your program to WineLib. As
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 are compatible. Hence, in the next section, we will examine
several legal issues.


IV. File Format Conversion

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. 

The main problem with the difference between Unix and DOS format
source files occurs with macro line continuation. A Unix compiler
expects a backslash (\) followed by a newline (^J) to indict that a
macro is continued on the next line. However, a file in DOS format will
have the characters backslash (\), carriage return (^M), and newline
(^J). The Unix compiler will interpret the backslash (\), carriage
return (^M), newline (^) of a file in DOS format as a quoted carriage
return and newline. The Unix compiler will think the line has ended
and the macro is completely defined. Hence, 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: 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 WineLib
libraries. There are several simple examples of WineLib programs in
the directory libtest/ in the Wine source tree. We shall examine one
of these to show you how to compile a WineLib program.

The example we shall examine is hello2. If you examine hello2.c, you
will see it is a windows program that pops up a message box that says
"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.

In WineLib, some of 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 winebuild in the tools/winebuild 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

import	user32.dll
import	kernel32.dll
import	ntdll.dll

Information on the complete format of the spec file can be found in
<wine>/tools/winebuild/README. Name is the name of the
application. Mode is the type of "glue" that winebuild 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. Import is a dll that must
be loaded for the program to execute.

During compilation of the hello2 executable, the following command is
executed. 

LD_LIBRARY_PATH="..:$LD_LIBRARY_PATH" \
    ../tools/winebuild/winebuild -fPIC -L ../dlls -sym hello2.o \
    -o hello2.spec.c -spec hello2.spec

The program winebuild will generate the output file hello2.spec.c (option
-o hello2.spec.c) from the spec file hello2.spec (option -spec
hello2.spec). The option -fPIC specifies that winebuild should generate
position independent code and is only necessary for building shared
library files (.so files). It is not needed when building the main
executable spec file, but since there is no assembly code generated
for the main executable, it doesn't make any difference anyway. [5]

The winebuild 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 the glue code to initialize WineLib
and call WinMain().

In order to run hello2, we will compile the code into a shared library
(hello2.so) and create a symbolic link (hello2) with the wine
executable with the following steps.

gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -DSTRICT \
    -D_REENTRANT -I/usr/X11R6/include -o hello2.o hello2.c

to compile the windows program itself and 

gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -DSTRICT \
    -D_REENTRANT -I/usr/X11R6/include -o hello2.spec.o hello2.spec.c

to compile the spec file and the glue code. Finally,

gcc -shared  -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o hello2.so \
    hello2.o hello2.spec.o -L.. -lwine -lncurses -lm  -lutil -ldl

links the compiled files into a shared library.

FIXME: -D_REENTRANT why?
FIXME: explain compiler options
FIXME: explain linker options

All of the steps are automated with the makefile, so "make hello2.so"
will execute all of the steps for you.  A final step is "make hello2",
which creates a symbolic link from hello2 to the wine executable. Now,
when "./hello2" is run, the wine executable sees it was called by the
name "hello2" and loads the shared library "hello2.so" and executes
the program.

THE INFO BELOW IS OUT OF DATE (28-Dec-2000)

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, in WineLib, 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, one line per imported DLL.

VII. DLLs

As mentioned in the introduction, Wine allows you to execute windows
executables and windows libraries under non-Microsoft operating
systems. WineLib allows you to take sources intended for the windows
operating system and to compile them to run as native executables
under a Unix/Linux operating system. With an executable and a single
library, there are four combinations in which to run the programs and
the library:
    1. a Windows executable with a Windows DLL,
    2. a Windows executable with WineLib DLL,
    3. a WineLib executable with Windows DLL, and
    4. a WineLib executable with WineLib DLL.
In this section, we will discuss each of these and discuss the steps
required to implement the executable/DLL combination. 

A. Windows executable and Windows DLL

Running a windows executable with a windows DLL is not a WineLib
program: it is a Wine program. If you type
    wine program.exe
and the DLL is in the search path, then the windows program should run
using the windows DLL.

FIXME: find out what is the search path.

B. Windows executable and WineLib DLL

Running a windows executable with a WineLib DLL is also accomplished
using the Wine program. The source code for the DLL is compiled into a
Unix style shared library. When the windows executable "loads" the
DLL, Wine will use the shared library (.so file) instead.

At first you may wonder why you would want to run a windows executable
with a WineLib DLL. Such a situation implies you do not have the
source for the executable, but you do have the source for the
DLL. This is backwards from what you might expect. However, I do have
an example where this situation might arise.

Codewright is a popular editor in the windows world, and the
capabilities of Codewright can be extended by using DLLs. Since
Codewright is a commercial product, you do not have the source and
must use the windows executable with Wine. If you have written a DLL
to add functionality to Codewright, you have two choices: you can
compile the DLL using a windows compiler and use both a windows
executable and a windows DLL as in case A above, or you can use
WineLib and compile the DLL as a shared library (.so file). I have no
idea if Codewright actually runs under Wine, but this is an example of
why you might decide to use a windows executable and a WineLib
DLL. Many other editors and other programs use DLLs to extend their
functionality.

In order for Wine to use the WineLib DLL, certain glue code is need to
replace the linker magic that windows compilers use. As with a simple
executable, the winebuild program uses a spec file to generate the glue
code. For example, in the spec file for the DLL will look something like
    name	winedll
    type	win32
    init	winedll_DllMain
    1 cdecl _WINEbirthDay@4 ( str ) WINEbirthDay
    2 cdecl _WINEfullName@4 ( str ) WINEfullName
The name is the name of the DLL. Since WineLib only supports win32,
the type should always be win32. The init function is the name of the
initialization function for the DLL. The initialization function for a
windows DLL is named DllMain(). You will need to rename the function
in the DLL source so there will not be any name clashes with the
DllMain() of other DLLs in you program.

The last two lines of the spec file above, provide the export
information for the DLL. For example, the line
    1 cdecl _WINEbirthDay@4 ( str ) WINEbirthDay
says that the function at ordinal 1 uses the cdecl calling convention
for the parameters. The DLL export name is _WINEbirthDay@4. The
function takes a single parameter that is a string. Finally, the C
function name to be called whenever this DLL function is called is
WINEbirthday. You will need a function ordinal line for each function
in the DLL. The export name and the ordinal can be obtained from the
windows program dumpbin and the windows version of the DLL. See the
file <wine>/tools/winebuild/README for more details on the spec file
format.

During the compile process, a command like
    winebuild -fPIC -o winedll.spec.c -spec winedll.spec
will be executed to create the file winedll.spec.c from information in
the file winedll.spec. The file winedll.spec.c and winedll.c are
compiled into object files and used to create the shared library.

In order for the program to run, a copy of the shared library must be in
your EXTRA_LD_LIBRARY_PATH. For example, if your wine.conf file has
the following line,
    EXTRA_LD_LIBRARY_PATH=${HOME}/wine/lib
then you must copy the shared library into the directory ~/wine/lib/
and the shared library will now be in the correct search path.

Now when you type 
    wine program.exe
the program will load the shared library (.so).

C. WineLib executable and Windows DLL

Running a WineLib executable with a Windows DLL is accomplished
using WineLib. This situation will be common since you may have
purchased DLLs to use with you project and the DLL vendor may not give
you the source code for the DLL.

In order for WineLib to use the Windows DLL, certain glue code is
needed to replace the linker magic that windows compilers use. Part of
the glue code must be written by you. The basic idea of the glue code
is that you write a new DLL that consists of function pointers. Each
function in the DLL will consist of a call on a function pointer. For
example, 
    WINEDLL_ConstString WINEDLL_INTERFACE 
    WINEfullName( WINEDLL_ConstString handle ) {
        return (* pWINEfullName) ( handle );
    }
The initialization function for the DLL will use the function
LoadLibrary() to load the windows DLL and initialize the function
pointers using the function GetProcAddress(). 

Since Wine can use either windows DLLs or Unix shared libraries (.so),
the LoadLibrary() function call may have unexpected results if there
is a winedll.dll and a winedll.so file. Hence, the windows version of
the DLL should be named something like hiddenWinedll.dll and the
shared library should be named winedll.so. Now the shared library will
use LoadLibrary() to load the "hidden" DLL.

The shared library will need a spec file. Fortunately, it is simpler
than case B above. The spec file will look something like
    name	winedll
    type	win32
    init	winedll_DllMain
The name is the name of the DLL. Since WineLib only supports win32,
the type should always be win32. The init function is the name of the
initialization function for the shared library. This is the function
that will load the "hidden" DLL and initialize the function
pointers. There is no need for any function ordinals unless your
program calls functions by the ordinal.

During the compile process, a command like
    winebuild -fPIC -o winedll.spec.c -spec winedll.spec
will be executed to create the file winedll.spec.c from information in
the file winedll.spec. The file winedll.spec.c and winedll.c are
compiled into object files and used to create the shared library.

Now that the shared library is compiled, you still need to compile
your program. Part of the compile process for your program will
consist of a spec file for your program. For example,
    name	program
    mode	guiexe
    type	win32
    init	WinMain
    import winedll.dll
This spec file is similar to the spec file of the simple WineLib
example in part V above. The only difference is the import
specification that tells WineLib that the main program uses
winedll.dll. If this import line is not included, the "hidden" DLL
will not be loaded and the function pointers will not be initialized.

During the compile process, a command like
    winebuild -fPIC -o program.spec.c -spec program.spec
will be executed to create the file program.spec.c from information in
the file program.spec. The file program.spec.c and your source code are
compiled into object files and used to create the executable.

D. WineLib executable and WineLib DLL.

Running a WineLib executable with a WineLib DLL is accomplished using
WineLib. The source for the DLL will be combined with a spec file to
generate the shared library. Likewise, the source for your program and
a spec file will be combined to create the executable. In the source
for the DLL, you should change the name of DllMain() to a name like
winedll_DllMain() so that there will not be a name clash with other
initialization functions for other DLLs.

The shared library's spec file is like case C above. The spec file
will look something like
    name	winedll
    type	win32
    init	winedll_DllMain
The init function is the name of the initialization function for the
shared library (what you renamed DllMain to). There is no need for any
function ordinals unless your program calls functions by the ordinal.

During the compile process, a command like
    winebuild -fPIC -o winedll.spec.c -spec winedll.spec
will be executed to create the file winedll.spec.c from information in
the file winedll.spec. The file winedll.spec.c and the source code for
your DLL are compiled into object files and used to create the shared
library.

Compiling your program is exactly like case C above. For example, the
spec file for you program will look something like
    name	program
    mode	guiexe
    type	win32
    init	WinMain
    import winedll.dll

During the compile process, a command like
    winebuild -fPIC -o program.spec.c -spec program.spec
will be executed to create the file program.spec.c from information in
the file program.spec. The file program.spec.c and your source code are
compiled into object files and used to create the executable.

VIII. How to use MFC
    A. Using a native MFC DLL
    B. Compiling MFC

FIXME: to be continued.

=====================================================================
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 perfectly 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] 

The exact options for controlling error messages mentioned in the
reference are apparently incorrect, but may have been correct for some
earlier version of Wine.

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.free.fr/wine/winelib-en.shtml

Reference [4]
Date: Wed, 21 Jun 2000 10:34:10 +0200
From: Rob Carriere <rob.carriere@lumin.nl>
To: Wilbur N Dale <wilbur.dale@lumin.nl>
Subject: WineLib-HOWTO comments

Hello Wilbur,

Some picking of nits.  It reads right well.

Some of Windows xyz are registered trade marks, other are vanilla:
Microsoft: Registered
Windows NT: Registered
Windows (95,98): plain

A Windows compiler does NOT generate a fake main.  Instead, the
executable file format provides for 2 (NE) or 3 (PE) entry points.
One of these is your program, the other(s) are normally filled with
stubs that print an error message and exit.  It is possible to instruct
the _linker_ to link 16-bit objects into one or both of the alternate
entry points, and create a fat binary.

At the C/C++ level, your statement about WinMain() is correct.  Of
course the actual entry point first inits run time lib etc, and then
calls the C/C++ level entry, but that is also true for main() in the
standard setup.  It may be important to regurgitate this info here,
though, because some of the fun things that can happen with multiple
run time libs and DLLs occur at this level.

Line 86: I only need to know how compile MFC if I use it... :-)


Best regards,
 Rob                          mailto:rob.carriere@lumin.nl

Reference [5]
To: wilbur.dale@lumin.nl
Subject: Re: tool/build questions
From: Alexandre Julliard <julliard@winehq.com>
Date:   13 Jun 2000 20:06:23 -0700

"Wilbur N. Dale" <wilbur.dale@lumin.nl> writes:

> 2. tools/build for WineLib users -- is there ever a need to not specify -pic?

-pic is only necessary for building .so files, so it's not needed when
building the main executable spec file (but since there is no assembly
code generated for the main exe it doesn't make any difference anyway).

-- 
Alexandre Julliard
julliard@winehq.com

Reference [6]
Wine Weekly News #51 (2000 Week 28)

Events, progress, and happenings in the Wine community for 
July 10, 2000. 

Uwe Bonnes and Ove Kaven also reminded of some tools to generate under
   Linux some Windows executables:
     * Cygwin/Mingw: as native Linux apps
     * LCC-Win32: run with the help of Wine
     * Borland C++ 5.5: command line version available for free (after
       registering to Borland users' database)
       
=====================================================================

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
    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++
    compilation? 

    Francois Gouget <fgouget@psn.net> has been doing a lot of work in
    this area. It should be a lot easier to compile using C++ now and to
    compile MFC.

    2. DOS format files <CR/LF> and no case distinction in
    filenames. Do the extensions Corel made to gcc 2.95 handle this?
    If so, how?

    3. Microsoft extensions to the C++ syntax. Do the extensions Corel
    made to gcc 2.95 handle this? If so, how?

If you have info that needs to be added, send me email at
<wilbur.dale@lumin.nl> and I will add it.

=====================================================================

THANKS

Most of the information in this file came from postings on
<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. 

CONTRIBUTERS:

    Damyan Ognyanoff <Damyan@rocketmail.com>
    Gavriel State <gav@magmacom.com>
    Ian Schmidt <ischmidt@cfl.rr.com>
    Jeremy White <jwhite@codeweavers.com>


From: Damyan Ognyanoff <Damyan@rocketmail.com>
Subject: Re: Wine MFC info request

hi,
my MFC is from VC6.0 with SP3
MFC Bulid: (form  afxbld_.h)
    #define _MFC_BUILD 8447
    #define _MFC_USER_BUILD "8447"
    #define _MFC_RBLD 0
mfcdll.rc
    FILEVERSION       6,0,_MFC_BUILD,_MFC_RBLD
    PRODUCTVERSION    6,0,0,0

Hints:
    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 :

typedef BOOL (CALLBACK *DLGPROC)(HWND,UINT,WPARAM,LPARAM);

must be converted to

typedef BOOL CALLBACK (*DLGPROC)(HWND,UINT,WPARAM,LPARAM);

and the second kind is something like

TYPE* WINAPI SomeFunction(HWND param1,UINT param2);

The problem here is a TYPE* or TYPE& (in some of mfc files) the
workaround is to declare a type before:

typedef TYPE* TYPEPtr; 

or

typedef TYPE& TYPERef;

and declaration will look like:

TYPEPtr WINAPI SomeFunction(HWND param1,UINT param2);

note: don't miss a 'struct' when you define struct type pointers. I
miss it and get a lot of problems compiling MFC:

>>
struct _TEB;
typedef !!!struct!!! _TEB* P_TEB;
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
defines's that are used to declare a COM interfaces

#define ICOM_METHOD(ret,xfn) \
     public: virtual ret (CALLBACK xfn)(void) = 0;

will be (for all of them that are related to C++ (watch #ifdef's
carefully)):

#define ICOM_METHOD(ret,xfn) \
     public: virtual ret CALLBACK (xfn)(void) = 0;

and the second tip is an error when compiler stops on line like:
 
   ICOM_DEFINE(ISomeInterfase,IUnknown)

watch method declarations above to find something like:

ICOM_METHOD1(TYPE*,MethodName, DWORD,dwParam)

and replace TYPE* with proper TYPEPtr type. In many cases You will see
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
miss type a line of mail to me.

2. MFC
The rules are the same with some new issues:

virtual BOOL Method1(int param1, BOOL (CALLBACK *param2)
(HWND,UINT,WPARAM,LPARAM));

don't compile. I remove a function pointer declaration
outside method:

typedef BOOL CALLBACK
(*param2Type)(HWND,UINT,WPARAM,LPARAM);

virtual BOOL Method1(int param1, param2Type param2);

I didn't apply this technique to a operator new
definitions:

        void* AFXAPI operator new(size_t nSize);

so i remove AFXAPI from these declarations:

I got some missed #defines from commctrl.h and I added
them form VC6.0 include.

these are my defines form Makefile which I used to
compile MFC

-DTWINE_NO_CMONIKER \ -- this is related to exclude
CMonikerFile 
-D__urlmon_h__ \ -- Wine didn't have URL interfaces 
-D_AFX_NO_OLEDB_SUPPORT \
-D_WIN32  \
-DNOWIN98  \ -- this is used to exclude all
unimplemented classes from commctrl 
-D_AFX_PACKING \
-D_AFX_NO_DHTML_SUPPORT \
-D_AFX_NO_SOCKET_SUPPORT \
-D_AFX_NO_SYNC_SUPPORT \
-D_AFX_NO_OCX_SUPPORT  \
-D_AFX_PORTABLE \
-D_AFX_OLD_EXCEPTIONS \
-D_AFX_NO_SOCKET_SUPPORT \
-D_AFX_NO_DEBUG_CRT \
-D_AFX_NO_DAO_SUPPORT \
-D_AFX_NO_OCC_SUPPORT \
-D_AFX_NO_INET_SUPPORT \
-D_AFX_NO_RICHEDIT_SUPPORT  \
-D_X86_ \
-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

in file afxcom_.h
- _CIP<_Interface, _IID>::~_CIP<_Interface, _IID>()
+ _CIP<_Interface, _IID>::~_CIP()

in file afxtempl.h
-       BOOL Lookup(BASE_CLASS::BASE_ARG_KEY key,
VALUE& rValue) const
-               { return BASE_CLASS::Lookup(key,
(BASE_CLASS::BASE_VALUE&)rValue); }
+       BOOL Lookup(typename BASE_CLASS::BASE_ARG_KEY
key, VALUE& rValue) const
+               { return BASE_CLASS::Lookup(key,
(typename BASE_CLASS::BASE_VALUE&)rValue); }

and all releated errors can be fixed in this way.

3. spec file
    name        mfc42
    type        win32
    rsrc        mfc42

    10 stdcall WinMain(long long ptr long) WinMain

4. linking 
    use -rdynamic wnen link libmfc.so to get ARGV and
ARGC from loader
    
5. I didn'n build a extension dll with Wine but I suspect that there
will be some problems related to a chaining Runtime classes form MFC
to a new dll

6. build your app as a MODULE too.

7. make a loader and in it's _WinMain:
... includes are here
iint PASCAL (*winMain)(HINSTANCE,HINSTANCE,LPSTR,int) =
0;
my app uses these to manage filenames
VOID __cdecl (*_splitpath1)(LPCSTR path, LPSTR drive,
LPSTR directory, LPSTR filename, LPSTR extension ) =
NULL;
VOID __cdecl _splitpath(LPCSTR path, LPSTR drive,
LPSTR directory, LPSTR filename, LPSTR extension )
{
    if (_splitpath1)
        _splitpath1(path, drive, directory, filename,
extension );
}
VOID __cdecl (*_makepath1)(LPSTR path, LPCSTR drive,
LPCSTR directory, LPCSTR filename, LPCSTR extension )
= NULL;
VOID __cdecl _makepath(LPSTR path, LPCSTR drive,
LPCSTR directory, LPCSTR filename, LPCSTR extension )
{
    if (_makepath1)
        _makepath1(path, drive, directory, filename,
extension);
}
int PASCAL _WinMain(HINSTANCE h,HINSTANCE h1,LPSTR
lpszCmdParam,int c)
{
  HINSTANCE hInstance,hins,hlib,htst,hform,himag,hexe;
        int retv;

        hins = LoadLibrary("CRTDLL.DLL");
        _splitpath1 = GetProcAddress(hins,
"_splitpath");
        _makepath1 = GetProcAddress(hins,
"_makepath");
        hins = LoadLibrary("COMCTL32.DLL");
        hins = LoadLibrary("COMDLG32.DLL");


        hins = dlopen("libmfc42.so",2);
        hlib = LoadLibrary("mfc42");
        himag = dlopen("libmxformatslib.so",2);
        hform = LoadLibrary("mxformatslib");
        hexe = dlopen("libmxpaint.so",2);
        htst = LoadLibrary("mxpaint");

        winMain = GetProcAddress(hlib, "WinMain");
        if (winMain)
        {
          retv = winMain (htst,    // note the > htst
< HERE
                  0,            
                  lpszCmdParam, 
                  SW_NORMAL);   
        }
    FreeLibrary(htst);
    FreeLibrary(hform);
    FreeLibrary(hlib);
    dlclose(hexe);
    dlclose(himag);
    dlclose(hins);
    return retv;
}
the spec for loader is:
name    c10
mode    guiexe
type    win32
init    _WinMain

please find attached a Makefile which i use to build
MFC

Regards 
Damyan.