Try it anyhow.. and tell me how it goes.

Oh, and make sure you give them the same email address that you use for logging in on GOG. Otherwise they can't figure out who you are, even if you link directly to a forum post of yours. And apparently they need to figure out who you are before they can help.

Sure, wouldn't hurt contacting them anyway. May be they'll find the right person for this.

UPDATE: I wrote to them explaining this in detail. Let's see what they'll say.

what wine did you use ?
SteamPlay/Proton?
vanilla wine?

yeah, I mean, i don't think they even have an option to remove that dependency, when the game is linked against galaxy.dll as you said. I doubt they have access to the source and the permission to change/recompile/distribute the modified exe. Not sure support is going to be much help.
Would be cool if you could get that d9vk developer to provide some more detail on where galaxy is "known to leak file descriptors & memory".
Then post that info on the mantis bugtracker or the galaxy thread. That should get some attention from the galaxy developers (ideally).

I used vanilla Wine 4.9 + dxvk.

just asking because shmerl was using vanilla wine

@shmerl
might be worth giving wine-staging a try? probably faster than waiting for an answer from GOG support :p

Yeah, let me try that. May be staging has some patches to reign in virtual memory overuse.

UPDATE:

Interesting, it didn't crash on mmap this time! Though it's getting stuck on xaudio with just showing a black screen:

====

00ba:err:ntdll:RtlpWaitForCriticalSection section 0x5846f88 "xaudio_dll.c: XA2SourceImpl.lock" wait timed out in thread 00ba, blocked by 00b7, retrying (60 sec)
00b7:err:ntdll:RtlpWaitForCriticalSection section 0x182e0ca0 "?" wait timed out in thread 00b7, blocked by 00ba, retrying (60 sec)

At least that's progress!

I wonder if it's related to faudio, since I've seen somewhere, that staging disables it, while stock wine is using it.

UPDATE 2:

Installing xact with winetricks worked around that. It started! Thanks a lot for the idea. I wonder what exactly staging does to fix it.

That's the same error I get with Wine Staging 4.9. The plot thickens

Edit: What if you build Wine Staging without those xaudio reverts?

For now I just installed xact with winetricks, and it worked! I can try building staging without faudio reverts. Problem is, it's a major pain to build WoW64 Wine (with 32-bit support) without using some chroot, containers or outright 32-bit VM. So I just never got to set up the build for it yet. I always simply build pure 64-bit Wine when needed. But I might as well go through setting up that mess again.

Wine developers really should figure out how to make it cross-compilable on 64-bit Linux. But I suppose a lot depends on proper multiarch packaging, which is a huge mess in Debian still. I still can't build 32-bit Mesa for example by cross compiling.

How do you build it usually?

I always compile the 64bit on host OS and the 32bit part in a VM, then merge the required files together.

EDIT: I play a lot of 32bit games, so that component is a must for me.

I actually compile 64-bit one in VM as well, and Mesa in a separate one, in order not to mess up things accidentally when dealing with some manual tweaks. I'll just add a 32-bit VM to that. I had no need to do it until now, since stock Wine was enough (it's WoW64). But the above case was really weird.

So to understand what you did:

Built Wine with Staging patches and applied xact with winetricks, and now game works "perfectly" so to speak?

I installed pre-built staging Wine from winehq repo. It's WoW64, so supports 32-bit. And installed xact with winetricks, yes.
For now I have a setup to build 64-bit Wine only (stock / staging, etc.). That's good only for 64-bit games. But I'll probably eventually set up 32-bit VM as well, since using faudio with staging would be better. Can be useful for such weird 32-bit outliers.

I can't say how "perfect" it is, since I didn't get far beyond the loading screen and settings, since I don't plan a major playthrough now (still in the middle of TW3). But I was interested in making it work, after buying the game :)

Out of curiosity, what specs do you use for the VM?

(Also, assuming your kernel can run 32-bit binaries, you could also use a chroot or container for the compiling, avoiding the overhead of a VM. And if your kernel can't run 32-bit binaries, why are you compiling a program that your system can't execute? (Note that not being able to run 32-bit binaries would be highly unusual; it probably means you compiled your own kernel and chose to disable 32-bit support, or you're working with some embedded distribution rather than one meant for desktop/laptop use.))

Again, you can do this with a chroot or a container and avoid the overhead of a VM.

(Quick way to get a debian chroot: use debootstrap. You may need to copy or hardlink resolv.conf into the chroot if you need network access (in particular, DNS) in it, but otherwise you should be fine for this purpose. Other distributions have similar tools; if you want an Arch or Gentoo chroot, the installation guide will have you setting up a chroot as part of the installation, so you could just follow that part of the guide.)