Wine Traffic #17 For 15 Nov 1999

By Eric Pouech

Table Of Contents

Standard Format
Text Format
XML Source
Introduction
Mailing List Stats For This Week
Threads Covered

1. Portability

2. Process creation

3. Overlapped I/O

4. Bleem!

Introduction

This is the sixteenth 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).

Wine 991114 has been released. The major improvements are:

ICMP DLL support.
Many fixes for better portability.
Debug APIs now based on ptrace.
Still more features in common controls.
Lots of bug fixes.

Mailing List Stats For This Week

We looked at 116 posts in 500K.

There were 31 different contributors. 19 posted more than once. 18 posted last week too.

The top posters of the week were:

15 posts in 32K by Alexandre Julliard <julliard@lrc.di.epfl.ch>
12 posts in 52K by Moshe Vainer <moshev@easybase.com>
12 posts in 35K by Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
11 posts in 87K by Ulrich Weigand <weigand@informatik.uni-erlangen.de>
6 posts in 21K by lawson_whitney@juno.com
Full Stats

1. Portability

Archive Link: "Portability"

People: Alexandre Julliard, , Patrik Stridval

Patrik Stridval kept enhancing his winapi_check tool (which is Wine home grown tool for checking coherency in various files - .spec / .h / .c) and came into some problems with portability issues and the HAVE_xxx macros. Wine (like many other Unix programs) uses configure to determine, before compiling, which include files, functions... are available on the target platform.

When a function (say gethostbyname) is to be used, it is tested by configure, and if found, a HAVE_GETHOSTBYNAME macro is defined.

Latest version of wineapi_check reports some incoherence between the known HAVE_XXX macros and the effectively used functions.

A discussion ensued between Patrik and Alexandre Julliard. The output, and the general rule of thumb for handling this type of function, is to:

check for the existence of the file with configure
do not use the HAVE_XXX macros for functions in the main code, but just add a stub (possibly returning error condition) in misc/port.c when the HAVE_XXX macro is not defined (this could also be added to another .c file if the function is only used in this place)
if needed, missing structures shall be added to include/wine/port.h.

With those rules, the code will not be encumbered with

#ifdef /
#endif

pairs all over the place, which degrades both readability and maintenability.

2. Process creation

Archive Link: "Process creation"

People: Uwe Bonnes, Ove Kåven, Alexandre Julliard, , Ulrich Weigand, Peter Hunnisett

Peter Hunnisett while toying with WineLib, reported two issues.

The first one was that CreateProcess implementation didn't use the CREATE_SUSPENDED flag, and thus made some trouble. Alexandre Julliard and Ulrich Weigand discussed a bit the implementation of such a feature and Alexandre provided the patch.

Basically, when a new process is created, several things have to be taken into account:

let the process calling CreateProcess wait until the new process is created (so that a correct error code can be returned)
have the newly created process do some initialization (part of this can be done a the context of process calling CreateProcess, but most of it must be done in the context of the new process).

Therefore, some synchronization is needed. Most of it was already in place. There is an event created at each process creation, used by the created process to signal its creator that it's initialization is done and it can return from CreateProcess. What has been done is that the server now handles this event signalling (so that the created process can be suspended by the server).

Peter's second issue was a bit more tricky. Peter wanted to have a WineLib program be launched by the Wine emulator (this is supported and works fine) but also be integrated with the Wine emulator (e.g use the same thread/process ids...).

Unfortunately, this is not supported yet and would require the (in)famous address space separation in place. The best solution right now is to create a PE (or NE) executable and run it in the emulator. Peter then asked for a list of tools to be used to create it under Linux (in other words: a cross compilation chain running under Linux generating Windows executable).

Several tools are known:

Uwe Bonnes proposed to
have a look at http://www.sourceware.cygnus.com/cygwin (http://www.sourceware.cygnus.com/cygwin) for mingw (find pointer to it on the http page above); it uses Windows crtdll and supports threading.
and also
If you want a light weighted tool and don't need c++ support, look for lcc-win32: http://www.cs.virginia.edu/~lcc-win32/ (http://www.cs.virginia.edu/~lcc-win32/) . For some old version of lcc I have a linux port available, but the command line tools then run under wine too. I don't know the present status.
Ove Kåven proposed to
to install the Cygnus GNU-Win32 stuff and configure gcc to cross-compile with that
( http://web.ukonline.co.uk/julian.smart/wxwin/technote/crosscmp.htm (http://web.ukonline.co.uk/julian.smart/wxwin/technote/crosscmp.htm) ).
and of course, you can check http://www.winehq.com/tools.html (http://www.winehq.com/tools.html)

3. Overlapped I/O

Archive Link: "Overlapped I/O"

People: Ove Kåven,

Moshe Vainer, while trying to let CodeBase 6.x work under Wine, pointed out that Wine doesn't correctly support overlapped I/O.

Ove Kåven (at Moshe's request) gave some more information on this:

Overlapped I/O is simply asynchronous I/O. The ReadFile call requests that data be read (asynchronously, in the background), then returns and lets the app do other stuff until the request is satisfied/completed. When that is the case, the OS can signal an event object specified in the overlapped buffer, if the app so desires. When that happens, it can call GetOverlappedResult and process the data now in the data buffer...

I'm not sure why such a mechanism would exist in Windows, since normal multi-threading can accomplish the same thing. It certainly wouldn't make the kernel less bloated, nor application programming much simpler, so I can only assume it's for performance reasons (cut down number of threads, perhaps since windows has limited resources and is a lousy multitasker or something).

So far, Wine does not support overlapped I/O. Several ways of implementing it have been discussed. The easiest one is simply not to handle the request in the background (but to do it inside ReadFile or WriteFile), signal the caller within ReadFile/WriteFile and have GetOverlappedResult always return TRUE.

Some more complicated implementation would require threading (or service thread support). Anyway, it also turns out that Windows 9x only supports overlapped I/O for the serial line or socket, but not on disk files. Win NT also supports overlapped I/O for disk files. So the first and easy implementation shall do for a first round.

Patches for this implementation circulated, but it just helped CodeBase crash a little farther. No success story yet.

4. Bleem!

Archive Link: "Bleem!"

People: , Ulrich Weigand, Ian Schmidt

Ian Schmidt, while trying to make Bleem! work under Wine, needed to emulate some more calls to the virtual memory manager VxD (which are by the way also needed by Internet Explorer).

After some fights with Microsoft documentation, some fixes on VirtualAlloc, things went better (read: it ran further before crashing) until some explanation from Ulrich Weigand boiled the thing down to bad news: some tricky Bleem! code calls MapLS/UnMapLS in a certain way to get back the LDT base address, and then modify it for getting access to ring-0, and then create its own threads inside the VMM. This is certainly a very bad way of writing applications, and a sign of Windows 9x not being protected (as an OS).

The conclusion is that it will be nearly impossible to let Bleem! (and other badly written applications) run under Wine.

This type of behavior will not be permitted under NT, and some discussion went on for implementation of type of direct LDT access under Wine, but did not go very far.

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.