(This is heavily expanded from a few Twitter posts of mine.)
When you write an application that has to rename a file, you have your chosen language and platform’s standard library to do the heavy lifting for you. For example in C it’s usually
int rename(const char* oldName, const char* newName), and a bunch of other languages follow suit. Why not, it’s a good function! But what does
rename actually do?
In MS-DOS, this’d be handled by Interrupt
AH 0x56. By which I mean it’d set two specific processor registers (as mentioned in Save Early, Save How) to point to the old and new file names, set the
AH register to
0x56, and execute the
INT 0x21 instruction. A function installed by MS-DOS will then take over, doing the actual renaming, possibly returning an error value which the C function can immediately use as its’ return value. Since SCI has its own “need-to-use” library…
rename proc oldName:ptr byte, newName:ptr byte
mov dx, oldName ; ds:dx = old name
mov di, newName ; es:di = new name
mov ah, 56h
xor ax, ax
(Full disclosure: the SCI code actually includes a
dos macro to save the programmers some typing. I unrolled it here for illustration purposes.)
All of this pretty much matches what you can find on Ralph Brown’s list. Given a suitable function prototype in C such as the one in the second paragraph, SCI can now call its own
rename function as it desires.
Enough about SCI though, its function as a practical example is at an end.
But what if you gave it bad inputs? Sure, if the old name doesn’t refer to an existing file it will return 2 “file not found”, but what if the new name isn’t quite valid? Remember, this is MS-DOS; we don’t have the luxury of long file names here. It’s 8.3 or bust. I don’t see any sanity checks in the above function, and Brown’s documentation only speaks of splats.
So what happens if we have a file
boop.txt and call
rename("boop.txt", "hello world.txt")?
In DOSBox, you’d end up with a file
hellowor.txt. You are free to further manipulate this file in any way you please. The command line won’t choke on it, file managers won’t get confused. If you wanted to manually rename it back to
boop.txt from the command line,
ren hellowor.txt boop.txt will work perfectly fine.
This is actually not true in real MS-DOS. If your program were to run on a real MS-DOS installation, you’d end up with
hello wo.txt, an 8.3 file with a space in it. And no contemporary file manager I’ve seen can handle that. The
ren command built into
command.com can’t parse it —
ren hello wo.txt boop.txt is three arguments where
ren expects only two, and the first isn’t an existing file’s name that it can change to
cmd.exe of course you can use double quotes to make it unambiguously two arguments, but this isn’t
cmd.exe. What about some file managers though? I have two, Norton Commander and its big brother Norton Desktop.
In Norton Commander, the file list shows
hello wo.txt, and its rename function can handle it. So can the built-in editor and viewer. Top marks for Norton Commander!
Norton Desktop on the other hand is not so sturdy. It can show the file in the list but that’s all. Trying to rename it back to
boop.txt reveals the incorrectness of the source file’s name quite succinctly:
Technically, this is true. You’re not supposed to have spaces in the middle of a FAT 8.3 file name. If a file has less than eight characters before the dot, it’s secretly padded with spaces, and so are the three extension characters. And the dot isn’t even — the true name as written in the FAT directory would be
BOOP TXT. But that’s just one way Norton Desktop trips. Its viewer seems to be passed the nonexistent
hello. It shrugs and asks which existing file we want to open. Its editor is given the same argument(s?) and lets us edit a brand new file named
hello. In Norton Desktop’s world, it can see the file, but it can’t do much with it.
What about a contemporary Windows? Can, let’s say, the Notepad from Windows 3.1 handle this file? Okay, so technically this is
commdlg.dll talking, but we’re playing for effect here.
Of course not, what did you expect by now!? Norton Commander only worked because it didn’t care enough! Would you really think one of the companies who made the FAT file system would blithely ignore one of the cardinal rules at the time?
Next time, we gettin’ hacky.
…Wait, hold up. Why does it say 1983 in the title? Well, if you notice on Ralph Brown’s site the rename function was introduced in DOS 2, which was first released in 1983. And so was I.