Building MFC for winelib has been addressed many times earlier on this list, from what I can see, since at least 2001 if not earlier. However, all together I cannot seem to find a well-written documentation of the process involved to build libmfc.so.
So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib.
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
Thanks!
Dan Dennison dand@csun.edu
Hi Dan,
--- Dan Dennison dand@csun.edu wrote:
So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib.
Nice! It would be good to have this documentation.
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
Just this stuff here http://www.winehq.com/docs/winelib-user.html#MFC
Thanks Steven
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
On Sat, Jan 22, 2005 at 01:19:35PM -0800, Dan Dennison wrote:
So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib.
Cool, this would be very valuable indeed.
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
All we have is this:
http://winehq.org/site/winelib#atlmfc
Dimitrie O. Paun wrote:
On Sat, Jan 22, 2005 at 01:19:35PM -0800, Dan Dennison wrote:
So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib.
Cool, this would be very valuable indeed.
I agree. Actually, we are doing this also. I started with the work done by Boaz Harrosh, and found it helped a great deal (we also are using ATL, __uuidof, etc...).
In fact, I often wonder why his work (which is very impressive) was not included in the base? It would seem ATL/MFC support is a very worthy addition to Wine. Anyone care to re-discuss why his patches were rejected?
I would be willing to help resubmit them, but I'm not really familiar with the path process. Boaz himself has always been very helpful, and a great source of information!
Geoff
Geoff Hart wrote:
In fact, I often wonder why his work (which is very impressive) was not included in the base? It would seem ATL/MFC support is a very worthy addition to Wine. Anyone care to re-discuss why his patches were rejected?
This is my own fault I never sent them. I sent them to wine-devel and not to wine-patches for review. I did not send them because they are kind of useless with out an example Project and Makefiles, and the ones I have are all old vanilla gcc Makefiles. I never came to the point to port them to winegcc Makefiles. So they are Just there on the mailing-list archives.
Free Life Boaz
Dan Dennison wrote:
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
Thanks!
Dan Dennison dand@csun.edu
I have done it up here last year. I did not post any results because by the time I finished they changed the winelib make system on me (move to winegcc) and I could not find any time to update it. If you want that I send you all the old system I can do that (Save the MFC source itself of course). Here are some notes on my experience.
MFC was actually easy. At the end I had MFC compiled out of the box with a trivial number of changes. The real changes are very few. 1. The "(...)" functions and C++. In msvc if a C++ object is passed to a printf like function the object is Just put on the stack struct style (all members pushed, so that, at the end, the exact struct layout is in stack memory.) In gcc it will issue a WARRNING and core dump in runtime. So in MFC all print("%s" ,aCStringObj) need change to printf("%s" ,(LPCSTR)aCStringObj) . 2. A very few "typename"s missing in templates. (MSVC7 MFC is better in that but has other problems)
That's it, no real code change, and NO comment out of 4000 lines (Like mentioned in wine documentation.)
The all secret is in the compiling Environment and the set of headers files: 3. Other than the pure MFC source files you will need other MS headers from MSVC\Include and MSVC\crt\src Since they come with the same License as MFC you can use them freely. (If you paid for your MSVC copy). Here too I can send you the list of extra needed files. My List is old and probably some are already not needed as wine catches up very fast. I did not put these headers in the wine/Include but in an extra Include dir that has lower precedence than wine/Include, so any headers missing from wine are taken from msvc/include. (At first I took the all MSVC headers set and winemaker them). Later I narrowed them down to as needed bases. 4. Some g++ headers need a special copy inside the wine tree and the -system (I think that is the switch) use, so g++ does not try to find any of its original headers. These are the "typeof" and other core C++ headers. And they need to be changed a bit mainly to be able to survive with msvcrt wine headers, and to not reference any gcc originals. (This step is mainly for STLPort and ATL see below). In general NONE of the original GCC++ headers can be used. This is because: 5. Use the MBCS switch in wine. MFC is highly MBCS and I think even in msvc on windows it will not compile with out it. (Perhaps UNICODE is also good but I never got there) And with out mention you need to use msvcrt (-nocygwin). 6. All these "Get off my neck and stop sucking my blood" GCC switches must be used. Most of them are mentioned in wine documentation and/or are default for winegcc, maybe a couple extra for C++ specific stuff. 7. Compile main ATL. The main ATL files (3 I think) are included in MSVC6-SP5 version of MFC. If they compile your life is much easier. Here as opposed to MFC there are more changes to do. (But it is only a few files). See my post of one year ago on the wine-devel archives search for "For compile of MFC and ATL". Attached are a couple of patches that will make your life a bit easier when compiling ATL. Or maybe find an MFC that does not use ATL (old versions did not) 8. To Makefile or not to Makefile, this is the Question? By far most of the work is in the Makefile (and directory layout). You must decide if you want a static lib or a dynamic fake C++ DLL. In some projects you must have the later but it is harder to do, (and very slow on load time). Than you need all your winebuild/winegcc flags just right. (Depending on the type of lib you're building) 9. WARRNINGS. Try to eliminate any warnings because in G++ some warnings are errors. (See above) See my Patches (above) on how to do that.
This is just what I remember probably it is only half of it. If we look at 8, above, it is perhaps easier to do what Dimi always says. First compile it on MinGW on windows than you can be sure your Makefiles are good, than the winelib is 90% there. (I never did that so I'm not sure what problems hide there). But for sure you will not have 2, and you then know the file listing for 3. If you do go that rout than MinGW project will also be happy with your paper as well as Wine.
Well good luck
Free Life Boaz
On Sat, 22 Jan 2005 13:19:35 -0800, Dan Dennison dand@csun.edu wrote:
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
Excellent. Also, does anyone know the (US) legal aspects of this? Is there a EULA that prevents it or doesn't prevent it? Is redistributrion allowed in any way? Bonus points for figuring out what countries it's legal or not legal to do so in.
-Brian
Brian Vincent wrote:
On Sat, 22 Jan 2005 13:19:35 -0800, Dan Dennison dand@csun.edu wrote:
Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib?
Excellent. Also, does anyone know the (US) legal aspects of this? Is there a EULA that prevents it or doesn't prevent it? Is redistributrion allowed in any way? Bonus points for figuring out what countries it's legal or not legal to do so in.
-Brian
I checked it out. Actually I had some e-conversation with the MSVC project manager. To put it as simple as possible: You can publish any using code as you wish. You can look at sites like Codeproject and Codeguru. They have lots of MFC/ATL related code freely on the net. You cannot however publish any MFC or ATL code or fixed code. We had a discussion about DIFF files and he was not sure about them, has he is not a legal professional. So he said I'll have to get in touch with the Legal department at MS - Which I did not. A lawyer friend told me that DIFF files are problematic since in the "-" statements and surrounding code is actual MFC code that is IP of MS. A binary patcher would be better for that. However it is definitely aloud in the EULA that I send you a DIFF file if you are a legal owner of MFC (MSVC++) and I am employed by you (Part of your team). But my lawyer friend said that if put to court. Then It is better I had proof that you paid me for that work. (Even something trivial). So in short Derived work (ala Codeguru) is allowed and recommended. Actual MFC even changed MFC is not. It is, if it is for me and I'm a legal owner of an MSVC++, for any purpose on any platform.
Needless to say, that they where not Interested in the patches I had for ATL that makes it compatible for other compilers. And is perfectly good also for MSVC++ compilers. My reasoning was that this way ATL can be used for COM/DCOM servers that run on other platforms (Mainframes to embedded systems). His answer was: that they have support for all these platforms as WINCE and Win/U and special MS partners. (Which is not true) Win/U has a special version of MFC but they do not, or can, compile ATL/WTL, for all of the same reasons, MSVCsim .
Free Life Boaz
-
Boaz Harrosh -
Brian Vincent -
Dan Dennison -
Dimitrie O. Paun -
Geoff Hart -
Steven Edwards