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:.
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 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?
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.
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)
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
I knew what this was going to be as soon as I saw "aux.h" in the screenshot.
Some years ago I was working on an embedded system that involved DisplayPort. For those unaware, DP's control channel is called AUX. One day, my new co-worker who used Windows asked me, who used Linux, why my AUX-related code wasn't checked in - which it most certainly was.
And that, folks, is how I learned about this absurd property of Windows that exists to this day.
OS filename issues and checking in code reminds me of an 8-hour mess I got myself into due to OS X deciding that filenames are case-insensitive, and git knowing that they are not...
I have had funny experiences copying files from Linux to a NTFS partition, because NTFS is actually case-sensitive, but Windows itself is not, so you suddenly end up with two files that differ only by case and you can't delete or rename them (but funnily enough they show fine on Explorer).
The thread inaccurately describes the limitation of these special names being on the "OS level" -- it's actually one layer down, in the DOS and Win32 subsystems. Windows NT doesn't throw fits about these file names if the subsystem you run under (see: POSIX, LXSS, OS/2) doesn't care about them. Cygwin can even override the Win32 behavior by just passing all its file handlers through the native NT API instead of the Win32 API.
Indeed. And Win32 even gives you a way to bypass the legacy behaviour. You can use `\\?\` paths, which get automatically translated to `\??\` NT paths but are otherwise left untouched.
Note that MS did implement this in DOS 2 as AVAILDEV. With AVAILDEV=FALSE special device files only existed in \DEV. They still existed on all drives but at least they were constrained to a special device directory. With that setting the console was at \DEV\CON, first serial port at \DEV\COM1, and so forth.
I can only assume IBM pitched a fit and made MS remove it like they did with SWITCHAR.
If you didn't know about SWITCHAR it allowed you to change DOS to use Unix's "-" switch delimiter instead of "/". This is why DOS/Windows also accepted either "/" or "\" as path separators (and still do).
The same IBM that wouldn’t let them port Windows to run ON OS/2 or let them ship 80386 features like v86 mode support. Microsoft even had 1.0 betas of v86 multitasking on OS/2 in 87, but it only shipped in Windows/386.. and of course 386 flat mode in Xenix 386.
Which isn’t such a great design either. DEV is after all a perfectly legitimate directory name. It would have been even weirder to be able to have a file named AUX.H in any directory except C:\DEV.
I wonder why didn’t they instead add a switch to bring back the requirement of a colon after the device name.
I'll guess that you didn't knew that DOS 1.x don't have any concept of directories. It's essentially a novo terra for DOS applications, and makes sense considering that Unix also standardised at /dev.
I did know that. The point is that unlike Unix, MS-DOS had no FHS to go with its hierarchical file system, which would cleanly separate the namespaces of user files from device nodes. (The file system layout didn’t even start becoming standardised until the Windows 95 days.) One could fairly legitimately create a DEV directory in the root of the file system and expect to be able to keep their own files there, naming them arbitrarily. The edge case is now harder to hit, but it’s still basically the same mistake.
IBM had massive style guides put together by committees and based on things they'd done for decades before. Some of what they wanted out of the PC was as a poor man's mainframe to potentially get more sales of their mainframes. They wanted DOS to look like the solid, stable System/360 and OS/360 they sold (well, leased in most cases), not some weird upstart UNIX clone from IBM's competitors.
For system apps like cmd.exe or explorer.exe, a registry key would be a better solution. That way the end user or sys admin can turn it on or off, whereas the exe manifest is fixed at build time.
I very much wish Excel had a "I could not care less about legacy crap and I never ever want to see my number converted to scientific notation again for as long as I freaking live so help me I want to kick those devs in the goshdarn shin" mode.
The "Number Format" panel is front and center in the Excel ribbon. Just use anything but "General" and you get the "I don't want you automatically guessing mode".
Ctrl+A then Alt H N T E enter to make the whole spreadsheet "Text" by default instead of "General". (Or Ctrl+A Alt H N A enter to default everything to "Accounting" if you are just going to be typing in a bunch of dollar amounts, etc.)
The tools are there to "opt out" of "I'm too lazy to set a data type so guess for me" mode and always have been.
The science community decided it was far easier to change the names of entire genes than to teach people how to use Excel and never use the "General" format.
I definitely appreciate both sides of the frustration: "General" exists for a lot of good reasons that people are lazy and don't want to learn how to operate the software they use every day correctly, they just want it to read their minds.
For similar, but different reasons, because it is hard to train people everyone else builds elaborate work arounds (renaming genes, coming up with silly naming conventions and separators that won't be confused with dates or numbers, always passing spreadsheets over to "that IT guy who knows how to fix it/clean it up" before doing anything critical with them, etc). It's funny how many of those workarounds become so much more work (as they get concretized into bureaucratic processes) overall than learning to hit the one big Number Format dropdown at the top of the screen sometimes.
Both problems exist because people are inherently lazy and don't want to learn how to use their tools properly, and no one is really at fault on either side ("General" has a right to exist and has existed since Visicalc; People are free to live/die by the illusion that processes are cheaper than education), but a lot of us get stuck uncomfortably in the middle both knowing the tools and being unable to get people to use them right.
> Both problems exist because people are inherently lazy and don't want to learn how to use their tools properly
No. That's definitely not it. We deal with people who know excel inside and out. They are human. They might not notice a cell on row 11593 has an issue. They might forget. It's Excel's fault for not understanding that it is software for humans.
If you use UNC paths, it already happens. The issue is dealing with software that won't give absolute UNC (NT-native) path to an API.
That said, it should be theoretically possible, but I believe any approach other than hooking into high level IO call will be problematic, and you'd probably lose access to many things like serial/parallel ports etc. (as applications wouldn't know the names you renamed them under).
> and you'd probably lose access to many things like serial/parallel ports etc. (as applications wouldn't know the names you renamed them under).
The big problem here is bare device names, and device names with an extension – e.g. "COM1", "COM1.TXT". Device names with a colon, e.g. "COM1:", are not such a big problem, because colon is not an allowed character in file names on Windows (it is reserved as syntax to specify a drive or stream.) And while colon is a valid character in Unix file names, it is rarely used in practice, so Windows not supporting it is less of a problem than Windows not supporting files named "aux" or "con" is. So if they still recognised the device names with a colon, that would work fine for some programs that already use the colon, and for those that don't it should be an easy fix to just add it before updating the EXE manifest to opt-in to this feature.
Actually there is another fix – in Win32 programming you are recommended to prefix device names with "\\.\" anyway. That is actually mandatory when dealing with more than 9 serial ports (e.g there are multiport serial cards with more than 10 ports, or you might have two 8-port serial cards in your system). If you want to access COM10, you have to prefix it with "\\.\". And it is best practice to use those prefixes even with COM1-9. So programs already following that best practice would need no change. (And few programs directly use serial or parallel ports nowadays anyway.)
Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk.
We ran into this recently when a bug in Ardour ended up creating files on disk named like "recorder:N". They were created correctly on the disk, and in the Ardour instance that had created them and thus had file handles for them, they could be read without issues. But ... close the program and restart it ... errors about not being able to find the files.
Fortunately, Notepad (I think) is one of the few applications that can handle these names (I have no idea why), and so it could be used to open and save the files under a "better" name.
ps. after 35 years in computing, I have not used Windows for more than 30 minutes in total. This account is based on being a developer of a cross-platform application who reads bug reports and interacts with users.
> Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk.
I think you are getting confused by stream names. If you try to create a file called "foo1.txt:bar", some Windows tools let you. But that is not an example of a file name containing a colon. The filename is "foo1.txt". In Windows NT (and its successors), a file can be composed of multiple named streams, and ":" separates the file name from the stream name. So "foo1.txt:bar" is actually the the stream named "bar" of the file named "foo1.txt", not a file named "foo1.txt:bar"
So let me rephrase. An application can attempt to create a file using the name "foo:bar" and this will result in a new entity in the filesystem that can sometimes be successfully accessed using the name "foo:bar", but generally not.
The core Windows APIs don't have any problem with accessing the file stream "foo:bar". It is just some applications which apply their own file name validation and reject it before passing it to the underlying APIs.
That is seen even in some programs shipped with Windows. For example, cmd.exe. Some of the built-in commands in cmd.exe, for example "del", "type" and "copy", refuse to work with file streams. But that's because cmd.exe's code is detecting the colon and rejecting it as bad filename syntax. If Microsoft would just comment that validation code out, and pass the name including the colon down to the core Windows APIs, those commands would work. But that said, other parts of the cmd.exe code can handle them. The "dir" built-in command even has an option to display file streams, "dir /r". You can also read/write streams using redirection in cmd.exe, e.g. "echo foo > bar:baz" will write the string "foo" to the file stream "bar:baz". And "more < bar:baz" can be used as a workaround for the fact that "type bar:baz" doesn't work. Even though "copy" doesn't understand streams, "copy foo bar" will copy "foo" with its streams intact (assuming both target and destination are on filesystems that support streams), since even though "copy" doesn't understand streams the underlying Windows file copy API it calls does.
Microsoft is unlikely to fix the limitations in cmd.exe since cmd.exe is now considered a legacy component. New features all go in PowerShell. And PowerShell has much better support for streams, it can do everything with them.
So the "generally not" really depends on which applications you are using.
The thing is, colon is NOT part of device name. It just separates device name from path, and is arguably the part of the mess that is derived from CP/M
Yes, it isn't strictly part of the device name, it is a separator. But it still works well for distinguishing device names from file names. For a character device, the path name has to be blank. "COM1:" is definitely a device not a file, as long as colons are not allowed in filenames.
(Well, strictly speaking you might argue it could be the default unnamed data stream of a file called "COM1". But almost nobody ever refers to the unnamed data stream explicitly like that, just using the bare file name to do so; and if one must, the canonical name for it is to include the stream type, giving the default unnamed stream of the file "COM1" a name of "COM1::$DATA". That's obviously not a reference to the "COM1" device, since it violates the "path name must be blank" rule)
DOS required extensions and most early DOS apps just always appended their own extensions automatically and only took in the base name. The system ignoring the file extension made it easier to use the devices in every DOS app, not just ones aware of the devices.
> Unfortunately the API was that you used CreateFile without colon.
I don't have time to do any detailed testing of this right now, but I believe that `CreateFileA("COM1",...)` and `CreateFileA("COM1:",...)` are equivalent, and both work identically. Am I wrong about that?
The problem is you could create the file in one program but not be able to read it the other.
I wonder if they should only exist for command line apps although I wonder if there aren't still GUI apps that control industrial machinery by opening "COM1" as a file.
You don't even need to use the NT APIs directly. The Win32 APIs already do it if you use the \\?\ prefix.
You can even demonstrate this with cmd.exe (which uses the Win32 API, it doesn't directly access the NT API)
`mkdir c:\con` will not work, says `The directory name is invalid.`
`mkdir \\?\c:\con` does work. But then to delete you have to use the \\?\ prefix again. And `cd \\?\c:\con\` doesn't work, you get the `CMD does not support UNC paths as current directories` error. (Win32 does, this is a cmd.exe limitation only)
My proposal was to have a way of getting the `\\?\` behaviour without having to explicitly provide that prefix.
Actually, not quite. There is one aspect of `\\?\` which is undesirable. The NT API only supports backslash as a directory separator. The Win32 API supports forward slash as well, it automatically converts forward slash to backslash. But `\\?\` turns that conversion off. I think you'd still want the forward to backslash conversion on, to maximise compatibility with Unix.
The reason why it's not quite so simple is because any existing API that uses TCHAR[MAX_PATH] would be ABI-broken. Some of them are obvious, e.g. the WIN32_FIND_DATA struct used by FindFirstFile/FindNextFile.
The less obvious part is that for a very long time, it has been a contract for all Win32 functions that return PATHs, that the maximum size of the returned path is MAX_PATH. So there are a lot of apps that basically allocate a buffer of that size and assume that it'll always be enough. So functions like GetFullPathName can't just start returning longer names, because it would break those apps. Instead, they rely on the presence of "\\?\" prefix in the input path as an indicator that the calling app understands those longer paths, and is ready to accept them as outputs as well.
I agree, but there are two different issues here (1) \\?\ to bypass the maximum path length limitation; (2) \\?\ to bypass the reserving of file names for devices
You are talking about (1), and I agree it has some problems, yet Microsoft already has an EXE manifest option to bypass maximum path length without \\?\.
Whereas, I am proposing (2), which could exist without (1). They could add an EXE manifest option and/or registry key to tell the Win32 API to ignore bare device names, or device names with extensions, when converting Win32-to-NT paths, even while keeping the MAX_PATH limitation. So you wouldn't need \\?\ to access a file/directory with a reserved device name. But you might still need it to access a long path. The two issues are orthogonal and could be controlled by different settings.
I'd say the better solution is to restrict the feature to only cmd.exe and batch scripts. I am willing to bet that anyone who needs to use it outside of those two cases is running Windows on hardware that doesn't permit software updates and is probably not running anything newer than Windows XP (or even 95).
If anybody knows of anyone using those special files in programs running on modern Windows, I'd love to hear about it.
I reckon somewhere out there, is some obscure program used to control some piece of scientific or industrial equipment, and it talks to that equipment over COM1, and it is just opening "COM1" as opposed to "COM1:" or "\\.\COM1", and it still runs on Windows 10. Rare scenario, few people are going to be impacted by it, but probably somewhere out there is someone who will be. And making it a registry key or EXE manifest option helps to not break that rare software. And I wouldn't assume that systems connected to laboratory or industrial equipment don't get Windows updates; some don't, some do.
Back when uploading Warez to unintentionally open FTP servers was still a thing this was quite handy. Apparently some server software used some low level API to create directories, so you could create folders named LPT1, AUX etc. and put your stuff in there. Many server admins who would usually delete your uploads quickly weren't able to access or delete these folders, and your stuff was up longer.
I used to keep my pr0n in a directory called "NUL" which I would temporarily rename to "XUL" with Norton Disk Editor. That was the only way to see or access the files, until my dad, wondering where the disk space had gone, ran a disk usage utility which read the disk directly instead of going through DOS.
You know that famed backward-compatibility that some folks praise Microsoft for? Yeah, well, this is the dark side of that. I'm curious how much stuff would actually break if one were just allowed to create files called COM1. Sure, someone is out there bit-banging stuff to a serial port with the copy command, but must we all suffer so that those three people don't have to rewrite?
Not COPY, but software that runs on Win9x used those names still for opening devices.
That's why they still work. For the same reason as other DOS Aliases, like C:
If you use UNC paths, you can bypass alias names, because your path will be unambiguous - however if you write such name into one of the "classic" visible name spaces, software that uses classic paths (for example because people are familiar with them, and because rewriting all strings to ensure you use UNC is annoying) might... Find issues ;-)
Oh there are plenty of batch files in DOS and Windows history that COPY SERIAL.TST COM1, just sending RS-232 bytes straight from file to COM1 via good old COPY.
It's not a mistake from 1974. It's a reasonably good bit of design from 1974 that has persisted with very little change since then, even though it no longer is a good bit of design. Now it's sacrificing sanity on the alter of backward compatibility.
But it wasn't insane to begin with. The insane part is never changing it.
Personally I can live with not being able to name a file con.txt, along with the other reserved terms. I guess it would be nice if I could, but I’m more likely to run some old programs than I am to name files using those keys.
One of those tweets prompted me to type "cat /dev/random" to see what happens. Mild panic as I was assaulted by a million lines of rapidly scrolling random text. Not sure what I expected.
Not sure if it still works, but catting /dev/random to a sound device used to be a great way to test that your speakers were working by producing ear-splitting static noise.
Ahh, the fun of opening a diskeditor in DOS, renaming some folder I wanted to hide to AUX then no teacher could access it and see my hidden treasures. Furthermore they couldn't even backup students folder nor delete my folder, and it was DOS running over Novell Netware. My oh my, the talk I had to hear from University rector himself and the jaws they dropped when I rename it back to some other name so they can finally have access to it. 1996, good times.
You don't have to do anything if you're on Windows 10 ver 1607 or later, have `HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled` DWORD=1, and your application manifest declares itself `longPathAware`.
It's null-terminated, so there are no length bytes.
You can have paths exceeding 260 chars for a long time now. The problem is that the older Win32 APIs that deal with files have structs with TCHAR[MAX_PATH] field in them, so changing that length would be a binary breaking change for apps.
So the new APIs allow for longer paths, but code has to be specifically written to take advantage of them. Some languages and frameworks - e.g. Node.js and Python - had that support for a while; others are still catching up.
Reminder that foone hates being linked on HN, so, before you start complaining about the Twitter format, as happens every time foone gets linked, remember that they didn't ask to be here. 99% of the time someone uses a thread unroller when the thread is finished, so if you can't stand going tweet to tweet, scroll down to the bottom and find an unrolled link. Also, foone is non-binary.
In the Windows 3.1 days I saw someone try to save an .eps file of a gaming convention flyer as "con.eps". The screen filled with PostScript and they freaked out.
Hah, I remember causing BSOD everywhere on IRC with that bug and CTCP SOUND when I was a kid. By the way, the list Microsoft published is not the full list of special files. I remember using at least one reserved word that isn't there. I remember using debug.exe on command.com to obtain the full list.
I really enjoy the end of the rant where he says he's been in the hospital for a number of hours in the middle of the night. It was a strange ending, but oddly fitting somehow.
AUX (including AUX.*, in any directory on Windows
) is a special “file” representing a hardware device (by default, tue first serial port, same as COM1); trying to copy to or from a file name matching that pattern results in accessing the device instead.
For legacy reasons, any drive path that ends in a special name, such as `AUX` will be rewritten by Win32 as the NT path `\??\AUX`. This `AUX` is a special device, not a file on the filesystem.
So, for example, `C:\Users\ChrisSD\AUX` will be resolved to `\??\AUX`.
Even more surprisingly, any filename that starts with `aux.` will also be affected by this. E.g. `C:\Users\ChrisSD\aux.txt`.
This is the 1980s holdout that bothers me much more. It's 2021 and Microsoft still clings to three-letter filename extensions? Curiously, they did abandon the 8 in 8.3, but not the 3.
And the TL;DR is that OP found com/aux/nul special names in Windows again. Which is a bit of a stretch to call it a 'mistake' if it was intentional and useful at the time (arguably still today, at least for 'nul').
I thought they found a bug in ALGOL60 code or something, which would have been funny as last week's pentest was written in an arcane language like that and likely last updated around the same time (not something we see every day; quite the opposite in terms of reinventing the wheel actually).
I agree, it's not a mistake or a bug. It's an intentional feature, followed on with intentionally including the feature in further releases.
It might not be a great feature anymore, but it's not a bug. A 40 year old bug is things like TCP didn't have timeouts in all states, so LAST_ACK sockets should stay around forever if you follow the spec, or that if the two peers get mixed up about where the seq and ack are, each ack will elicit an ack from the other side, and if the peers are near enough to each other, that can result in gigabits of useless ack traffic that never results in data exchange (thankfully this isn't a common state; I've only seen it as a result of a bug in one OSes syncookies that was fixed, and it is likely to end with a timeout)
I know people link to Twitter because it's the original source, but why don't we make an exception for Twitter and just link to ThreaderApp when it's a thread?
It's 2021 and I just read an article broken into tiny chunks because of technology invented in 1984, and apparently still bound by its limitations even until this day...
The author chooses to use this medium as a way to share his findings without losing them to his ADHD - if he tried to write a long form blog post it would never be complete.
> so given this is a choice between two options, I can either: 1. make rambly tweet-threads that some people hate and wish were blogs 2. make no blog posts
> I am sorry that I am picking #1, but it's really best for everyone.
There's some leeway in the language there. They say they "kinda wish" that HN was a twitter account so they could block it. That's not really the same thing IMO, that could very well mean they're of two minds on the topic, or it could mean they just threw in "kinda" without thinking about it. Have they been more explicit elsewhere?
From a look at your posting history, you're just jealous because you ARE that guy, who goes out of his way to be an asshole, then pretends he's the victim, while actually being a childish bully. Your pathologically obsessive focus on certain other people's issues makes it transparently obvious to anyone who's not you, that you have a lot of your own deep issues that you haven't dealt with.
Fun times we live in where a system pretty much designed primarily for attention seeking over effective communication now can be deemed some kind of private/protected space. This is classic manipulative behavior though, make a big scene in a public forum and then claim your privacy is being invaded. If you don’t want the attention, delete it.
They never claimed their privacy was being invaded. They simply asked (allegedly? I haven't seen any actual request from them but lets just assume there is one) not to be linked to from HN.
They aren't manipulating anyone... they're just making it known they'd prefer not to be linked to from another platform.
Is this a reasonable expectation? I'm not sure -- my gut says probably not. Is it a reasonable request? IMO yes.
Contrived scenario for expository purposes: lets say I'm an expert in pre-civil war era southern cuisine. If I find out that people on stormfront are linking to and discussing my posts for their own agenda, do I have a right to make them stop? Of course not. Is it reasonable for me to say "I'd prefer if your platform didn't link to my blog"? Of course it is.
This goes against the purpose of the internet. It is not a reasonable request at all. He doesn’t pay for the bandwidth, he posted thoughts on a public forum, and people felt they were notable enough to be shared to another public audience. Reap what you sow.
In my opinion, it's a totally reasonable request. It's not a reasonable expectation, but that is a different matter. I'm not sure what the 'purpose of the internet is' but I don't think Al Gore had such a request in mind when he invented the internet.
It is a reasonable request to ask your neighbor to take down their billboard that says "THE GUY NEXT DOOR WROTE ${THIS} BLOG POST AND IS A REAL PIECE OF SHIT", even though they aren't obligated to do so. It becomes unreasonable when you expect that they take it down.
FWIW, calling somebody a piece of shit goes against personal insult laws in many countries, so in your particular example, the neighbor may in fact be obligated to take down the billboard, or at least to modify it.
FWIW there are few expressions of free speech that aren't in violation of some arbitrary law enforced by some arbitrary country. It was probably short-sighted of me to assume that my exaggerated example wouldn't be recognized as hyperbole, but honestly what is the point of this comment?
Everything depends on jurisdiction, that's the very nature of law in and of itself.
It's an interesting question though. I feel like in this case the right thing to do would be to stop linking to his twitter.
But what if he was a "bad" (in quotes) guy? Like the CEO from the recent repl.it debacle. What if he asks to stop linking to his bullying tweets? Nobody would side with him.
So.. where's the line? Is anything public fair play? Who decides if someone is bad or good? The collective internet mob? Surely nothing can go wrong with that.
Foone is more than competent enough to publish to the web with whatever access control they find agreeable. jwz is, as well, and doesn't like being linked from
HN either, for example.
Posting on Twitter publicly is consent to be linked to, regardless of what other words are said.
That doesn't mean you're not being a jerk by going against someone's preferences.
If you invite people to a party, are you the jerk for telling the person you know to be vegan that by going to the party they consent to having to eat meat? Clearly, the vegan person could simply not go to the party and not consent to it, but it still kinda makes you a jerk for even making this a problem, you could have either made a vegan meal or not invite them (and inform them why if they're a close friend maybe).
> Clearly, the vegan person could simply not go to the party and not consent to it, but it still kinda makes you a jerk for even making this a problem, you could have either made a vegan meal or not invite them
I think not inviting someone to a meat party because they're vegan is way more of a jerk move than saying "hey, I'm having a meat party, I know you're vegan but you can still come if you want" and them not coming. Give people the option to make their own choices.
Foone chose to publish things unauthenticated to the web on Twitter. That's affirmative consent to anyone on the web reading the URL by visiting it.
>That's affirmative consent to anyone on the web reading the URL by visiting it.
No it's not. It means it's out there but the wishes of a person may still go contrary. That is perfectly fine and like in the above example, maybe you should give people options instead of taking them away.
It seems like more and more links to Twitter being submitted to HN. This is inconvenient for me as I do not use Twitter's GUI. I do not like the way Twitter uses Javascript and tries to force users to enable it.
Here is a temporary solution to I am using to fetch the JSON from the command line and make simple HTML. I did try Nitter but found that sometimes instances were exceeding rate limits.
Without logging in to Twitter, if you look at the HTTP and HTML sent from twitter.com when you make a request (I try to log all traffic to/from my computers), you will see the exact same token. There's nothing "secret" about this header. Thus, there's nothing to censor. I have seen it in other people's code as well. It gets sent to everyone who visits twitter.com.
Not a huge fan of the blog-post-by-twitter-thread pattern.. read the first 6 posts, the. Need to click to read more, then find out it's 50+? tweets long?
Might be interesting, but feels like the wrong format.
It's interesting that the author mentions ADHD as a reason to not post full blog posts.
I don't have ADHD but I certainly find a Twitter thread much more distracting than a blog post to read. I need to untrain my mind that the entire message isn't done by the end of the tweet. And ignore all the other crap that Twitter is trying to get me to click on in the trending topics. I have to be extremely interested in a Twitter thread to read it. It's just a horrible format.
HN is basically what amounts to my blogging platform for the same reason as foone.
It's the only place that I come back to consistently for enough novel scraps of textual information to hold my attention, the community and culture is welcoming enough for the most part, and the comment box is a single click from the home page. By the time my attention has shifted to article X and the following HN discussion, I usually have enough mental inertia to leave my thoughts at that point. It's a different mindset than if I had to use a separate website to write blog posts on, without any sort of original context.
I remember there was an HN post about static websites and it was filled with comments about how people were wanting to get around to setting it up but they had to go through hosting and theming, and were ultimately sucked into the trap of overengineering. Depending on how your brain is built, for some people this kind of problem is not just a minor annoyance they could solve on any given day, but a persistent obstacle.
But then I could just ask: "Do I actually care about writing?" I would say, to a certain extent, yes. I want recognition that my thoughts existed at one point, inside this mind that's a part of me, regardless of what medium they were conveyed with. If HN commenting is the only form of writing that holds my attention long enough for me to get my thoughts out of my head, then I don't see a problem with it. Otherwise a lot of the parts that make up my whole would die with me, all alone.
I'm sure some of what I've written would make good blog posts if I got around to researching and editing for more than a single session. But because that's not how I write, if I want my voice to be heard then this is about the only way that works consistently enough for me: writing it all at once, before my interest fades and I forget about it later.
So I have a lot of sympathy towards the author. I personally would not use Twitter for this purpose, because it feels like screaming into the void to me, and I wouldn't expect the same kind of responses I could receive on HN, but I share much the same sentiment.
I agree with this so much and I have my own blog already. It's hard to come up with unique content and I think my writing excels when I'm replying to something - when someone else has written something and I feel like I can contribute to the conversation.
I guess I could link things I want to reply to in my blog, sort of like Daring Fireball, but without an existing readership it seems really lame to try to force it when I can reply in an HN or Twitter comment instead.
If you're patient enough, you can not provide a phone number, then get your account blocked due to suspicious activity. Then you can appeal. Then get blocked again and appeal. Two-three times. Eventually they'll allow you to exist without a phone number. For some time.
The problem was introduced, IIRC, in MS-DOS.