At This Rate, Don't Be Surprised If You See Steam Soon

[GNU/Blind]

Especially it doesn't lock your games into DRM-caged disk files which I appreciate a lot.

Not sure what you mean here, I have Rainbow Six Vegas 2 purchased through Steam, it is by no means caged. The exe is tied into steam but it can be replaced with the official exe from the latest patch and will run with out steam. Same goes for every other third party game on steam, hell Valve is very proud of there anti piracy/cheating measures, and they should be, its not invasive and they allow for offline mode. they even place warnings about other manufacturers DRM.

Online Requirement

A PERMANENT HIGH SPEED INTERNET CONNECTION AND CREATION OF A UBISOFT ACCOUNT ARE REQUIRED TO PLAY THIS VIDEO GAME AT ALL TIMES AND TO UNLOCK EXCLUSIVE CONTENT. SUCH CONTENT MAY ONLY BE UNLOCKED ONE SINGLE TIME WITH A UNIQUE KEY. YOU MUST BE AT LEAST 13 TO CREATE A UBISOFT ACCOUNT WITHOUT PARENTAL CONSENT. UBISOFT MAY CANCEL ACCESS TO ONLINE FEATURES UPON A 30-DAY PRIOR NOTICE PUBLISHED AT http://www.splintercell.com/conviction/

Valves okay in my book.

[Dragonlord]

Not sure what you mean here, I have Rainbow Six Vegas 2 purchased through Steam, it is by no means caged. The exe is tied into steam but it can be replaced with the official exe from the latest patch and will run with out steam. Same goes for every other third party game on steam, hell Valve is very proud of there anti piracy/cheating measures, and they should be, its not invasive and they allow for offline mode. they even place warnings about other manufacturers DRM.

Nope, that's not the case. I know more than enough examples where the game ends up in a caged file, where the binary of non-steam patches are utterly incompatible with the steam-version and where games even fail to install through steam at all (sucks if you pay for a game and you can't install it since steam says it installed it but did nothing). Besides VAC does not work one inch. I see more cheaters on VAC servers than any other since it's so fun to mock with a non-working anti-cheat system.

EDIT: By the way, the last paragraph of yours is a total contradiction. If you consider them "being ok in your book" for that crap then you are brain-sick, sorry.

[Compholio]

Actualy the difference isn't so big. A hardware emulator such as a NES or SNES or whatever emulator doesn't emulate the harware at all. That would be very difficult to do (impossible?). It only returns to the software the results (don't know how to call it) that the software would get if it was running on the real hardware. This isn't so different from what wine does, as it also returns what the software was expecting to get if it was running on windows. I could be completely wrong here, because I don't know that much about emulators though.

I hope you're joking, hardware emulators do emulate the hardware of a system - that's part of why they run incredibly slow unless you have a pretty nice box. Wine is more of a translator than an emulator, it has no code for a processor, an MMU, or any hardware devices like an emulator does. Both building an emulator and building something like Wine are incredibly difficult, but that's probably why a lot of people do it.

[Dragonlord]

Does the registry exists natively under Linux? No? So WINE is an emulator.
Does DirectX work natively under Linux? No? So WINE is an emulator.
There are a bunch of other system parts that have to be emulated as otherwise windows apps do not run. The only difference to a console emulator is that wine (the emulator) does not have to emulate the command set as it matches the PC it runs on. Spares them from doing dyna-rec and other nasty stuff but in the end it's still emulating a system so you can run stuff like it runs on said system.

[Compholio]

Does the registry exists natively under Linux? No? So WINE is an emulator.
Does DirectX work natively under Linux? No? So WINE is an emulator.
There are a bunch of other system parts that have to be emulated as otherwise windows apps do not run. The only difference to a console emulator is that wine (the emulator) does not have to emulate the command set as it matches the PC it runs on. Spares them from doing dyna-rec and other nasty stuff but in the end it's still emulating a system so you can run stuff like it runs on said system.

Sure, using the colloquial definition of emulation - from a technical standpoint these are very different things. For example, DirectX is a "standard" rather than a piece of hardware, so Wine can translate the instructions for the DirectX standard to the OpenGL standard. Wine doesn't actually implement DirectX in software (though, if you follow such things, there is some discussion about optionally doing this for a few select API calls).

You can't just use the colloquial term to define something, if that's how you see it then that's fine but there is different established technical terminology. The technical community considers Wine to be considered a "compatibility/translation layer," which they do not consider to be the same as an emulator.

[GNU/Blind]

Nope, that's not the case. I know more than enough examples where the game ends up in a caged file, where the binary of non-steam patches are utterly incompatible with the steam-version

Please provide examples, I have many games on steam and from what I can tell in the Steam/steamapps/common folder the games are completely the same as if they were installed from disk.

[GNU/Blind]

Myth 1: "Wine is slow because it is an emulator"

Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).

Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

Also, and that's what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it's just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.

But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).

[Dragonlord]

Don't have the names in my head anymore as I send those buggers flying out of the window when they didn't work. Also some cases happened with others with games I don't own myself. But as far as I recall it includes AAA titles. Since some time I do not buy anything through steam anymore and it kept me rather sane. At last if it runs or not is then only the problem of the game developer no more a two-fold problem of steam messing up too.

[GNU/Blind]

Don't have the names in my head anymore as I send those buggers flying out of the window when they didn't work. Also some cases happened with others with games I don't own myself. But as far as I recall it includes AAA titles. Since some time I do not buy anything through steam anymore and it kept me rather sane. At last if it runs or not is then only the problem of the game developer no more a two-fold problem of steam messing up too.

Thats what I thought, you empty handed with nothing to back up your claims. Please refrain from talking about things you have no clue about or have very little experience with. If you come up with anything to substantiate your theories please educate me.

[Dragonlord]

Thats what I thought, you empty handed with nothing to back up your claims. Please refrain from talking about things you have no clue about or have very little experience with. If you come up with anything to substantiate your theories please educate me.

Yeah, the old fan-boy rant. I'm not empty-hand you idiot. But do you really expect me to keep a "non-functional" game around on my machine for eons to come? Important is that it happened and more than once. It happened also more than once to people I know which got pissed at these problems. So I'm not the only one. This alone is enough for me to state that there is a problem (if it happens to more than one person). And I don't go call blame on games if I'm not 100% about the name. I'm coming across a lot of games for various reasons and I tend to keep remembering the names of the really good ones. But I guess in your case name is program you are "GNU restricted-to Blind"