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

Wine Traffic #195 For 8 Nov 2003

By Brian Vincent

Table Of Contents


This is the 195th issue of the Wine Weekly News publication. Its main goal is to bemoan the breakup of O-Town. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at

Mailing List Stats For This Week

We looked at 185 posts in 670K.

There were 65 different contributors. 28 posted more than once. 31 posted last week too.

The top posters of the week were:

1. News: Wine for Crystallography

1 Nov 2003 - 8 Nov 2003 (1 post) Archive Link: "News"

Topics: News

People: News

This week's issue is once again a little late. Things have been quite busy in real life. Conversely, things have been a little slower than normal in the Wine world. The mailing lists and CVS have seen less activity than they have in the previous few months.

Part of that means it's a little harder to find news stories.. but of course that's why Google exists. I found a page describing how to use Wine to run some specialized scientific (crystallography) software. It appears these instructions have been around for a while, but the screenshots are still nice..

2. WineConf 2004

4 Nov 2003 (1 post) Archive Link: "Announcing Wineconf 2004"

Topics: WineConf 2004

People: Jeremy WhiteCodeweaversCodeWeavers

Over the past month there's been more discussion of a Wine developer's conference. A vote was called for and the results are in. WineConf 2004 will be held the weekend of January 31/February 1st 2004 in St. Paul, Minnesota. Jeremy White announced it:

Okay, I've finally put together a web page and mailing list to centralize our information about Wineconf.

You can view the page here:

It's just a start; there are lots of details to fill in, but now everyone has a place to look.

I'd appreciate it if interested parties could both let me know that they'd be there via the registration form and join the mailing list so that we can discuss the agenda.

Once we've defined a bit more of an agenda, I'd like to go ahead and announce the conference as a whole to wine-announce.

The web page above includes more detail:

Everyone is welcome at the second semi regular conference of Wine enthusiasts. Come and gather with fellow Wine hackers to:

The conference is in the early stages of planning, so full details are not yet available. However, here are the details that are firm:



February 1st will also be the Superbowl.

3. DirectX Games Tested

1 Nov 2003 - 2 Nov 2003 (8 posts) Archive Link: "Is it time for playing games on WINE?"

Topics: IO

People: Carlos LozanoRaphael Junqueira

Carlos Lozano posted some success stories for games running under a standard Wine installation:

Is it time for playing games on WINE? Here goes some sucessfull stories :) If you need more screenshots, logs or another info about this games, leave me know.

Date of the test: 20031101

Star Wars: The Phantom Menace.

CDROM: Original disc, not necessary any trick. Additional wine patches: No


Grand Theft Auto III

CDROM: You need set the windows version to nt40, and use a modified EXE due to safedisc 2 protection.
Additional wine patches:


Commandos 3: Destination Berlin Demo

CDROM: Using the original disc, not necessary any trick.
Additional wine patches:


Haegemonian Demo (no playable demo).

CDROM: Using the original disc, not necessary any trick.
Additional wine patches:


Anno 1602.

Notes: Using the original disc, not necessary any trick.
Additional wine patches:


Praetoriam Demo.

Notes: Using the original disc, not necessary any trick.
Additional wine patches: No


This prompted more discussion about Wine's support for games. At one point Raphael Junqueria remarked, " And i have already a simple but working d3d9 prototype (who use a new d3dcore lib)" Later in the week some of that new d3dcore arrive on wine=patches.

4. Copy Protection Sucks

4 Nov 2003 - 8 Nov 2003 (34 posts) Archive Link: "copy protection - was: Re: Is it time for playing games on WINE?"

People: Jason EdmeadesZsolt RizsanyiRoderick ColenbranderSteven EdwardsAlexandre JulliardGeoff ThorpeShachar ShemeshTransgamingMicrosoftReactOSLaurent Pinchart

I remember back in the 80's the gaming industry discovered people could copy floppy disks. A few friends I used to spend countless hours figuring out how to get around the latest copy protection schemes. Ultimately we always discovered a solution - finding a cracked game hacked by some underground group or a way to use one of the popular game copying programs. Fast forward 15 years.. nothing has changed. Game manufacturers still use copy protection and it's still as useless as always. I doubt any 14 year old has a problem downloading the latest Grand Theft Auto cracked executable and burning it to a disk. In the ensuing discussion about gaming this week, Jason Edmeades made this remark:

One other thought. At some point in time we will have to address copy protection. I dont want to get into legal discussions and I dont intend looking into it (yet), BUT would I be correct in saying that if someone worked out the first point at which copy protection fails, and codes a basic application which emulates this behaviour. Since this simple app works on windows, then someone else could then work on getting the basic program working under wine without being contaminated by knowledge of the internals of the copy protection itself? If this is the case, it would be a useful thing to put on the projects page. If the legality of this is dodgy, forget it - there are always hacks around, its just frustrating.

Zsolt Rizsanyi summed up the state of Wine being able to support Safedisk copy protection:

The problem is that copy protection is usually implemented in drivers (*.sys files), which cannot be loaded by wine.

If I remember correctly then Laurent Pincharts safedisk patch consisted of the next logical parts:

  1. fix a process startup race - if the child process was created suspended, then some wineserver messages got overwritten by new messages.
  2. add code to handle scsi cdrom ioctls (used by the copy protection to read some raw data from the cd).
  3. return EXCEPTION_PRIV_INSTRUCTION instead of EXCEPTION_ACCESS_VIOLATION when a some exception was raised by the user
  4. support shared memory beetween kernel space and user space (see SharedUserData in ntddk.h)
  5. implement SECDRV device handler

For all this to work it is necessary to set winver to nt40 (or some other from the nt line).

The current status is (AFAIK):

Some of the discussion delved into what it would take for Wine to include a builtin version of the Safedisk secdrv.sys driver. Roderick Colenbrander pointed out some of the pitfalls:

It might be possible to reverse engineer the current safedisc 1 and 2 protections and include the code in wine. The problem is that the new version (a snapshot of it was used at the time in flashpoint) is less nice. Nowadays when you for example use a crack the game works or doesn't work. The new safedisc is really nasty. When you apply a crack (or perhaps our upcoming safedisc driver) the game starts up no matter if the crack is really correct or not. During the game you will know if the crack was correct or not. When you play using an incorrect crack the game will slowly become unplayable. For example the keys to finish the level will disappear or you can't aim anymore..

Perhaps the "solution" is to write a wrapper to load secdrv.sys and friends. Perhaps in a way like that ntfs emulation project works (it uses a reactos kernel) or perhaps using an emulator like qemu.

Steven Edwards agreed it might be possible to load the native version,

Yes it should be possibe to adapt the work of Jan Kratochvil's Captive NTFS project to let you load the safedisk driver under Linux rather than the Windows NTFS driver. I have not tested loading the safedisk driver under ReactOS but I dont see why it wouldn't work.

Tom Wickline asked if Laurent Pinchart's work would ever make it into Wine. Alexandre had a firm "no" response:

None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.

Geoff Thorpe brought up some of the problems with ever including code like that in Wine:

As we've seen with encryption regulations in the past, the issue of control-circumvention law dissolves in the face of open-source software. Moreover, in the face of (L)GPL open-source software, it dissolves by *design* - you can not withhold source-code if you want to release binaries. IIRC, this was one of the major stumbling blocks for Transgaming and the Wine/LGPL debate - they have copyprotection support that they legally can not dream of releasing source for. Some argue that binaries are a form of source code anyway, and that you can "read" them in the sense that you can interpret and modify their operation. However, the lawyers seem reasonably comfortable with that argument - they call it reverse engineering and it's "bad"(tm). It is my personal opinion that this legal anomaly with copyleft is no accident - Microsoft (and the RIAA) lobby harder than most, and laws that are impossible to abide by in open source are "good" laws for lawyers and their preferred clients, and "bad" for disreputable communists (as we most surely must be if we don't feel like trading binaries commercially). But I digress.

What you've said about putting safedisk support into Wine is analogous to saying (a few years ago) that you could add an open-source encrypted filesystem to the O/S by only allowing the use of 40-bit cipher keys to satisfy export regulations. The fact that any dolt with gcc and a text-editor can type "s/40/128/g" makes that an insufficient defense, unfortunately. Somewhere in the callstack between the application and the kernel's CD driver needs to be something that is closed-source and not subject to trivial circumvention. I can't see how this can be done without requiring a DMCA violation in Wine, the O/S kernel, or requiring the copying of a closed-source driver that *itself* is irreplacable (choosing to load it from Wine and say "don't edit this Wine code to circumvent the commercial driver" in a C comment won't jive). Perhaps I've misunderstood something about the copy-protection model here, but the law itself seems to preclude a general open source solution, no matter how you slice it.

Shachar Shemesh didn't understand where the problem actually was, " I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens." Alexandre explained:

The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written.

So the question is whether the code in question is "circumventing" the protection or not. I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original. OTOH you can make a pretty good case that a generic "Windows driver loader" is not circumventing anything, it's just doing what any Windows replacement is supposed to do.

He went on to give a little more detail on why a Wine-specific driver would be a legal minefield:

By providing a replacement driver, you are circumventing a technical measure controlling access to the work. The fact is that without the driver you don't get access, and with the dummy Wine driver you do; since the dummy Wine driver is not an "authorized" way to get access it's circumvention. It doesn't matter at all whether it lets you use copied CDs or not.

Besides, I 1don't see how you could possibly prove that our implementation does exactly the same thing as the original one. Maybe the original doesn't only prevent copied CDs, maybe it also checks the phase of the moon or whatever, you have no way to make sure the protection is implemented correctly.

The thread pretty much ended after that. Several developers voiced their hatred of the DMCA.

5. IPX Improvements

8 Nov 2003 (1 post) Archive Link: "Resend: Winsock ipx improvements"

Topics: IO

People: Roderick ColenbranderMike McCormack

Roderick Colenbrander sent some patches to improve IPX networking and noted:

Here are some patches which improve winsock's ipx support. Using these patches games C&C Tiberian Sun, Red Alert (v3.x) and Red Alert II work over a lan.

First patches 1 and 3 add a new ipx related header. Patch 1 is the new header I made and patch 3 contains some extra structs submitted by vincent beron.

Patch 2 adds various missing pieces to the winsock code. For one of the new pieces of code a new wineserver call was required. In short the problem is that the way in which you can set the ipx packet type is different. On linux you can change the ipx packet type by setting an attribute of the linux ipx sockaddr structure. On windows it is changed using (WS_)setsockopt. The attribute that exists in the linux sockaddr structure doesn't exist on windows.

In our winsock dll all winsock structures are in the end converted to their linux equivalent. When we receive a request to change the ipx packet type we only have access to the winsock structure and because of this we can't change the packet type. (since it misses the attribute) To be able to get and set the packet type it needs to be stored in the wineserver. (Mike McCormack advised me this)







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.