From the Wikipedia article on reserved device names
... and the CLOCK$ (still named CLOCK in some issues of MS-DOS 2.11) clock device were introduced with DOS 2.0, ...
Why was is necessary to add a $ character to this device name?
And why didn't they name this device CLK which would have made sense in a list such as CON, AUX, PRN, LST, NUL?
Microsoft advices against using these device names as filenames regardless of extension. Perhaps too many users couldn't resist having CLOCK as a filename?
Quick partial answer:
CON, LST, PRN and AUX (*1) are names inherited from CP/M, either direct form its BIOS or CP/M's main file handling utility PIP (*2). NUL was add with DOS.
DOS 1.x added additional names for installable interfaces like LPT1..4 or COM1..4
CLOCK was introduced with DOS 2.0
But DOS 2.0 added loadable device drivers as well, each able to bring any arbitrary name of its own. Basically not a big issue, but it would make it quite hard for MS to make sure that any new name they may come up in future versions has not been taken by any third party driver.
To solve this MS defined that all future (MS) device names, except for the DOS1.x like names, which may be present at boot, has to include a $ sign as last character (*3).
Problem solved - except, that definition was only made after DOS 2.0 was published, so CLOCK came preinstalled in DOS 2.0 without a $-suffix, a lapse fixed in DOS 2.1.
CLOCK$ was, BTW, not the only one added that way, so was SCREEN$, KEYBD$ or MOUSE$.
*1 - there were a few more, like RDR (Reader) or PCH (Punch), that got added over time, but didn't make it to MS-DOS
*2 - CP/M PIP in turn inherited them from RSTS/E.
*3 - They had to pick one that had no other meaning at the time and would be valid wherever a device name is possible.
XMSXXXX0 (HIMEM.SYS), EMMXXXX0 (EMM386.EXE), SETVERXX (SETVER.EXE), _doubleB (SMARTDRV.EXE) or MSCD0001 (commonly used with MSCDEX.EXE) obey this?
Commented
Apr 4, 2022 at 6:35
CLOCK$ also needs to handle a stream of characters; specifically, sequences of three words. Try COPY CLOCK$ CON ;-).
Commented
Apr 4, 2022 at 10:07
As Raffzahn explains, the clock device driver was added in DOS 2.0. CON, AUX, etc. were device names already present in DOS 1.0, some of them even earlier in CP/M; these names couldn’t be changed to preserve backwards compatibility. Of all the standard (in-kernel) device drivers, CLOCK$ is the only one which wasn’t already present in DOS 1.0.
An important subtlety in DOS is that opening a file or device (interrupt 0x21, service 0x3D when using file handles) will open a device in preference to a file for any file name matching a device, ignoring the file extension. Opening NUL, NUL.TXT etc. will all result in opening the NUL device driver, not a file on disk. Thus, any new device driver effectively replaces any file using the same name, in any directory, regardless of extension.¹ CP/M required colons (PRN: etc.) to identify device names, but this requirement was dropped in MS-DOS, which merged the namespaces.
As far as the clock device goes, DOS itself doesn’t care what the name of the device is; the clock device is identified by a specific bit in the device driver attributes (bit 3). The DOS reference manual mentions this:
MS-DOS assumes that some sort of clock is available in the system. This may either be a CMOS real-time clock or an interval timer that is initialized at boot time by the user. The
CLOCKdevice defines and performs functions like any other character device, except that it is identified by a bit in the attribute word. The DOS uses this bit to identify it; consequently, theCLOCKdevice may take any name. The IBM implementation uses the name$CLOCKso as not to conflict with existing files named clock.
It would appear that the CLOCK device name was chosen, and then someone realised that it would create conflicts with any existing file matching CLOCK.*; to avoid that, the driver was renamed to $CLOCK in PC DOS, and CLOCK$ in MS-DOS (which was also the name used in DR DOS), but not before some releases ended up using that name in the wild.
Without this change, people with files named CLOCK.EXE or CLOCK.TXT etc. on floppy disks would lose access to them when they switched from DOS 1 to DOS 2. CON, NUL, AUX etc. don’t have this problem because no one would ever have been able to create such files on a PC using DOS (except by modifying the directory entry directly on disk).
All this is the reason why installable character device drivers use variously-decorated names: MSCD0001 and so on for MSCDEX, EMMXXXX0 for EMM386, the list goes on.
¹ Ignoring both the directory and extension were deliberate design decisions. DOS 1 programs didn’t know about directories, and expected to be able to open devices anywhere (see “From a Feature to a Bug” on OS/2 Museum). Some programs (particularly those ported from CP/M) also forcibly applied their own extension to whatever was provided by the user, so extensions had to be ignored so that devices could be used (being able to ask a program to use PRN or COM1 instead of a regular file could be very useful in some circumstances). DOS supports a Unix-style \DEV virtual directory, but that never gained much traction.
The $ suffix was meant to fence off the Microsoft-reserved namespace. It works the way the __ prefix fences off the implementation-reserved namespace in C and C++.
Similar to C and C++, DOS had a long legacy. The legacy devices inherited from CP/M and DOS 1.x were kept unchanged, as everyone writing custom device drivers would be aware of them. The MS-reserved namespace was there so that DOS-specific device names would not clash with those provided by 3rd-party drivers.
As for why some implementation-provided drivers, like XMM/EMS, didn't have $-prefix: they had a numeric suffix... This was another part of the device namespace MS has fenced-off for their own use. Those things weren't always written down, and absent a clear design documentation stating these constraints, the implementers often did things "similar but not quite".
Speaking of XMM and EMS specifically: the named device files wouldn't be used for anything but detecting the presence of the drivers. To use the services, you'd directly use service-specific entry points, e.g. INT 67h for EMM services. The name-based device detection was a bit more robust, as in some circumstances the non-installed interrupt vectors could point to garbage. The file-handle based access to performance-critical services such as EMM had too much overhead in the early days of DOS. DOS+BIOS made the decision to have quite a bit of system device access done by dedicated APIs, and not using the character device abstraction. Which, admittedly, was a shame.
