Hacker News Reader

Comment by kragen | Hacker News Reader

As I've pointed out before, I think this problem didn't exist in 01974, or in CP/M at all, ever; I think CP/M was perfectly capable of creating files named AUX.H, or PRN.H, RDR.H, CON.H, LPR.H, etc. IIRC, even CP/M PIP (which is what actually implemented the special device names) required the colon to indicate that you meant a device. So if you wanted to print FOO.DOC on the printer in CP/M PIP you could say PRN: = FOO.DOC but not PRN = FOO.DOC. You could also, I think, say B: = FOO.DOC to copy FOO.DOC onto drive B:.

The problem was introduced, IIRC, in MS-DOS.

View on HN

Having worked with both CP/M and DOS back in the day, I'm pretty sure you are correct.

This does bring back fond memories. In the early days of Windows 1.x, the way to get debug/log output was with the OutputDebugString() function. This wrote the output to the AUX device, which would be a serial terminal or printer. I didn't have one of those, but did have the IBM Monochrome display sitting idle while Windows ran on the CGA or EGA display.

So I wrote a little DOS driver called AUX.SYS (with source code in AUX.ASM) to redirect AUX output to the Monochrome display.

That did not work very well! I couldn't even edit my source file.

After a while I figured out the problem and renamed the driver to OX.SYS and OX.ASM for the source. Homophones to the rescue!

I found the source code! For your retrocomputing pleasure:

https://github.com/geary/OX.SYS

And as usual, Raymond Chen has some insights on why these special filenames "worked" regardless of file extension or directory location:

https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42...

hey, this is super cool. do you suppose it works in modern freedos as well

You are very kind to say that, thanks!

I have no idea whether it works in FreeDOS, and I don't have a monochrome display to test it on. But if you try it, I would be very curious to know if it works! (You can reply to this message and I will get notified.)

For what it's worth, OutputDebugString() still exists and works in Windows 10. It just displays the text in the Visual Studio output window, but it's neat how much Windows 1.0 code will work without too much modification on Win10.

Microsoft go to great lengths to do everything possible to make that backwards compatibility happen.

only after the last 32-bit version of Windows 10 goes out of support will some of these things begin to get fixed. and even then it will not be a priority.

This isn't just for backwards compatibility, OutputDebugString is a crucial function and hasn't been replaced with anything afaik. We use it all the time. Why fix something that isn't broken I guess?

Indeed, that is the very definition of backward compatibility.

This is closer to forward compatibility: your program written for Windows 10 will work as expected on Windows 1.0! Well, at least the OutputDebugString parts.

No. It’s not. If it was superseded, and still kept in, that’s backward compatible.

You can also view it using Sysinternals DbgView or a debugger. This comes in really handy when you want some output from something that doesn't have stdout available, like a DLL.

I have about a dozen horror stories about being sent on-site to assist a customer who was having a massive production outage, only to discover that they were "smothering" all exceptions in a global handler... (because the hosting platform their components ran in was notorious for generating thousands of useless exceptions)

With no logging... But invariably, they would not want log files created in their production environment...

So, we would add at least an OutputDebugString() to the catch... prepare a build - then in the production environment we would use the Sysinternals "DebugView" to find out why things were breaking... (And typically - it was a missing dependency or DLL version miss-match from dev to production)

Fun times.

https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

The various DEC operating systems (RT-11, VMS, etc.) had PIP (Peripheral Interchange Program) which allowed you to copy files to devices (such as a printer). CP/M had PIP, but did not implement the devices in the filesystem, which MS/DOS did. The result of putting specially named files in the operating system was that files were not always files and strange behavior would occur in fringe use cases.

The basename (without the extension) had certain reserved names such as CON, PRN, AUX, PTR, PUN, etc. Originally these names always had a trailing colon to identify them as devices, but MS/DOS dropped that. MS/DOS kept the trailing colons for disk drive identification, but not much else.

This capability could be used to make a batch files (.BAT) without any editor on the system. One could type: COPY CON RUNME.BAT, and then type in the wanted lines of the batch file. The end-of-file character (^Z 0x1A) was the same on CP/M and DOS, unlike (^D 0x04) on Unix.

https://gordonbell.azurewebsites.net/Digital/RT-11%20System%...

>files were not always files and strange behavior would occur in fringe use cases.

coughs in Unix

The comparison to Unix stumbles because the behaviour of named pipes, Unix-domain sockets, and device special files, in a regular filesystem, is not based on their filename, but on the arguments to mknod(2) at their creation.

It goes back to version 2 where there was a planned merge of Xenix and dos.

You can even get it using the Unix path slashes in the 2.11 source code.

True, device nodes and other special files exist in Unix, but they are usually contained to special directories.

Should have been more clear. Yes, (at least in Linux) you can mknod a special file anywhere, but the directory hierarchy is taken in context when you open the file. On MSDOS, you can open AUX or CON in any directory, even though no such named file exists anywhere in the filesystem. THAT is a poor implementation, and would probably be considered a bug by most developers if it were offered as a solution today.

There wasn't directories in the first release of DOS. So I can forgive those special devices being location agnostic. However removing the device suffix (the colon) is really what causes this to be a bug.

You either have persistent files with special attributes that identify it as a device, or you namespace your devices with characters that cannot be used in a file name. But you don't allow your devices to be valid file names and have them invisible on the file system.

> However removing the device suffix (the colon) is really what causes this to be a bug.

I never thought about it, but when you consider ‘:’ as the device suffix, this makes directory structures make more sense to me on Windows.

C:\foo\bar makes more sense to me if it is the ‘C:’ device. Calling it a ‘C drive’ with a separate namespace never made sense to me. Somehow thinking of it the ‘C:’ device in an anonymous global hierarchy makes more sense to me.

Device files require that the mount point allow device files. That's a mount-time option, and "nodev" will prevent this.

You'll still be able to create named pipes (mkfifo), but mknod will fail.

This is handy for filesystems with a poorly developed sense of user ownership and permissions, say, msdos or vfat.

I tend to mount my /tmp space nodev and nosuid, as occasionally you'll find poorly-written, or nefariously-intended programs attempting to do such things there.

You know… it was called QDOS for a reason.

You can create sockets and fifos anywhere. Device nodes are the only special ones which are generally confined to specific locations.

I think on BSDs at least you can theoretically put device nodes wherever you want (but there’s no good reason not to put them in /dev where everything expects them to be).

From FreeBSD 6.0 onwards, device nodes can only exist in devfs. (Ok, technically you can create them elsewhere, but you can't use them to access devices.)

I see. I’m more familiar with OpenBSD which I don’t think has such a restriction. (Though I could be wrong).

That's why most partitions have the nodev mount option. An (one of the rreasons) why there is pushback on a single big partition for everything.

I'm pretty sure on Linux too there is nothing stopping you from putting a device node in any directory either. By convention they live in /dev (or its subdirectories), but there is nothing technically enforcing that convention.

(udev assumes they live under /dev. I'm not sure if /dev is hardcoded in udev or configurable. But you don't have to use udev anyway, you can create device nodes manually.)

Running a service inside a chroot might require some combination of /dev/{null,random,console,log} to be present inside the chroot, and bind-mounting /dev exposes the entire underlying system (raw disk nodes) inside the chroot.

So there's actually a good reason for being able to create device nodes outside /dev.

On FreeBSD you can mount devfs but tell it to only expose a subset of the device nodes, for exactly this reason.

Yeah, I used to do this to NFS-export a root filesystem for my diskless Sun-3. The NFS server was running Linux and the Sun was running IIRC NetBSD, so some of the device numbers in the Sun's /dev needed to be different. Pretty rickety setup but it worked okay. I don't recall ever accidentally overwriting my root filesystem or hanging up the modem line by accessing the bogus device nodes.

Yeah, it's just a mknod away provided your filesystem isn't mounted nodev

We actually use this too (https://libguestfs.org/nbdkit-file-plugin.1.html#PARAMETERS with "dir" parameter). It allows you to create a directory of devices to export. Symlinks are supported and generally better though.

This is actually mentioned very deep into the thread: https://twitter.com/Foone/status/1058928459462787072?s=20

Hyrum's Law [1]. By the time they figured it out it was too late. Orrrrr maybe they just threw it on the backlog and never thought about it again ;)

[1] https://www.hyrumslaw.com/

What is great is that things like Pypi and NPM all have packages that require the creation of such files, locking out windows from ever mirroring them.

Why old tech uses UPPERCASE so much?

The oldest encodings didn't always have both upper and lower case letters. So you picked one. For reasons of backwards compatibility similar to the one discussed here, DOS and Windows then decided to treat upper and lower case interchangeably in most contexts. FAT is a case-insensitive file system.

As for why default to uppercase instead of lower case, I think just a matter of style. Unix and C favour lower case, FORTRAN and COBOL and your keyboard keycaps favour upper case.

> why default to uppercase

probably to make sensible use of limited display abilities of early hardware, fitting characters in 8x8 boxes and making it readable on blurry fat beam glowing green screens quickly becomes a problem with lowercase (size, readability, ascenders, descenders, baseline), whereas uppercase is comparatively easy.

early hardware didn't have pixels or, except for debugging, screens; it had typebars which slammed bits of type into an inked ribbon and the paper. we're talking about 01930s to 01970s here. the baudot code didn't have separate codepoints for upper and lower case. in point of fact, it didn't have separate codepoints for numbers ('figures') and letters either; it had shift characters called 'figures' and 'letters'.

but why uppercase rather than lowercase, you might ask? well, http://wiki.c2.com/?CapitalizingGod has the following story, but i don't know if it is correct.

We may remember that ancient teletypes, printers, and terminals would bang out their output in all upper case. When this technology was first being standardized, the researchers did usability studies and found that people read lowercase text more easily than uppercase. But management decided to use uppercase instead. The reason? If only lowercase was shown, then there would be no means for CapitalizingGod.

anyway, by the time people started putting screens and pixels on computers in the 01960s to 01980s, the uppercase-only tradition was very well established.

Lack of syntax highlighting is the reasoning in SQL, I think.

SQL is incredibly easy to learn (even if you're learning concepts like foreign keys etc. at the same time) and really hairy to read, even with well-meaning indentation. Maybe there's a lesson from SQL and COBOL about prose-y programming languages for the hoi polloi.

Fortunately nobody ever tried downloading PRN.JPG

Reply on news.ycombinator.com