Comment by StillBored | Hacker News Reader

Comment by StillBored | Hacker News Reader

Again, I will write. The job of an OS is to provide an abstracted shim between HW customers have, and the software they have. When this doesn't happen it is a giant fail. There are untold thousands of devices just like this scanner for which the choices to drop support (or change) the OS driver ABI puts people in a bad position because frequently this low volume specialty hardware costs more than the OS vendors product and a new PC/etc to run it because the HW vendor uses MS/Apple/etc's decisions as a chance to force their customers to upgrade to the latest HW. Frequently when the old stuff continues to work just fine.

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).

On the other hand, there is little that necessitates this sort of thing to be part of the OS instead of just being separate piece of software like VueScan

This isn't the MS-DOS/PC-DOS era where it was necessary for software to have full and direct access to communicate directly with the (ISA 16-bit bus attached, whatever) hardware and peripherals on a desktop workstation, because that can crash the whole multitasking OS.

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.

This paragraph from the blog post stuck out to me:

> 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.

In business terms, open-sourcing a piece of software they haven't touched for ten years means spending a number of hours on doing that for no obvious gain¹. Legal has to clear this for approval (risks? liability?), someone has to decide if opening up the code won't give away company IP, and someone has to actually find the source code (not a given at all), put a licence on it (going through legal again), upload it, and provide a minimum level of documentation.

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.

That's fair, but I still don't see why that somehow means that the OS vendor should therefore be expected to keep that code working in perpetuity. I have no love for Apple or MacOS, but I just don't see how they're ultimately the ones who should be blamed for this situation.

Apparently the Apple Silicon macs don't have the capability of running 32bit binaries. Since this software is abandoned, it's not like a longer support window would have given them time to recompile the drivers.

>the Apple Silicon macs don't have the capability of running 32bit binaries.

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.

Yes, Apple only cares about allowing supported software to easily keep running. This means they can implement more modern and secure systems than Microsoft is able to achieve. It's also the reason Windows is plagued with 32 bit software currently in development as MS has no way to push for the removal of obsolete features.

> It's also the reason Windows is plagued with 32 bit software currently in development

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.

One major issue is it can't handle dates any further than 2038 which is getting uncomfortably close, especially when you have to handle future dates.

Windows doesn't use UNIX time. The SYSTEMTIME structure can go up to the year 30827. See https://learn.microsoft.com/en-us/windows/win32/api/minwinba....

64-bit time_t works perfectly fine on 32-bit systems. That is completely unrelated to machine word size.

And also the reason why no large company will touch macos (and I imagine it is the same thing server side).

Given the vast difference in power, it’d probably have been enough to just cascade all the various layers they already have. Arm > x86 > ppc > 68k

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)

You're confusing the "fat" binary format that allowed developers to ship the same application file for both 68k and PowerPC with the emulator that allowed for compatibility with existing 68k code. Much of the OS and apps remained 68k to the end of classic Mac OS's life.

Intel Macs do, though; until Apple removed it. Worked fine in Mojave, but me (and many others) one day rebooted our Macs to find dozens of programs, libraries and plugins that no longer worked.

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.

For all the hate Microsoft regularly gets, they are pretty amazing about that: I have ancient software that still runs fine on Windows 11 through layers upon layers of compatibility libraries baked into the OS.

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.

Speaking of smelly: My scanner just broke down last week. The powersupply started smelling burned plastic and then gave up the ghost completely. Can't find a powersuppy fitting the special contact. It has been working since windows 95 or so, was now running windows 10 without problems and without having to install special drivers from the producer. Old was a canon, early USB model.

Reply on news.ycombinator.com