Building Software to Stand the Test of Time.

I love building things.  Tinkering.  Creating something new.

Brick_wall_close-up_viewRight now I’m working on re-doing the brick work on my house — the existing bricks having been in place for over 100 years.  I find the process of re-laying those bricks profoundly satisfying.

It’s like a grown-up version of playing with Lego blocks.  And, when I’m all done for the day, I know that the results will last.  At least… probably for another 100 years or so.

But, with software, things are a bit different.  Certainly far more short-lived.

In fact, most software is so short lived, that we, as developers, spend the majority of our time re-inventing the wheel.

Really, it’s even worse than that.  We’re re-inventing the wheel that we, ourselves, have already re-invented several times.

Case in point.

I’ve been releasing software to the world since the mid-90’s.  And, in that time, every application or game that I have made (with one or two exceptions) has had at least one “preference” that needed to be saved and stored between sessions.

How many times have I built (and re-built) classes and functions to handle reading/writing preferences to disk?  I have absolutely no idea.  Dozens.  In C, C++, Obj-C, Basic, Java, PHP and Pascal.  Add multiple platform frameworks (and revisions of those frameworks) on top of that… starts adding up fast.

Sure.  Building functions for reading/writing preferences to disk isn’t the most challenging or time consuming task in the world… but every little thing adds up.

A specific example.

discblaze-12Over a decade ago I released a piece of CD burning software for MacOS X.  Nothing terribly fancy or complicated, just a simple application that burned files to a CD.

Over the years that followed, that application needed to be updated approximately once every 4 to 6 months just to keep running.  Even minor system updates (ala MacOS X 10.2.4, 10.2.3, etc.) broke things badly enough to make this little CD burner of mine stop working.

We’re talking about minor changing in an underlying platform causing forced obsolescence at least twice a year.

While this example is a tad extreme, the same problems hold true nowadays as well.

Host platforms come and go (how many of us are running AmigaOS as our main desktop right now?) and UI libraries change with the wind (how many GTK1 apps are you running currently?).  There are, quite literally, thousands upon thousands of ways that (even seemingly minor) changes to a system will cause software to cease to function properly.

Is that bad?  Do we really want to stop pushing things forward simply to keep old software running like a champ?  Of course not.  Progress is awesome.  But the problem still exists.

And, when I build something, I want it to last.  When you download (or buy) a piece of software… you want it to last too.

One of the big problems with DRM-ed content (games, media, etc.) is that we, as the consumers of that content, can’t be assured that we will continue to have access to it in the future.  And that makes us grumpy.

But, in actual practice, the same effect is created when companies (or organizations/individuals) release updated versions of core libraries or systems that break backwards compatibility.  Same effect, different purpose.

Ok.  Great.  So what’s the solution?

Oh, jeeze.  I have no idea.  The problem is obvious.  The solution… far less so.

Many say that HTML/JS (ala “HTML5″) is the answer.  To which I say:

“The same JS code barely functions similarly across current versions of a handful of web browsers… and doesn’t really work at all on browsers from just a few years back.  And things are still in a state of flux.  What makes us think that code that works today will work in 2 years?”

Others will point to interpreted, cross platform languages such as Java or Python.  To which I say:

“Which version of Java or Python?  Also which versions of the countless supporting libraries?  Nope.  Same problem.”

We could, of course, go back to just writing console applications.  Do everything in C/ncurses and just call it a day.  But…

“What about when executable formats change?  Because they have.  And they will.  Going with something like C/ncurses reduces the total number of variables that could go wrong… but doesn’t eliminate those variables.”

Okay… so let’s focus on building languages and tools that are easy to port/update when needed!  Cough:

“That solves one, small, part of the issue.  This is something I’ve been focused on with Illumination and App-Make-inator for a few years now.  High-level tools like this do make it easier to re-build apps when needed to work on newer systems.  But they require the developers to rebuild.  And they require the users to re-acquire.  Which isn’t always possible.  What happens 20 years from now when people want to play my games?”

You’ll notice a pattern here.  Basically I’m shooting every (reasonable) possible idea down because it’s just not going to solve the problem.

The Most Ridiculous Solution Possible.

snesThere *is* a solution.  Select a platform, emulate that platform in a portable way, then only build for that platform.  In order to make that work you need to pick a non-moving target that has already achieved the critical mass necessary to build and support a portable emulation system.  Something like a Super Nintendo or DOS emulator.

That solves the problem.  But then you’re limited to the constraints of those systems.  In those cases that would be :

  • No (or highly limited) networking.
  • Memory and file size constraints.
  • A lack of currently maintained modern development tools.
  • No 3D acceleration (for the most part).
  • Plenty of other issues I can’t even think up at the moment.

I went down the DOS route for one of my games.  More just for fun than anything else.

Did it work for that?  Yes.  Yes, it did.  And, to be honest, it would work for most of the types of software and games that I build.  But would that sort of approach work for most software out there?

… probably.  So long as it doesn’t need internet connectivity.  Or 3D acceleration.

And, at least in the current world we live in, it seems like folks would far prefer a “native” experience on their platform of choice — which is a stance I totally get.

TinuxTycoonDOSAtLastThen again… download numbers for Linux Tycoon for DOS are far higher than for all other platforms (including Windows and Linux).  I posted some numbers in a rather tongue-in-cheek article.  I find that notion humorous… but interesting.

Now, for making games in a retro style — which so many games use nowadays — I don’t see much of a reason to not build those games for SNES, Genesis, etc..  As they can then be bundled with emulators and sold in app stores and posted for download quite easily.

All of which is to say: I don’t have a good answer.  But I’m wishing more developers built SNES and DOS games.  Because then I could play those games 30 years from now with my grand-kids.

Share Button

Announcing the App-Make-inator. Build apps “in the cloud”.

Being able to build apps for iOS, Android (and more) without writing any “code” is cool – Illumination Software Creator has been doing it for years.

But wouldn’t it be even cooler if you could do it all from a webpage that works on any device (including iOS and Android itself)?

Illumination IconYes.  The coolness would be off-the-charts.

So I made it happen.

I call it… The App-Make-inator.

Some quick details:

  • Visual development, building on the years of experience with Illumination Software Creator.
  • Easy to learn and use.  No “coding” required.
  • Builds native apps for multiple platforms — including iOS, Android, Windows PhoneHTML5 and Desktops.
  • Completely web-based interface with full support for designing, and building, your app or game right from Chrome on Android and Safari on iOS.
  • Free to use to design and test your app or game.  You only pay for a subscription for the platforms you want to ship on.

That’s right.  Build an iPhone app from the comfort of your Android tablet (and vice versa).

Here’s how it works:

  1. Load up the App-Make-inator webpage.
  2. Design how your app looks by drag-and-drop.
  3. Tell your app what it should do… also by drag-and-drop.
  4. Test your app right from the web page.
  5. When you’re ready to deploy your app, you hit a button and, wham-o, your app is generated (including complete, native source code for the platform you want to release for).

The App-Make-inator will launch publicly in March.  Currently in closed Beta testing.

ISC Portal BlocksBut wait… there’s more.

The source code for the latest version of Illumination Software Creator 5.0 (the Linux/Windows/Mac Desktop-based daddy of the App-Make-inator) is being released under the GPL.

Q: Why release Illumination source code under the GPL?  Why now?

A: The combination of the success of the “pay (what you want) to download” system, combined with the (completely selfish) advantages of having Illumination as an open project that the community can get involved in, makes this a no-brainer.  This isn’t an experiment in GPLing a closed source app.  This is the way forward.

The latest versions of Illumination Software Creator will continue to be released on the Download Page here, with the code available on GitHub.

Share Button

Everything here is free.

All of the software, video games and comics on this website are now available for free.

Illumination Software Creator, Linux Tycoon, Road Sign Hank and the Aliens… the whole shebang.  Free.

This isn’t an experiment in funding Open Source Software.  This is a permanent change (at least as permanent as anything in this crazy, mixed up world) to the way I am distributing my software — brought about, in part, by significant changes in my life.

I will be accepting donations that will be used to fund continued development, design and support — including funding others to work on them.  There’s even a handy-dandy set of sliders that allow you to set how much you want to donate towards various types of projects (including support for the BBS).  Those donations are entirely voluntary.  There is no catch.

Links are on the individual project pages.  And on the side of this page.  Or you can just click here.

All are entirely viable options.

Share Button

Software Alternatives… for DOS

I am building a list of alternatives for certain types of applications for an article series I am writing… and I’m only interested in ones that run in DOS (MS-DOS or FreeDOS).

For example, as an alternative to Excel and OpenOffice Calc — we have Lotus 1-2-3.  As an alternative to Word we have… well… Word (there is a DOS version).

But there are still a lot of holes to fill in.  So I am reaching out to you amazing, nerdy folk to help track down the best old DOS applications  that can replace some of the modern apps many of us use.

Here’s what I’m still looking for:

Visual App Programming (such as Illumination and App Inventor)

Visual Game Creation (such as GameSalad and BLABA)

Presentation Software (such as Powerpoint – I know Harvard Graphics exists… but I can’t find a way to get a copy of it anywhere… it seems to have vanished into the abyss)

Video Player (such as VLC, Totem, etc.)

Project Management (such as MS Project or Calligra Plan)

Instant Messaging (I know, I know.  I ask for a lot.  Possibly a DOS port of naim?)

For those interested, I will be including my complete list and details in an upcoming Network World article (I’ll link to it here).

Share Button

Exploring The Software Project Graveyard

There is a folder on my server where I keep old projects that have died.

Software for a variety of platforms.  Some complete.  Some half finished.  Others consisting of nothing more than a few mock-ups or prototypes.

Every developer has just such a place — where good (and not-so-good) code goes to die.  A software graveyard.

I needed to venture into my own graveyard to dig up some old code… and got distracted by some of the older projects.  Because reminiscing is fun, I am now sharing some of the weirder ones with you.


Back in 2004 (or 2003?  No… no… 2004… some time around there) I built this little Mac-only app called “Macabinet”.

It was this little drawer that slid out from the side of the screen when you dragged files near it… then you could drop them there.  And sort them.  Basically a place to file away your files to keep your desktop clear.

It was a cabinet.  For your Mac.  Hence… “Macabinet”.

It had a few fancy themes (done by the same artist that did my current website design) and it had a small — but loyal — base of users.


This was an online game for the original e-ink Kindle that I started working on the moment that the Kindle’s Java SDK was made available.

It was basically a simple BBS-style, turn based RPG along the lines of Legend of the Red Dragon.  Except it ran on the Kindle with its fancy, free, always available (but kinda slow) wireless.

Got the game to about, I’d say, 50% complete before I decided to move on to other projects.  It kinda worked.  Was a bit pokey though.  The latency of the Kindle’s wireless made things almost maddeningly slow to play.  Was fun to do a Java game project though!

Kernel Attack

This was a game that I started putzing around with some years back and never quite wrapped up.

The basic idea was that you were a program that must protect portions of the kernel from invading code.

Game-play wise it was a funky mix between Rampart and Robotron (quick action in rounds where you rebuild your defenses).  Two of my all time favorite games.

Super, super nerdy.  And very retro.  Every now and then I get the itch to finish this one…


This is another “Mac only” project from quite a few years back.

It was a video player with some various, odd options that nobody wanted in a video player.

One such feature is demonstrated in that screenshot.  Adjustable transparency of every video playback window.

Because that is something that everybody wants to do every day.

Other features that only a handful of people would care about : Adjustable settings (like gamma and contrast)… and… I kid you not.  Rotation.

Seriously.  Check that screenshot out to the right.  That’s a video playing back nice and smooth… while being rotated.

You might ask me why that would be useful.

To which I would, confidently, reply… “uhhhh… I dunno”.

It was cool looking and I wanted to do it.   Does a dev really need a reason to do something random like that?

I’m curious what sort of funky projects are in your software project graveyard… feel free to post away in the comments.

Share Button