Wine Traffic #195 For 8 Nov 2003

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

You can view the page here:

www.winehq.org/wineconf/

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.

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

• Discuss the future of Wine
• Work on nasty glibc bugs
• Attack installers in an install-o-thon
• Relax in the beautiful winter weather of Minnesota, enjoying the St. Paul Winter Carnival (complete with Ice Palace!).
• Marvel at how the weather promotes an amazing amount of hacking time.
• Hoist a real glass of Wine with your compadres at the Mall of America.

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

Date

Saturday, January 31st and Sunday, February 1st, 2004.

Location

At the conference facility at CodeWeavers headquarters;
Court International Building
2550 University Avenue West
St. Paul, MN 55114
651-523-9300

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

• Install: Yes.
• Gameplay:
  • Video: Correct (maybe some missing effects)
  • Sound: Yes.
  • Mouse: Ok.

snapshots:

• http://62.93.166.115/tpm-1.jpg
• http://62.93.166.115/tpm-2.jpg (Probably some effect is missing here)
• http://62.93.166.115/tpm-3.jpg

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:

http://www.winehq.org/hypermail/wine-patches/2003/11/0000.html
http://62.93.166.115/d3d8_private.diff

• Install: Yes (using native dlls for InstallShield 7)
• Gameplay:
  • Video: Correct (graphics glitches, missing effects and a bit slow) (You need disable in video settings the 5th option, or you will see the gfx 4 times together)
  • Sound: Yes.
  • Mouse: Ok during gameplay (probably not in the menu zone)

Snapshots:

• http://62.93.166.115/gta3-0.jpg
• http://62.93.166.115/gta3-1.jpg (where is the rain?)
• http://62.93.166.115/gta3-2.jpg (with the 5th option enabled)

Commandos 3: Destination Berlin Demo

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

http://www.winehq.org/hypermail/wine-patches/2003/11/0000.html
http://62.93.166.115/d3d8_private.diff

• Install: Yes (using native dlls for InstallShield 7)
• Gameplay:
  • Video: Correct (some graphics glitches in text windows). There is 2 stages for select in the demo, only the first one shows graphics, in the second you can heard the sound, but the screens remains to black.
  • Sound: Yes.
  • Mouse: Ok.

Snapshots:

• http://62.93.166.115/commandos3.jpg

Haegemonian Demo (no playable demo).

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

http://62.93.166.115/device.diff -- (IDirect3DDevice8Impl_CopyRects)

• Install: Yes.
• Gameplay:
  • Video: Correct (missing some screens, but the 3D engine works very nice).
  • Sound: Yes.
  • Mouse: No mouse needed.

Snapshots:

• http://62.93.166.115/haegemoniam-1.jpg
• http://62.93.166.115/haegemoniam-2.jpg

Anno 1602.

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

http://www.winehq.org/hypermail/wine-patches/2003/10/0274.html

• Install: Yes.
• Gameplay:
  • Video: Correct.
  • Sound: Yes.
  • Mouse: Ok.

Snapshots:

• http://62.93.166.115/a1602-1.jpg
• http://62.93.166.115/a1602-2.jpg

Praetoriam Demo.

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

• Install: Yes (using native dlls for InstallShield 7)
• Gameplay:
  • Video: Missing some tittle screens, and problems with textures during gameplay. fixme:ddraw:Main_IDirect3DDeviceImpl_7_Load
  • Sound: Yes, but some effects with noise.
  • Mouse: No works correctly, moves only in range 1024x740, but it should be possible in range 1024x768.

Snapshots:

• http://62.93.166.115/praetorians.jpg

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.

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

• 2 was committed to wine CVS.
• The problems behind 1 and 3 were fixed in the meanwhile.
• I have read a discussion about 4 on wine-devel. If I remember correctly it was aggreed that it should be added to wine sooner or later. But I dont see it yet in the CVS.
• 5 is the only part which is related to safedisc. The SECDRV device handler is implemented in the secdrv.sys file which comes with the copy protected CD. The problem is that wine can't load .sys files. Laurent solved the issue by reimplementing the secdrv.sys in wine, but this brings fort the legal issues.

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.

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.

http://www.jankratochvil.net/project/captive/

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.

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.

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.

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.

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)