Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #120 For 17 Apr 2002

By Brian Vincent

Table Of Contents

Introduction

This is the 120th 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 418 posts in 2660K.

There were 98 different contributors. 51 posted more than once. 26 posted last week too.

The top posters of the week were:

1. News: wine-20020411, WineHQ Update

30 Mar 2002 - 17 Apr 2002 (2 posts) Archive Link: "News"

Topics: News

People: , Jeremy Newman, Lindows.com, News

Alexandre announced the release of wine-20020411 last Thursday. Included in the announcement are the following changes and additions:

Thanks to everyone who responded a few weeks ago about having commercial news appearing here. There was an overwhelming response (to the point of being unanimous) to keep it in. This week I decided to do something a little different by adding different sections for some of the news from Trangaming and Lindows.com; both generated enough news this week to warrant it. In the future you'll find news confined to the first topic.

Also worth noting is Jeremy Newman's work over at WineHQ. Among other things, Jeremy added an XML parser to the site and given it a facelift. As far as Wine Weekly News goes, issue #118 was the first to have the same XML appear on both KC Wine and the Wine Weekly News. I'm in the process of doing a massive cleanup on past issues from 1999 and 2000 to merge some of the differences between the two.

2. ReWind: The X11 Tree

12 Apr 2002 (1 post) Archive Link: "X11 fork available"

Topics: X11 Tree

People: Ove Kaaven, , Ove Kåven, Eric Pouech

Ove Kåven announced the availability of the Wine X11-license code on SourceForge:

Ever since the main Wine tree changed its license to the LGPL, a fork of the tree under the old license had seemed necessary, and been planned. This fork is now ready.

If you're a Wine contributor that don't care all that much about forking, you do not need to leave the official LGPL-ed Wine tree to let the X11-licensed fork live. All you have to do is to agree to license your patches under the X11 license, so we are able to pick it up from wine-patches and apply it to the X11 tree whenever possible. This will make your contributions more widely used, so we encourage as many as possible to do so. And if it's out of the question for you, then we encourage you to tell us that, so that we know that we can never apply your patches.

The fork's name was decided after a lot of brainstorming by Eric and me, when we found a name which we both liked... ReWind. It can stand for "Re-engineering Windows", or something like "Rewind to the old Windows days".

The fork is currently hosted on SourceForge. The homepage is thus http://rewind.sourceforge.net/ for now. It's not a very fancy page, but all the necessary CVS and mailing list information is there. Go there if you're interested in contributing actively to ReWind. Patches known to come from X11-friendly contributors are already applied to the CVS, but many more patches are waiting for the authors to declare a stance.

The CVS repository that ReWind is based on is the WineHQ repository, cleansed of all post-LGPL commits (except the Before-LGPL tag), so all the CVS history of the pre-LGPL Wine is present in the ReWind CVS repository. This ensures that no history is lost in the event that the X11 fork prevails over the LGPL fork.

Your help to achieve this is welcome.

Followups to this post should preferably go to wine-license.

Thanks for your attention.

Ove and Eric Pouech are also tracking recent contributors to Wine at: http://rewind.sourceforge.net/contribs.html. Quite a few developers have expressly consented to having their patches included in the X11 tree. There's also a huge list of people who fall into the "unknown" category - if you're submitting patches to wine-patches you may want to let Ove or Eric know if it's okay to also add your patch to ReWind.

3. TransGaming: WineX 2.0

16 Apr 2002 (1 post) Archive Link: "TransGaming: WineX 2.0"

Topics: Transgaming

People: Transgaming, Max, , TransGaming, Gavriel State

TransGaming announced the availability of WineX 2.0:

WineX 2.0 allows over 80 Windows games to run on the Linux operating system, seamlessly, transparently, and right out of the box. "This is another breakthrough for TransGaming. No other company can do what we do. In February we brought DirectX 8 capabilities to the Linux platform demonstrating how quickly and effectively our technology can keep pace with Microsoft development," remarks company CEO & CTO Gavriel State. "And today, WineX 2.0 opens the door for the latest 'high twitch' PC games to run on Linux. Our subscribers have been eagerly anticipating this release and we're confident it will meet their high expectations."

Max Payne and Jedi Knight 2: Jedi Outcast are some of the new titles that work. Other changes include:

Subscribers get the benefit of being able to download binaries (.rpm and .deb packages) as well as Safedisc copy protection support and improved InstallShield support.

Gav also updated his column on the web site to include news about Transgaming's views on the recent licensing changes.

4. Lindows.com: Sneak Preview 2

7 Apr 2002 (1 post) Archive Link: "Lindows.com: Sneak Preview 2"

Topics: Lindows

People: Michael Robertson, April 17th Debian Weekly News, , Lindows.com, News

Lindows.com announced their latest beta release available to registered users of their "Insiders" program. Michael Robertson explains the biggest addition to Sneak Preview 2:

Click-N-Run is a powerful new feature in the latest preview of our operating system, LindowsOS, which opens the door to a world of high-quality software solutions that can be instantly zapped to any machine running LindowsOS. Finding and installing software has always been a tricky, time-consuming experience. LindowsOS users can now browse a warehouse of software titles in a rich graphical presentation via the Warehouse tab on Lindows.com or by launching Click-N-Run from their desktop. From here they can read descriptions of products, do comparisons, and view screenshots and best of all, a single click will download and install the title of their choice. Never before has it been this simple to peruse software titles and add them to your computer.

Newsforge has a review.

Some people aren't happy with the lack of attention Lindows.com seems to have towards software licenses. Bruce Perens wrote an open letter to Michael Robertson this week to discuss GPL'ed parts of LindowsOS. As described in the April 17th issue of the Debian Weekly News:

Bruce Perens, former Debian Project Leader and Free Software evangelist, recently sent an open letter to Michael Robertson, CEO of Lindows.com, Inc. Bruce points out very politely that they are both partners, who have agreed to certain rules. The main reason for sending this letter is that a first beta version (binary-only) of LindowsOS, which is said to be based on Debian, has been released to a limited number of beta testers and the company hasn't yet fulfilled its source-code obligation. Bruce was also distressed by Robertsons treatment of the FSF and Bradley Kuhn, which was reported in Newsforge.

[Ed note: I changed the URL's referenced into hyperlinks in the above paragraph.]

Michael Robertson notes that
the ability to run Microsoft Windows software titles
has not improved in their latest preview. If so, all of their Wine implementation probably falls under the X11 license and not required to have the Wine source code available. However, the fact that other parts of the system appear to be based on Debian requires some source code to be available.

5. CreateProcess Test

31 Mar 2002 - 1 Apr 2002 (5 posts) Archive Link: "create process test (for review)"

Topics: Testing

People: Alexandre Julliard, , Eric Pouech

Eric Pouech posted test for CreateProcess and asked for comments. He noted the following tests: One of the challenges with testing CreateProcess is ensuring that the child process was created correctly by the parent. Eric chose to have the child process write out it's information to a file that gets checked later for the proper results. One advantage to this is not relying on other Wine API's for storing the information, it's all written out using standard libc functions. Alexandre didn't like this though:

I don't see any problem in using other APIs, that's just another way to get them some more testing. And it is very important that the tests behave exactly the same under Windows and Wine so that any difference can be found. If we start having different code paths on different platforms we can never be sure that we are actually testing the same thing.

6. C Profiler

1 Apr 2002 (2 posts) Archive Link: "Where is "cprof""

Topics: Debugging

People: Luca Fini, , Jeff Tranter

Luca Fini inquired about a profiler:

I've seen that the Wine development team has also developed a profiler for multi-threaded programs.

I'd be very interested in using it to profile an application which I'm developing (with no connection with wine itlself).

Unfortunately the site which is suppose to be the cprof home is at Corel, which I understand is no longer in business.

Jeff Tranter replied that he'd send a copy of the source code he backed up before Corel's site was shut down.

7. Reorganizing CVS

12 Apr 2002 - 13 Apr 2002 (2 posts) Archive Link: "Directory reorganization"

Topics: Project Management

People: Joshua Thielen, Alexandre Julliard, , Josh Thielen

Josh Thielen wrote:

I have an idea for reorganizing some of the directories in wine. I hope I'm not stating an obvious idea here, but I would like to group everything into the following first level directories:

Alexandre replied,
That's more or less the plan yes. We are slowly getting there. I have not moved everything yet because it's not yet clear where everything will go (most notably for the ntdll/kernel proper separation) and I don't want to move things twice given CVS weaknesses in that area.

8. Testing Unicode Functions Too

5 Apr 2002 - 14 Apr 2002 (8 posts) Archive Link: "Regression tests, UNICODE vs ASCII"

Topics: Testing

People: Geoffrey Hausheer, Francois Gouget, Lina Kimmel, , Shachar Shemesh, Mark, Andriy Palamarchuk

Geoffrey Hausheer wondered how to go about testing functions that also come in Unicode flavor,
So I've finally started writing tests for functions that have both Unicode and Ascii equivalents, and I'm wondering how to write the tests. I re-read the thread about this that occurred back in January, and there didn't seem to be a clear decision.

Geoff figured he could either ignore the functions or simply do the same test as the ASCII functions. Learning enough about Unicode to write proper tests didn't seem appealing. However, Andriy Palamarchuk suggested creating the Unicode tests just like the ASCII versions but using symbols that have no ASCII equivalents. Shachar Shemesh suggested using some BiDi characters that specify right-to-left or left-to-right encoding. Francois Gouget asked,
I know that I would be hard-pressed to make up a Unicode string with anything significant. But if I had an example to base my code on, integrating it into my own tests should be trivial.

Lina Kemmel gave an example of a bunch of such characters:

const WCHAR zeroWidthNonJoiner = 0x200C;
const WCHAR zeroWidthJoiner = 0x200D;
const WCHAR leftToRightMark = 0x200E;
const WCHAR rightToLeftMark = 0x200F;
const WCHAR leftToRightEmbedding = 0x202A;
const WCHAR rightToLeftEmbedding = 0x202B;
const WCHAR popDirectionalFormatting = 0x202C;
const WCHAR leftToRightOverride = 0x202D;
const WCHAR rightToLeftOverride = 0x202E;

const WCHAR test_string[] = {zeroWidthNonJoiner, zeroWidthJoiner, leftToRightMark, ... , rightToLeftOverride};

9. Header Files and Testing

6 Apr 2002 - 7 Apr 2002 (7 posts) Archive Link: "Running tests on windows"

Topics: Testing

People: Geoffrey Hausheer, Francois Gouget, , Geoff Hausheer, ReactOS, Steven Edwards

Geoff Hausheer wondered how to go about using the Wine regression tests in other environments (e.g. Windows):

Last week I submitted a perl script that makes a Makefile (and archive bundle) for building tests on Windows boxes under cygwin. Well, it works fine with mingw too (when using msys at least), but there is a snag.

In order to compile tests under Windows, I seem to need to include windows.h before any other .h files. I did this using the '-include' directive in gcc, but it requires knowledge of the absolute path to the windows.h file. This means I need to specify the path in the Makefile, which is completely non-portable (especialy with mingw which doesn't really have a default setup like cygwin does).
  1. So it seems I have three options. I can append '#include <windows.h>' to each .c file (either wrapped in #define, or through the perl script)
  2. I can include the entire wine /include directory in the archive, and use that 'windows.h' to build against.
  3. I can just force the user to edit the Makefile to point to the correct include directory.

Francois Gouget felt the headers of whatever environment the tests were being run in should be used. He thought the script could be extended to help out,
I think I will work on extending your script to also generate Makefiles for use with Visual C++. The way it will work with Visual C++ is that you are supposed to run a batch script provided by Visual C++ (vcvars32.bat). This script sets a number of environment variables which point to the location of the headers, etc. and which you can also use in your Makefiles.

Steven Edwards pointed out that the headers in mingw were terrible and that he uses wine's headers when compiling for ReactOS. Geoff decided to change the script to allow the user to choose whether native headers were used or wine's.

10. Implementing PeekNamedPipe

15 Apr 2002 - 16 Apr 2002 (6 posts) Archive Link: "fixme:win32:PeekNamedPipe"

Topics: IO

People: Michael Riedel, Mike McCormack, , Michael Cardenas

Michael Riedel wondered how to go about implementing a function he needs:

First of all I want to thank the community for the efforts spent in developing wine. It's simple a cool "tool" (sorry, it's more, I know).

Now my problem: I installed wine-20020411 without having a native windows installation. I installed successfully a simulator software which obviously uses a tcl/tk-GUI to invoke other program moduls (compiler, library manager, simulator core) re-directing their stdin/stdout to the console window via pipes. It does not work for me and I get the message (infinitivly repeated):

Michael Cardenas suggested searching on msdn.microsoft.com for PeekNamedPipe to find out what DLL it resides in. Michael R. looked and found it resided in kernel32.dll, which unfortunately meant it wasn't a simple matter of using a native DLL to work around it. He asked for hints on fleshing out the stubbed function. Mike McCormack replied,
Implementing PeekNamedPipe will probably be difficult to do properly. Named pipes work through unix domain sockets at the moment. The code is in dlls/ntdll/sync.c and server/named_pipe.c. (I was the one who wrote most of it.) Unfortunately I don't have time to work on this at the moment, but i can give you a few hints on how to procede. You might be able to use recvfrom with the MSG_PEEK flag to do it...

11. More Async IO Fixes

4 Apr 2002 - 7 Apr 2002 (5 posts) Archive Link: "[PATCH] async IO API, reworked"

Topics: IO

People: Martin Wilck, Alexandre Julliard, , Paul Rupe

Martin Wilck submitted a bunch of patches to improve asynchronous IO. Martin wanted to change the API to allow for better DLL separation. He also noted the following changes:

PATCH: async-struct.diff

Purpose: Modified API for asynchronous IO requests.

Alexandre applied the patch, but wasn't totally happy:
One thing is that it introduces a header that doesn't exist under Windows. That can be acceptable, we have a few internal headers already; but it must be avoided as much as possible. The bigger problem is that you not only share static functions, but also data structures; and this is a big problem when trying to remain compatible between different versions of the various dlls.

Ultimately we may need to formalize this as part of the wine server interface, and we may not be able to avoid data structures completely. I do think that it should be possible to make the dlls more independent by doing more work in the server; but we should probably finish the implementation first and then we can start cleaning things up.

Martin began feeding more patches in and prefaced them with a request for people to do testing. He added:

As I indicated in my last posting, there is a lot of work outstanding to make all of the winsock2 code consistent with this async IO implementation. I see strange things in socket.c anyway, e.g. the select() call that simply disregards all the wait mechanisms that are provided in other places in wine.

If any of the original authors of this code read this message, I'd be really happy to get in contact with you!!

Paul Rupe suggested using "Hamster" to do testing, A good one to look at is Hamster, a local newsserver at < http://home.arcor.de/tgl70/misc/hamster_en.htm >. The nice thing about it is the source code (in Delphi) is available as well. It uses overlapped I/O on sockets, is multithreaded (a good thing to test), and has detailed logging you can turn on. I've used it to debug socket-related problems in the past and even worked on the overlapped I/O problem myself briefly.

 

 

 

 

 

 

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.