Aeon Emulator Blog

February 25, 2012


Filed under: Aeon — Greg Divis @ 4:43 pm

Programming is kind of an odd hobby, since it’s also what I do for my day job. I created Aeon (and before it, other projects) as a kind of outlet for solving challenging development problems. Since it’s all mine and just for fun, I don’t really have to stick to any established design patterns or coding standards. I don’t even have to design around the requirements, because I’m constantly making those up as I go. Because of this, it’s not what I would call a shining example of cleanly architected code, and I’ve been investing some effort lately into restructuring things in the hope that it will make things easier going forward.

The biggest challenge I’m facing now is trying to extricate my DOS implementation from everything else, so that (in theory) Aeon could be run without it – say to install MS-DOS or some other variant and use it more as a true virtual machine. I actually started reimplementing my DOS code from scratch, and spent quite a few weeks on this. I had grand plans of a clean, maintainable, and accurate simulation of MS-DOS.

Sadly, it wasn’t meant to be. As the time went by and I was adding interface after interface, I ended up with an object model that turned by current tightly-coupled DOS into a loosely-coupled mess that was orders of magnitude worse.

Sometimes It’s Tightly Coupled for a Reason

MS-DOS was a complicated mess of features in the unfortunate position of becoming a de facto standard. Since it was a standard, tons of programs built for it actually relied on some if its more quirky behavior, so it could never really be improved architecturally. My mistake was thinking that by just adding some abstraction, I could elegantly implement DOS. Sometimes a cigar is just a cigar, and sometimes a mess of contradictory requirements is just a mess of contradictory requirements.

My  solution to the DOS problem was to greatly increase the complication by adding level upon level of logic to abstract it away and hide it. Of course, since I was the one writing these abstraction layers I was just making more work for myself. My goal now is just to minimize and isolate. Of all of the ridiculous changes I made trying to reinvent the wheel, I’ve only actually ended up keeping a small number of trivial classes. Lesson learned. Again.



  1. Necessary complexity is, sadly, sometimes necessary. Sorry the re-org didn’t work out. Finding the right balance of global to local complexity can lead down some pretty nasty dead ends.

    On the plus side, I bet you got to learn a few new industry buzzwords that you can throw around! :D

    Comment by airhed13 — February 26, 2012 @ 11:42 pm

  2. My suggestion is to save yourself a lot of trouble and only emulate the hardware, leaving DOS duties to the real MS-DOS, which is installed by a user. Simulating MS-DOS is like going through a zoo of badly documented antiquities. And DOSBox is not that great at accurately implementing DOS behavior if you look at their forum. So I’d leave that niche of not so accurate emulation to DOSBox.

    Comment by motke — March 4, 2012 @ 6:59 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: