I like DOSBox pure, because that allows you to put the full games into a single zip file and so you then essentially have the equivalent of per-game file on consoles.
Last time i checked (and DOSBox hasn't made an official release since then) the vanilla DOSBox isn't able to run the game i made for an MS-DOS game jam a few years ago[0] because it doesn't implement RDTSC properly (that the game uses for timing). All currently developed DOSBox forks work properly.
Also the forks add some additional niceties, e.g. DOSBox Staging has some very nice CRT filters that basically make games look almost like the real thing (i have some actual CRTs to compare). DOSBox-X has a GUI to setup options while the emulator is running which is very convenient.
If I'm reading the article right, they are saying that macOS is giving the scare warning on it - this implies that DOSBox is an x86_64 binary and not ARM native.
If true, that implies development is on life support at best, since any actively-developed project targeting Mac OS would likely have shipped an ARM version within 6 years of the ARM transition.
So anyone who wants to ever run Mac OS 27 or buy a Mac after next year will probably have to find an alternative (or port DOSBox mainline to ARM themselves!)
The last significant DOSBox update (ignoring 0.74-3 which was not significant) must be over 10 years ago by now. In that time, forks like DOSBox-X have made tremendous progress in compatibility and accuracy. The original DOSBox is essentially frozen in time at this point, with many things not being emulated correctly.
Same thing I'd want to be "interesting" about any emulator. Focusing on just graphics for a moment (but there are equivalent examples in other domains):
1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, by calling the game's own rendering logic more frequently than the original hardware could "afford" to, but without breaking game logic (i.e. by forcibly decoupling the game's physics ticks from its presentation ticks);
2. Using out-of-viewport but in-{tile/frame}buffer data to expand the viewport to fill my screen (which can be very janky under some rendering paradigms, due to offscreen parts of tile/frame buffers being dynamically partial-updated with a loading seam; but which can work very well under other rendering paradigms, like the SNES's mode 7 where the tilemap was usually just fully populated once at mode-switch time);
3. Making games that used vector-graphics for at least part of their display, and soft- or hard-rasterized those vector graphics into the native low-resolution framebuffer, instead rasterize those graphics at my display's native resolution;
4. having the emulator recognize particular bitmap assets (tiles, sprites, 3D meshes/textures) the game is telling it to render, and swap these out for hand-crafted HiDPI / high-poly versions of those assets from an asset-pack file (as opposed to relying on the caprices of a DLSS-like upscaling model.)
Mind you, to have features like this work well, they often leave the realm of "interpreting the control-register pokes from the game differently", and enter the realm of "the game being patched to take advantage of the capabilities of the emulator." Then, as with these GOG games, you're no longer just shipping a ROM "and an emulator configured to run it well"; rather, you're shipping a co-designed product: an emulator tuned to run that ROM, and a ROM tuned to run in that emulator.
---
By doing this, you technically leave the realm that MAME-like "archival preservation" emulation usually aims for, of "faithful emulation" of both a game's logic and its presentation.
However! "Faithful emulation" folks shouldn't despair. The nice thing about this technique, is that this is all done by wrapping the original ROM in an emulator + shipping runtime-applied IPS patches.
In other words, the original game ROM is still there, unmodified, under an "isolation layer"; and everything being done to modify it is done using "reversible, conservation-grade" techniques.
Which means the emulator can provide a launcher UI to turn any of those presentation "enhancement" features on-and-off. If you're the "faithful emulation" type, you can just turn them off!
(And, under this paradigm, even with the "enhanced emulation" features on, the game logic is still preserved as-is; you're only modifying the presentation. The original game engine is still running; the original instructions are still executing cycle-accurately to how they should. So the "game feel" is preserved perfectly. If you were good at the original game, you'll still be good at playing an "enhanced emulation" of the game; nothing will be "off" about it. Even input movies recorded against the un-enhanced game should replay unmodified against the enhanced game!)
Contrast this to the average "HD remaster", where the game is at the very least recompiled for a new platform (with different timing guarantees), if not entirely rewritten atop a new engine. In that process, there's no "isolation layer"; no way to guarantee a preservation of any part of the original game logic in the remastered artifact. And like George Lucas, game developers coming back to their own works 20–40 years later, just can't help but want to tweak things. So these HD remasters end up breaking "game feel" in all sorts of ways.
I have to admit, I've tried using Heroic Launcher both on macOS and on a Steam Deck and in both cases the experience has been rather frustrating. Maybe I was just unlucky, but any game I tried was broken in a way or another, or stopped working with no clear explanation (weird segfaults at start) just a few days later.
I've tried GOG DOS Games, GOG Windows Games, Steam Games under Proton, nothing was particularly usable.
Got the very same games working under Faugus Launcher and Dosbox-X. The UX is a bit worse but my games run without any issues, and I've stuck with those since then.
x86 gaming and running x86 Linux software are the exceptions.
> Starting with macOS 28, Rosetta 2 will be largely discontinued. Apple says that after that point, it “will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”
What they say is "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks" which sounds like OS X games. But even if it is all-inclusive "retro" games, that means the 1,000s of contemporary games runnable via Crossover through Steam for Windows are being shut out.
They relented under pressure to continue allowing Linux virtual machines, so hopefully they continue to revisit this decision.
Given that they could have easily get Steam Deck levels of compatibility with Windows games, but didn’t, I think they’re mainly after the App Store margins for ported games. Having an independent marketplace with tons of Mac-compatible games is a nightmare for them.
If I'm not mistaken, to keep native titles running, they need to continue to haul around x86 versions of the majority of the system's libraries and frameworks, in which case there's little reason to not continue supporting Rosetta 2 as a whole since the delta between the two library/framework sets is minimal.
To keep games in WINE/CrossOver/etc working all they need to keep around is the x86 translation layer and maybe the x86 slice of OpenGL. Everything else x86 related can be deleted.
Dosbox has its emulator to run DOS, but afaik dosbox binary that starts up dosbox on Mac uses Rosetta on M-series Macs, and without Rosetta it simply won’t start and emulate DOS.
At least the ARM-based binary of DosBox-X (a variant of DosBox) runs natively and works great for everything I've thrown at it like old Apogee games, etc.
I get why Apple wants to remove it but it genuinely sucks. I can't imagine it costs them a lot to put it into maintenance mode and just support 20 years of macOS games and apps going forward. They want developers to fully move to ARM but older titles or software whose developers have moved on/passed will be lost to the sands of time.
If they choose to discontinue it, it would be nice to have them opensource it so that the community could have a go at maintaining it tbh. Surely that's better than letting it rot (both rosetta and the old software that it runs).
That would be ideal, but given Apple's general hostility towards Open Source, it sounds extremely unlikely. I wonder what it would take to re-implement it. If it's "just software," I suppose there is a chance, not that I'm volunteering :)
Apple really isn't as hostile towards OSS as people think. With that being said, the reason to discontinue Rosetta 2 is to push developers to upgrade their software. Allowing others to continue using Rosetta 2 by way of 3rd party maintainers works against that goal :(
Rosetta 2 is software, but there are design decisions made for the M-series chips that are specifically made to improve the ability of Rosetta to work in a performant way. The main one I'm aware of is the x86-TSO memory-ordering mode - most ARM chips don't support this, but the M-series have it so that Rosetta can toggle it on for x86 emulation.
I'm not sure what the total cost of these are, but it's not zero.
> There are only a handful of different instructions that account for 90% of all operations executed, and, near the top of that list are addition and subtraction. On ARM these can optionally set the four-bit NZCV register, whereas on x86 these always set six flag bits: CF, ZF, SF and OF (which correspond well-enough to NZCV), as well as PF (the parity flag) and AF (the adjust flag).
> Emulating the last two in software is possible (and seems to be supported by Rosetta 2 for Linux), but can be rather expensive. Most software won’t notice if you get these wrong, but some software will. The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
There's another big one, 4K page support. The MMU can be told to set up a virtual address space with smaller, x86-compatible 4096-byte memory pages instead of the default 16384-byte pages.
This would be very bad for Wine too. I think Wine has some answer to this, since Wine does run on Android, but I think it won’t make the current easy path that is just brew install wine and be done.
My favourite project to run these old games was Boxer (1). Based on dosbox, it creates a runnable self contained disk (app) for each game or set of games / software. It is pretty neat, but I am not sure if it has been maintained recently.
I've hoped for years someone would pickup the source and get it going again, it's essentially abandonware right now, no changes in nine years. The website is like a time machine back to the peak skeuomorphic mac app era. It still has the nicest UX of any of the DosBox variants I've tried. In this era of agentic rewrites, modernizing this app is probably the cheapest it has ever been too...
I do the opposite and put all games together, with DOS BAT-files to launch the games. I boot up my virtual dream DOS machine by just starting DOSBox-X and then I launch the games the way they are meant to be launched, from the DOS COMMAND.COM command-line. And as I mentioned in another comment, all of that is in one big DOS git repo.
Nice thing with DOSBox-X is there is a built-in command to set config parameters, so for games that require special settings or to slow down etc that can be set up from its launcher BAT file. All games share the same dosbox config file with default settings.
I'm not sure if this works well for more demanding games, but recently I wanted to let my kid play Number Munchers and Oregon Trail and just built a webpage for those games using js-dos. It worked well enough for those games.
This is awesome, and I can't wait to have the time to set this up and install my GOG library .. but one thing has been bugging me for a long time about my GOG library, and that is: local multiplayer network gaming was awesome then.
So .. is there going to be any chance of getting multiplayer networking setup for some of the GOG's? Has anyone accomplished this in the DOXBox-*'en .app'o-sphere yet?
I never had any issues using WINE to install GOG games, but maybe running WINE on a Mac is not as easy now as it was back when I did that on a x86 Mac?
I always run the GOG installer in WINE and then copy the game into my git repo for DOS stuff, make sure the game works, git commit it, and then I know it will always just work and I will not have to think about that again (plus I can version manage all settings and save-games for all the games and also sync between my different machines without relying on any cloud service).
Hmm i guess this would require figuring out how to extract game data from an .exe installer GOG distributes. I guess AI would figure it out in like 3 minutes ;) I’ll check later.
Numerous games avaiable on GOG are playable via ScummVM. Just install it on Mac and download the installer. This includes my beloved Monkey Island series including 1,2,3 and you might try 4 (status Bugged on https://www.scummvm.org/compatibility/)
<ADVERTISEMENT>
and other great titles like Gobliiins, Police Quest, King's Quest, Leisure Suit Larry, Indiana Jones, Sam & Max hit the road, The Day of The Tentacle and many many more.
I really respect all the work done by enthusiasts to, for example, make DOS games work on other OS as well as all emulators more generally.
Obviously all these binaries can be decompiled into assembly. I really think this is somewhere where Claude can do a lot of heavy lifting to reconstruct source code in a higher-level language that can then be built into something that can run natively on other platforms. AI might be able to do that work directly too.
Now this might have some legal issues. Emulation and recompilation (with distribution) are fundamentally different (legally speaking). Still, it'd be a nicer solution.
Mind you there are countless DOSBox forks out there and the vanilla original one is probably the least interesting one.
Nowadays the three most popular one would be DOSBox-X, DOSBox Pure, and DOSBox Staging
https://dosbox-x.com/ https://github.com/joncampbell123/dosbox-x
https://schelling.itch.io/dosbox-pure https://github.com/schellingb/dosbox-pure-unleashed/
https://www.dosbox-staging.org/ https://github.com/dosbox-staging/dosbox-staging
Straight from the article:
> there are actively developed alternatives like DOSBox-X
What do you want to be "interesting" about dosbox?
Also the forks add some additional niceties, e.g. DOSBox Staging has some very nice CRT filters that basically make games look almost like the real thing (i have some actual CRTs to compare). DOSBox-X has a GUI to setup options while the emulator is running which is very convenient.
[0] https://bad-sector.itch.io/post-apocalyptic-petra
If true, that implies development is on life support at best, since any actively-developed project targeting Mac OS would likely have shipped an ARM version within 6 years of the ARM transition.
So anyone who wants to ever run Mac OS 27 or buy a Mac after next year will probably have to find an alternative (or port DOSBox mainline to ARM themselves!)
GUI config, load games from zip and image files, controller support, save states, various sound, graphics, and network enhancements etc.
There is more to this than simply being a DOS emulator.
1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, by calling the game's own rendering logic more frequently than the original hardware could "afford" to, but without breaking game logic (i.e. by forcibly decoupling the game's physics ticks from its presentation ticks);
2. Using out-of-viewport but in-{tile/frame}buffer data to expand the viewport to fill my screen (which can be very janky under some rendering paradigms, due to offscreen parts of tile/frame buffers being dynamically partial-updated with a loading seam; but which can work very well under other rendering paradigms, like the SNES's mode 7 where the tilemap was usually just fully populated once at mode-switch time);
3. Making games that used vector-graphics for at least part of their display, and soft- or hard-rasterized those vector graphics into the native low-resolution framebuffer, instead rasterize those graphics at my display's native resolution;
4. having the emulator recognize particular bitmap assets (tiles, sprites, 3D meshes/textures) the game is telling it to render, and swap these out for hand-crafted HiDPI / high-poly versions of those assets from an asset-pack file (as opposed to relying on the caprices of a DLSS-like upscaling model.)
Mind you, to have features like this work well, they often leave the realm of "interpreting the control-register pokes from the game differently", and enter the realm of "the game being patched to take advantage of the capabilities of the emulator." Then, as with these GOG games, you're no longer just shipping a ROM "and an emulator configured to run it well"; rather, you're shipping a co-designed product: an emulator tuned to run that ROM, and a ROM tuned to run in that emulator.
---
By doing this, you technically leave the realm that MAME-like "archival preservation" emulation usually aims for, of "faithful emulation" of both a game's logic and its presentation.
However! "Faithful emulation" folks shouldn't despair. The nice thing about this technique, is that this is all done by wrapping the original ROM in an emulator + shipping runtime-applied IPS patches.
In other words, the original game ROM is still there, unmodified, under an "isolation layer"; and everything being done to modify it is done using "reversible, conservation-grade" techniques.
Which means the emulator can provide a launcher UI to turn any of those presentation "enhancement" features on-and-off. If you're the "faithful emulation" type, you can just turn them off!
(And, under this paradigm, even with the "enhanced emulation" features on, the game logic is still preserved as-is; you're only modifying the presentation. The original game engine is still running; the original instructions are still executing cycle-accurately to how they should. So the "game feel" is preserved perfectly. If you were good at the original game, you'll still be good at playing an "enhanced emulation" of the game; nothing will be "off" about it. Even input movies recorded against the un-enhanced game should replay unmodified against the enhanced game!)
Contrast this to the average "HD remaster", where the game is at the very least recompiled for a new platform (with different timing guarantees), if not entirely rewritten atop a new engine. In that process, there's no "isolation layer"; no way to guarantee a preservation of any part of the original game logic in the remastered artifact. And like George Lucas, game developers coming back to their own works 20–40 years later, just can't help but want to tweak things. So these HD remasters end up breaking "game feel" in all sorts of ways.
Quality of life improvements? Expanded (experimental) hardware support?
https://boxerapp.com/
which was then continued via boxer-plus which adds apple silicon support
https://github.com/Solid7s/Boxer-Plus
edit: I think it has apple silicon support. I am getting mized messages when I look it up.
I've tried GOG DOS Games, GOG Windows Games, Steam Games under Proton, nothing was particularly usable.
Got the very same games working under Faugus Launcher and Dosbox-X. The UX is a bit worse but my games run without any issues, and I've stuck with those since then.
> Starting with macOS 28, Rosetta 2 will be largely discontinued. Apple says that after that point, it “will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”
https://9to5mac.com/2026/02/16/macos-26-4-will-notify-users-...
It's the Mac native x86 software that hasn't been updated in most of a decade that would be affected.
What they say is "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks" which sounds like OS X games. But even if it is all-inclusive "retro" games, that means the 1,000s of contemporary games runnable via Crossover through Steam for Windows are being shut out.
They relented under pressure to continue allowing Linux virtual machines, so hopefully they continue to revisit this decision.
https://developer.apple.com/documentation/apple-silicon/abou...
On Mac it's probably closer to 0% of all revenue, and they seem incapable of competing for it.
As my sibling post says, it's more likely to work only for some older mac os native games.
If I'm not mistaken, to keep native titles running, they need to continue to haul around x86 versions of the majority of the system's libraries and frameworks, in which case there's little reason to not continue supporting Rosetta 2 as a whole since the delta between the two library/framework sets is minimal.
To keep games in WINE/CrossOver/etc working all they need to keep around is the x86 translation layer and maybe the x86 slice of OpenGL. Everything else x86 related can be deleted.
For the consumer, the benefits of backwards compatibility are obvious, but it’s sad that companies don’t see it as a selling point.
Well, we wouldn’t want anyone using their perfectly functional copy of Photoshop CS6 would we…
Their attitude has been "we built new hardware, we built new software, we have the tools to develop for these new systems, adapt or die".
This Rosetta 2 transition is actually a couple years longer that their first PPC -> Intel transition. There's more time to adapt this go around.
If you want to continue to run older software, do what you would do in Windows 11 and spin up VM with an older version of the OS.
I keep a Windows 2000 VM with no network access around just to occasionally play Heroes of Might and Magic 3.
https://github.com/joncampbell123/dosbox-x
I'm not sure what the total cost of these are, but it's not zero.
> Emulating the last two in software is possible (and seems to be supported by Rosetta 2 for Linux), but can be rather expensive. Most software won’t notice if you get these wrong, but some software will. The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
1 boxerapp.com
> https://www.gog.com/forum/general_archive/mac_dos_game_editi...
I've hoped for years someone would pickup the source and get it going again, it's essentially abandonware right now, no changes in nine years. The website is like a time machine back to the peak skeuomorphic mac app era. It still has the nicest UX of any of the DosBox variants I've tried. In this era of agentic rewrites, modernizing this app is probably the cheapest it has ever been too...
> http://boxerapp.com/
> https://github.com/alinebee/Boxer
https://github.com/Solid7s/Boxer-Plus
Nice thing with DOSBox-X is there is a built-in command to set config parameters, so for games that require special settings or to slow down etc that can be set up from its launcher BAT file. All games share the same dosbox config file with default settings.
The person who created js-dos runs https://dos.zone as well which has a bunch of abandonware running on the browser.
So .. is there going to be any chance of getting multiplayer networking setup for some of the GOG's? Has anyone accomplished this in the DOXBox-*'en .app'o-sphere yet?
I always run the GOG installer in WINE and then copy the game into my git repo for DOS stuff, make sure the game works, git commit it, and then I know it will always just work and I will not have to think about that again (plus I can version manage all settings and save-games for all the games and also sync between my different machines without relying on any cloud service).
Or run the installer in Wine/Proton.
Is the author reading hackernews?
https://www.macsourceports.com/utility/extractor
The thing I've noticed is that many games are wrapped in different versions, like older versions for older games, etc.
Obviously all these binaries can be decompiled into assembly. I really think this is somewhere where Claude can do a lot of heavy lifting to reconstruct source code in a higher-level language that can then be built into something that can run natively on other platforms. AI might be able to do that work directly too.
Now this might have some legal issues. Emulation and recompilation (with distribution) are fundamentally different (legally speaking). Still, it'd be a nicer solution.