| 24 May 2026 |
 emily | slimming it down to the core ISA emulation because Wine already handles adapting the system APIs makes a lot of sense from a reducing maintenance burden perspective too | 18:58:50 |
 Randy Eckenrode | Apple seemingly caring about old games is unprecedented. | 18:58:54 |
| emily | I think the difference is that Apple has already killed off half of the old Mac games with Catalina… | 18:59:27 |
| Randy Eckenrode | What I want to know is how games that are still x86_64-only like Stellaris are going to work. I’ve got a bunch of Mac games that never got ARM64 ports. | 18:59:34 |
| emily | whereas they can't force Windows devs to do anything | 18:59:37 |
| Randy Eckenrode | Yeah, but who cares about that? | 18:59:54 |
| Randy Eckenrode | Having a special carve out for Windows but not for Mac games would be a really developer-hostile thing to do. | 19:00:19 |
| emily | I don't know. "Intel-based frameworks" is super vague, I hope we hear more about it at WWDC but I doubt it since it's not due for macOS 27. | 19:00:40 |
| Randy Eckenrode | It would be good to know so people could start planning. | 19:01:02 |
| emily | it's possible they'll do something more like the Windows ARM64EC where the system frameworks will be AArch64-only. I'm not sure though, that would be a substantial amount of investment into something they're trying to kill off. | 19:01:02 |
| Randy Eckenrode | Like if they do Mac games, and Paradox releases a Stellaris update, will it stop working because that’s technically not an older, unmaintained game? | 19:01:21 |
| emily | I think you can somewhat reasonably read "Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks." as "we have a line of contact with CrossOver and they screamed at us about what killing support for the long tail of Windows apps would do". | 19:01:44 |
| emily | tbh I doubt they'll actually try and condition on that. an unmaintained game can't really use a special codesigning entitlement or whatever by definition. | 19:02:31 |
| emily | I think the implication is more "no fancy new APIs are coming to x86 code" | 19:02:48 |
| emily | anyway, this uncertainty plus my expectation that it will be resolved in the coming year is why it seems like not a totally terrible idea to just see if we can keep x86-64 Wine limping along for now :P | 19:03:24 |
| emily | the closure is not very big and I'm confident we can shrink it. I don't think anything I've poked at cleaning up along the way would get meaningfully more of a pain by carving that out specifically. the macOS 26 SDK is going to stick around more than long enough. the most pain I can envision is perhaps the relevant subset of the source releases used in the build process giving us headaches, but I think we could cut our losses and let it break when we run into that. cross from aarch64-darwin would also avoid that | 19:05:33 |
| Randy Eckenrode | Apple could only allow games with specific signatures to work. | 19:05:38 |
| Randy Eckenrode | No idea though given how unprecedented this is. | 19:06:13 |
| emily | sure. I mean, anything's possible :) it would be funny if they treated unsigned code as worse than ancient signed code for that, but… | 19:06:29 |
| emily | anyway, if you think we should just drop the support completely I'm okay deferring to your judgement call as the one who maintains and uses the package much more than me. (I do love just removing things and hate dealing with compatibility!)
I just figure that it's rather likely that by 27.11 we'll have a way to do native AArch64 Wine for running x86 apps, and that a few hours of Hydra build time and a handful of packages that can't drop some trivial x86 conditionals until it becomes too painful is maybe a reasonable price to pay for now to not have a ~year where people can't get Wine from Nixpkgs. especially if trimming down the closure and doing cross works, which I can look into. | 19:09:14 |
| emily | FWIW I expect that people who have actual lines of contact with Apple already know some details here. | 19:10:48 |
| emily | like I'd guess CodeWeavers know what's going to happen but are just under NDA about it. | 19:11:01 |
| emily | plausibly the same for a bunch of game devs. | 19:11:10 |
| Randy Eckenrode | I’m not against keeping it. How long does it take Hydra to build a stdenv? stdenv + Wine would be about double that AFAIK. | 19:14:32 |
| emily | on the order of hours I think. but if we use pkgsCross then we don't actually need to build an LLVM or any of the nativeBuildInputs | 19:18:12 |
| emily | so substantially less and we can drop much more. | 19:18:20 |
| Randy Eckenrode | Wine can't be cross-compiled due to Python. | 19:29:15 |
| Randy Eckenrode | * | 19:30:14 |
| Randy Eckenrode | I tried that for FFXIV in my configs. I don’t know if Wine specifically requires it or something in its dependencies. Python doesn’t support Darwin cross at all. There’s an issue for it that’s well over a decade old at this point. | 19:33:03 |
| emily | the Wine derivation at least only uses Python at compile time | 19:35:57 |
