mahiwaga

I stumbled upon this blog entry on The Old New Thing which discusses the 8.3 filename convention on MS-DOS and Windows up to and including XP, which limits a filename to 8 characters with a 3 character extension.

Now I haven’t run Windows since 1998, although I’m forced to used it at work. While the filename limitation was effectively eliminated by Windows 95 and the introduction of VFAT for most casual users, as oldnewthing points out, it still has ramifications to programmers.

I find this sad.

My very first computer, a Commodore 64 purchased in the ‘80’s, could use up to 16 characters in the filename. The original incarnation of the filesystem for UNIX (now commonly referred to as s5fs) which existed in the ‘70’s could have 14 characters in the filename. The original Macintoshes with the Macintosh File System could have 255 characters (although this was in practice limited to 31 characters because of the limitations of the Finder)

And here we are in 2007, with programmers still having to deal with 8.3. Hah!

OK, so maybe I’m just a touch melodramatic when I say that Windows’ reliance on the 8.3 naming convention makes me sad. And, yes, I do subscribe to the ”worse is better” school of software design, so I agree that you shouldn’t futz around and break something that already works pretty well 95% of the time.

But I do find it quaint that vestiges of CP/M still survive to the present day. It’s as if we’ve never left the 8-bit era of computing (those were the golden ages, I tell you.)

What I do find disturbing is the fact that you can’t safely abandon the 8.3 filename convention. Say I want to use only long filenames. Thanks to poor third-party developer practices, it’s never going to happen. As oldnewthing points out, there is a lot of crappy code out there that hard codes 8.3 filenames into their installers. And then there’s the thing with how the dynamic loader almost makes name collisions inevitable by allowing you to call the same library by both its short name and its long name as if they were different libraries, resulting in two copies of the library taking up space in memory, and possibly leading to some rather hard-to-detect bugs. This gives me the heebie-jeebies.

There’s nothing you can really do about the third-party developers. The only way would be if their code happens to be open-source, then you could fix it yourself by removing the hard-coded filenames and recompiling. But I think that, in this day and age, it should probably be the standard practice to just call libraries by their long file name and ditch the 8.3 filename convention altogether in any new code you’re writing. After all, most newbie end-users booting up XP on a clean install should have their hard drive formatted as NTFS, and anyone demented enough to still use FAT32 will have to take their own chances.

I think the reason why the 8.3 filename convention grates on me so much is the fact that I started off on an OS that allowed me to save files with descriptive names—as I mentioned before, CBM-DOS allowed 16 character names, which was plenty enough for me at the time. To be reduced to goobledygook like FVQURPMX.DOC didn’t sit too well with me in those days when I was still running MS-DOS 5 and Windows 3.11. It certainly made searching for old documents an adventure. I remember long filenames being one of the huge features that made Windows 95 a must-have for me. Hell, long filenames were one of the reasons why I braved the sources of the Linux 1.x kernel in the early ‘90’s.

Oh, I know that long filenames aren’t too nice if you’re stuck with using COMMAND.COM as your shell, but if you have something sane like Bash which allows tab-completion, or if you—horror of horrors—actually use the GUI, then it doesn’t matter at all. And sure, even now, the UNIX convention is to use program and directory names that are as short as possible. Look at the FHS. All the key directories still consist of only three characters. But it doesn’t hamper you from using longer directory names if you want to. Look at Mac OS X, for example, which uses verbose directory names like “Library” or “Applications”, all without significantly breaking compatibility with its BSD roots.

That said, yes I know Unix itself is pretty ancient. But its heterogeneity makes the development environment a lot more stringent. You’d never get away with doing non-portable things like hard-coding which directories you expect to exist on the filesystem. If your code relies on legacy things that have long since been thrown away, it’s just not going to compile, and you’re going to have to fix it if you want anyone to use your software.