Wine Traffic #76 For 1�Jan�2001
Table Of Contents
This is the 76th 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 85 posts in 450K.
There were 26 different contributors.
17 posted more than once.
14 posted last week too.
The top posters of the week were:
- 11 posts in 47K by Francois Gouget <firstname.lastname@example.org>
- 11 posts in 103K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 8 posts in 23K by Alexandre Julliard <email@example.com>
- 7 posts in 32K by Ulrich Weigand <firstname.lastname@example.org>
- 5 posts in 85K by Guy L. Albertelli <email@example.com>
- Full Stats
Well, that's a brand new year, century even millenium opening in front
of us. I really feel like 2001 will be the year of Wine 1.0, including
all the great new stuff, like TransGaming is doing (see article
below), and the great progress on lots of areas:
So, lots of activities are underway and great progress are being
made. So, I really feel like 2001 will even more enjoyable than 2000,
with lots of more of software being ported to Unix using Wine. Corel
efforts in 2000 were only the first and early stones, which shall
bring their full power this year.
Let's meet next year same time, same place and really check what'd
- font handling has now a proper fix (even if it's not implemented
- DLL and process separation is almost done now - only remains the
cross-process message sending which starts being heavily discussed
- WineLib starts to run on Solaris...
Wine headers and configuration
Archive Link: "Fixes for unaligned memory accesses"
Alexandre Julliard, while considering a patch for commit into Wine CVS
The discussion then evolved into what should be generated with the
configure tool and what shouldn't. Basically, the summary is:
I think I mentioned this a couple of times already: standard Windows
headers *MUST NOT INCLUDE* config.h.
There is no guarantee that Winelib apps use the same configure script
as Wine itself, or that they even use a configure script at all. Any
#ifdef in the standard headers must be based on available preprocessor
defines like __sparc__ etc.
This would allow, for example, to keep the same standard headers and
still be able to cross-compile Wine (think of a Windows-CE like system
based on Wine).
Just for information, the listed patch fixed some alignment issues in
Wine code, letting WineLib applications to work on Solaris/Sparc. The
discussion finished in getting around the proper handling for
- configure shall be used for questions around the build process (to
determine headers location, which libraries contain which symbols
- Architecture differences should be defined using
#define:s and provided by the compilation
winsock.h. Currently, it tries to defines the Winsock
prototypes from the Unix system ones (like re-using fd_set when
possible...). However, for this to happen, the
file must know how to include the Unix network headers file (hence the
use of the
config.h file). To get around this,
winsock.h will have to define at its level all the needed
bits (structures and macros), and let the WinSock.dll implementation
take care of the mapping to the networking elements defined by the
underlying system (like
Archive Link: "TransGaming DirectX Release"
Gavriel State,�,�Transgaming,�TransGaming,�Marcus Meissner,�Mark
Gavriel State (from TransGaming) announced:
Marcus Meissner pointed out to the Slashdot coverage of this
"WINE gets Direct3D Support" (http://slashdot.org/article.pl?sid=00/12/30/1427237)
>From the CVS inclusion point of view. The DirectDraw patch has been
committed to the CVS tree. For all the other folks willing to test
Transgaming patch, don't forget to run autoconf; ./configure after
applying the patch.
Several months ago, I promised that wine-devel folks would be among
the first to know what TransGaming Technologies has been up to. While
we're not ready to make a big PR push at this point, we wanted to
make sure that everyone involved in Wine is up to speed with what
Our goal is nothing less than 100% compatibility for running Windows
games on Linux through Wine.
So - we've been working hard on revamping the DirectX code within Wine
to fully support the Direct3D 7 APIs, as well as substantially
restructuring the DirectDraw code. So far, we've been able to get most
of the core Direct3D 7 sample apps up and running, as well as some
major game titles (Sacrifice), and the 3DMark2000 benchmark. We've
implemented most of the code D3D features, including multitexturing,
stencil buffers, alpha blending, fog, etc. We're still working on
optimizations such as holding D3D Vertex Buffers in video memory for
quick access to hardware T&L.
On the DirectDraw side, we've unified the code in the the x11 and DGA
drivers into a new more OO design, separating direct use of xlib from
the core code. We've added an 'update thread' which should make
non-DGA use almost as good as DGA, especially when combined with some
of contextual smarts in the GDI x11 driver Ove submitted a few weeks
ago to speed up DIBsections. We still have some work to do on this
front, since DGA support hasn't yet been integrated into our new
Initially, the Direct3D code will be released with limited
redistribution rights under the Aladdin Free Public License - it will
not be available under the Wine license. The DirectDraw code will be
made available under the Wine license, and we should be submitting a
patch with that code within a couple of days.
In 2001, we will be setting up a subscription service that allows
users to vote on the games they would most like to see working. Users
who pay will be allowed to vote on what we work on next - essentially
a variant of the Street Performer Protocol
Once a set number of users have subscribed to the service we will
release the code under the Wine license. After the initial code is
released under the Wine license, so will all subsequent patches,
assuming we retain a set minimum number of subscriptions.
You can get the AFPLed code from our web site (
now. Once we have some feedback on the 2D side of things, we'll send a
patch to wine-patches for release under the Wine license.
Setting up Winedbg
Archive Link: "Problem with Winedbg"
Alexandre Julliard,�,�Guy Alberte
Guy Albertekku reported that since a patch from beginning of December,
he could no longer get the WineDebugger to start (the patch moved the
WineDbg executable into a .so library).
After some investigations, it turned out that Guy had set up the
debugger with a DOS file name (
whereas current Wine loader code only allowed to start processes
stored in .so files from a Unix filename (and not a DOS one).
Later on, Alexandre Julliard posted a patch to the loader code which
took care of this issue, plus other issues with relative paths.
Even, if, now, you're able to set up a DOS file name as your debugger
path, it's highly recommended to set up a full path (and not a
relative one), because you cannot tell which current directory will be
used when launching the debugger. Also, remember, if you use a Unix
path name to launch any .so file (including Winelib executables), the
Unix pathname must be mappable to one of the Drive:s defined in your
Archive Link: "keyboard autorepeat patch"
Ove Kaaven,�Francois Gouget,�,�codeweavers
Ove Kaaven wrote a patch with the following changelog:
Francois Gouget asked whether the patch was related to a given bug (
I got tired of certain keyboard autorepeat issues. When I played
Monkey Island 4 in OpenGL mode a couple of weeks ago, I had to always
remember to turn autorepeat off (
xset r off
) or there would be
trouble. When I play a DirectInput-using game, I don't have to do that
(because DirectInput does it), but when the game exits, the autorepeat
is still off so I have to turn it on manually (
xset r on
Why do we have to put up with that? We know why (because X autorepeat
isn't detectable). So this patch goes to the root of the problem...
The message sequence that Wine generates when a key is in auto-repeat
mode is incorrect.
In Windows one gets a series of
first one has the 'previous state' bit (30th of
set to 0, and all those that come after have it set to 1. Then when
the key is released the application gets a single
In Wine the application receives a succession of
instead. Note that this description is valid for a key like the down
It's the very same thing. For where XKB is available and supports
detectable autorepeat (certainly at least any PC that runs XFree86),
you could now close the bug.
However, Ove suggested to use Francois' proposal when XKB autorepeat
In most systems you can receive an event saying that such and such key
has been pressed/released, but you can also query whether a given key
is up or down. When we receive the
Ove erased some fears Francois had about the validity of the idea, and
giving hints on places to grab the correct code for doing what had
However such a patch hasn't been written yet.
KeyUp event, would it
be possible to query X to determine if the key is really up or if it
is pressed? If it is still pressed, then we would ignore the
KeyUp event, mark the key as pressed internally, and on
KeyDown event we would send a
VM_KEYDOWN with the bit 30 set to 1.
Sharon And Joy