Complications

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.

So what have I been doing?

Despite the lack of updates to this blog, I have actually been working on Aeon. I haven’t been working on it nearly as much as I have in the past. Between my day job and my other obligations it’s sometimes been a challenge to find time to keep going.

That being said, my tentative plan for Aeon this year is to refactor portions of the code that have become very difficult to maintain, and to improve MS-DOS compatibility in the process. I’ll be writing up another blog post about that soon (for reals this time). The short version is that I ended up undoing a lot of the “improvements” I was making when I realized how vastly overcomplicated my new design was :)

Of course, refactoring isn’t that great of a feature since it doesn’t add features or fix any bugs, but it will give me enough confidence about the codebase that I can start to consider making it available for download. So far, I just haven’t wanted to deal with the extra hassle of (and sometimes drama) that goes along with making a large project like this open-source (not to mention the fact that another project very nicely fills this void already), but I’m not working on it as much as I used to, so maybe that will happen later this year.