There is a win 3.1 port for wider screens that do box will run

86Box runs on modern MacOS, but is not very performant for games on ARM.

https://github.com/86Box/86Box

There are also patch sets available for modern PCs to support legacy MSDOS, and Windows 3.1/95/98/ME. Attempting to install/run on modern hardware will usually blue-screen without the workarounds. =3

https://github.com/JHRobotics/patcher9x

> Nothing obsolete about DOS when it comes to playing 2D games.

Until you want better graphics, network, touch support, etc, etc.

Some people may not want that; and there are workarounds, even in dosbox itself; still, they are just that.

The page lists similar plans in FAQ: “To add additional functionalities (features) to the game (like online gaming, scalable HQ Grahics, HQ Audio, plugins, etc.).”

What I like about DOSbox are its constraints and limitations.

Of course there plenty of good features missing but on the other hand that’s the point.

Why start in 2d when in reality you want a 3d game?

DOSbox is delivering constraints.

The demo scene died when the constraints were gone and all that was left was showing a movie. On a C64 for example there are no animations per se but maxing out technical prowess combined with design. If it matches optimally it will make you marvel otherwise not so much.

So there is no right or wrong only what do you want?

> The demo scene died when the constraints were gone

The problem was in my opinion not that the constraints were gone, but the fact that the PC did not provide a very stable platform anymore on which you could do some crazy low-level optimizations.

Building stable software for all varieties of PC hardware was part of the challenge of course. Lots of demos had problems with all kinds of hardware varieties.

Lots of low-level optimizations also made their way into compilers that sometimes do a better job than a human. There's not much to be gained by writing everything in assembly which means it doesn't interest people as much as in the 90s.

> There's not much to be gained by writing everything in assembly which means it doesn't interest people as much as in the 90s.

There is a lot to be gained from writing your code in a way that makes use of SIMD instructions. Also, a lot of things that you can write in assembler code is insanely hard to express in higher-level languages, so of course

- the compiler may implement some specific low-level optimization

- but the compiler can (in general) not easily change the programming language so that low-level programming tricks can (without "contortions") be formulated in the programming language.

I agree that if the compiler was "allowed" to change the (higher-level) programming language, too, by quite a lot, so that quite a lot of low-level programming tricks can be formulated or much better formulated in it, then I would somewhat agree that the advantages of low-level coding have become smaller.

But this is currently clearly not the case.

I'm the author of OpenCiv1 project. The main point of such project is to fix the bugs and to provide additional features. Also, there are multiple live discussions on Civ Fanatics Forums on how to modify Civ1. The people still have endless creativity for Civ1 and this is the way to give it to them :)

You can also run the original on an Amiga emulator (or an actual Amiga, like me).

I bought some DOS games wrapped in DOSBox on GOG, and I'm not sure if GOG uses some bad version or bad config, but it's pain the the ass - you can't resize a window to be able to actually see something on 4k screen, no obvious way to switch to fullscreen and back, etc.

It's one thing to be able to emulate DOS games (something which worked 20+ years ago), it's another thing to offer reasonable ergonomics in a modern environment...

Yeah this is key - in order to get out of full-screen you have to find and navigate some some ini file, then its still doing the mouse capture thing, which I think is also a setting, but all this faffing about just to get it into a usable state is pretty user hostile

I want the window to be open like any other window, and the mouse pointer to work transparently in and out of it - like when I hover the mouse over the dosbox window, change the pointer but keep the same mouse speed, momentum etc

I think this would be really hard to do in an emulated environment, maybe even would require patching each game executable to get the mouse speed right (not sure?), the modern environment integration, like you say, is what Im after too

I run the GOG installer, then copy the game files to where the virtual C: is for my DOSBox-X (in a git-repo). Then there is usually some small BAT script to write to launch the game (what is required can be figured out from the config GOG installed). I play all the games from within DOSBox-X, so I start that up in fullscreen and then run games as if running real DOS (from COMMAND.COM prompt).

It is of course possible to launch games from outside of DOSBox the way GOG does it, using host OS (non DOS) launch scripts and config for each game, but I prefer to have more like a virtual DOS fantasy console with all games installed. It also means DOSBox is fully self-contained, with no dependencies on the host OS. Once set up there is no maintenance. There is no code rot in DOS of course, so when something has been set up it will always work.