Wine Traffic #19 For 29�Nov�1999

By Eric Pouech

Table Of Contents

Introduction

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:

1. GraphOn patent

�Archive Link: "GraphOn patent"

People: Doug Ridgway,�

Following last week discussion on BROKEN KCREF, Doug Ridgway found the details of the patent (you can get more at IBM online patent site (http://www.patents.ibm.com/details?pn=US05831609__) ):

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

Anyway, it turns out that Wine should be safe regarding this, because:

2. COMDEX Report

�Archive Link: "COMDEX report"

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

3. 16/32 bit weirdness in messages

�Archive Link: "16/32 bit weirdness in messages"

People: Rein Klaze,�Ulrich Weigand,�

Rein Klaze posted a patch to solve issues he had with one application:
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.

Ulrich Weigand gave more details of the problem:
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 ...)

Ulrich Weigand also gave some more information on how Windows handle this type of situation:
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 ;-)

4. 16 bit DLLs and WineLib

�Archive Link: "16 bit DLLs and WineLib"

People: 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 techniques:
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...)

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

5. Wine on FreeBSD

�Subject: "Wine on FreeBSD"

People: J�rgend Lock,�

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 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/ (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/ (http://www.jelal.kn-bremen.de/freebsd/ports/emulators/wine/files/)
)

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.