![[LWN Logo]](/images/lwn.banner.gif)
Date: Mon, 15 Nov 1999 20:16:19 +0000
From: Eric Pouech <Eric.Pouech@wanadoo.fr>
To: "Wine annouce (WWN publish)" <wine-announce@winehq.com>
Subject: Wine Weekly News #17 (1999-Week 46)
This is a multi-part message in MIME format.
--------------B3A031465E2263CDC0796681
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please find enclosed this week WWN. You can also read it online
(and browse previous issues) at http://www.winehq.com/News/
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
--------------B3A031465E2263CDC0796681
Content-Type: text/plain; charset=iso-8859-1;
name="wwna.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="wwna.txt"
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for November,
15th.
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
* Alexandre Julliard, Jeremy White and Marcus Meissner will be
talking about Wine at Comdex Las Vegas (Tue Nov. 16).
* Wine 991114 is out.
_________________________________________________________________
Keeping Track of Wine
_________________________________________________________________
* Ulrich Weigand fixed exception handling, version handling, memory
wipe reliability, loader, and VxDCall variable arguments, and did
some preliminary porting of Winelib to (32-bit) Sparc, doing some
architecture modularization in the process.
* Moshe Vainer added a stub for GetOverlappedResult.
* Rein Klazes corrected some version-specific control color message
handling, and CoGetClassObject options.
* Patrik Stridvall did more porting of Wine to his favourite
platform Solaris.
* Alexandre Julliard fixed a potential wineserver crash, made it
possible to create a process initially suspended, added
ReadProcessMemory/WriteProcessMemory support to wineserver, and
fixed page rounding.
* Huw D M Davies fixed a registry saving problem, and documented how
to set up Wine's PostScript driver.
* Eric Pouech fixed MIDI and MMIO bugs, and added some OLE stubs.
* Ove Kåven fixed a resource leak in DirectX XShm.
* Jeremy White added a general hex dump debug facility.
* Gerald Pfeifer made ptrace usage BSD-portable. (This made it
Solaris-unportable, though, something Alexandre has tried to fix
later.)
* Adrian Thurston submitted Corel patches for file dialog, property
sheet.
* Klaas van Gend mostly implemented the PrintSetup dialog box.
* Jürgen Schmied added a binary resource converter, improved
filedialog, and did more work on shell32.
* François Gouget made ICMP implementation compile on libc5.
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 116 posts consumed 500 K. There were 31 different
contributors, 19 (61%) posted more than once, and 18 (58%) posted
last week too.
The top posters of the week were:
* 15 posts in 32 K by Alexandre Julliard <julliard@lrc.di.epfl.ch>
* 12 posts in 52 K by Moshe Vainer <moshev@easybase.com>
* 12 posts in 35 K by Uwe Bonnes
<bon@elektron.ikp.physik.tu-darmstadt.de>
* 11 posts in 87 K by Ulrich Weigand
<weigand@informatik.uni-erlangen.de>
* 6 posts in 21 K by lawson_whitney@juno.com
* 6 posts in 19 K by Ian Schmidt <ischmidt@cfl.rr.com>
* 6 posts in 12 K by Ove Kaaven <ovek@arcticnet.no>
* 5 posts in 55 K by Eric Pouech <Eric.Pouech@wanadoo.fr>
* 5 posts in 19 K by "Peter Hunnisett" <hunnise@nortelnetworks.com>
Portability Evolution
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 between Patrik and Alexandre Julliard triggered. 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.
Process creation Issue
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
[1]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:[2]
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" ([3]
http://web.ukonline.co.uk/julian.smart/wxwin/technote/crosscmp.htm
).
* and of course, you can check [4]http://www.winehq.com/tools.html
Overlapped I/O Issue
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.
Bleem! Issue
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 crashed further) 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 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.
Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove Kåven.
_________________________________________________________________
References
1. http://www.sourceware.cygnus.com/cygwin
2. http://www.cs.virginia.edu/~lcc-win32/
3. http://web.ukonline.co.uk/julian.smart/wxwin/technote/crosscmp.htm
4. http://www.winehq.com/tools.html
5. mailto:ridgway@winehq.com
6. mailto:pouech@winehq.com
7. mailto:ovek@winehq.com
--------------B3A031465E2263CDC0796681--