Wine Traffic #44 For 22 May 2000

After doing some benchmarks, I found out that the OpenGL performance is not too bad compared to Windows: about 25 % slower on the Tirtanium benchmark when removing the X11 critical section protection, 50 % slower with it.

Now, I think most of the remaining frame per second are lost in the CDECL -> STDCALL conversion of all the OpenGL routines. I looked at the code GCC generated for the OpenGL code and it's not really efficient: it 'pops' all the arguments in registers and then pushes them again for the calling of the CDECL function...

Over the past few months I have been working with wine and winelib in my spare time. Eventually I hope to port a Win32 app to linux using winelib. The next major hurdle in the port is MFC. I see two paths and I am seeking advice and help.

1. Compile MFC. Several years ago we (Lumin Software) tried to compile MFC. The attempt failed and we found another way to do what we wanted. MS documentation states that compiling MFC was deliberately made difficult. Considering my experience with stuff they call "easy" I am not looking forward to compiling MFC. We are currently using Visual Studio 5 for windows development.

2. Create some code that loads and initializes the MFC library and allows access to the MFC functions from within winelib. I know how to do this. I successfully ran the EdrTest/EdrLib example from Petzold last weekend. In my code, I had edrtest compiled under winelib and it ran the functions using the windows compiled edrlib.dll. I think this solution may be easier, but it requires over a thousand functions in MFC to be hooked up. However, it looks like the process can be automated. There is a text file (MFC42.DEF) with the MFC libraries that contains the ordinals and the mangled names. From this file it is possible to automatically create the spec file, the pointers to functions, and the initialization of the pointers. The automation would require a name de-mangler. So far I have found no documentation on MS C++ name mangling.

At Corel, we had MFC compiled and running sample apps in WineLib in late 1998. It's mostly a question of the Wine headers, which weren't originally up to snuff. We did quite a bit of work on them, and most of those changes have been contributed back to WineHQ, so it should be pretty easy now. The other thing that was a big deal was getting the startup code working properly - since MFC needs to initialize static data after WineLib gets initialized. I believe that that issue has been addressed now on the WineHQ side with some of the work done on the .spec file tools recently.

Despite your previous experience, and despite my earlier incorrect statements, I think that this is simpler than you fear. It's one of those tasks that's darkest before the storm - you spend all of your energy getting all the include files to work. Once you have one object file, the rest go much more quickly (alright, getting it to link is also a hairball of a job, but it's tractable <g>).

If you're not in a hurry, getting MFC to compile, and having a documented procedure for compiling it is on our agenda for the relatively near future (see the Wine 1.0 task list).