Why Windows uses file extensions to determine file type

Just mentioning "file extensions" should make everyone flinch: they've been a source of confusion and security problems for the entire existence of Windows.

This article does nothing to make me feel better about "file extensions", in that Mr Chen, for all of this authoritative knowledge of Windows, makes one of the big mistakes about "file type" that have plagued Windows. What is "file type"? Is is "binary file" vs "text file"? Is it "executable file" vs "data file"? Is it "input file for Excel" vs "input file for Word" vs "input file for $X"? Or is is something weird like in old VMS ODS-11 files, fixed-length records vs variable length records which is a very basic "type", which could be characterized as "disk hardware level organization".

Microsoft has done nothing over the years to make this easier. "Extensions" like "COM" and "EXE" and some other undocumented list of extensions make a file executable to the operating system. Having file explorer (or whatever it's called these days) hide the extension has led to people getting fooled into running "porn.jpg.exe" trojan horses.

File extensions: a debacle in many acts. I guess this article clears up some of the more obvious aspects, but does nothing overall.

Ah. Over thirty years ago, I worked with Data General's AOS/VS operating system. I remember very well transferring a source file to another system and finding that it would not compile, and gave me an odd message to explain with its refusal. Somehow I learned that the compiler checked to see the type of the file--there were ~255 of them, I think, and on finding that it was FIL and not SRC, rejected it. The cure was to

CREATE/type=SRC newfile.c COPY/A newfile.c oldfile.c

I know that I was not the last person caught by this, because someone emailed me to say that the source file I had sent him wouldn't compile.

(File types and CLI syntax are not guaranteed.)