Window activation cleanups.
[wine] / documentation / HOWTO-winelib
1 WineLib HOWTO
2 Version 28-Dec-2000
3
4 AUTHOR: 
5 Wilbur Dale
6 Lumin Software BV
7 Zandheuvel 52 B
8 4901 HW Oosterhout (NB)
9 The Netherlands
10
11 wilbur.dale@lumin.nl
12
13 WARNING: This HOWTO is incomplete. I expect to add to it on a weekly
14 basis until it is complete.
15
16 =====================================================================
17
18 Table of Contents
19
20    I. Introduction: Wine vs. WineLib
21
22   II. Legal Issues
23
24  III. How Much Work?
25
26   IV. File Format Conversion
27
28    V. Compiling A Simple Win32 Program 
29
30   VI. Compiling A Win32 Program With Resources
31
32  VII. DLLs
33     A. Windows executable and Windows DLL.
34     B. Windows executable and WineLib DLL.
35     C. WineLib executable and Windows DLL.
36     D. WineLib executable and WineLib DLL.
37
38 VIII. How to use MFC
39     A. Using a native MFC DLL
40     B. Compiling MFC
41
42 VIII. Trademarks
43 Windows 3.x, Windows 95, Windows 98, Windows NT are trademarks of
44 Microsoft Corporation. 
45
46 Unix is a trademark of ???? FIXME: who has the trademark this week?
47
48 CrypKey is a trademark of Kenonic Controls Ltd.
49
50 FIXME: Codewright copyright ???
51
52 All other trademarks are the property of their respective owners.
53
54 =====================================================================
55
56 I. Introduction: Wine vs. WineLib
57
58 WineLib provides the Win32 API to a non-Microsoft operating
59 system. The WineLib Win32 functions use X11 functions to perform the
60 actual drawing on the screen. Wine and WineLib are based on the same
61 set of functions that implement the Win32 API. The difference between
62 Wine and WineLib is the type of executable that is loaded into memory
63 and executed. If an executable and any associated DLLs were compiled
64 for x86 hardware running the Windows 95, 98, or Windows NT (TM)
65 operating systems, then Wine can use a special binary loader to load
66 the program and the libraries into memory and execute it. WineLib on
67 the other hand allows you to take the source for such a program and
68 DLLs and compile it into the native format of a x86 Unix or Linux
69 operating system. WineLib also allows you to partially compile the
70 program and DLLs into the native format. For example, if you use a DLL
71 from a vendor to provide some functions to your program and the vendor
72 does not give you source, then you can use the Windows version of the
73 DLL to provide the functions and compile the rest of your program in
74 the native form for your system. [1]
75
76 Windows compilers and linkers generate executables with a different
77 structure than standard compilers. Windows has two executable formats:
78 the NE format and the PE format. The NE executable format provides for
79 two entry points and the PE format provides for three entry points
80 while a standard executable has a single entry point. Usually, a NE or
81 a PE executable will use one of the entry points for your program and
82 the other entry points will print an error message and exit. However,
83 a linker can link 16 bit objects into one or both of the alternate
84 entry points of a NE or PE executable.
85
86 Standard compilers assume that the function main() exists. The entry
87 point for a standard program is constructed from the C runtime
88 library, initialization code for static variables in your program, the
89 initialization code for your classes (C++), and your function main().
90 On the other hand, windows compilers assume WinMain() exists. The
91 entry point for a windows program is constructed from the C runtime
92 library, initialization code for static variables in your program, the
93 initialization code for your classes (C++), and your function
94 WinMain(). [4]
95
96 Since main() and WinMain() have different type signatures (parameter
97 types), WineLib provides certain aids to generate code so that your
98 program can be compiled and run as written for windows. For example,
99 WineLib generates a main() to initialize the windows API, to load any
100 necessary DLLs and then call your WinMain(). Therefore, you need to
101 learn four basic operations to compile a windows program using
102 WineLib: compiling a simple program, compiling resources, compiling
103 libraries, and compiling MFC (if you will be using MFC). Each of these
104 skills or operations are explained in later sections of this HOWTO.
105
106 Before you start porting your windows code to WineLib, you need to
107 consider whether you are allowed to port your program to WineLib. As
108 you compile your program using WineLib, you will be combining software
109 from several sources and you need to ensure that the licenses for the
110 components are compatible. Hence, in the next section, we will examine
111 several legal issues.
112
113 II. Legal Issues
114
115 Disclaimer! I am not a lawyer. The purpose of this section is to make
116 you aware of potential legal problems. Be sure to read your licenses
117 and to consult your attorney.
118
119 During the compilation of your program, you will be combining code
120 from several sources: your code, WineLib code, code from your vendor's
121 DLLs (if any), and Microsoft MFC code (if used). As a result, you must
122 ensure that the licenses of all code sources are obeyed. What you are
123 allowed and not allowed to do can vary depending on how you compile
124 your program and if you will be distributing it. For example, if you
125 are releasing your code under the GPL, you cannot link your code to
126 MFC code because the GPL requires that you provide ALL sources to your
127 users. The MFC license forbids you from distributing the MFC source so
128 you can not comply with the GPL license except by not distributing you
129 program. On the other hand, if your code is released under the LGPL,
130 you cannot statically link your program to MFC and distribute it, but
131 you can dynamically link your LGPL code and MFC code and distribute
132 it.
133
134 Wine/WineLib is distributed under an X11-like license. It places few
135 restrictions on the use and distribution of Wine/WineLib code. I doubt
136 the Wine license will cause you any problems. On the other hand, MFC
137 is distributed under a very restrictive license and the restrictions
138 vary from version to version and between service packs.
139
140 If you plan on using MFC, there are three hurdles to legally using
141 MFC. The first hurdle is how to legally get MFC source code on your
142 computer. MFC source code comes as a part of Visual Studio. The
143 license for Visual Studio implies it is a single product that can not
144 be broken up into its components. The cleanest way to get MFC on you
145 system is to use a dual boot Linux box with the windows partition
146 visible to the Linux OS. Boot into windows and install Visual
147 Studio. Since Visual Studio is installed on the computer, you have not
148 broken it into its components. There may be other solutions, but I
149 think this is the easiest.
150
151 FIXME: quote relevant sections of EULA in above paragraph.
152
153 The second hurdle for MFC is the legality of compiling MFC on a
154 non-Microsoft operating system. This varies with the version of MFC.
155
156 MFC license from Visual Studio 6.0:
157
158     1.1 General License Grant. Microsoft grants to you as an
159     individual, a personal, nonexclusive license to make and use
160     copies of the SOFTWARE PRODUCT for the sole purposes of designing,
161     developing, and testing your software product(s) that are designed
162     to operate in conjunction with any Microsoft operating system
163     product. [Other unrelated stuff deleted.]
164
165 So it appears you cannot compile MFC for WineLib using this
166 license. On the other hand, Visual Studio 6.0 service pack 3 (Visual
167 Studio 5.0 is similar):
168
169     1.1 General License Grant. Microsoft grants to you as an
170     individual, a personal, nonexclusive license to make and use
171     copies of the SOFTWARE PRODUCT for the purpose of designing,
172     developing, and testing your software product(s). [Other unrelated
173     stuff deleted]
174
175 So it appears you can compile MFC for WineLib using this license.
176
177 The third hurdle is your legal right to distribute an MFC
178 library. Check the relevant section of the license on redistributables
179 and your redistribution rights. As I read the license, you only have
180 the right to distribute binaries of the MFC library if it has no debug
181 information and if you distribute it with an application that provides
182 significant added functionality to the MFC library.
183
184 FIXME: quote relevant sections of EULA in above paragraph.
185
186 Once you have examined the licenses for all of the sources used in
187 compiling your program and have decided you can legally compile you
188 program using WineLib, you should probably experiment with your
189 program running under Wine to determine how much work will be involved
190 in the port. The next section will give advice on estimating the
191 amount of work required for porting your program to WineLib.
192
193 III. How Much Work?
194
195 Wine and WineLib use the same functions to implement the windows API;
196 hence, if your program correctly runs under Wine, it should run under
197 WineLib. However, Wine/WineLib is incomplete; you may have trouble
198 running your program under Wine. Many people have successfully run many
199 programs under Wine, so there is a good chance you will have no
200 trouble.
201
202 Wine executes the binary program that was compiled for a windows
203 operating system. There are differences between the windows operating
204 system and Unix/Linux operating systems. For example, in Windows 95
205 and Windows 98, the program has direct access to the hardware. A copy
206 protection program that you purchased for your windows executable may
207 use direct hardware access to write data to the disk. Hence, you may
208 need to disable the copy protection in order to test your executable
209 under Wine.
210
211 As a specific example, CrypKey is a copy protection program we use at
212 Lumin Software. Our program does not execute under Wine with the copy
213 protection enabled. We disabled the copy protection, recompiled the
214 windows executable, and our program works fine. CrypKey also works for
215 Windows NT where it creates a service. Using Wine with the --winver
216 nt40 option "almost" gets the our program working with copy
217 protection. At a later date, we intend to either implement the system
218 calls in Wine that are missing for CrypKey or to use another copy
219 protection program that does work under Linux.
220
221 During the execution of your program, Wine prints error messages to
222 standard error. These error messages include "stubs", which are
223 windows API functions that have not been completely
224 implemented. Depending on the the system call, these could be harmless
225 or crash your program. Most of the common windows API functions have
226 already been implemented, so you should have no missing API functions
227 or only a few missing functions. If you intend to continue with the
228 port to WineLib, you will need to implement these API
229 functions. After running your program for a while, you should have a
230 good feel for the number of windows API functions that you need to
231 implement. 
232
233 FIXME: give info on Wine command line options to control error
234 messages. 
235
236 During the compilation of Wine, you can control the amount of error
237 messages and debug information that will be be generated by Wine and
238 WineLib. For the version released to your customers, you may want to
239 use the following command line to configure the Wine/WineLib
240 libraries.
241
242 ./configure --disable-debug --disable-trace
243
244 The option --disable-debug compiles out all debugging messages and the
245 option --disable-trace compile out TRACE messages. [2] 
246
247 It is not necessary for you to implement the entire documented
248 behavior of an API function in order to get your program to work. For
249 example, many API functions have pointer parameters that are NULL in
250 the common cases. If you always call the function with a NULL pointer
251 for the default behavior, you can save yourself some effort by
252 implementing a function that only works for the NULL pointer
253 parameter. If you do this, make sure you test if the parameter is
254 non-null and issue a warning for the non-null case. Also document in
255 the source that the API function is incomplete.
256
257 FIXME: give info on the FIXME (macro/function?) for partially
258 implemented API functions.
259
260 Once you have implemented an API function, submit the change back to
261 the Wine project so the next person to need the same function does not
262 need to repeat your work. Remember, someone else wrote all of the
263 other API functions that you are using, so you are benefitting from
264 their work. Let other people benefit from your work as well. If you
265 work for a company, you may need your company's permission to "give
266 away" your work.
267
268 IV. File Format Conversion
269
270 Before you can compile your program, you must deal with one major
271 difference between Windows and WineLib. Window sources are in DOS
272 format with carriage return / line feed at the end of each line of
273 text while WineLib files are in Unix format with only line feed at the
274 end of each line of text. 
275
276 The main problem with the difference between Unix and DOS format
277 source files occurs with macro line continuation. A Unix compiler
278 expects a backslash (\) followed by a newline (^J) to indict that a
279 macro is continued on the next line. However, a file in DOS format will
280 have the characters backslash (\), carriage return (^M), and newline
281 (^J). The Unix compiler will interpret the backslash (\), carriage
282 return (^M), newline (^) of a file in DOS format as a quoted carriage
283 return and newline. The Unix compiler will think the line has ended
284 and the macro is completely defined. Hence, before you compile your
285 sources, you will need to convert you DOS format sources to Unix
286 format. There are several tools such as dos2unix and tr that are
287 available to convert the format.
288
289 FIXME: get more info on dos2unix, tr, and all other such tools and
290 give example commands. Until I do [3] is a good source.
291
292 FIXME: is CR/LF conversion necessary for gcc 2.95 ?
293
294 V. Compiling A Simple Win32 Program 
295
296 Wine and WineLib are written in C as is the MS Win32 API; thus, if
297 have a program that calls only the Win32 API directly, you can compile
298 the program using a C compiler and link it with some of the WineLib
299 libraries. There are several simple examples of WineLib programs in
300 the directory libtest/ in the Wine source tree. We shall examine one
301 of these to show you how to compile a WineLib program.
302
303 The example we shall examine is hello2. If you examine hello2.c, you
304 will see it is a windows program that pops up a message box that says
305 "Hello, hello!". It can be compiled and run using a windows compiler
306 just like any other windows program. However, it can not be compiled
307 and run with a non-windows compiler. As mentioned previously, windows
308 programs have an entry point called WinMain(), while non-windows
309 compilers use an entry point of main(). Hence, we need some "glue" to
310 glue the main() entry point to the WinMain() in the windows program.
311
312 In WineLib, some of the glue is provided by the spec file. Spec files
313 are used in several places in Wine and WineLib to provide glue between
314 windows code and code for non-windows compilers. WineLib provides a
315 tool called winebuild in the tools/winebuild directory that converts a
316 spec file into a C file that can be compiled and linked with the
317 windows source files. If you examine hello2.spec, you will see the
318 following:
319
320 name    hello2
321 mode    guiexe
322 type    win32
323
324 import  user32.dll
325 import  kernel32.dll
326 import  ntdll.dll
327
328 Information on the complete format of the spec file can be found in
329 <wine>/tools/winebuild/README. Name is the name of the
330 application. Mode is the type of "glue" that winebuild needs to
331 create. Possible modes are 'dll' for a library, 'cuiexe' for a console
332 application, and 'guiexe' for a regular graphical application. Type is
333 the type of API, either win32 or win16. Win16 is supported only in
334 Wine, not WineLib, so you should use win32. Import is a dll that must
335 be loaded for the program to execute.
336
337 During compilation of the hello2 executable, the following command is
338 executed. 
339
340 LD_LIBRARY_PATH="..:$LD_LIBRARY_PATH" \
341     ../tools/winebuild/winebuild -fPIC -L ../dlls -sym hello2.o \
342     -o hello2.spec.c -spec hello2.spec
343
344 The program winebuild will generate the output file hello2.spec.c (option
345 -o hello2.spec.c) from the spec file hello2.spec (option -spec
346 hello2.spec). The option -fPIC specifies that winebuild should generate
347 position independent code and is only necessary for building shared
348 library files (.so files). It is not needed when building the main
349 executable spec file, but since there is no assembly code generated
350 for the main executable, it doesn't make any difference anyway. [5]
351
352 The winebuild program is used in several places in Wine as well as
353 WineLib; however, only the -spec option will be used in WineLib. The
354 output file hello2.spec.c contains the glue code to initialize WineLib
355 and call WinMain().
356
357 In order to run hello2, we will compile the code into a shared library
358 (hello2.so) and create a symbolic link (hello2) with the wine
359 executable with the following steps.
360
361 gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -DSTRICT \
362     -D_REENTRANT -I/usr/X11R6/include -o hello2.o hello2.c
363
364 to compile the windows program itself and 
365
366 gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -DSTRICT \
367     -D_REENTRANT -I/usr/X11R6/include -o hello2.spec.o hello2.spec.c
368
369 to compile the spec file and the glue code. Finally,
370
371 gcc -shared  -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o hello2.so \
372     hello2.o hello2.spec.o -L.. -lwine -lncurses -lm  -lutil -ldl
373
374 links the compiled files into a shared library.
375
376 FIXME: -D_REENTRANT why?
377 FIXME: explain compiler options
378 FIXME: explain linker options
379
380 All of the steps are automated with the makefile, so "make hello2.so"
381 will execute all of the steps for you.  A final step is "make hello2",
382 which creates a symbolic link from hello2 to the wine executable. Now,
383 when "./hello2" is run, the wine executable sees it was called by the
384 name "hello2" and loads the shared library "hello2.so" and executes
385 the program.
386
387 THE INFO BELOW IS OUT OF DATE (28-Dec-2000)
388
389 Thus, you now have the basics of compiling a simple windows
390 program. There are two more things to learn for compiling more complex
391 windows programs: windows resources and DLL dependencies. Window
392 resources are described in the next section. DLL dependencies are
393 handled by linker magic with windows compilers. Thus, in WineLib, you
394 will need to provide information about which DLLs your program
395 depends. This information is given in the spec file. For example, if
396 our hello2 program had a .wav file that it played, it would need the
397 multi-media DLL winmm. Our spec file would then be
398
399 name    hello2
400 mode    guiexe
401 type    win32
402 init    WinMain
403 import  winmm
404
405 If you need to list multiple DLLs, then the import specification can
406 appear multiple times.
407
408 FIXME: can multiple libraries appear on one import line?
409
410 VI. Compiling A Win32 Program With Resources
411
412 FIXME: to be continued.
413 Describe wrc.
414 Go through hello world example 3.
415
416 VII. DLLs
417
418 As mentioned in the introduction, Wine allows you to execute windows
419 executables and windows libraries under non-Microsoft operating
420 systems. WineLib allows you to take sources intended for the windows
421 operating system and to compile them to run as native executables
422 under a Unix/Linux operating system. With an executable and a single
423 library, there are four combinations in which to run the programs and
424 the library:
425     1. a Windows executable with a Windows DLL,
426     2. a Windows executable with WineLib DLL,
427     3. a WineLib executable with Windows DLL, and
428     4. a WineLib executable with WineLib DLL.
429 In this section, we will discuss each of these and discuss the steps
430 required to implement the executable/DLL combination. 
431
432 A. Windows executable and Windows DLL
433
434 Running a windows executable with a windows DLL is not a WineLib
435 program: it is a Wine program. If you type
436     wine program.exe
437 and the DLL is in the search path, then the windows program should run
438 using the windows DLL.
439
440 FIXME: find out what is the search path.
441
442 B. Windows executable and WineLib DLL
443
444 Running a windows executable with a WineLib DLL is also accomplished
445 using the Wine program. The source code for the DLL is compiled into a
446 Unix style shared library. When the windows executable "loads" the
447 DLL, Wine will use the shared library (.so file) instead.
448
449 At first you may wonder why you would want to run a windows executable
450 with a WineLib DLL. Such a situation implies you do not have the
451 source for the executable, but you do have the source for the
452 DLL. This is backwards from what you might expect. However, I do have
453 an example where this situation might arise.
454
455 Codewright is a popular editor in the windows world, and the
456 capabilities of Codewright can be extended by using DLLs. Since
457 Codewright is a commercial product, you do not have the source and
458 must use the windows executable with Wine. If you have written a DLL
459 to add functionality to Codewright, you have two choices: you can
460 compile the DLL using a windows compiler and use both a windows
461 executable and a windows DLL as in case A above, or you can use
462 WineLib and compile the DLL as a shared library (.so file). I have no
463 idea if Codewright actually runs under Wine, but this is an example of
464 why you might decide to use a windows executable and a WineLib
465 DLL. Many other editors and other programs use DLLs to extend their
466 functionality.
467
468 In order for Wine to use the WineLib DLL, certain glue code is need to
469 replace the linker magic that windows compilers use. As with a simple
470 executable, the winebuild program uses a spec file to generate the glue
471 code. For example, in the spec file for the DLL will look something like
472     name        winedll
473     type        win32
474     init        winedll_DllMain
475     1 cdecl _WINEbirthDay@4 ( str ) WINEbirthDay
476     2 cdecl _WINEfullName@4 ( str ) WINEfullName
477 The name is the name of the DLL. Since WineLib only supports win32,
478 the type should always be win32. The init function is the name of the
479 initialization function for the DLL. The initialization function for a
480 windows DLL is named DllMain(). You will need to rename the function
481 in the DLL source so there will not be any name clashes with the
482 DllMain() of other DLLs in you program.
483
484 The last two lines of the spec file above, provide the export
485 information for the DLL. For example, the line
486     1 cdecl _WINEbirthDay@4 ( str ) WINEbirthDay
487 says that the function at ordinal 1 uses the cdecl calling convention
488 for the parameters. The DLL export name is _WINEbirthDay@4. The
489 function takes a single parameter that is a string. Finally, the C
490 function name to be called whenever this DLL function is called is
491 WINEbirthday. You will need a function ordinal line for each function
492 in the DLL. The export name and the ordinal can be obtained from the
493 windows program dumpbin and the windows version of the DLL. See the
494 file <wine>/tools/winebuild/README for more details on the spec file
495 format.
496
497 During the the compile process, a command like
498     winebuild -fPIC -o winedll.spec.c -spec winedll.spec
499 will be executed to create the file winedll.spec.c from information in
500 the file winedll.spec. The file winedll.spec.c and winedll.c are
501 compiled into object files and used to create the shared library.
502
503 In order for the program to run, a copy of the shared library must be in
504 your EXTRA_LD_LIBRARY_PATH. For example, if your wine.conf file has
505 the following line,
506     EXTRA_LD_LIBRARY_PATH=${HOME}/wine/lib
507 then you must copy the shared library into the directory ~/wine/lib/
508 and the shared library will now be in the correct search path.
509
510 Now when you type 
511     wine program.exe
512 the program will load the shared library (.so).
513
514 C. WineLib executable and Windows DLL
515
516 Running a WineLib executable with a Windows DLL is accomplished
517 using WineLib. This situation will be common since you may have
518 purchased DLLs to use with you project and the DLL vendor may not give
519 you the source code for the DLL.
520
521 In order for WineLib to use the Windows DLL, certain glue code is
522 needed to replace the linker magic that windows compilers use. Part of
523 the glue code must be written by you. The basic idea of the glue code
524 is that you write a new DLL that consists of function pointers. Each
525 function in the DLL will consist of a call on a function pointer. For
526 example, 
527     WINEDLL_ConstString WINEDLL_INTERFACE 
528     WINEfullName( WINEDLL_ConstString handle ) {
529         return (* pWINEfullName) ( handle );
530     }
531 The initialization function for the DLL will use the function
532 LoadLibrary() to load the windows DLL and initialize the function
533 pointers using the function GetProcAddress(). 
534
535 Since Wine can use either windows DLLs or Unix shared libraries (.so),
536 the LoadLibrary() function call may have unexpected results if there
537 is a winedll.dll and a winedll.so file. Hence, the windows version of
538 the DLL should be named something like hiddenWinedll.dll and the
539 shared library should be named winedll.so. Now the shared library will
540 use LoadLibrary() to load the "hidden" DLL.
541
542 The shared library will need a spec file. Fortunately, it is simpler
543 than case B above. The spec file will look something like
544     name        winedll
545     type        win32
546     init        winedll_DllMain
547 The name is the name of the DLL. Since WineLib only supports win32,
548 the type should always be win32. The init function is the name of the
549 initialization function for the shared library. This is the function
550 that will load the "hidden" DLL and initialize the function
551 pointers. There is no need for any function ordinals unless your
552 program calls functions by the ordinal.
553
554 During the the compile process, a command like
555     winebuild -fPIC -o winedll.spec.c -spec winedll.spec
556 will be executed to create the file winedll.spec.c from information in
557 the file winedll.spec. The file winedll.spec.c and winedll.c are
558 compiled into object files and used to create the shared library.
559
560 Now that the shared library is compiled, you still need to compile
561 your program. Part of the compile process for your program will
562 consist of a spec file for you program. For example,
563     name        program
564     mode        guiexe
565     type        win32
566     init        WinMain
567     import winedll.dll
568 This spec file is similar to the spec file of the simple WineLib
569 example in part V above. The only difference is the import
570 specification that tells WineLib that the main program uses
571 winedll.dll. If this import line is not included, the "hidden" DLL
572 will not be loaded and the function pointers will not be initialized.
573
574 During the the compile process, a command like
575     winebuild -fPIC -o program.spec.c -spec program.spec
576 will be executed to create the file program.spec.c from information in
577 the file program.spec. The file program.spec.c and your source code are
578 compiled into object files and used to create the executable.
579
580 D. WineLib executable and WineLib DLL.
581
582 Running a WineLib executable with a WineLib DLL is accomplished using
583 WineLib. The source for the DLL will be combined with a spec file to
584 generate the shared library. Likewise, the source for your program and
585 a spec file will be combined to create the executable. In the source
586 for the DLL, you should change the name of DllMain() to a name like
587 winedll_DllMain() so that there will not be a name clash with other
588 initialization functions for other DLLs.
589
590 The shared library's spec file is like case C above. The spec file
591 will look something like
592     name        winedll
593     type        win32
594     init        winedll_DllMain
595 The init function is the name of the initialization function for the
596 shared library (what you renamed DllMain to). There is no need for any
597 function ordinals unless your program calls functions by the ordinal.
598
599 During the the compile process, a command like
600     winebuild -fPIC -o winedll.spec.c -spec winedll.spec
601 will be executed to create the file winedll.spec.c from information in
602 the file winedll.spec. The file winedll.spec.c and the source code for
603 your DLL are compiled into object files and used to create the shared
604 library.
605
606 Compiling your program is exactly like case C above. For example, the
607 spec file for you program will look something like
608     name        program
609     mode        guiexe
610     type        win32
611     init        WinMain
612     import winedll.dll
613
614 During the the compile process, a command like
615     winebuild -fPIC -o program.spec.c -spec program.spec
616 will be executed to create the file program.spec.c from information in
617 the file program.spec. The file program.spec.c and your source code are
618 compiled into object files and used to create the executable.
619
620 VIII. How to use MFC
621     A. Using a native MFC DLL
622     B. Compiling MFC
623
624 FIXME: to be continued.
625
626 =====================================================================
627 References
628
629 Until this HOWTO is complete, I will document who gives me what
630 information. 
631
632 Reference [1] 
633 From: Patrik Stridvall <ps@leissner.se>
634 To: "'wilbur.dale@lumin.nl'" <wilbur.dale@lumin.nl>,
635 Date:   Mon, 5 Jun 2000 14:25:22 +0200 
636
637 First of all WineLib suppport for Win16 has been discontinued
638 for quite some time, because:
639
640 1. It is difficult for us to support and it is impossible
641    to do so prefectly without special compiler support,
642    because of memory layout issues. For example Win16 int
643    is 16-bit and data is aligned 16-bit.
644 2. It is in almost all cases easier to port a
645    Win16 application to Win32.
646
647 A minor detail, I personally would prefer that Wine and WineLib
648 was always used in the uppercase W and uppercase L variant,
649 instead of, as in your document, sometime one variant, sometimes
650 another.
651
652 Reference [2] 
653
654 The exact options for controlling error messages mentioned in the
655 reference are apparently incorrect, but may have been correct for some
656 earlier version of Wine.
657
658 From: michael cardenas <mbc@deneba.com>
659 To: wilbur.dale@lumin.nl
660 Date:   Mon, 5 Jun 2000 13:19:34 -0400
661
662 a few things you should mention...
663
664 - you can compile resources as a dll under windows and then load the dll
665 with wine. That's what we do for canvas. This is probably not ideal, but
666 most of my problems porting were in the code. We very seldomly have to
667 change the resources for the porting process. But wrc does work for most
668 cases...
669
670 - the error messages can be turned off or turned up with options to
671 configure like --enable-trace-msgs=wireoff or --enable-trace-msgs=wireon .
672 Take a look at configure.
673
674 - you probably want to compile your WineLib with --disable-debugger, at
675 least for the release version of your app.
676
677 Reference [3] 
678 http://fgouget.free.fr/wine/winelib-en.shtml
679
680 Reference [4]
681 Date: Wed, 21 Jun 2000 10:34:10 +0200
682 From: Rob Carriere <rob.carriere@lumin.nl>
683 To: Wilbur N Dale <wilbur.dale@lumin.nl>
684 Subject: WineLib-HOWTO comments
685
686 Hello Wilbur,
687
688 Some picking of nits.  It reads right well.
689
690 Some of Windows xyz are registered trade marks, other are vanilla:
691 Microsoft: Registered
692 Windows NT: Registered
693 Windows (95,98): plain
694
695 A Windows compiler does NOT generate a fake main.  Instead, the
696 executable file format provides for 2 (NE) or 3 (PE) entry points.
697 One of these is your program, the other(s) are normally filled with
698 stubs that print an error message and exit.  It is possible to instruct
699 the _linker_ to link 16-bit objects into one or both of the alternate
700 entry points, and create a fat binary.
701
702 At the C/C++ level, your statement about WinMain() is correct.  Of
703 course the actual entry point first inits run time lib etc, and then
704 calls the C/C++ level entry, but that is also true for main() in the
705 standard setup.  It may be important to regurgitate this info here,
706 though, because some of the fun things that can happen with multiple
707 run time libs and DLLs occur at this level.
708
709 Line 86: I only need to know how compile MFC if I use it... :-)
710
711
712 Best regards,
713  Rob                          mailto:rob.carriere@lumin.nl
714
715 Reference [5]
716 To: wilbur.dale@lumin.nl
717 Subject: Re: tool/build questions
718 From: Alexandre Julliard <julliard@winehq.com>
719 Date:   13 Jun 2000 20:06:23 -0700
720
721 "Wilbur N. Dale" <wilbur.dale@lumin.nl> writes:
722
723 > 2. tools/build for WineLib users -- is there ever a need to not specify -pic?
724
725 -pic is only necessary for building .so files, so it's not needed when
726 building the main executable spec file (but since there is no assembly
727 code generated for the main exe it doesn't make any difference anyway).
728
729 -- 
730 Alexandre Julliard
731 julliard@winehq.com
732
733 Reference [6]
734 Wine Weekly News #51 (2000 Week 28)
735
736 Events, progress, and happenings in the Wine community for 
737 July 10, 2000. 
738
739 Uwe Bonnes and Ove Kaven also reminded of some tools to generate under
740    Linux some Windows executables:
741      * Cygwin/Mingw: as native Linux apps
742      * LCC-Win32: run with the help of Wine
743      * Borland C++ 5.5: command line version available for free (after
744        registering to Borland users' database)
745        
746 =====================================================================
747
748 The information included here is from various Wine-devel posting and
749 private e-mails. I am including them so that any one starting on MFC
750 will have some documentation. Glean what you can and good luck.
751
752 Before I write more detailed info on compiling MFC I have three
753 questions. The info I have mentions three problems:
754
755     1. Wine header files---what is the status of this? Do changes need
756     to be made in the headers and if so, do I submit the changes back
757     into Wine cvs? Do the changes need #ifdef for C vs. C++
758     compilation? 
759
760     Francois Gouget <fgouget@psn.net> has been doing a lot of work in
761     this area. It should be a lot easier to compile using C++ now and to
762     compile MFC.
763
764     2. DOS format files <CR/LF> and no case distinction in
765     filenames. Do the extensions Corel made to gcc 2.95 handle this?
766     If so, how?
767
768     3. Microsoft extensions to the C++ syntax. Do the extensions Corel
769     made to gcc 2.95 handle this? If so, how?
770
771 If you have info that needs to be added, send me email at
772 <wilbur.dale@lumin.nl> and I will add it.
773
774 =====================================================================
775
776 THANKS
777
778 Most of the information in this file came from postings on
779 <Wine-devel@Winehq.com> and from private e-mails. The following people
780 contributed information for this document and I thank them for their
781 time and effort in answering my questions. I also want to thank them
782 for encouraging me to attack the MFC problem. 
783
784 CONTRIBUTERS:
785
786     Damyan Ognyanoff <Damyan@rocketmail.com>
787     Gavriel State <gav@magmacom.com>
788     Ian Schmidt <ischmidt@cfl.rr.com>
789     Jeremy White <jwhite@codeweavers.com>
790
791
792 From: Ian Schmidt <ischmidt@cfl.rr.com>
793 Subject: Re: WineLib and MFC
794
795 "Wilbur N. Dale" wrote:
796
797 > What is the status of MFC under WineLib?
798
799 I don't know precisely. Corel has done more MFC work than anyone (all
800 of their applications which they are porting are MFC-based), and
801 reportedly they have MFC itself compiled. I was just trying to get a
802 moderately simple MFC-using app to compile, with moderate success
803 (there are still some problems with MFC's headers after my patch, but
804 at least they don't appear to be Wine's fault :) I did not try to
805 compile MFC itself.
806
807 > Which versions of MFC, if any?
808
809 I have no idea what version Corel uses. As noted in my patch, I was
810 fiddling with the headers for MFC 6 (from Visual C++ 6.0 Service Pack
811 3). Most of the stuff my patch addressed was for newer IE 5-related
812 features, so I'd guess MFC 5 (VC++ 5.0) is likely what they used.
813
814 > Is there any documentation on how to compile MFC for WineLib?  If so
815 > where?
816
817 Not that I know of.
818
819 > I have started to compile programs using WineLib (hello.c last
820 > Sunday) and expect to be ready to start compiling MFC in a couple of
821 > weeks. If documentation is not available on compiling MFC, I am
822 > willing to write it.
823
824 Documentation would be a Good Thing, as WineLib in general is grossly
825 underdocumented right now. Here's a few tips I discovered to get you
826 started:
827
828 - First off, run all the MFC headers (and source too if you try it)
829 through a utility to strip out the DOS carriage returns. They cause
830 havoc with GCC when it sees one after a line that ends with a \ (and
831 MFC has many macros in it's headers that meet that description). If
832 you don't have one, do a Google search on "fromdos" and you should
833 locate some source (or it's fairly easy to make your own).
834
835 - Use GCC 2.95.2, and the -fpermissive flag to make it less picky.
836 2.95.2 has some VC++-compatibility features that Corel paid for, and I
837 believe more are forthcoming in future GCCs.
838
839 - Use -I to add whereever you have the MFC headers at to your include
840 path, as MFC apps typically use #include <> to access them rather than
841 "".
842
843 - Be prepared to have to rename and/or symlink headers, unless you
844 compile on a case-insensitive filesystem :)
845
846 - When you make install Wine it seems not to include all it's headers
847 in /usr/local/include/Wine. To have any chance at getting MFC going
848 you'll want to use -I to add the include/ directory from the Wine
849 source tarball to the path so it can grab everything.
850
851 Sorry I can't help you more, but good luck!
852
853 -Ian Schmidt
854 ischmidt@cfl.rr.com
855
856
857 From: Jeremy White <jwhite@codeweavers.com>
858 Subject: Re: RFC: Wine 1.0
859
860 "Wilbur N. Dale" wrote:
861 > > Further, we have successfully built MFC after making only
862 > > a modest set of changes to it, even with older
863 > > versions of g++.
864
865 > Lumin Software is about to use WineLib to port a window program to linux. A
866 > couple of years ago we thought we had to make a modification to MFC for one
867 > of our projects and we had problems getting MFC to compile under MS Visual C++.
868 > After much wailing and gnashing of teeth, we gave up and did things another
869 > way. After this bad experience, we were wondering --- approximately how many
870 > man-hours did you spend compiling and changing MFC ?
871
872     Urk. I misspoke. None of the developers here that I thought
873 had working versions of MFC with Wine have working versions any
874 longer. So, it may be a bit trickier than I led you to believe.
875
876     We have it working pretty reliably with TWine, but not 
877 quite so cleanly (yet) with Wine. However, it really shouldn't
878 be too difficult, and this is what I can remember of the process:
879
880         1. If you use a very modern version of gcc (2.95.2 or higher),
881             I believe you will need to add the -relaxed flag to
882             have any hope of compiling.
883
884         2. If you use an earlier version of gcc, you will need to
885             adjust the many anonymous structs/unions that MFC supplies.
886             We prefer this approach, because requiring very
887             modern gcc implementations seems harsh to us.
888
889         3. You will need to adjust for the many type differences
890             between MFC intrinsic types and the types supplied by Wine.
891             For example, I believe that MFC expects a HANDLE to
892             be compatible with certain scalar types, (and it is
893             under Windows/VC, but is not with Wine/gcc).
894
895         4. The key procedure:  add many -DNO_XXX flags to the
896             makefile. If you start with Microsofts make file
897             for MFC, convert it into a Wine makefile, and then turn
898             on many of the flags they list there (of the form -DNO_XXX),
899             your life will get much easier. Once you get it working
900             with a few -DNO_XXX flags, you can go back and add them
901             back in.
902
903         5. The best resource:  you need someone who knows C++ very,
904             very well. You occassionaly run into very obscure C++
905             problems where MS has extended the C++ standard and
906             gcc has not. It really helps to have a guru on hand
907             when you hit those.
908
909
910 I hope this helps. Sorry for the earlier deceptive post.
911
912 Jeremy
913
914 From: Gavriel State <gav@magmacom.com>
915 Subject: Re: MFC questions
916
917 "Wilbur N. Dale" wrote:
918
919 > 1. Compile MFC. Several years ago we (Lumin Software) tried to
920 > compile MFC.  The attempt failed and we found another way to do what
921 > we wanted. MS documentation states that compiling MFC was
922 > deliberately made difficult.  Considering my experience with stuff
923 > they call "easy" I am not looking forward to compiling MFC. We are
924 > currently using Visual Studio 5 for windows development.
925
926 At Corel, we had MFC compiled and running sample apps in WineLib in
927 late 1998. It's mostly a question of the Wine headers, which weren't
928 originally up to snuff. We did quite a bit of work on them, and most
929 of those changes have been contributed back to WineHQ, so it should be
930 pretty easy now. The other thing that was a big deal was getting the
931 startup code working properly - since MFC needs to initialize static
932 data *after* WineLib gets initialized. I believe that that issue has
933 been addressed now on the WineHQ side with some of the work done on
934 the .spec file tools recently.
935
936 -Gav
937
938 -- 
939 Gavriel State
940 CEO
941 TransGaming Technologies Inc.
942 gav@transgaming.com
943
944 From: Jeremy White <jwhite@codeweavers.com>
945 Subject: Re: MFC questions
946
947 "Wilbur N. Dale" wrote:
948 [snip]
949 > 1. Compile MFC. Several years ago we (Lumin Software) tried to
950 > compile MFC.  The attempt failed and we found another way to do what
951 > we wanted. MS documentation states that compiling MFC was
952 > deliberately made difficult.  Considering my experience with stuff
953 > they call "easy" I am not looking forward to compiling MFC. We are
954 > currently using Visual Studio 5 for windows development.
955
956 Wilbur, I personally think that this is the 'right' approach, although
957 approach #2 may prove faster.
958
959 Despite your previous experience, and despite my earlier incorrect
960 statements, I think that this is simpler than you fear. It's one of
961 those tasks that's darkest before the storm - you spend all of your
962 energy getting all the include files to work. Once you have *one*
963 object file, the rest go much more quickly (alright, getting it to
964 link is also a hairball of a job, but it's tractable <g>).
965
966 If you're not in a hurry, getting MFC to compile, and having a
967 documented procedure for compiling it is on our agenda for the
968 relatively near future (see the Wine 1.0 task list).
969
970 Jer
971
972 p.s. Stick with Visi C++ 5. IMHO its MFC license is cleaner than that
973 of VC 6.
974
975 From: Gavriel State <gav@magmacom.com>
976 Subject: The MSVC++ 6.0 license
977
978 Jeremy White wrote:
979 > p.s. Stick with Visi C++ 5. IMHO its MFC license is cleaner than that
980 > of VC 6.
981
982 Actually, I just picked up a copy of MSVC 6.0 and it appears that they
983 changed the license between the original release and the Service Pack
984 3 release - they removed the bit in section 1.1 about requiring that
985 you be developing your software product only for use with a Microsoft
986 OS.  In any case, even the original license explicitly says that the
987 MFC redistribution rights are *in addition* to the usage rights in
988 section 1.1.
989
990 The relevant portion of the original EULA:
991
992  1.1    General License Grant. Microsoft grants to you as an individual, a
993  personal, nonexclusive license to make and use copies of the SOFTWARE 
994  PRODUCT for the sole purposes of designing, developing, and testing your
995  software product(s) that are designed to operate in conjunction with 
996  any Microsoft operating system product. [Other unrelated stuff deleted]
997
998 >From the SP3 EULA:
999
1000  3.     Section 1.1 of the EULA is deleted in its entirety and replaced 
1001  with the following:
1002
1003  1.1    General License Grant. Microsoft grants to you as an individual, a 
1004  personal, nonexclusive license to make and use copies of the SOFTWARE 
1005  PRODUCT for the purpose of designing, developing, and testing your 
1006  software product(s). [Other unrelated stuff deleted]
1007
1008 Disclaimer - I am not a lawyer, but I've spent lots of time with them 
1009 investigating software licenses.
1010
1011  -Gav
1012
1013 -- 
1014 Gavriel State
1015 CEO
1016 TransGaming Technologies Inc.
1017 gav@transgaming.com
1018
1019 From: Damyan Ognyanoff <Damyan@rocketmail.com>
1020 Subject: Need a hint
1021
1022 Hi,
1023
1024 I manage to build mfc42 as .so library and a application using it (as
1025 a .so library too). I execute it using simple loader which is linked
1026 to Wine and I load my application in it's WinMain routine. The
1027 problem is how clearly to unload mfc and my application (to invoke
1028 mfc's destructors before loader is terminated) All is fine except that
1029 there is a "zombi" reference to code in shared library which is
1030 invoked in Wine code and generate GPF. debugger stops somewhere in
1031 aplication's InitInstance !!! - and the stack is broken so I can't
1032 catch where exactly the problem is. Any hints are welcome. I'm using
1033 Wine-2000517 shapshot downloaded form Wine.datapary.no 
1034
1035 TNX.
1036
1037 Damyan
1038 p.s.
1039 If any of You is interested in details I can share my
1040 experience.
1041
1042 WND comment:
1043     Francois Gouget <fgouget@psn.net> has been doing a lot of work in
1044     the  headers of wine. It should be a lot easier to compile using
1045     C++ now and to compile MFC. Many of the actions needed in the
1046     following email are not needed any more.
1047
1048 From: Damyan Ognyanoff <Damyan@rocketmail.com>
1049 Subject: Re: Wine MFC info request
1050
1051 hi,
1052 my MFC is from VC6.0 with SP3
1053 MFC Bulid: (form  afxbld_.h)
1054     #define _MFC_BUILD 8447
1055     #define _MFC_USER_BUILD "8447"
1056     #define _MFC_RBLD 0
1057 mfcdll.rc
1058     FILEVERSION       6,0,_MFC_BUILD,_MFC_RBLD
1059     PRODUCTVERSION    6,0,0,0
1060
1061 Hints:
1062     1. Wine include files
1063
1064 In some of them you will find error about '__attribute__' all kinds of
1065 similar errors can be fixed using proper typedefs first example :
1066
1067 typedef BOOL (CALLBACK *DLGPROC)(HWND,UINT,WPARAM,LPARAM);
1068
1069 must be converted to
1070
1071 typedef BOOL CALLBACK (*DLGPROC)(HWND,UINT,WPARAM,LPARAM);
1072
1073 and the second kind is something like
1074
1075 TYPE* WINAPI SomeFunction(HWND param1,UINT param2);
1076
1077 The problem here is a TYPE* or TYPE& (in some of mfc files) the
1078 workaround is to declare a type before:
1079
1080 typedef TYPE* TYPEPtr; 
1081
1082 or
1083
1084 typedef TYPE& TYPERef;
1085
1086 and declaration will look like:
1087
1088 TYPEPtr WINAPI SomeFunction(HWND param1,UINT param2);
1089
1090 note: don't miss a 'struct' when you define struct type pointers. I
1091 miss it and get a lot of problems compiling MFC:
1092
1093 >>
1094 struct _TEB;
1095 typedef !!!struct!!! _TEB* P_TEB;
1096 extern inline P_TEB WINAPI NtCurrentTeb(void);
1097 <<
1098
1099 Those conversions are semanticaly the same as above but g++ compile
1100 them and generate proper code to invoke __stdcall kind of functions
1101
1102 in some of Wine/obj_XXX.h files: Wine/obj_base.h - there are a lot of
1103 defines's that are used to declare a COM interfaces
1104
1105 #define ICOM_METHOD(ret,xfn) \
1106      public: virtual ret (CALLBACK xfn)(void) = 0;
1107
1108 will be (for all of them that are related to C++ (watch #ifdef's
1109 carefully)):
1110
1111 #define ICOM_METHOD(ret,xfn) \
1112      public: virtual ret CALLBACK (xfn)(void) = 0;
1113
1114 and the second tip is an error when compiler stops on line like:
1115  
1116    ICOM_DEFINE(ISomeInterfase,IUnknown)
1117
1118 watch method declarations above to find something like:
1119
1120 ICOM_METHOD1(TYPE*,MethodName, DWORD,dwParam)
1121
1122 and replace TYPE* with proper TYPEPtr type. In many cases You will see
1123 void* which can be replaced simply by LPVOID.
1124
1125 qthere are several errors related to anonymous structs and unions but
1126 they can be avoided with proper - #ifdef __cplusplus
1127
1128 This is all about Wine headers I think. If you find something that I
1129 miss type a line of mail to me.
1130
1131 2. MFC
1132 The rules are the same with some new issues:
1133
1134 virtual BOOL Method1(int param1, BOOL (CALLBACK *param2)
1135 (HWND,UINT,WPARAM,LPARAM));
1136
1137 don't compile. I remove a function pointer declaration
1138 outside method:
1139
1140 typedef BOOL CALLBACK
1141 (*param2Type)(HWND,UINT,WPARAM,LPARAM);
1142
1143 virtual BOOL Method1(int param1, param2Type param2);
1144
1145 I didn't apply this technique to a operator new
1146 definitions:
1147
1148         void* AFXAPI operator new(size_t nSize);
1149
1150 so i remove AFXAPI from these declarations:
1151
1152 I got some missed #defines from commctrl.h and I added
1153 them form VC6.0 include.
1154
1155 these are my defines form Makefile which I used to
1156 compile MFC
1157
1158 -DTWINE_NO_CMONIKER \ -- this is related to exclude
1159 CMonikerFile 
1160 -D__urlmon_h__ \ -- Wine didn't have URL interfaces 
1161 -D_AFX_NO_OLEDB_SUPPORT \
1162 -D_WIN32  \
1163 -DNOWIN98  \ -- this is used to exclude all
1164 unimplemented classes from commctrl 
1165 -D_AFX_PACKING \
1166 -D_AFX_NO_DHTML_SUPPORT \
1167 -D_AFX_NO_SOCKET_SUPPORT \
1168 -D_AFX_NO_SYNC_SUPPORT \
1169 -D_AFX_NO_OCX_SUPPORT  \
1170 -D_AFX_PORTABLE \
1171 -D_AFX_OLD_EXCEPTIONS \
1172 -D_AFX_NO_SOCKET_SUPPORT \
1173 -D_AFX_NO_DEBUG_CRT \
1174 -D_AFX_NO_DAO_SUPPORT \
1175 -D_AFX_NO_OCC_SUPPORT \
1176 -D_AFX_NO_INET_SUPPORT \
1177 -D_AFX_NO_RICHEDIT_SUPPORT  \
1178 -D_X86_ \
1179 -DLONGHANDLES
1180
1181 may be you will try to enable some of features of mfc I tested only
1182 -D_AFX_NO_OCC_SUPPORT but got missing interfaces from Wine
1183
1184 in file afxcom_.h
1185 - _CIP<_Interface, _IID>::~_CIP<_Interface, _IID>()
1186 + _CIP<_Interface, _IID>::~_CIP()
1187
1188 in file afxtempl.h
1189 -       BOOL Lookup(BASE_CLASS::BASE_ARG_KEY key,
1190 VALUE& rValue) const
1191 -               { return BASE_CLASS::Lookup(key,
1192 (BASE_CLASS::BASE_VALUE&)rValue); }
1193 +       BOOL Lookup(typename BASE_CLASS::BASE_ARG_KEY
1194 key, VALUE& rValue) const
1195 +               { return BASE_CLASS::Lookup(key,
1196 (typename BASE_CLASS::BASE_VALUE&)rValue); }
1197
1198 and all releated errors can be fixed in this way.
1199
1200 3. spec file
1201     name        mfc42
1202     type        win32
1203     rsrc        mfc42
1204
1205     10 stdcall WinMain(long long ptr long) WinMain
1206
1207 4. linking 
1208     use -rdynamic wnen link libmfc.so to get ARGV and
1209 ARGC from loader
1210     
1211 5. I didn'n build a extension dll with Wine but I suspect that there
1212 will be some problems related to a chaining Runtime classes form MFC
1213 to a new dll
1214
1215 6. build your app as a MODULE too.
1216
1217 7. make a loader and in it's _WinMain:
1218 ... includes are here
1219 iint PASCAL (*winMain)(HINSTANCE,HINSTANCE,LPSTR,int) =
1220 0;
1221 my app uses these to manage filenames
1222 VOID __cdecl (*_splitpath1)(LPCSTR path, LPSTR drive,
1223 LPSTR directory, LPSTR filename, LPSTR extension ) =
1224 NULL;
1225 VOID __cdecl _splitpath(LPCSTR path, LPSTR drive,
1226 LPSTR directory, LPSTR filename, LPSTR extension )
1227 {
1228     if (_splitpath1)
1229         _splitpath1(path, drive, directory, filename,
1230 extension );
1231 }
1232 VOID __cdecl (*_makepath1)(LPSTR path, LPCSTR drive,
1233 LPCSTR directory, LPCSTR filename, LPCSTR extension )
1234 = NULL;
1235 VOID __cdecl _makepath(LPSTR path, LPCSTR drive,
1236 LPCSTR directory, LPCSTR filename, LPCSTR extension )
1237 {
1238     if (_makepath1)
1239         _makepath1(path, drive, directory, filename,
1240 extension);
1241 }
1242 int PASCAL _WinMain(HINSTANCE h,HINSTANCE h1,LPSTR
1243 lpszCmdParam,int c)
1244 {
1245   HINSTANCE hInstance,hins,hlib,htst,hform,himag,hexe;
1246         int retv;
1247
1248         hins = LoadLibrary("CRTDLL.DLL");
1249         _splitpath1 = GetProcAddress(hins,
1250 "_splitpath");
1251         _makepath1 = GetProcAddress(hins,
1252 "_makepath");
1253         hins = LoadLibrary("COMCTL32.DLL");
1254         hins = LoadLibrary("COMDLG32.DLL");
1255
1256
1257         hins = dlopen("libmfc42.so",2);
1258         hlib = LoadLibrary("mfc42");
1259         himag = dlopen("libmxformatslib.so",2);
1260         hform = LoadLibrary("mxformatslib");
1261         hexe = dlopen("libmxpaint.so",2);
1262         htst = LoadLibrary("mxpaint");
1263
1264         winMain = GetProcAddress(hlib, "WinMain");
1265         if (winMain)
1266         {
1267           retv = winMain (htst,    // note the > htst
1268 < HERE
1269                   0,            
1270                   lpszCmdParam, 
1271                   SW_NORMAL);   
1272         }
1273     FreeLibrary(htst);
1274     FreeLibrary(hform);
1275     FreeLibrary(hlib);
1276     dlclose(hexe);
1277     dlclose(himag);
1278     dlclose(hins);
1279     return retv;
1280 }
1281 the spec for loader is:
1282 name    c10
1283 mode    guiexe
1284 type    win32
1285 init    _WinMain
1286
1287 please find attached a Makefile which i use to build
1288 MFC
1289
1290 Regards 
1291 Damyan.
1292
1293  LocalWords:  WineLib HOWTO Jul vs DLLs DLL MFC NT FIXME CrypKey Kenonic API TM
1294  LocalWords:  Codewright NE PE WinMain GPL LGPL EULA nonexclusive winver nt dos
1295  LocalWords:  redistributables unix tr CR LF gcc libtest winebuild pic fPIC dll
1296  LocalWords:  guiexe init cuiexe lwine lncurses lm lutil ldl wav winmm wrc lcc
1297  LocalWords:  dllExamples WindowsExeWindowsDLL WindowsExeWineDLL WineExeWineDLL
1298  LocalWords:  WineExeWindowsDLL Borland URL's cd distclean DllMain winemain exe
1299  LocalWords:  winedll cdecl WINEbirthDay str WINEfullName WINEbirthday libtool
1300  LocalWords:  proost conf LD libwinedll Gouget docs dumpbin ConstString Lumin
1301  LocalWords:  pWINEfullName LoadLibrary GetProcAddress hiddenWinedll BV HW dlls
1302  LocalWords:  Zandheuvel Oosterhout linkers executables runtime ntdll sym Wl
1303  LocalWords:  DSTRICT REENTRANT rpath Bsymbolic makefile multi