It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
ssokolow: Wine already can't run 64-bit Windows apps on OSX because they use processor registers in incompatible ways.
If it's not corrected on Wine side it will be a problem for plenty of games in the future. you cannot realistically expect all games to have an engine recreation/released source code; it would be great but it's king of unrealistic.

avatar
ssokolow: His point is that innoextract, innounp, and unrar are open-source and, thus, are more future-proof than the installer's code and at least as future proof as things like DOSBox and ScummVM. (Possibly more so, given that games are more complex and easier to botch than extractors.)
He was implying that it was GoG responsibility to ensure that it's games/installer were future proof and that them not going it was some sort of "DRM". At least that's how I read it.
avatar
ssokolow: Wine already can't run 64-bit Windows apps on OSX because they use processor registers in incompatible ways.
avatar
Gersen: If it's not corrected on Wine side it will be a problem for plenty of games in the future. you cannot realistically expect all games to have an engine recreation/released source code; it would be great but it's king of unrealistic.
However it's fixed, it's going to be difficult. x86 machine code is x86 machine code. Wine just reinvents the loader and the libraries the code expects to call. (On-disk binary formats are sort of like Ogg, Matroska, and so on. They provide a defined structure for the binary code and a whole bunch of metadata. Windows uses PE, OSX uses Mach-O, and everything else modern has agreed that ELF is superior in every way except for supporting embedded icons or "Universal Binaries"... both of which were prototyped for it but rejected.)

Rewriting how a compiled program uses processor registers is non-trivial and, so far, most of the talk I've heard of getting Win64 to work on OSX has centered around emulating it via qemu-user. (Which is full/slow emulation. It's also how you run Win32 Wine on ARM processors.)

avatar
ssokolow: His point is that innoextract, innounp, and unrar are open-source and, thus, are more future-proof than the installer's code and at least as future proof as things like DOSBox and ScummVM. (Possibly more so, given that games are more complex and easier to botch than extractors.)
avatar
Gersen: He was implying that it was GoG responsibility to ensure that it's games/installer were future proof and that them not going it was some sort of "DRM". At least that's how I read it.
My interpretation was that he wants GOG to limit the roadblocks they put up to ones that are roadblocks as an inherent side-effect of "computer science is complicated" rather than "explicitly tries to limit what you can do".

(Sort of like the difference between speaking a foreign language and speaking in code.)
avatar
Maighstir: browser and downloader: only the latter of those can do checksums
avatar
xyem: If GOG provided the checksums in the download area (like Daily/Indie Royale do), some browser tools let you give them a hash digest when you start the file download, allowing them to check it was downloaded correctly. e.g. DownThemAll.
Yeah, wrongly worded of me. The (common) browsers don't do checksumming without such addons though, and even considering them, GOG cannot offer official support for them.

If a support issue comes down to making sure that a file is downloaded without missing/changed bits, the only tools they can - and should - recommend are ones they have tested extensively themselves - taking that into account, I'm fairly certain that the official downloader is the only one with built-in checksum checking.
avatar
Magmarock: Secondly there is no such thing as future proof, EVER!!
Hence why I said "in so much as anyone can guarantee anything".
If the computers are so different that they cannot read the file then that is on me to try and work with it, it is not something that GoG did.
It doesn't matter what type of computers we have in the future, I guarantee (again, in as far as anyone can guarantee anything) that it will be possible to physically copy files from old systems to whatever we have at the time.

avatar
Magmarock: When GOG do something I don't like I'm very quick to speak it but when they are criticize for something like this I'm just as quick to deafened them because this is really silly when you think about it. They are just quality assuring their software.
Oh absolutely, but if you'd read my first paragraph, and really the last 20-odd pages of discussion, you'd see that "this" isn't quality assuring their software, it was poorly implemented and didn't accomplish what they claimed they were trying to do. Don't defend that.


avatar
Gersen: You are savvy enough to be able to use DosBox but not savv enough to use Wine to run the installers ? Or not savvy enough to, as soon as GoG gone under extract your installer and save the data files in the format of your choice. Seriously, if you want to be able to use your games in X years you will have to actually work for it; don't expect somebody to hold your hands.
Future. In the future. Distant future. Not now. Years from today, as in not the present. In a time when computers are completely different and those installers have no chance of running on the hardware, after a time when they may have done something that makes it impossible to run those installers at all.

avatar
Gersen: They cannot and never will be able to guarantee you that the games will still be able in the future, they guarantee you that the games are DRM-free and run "now", nothing more nothing else, for the rest you are on your own.
In so far as anyone can guarantee anything, yes they can. They can promise to only use package technologies with known formats that can be extracted by third party tools. Beyond that it's up to the user to figure out what to do with it. Maybe not easily, if we have to jump through hoops to do it then so be it, but the possibility is still there. If they implement something in the future that is somehow encrypted that it cannot be extracted without their installer AND they've done something "clever" with the installer such that it just doesn't run in Wine, or Windows 19, or even Windows XP in an emulatore, whatever we've got at the time, that's the problem. Promise me that, that they won't intentionally do something that makes it impossible to get the data files. Basically the only thing I can think of is if they put in literal DRM, something like a "phone home" installer, or time synced, but I'm not very imaginative, I cannot see the future, and it is entirely possible that they may, over the next few years, create an installer which will eventually be impossible to read. I want a promise that they won't do that.
No hand holding required, just a promise that they won't make it impossible to get the data. That doesn't seem like very much to ask.
avatar
Gersen: He was implying that it was GoG responsibility to ensure that it's games/installer were future proof and that them not going it was some sort of "DRM". At least that's how I read it.
avatar
ssokolow: My interpretation was that he wants GOG to limit the roadblocks they put up to ones that are roadblocks as an inherent side-effect of "computer science is complicated" rather than "explicitly tries to limit what you can do".

(Sort of like the difference between speaking a foreign language and speaking in code.)
Yes, that's what I was getting at. They should "future proof" their installers by not making limiting decisions, not by literally thinking about what is currently happening. They don't need to guarantee that it'll work with current tools, it's enough to guarantee that the format of their installers, whatever it may be, is known enough that someone else can write a tool for the job. As long as they don't intentionally try to limit things everything will work out just fine.
Post edited January 08, 2015 by WizardStan
Is there a full list of games affected by this? Are they already unpassworded?
Post edited January 08, 2015 by jcoa
avatar
WizardStan: Promise me that, that they won't intentionally do something that makes it impossible to get the data files.
The whole point of the installer is it to give the user the data files. They can't make that impossible, can they? :)
The only thing that may happen is that our tools don't work any longer and we have to develop new ones. But if those data is in the installer, it can also be extracted. The only question is how much effort it requires.
And in that matter I am content with the promise of GOG that they won't hinder our efforts on purpose.
avatar
immi101: They can't make that impossible, can they? :)
Maybe they can. Maybe they can't now but find something in the future. Who knows? The future has many possibilities. Maybe, over time, little bits and pieces of DRM slowly slip in, mostly benign on their own, until one day, years from now, a complete infrastructure that depends on always on connectivity exists, and that could have all started with the (easily breakable) password protected RAR files.
The only people who can say this won't happen are the good folks of GoG.
Note very carefully what I'm saying and asking for. I did not complain about the password protected RAR files simply because it made extraction more difficult (although that is a concern, it's not something I would complain about), I complained about them because they didn't do the things we were told they were supposed to do: they created a feature that did nothing but hinder "legitimate" (rightful owners even if they aren't using it in a prescribed manner) users.


avatar
immi101: And in that matter I am content with the promise of GOG that they won't hinder our efforts on purpose
Yes, that is almost word for word what I said. If non-compatibility is a result of a perfectly valid feature, that's unfortunate but they don't claim to support third party stuff. An interesting side effect of "not hindering on purpose" and "no DRM" (as is classically defined) is that future compatibility will basically be assured. But if they can't even promise these two things then there's not enough trust in the system, especially when they explicitly reject such third party extraction in their EULA.
avatar
Magmarock: Why the hell would you not want to use the GOG installer. It's the best thing ever. Leaving little impact on the registry and somehow knowing what the game save files are. Not sure if this happens on the Linux version but still. I really like the GOG installer. I with more companies used it.
avatar
ssokolow: Typically, because we want something that's, by the installer's limited definition, broken, because it's just the game resources and not the engine.

For example:
1. Using the Duke Nukem 3D data files on Windows but with the massively enhanced EDuke32 engine rather than the original one.
2. Playing ScummVM-compatible games on Android
3. Unpacking a DOSBox-wrapped game so it can be used with a native Linux or MacOS version of DOSBox without waiting for GOG to renegotiate the list of platforms they're allowed to release it for.

Under those circumstances, the installer's insistence on a working install is detrimental because we have to do the install, copy the files we actually want out, and then immediately uninstall.

Also, that assumes that the GOG installer will actually run. Microsoft has made noises about dropping 32-bit compatibility in Windows 9 but Wine on OSX can't run 64-bit Windows apps because Win64 and 64-bit OSX have different, incompatible rules for which processor registers are clobbered in a context switch.

(And, for many early 32-bit Windows apps, the only reason their original installers work on modern Windows is that Windows detects 16-bit InstallShield launcher stubs and transparently swaps in 32-bit replacements that they got a license to bundle with Windows.)
Minor correction, Wine can handle 64 bit, sort of, it's just a real PITA to set up and not something that's done by default. In general, you don't want to go there if you don't have to, but it is possible.

I've done it and it's a pain that involves a fair amount of work in most cases.

http://wiki.winehq.org/Wine64
avatar
hedwards: Minor correction, Wine can handle 64 bit, sort of, it's just a real PITA to set up and not something that's done by default. In general, you don't want to go there if you don't have to, but it is possible.

I've done it and it's a pain that involves a fair amount of work in most cases.

http://wiki.winehq.org/Wine64
That just talks about building 64-bit Wine for Linux and I never claimed that wasn't possible. (I've used 64-bit Wine through Gentoo ebuilds, Ubuntu PPAs, and PlayOnLinux)

Emphasis mine.
64-bit Wine runs only on 64 bit installations, and at present only on Linux.
-- Wine FAQ, Section 2.5, Retrieved 2015-01-08 14:48 UTC-5
I don’t know the exact details myself (Ken is the expert), but the answer is that it does not work, and probably never will. OSX has a ABI incompatibility with Win64 - OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way. A potential workaround may be to run Wine inside a CPU emulator like qemu, but that is anything but easy.
-- Stefan Dösinger, Thu Feb 20 07:28:07 CST 2014
Actually, Alexandre is the expert, but this is my understanding as well.

Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty.
-- Ken Thomases, Thu Feb 20 10:20:49 CST 2014
This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue. With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it. So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code. When Wine code calls out to Windows code, there's nothing we need to do. So, putting the attribute in the WINAPI declspec works.
-- Ken Thomases, Thu Feb 20 15:51:49 CST 2014
...and so on.
Post edited January 08, 2015 by ssokolow
avatar
ssokolow: I did send a PM to Gowor with a link to that post and, aside from the idea to include a "must run to open a ticket" dxdiag-like "verify that this was installed correctly" utility with each game, that's just summarizing the most refined versions of all the different ideas I proposed in this thread over the course of several pages.
I see. My bad. The lack of official attention is unfortunate.

But, interesting ideas keep rolling in.
avatar
GOG.com: As the topic of password protected archives *snip*
GOG.com Team
This particular issue didn't affect me personally, but I was aware of it and was mildly concerned.

For lack of a better venue, thanks to the GOG.com team for listening to your friends and responding in a rational and responsible manner. You will continue to enjoy my business and I will continue to recommend GOG.com to anyone who will listen.

Thank you. You are rare in this world. I appreciate that.
avatar
Magmarock: No I don't, you click the little picture and it works. You don't download and install another program to view and then extract with the chance of problems as a results of not making proper entries into the registry or the files being set up properly. You click the little picture and it works. If you change the directory the next game automatically follows. Best installer ever made You click the little picture and it works.
avatar
immi101: did you actually read the post you replied to?(The one talking about scummvm,eduke32,etc)

In case of those games we don't need registry entries, we don't even need the .exe of the game in some cases. All we need is the game resources.
yes I did read the post and as I said you can just install the games to an external hard drive and keep that as your game data archive
avatar
immi101: did you actually read the post you replied to?(The one talking about scummvm,eduke32,etc)

In case of those games we don't need registry entries, we don't even need the .exe of the game in some cases. All we need is the game resources.
avatar
Magmarock: yes I did read the post and as I said you can just install the games to an external hard drive and keep that as your game data archive
Except the whole point is not to install it but unpack with minimal effort. Using Wine for that and let a lone some Windows in VM is far from minimal effort. Anyway, GOG already said they aren't going to hinder that on purpose.
Post edited January 09, 2015 by shmerl
avatar
Magmarock: yes I did read the post and as I said you can just install the games to an external hard drive and keep that as your game data archive
avatar
shmerl: Except the whole point is not to install it but unpack with minimal effort. Using Wine for that and let a lone some Windows in VM is far from minimal effort. Anyway, GOG already said they aren't going to hinder that on purpose.
They also said we won't get regional pricing. :P
avatar
Magmarock: HASSLE FREE!!! USER FRIENDLY!!! What on earth are you talking about. Hassle free is a very strange and alien consent to some people. What I'm trying to say is no matter how simple and straight forward something is, there will always be people who will want to do things the hard way.
avatar
immi101: Please take a moment here and seriously think about this.
How do you think we are able to play all these decades old classic games. How to you think projects like ScummVM, dosbox and others were created? They were created by people who were not happy to be constrained by the environment the games were originally meant for. The wanted to explore new possibilities, wanted to tinker around, wanted to do things the hard way. And thanks to the countless hours spent by those people you can now easily and conveniently play those old games on todays computers. Without these people the catalogue here on GOG would be a lot smaller.
Think about this the next time you scoff at people who don't share your mindset of "click, play and be happy".
Yeah but those games DIDN'T WORK. GOG games work fine, if you're trying to make an emulator or a mod for something that doesn't work then more power to you. But trying to extract game data from a perfectly working installer using a algorithm to hack it's password is insane. Especially when he developers of said installer have gone out of their way to make it unnesosery hence the term "hassle free and user friendly." So there's no need do it.