Wine Traffic #44 For 22 May 2000
Table Of Contents
This is the 4R4threlease of the Wine's kernel cousin
publication. It's main goal is to distribute widely what's
going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 159 posts in 743K.
There were 46 different contributors.
26 posted more than once.
21 posted last week too.
The top posters of the week were:
- 19 posts in 279K by Patrik Stridvall <email@example.com>
- 13 posts in 26K by gerard patel <firstname.lastname@example.org>
- 11 posts in 22K by Alexandre Julliard <email@example.com>
- 10 posts in 31K by Lionel Ulmer <firstname.lastname@example.org>
- 9 posts in 38K by Ulrich Weigand <email@example.com>
- Full Stats
16 May 2000 - 20 May 2000
Archive Link: "Automatic CDECL / STDCALL translation"
Lionel Ulmer, , Patrik Stridval
Lionel Ulmer, while toying with the OpenGL support in Wine, wrote:
For better comprehension, the Linux OpenGL Windows routines are
analogous in their prototypes. Only the calling convention
differs. Linux OpenGL uses the C-decl order, whereas Windows uses the
STDCALL (or PASCAL) calling convention.
Lionel was looking for optimized (maybe ASM based) solutions to do the
reordering of the parameters.
Patrik Stridval provided some code he had written for portability
issues: Patrik wanted to compile Wine with a compiler not supporting
the stdcall convention, but still keeping the ability to call in
native DLLs (which export only stdcall functions). Patrik had in mind
at that time either Solaris on ix86 with the Sun C Compiler (another
use would be any other platform running an ix86 emulator).
Various versions of the patch circulated, including differences
regarding thread safety (some locks must be set before entering the
OpenGL functions), reentrancy (can an OpenGl function be called - thru
this thunking mechanism - while already executing the call to another
OpenGL function), PIC (since the generated code can be put in a .so
file, it needs to be Position Independant Code - all references are
No final word has been spoken yet (either on a working patch, nor a
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...
MFC and Wine
19 May 2000 - 20 May 2000
Archive Link: "MFC questions"
Wilbur Dale, Gavriel State, Jutta Wrage, , Jeremy White
Wilbur Dale wrote
Wilbur then asked for some advices on how to do it.
Gavriel State was the first to fire back:
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
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
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.
Also, Jeremy White continued on the same path:
Gavriel also pointed out some interesting changes in the MFC licence
from Microsoft. Basically, and without too much of lawyer talking,
Microsoft removed the need to run code using MFC on a Microsoft
OS. So, if you have a licence for MFC (of the correct type, seems that
SP3 for MSVC 6.0 allows it), you can, for personal use, compile and
use the MFC lib under Linux!
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).
Sharon And Joy