In the case of the scanner in the original post here which appears to be from the era of MacOS 10.4, 10.5 and 10.6 , the operating system clearly doesn't let the scanning software talk DIRECTLY to it, there's an abtraction layer of some sort for the SCSI or (Firewire 400?) bus.
Whole thing sorta smells like Apple trying to further assert the dominance of AArch64, what with their insane stake in the ISA and it's eventual dominance. Not a terrible thing inherently, but the push to depreciate 32-bit hardware and software alike was pointless. 32-bit ARM can (and should) live alongside AArch64 as an ISA. From what I understand, the M1 even has secure 32-bit emulation mode built-in, without any OS functionality to leverage it.
Whatever Apple does, it's hard for developers to treat the Mac like a regular development target now. Besides the ISA change, the push for Metal-agnostic GPU pipelines has left developers scrambling. Massive open projects like Blender didn't even have an Apple Silicon strategy until Apple sponsored one. It's a bit of a mess, and kinda tragic that Apple is pointlessly complicating cross-platform development.
I'm sure it's costing them dearly, but there's plenty of niche and industrial hardware like this that lasts much longer than a generation of operating systems, and there's no alternative. Linux pays lip service to compatibility, but ABIs change constantly and it's easy to get stuck in dependency hell. MacOS X is... MacOS X.
It could be possible, with emulation, to run even 68000 binaries targetting the original Mac's operating system.
... if Apple cared. They very obviously do not.
Even if each layer loses, say, 50% performance, the fastest 68k was only 75mhz.
(Although now that I think about it I think the handled the 68k/ppc transistion by just making everyone compile for both and slap em into the same binary. Memory is hazy.. it’s been at least 20 years since I’ve touched a classic mac)
What's wrong with 32-bit software? If you don't need more than 4GB of virtual memory, you've got half the memory footprint for pointers.
> The software that drives these scanners is compiled for 32bit architecture and hasn’t been updated in well over 10 years. Hasselblad refuse to update it to modern architectures, and refuse to open source it to allow others to do that, so you are stuck using an OS that can run it.
It's fine if the scanner company doesn't think it's worth putting in the work to add 64-bit support to their software themselves, but they're the ones artificially making it harder to support indefinitely by keeping the code private despite seemingly having no plans to ever sell anything that uses it again. It seems weird to me to blame OS vendors for operating in bad faith when the people who own the actual code that no longer works aren't even willing to let anyone else attempt to do the work to update it for them.
Doing nothing on the other hand, costs nothing.
1: There is the positive marketing you gain from such a move, but someone has to quantify if doing this is worth it.
So IMHO this is a giant middle finger from the OS vendors to their customers, because (as an OS developer myself) dropping support for these kinds of things are rarely done because its costing developer time to have modules that are mostly untouched for years in the tree, or infrequently provide a small shim from the new driver model to the old one. And even when it turns out to be real effort, the OS vendors show us they can provide very transparent shims as long as it benefits them and not a second longer (ex most recently doing transparent x86 emulation on arm based machines).