Even then, you can still download Mac DOS games that haven't been 64-bitified yet, it's just that they won't run out of the box unless you're on 10.14 or earlier; the Mac versions are not actually removed.

It's likely a case of the publisher refusing the game to be sold for Linux.

I'd guess it goes something like this.

Doesn't getting them to run on Linux involve using a separate program to extract the game files from gogs weird installer?

I don't know... does it?

Yes it does. The "format" of GOG's installers changed a while back from being more like a self-extracting ZIP / RAR file to basically a Galaxy "stream" embedded within an .exe. If you just extract that you get hundreds of folders and gibberish filenames under a \tmp folder. You need a newer version of InnoExtract that can reassemble them into the proper "post-Galaxy" structure.

"Other newer GOG.com installers don't include the raw files directly but instead store them in GOG Galaxy format: split into small parts which are then individually compressed. These files are named after their MD5 hash and stored in the tmp directory, for example "tmp/ab/d7/abd72c0dddc45f2ce6098ce3a286066a". innoextract 1.7 or newer will automatically re-assemble these parts and extract the original files"

This link explains it better:-
https://www.gog.com/forum/general/adamhms_linux_wine_wrappers_news_faq_discussion/post127

I see. Thanks for that.

So this would apply even to DOSBox-based titles and not more modern games?

Like I mentioned previously, I'm not a Linux user.

The last time I was, it was years and years ago out of necessity and not for fun/etc. like even dreaming of playing any game.

Sadly yes GOG have been "updating" installers to this all round. It's not a Linux specific thing, it's in the Windows installers too. The old installers with version numbers like 2.0.0.1.exe were the "clean" ones with files stored normally but the newer ones that have naming formats like setup_beneath_a_steel_sky_1.0_(20270).exe are all Galaxified. I just tested several DOS games like Beneath A Steel Sky, Bio Menace, 2x Indiana Jones, Dragonsphere, etc, and sure enough all offline installers are in the new "Galaxy format" and require InnoExtract to reassemble.

In fact there's a --no-gog-galaxy command line switch for InnoExtract that extracts without Galaxy format reassembly and the attached pic shows you what the offline installer contents look like in the new "Galaxy" format. Indiana Jones and the Fate of Atlantis is stored in Galaxy format in 165 files in 116 tmp folders (which is absurdly messy given the game itself takes up just 3x files in 1x folder when fed into ScummVM).

Might be easier for Linux users to download the Mac versions of DOS games, since the .pkg files are just .xar archives.

xar -xf NameOfFileHere.pkg
cd package.pkg/
tar -xvf Scripts

It’s not clear to me, galaxy is not even on Linux so what is this happening?

I'm guessing GOG are trying to make the Windows offline installers into the same internal format as how Galaxy streams in an attempt to simplify something at their end (whether it does or not is anybody's guess). If you unpack a new installer with an old InnoExtract, aside from the messed up folder structure, you'll see all sorts of cr*p in there like .png files with Galaxy buttons on in multiple languages. One thing I've seen a couple of people comment on is that the newer "Galaxy Structure" based offline installers seem slower to install than the old one. I don't have time tonight, but since I have a number of the old ones backed up offline, I'll have to download the new ones and compare install times side by side.

Great so offline installers will become even more bloated and less user friendly than they were before. So much for galaxy being optional!

Yeah it's not good. If anyone is interested, I just did a couple of quick performance tests comparing old vs new installers. Installation was from a RAMDisk to a fast SSD to eliminate drive bottlenecks. Numbers are size in MB / install time in seconds. A portable 7z of the game folder (compression settings = LZMA2 / Solid / 128MB Dictionary) was also included as a control to show the time in copying the files without extra work. Game versions are all the same version, it's just the installers that are different, ie, those endless "Installer update - No game files were changed" changelog entries a while back.

1954 Alcatraz:-

Old installer "setup_1954_alcatraz_2.1.0.4.exe" - 1,115MB / 49s
New installer "setup_1954_alcatraz_1.3.5019_(19812).exe" - 1,195MB / 57s
7z of new installer - 1,087MB / 9s

Crookz The Big Heist:-

Old installer "setup_crookz_2.1.0.4.exe" - 3,479MB / 49s
New installer "setup_crookz_1.0.0.24360_(16766).exe" - 3,488MB / 216s
7z of new installer - 3,259MB / 44s

Aside from Inno Setup simply being slower in general (1954 Alcatraz requires no dependencies so the extra time isn't on installing .NET / VCRedist, etc), the Galaxified versions always take longer as first they have to extract the "Galaxy stream" files into a temp folder and then do a 2nd pass reassembling them into "actual" files, before moving them to the destination folder where the others seem to extract more directly. For some games this is relatively minor (57s vs 49s is 12% slower) but for others the difference is highly pronounced, eg, Crookz 3m 36s Galaxified installers is over 4x slower vs 49s old installers. I used to think the neatly packaged installers were more convenient, but for some users (eg, Linux or ScummVM for Android) GOG would be doing everyone a favour just supplying a clean zip file rather than "enhance" the offline installers with fake "Galaxy files" any more.

To be fair, here on Linux I get very different results when extracting the installer data with innoextract:
- setup_1954_alcatraz_2.1.0.4.exe (old format): 27s
- setup_1954_alcatraz_1.3.5019_(19812).exe (new format): 18s

So I suspect what you notice is due to the way the chunks are handled by the new installers, not their compression method. The new installers logic would be the cause of the slowdown, much more than the way the contents are stored.

I do not own Crookz so can not test this one, but my experience (limited to innoextract, I never run GOG Windows installers) is that the new format is reliably quicker to extract (usually takes half the time compared to the old format) at the cost of bigger downloads.

To get something roughly similar to your Crookz test, I gave a try to A New Beginning:
- setup_a_new_beginning_final_cut_2.2.0.7.exe (3.6Gib): 1m39s (beware that this is one of these RAR-based installers)
- setup_a_new_beginning_final_cut_2.0.4.0395_(27805).exe (3.9GiB): 47s

---

EDIT

One last test to be on the safe side, with Giana Sisters: Twisted Dreams:
- setup_giana_sisters_twisted_dreams_2.2.0.16.exe (1.3GiB): 1m22s
- setup_giana_sisters_twisted_dreams_1.2.1_(19142).exe (1.5GiB): 25s

Yeah that was what I was also thinking about, the most logical explanation is that they are streamlining the offline installer structure to the same as Galaxy, in order to lessen extra work for the offline installers.

If this change means updates, which are already available on Galaxy, find their way faster to the offline installers, then I will consider this as a positive change, at least if it is so that Linux users can still "extract" the correct game files by using a newer Innoextract.

If this new format is in use in all installers with the newer version numbering format, then they seem to have been there and quite commonplace for quite some time already. I haven't seen any issues with these new installers yet, at least in Windows. Not sure if the new installers are compatible with Windows XP (in case someone wants to try to install some older GOG games to some retro XP machine; I've done that in the past for a couple of games), but then GOG hasn't supported XP for quite some time... Maybe I could still try it with some new installer, for shits and giggles.

Indeed, InnoExtract has added special GOG support at 1.7.

The offline extractors now contain alongside the cache blob files a special compiled InnoScript which does the extraction. My guess is that IE executes this script for proper reconstruction ... what a relief.