Wine Traffic #19 For 29 Nov 1999

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..."

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" mentioned on http://www.comdex.com/comdex/owa/session_home?v_session_id=6064 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 attend.

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 committers.
• CodeWeavers is doing fine according to Jeremy. ;)

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 PostMessage16.

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.

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 ;-)

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.

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 all...)

• 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 or WOWCallback16Ex.
  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 calling QT_Thunk.
  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 ...

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 hurt...)

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:

ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/ports/emulators/wine/files/

(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:

http://www.jelal.kn-bremen.de/freebsd/ports/emulators/wine/files/

)