Yes, basically that. I need to have a game install without installer polluting the prefix with dlls blobs. The above method probably might need some registry tweaks transferred between prefixes as well. I'll give it a try without registry first.

try this:
run the installer once with WINEDEBUG=process, take note how the executable of the redistributable installer is called.
delete the prefix, start a fresh wineprefix and use the dll override feature to disable the exe. either via winecfg -> libraries -> add your exe -> change to "disable", or via env variable, e.g.
WINEDLLOVERRIDES=dotNetFx40_Full_x86_x64.exe=d wine game_installer.exe

I used this successfully in the past to prevent the dotNet installer from running. As long as the gog installer doesn't abort when failing to install the redistributable that should work for others as well.

and since these are usually the same few packages that get installed, once you collected the installer names, you can just write a small script to disable all of them automatically when creating a new wine prefix. (unless they have a totally generic name like setup.exe)

//edit:
doesn't work for .msi installers though, unless you block all of them by disabling access to msiexec.exe

The game is playable, although as I said some screens or parts of them get garbled (just tested in a clean prefix with Wine 4.0). The shooting part of the game is functional with no major issues aside from a few visual effects not working properly for the same reason. I wouldn't consider it to be worth buying yet though till the issues get solved.

Edit: the problem only applies to AMD GPU. I tested the game on a computer with integrated graphics, at it works flawlessly after installing MS Visual C++ runtime as suggested in the original post by Judas (I installed 2015 version since there was none for 2013 that supported 32 bit wine).

Raiden III works really well on the other hand (although I only tested the first two levels). The only minor annoyance is with the main menu (the active choice keeps moving down) but this issue disappears after a directional key is pressed and only happens at the start of the game.

Interesting idea, thanks! There is no need to run installer first time, since you can unpack everything with innoextract, to collect the names of executables. I'll give it a try.

I see there are a ton of *.cab files there. What is usually run when that's installed?

UPDATE:

Never mind, it's actually all driven by DXSETUP.exe, so I'll blacklist that.

Here is the list for Bioshock Infinite:

D3D11Install_2010.exe
DXSETUP.exe
scriptinterpreter.exe
vcredist_x86.exe
vcredist_x86_vs2008sp1.exe
vcredist_x86_vs2010sp1.exe

So trying with this:

WINEDLLOVERRIDES=D3D11Install_2010.exe=d;DXSETUP.exe=d;scriptinterpreter.exe=d;vcredist_x86.exe=d;vcredist_x86 _vs2008sp1.exe=d;vcredist_x86_vs2010sp1.exe=d

UPDATE 2:

That method helped thwart blobs installation! Installer complained that they failed, but still completed. And I don't see those blobs in the prefix!

Now to check if the game is working.

With dxvk enabled, it fails like this:

=====================
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 2176454046
Ignoring received block reference with non-registered memfd ID = 2176454046
Assertion 'pa_atomic_load(&(c)->_ref) >= 1' failed at pulse/context.c:1052, function pa_context_disconnect(). Aborting.
0096:err:ntdll:RtlpWaitForCriticalSection section 0x18570ca0 "?" wait timed out in thread 0096, blocked by 0097, retrying (60 sec)
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff7a90000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff7a50000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff7af0000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff7750000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff2150000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff0440000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff0e80000
00ad:fixme:dbghelp:validate_addr64 Unsupported address ffffffffe40e0000
00ad:fixme:dbghelp:validate_addr64 Unsupported address ffffffffefad0000
00ad:fixme:dbghelp:validate_addr64 Unsupported address fffffffff0410000
00ad:fixme:dbghelp:validate_addr64 Unsupported address ffffffffefab0000
00ad:fixme:dbghelp:validate_addr64 Unsupported address ffffffffe7210000
00ad:fixme:dbghelp:validate_addr64 Unsupported address ffffffffe6180000
00ad:fixme:faultrep:ReportFault 0x2114ef04 0x0 stub

=========

With wined3d it hangs for a brief moment, but looks like GPU reset kicks in (that's the first time I see it's actually working for me!). Though the whole desktop is messed up, I can switch to tty and restart sddm. A lot better than a hard hang!


=========

I should probably look into that method that @Ganni1987 mentioned, how to extend it to use more than 4GB or RAM.

@Shmerl: Just a small correction, that patch only allows programs to use more than 2 and up to 4GB of ram, which is the limit for 32bit programs.

For the game in question, I don't have the GOG version but I have access to it on Steam from the old days, I'll give it a shot tomorrow and see what I can find.

Yeah, looks like the game is hitting > 4GB and crashing (dxvk enabled) or hangs the GPU (wined3d). That's very annoying since it's 32-bit. Steam version is working OK according to https://github.com/doitsujin/dxvk/issues/1085

So either something is different with the GOG version, or something is off in my setup.

According to Joshua Ashton (dxvk / d9vk developer), memory issues in Bioshock Infinite can be caused by Galaxy.dll. Is there some way to disable it? I tried to outright remove or ban it with env variable, but then the game doesn't even start, since dynamic linker requires it. May be some fake stub can work around it, but it should at least link properly.

See: https://github.com/doitsujin/dxvk/issues/1085

Just a blind shot, what if you try a galaxy.dll from a different game(s)?

EDIT:

I'm in the process of installing and testing out the Steam version, will give you a full report asap.

does galaxy.dll even do anything when there is no galaxy client running ? I thought not ?

If it did nothing, then how would it be able to determine that galaxy is not running?

May be not, but it can still reserve memory or something like that. Of course the above was just a suggestion, we don't know for sure it's galaxy that's causing it to run out of the memory.

low effort troll posting ? :p
I said it does nothing if there is no client running. obviously it does something first when it doesn't know yet if the client is running.

Just finished testing the Steam version, it runs on both WineD3D and DXVK (although randomly freezes due to some missing xaudio ovverrides on my end).

I monitored the Virtual Memory usage and sits happily at about 2.6GB ingame at ultra settings, most likely the game is already large address aware enabled so that patch doesn't help here unfortunately.

Since you can't even get in game, I'd say there is definitely something going on with those Galaxy libraries.

Just to be clear - the logo intro videos play, it's after that it crashes with mmap error. @doitsujin also said, that Steam version is running fine for him. So it's definetely something messed up in the GOG one.

Who in the GOG support or Linux team is good to contact about this? With @linuxvangog gone and @JudasIscariot never responding to anything, I have no idea whom to ask. Contacting GOG support directly will probably end up in "we don't support it, so go figure it out yourself", instead of "hey, here is how you can remove Galaxy dependency...".