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
Braggadar: I believe some measure of fairness should prevail.
If a GOG user purchases a game that indicates on the store page as being compatible with a certain OS, then it is reasonable to expect that future DL access to said game will remain so. Since GOG sells digital access to their games as a continuing concern rather than a once-off DL, the expectation that game access sold at one time as compatible for a particular OS should remain in the future, but no guarantees are made on future updates of course.
Cosmo's Cosmic Adventure may be compatible with a XT class CPU, DOS 3, and Windows 3.0, but nobody at GOG is going to haul out a test machine to make sure. Same thing with Windows XP. Even if it may work, they can't test it and be sure, so better to CYA by not labeling it as such then to have some future patch break it.
avatar
Darvond: so better to CYA by not labeling it as such then to have some future patch break it.
If GOG is not willing to make it reasonably clear that compatibility is not guaranteed as a readable disclaimer, then yes, it would be better not to list it as such. Selling a modified software product and basing advertised compatibility on an "Expected Compatibility" is dicey at best. I understand very well that Tested Compatibility is not the same as Expected Compatibility. The onus is on the company to expect that things will happen and cover themselves by informing the customer of potential problems at POS.

This problem is partially linked in a way to GOG's Account page only offering the "latest" version, rather than offering scaled patches / versions.
If GOG is unwilling/unable to thoroughly test for compatibility, then offering only the "latest" package for DL is likely going to cause upset when it finally breaks on a particular OS. This is often why some users here have commented they would like GOG to offer other versions, or a scale of update patches, allowing users to backtrack and identify themselves which version still worked. Eventually if compatibility is to be ended for an OS, GOG could then test that community identified version and leave it as the only offering for these outdated consumers, and move on to updating for newer OSes.

If you sell a product advertising it as being something it isn't, then it isn't too much to expect a user to demand a refund. Like it or love it, in today's world you must be CLEAR of what you are selling.
avatar
Braggadar: If GOG is not willing to make it reasonably clear that compatibility is not guaranteed as a readable disclaimer, then yes, it would be better not to list it as such. Selling a modified software product and basing advertised compatibility on an "Expected Compatibility" is dicey at best. I understand very well that Tested Compatibility is not the same as Expected Compatibility. The onus is on the company to expect that things will happen and cover themselves by informing the customer of potential problems at POS.
I do recall rather clearly that GOG gave advance notice that they were no longer supporting Windows XP, and nobody batted and eye when Windows Vista support was quietly pulled.

I expect the same, should they decide to retire Windows 7 or 8, or any of the lesser *Buntu versions.

(With MacOS, it is basically, "Upgrade or GTFO."
Post edited September 21, 2018 by Darvond
avatar
Darvond: I do recall rather clearly that GOG gave advance notice that they were no longer supporting Windows XP, and nobody batted and eye when Windows Vista support was quietly pulled.
The difference between no-longer offering support for an OS, or no-longer offering new updates for same, is different than only offering one version of a game and breaking a past advertised compatibility for a customer.

It is not too much to expect that once an OS is "retired" by GOG, the last (even "Expected") compatible version for that OS it offered for DL (where possible). If they are indeed doing this, kudos.
high rated
avatar
Olauron: ...Changing system requirements long time after the release may be done by developers (I've seen patches like that) but doubtfully by GOG. And on GOG patches are optional so existing customers may ignore such patches from developers.
Actually, this is *exactly* what has happened - the developer has not changed their system requirements but GOG has through the addition of its Galaxy.dll, which is non-optional (despite Galaxy itself being claimed to be optional).
avatar
Braggadar: If a GOG user purchases a game that indicates on the store page as being compatible with a certain OS, then it is reasonable to expect that future DL access to said game will remain so.
Indeed - otherwise people would be safer sticking with CD/DVD releases.
avatar
Braggadar: The moment the game gets updated beyond support for these previous advertised compatible OSes, the older (offline, non-Galaxy) installers should be made permanently available on the DL page, appropriately tagged for identification. Then they may continue to provide newer updates that keep the game compatible with newer OSes. This would be perfectly acceptable, as really old games (particularly SP) will rarely need updates for antiquated OSes.
I would agree with this in cases (which seem pretty rare) where the *developer* withdraws support for an OS.

In this case though, it is GOG that has thrown a spanner in the works and GOG that should offer a solution - whether that be a galaxy.dll-free version (which really should be the default for offline, non-Galaxy downloads) or a replacement dummy dll.
avatar
Darvond: ...but nobody at GOG is going to haul out a test machine to make sure. Same thing with Windows XP. Even if it may work, they can't test it and be sure, so better to CYA by not labeling it as such then to have some future patch break it.
No-one is asking GOG to guarantee compatibility with older games (though it shouldn't be *that* hard to provide an exact copy of the orginal files with no installer, no scripting, no addons which expert users could make use of). It is a simple case of GOG *not* adding anything that might break compatibility.

Unfortunately they seem so desperate to push Galaxy down everyone's throats (almost all support responses now seem to start "Have you downloaded the latest version from Galaxy?") that disenfrancising part of their customer base seems to be a non-issue.
avatar
Darvond: I do recall rather clearly that GOG gave advance notice that they were no longer supporting Windows XP, and nobody batted and eye when Windows Vista support was quietly pulled.
Not everyone lives on the forums here - had I know about the news item or thread, I would certainly have posted. However one point of "DRM-free" gaming is that you shouldn't have to continuously monitor a website or forum to guarantee your games continues to work.

As more games (and customers) are affected, I would expect complaints to continue. Another potential example looks to be ADOM (Ancient Domains Of Mystery) - GOG list their minimum requirement as Windows 7 while the Developer FAQ indicates WinXP compatibility (see "Q: Where does the Windows version store the saved games?"). Of course, the original, free version (ADOM Classic) runs on a wider range of OSes - including AmigaOS...

To put some figures on this, Statcounter reports a market share of 0.91% (36.39% x 2.51%) for WinXP in September 2018, compared to 0.78% for Linux (excluding Android). So WinXP is still being used more widely than the Penguin. :) And it exceeds Win8 (2.24% of Windows marketshare compared to 2.51% for WinXP).

NetMarketShare shows a bigger difference - 4.61% on WinXP, 1.45% on Linux, 1.13% on Win8 - this is just looking at desktop systems though.
avatar
HereForTheBeer: good Old games, the old name with emphasis on "Old". My vain attempt to tell gOg not to forget where the store came from and who helped get them here: those who showed up for the old games.
I'd agree (although belatedly late) with such a sentiment - though I can aso understand the business reason behind it.
Post edited October 06, 2018 by AstralWanderer
high rated
I'm also one of those "stoneage" users, and I've been using XP x64 since 2009 on my workstation. Mostly because I like the GUI / workflow on the OS. I also have a Windows 10 box for gaming and more Linux & FreeBSD UNIX machines for work, but I still like to play older games on my XP x64 box as well sometimes (It's a hexcore Xeon X5690 with 48GB RAM, a Titan Black, a big 1.6TB SSD and a big 55TB RAID-6 with GPT, which works for data volumes on XP x64 / NT 5.2). I still like it, despite knowing and working with a lot of modern OSes as well.

Anyway, if GOG isn't gonna do something about Galaxy.dll, then why don't we just fix it up ourselves, if we care enough? I used the stub DLL work by russian hacker Oleg Ovcharenko (who I'm in regular contact with, he has developed the open-source Stellaris WinXP fix (github.com/UncleVasya/EU4_WinXP_fix) and also Drako Pensulos' GOG Galaxy WinXP patch (drakopensulo.wordpress.com/2016/12/18/gog-galaxy-winxp-patch-v0-05/) to provide the necessary bcrypt.dll drop-in replacement for XP. For the offline installers of course.

I've worked for a while with Oleg's code, and managed to port his work (with his help) to 64-bit as well, so things like Factorio (which is 64-bit) can work on XP x64. It's a niche thing to do, but it's fun. ;)

Anyway, I have demonstrated a Galaxy.dll XP compatibility hack on my blog here (wp.xin.at/archives/4601), using "Into the Breach" as an example. Essentially, you just need to fix the PE header of the binary to replace the NT 6.1 platform information with 5.1, then you reimplement a few modern function calls in a small stub DLL, and then redirect the calls from the game binary and Galaxy.dll to that stub DLL. The missing calls are now there, and all others get passed through to the operating systems' real API DLLs.

Problem solved! And if GOG changes something again, I'm pretty sure some hacker will be able to fix it up to make it run on XP once again, by reimplementing the missing Win32 API functionality. ;)

It's not exactly a "clean" solution, but hey... it works.

PS.: I provided links as plain text, because it seems posting actual links is not allowed here? I hope that is ok and doesn't break any rules.
Post edited March 28, 2019 by SonicBlue.986
avatar
SonicBlue.986:
A hack solution, takes me back to when the word hacker had a different sound than now.

Links cannot be posted by accounts with very low rep without a workaround.
high rated
avatar
SonicBlue.986: ...I have demonstrated a Galaxy.dll XP compatibility hack on my blog here (wp.xin.at/archives/4601), using "Into the Breach" as an example...
Many thanks for the info in your post. I have managed to use it to regain access to Age of Wonders 3 - the latest version 1.802 requires normaliz.dll and makes use of post-XP functions like GetTickCount64. In this case it is pops_api.dll that needs patching rather than the AoW3 executable but once done, it works the charm.

Thanks to Oleg also and hope he updates his excellent work (Imperium Galactica 2 fails on a call to SetProcessDPIAware which this doesn't yet address).
high rated
Add Panzer Corps to the list. Works fine on XP normally but blocked by Galaxy.dll. Fixable using the bcrypt/kernel35.dll combination mentioned above.
high rated
A new twist on the Galaxy compatibility issue - Stellar Tactics appears to copy its galaxy.dll file into its Cache folder on startup (so any modifications are over-written). On the other hand, the game still works - you just have an error message on startup (modifying the .dll and making it read-only causes the game to crash to desktop).

Better news - there is a solution to the SetProcessDPIAware problem mentioned in my previous post thanks to the Xompie website.

The details are covered here for Imperium Galactica 2 but this fix also works on
This War of Mine (which previously crashed with the same error).
Post edited April 17, 2020 by AstralWanderer
high rated
Eador Imperium is another candidate hit by "Galaxy"-itis, despite it being targeted at Win2K platforms onwards (according to the program headers). For full details on how to work around this, see this thread
I do wonder if FATE and Fate: undiscovered realms the galaxy.dll fault for the error since it's similar to eador imperium.
("The procedure entry point QueryFullProcessImageNameA could not be located in the dynamic link library KERNEL32.dll")

On pcgaming wiki the first two games do say that they supported win xp the latter games only vista and higher.
Or maybe it was updated too much and that is why it doesn't work.
I only tried Fate and Fate: traitor soul to confirm that the query error shows up
Edit: after trying the above i got rid of query problem with the bcrypt/kernel35.dll combination, but then i get a gettickcount64.
Post edited April 21, 2021 by Fonzer
high rated
avatar
Fonzer: Edit: after trying the above i got rid of query problem with the bcrypt/kernel35.dll combination, but then i get a gettickcount64.
This can be fixed by using the second solution of SonicBlue.986's Into the Breach fix using his Stellaris patch (this includes zernel32.dll which implements the gettickcount64 function).

Good luck.
avatar
Fonzer: Edit: after trying the above i got rid of query problem with the bcrypt/kernel35.dll combination, but then i get a gettickcount64.
avatar
AstralWanderer: This can be fixed by using the second solution of SonicBlue.986's Into the Breach fix using his Stellaris patch (this includes zernel32.dll which implements the gettickcount64 function).

Good luck.
I tried both solutions but now i get a ReleaseSRWLockExclusive not found in dll library kernel 32 or 35 dependable on the kernel i used. But this was for Fate traitor soul game that i tried.
I did try using the patch for into the breach on galaxy dll so i don't know what to do anymore.
Galaxy.dll is version 1.144.1.0

Also appeared on undiscovered realms.
Post edited April 22, 2021 by Fonzer
avatar
Fonzer: I tried both solutions but now i get a ReleaseSRWLockExclusive not found in dll library kernel 32 or 35 dependable on the kernel i used...
Check the Extended XP :Lets patch XP for newer apps thread to get that function added. This does involve a system-wide change so I'd recommend a full system backup beforehand.