Is SRHK 64-bit this time on Linux or just the usual 32-bit only binary?

Why is this kind of bullshit happening?

We have 64 bit Linux operating systems now, why are we getting 32 bit software? Is this down to HBS or GOG?

It's always one step forwards and two back.

What does it matter?

They could compile it as 64-bit and it would be no different unless they took advantage of it.

Is it even really 64 bit for the Windows version? I can't imagine this game really needing that much.

I would be slightly faster, '64-bit" vs "32-bit" isn't just a larger address space, but amd64 architecture also has additional registers compared to i386 architecture, and compilers use those additional registers to optimize the code more, so even if you don't change one line of source code, compiling for amd64 will give you a slightly faster binary than if you compile for ia32.

The binary would also be slightly bigger. But more importantly it would break backwards compatibility with older hardware and non-x64 OSs, which especially in the Linux world are still being used by many - you don't really need a 64-bit OS if you have less than 4GB of RAM.
I don't think creating a 64-bit binary would be worth the trouble, neither for HBS nor for the users.

In the Linux world 64-bit is everywhere. And compiling both 32-bit and 64-bit is possible with Unity. It's not about “better” or “faster,” it's about (not) supporting what's going straight into obsolescence at the speed of light.

Oh, well.

I do understand that the HBS team currently supports only a 32bit release. I do not exactly know why (man power issue or some mono/.net mess?) but thanks to AMD our 64bit x86 cores ARE still 32bit capable. Which is a good thing. What you need, however may be 32bit libraries.
The former SRR releases worked nicely on my main box (r600g) until I hit severe issues on my Kabini (radeonsi) system, even though it was more than strong enough for the game in theory. The issue was an old 32bit compatibility lib (mesa and freedom driver stack) that was unaware of this GPU generation - thus resulting in fallback solutions which gave me about 0.5 fps (unplayable).
The solution is distribution dependent, on Gentoo we now have multi-ABI so everything is compiled with 64 AND 32 bit ABI. After that it went to absolutely fluid performance.

So 32bit causes possibly those issues but on the other hand a lot of older systems (HW/SW) are still supported. There are a lot of users out there with elderly hardware.
Of course 2 binaries would be nicer but then, as I mentioned, I don't know what keeps them from releasing two versions.

Frozenbyte explanation for Trine & Trine 2 is about proprietary middleware available in 32-bit only.
I wouldn’t be surprised if it is the same here with Shadowrun.

32-bit code which works today is the code that potentially does not work in the future. And if the game is any good you might want to replay it someday.

Seeing how we play now using DOSBOX games that are from the 80s I bet the 32-bits compat libraries will stay available for a while. Sure it would be better to not need them, but it's already too late, there are too many 32-bits only games around so we won't be able to ditch all those compat lib for long.

Which is emulator and DOS is much smaller. I've already had 1 Debian release where 32-bit libraries couldn't access hardware acceleration from my graphics card. Speaking of which, there is absolutely no guaranty that newer drivers for newer graphics cards will even have 32-bit versions. That's gonna be a pain down the road.

I don't have any 32-bit libraries on my machine nowadays, personally.

I’m almost certain that the day 32-bit compatibility is dropped from modern CPU we will see emulators coming.

Not that it would justify in any way to bypass the publication of both 32-bit & 64-bit binaries for games developed today. But I don’t think we will not be able to play our "old" 32-bit games in the foreseeable future.

AFAIK 32 bit will always be able to work in higher multiples. It's just the higher multiples that can't work in lower environments. I don't think there is a way to lose that backward compatibility.