Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

Wine Traffic #76 For 1 Jan 2001

By Eric Pouech

Table Of Contents

Introduction

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:

1. Headlines

 

People: , TransGaming

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

2. Wine headers and configuration

25 Dec 2000 - 29 Dec 2000 (12 posts) Archive Link: "Fixes for unaligned memory accesses"

People: Alexandre Julliard, 

Alexandre Julliard, while considering a patch for commit into Wine CVS tree wrote:
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.

The discussion then evolved into what should be generated with the configure tool and what shouldn't. Basically, the summary is:

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 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 winsock.h 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 fd_set:s).

3. TransGaming

27 Dec 2000 (4 posts) Archive Link: "TransGaming DirectX Release"

People: Gavriel State, , Transgaming, TransGaming, Marcus Meissner, Mark

Gavriel State (from TransGaming) announced:
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 we're doing.

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

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 ( http://www.firstmonday.dk/issues/issue4_6/kelsey/).

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 ( http://www.transgaming.com/) 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.

Marcus Meissner pointed out to the Slashdot coverage of this announcement ( "WINE gets Direct3D Support").

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

4. Setting up Winedbg

29 Dec 2000 - 30 Dec 2000 (12 posts) Archive Link: "Problem with Winedbg"

People: 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 (H:debugger/winedbg), 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 ~/.wine/config file.

5. Keyboard autorepeat

29 Dec 2000 - 30 Dec 2000 (2 posts) Archive Link: "keyboard autorepeat patch"

People: Ove Kaaven, Francois Gouget, , codeweavers

Ove Kaaven wrote a patch with the following changelog:
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...

Francois Gouget asked whether the patch was related to a given bug ( #39):
The message sequence that Wine generates when a key is in auto-repeat mode is incorrect.

In Windows one gets a series of WM_KEYDOWN messages. The first one has the 'previous state' bit (30th of LPARAM) 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 WM_KEYUP message.

In Wine the application receives a succession of WM_KEYDOWN and WM_KEYUP messages instead. Note that this description is valid for a key like the down arrow key.

Ove answered:
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 wasn't detectable:
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 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 the next KeyDown event we would send a VM_KEYDOWN with the bit 30 set to 1.

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

However such a patch hasn't been written yet.

 

 

 

 

 

 

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.