Wine Traffic #19 For 29�Nov�1999
Table Of Contents
This is the nineteenth release 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 119 posts in 575K.
There were 35 different contributors.
19 posted more than once.
12 posted last week too.
The top posters of the week were:
- 18 posts in 45K by Alexandre Julliard <firstname.lastname@example.org>
- 14 posts in 36K by Ulrich Weigand <email@example.com>
- 13 posts in 46K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 8 posts in 25K by Huw D M Davies <firstname.lastname@example.org>
- 7 posts in 98K by Peter Ganten <email@example.com>
- Full Stats
�Archive Link: "GraphOn patent"
Following last week discussion on BROKEN KCREF, Doug Ridgway found
the details of the patent (you can get more at IBM online patent
Anyway, it turns out that Wine should be safe regarding this, because:
filed June 6, 1995, in continuation of a patent filed in 1994:
The present invention is directed towards a translation software
that provides remote access to an application program that is
executing on a host machine in its native operating system
environment. The translation software monitors messages that are
relayed from the application program to an application interface that
is provided via the native operating system..."
�Archive Link: "COMDEX report"
Marcus Meissner,�CodeWeavers,�,�Jeremy White,�Douglas Ridgway
Here's Marcus Meissner report on his COMDEX visit:
You might remember me asking about who is going
to talk on COMDEX Fall'99 in Vegas.
Since nobody came forth, Jeremy White asked Douglas Ridgway if there
was someone speaking on COMDEX... Douglas did not know either, so
Jeremy called ZD Events. It turned out that the "project leaders"
actually was some marketing guy of Corel who had canceled this talk.
ZD Events even asked if Jeremy didn't knew something of WINE and he
would like to do the talk ... You might guess the reaction ;)
Since Jeremy does not know much about the technical details, and
Alexandre does not really want to talk since his spoken english is not
very fluent, Jeremy asked me to participate too.
So we met on the COMDEX floor 2 hours before the talk, did merge the
slides of my denmark talk with slides of Jeremy and Alexandre and
prepared a small demo.
The whole thing happened in the Las Vegas Hilton, Pavilion 1,
capacity around 200 people. We did not fill the whole room, but I
guess approx 120 (?) people were in there. Not much suits in the
audience, but with computer people you never know anyway who might
No other WINE developers came forth except us 3.
Jeremy started on what WINE is, and what it might mean to business
people including a brief history.
I followed with the largest part, a basic introduction to the
technical side of WINE, how it works, what parts are implemented how,
and problems we do face.
Alexandre concluded with a current overview of the project, what is
done, and what needs to be done and how users can help. One
interesting point he said that the 1.0 release might even happen, but
probably not before second quarter 2000.
After this Jeremy demoed Pegasus Mail and I demoed Monkey Island 3.
We did some Question and Answers after that, some did go over to
specific business question to things CodeWeavers does, some others
went to specific implementation details.
The talk seem to well received, but not overly enthusiastic.
Afterwards Jeremy, Alexandre and I went to a small bar and had some
real wine (beer in Alexandre's case ;) on the European WINE partyfund.
In general, some points that came up that might be interesting:
- Jeremy and Alexandre are considering a WINE developer conference
sometime next year. Either on European soil or on North American.
- The reason for the almost instantly following cvs commits is that
Alexandre processes patches in batches, reads through them to consider
them good, and applies them in batches if they do not interfere
- The reason why he does think that multiple committers are a bad
idea is the inherent complexity of WINE, and that even small changes
may break stuff and that it would get out of control with multiple
- CodeWeavers is doing fine according to Jeremy. ;)
16/32 bit weirdness in messages
�Archive Link: "16/32 bit weirdness in messages"
Rein Klaze,�Ulrich Weigand,�
Rein Klaze posted a patch to solve issues he had with one application:
Ulrich Weigand gave more details of the problem:
I have an application here that has stopped working since the
introduction of 32 bit message queues.
The application breaks when it posts a WM_COMMAND message using
The message is received by a GetMessage and dispatched by
DispatchMessageA in DIALOG_DoDialogBox(). However these are win32
functions and when calling the 16 bit dialogproc, a message
translation 32->16 bits is done which messes up the parameters.
Ulrich Weigand also gave some more information on how Windows handle
this type of situation:
Actually, this is just a symptom of a more general problem: retrieving
a message that was posted with PostMessage16 using GetMessageA (or
vice versa) is broken.
I'm not sure yet what the correct fix for this problem is, but it will
probably have to involve message translation at some point...
As a temporary fix, using either 16- or 32-bit GetMessage in some of
the Wine-internal message loops (as your patch does) might help a bit,
but I think your trigger is not quite correct: actually, whether the
16- or 32-bit version of DoDialogBox was called isn't of any interest;
the question should rather be whether the one
message that is next
in the queue was posted
using 16- or 32-bit PostMessage.
(Note that you can have those messages mixed
in the same
queue. Sure, a 16-bit program tends to have 16-bit messages in its
queue, which is why your patch works for you, but it could just as
well get messages posted into its queue by other
, 32-bit apps -- or
simply by libraries that have thunked up ...)
These 16/32 bit conversions most definitely exist in Win9x ;-) In
fact, the Win95 USER always converts all messages to the 16-bit style
before doing anything else.
[ This is not quite
as bad as it seems, as the Win95 '16-bit' style
is different from the original Win3.1 message style in that it allows for a
DWORD wParam internally. Thus, conversions 32->16->32 do not clobber
the high word of wParam; they do forget the high word of uMsg, however,
which is why you can't use user-defined messages > 65535 on Win9x. ]
For Wine, I guess tagging the messages with a flag would be
preferable, as we could avoid conversions in the typical case, then.
The question remains what to do with those messages containing a
pointer; the default message conversion converts 32-bit to 16-bit
pointers, either allocating selectors on the fly or copying data to
the segptr heap. These need to be freed to avoid leaks, which is no
problem in the case of SendMessage() (where the conversion already
works), but is difficult in the case of GetMessage(), as we don't know
how long the app will keep the pointer...
Win95 solves this problem in a quite simple way: if a pointer would
need to be converted while retrieving a message with GetMessage(),
this message is simply silently dropped from the message queue ;-)
16 bit DLLs and WineLib
�Archive Link: "16 bit DLLs and WineLib"
Lawson Whitney,�Ulrich Weigand,�
Lawson Whitney was looking for a way
to [load and]
call a function exported by a 16-bit dll (or the built-in, when it
gets to be more than a stub) from a winelib program. If the windose
API was anything but nested brain-damage and leveraged fertilizer,
there would be a CallProc16 exported by kernel32 for the purpose. I
mean, there is a GetProcAddress16, which is not much use without
one. For that matter, I don't see any reason wine should not have one
just because windose doesn't.
Ulrich Weigand gave a list of ways to do it using regular Windows
If you want to use standard Win32 calls, you have basically three
possibilities: either Universal Thunks, or Generic Thunks, or else
Flat Thunks. (Note that depending on the particular Windows version,
not all of them are available on real Windows. Only Win9x has them
- Universal Thunks
You just need to call UTRegister. This will load a 16-bit DLL,
retrieve the address of a specified 16-bit routine, and return a
32-bit function pointer that you can call whenever you want the 16-bit
function to be called.
Disadvantages: you can use it only once (per 32-bit module), so you
can call only one 16-bit routine.
- Generic Thunks:
These are intended to be used starting from 16-bit code, so it's a
little awkward to use if you want to start from 32-bit code. At least
under Wine, however, you should be able to load the 16-bit DLL using
LoadLibrary16, retrieve the address of a routine using
WIN32_GetProcAddress16, and then call the function using WOWCallback16
Disadvantages: probably won't work this way under Windows.
- Flat Thunks:
These are intended to be used via assembly glue code provided by the
Windows Thunk Compiler. As we don't have that, you'd need to simulate
this e.g. by setting up a CONTEXT86 structure as required and then
Disadvantages: difficult to use, won't work this way under Windows.
So, I'd recommend using UTRegister if you only want to call one routine
(this will also work on Windows), and using WOWCallback16 if you have
more than one or don't care whether it runs on Windows as well ...
Wine on FreeBSD
�Subject: "Wine on FreeBSD"
J�rgend Lock provided some extra documentation for patches to apply to
the FreeBSD kernel in order to have the better support:
Similarly if you are on FreeBSD you may want to apply an LDT sharing
patch too (unfortunately this one still isn't in the tree, neither
-current nor -stable), and there also is a small sigtrap fix thats
needed for wine's debugger. (Actually now that its using ptrace() by
default it may no longer make a difference but it still doesn't
And if you're running a system from the -stable branch older than Nov
15 1999, like a 3.3-RELEASE, then you also need to apply a signal
handling change that was MFC'd at that date. More information
including patches for the -stable branch is in the ports tree:
(the signal handling patch, patch-3.3-sys-fsgs, and the latest
README haven't yet been committed as i write this, if they still
aren't there when you look, go here:
Sharon And Joy