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

• Beginnings of an SMB client implementation.
• New naming scheme and location for builtin dlls.
• aRts sound driver.
• A bunch of unit tests.
• Much more complete setupapi implementation.
• Some dll separation progress.
• The usual common controls rewrites.
• Much improved Microsoft Office support.
• Lots of bug fixes.

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.

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.

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:

• Initial support for 3D sound, used in games such as Max Payne
• Better support for copy protected CDs on systems using SuperMount, such as Mandrake Linux 8.2
• Full screen mode capabilities on NVidia cards using the latest drivers
• Improved full-screen video mode support eliminating off-centre issues or desktop problems in some games
• Improved support for ALSA and OSS sound drivers, although a separate ALSA driver is still under development
• Improved support for many game installers
• Some improvements in keyboard handling
• Mouse wheel support

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.

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.

Eric Pouech posted test for CreateProcess and asked for comments. He noted the following tests:

• lookup: check the way program to be executed is searched
• environment: check environment string passing
• handles: check the handle inheritance stuff (+sec options)
• console: check if console creation parameters work

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.

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:

dlls
documentation
include
programs
server
tools

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.

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};

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.

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):

fixme:win32:PeekNamedPipe (00000080, (nil), 00000000, (nil), 0x406a2194, (nil)): stub

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

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.

• separate cleanly between async scheduling and file IO related issues,
• make the API compatible with other types of async requests (e.g. for sockets),
• remove exports of async IO related functions for DLL separation.

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.