Hacker News Reader

Comment by smsm42 | Hacker News Reader

I've just checked which 32-bit apps I have (system information/software/applications if you wonder) and turns out if I upgrade I lose:

- My scanner support (they have new version, which is insanely buggy and can't even detect my scanner properly)

- All my games (literally every single one of them turns out to be 32-bit) - I don't play that much but still, would be a shame to lose all of them

- Postal label printing app (no idea if they have an update, need to check)

- App supporting my stand-alone disk array (not using it too much though)

- My niche learning apps (pretty old, from small providers, not sure if they'd ever be updated)

Much more than I expected, given that I don't have any exotic stuff like music instruments, specialized equipment, etc. So I personally probably would hold off upgrading as long as I can.

View on HN

Apple's backward compatibility is poor, and particularly bad for games. The 32-bit apocalypse kills off a large subset of the Mac's already less-than-stellar game library; and on iOS it already broke many apps that I used, many of which will not be updated. To me it seems like Apple is going in the wrong direction - really I want them to add an x32 ABI to save pointer space for apps that don't need more than 4GB!

Stick with Windows/Steam/Consoles/etc. if you don't want a bunch of your games that you purchased to become unplayable every year (unless you add multi-boot to run the old, compatible OS, or run them in a VM, which usually works poorly.)

As I have mentioned before, it's a very annoying example of Apple shifting technical debt and maintenance work away from themselves and onto developers, and the overall maintenance burden is greatly increased.

I like how the platform moves forward, but I really wish that there were a way of getting desirable security patches and feature improvements in the OS without breaking all of my apps.

Dropping 32bit support is game-over for gaming on macOS. The numbers already didn't add up for indie developers [1]. Even AAA game developers often ignore macOS because the ROI is just too low. And from the $5/month subscription how much will end up to the developers [2]?

Essentially what Apple Arcade will end-up hosting is ports of run-of-the-mill mobile games. And I'd bet the advertised number of developers will diminish as soon as the agreements they secured for the launch expire. But if this is the kind of gaming you're interested into, you already have your iPhone/iPad.

[1]: https://www.gridsagegames.com/blog/2019/09/sorry-mac-users-a...

[2]: https://www.vice.com/en_us/article/43k4ww/its-hard-to-use-ap...

> Dropping 32bit support is game-over for gaming on macOS.

No, it isn't. There were never any 32-bit x86 Macs with decent GPUs. Dropping 32-bit support only affects games that were already old enough to be commercially irrelevant or games that rely on unmaintained third-party middleware that never got a 64-bit port. Those don't add up to enough to be a major impact on the Mac gaming market. There are plenty of other factors that are much more important, such as Apple's abandonment of OpenGL and preference for Metal over Vulkan.

A huge amount of Indie games do not require a powerful (or even decent cpu). Many of them have Linux and Mac ports. Those are the same kind of games whose developers do not have a lot of spare resources to stay on the endless treadmill of deprecation.

It also kills any hope of wine powered support for proton in steam as many many windows games will be still 32 bit for a very long time (mind you, metal already had put a big dent in that).

Interestingly Linux users are indirectly getting affected by this: for many developers supporting Linux was just a byproduct of supporting macOS. As the latter is being dropped, support for the former is getting harder to justify. Luckily Proton seem to be a very viable alternative to native games.

I thought PlayOnLinux/WINE is the linux gaming solution.

Proton is a wine variant directly integrated with steam.

A bunch of Aspyr titles (a sizable publisher of AAA ports) won't work with Catalina, and there are no plans for updates.

These aren't old games for the most part: https://www.macworld.co.uk/feature/mac-software/apps-wont-wo...

Those are old games for the most part. The newest thing on that list appears to be from 2015, and it's a remastered version of games released in 1999 and 2003.

They certainly weren't making much money off these particular games even before Apple announced the deadline for going 64-bit. It's unfortunate and disappointing for customers who had already bought those games, but this deprecation didn't shut Aspyr out of much in the way of future sales.

Users do not care about that. They care about when things they paid for stop working.

But that's not what drives the market for Mac gaming. What matters is what kind of return on investment developers expect to get out of porting to macOS. They don't particularly care whether the port keeps working for four years or forty, because they'll make basically all the revenue in the first several months.

Now, if users become reluctant to buy Mac games for fear that they'll stop working unacceptably soon, that could have a meaningful impact on demand for Mac games. But even if Apple made it official policy that they would break games after four or five years, that wouldn't completely kill the market for Mac games. If Apple made it cost-prohibitive to get a game ported to their platform in the first place, that would pretty much be "game-over for gaming on macOS".

If you can't play your old games it makes the entire platform unattractive to players, which in turns makes it unattractive to game developers.

But tbh Mac was hardly a gaming platform to begin with.

>it makes the entire platform unattractive to players

The platform has never been "attractive to players" to begin with.

Now we have Arcade though and easy porting to iOS though, which could open a multi-billion market...

Now, if you only had a way to actually get your fair share of those billions...

Commercially irrelevant for the game maybe, but not for the platform. If i can't play my old favorite games i am less inclined to buy a new platform. Or might move to a platform which supports those games.

> No, it isn't.

Well, let's see. My main 3 purchase locations are Steam, Humble Bundle and GOG.com. I'd guess this is fairly typical, but anyone using other platforms feel free to add yours.

Steam: The Steam client is still stuck on 32bits. I'd bet it will soon be updated to 64bit, but it just goes to show that macOS is pretty low in the priorities of Valve. And if a company with the resources of Valve doesn't care, I can't see much motivation for the individual developers either.

Humble Bundle: I've went through the current and following Humble Bundle Monthly games. Windows Only: Call of Duty WWII, Crash Bandicoot Remastered, Spyro Remastered, Sonic Mania, Planet Alpha, Override-Mech City Brawl. Windows+macOS: Battletech, The Spiral Scouts.

GOG.com: There's already a 64bit DOSBox port—DOS–era games will eventually be supported. Windows–era games are gone—Catalina breaks Wine emulation and no announcement has been made for 64bit support by the Wine Team. For newer games, GOG.com will need new builds from the developers—doubtful if we ever get to see those, especially for indie games where developers don't have the resources to go back and port their released games. Newly released games are often Windows-only.

I don't know how you see this picture, but it looks pretty bleak to me.

The Steam client has been updated to 64 bit quite a long while before. But the in built updater seems to only fetch the 32 bit version. If you uninstall Steam and do a clean reinstall from Steam website, you will get the 64 bit client.

Old games like Civilization 6? Civ 5 is old, I give you that.

Civ 5 and 6 both have 64-bit Mac versions. It's only Civ 4 that's unplayable on Catalina. That's a game from 2005.

Most indie games in the past 5+ years are made with a few middleware engines like unity or gamemaker and AFAIK it's a rebuild option to release a 64bit version.

This is true, but unfortunately, a lot of games are almost completely unmaintained, especially on macOS. Many of the smallest indie game developers don't even own Macs—they either borrow their friends' machines to do one-off builds, or they use cross-compilers and rely on fans for testing.

Even just recompiling the game might be a challenge for a lot of developers in the "long tail" of the Mac game library.

This is my sentiment as well. A twitter summed it up nicely:

> the notion that every developer of every app is part of the constant, incessant update loop that Apple encourages is fundamental to the problem. Someone's super personal narrative unity game from 2013 is not getting updated!

[1] https://twitter.com/MammonMachine/status/1181327259057082368

Unity 5 came out in 2017 and it's not supported on Catalina.[1]

So devs of two year old games will need an old macOS install that can export their game to 64-bit, but also a new enough macOS install that can notarize their app (maybe these can both be Mojave -- but many indies don't own their own macs).

Also, Unity 5 is no longer available for purchase. If they're already using their license on another machine, they'll have to migrate it to these macOS installs.

Devs could upgrade to a more recent Unity and fix all the bugs, but to what benefit and at what cost?

[1]: https://forum.unity.com/threads/installing-unity-on-macos-ca...

It would be interesting to see a report from Steam on how many 32bit only OSX games are in the store. According to the stream hardware survey [1], OSX represents 3% of their install base.

[1]: https://store.steampowered.com/hwsurvey

According to people in the know, the $5 a month is for Apple. Apple pays a flat-fee to the developers of games in Apple Arcade, and that's it.

... I mean sure, I love the idea of paying $60 for a game that throws away 15-20% of the performance by targeting an architecture that hasn't been supported by MacOS for more than a decade, rather than supporting an architecture that has been around for something like 15 years.

But yes, apple is in the wrong here, and should continue to support hardware that they haven't shipped in 10+ years.

I assume you're in the group that believes MS should be required to support XP forever.

As far as iOS is concerned, Apple got rid of 32 bit support in the processor itself allowing it to improve the processor.

Keeping around old code increases the security vulnerability surface. For instance, there are at least a half dozen ways of representing a string in Windows. One of the earliest widespread vulnerabilities in Windows was caused by improper handling of string encoding where anyone could run DOS commands on a web server running IIS just by encoding the commands in the browser.

https://www.sans.org/reading-room/whitepapers/threats/unicod...

> As far as iOS is concerned, Apple got rid of 32 bit support in the processor itself allowing it to improve the processor.

That is slightly different because Apple is designing their own mobile CPU's. And indeed by dropping 32-bit ARM support they can simplify and improve their CPU designs.

OTOH, Intel isn't gonna drop 32-bit x86 support from their chips just because Apple isn't making use of it.

Yeah but maybe dropping 32-bit support is a necessary step before dropping Intel chips...

They will face some* backslash now, but if/when they switch Mac to their own arm chips they might achieve a painless transition.

*They announced 32-bit deprecation like a decade ago, will legacy users be pissed of? yes! Is it a excuse for developers that still relied on 32-bit support over the last decade? NO!

Maybe, but I remember reading a the time that it was so the OS didn't need to load two versions of every library in.

Your example is from 2000/2001. The same year OSX was first publicly released.

That’s kind of the point - it’s gotten worse since then. Windows has become more bloated as they’ve added on more layers and refuse to drop backwards compatibility.

Presumably Apple is dropping x86-32 because they don't want to spend resources maintaining 32-bit support libraries, doubling their testing matrix etc. And now you want them to add a third ABI?

(Even in the Linux world, which prides itself in supporting crap used by a handful of people globally, X32 is dead, to the extent it was ever alive.)

X32 is dead exactly because, where 64bit is not needed, x86-32 is perfectly fine. I.e. the only practical reason not to go 64 is backward compatibility.

Indeed. X32 is beneficial for an application that

- Never needs more than 4 GB RAM (because it's not worth the usability downsides from having two binaries and letting the user choose which to use, just for a small performance boost)

- Is performance critical

- Performance is bound by memory and/or cache bandwidth

- A large share of the program memory usage is due to pointers

The intersection of all the above is just vanishingly small in reality. X32 was never more than a gimmick to score a few extra points in SPECcpu. And thus people rightfully ignored it.

Regarding games, Apple Arcade seems to be just what the Mac needed.

I haven't evaluated the quality of available offerings yet, but they look good in the App Store previews, and I think they're all native Mac apps (not lazy ports), using Metal and everything.

Although yeah, you can't really own any of those games and will always need a subscription, and some may be removed in the future.

I play games on my Mac when I can play them on my PC (travelling is one reason for this). I try buy my games DRM free on GOG, and play them either on Mac or through Steam streaming (yes you can load non steam games). My Mac game library is essentially wiped out by this.

And yes, there's this Arcade, but I have no interest in playing for something which is locked down to one platform.

If I want to play something and I already own that platform, why should I prevent myself from playing it because of its exclusivity?

Do you boycott Xbox, Playstation, Switch, DS etc. exclusives too?

What about Windows-only games that aren't on Mac or other systems? There are certainly thousands of those. Do you refuse to play those either?

Does this mean I won't be able to play 32-bit Windows games with CrossOver?

Not currently, but Codeweavers is working on a solution.

https://www.codeweavers.com/about/blogs/ken/2019/10/3/crosso...

It depends.

* 64bit processes usually can't load 32bit modules, only a 64bit OS can (true for Linux and Windows, I'm not sure if it's true for x86 overall). There's a pretty good chance that only a 32bit CrossOver could load 32bit modules.

* Has 32bit support been stripped from the kernel, or has it only been stripped from the installed dynamic libraries? I'd wager that it's stripped from, or partially stripped from, the kernel. Even if Catalina allows 64bit processes to load 32bit modules, the kernel would have to support it.

There's a one in four chance your scenario is supported. CrossOver definitely couldn't magically voodoo a 32bit module into a 64bit one, as it's impossible to determine if a register/address is a 32bit integer or pointer; if it doesn't work today, it will probably never work.

I'm not sure if macOS supports IOMMU, but an external GPU with a VM might be your saving grace here.

Support has been at least partially stripped from the kernel. Attempting to run a 32-bit executable yields an "invalid executable type" error.

Given that the kernel is open source, I wonder how hard it would be for someone to add that back in...

Ah, thank you guys for posting this.

I'll hold off too. My macbook pro is 2013 and pretty old it overheat often if I play video. This update will definatedly exacerbate the problem.

Doesn't the apple watch run a 32bit-on-aarch64 abi?

Apple watch uses a variant of LLVM bitcode as deployment format.

And no, it isn't raw LLVM bitcode.

I was talking about the arch/abi running on the os. Looks like it's called "arm64_32" (maybe it's similar to the linux abi "x32"?)

Xamarin among others ran into a snag but it seems they could retool and convert from armv7k to arm64_32 for example https://github.com/xamarin/xamarin-macios/issues/4864

Yes.

Have a look at vuescan. It's 64bit clean and supports scanners back to the late 1990's.

I use it myself and ignore the manufacturers software altogether. Which form my scanner only supported PowerPC.

https://www.hamrick.com/vuescan/supported-scanners.html

Wow, VueScan! A blast from the past. I used it 15 years ago. Glad to see it's still around, maintained by the one guy (and now him and his son according to the website). I'm definitely going to buy a license now ($99) and ditch the 32-bit manufacturer's software.

Software like VueScan and USB Overdrive (just bought a license for that too $20) deserve to be in some sort of Apple Hall of Fame.

I switched to ExactScan to support my Fujitsu S1500M:

https://www.exactscan.com

Vuescan is great, its better than most scanner apps too, insomuch as, its actually good at scanning.

> its actually good at scanning

Careful now. Scanner manufacturers would have you believe that's nearly impossible unless you remember to make the appropriate sacrifices under a full moon on a marble altar.

I found this application the other day, and despite its look, it really is great.

It really demonstrates how incredible Windows 10’s 16-bit application support is.

Although I understand the Windows codebase is a nightmare.

And how much they tolerate it, as it's so embedded in their engineering culture and I imagine "backwards compatibility" is drilled into your face when you start working on Windows at MS.

It's not easy to get into the mindset of fixing every problem a 3rd party app creates.

Some will say Apple is offloading tech-debt onto client apps, but Microsoft is allowing client appts to offload tech-debt onto itself, and it's big enough to take that burden on so its users can still use the stuff they bought.

I dunno, sometimes I hate having to do it but it's all about user/dev experience and if you're optimising for your own employees you're making it worse for everyone else who makes your OS/machinery worth buying. There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware.

Which, additionally, must contradict their environmental aims. It's not good for the environment if upgrading an OS means you throw away your printers and scanners and buy compatible ones.

As a developer who strongly advocates for and strives to maintain backwards compatibility whenever possible (and even when it isn't so easy...), I can say that it's unfortunately something the vast majority of (younger) developers today don't even think about, much less care for. Perhaps they just haven't experienced stability nor noticed it enough in their daily lives, because all they seem to care about is "new and shiny" and rewriting things constantly.

I have written various (Windows) utilities over the years, and some are over 20 years old now and I use them every day. They worked on Win95, they still work through to Win10. They're all tiny single binaries that require no installation, start immediately, and are extremely responsive and low on memory usage. Ironically, it's almost impossible to do that with a "modern" toolchain now, and I'm not even sure if something like that would've ever been possible with the Mac. To me, the idea that backwards compatibility is a "burden" is absurd. Constant churn is a burden. If I had to go and "fix" all my utilities every few years because a new OS broke something that was working before, I would have less time for actual new developments. Instead I can continue to use them and write other things as the needs arise, instead of wasting the effort redoing things that should've still been working. Just "leaving well enough alone" is a big part of it.

The kind of simple utilities you are talking about would have also been pretty easy to maintain/port from OPENSTEP in 1996 through to current MacOS. Apple's offered pretty good source-level compatibility for the basic stuff, and an easy migration path for tooling. Recompiling something every few years isn't a "constant churn" sort of burden.

There's a lot of stuff out there that's not maintained, but is still useful. So "recompiling every few years" is a pretty big burden.

> There's a lot of stuff out there that's not maintained, but is still useful.

I can't see how this is Apple's problem. Holding up development of a platform and technical progression generally for unmaintaned software is not a good working model for anyone, no matter how useful it is.

> So "recompiling every few years" is a pretty big burden.

As is "supporting everything ever implemented in perpituity"...

is not a good working model for anyone, no matter how useful it is

WTF!? You've just perfectly illustrated the attitude that's making technology worse for everyone.

What are computers for? "To control and force users to consume mindlessly" might be an accurate depiction of reality today, but that's not what they were originally invented for. Computers were intended to assist people. As the early (1930s-40s) promotional material would say, "to come to the aid of mankind". The whole point of a computer is to be useful to its users, so arguing against that is just nonsense. This discussion item is full of other comments stating exactly what sort of work they use a computer for, and how they are being affected by useless changes.

Most people take it for granted just how stable a lot of other things --- also invented to help them --- they use on a daily basis are. Imagine if every few years, your toilet, sink, bathtub, light switches, power sockets, door and window handles/locks, lightbulb sockets, and home appliance controls changed in such a way that you had to completely relearn how to use them and without some functionality they had before, and all for totally BS reasons like "development of a platform and technical progression".

As is "supporting everything ever implemented in perpituity"...

Some things just don't ever need to change.

>What are computers for? "To control and force users to consume mindlessly"

Nonsense. I never suggested that. What I am suggesting is that whining about progress (especially when it has been known to have been deprecated for at least the last 10 years!) and layering technical debt on top of technical debt is stupid. I do agree that somethings don’t need to change, but are absurd, not to mention inaccurate. The many types of different light fittings for example are evolving. Somewhat more slowly than computing, I grant you. The same is true for locks and light switches are being developed too. Your comment about home appliances is By far the most ludicrous. I do take issue with your notion that things in Catalina have changed to the extent that they need to be relearned. Bullshit.

> If I had to go and "fix" all my utilities every few years* because a new OS broke something that was working before, I would have less time for actual new developments.

Welcome to the life of a Mac developer.

*year

>There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware.

I think part of the idea is (and how they see it), if you buy into Apple, you should have enough spare money to upgrade your hardware as needed. This sucks for us which are not exactly affluent, but that's part of the thing. Apple never tried to maximize affordability or expenses.

(Though in some cases, they have been the more affordable of the bunch, e.g. when the iPad was announced, it took about 2 years for competitive machines to reach price parity. Or now, e.g. the newly announced MS earbuds are more expensive than airpods).

It's not a platform for long term support and maximum bang for the buck, it's a platform for user convenience ("it just works, mostly"), inter-operation ("things -phone, earbuds, speaker, watch, etc- just work together, mostly"), and cohesiveness ("things have a unified vision, mostly"), plus polish (thinking some things more through in their design -- not always though, e.g. BS MBPr keyboard).

I use "mostly" above in the sense that it's not obviously perfect (and some areas far from it). But the tradeoff is in the areas mentioned above.

This is only on 32-bit versions of Windows 10. Which I can only imagine is a very small portion of W10 installs.

fwiw, upgrading to x64 windows killed 16-bit support, I think? But as far as I know that was due to architectural limitations as much as it was an intentional choice. It's still impressive that 16-bit stuff kept working on x86 windows basically forever.

Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. That's just a limitation of the cpu architecture that's just not something you can work around. Dosbox and virtualization however do allow that to still be run if you provide the OS bits (install windows 95 or 3.1 in them), so there's still paths forward that will usually work. If they need to talk to esoteric hardware then you might be out of luck still but it might not be impossible to get that to pass through depending on what it is.

> Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16.

Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code.

I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.

As with a lot of other things, the truth is a bit more subtle than "it's impossible" and closer to "we didn't care enough to try hard enough to make it work":

https://www.dkia.at/en/node/180

http://v86-64.sourceforge.net/

If that v86_64 thing works the way I think it does, it is not really an acceptable way to do this. If you drop the CPU down from long mode to legacy mode and get an NMI, either you are toast or you have some extremely complicated awful code to handle it. Not to mention that the CPU can’t even address all of physical memory when you do this.

Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.

Honestly kind of surprised they didn't just build a subtle Windows 3.1 wrapper that would launch to run 16-bit apps, combining the view-of-the-system virtualization approach of WOW64 with ABI translation ala Rosetta.

Windows NT setup programs were traditionally 16-bit because every version of NT could run 16-bit x86. The non-x86 variants (alpha, mips, etc.) had built in emulation.

So Microsoft has already got the ability to run 16-bit Windows apps in emulation. It's a shame they didn't enable this on x86-64.

Quinn is 32bit! Oh no! Best macOS Tetris-like game around.

I’ve also been wondering about Dymo label printers. I haven’t seen anything when I searched - if anyone knows, I’d like to learn!

Maybe not much help to you, but my Rollo Thermal Label Printer works fine on Catalina. Didn't need to update any drivers, it just works as it did before the update.

Same here. My Canon scanner is not going to work any longer.

And Canon is notoriously bad at updating their drivers, so my scanner will now be a brick.

VueScan to the rescue, it supports scanners from the 90s and is also a very good scanning app to boot.

VueScan works, but it is stupidly bloated compared to the macos native scan tool.

I remember how it was so easy to scan directly to multi-page PDF with my Brother portable scanner. The Apple build in capture software was just so easy and clean to use. Then Apple removed TWAIN support in snow leopard, and suddenly my 2 month old 400 euro scanner was no longer usable. :(

Reply on news.ycombinator.com