Maybe it's issue with HDD??? I never had the game install that fast for me on windows 10/11. Usually take 30 or more mins sometimes. I'm installing form external HDD

Possible. I could try reversing the direction of data flow. Reading the setup.exe from the HDD, writing to somewhere else. (But that would require a reboot to clear any read-write cache. Will try that later.)

edit: Oh, I just remembered I *have* an empty external HDD lying around somewhere. Even better to try that.

On my notebook with an Intel i5, an SSD and Windows 11 it took 15 minutes to install the game with 39.781 files and 2.918 folders. I uninstalled it. I took the DVD of Civ IV Complete to install it. The install needed 40 minutes then. It slowed down when lots of small files were installed.

GOG is obviously wrong here.

The game's .exe immediately calls the galaxy.dll code as supplied by GOG which itself calls the "ghost wrapper" and it's that wrapper that's hanging an extra +15-20s waiting for Galaxy (that isn't running) to timeout, ie, it's Galaxy "black box" code in GOG's dlls not "internal" game code. Same way if you delete / rename galaxy.dll in games that need it, it'll crash immediately on startup long before "proper" game code is started / initialised. If you then replaced GOG's ghost wrapper (named something like "common.dll" and filled with Steam API calls) with the Goldberg Steam emulator crack (used to run Steam games without the client) without touching any of the game files, it then starts normally without any delay. There's your proof as to where the problem lies - the Galaxy 'ghost' wrapper code, not the game code. All game devs are doing is feeding the buggy code GOG gives them and following their Galaxy Developer instructions.

It hardly needs to be said that you obviously shouldn't have to use literal Steam emulator cracks on DRM-Free GOG games legally purchased from GOG, that use GOG-supplied Steam emulators to not get GOG's DRM-Free games to startup several times slower than Steam's DRM'd ones (including the extra time it takes for DRM checks) because the "offline" wrapper is waiting ages for a response from a client not running. That sheer level of over-convoluted, "Rube-Goldberg Machine" obtuseness of a faked Steam client running within a faked Galaxy client, is absurd in offline installers, and completely not why many of us signed up here for clean, hassle-free, DRM-Free games in the first place.

It's more than a bit pointless to compare radically different read speeds of different install media (optical vs external HDD / SSD) when testing something else entirely. For those who own games with abnormally long install times, it would interesting to do the following test:-

1. If the game is already installed, uninstall it then reboot Windows to completely clear the Windows File Cache
2. Using GOG installers backed up to an external HDD, install the game and time how long it takes.
3. Once installed, zip up the game folder then move the zip file to the same external HDD
4. Reboot Windows (to clear the Windows File Cache)
5. Unzip that zip file of the game folder to your SSD (again timing how long it takes)

If there's a significant disparity between the two, then the problem isn't simply "writing lots of little files is slow" but rather is intrinsic to GOG's offline installer (presumably the extra convoluted stage needed in renaming all the Galaxy streams back to files, then maybe using single-threaded decompression on top).

Last i installed Civ 4 (steam) it had a shitload of text files and took a good long while like most paradox games.

So? That can be done on another thread. Apparently the dev is calling the function on the main thread and blocking. Which you should not do if the call is not guaranteed to return immediately.

Again, I understand the delay is happening in a library the game calls, but the game doesn't have to wait. It's choosing to wait.

UPDATE #2:

Civ 4 install
Windows 7 natively, as above
but this time I intentionally tried to create the worst possible working conditions:
reading from and writing to the same USB 2.0 external 2.5 inch HDD.
Result: The install process completed in 17 minutes.

This must be some problem with WINE then. It's definitely not the HDD. I mean, of course it's a bit slower than installing from/ to an SSD, but still very much acceptable.

The Civ 4 installer does take a lot longer than is reasonable. By comparison, a game where the installer is of similar size (King's Bounty Crossworlds) takes 2.5 minutes to install using Wine, on a HD where the installer and installed game are on the same drive. Presumably this could be sped up using my SSD but I'm not going to bother. This game has almost 4,000 files, and the data written while extracting matches the final installed size almost exactly. Using innoextract, it takes 2.0 minutes.

Another game with a similar installer size, Sins of a Solar Empire, takes 3.5 minutes to install, has ~10K files, but writes over 7GB while installing even though the final size is 4.4GB. Civ 4 takes half an hour, has ~40K files and writes well over 100 GB during installation for some reason. Wine historically has issues with I/O, so maybe the very large number of files has something to do with it, or the excessive disk writing, though that doesn't explain why Crossworlds doesn't do that (and 4K files is still a lot).

In conclusion, the offline installers suck (but not any worse than you remember), Wine file I/O sucks, the Civ 4 installer in particular sucks, and something with your system definitely sucks; 2+ hours is absurd.

You are right. The installer does a lot of I/O read operations.
I did another install while monitoring it at the same time. See attached screenshot.
I/O Read = 153 GiB, not sure why either
I/O Write = 4.3 GiB, as expected, matches the final size

edit: ^^ To put that into perspective: Each byte written is read 35 times !

I could justify 16Gb read with the current form, 4Gb extract files, 4Gb to do a first pass hash checks (before it works) and again 4Gb hash checks (check files are build correctly), and 4Gb to copy. (A good programmer would have combined most of these steps).

After that... No clue. there's 9x more going on than needed. And if they weren't broken into chunks it would only need to verify the initial archive and then each file as they output.

Though; Do you have a separate drive for temp folder? Maybe ramdisk? If said ramdisk is FAT32 it may work a LOT faster. Or just having enough Ram where it's all cached then it doesn't matter as much.

Me?
That last I/O measurement was done while installing from my system SSD to a secondary SSD. My System has 32 GiB of RAM total. I didn't notice any use of temp\ except for the setup GUI installer/ executable itself.

Hmmm yeah... no clue then. It just seems like things get more inefficient and bloated.

That might be how you want the Galaxy wrapper to function, but isn't how it actually does. Rather than go round in circles arguing "Gog's wrapper isn't up to GOG to fix or acknowledge" (of course it is, they've already acknowledged the problem on another thread but only half-fixed it), I'll just refer again to you that.