DOSBox x86 system emulator | Hacker News Reader

DOSBox x86 system emulator

dosbox.com

129 pointsbookofjoe72 comments

If you're a fan of DOSBox, you might like this: http://www.doshaven.eu/

I love the fact that people are still making games for DOS. I've been playing a bit of this: http://www.doshaven.eu/game/ptakovina/ (from 2017!)

Get a GPDWIN2 turbo back to the 80s.

I was going to ask what languages/frameworks they use, but found this easily enough:

http://www.doshaven.eu/programming-tools/

You can also download the Digital Mars C and C++ compilers for DOS here:

https://www.digitalmars.com/download/freecompiler.html

I have to say, the stylesheet for that page is amazing and gives me such nostalgia.

I think that's just BOOTSTRA.386[1] but it's probably the best usage I've seen of it.

[1] https://github.com/kristopolous/BOOTSTRA.386

Allegro + DJGPP does miracles

What's missing is a multitasking library (not sure Allegro offers something to that effect)

You can run DOSBox in your browser, the Internet Archive has a bunch of games emulated that way,

https://archive.org/details/softwarelibrary_msdos_games

Oh my god. It's astounding what becomes possible as we move further into this era when most digital activity gets archived for future mashups and other archaeology.

Here, I released this in 1996:

https://archive.org/details/msdos_Aspetra_1996

I knew people still played it, but I had no idea it had a freaking URL now!

My favorite (mis)use of Dosbox was using it to drive Symate for PLC programming. That let me switch to using a Linux netbook instead of dragging a laptop booted in DOS around a factory.

My notes from the time: https://sites.google.com/site/waspvm/runningsymate374underdo...

Did a similar thing with engraver software (which had a parallel port hardware serial key dongle that DOSBox allowed access to) and a dBASE IV program at a client's factory. Amazing piece of emulation that enables "ancient" code to run forever in small businesses around the world.

Same here, we had some buggy PLC controller software that would only run properly on increasingly hard-to-find old PCs, or more expensive embedded kits, due to timing issues. This was in an electroplating plant so they corroded to the point of needing replacement every year or so. Instead, with DOSBox set to an appropriate clock speed, we could use any commodity PC.

Did something similar for some ancient Clipper apps I had to maintain after migrating to OSX/Linux. It was more practical than dosemu.

I used Dosbox to run a program to upload source code on old GE PLCs in order to covert to new systems. Couldn't have done it otherwise. Long live Dosbox!

DOSEMU is a really good option for this this sort of thing. On github development continues here -

https://github.com/stsp/dosemu2/

Does anyone know why they haven't released a new version going on 8 years now even though it looks like it's been continually worked on according to http://source.dosbox.com/dosboxsvn.txt?

Yes, they are stuck with technical debt which, let's say, they cannot repay.

Therefore further development on it is really difficult. This was stated by the developer in an interview some 5 years ago.

Do you happen to have a link to that interview? I'd love to read about it

not sure if this is the interview OP is referring to, but the timeframe is right: https://sourceforge.net/blog/potm-201301/

What is "technical debt?"

It is a term used by people with hindsight to depict bad decision making in programming that needs a lot of fixing and refactoring later on. And to insinuate they are more cautious.

It doesn't have to be with hindsight, you can forecast technical debt.

So true. Often technical debt is intentionally taken on as a calculated risk to get to market faster with the intention of fixing it later. Fixing it later rarely happens though. In my experience it either ends up being someone else's problem or you just live with it.

It's very hard to avoid tech debt if you're under constant and severe deadline pressure. But I don't consider it at all hard to avoid otherwise. To me, avoiding debt can be summarized as not taking shortcuts. This shortcut would save time right now, but you know its a hack that makes an abstraction leak? Don't do it. You know an approach is going to cause problems down the line, but you just can't think of a better way? Again, don't do it. See if something comes to mind later. Wrote and tested a bunch of code that seems to work, but there's an itch in the back of your mind saying you haven't thought the problem all the way through? Don't check it in. One might think this sort of approach is paralyzing or something, but in my experience it's extremely empowering over the lifetime of a software project.

You act like you always know what will become debt and even then what will become important debt.

We don’t know much. We have to make calls. What can I say? I’m old and I have my heuristics.

https://en.wikipedia.org/wiki/Technical_debt

basically it's when a bunch of bad but seemingly-innocuous coding design decisions accumulate and compound each other multiplicatively over time, to the point that any change of the code is far more likely to break something than the new feature is worth

Or as I stated at a previous job where I complained about the 40-minute-long test-suite run time that was bogging everyone down, "the road to a 40 minute long test suite is paved with a couple extra seconds here and there with every new code commit"

Clear and to the point for this non-techie: thank you!

Why not just make a conscious decision to stop developing new features and dedicate all the effort to refactoring then?

That is the solution, but sometimes it's a hard decision to make.

A few reasons. If you're an employee building a product for a company, management's always going to push for features, features, features, to keep the customers happy, and to keep up with the competition. Time spent refactoring is an investment in the future, but management tends to be more shortsighted than that. By the time that you really can't add more to the program, it's years down the line, and they've probably been considering pulling the plug anyhow.

In my own projects, it's often fun to keep adding things until I hit a roadblock, then spend a couple weeks reworking stuff. It's satisfying to add new features, but architectural maintenance feels like treading water.

So, I'd guess that the answer is somewhere between "outside factors dictate that there isn't time" and "we haven't decided to make the time, even though we could".

There's an interview with the two main developers here, from 5 years ago: https://sourceforge.net/blog/potm-201301/

It sounds like they ran out of energy to really rearchitect the whole thing, or build a new one from scratch.

> If you're an employee building a product for a company, management's always going to push for features

What company? What management? What customers? What features? Are we still talking about DOSBox?

No; I was speaking more generally about some potential reasons that software wouldn't be kept in a low-debt state. The same concepts could apply to Dosbox with some remapping.

What company? The Dosbox project itself.

What management? The devs making overall decisions for the direction of the project.

What customers? Anyone requesting new features and fixes in the software.

What features? Built-in support for Munt, new networking support, support for more varieties of peripheral hardware...

It made sense to me to give a more general explanation, since this thread started off with a question about what technical debt is in the first place. I also did my best to address Dosbox's specific reasons by posting the interview with their devs and providing my own interpretation of it.

Could be various reasons - the original people aren't there, or more likely the amount of free time people have to work on dosbox is not very big. Then, when people try and develop, the tech debt makes everything slow, even paying off that same debt.

As others have hinted, the best path to better code is

1) have a good test suite and test coverage to ensure that any code refactoring hasn’t broken other or expected functionality

2) spend the time to rethink the design of some piece and refactor that, deploy and watch for unexpected bugs

3) repeat until the code is up to date

The problem is nontechnical management that doesn’t even understand why it’s important to revisit old code in this way instead of constantly coming out with new features. It is just seen as an unnecessary cost, even though the crufty state of the code has been slowing the whole team down. (Disclaimer: I have been in this exact situation. The founders ended up selling out and leaving.)

DOS isn't getting any newer...

actually, it kinda is. FreeDOS has added a lot of nice features over the last few years. http://www.freedos.org/

Wonder if one could get a modern browser going on FreeDOS somehow...

The Arachne browser was last updated in 2013, and its code is freely available - it might make a good starting point: http://www.glennmcc.org/

At this point in time i suspect it would be easier to port webkit over in some form...

Emulation's difficult, even for well-known platforms. Dosbox emulates a large variety of hardware, quirks in various DOS versions, and runs on a ton of platforms, but it doesn't do any of those things absolutely perfectly, and there's room for improvement in its hardware support. Plus, compiler and environmental changes need occasional maintenance.

There's also NightKernel[0]...

"The Night kernel is a 32-bit drop-in replacement for the original 16-bit kernel of the FreeDOS operating system. It uses linear memory addressing and operates in protected mode on the Intel x86 architecture. The typical user will retain compatibility with their DOS applications and gain protected mode abilities such as task switching between applications..."

At it's infancy but you can add RSS[1] to follow the discussion.

[0] https://github.com/mercury0x000d/NightKernel

[1] https://groups.google.com/forum/feed/night-dos-kernel/msgs/r...

More feed options here: https://groups.google.com/forum/#!aboutgroup/night-dos-kerne...

Just this month I had to update some (very old) production code for a client, and when we pulled the project out of cold storage we discovered that the compiler wouldn't run on the Windows 64-bit command line.

DOSBox saved my bacon, and it wasn't the first time.

I had the same thing with concrete structural integrity calculations software written in BASICA. Still useful.

Maybe you could compile these with QB64.

(Quick Basic was the descendant of BasicA and largely compatible).

Any reason why this is up on HN? Is there a new release or something?

There's a certain mean time between new HN users rediscovering things.

*Which is fine, because after all, Hacker News is all about the comments. I don't mind re-discussing fine pieces of software or topics like these every once and a while.

Not sure myself... It looks like the latest release (0.74) was nearly eight years ago. That's not to say that it isn't an extremely useful and well-made tool, and perhaps doesn't really need a whole lot of updating.

That’s what I was wondering. Now and then, I see popular submissions here that I thought were common knowledge.

My favorite use (I mean, aside from the more obvious uses, like to run my GOG and Steam games, along with disks from my childhood) is to compile it with heavy debug enabled, and using it in conjunction with IDA to debug game issues.

It's actually got a fairly nice debug environment.

Before dosbox there were dosemu (which let you use hardware but was pain to configure) and things like qemu (emulate any hardware but even more pain to configure). You still had to install OS into VM. Dosbox just changed the rules of this emulation game. It was unbelieveably good even when it didn't do 32 bit yet.

Regarding DosEmu. How about the main developer presenting on it in 2018 from FosDem! https://mirrors.dotsrc.org/fosdem/2018/AW1.121/dosemu_and_fr...

I seem to remember using dosemu on early Linux on the console, and was amazed at seeing my graphics card perform its POST BIOS run on-demand - the first few times, I thought Linux had spontaneously rebooted, but it was just dosemu getting ready to run VESA graphics, IIRC. Or maybe I'm just misremembering?

Also worth mentioning, http://js-dos.com/ offers an API to load an emscripten build of dosbox and a DOS program of your choice.

Just wanted to mention 86box, which is a "spin-off" of PCem, actively maintained:

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

with "nightly builds" available, besides the Source Code.

It's a fork of PCem, but PCem is also actively maintained.

>It's a fork of PCem, but PCem is also actively maintained.

Yes, of course.

As I see it PCem is more "stable", whilst 86box is a little more "dynamic".

Since it offers (experimental but) "optimized" builds for certain processors:

http://ci.86box.net/job/86Box-Optimized/

in some cases it is conveneient.

http://blog.yesterplay80.net/dosbox-ece-en/

Community Edition. Seems to be some popular tweaks built in. Probably a good place to actually start.

DOSBox is also a great little debugger for x86 applications! It comes built with some excellent debugging features.

Qemu is a great platform to emulate x86 including numa machines

I'm not sure how Qemu would emulate a NUMA arch on a non-NUMA machine.

It doesn't even attempt to emulate different memory models WRT where you need barriers AFAIK.

You can Use -smp 8 -numa node,nodeid=0 -numa node,nodeid=1

All that does is lie to the guest over firmware (device tree, ACPI, etc.). All of the memory accesses are still uniform as far as CPU emulation is concerned.

How many different early-90s display adapters, audio adapters, and such does it emulate? It also means that you'd have to source the OS and drivers. If the goal is to run old DOS games, Dosbox is generally more convenient.

why is this trending?

Is it still being developed? They should move the repo from Sourceforge to some better platform.

Last commits are from February 2018, so I guess it is.

If you can't stand SourceForge or Subversion, there's a very unofficial and irregularly updated mirror of their VCS on GitHub:

https://github.com/jwilk-mirrors/dosbox

Good, so why didn't it have any releases in years? Distros package last release version, not current master.

Try Gentoo.

emerge -av =games-emulation/dosbox-9999

Pulls straight from SVN trunk @ https://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk

That is not actually true. Distributions are not consistent in such things even across a single distribution, and there is certainly no universal rule about only packaging the latest release versions of everything.

That doesn't answer the question. Did the project switch to realease-less method? If so, then all distros should simply package periodic snapshots.

Reply on news.ycombinator.com