Dealing with the MFC

Dealing with the MFC Introduction To use the MFC in a Winelib application you will first have to recompile the MFC with Winelib. In theory it should be possible to write a wrapper for the Windows MFC as described in . But in practice it does not seem to be a realistic approach for the MFC: the huge number of APIs makes writing the wrapper a big task in itself. furthermore the MFC contain a huge number of APIs which are tricky to deal with when making a wrapper. even once you have written the wrapper you will need to modify the MFC headers so that the compiler does not choke on them. a big part of the MFC code is actually in your application in the form of macros. This means even more of the MFC headers have to actually work to in order for you to be able to compile an MFC based application. This is why this guide includes a section dedicated to helping you compile the MFC with Winelib. Legal issues (Extracted from the HOWTO-Winelib written by Wilbur Dale <wilbur.dale@lumin.nl>) The purpose of this section is to make you aware of potential legal problems. Be sure to read your licenses and to consult your lawyers. In any case you should not consider the remainder of this section to be authoritative since it has not been written by a lawyer. Well, let's try to have a look at the situation anyway. During the compilation of your program, you will be combining code from several sources: your code, Winelib code, Microsoft MFC code, and possibly code from other vendor sources. 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 combine the code and if you will be distributing it. For example, if you are releasing your code under the GPL or LGPL, you cannot use MFC because these licenses do not allow covered code to depend on libraries with non-compatible licenses. There is a workaround - in the license for your code you can make an exception for the MFC library. For details see The GNU GPL FAQ. Wine/Winelib is distributed under the GNU Lesser General Public License. See the license for restrictions on the modification and distribution of Wine/Winelib code. In general it is possible to satisfy these restrictions in any type of application. On the other hand, MFC is distributed under a very restrictive license and the restrictions vary from version to version and between service packs. There are basically three aspects you must be aware of when using the MFC. First you must legally get MFC source code on your computer. The MFC source code comes as a part of Visual Studio. The license for Visual Studio implies it is a single product that can not be broken up into its components. So the cleanest way to get MFC on your system is to buy Visual Studio and install it on a dual boot Linux box. Then you must check that you are allowed to recompile MFC on a non-Microsoft operating system! This varies with the version of MFC. The MFC license from Visual Studio 6.0 reads in part:

1.1 General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the SOFTWARE PRODUCT for the sole purposes of designing, developing, and testing your software product(s) that are designed to operate in conjunction with any Microsoft operating system product. [Other unrelated stuff deleted.]

So it appears you cannot even compile MFC for Winelib using this license. Fortunately the Visual Studio 6.0 service pack 3 license reads (the Visual Studio 5.0 license is similar):

1.1 General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the SOFTWARE PRODUCT for the purpose of designing, developing, and testing your software product(s). [Other unrelated stuff deleted]

So under this license it appears you can compile MFC for Winelib. Finally you must check whether you have the right to distribute an MFC library. Check the relevant section of the license on redistributables and your redistribution rights. The license seems to specify that you only have 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. Compiling the MFC Here is a set of recommendations for getting the MFC compiled with WineLib: We recommend running winemaker in '' mode to specify the right options for the MFC and the ATL part (to get the include paths right, to not consider the MFC MFC-based, and to get it to build libraries, not executables). Then when compiling it you will indeed need a number of _AFX_NO_XXX macros. But this is not enough and there are other things you will need to '#ifdef-out'. For instance Wine's richedit support is not very good. Here are the AFX options I use: #define _AFX_PORTABLE #define _FORCENAMELESSUNION #define _AFX_NO_DAO_SUPPORT #define _AFX_NO_DHTML_SUPPORT #define _AFX_NO_OLEDB_SUPPORT #define _AFX_NO_RICHEDIT_SUPPORT You will also need custom ones for CMonikerFile, OleDB, HtmlView, ... We recommend using Wine's msvcrt headers (-isystem $(WINE_INCLUDE_ROOT)/msvcrt), though it means you will have to temporarily disable winsock support (#ifdef it out in windows.h). You should use g++ compiler more recent than g++ 2.95. g++ 2.95 does not support unnamed structs while the more recent ones do, and this helps a lot. Here are the options worth mentioning: -fms-extensions (helps get more code to compile) -fshort-wchar -DWINE_UNICODE_NATIVE (helps with Unicode support) -DICOM_USE_COM_INTERFACE_ATTRIBUTE (to get the COM code to work) When you first reach the link stage you will get a lot of undefined symbol errors. To fix these you will need to go back to the source and #ifdef-out more code until you reach a 'closure'. There are also some files that don't need to be compiled. Maybe we will have ready-made makefile here someday... Using the MFC Specific winemaker options, the configure options, the initialization problem...