Hacker News Reader

Comment by TheTon | Hacker News Reader

But games are full fledged GUI apps. At a minimum they have a window.

It’s really unclear what it means to support old games but not old apps in general.

I would think the set of APIs used by the set of all existing Intel Mac games probably comes close to everything. Certainly nearly all of AppKit, OpenGL, and Metal 1 and 2, but also media stuff (audio, video), networking stuff, input stuff (IOHID etc).

So then why say only games when the minimum to support the games probably covers a lot of non games too?

I wonder if their plan is to artificially limit who can use the Intel slices of the system frameworks? Like hardcode a list of blessed and tested games? Or (horror) maybe their plan is to only support Rosetta for games that use Win32 — so they’re actually going to be closing the door on old native Mac games and only supporting Wine / Game Porting Toolkit?

View on HN

Games use a very small portion of the native frameworks. Most would be covered by Foundation, which they have to keep working for Swift anyway (Foundation is being rewritten in Swift) and just enough to present a window + handle inputs. D3DMetal and the other translation layers remove the need to keep Metal around.

That’s a much smaller target of things to keep running on Intel than the whole shebang that they need to right now to support Rosetta.

I don’t agree. My point is their collective footprint in terms of the macOS API surface (at least as of 2019 or so) is pretty big. I’m not just speculating here, I work in this area so I have a pretty good idea of what is used.

Could you give examples at least of what you think that big collective footprint might include?

Bear in mind that a large chunk of Mac gaming right now that needs translation are windows games translated via crossover.

As I said in my first comment, it's at least Cocoa (Foundation + AppKit), AVFoundation, Metal, OpenGL, and then all of the lower level frameworks and libraries those depend on (which may or may not be used directly by individual games). If you want a concrete example from something open source, go look at what SDL depends on, it's everything I listed and then some. It's also not uncommon for games to have launchers or startup windows that contain additional native UI, so assume you really do need all of AppKit, you couldn't get away with cutting out something like NSTableView or whatever.

So my point remains, if Apple has to continue providing Intel builds of all of these frameworks, that means a lot of other apps could also continue to run. But ... Apple says they won't, so how are they going to accomplish this? That's the mystery to me.

With the exception of AVFoundation, I’d covered all of those in my comments. That’s not a lot of surface area. Games are typically not using a significant portion of AppKit beyond what I already mentioned, and AVFoundation is likely also a very thin wrapper that is maintainable.

I’m assuming Apple isn’t going to arbitrarily restrict what runs but will remove things to just the subset that they believe are needed for games such that other stuff just implicitly won’t work.

Is it practical for Apple to produce a set of frameworks for Intel that run some useful set of old games but that do not run any useful set of non game software?

I grant it’s probably possible to do, but I think that is a lot more work and more error prone than just continuing to ship the major frameworks as they were.

From Apple’s perspective I’m sure they have a few big goals here:

1. Encourage anyone who wants to continue offering software on Mac to update their builds to include arm64.

2. Reduce download size, on disk size, and memory use of macOS.

3. Reduce QA burden of testing ancient 3rd party software.

These are also the same motivations Apple had when they eliminated 32 bit Intel and when they eliminated Rosetta 1, but they were criticized especially for leaving behind game libraries.

Arguably, arbitrarily restricting what runs gets them the biggest slice of their goals with the minimum work. Devs are given the stick. People typically only play 1 game at a time and then quit it, so there isn’t a bunch of Intel code in RAM all the time because of a few small apps hanging out, and they have less to test because it’s a finite set of games. It just will chafe because if they do that then you know that some unblessed software could run but Apple is just preventing it to make their lives easier.

> Is it practical for Apple to produce a set of frameworks for Intel that run some useful set of old games but that do not run any useful set of non game software?

They already have the frameworks supporting intel. They can just start pruning away.

Some teams will draw the short straw of what needs to continue being supported, but it’s likely a very small subset of what they already maintain today.

If you'd like to see an interesting parallel, go look at how Microsoft announced supporting DirectX 12 on Windows 7 for a blessed apps list - basically because Blizzard whined hard enough and was a big enough gorilla to demand it.

That's one implementation, yeah, just have a list somewhere of approved software and make an artificial limitation. But their announcement is so vague, it's hard to say.

And then the next question is why? It's not like they've ever promised much compatibility for old software on new macOS. Why not let it be just best effort, if it runs it runs?

Reply on news.ycombinator.com