I got into software in the late 1970s, so my first couple of decades involved lots of low-level systems and designs. My world had a lot of assembly code, interrupt handlers, and driver routines. I can’t say I miss living in that realm, but it’s still fun to revisit sometimes.

A rare place that still happens is when I get to thinking about how I might design an operating system should I ever chose to (these days a dubious and foolish choice, at best).

One thing I’ll write about another time is the file system.

[I’d divide the file system into key sectors: O/S application, and user. Each of those has three sections: read-only, general, and temp. (The temp section is deleted on session end.) The underlying system maintains a simple hierarchical file system for the file’s “real” location. The upper system  uses tags and sub-tags for file management. The layering also enables file versioning.]

One of the things that neat about the Macintosh is how the file system has a dual fork: file content on one side, file description on the other. (The file system I just described would include such meta-data describing the file as well as meta-data for the managed set of tags.)

I really like XML. You can do so much with it.

For instance…

What if your O/S worked such that saw certain XML files as executable in the sense that they describe an executable. (In other words, they’d work very much like desktop shortcuts do on PCs.)

It might be based on file extension (using .xexe or .xex would be funny), but it would really depend on the XML content. A system that peeked at XML files could recognize executable ones regardless of actual extension. (Allowing generic tools to recognize these as XML files — a plus or minus depending on your point of view.)

As with shortcuts, the (let’s call them) XEX files would have parameters allowing configuration of current directory and execution command line. Of course they’d point to the actual executable (either directly or indirectly — say by registry entry).

But XEX files, and the O/S that recognizes them, could do more. They could bind the execution with input and output files; they could potentially configure the execution security, context, and resources (shortcuts do some of these).

They might even allow chains of executables so you could build a process.

The XEX file might also contain background process (“at” command) information, although either the system has to scan all XEX files for that data or such files need to be registered with the system. The thing is, the system is probably going to be scanning all the XEX files (which are small and fast) anyway, so…

Seems like that would make for a very configurable system that continues to have utility outside a windowing environment. After all:

start "rock playlist (v4).xex"

For the casual user, a handy GUI tool — a property sheet — edits the underlying XML file just as the Windows shell edits a shortcut. The power user, on the other hand, has access to all the goodies in a simple XML text file!

[This gets meta-twisty when you try to think about the XEX file in my file system having its own descriptor file (and tags file), so it’s a descriptor with a descriptor. And the file being described has a descriptor.]