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.
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.
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.
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.
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?
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 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.
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.
>install DOSBox for Mac
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
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.
> there are DOSBox forks, most popular one would be DOSBox-X
Straight from the article:
> there are actively developed alternatives like DOSBox-X
> Mind you there are countless DOSBox forks out there and the vanilla original one is probably the least interesting one.
What do you want to be "interesting" about dosbox?
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.
[0] https://bad-sector.itch.io/post-apocalyptic-petra
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!)
I believe Dosbox-X had native Apple Silicon support…at least it has an Apple Silicon installer.
Read what the others offer
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.
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.
The Slirp backend for the NE2000 networking driver is the big one for me.
> What do you want to be "interesting" about dosbox?
Quality of life improvements? Expanded (experimental) hardware support?
This seems like a good place to mention boxer for macos. Sadly discontinued in 2016
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.
Heroic Launcher makes it even simpler, also for non-DOS Windows games (both very old and newer) - https://heroicgameslauncher.com/
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.
But I wonder if Heroic can install HoMM2 on a Mac if no Mac binary is available on GOG.
How so? I don't think heroic can install a native DOSBox when the game ships a windows DOSBox. Or was that added recently?
Apparently (<https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher...>) Heroic supports launching games with DOSBox Staging or ScummVM.
Heroic Launcher is awesome on the Steam Deck
This is why Rosetta 2's looming retirement sucks.
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.”
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.
> Retro gaming
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...
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.
Apple is dogmatically anti games, they only spare bare minimum of effort to support videogames as an necessary evil. It's some Jobs' teaching thing.
gaming apps account for approximately 70% of all App Store revenue.
On the iPhone, where they go out of their way to prevent Steam or anyone else eating into that market.
On Mac it's probably closer to 0% of all revenue, and they seem incapable of competing for it.
Of course, I agree. Just saying I think they probably do have to care about the gaming market a whole lot, whether Jobs liked it or not
They tried, but didn't follow through. macOS is corporate abandonware and they don't want to undermine their iOS market with real emulators.
That's an "I'll believe it when I see it working on my machine" matter.
As my sibling post says, it's more likely to work only for some older mac os native games.
I'd expect the exact opposite.
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.
Is there an actual reason for it, apart from Apple hurrying devs along?
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…
Apple has historically always been about pushing devs forwards and dropping support for legacy systems.
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.
The Apple Silicon dev kit shipped in 2019 and the cutoff date is 2028, so it's a pretty mild form of hurry.
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.
That’s probably the sensible route… No use being idealistic about these things, public companies aren’t known for their sentimentality after all :)
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 :(
I imagine that the area it takes up on the chip is non-trivial and so it'd cost them a ton to continue to have it.
I thought Rosetta 2 was a purely software layer
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.
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
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.
Those are still needed for the Rosetta use-cases that are sticking around (old games, Linux binaries)
It’s software.
I thought dosbox had its own x86 emulation layer so it should work fine on any arch?
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.
https://github.com/joncampbell123/dosbox-x
Wow that brings back some memories, but I was playing those games on a 386 running them on any hardware from this century must be absolutely trivial.
Oh yeah for sure. I used to play Commander Keen, Cosmo's Cosmic Adventure, Major Stryker, etc. though it was on a 486 SX 25 MHz back in the day too!
Enjoy paying for your yearly Adobe subscription as your shrink wrap software won’t work.
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.
Buy a gaming desktop PC my guy. Great performance, no cooling issues. Even pre-builts are somewhat good now.
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.
1 boxerapp.com
Boxer was wonderful in its day, I think it also became the basis of the official GOG Mac DOS game releases for a while too:
> 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
Check out boxer-plus
https://github.com/Solid7s/Boxer-Plus
4 commits all in April. Needs some more love & time.
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.
Thanks, I’ll check it out
its back https://github.com/Solid7s/Boxer-Plus
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?
Dosbox-X has network support via NE2000 drivers.
Ooh, that is really great to know - thank you! I will start with that first ..
at this point, considering ppl have gotten classic MacOS to run in the browser, maybe that will be the future at some point...
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/)
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.Is it really necessary to first install and copy from a Windows machine?
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).
I wouldn’t be surprised if 7-zip can extract the files from the installer if the installer is not a custom thing.
You could use heroic launcher to install the game, and then run it through the DOSBox you manually installed.
Or run the installer in Wine/Proton.
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.
You could try https://github.com/dscharrer/innoextract (installable via homebrew).
I wondered if innoextract was Linux only, but I see there is a homebrew formula. https://formulae.brew.sh/formula/innoextract
Is the author reading hackernews?
That, or just run it with wine.
Interestingly, wine works on Apple Silicon via Rosetta2 so I guess it won't work by macOS 28, and we will be only left with arm64 DOSBox-X.
... and arm64 innoextract hopefully
There was a tool that would take a GOG installer and extract it.
https://www.macsourceports.com/utility/extractor
If this works I wonder why GOG doesn’t do it automatically.
gog does do this - many classic games are already wrapped in dosbox.
The thing I've noticed is that many games are wrapped in different versions, like older versions for older games, etc.
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.