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.
HelloUsername 1 days ago [-]
> there are DOSBox forks, most popular one would be DOSBox-X
Straight from the article:
> there are actively developed alternatives like DOSBox-X
pezezin 16 hours ago [-]
Indeed. My favourite one is DOSBox Staging due to the built in CRT emulation, it gets the feeling very close to the original displays of the era.
thaumasiotes 1 days ago [-]
> 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?
badsectoracula 1 days ago [-]
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!)
sunnybeetroot 16 hours ago [-]
Many apps are showing this warning, likely because they include a slice of the deprecated architecture even though they do have Apple silicon.
themadturk 21 hours ago [-]
I believe Dosbox-X had native Apple Silicon support…at least it has an Apple Silicon installer.
haunter 1 days ago [-]
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.
TonyTrapp 21 hours ago [-]
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.
derefr 1 days ago [-]
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.
nsxwolf 1 days ago [-]
The Slirp backend for the NE2000 networking driver is the big one for me.
parl_match 1 days ago [-]
> What do you want to be "interesting" about dosbox?
Quality of life improvements? Expanded (experimental) hardware support?
grobibi 1 days ago [-]
This seems like a good place to mention boxer for macos. Sadly discontinued in 2016
edit: I think it has apple silicon support. I am getting mized messages when I look it up.
19 hours ago [-]
nihilismislove 1 days ago [-]
Heroic Launcher makes it even simpler, also for non-DOS Windows games (both very old and newer) - https://heroicgameslauncher.com/
univocal 1 days ago [-]
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.
f055 1 days ago [-]
But I wonder if Heroic can install HoMM2 on a Mac if no Mac binary is available on GOG.
CodesInChaos 23 hours ago [-]
How so? I don't think heroic can install a native DOSBox when the game ships a windows DOSBox. Or was that added recently?
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.”
It's the Mac native x86 software that hasn't been updated in most of a decade that would be affected.
benoau 1 days ago [-]
> 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.
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.
numpad0 22 hours ago [-]
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.
iknowstuff 21 hours ago [-]
gaming apps account for approximately 70% of all App Store revenue.
numpad0 5 hours ago [-]
Gambling apps. Extremely few of the "games" on App Store are traditional games. Most of them are lootbox puzzle slop because that's what Apple tolerates && most lucrative.
benoau 19 hours ago [-]
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.
iknowstuff 18 hours ago [-]
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
cyberax 19 hours ago [-]
They tried, but didn't follow through. macOS is corporate abandonware and they don't want to undermine their iOS market with real emulators.
nottorp 1 days ago [-]
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.
cosmic_cheese 21 hours ago [-]
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.
Cassell 1 days ago [-]
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…
fckgw 1 days ago [-]
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.
GeekyBear 1 days ago [-]
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.
Cassell 21 hours ago [-]
That’s probably the sensible route… No use being idealistic about these things, public companies aren’t known for their sentimentality after all :)
zokier 1 days ago [-]
I thought dosbox had its own x86 emulation layer so it should work fine on any arch?
f055 1 days ago [-]
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.
vunderba 24 hours ago [-]
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.
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.
vunderba 22 hours ago [-]
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!
smith7018 1 days ago [-]
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.
chii 1 days ago [-]
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).
ryandrake 1 days ago [-]
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 :)
smith7018 1 days ago [-]
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 :(
fragmede 1 days ago [-]
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.
rimunroe 1 days ago [-]
I thought Rosetta 2 was a purely software layer
fwip 1 days ago [-]
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.
icelusxl 23 hours ago [-]
> 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.
mrpippy 1 days ago [-]
Those are still needed for the Rosetta use-cases that are sticking around (old games, Linux binaries)
wat10000 1 days ago [-]
It’s software.
ptek 1 days ago [-]
Enjoy paying for your yearly Adobe subscription as your shrink wrap software won’t work.
a1o 1 days ago [-]
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.
Scroll_Swe 20 hours ago [-]
Buy a gaming desktop PC my guy. Great performance, no cooling issues. Even pre-builts are somewhat good now.
lastdong 1 days ago [-]
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
giobox 1 days ago [-]
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:
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...
4 commits all in April. Needs some more love & time.
1313ed01 1 days ago [-]
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?
fragmede 1 days ago [-]
Dosbox-X has network support via NE2000 drivers.
rigonkulous 1 days ago [-]
Ooh, that is really great to know - thank you! I will start with that first ..
vifly_net 2 hours ago [-]
learn a lot and get a lot of old memory too
simscitizen 16 hours ago [-]
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.
vunderba 12 hours ago [-]
I've seen JS-DOS used for id software stuff like DOOM so I think it's plenty capable.
The person who created js-dos runs https://dos.zone as well which has a bunch of abandonware running on the browser.
47282847 1 days ago [-]
Is it really necessary to first install and copy from a Windows machine?
1313ed01 1 days ago [-]
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).
bananaboy 19 hours ago [-]
I wouldn’t be surprised if 7-zip can extract the files from the installer if the installer is not a custom thing.
CodesInChaos 22 hours ago [-]
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.
f055 1 days ago [-]
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.
at this point, considering ppl have gotten classic MacOS to run in the browser, maybe that will be the future at some point...
p0w3n3d 22 hours ago [-]
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.
haberman 1 days ago [-]
If this works I wonder why GOG doesn’t do it automatically.
m463 24 hours ago [-]
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.
jmyeet 23 hours ago [-]
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.
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?
The person who created js-dos runs https://dos.zone as well which has a bunch of abandonware running on the browser.
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.