Nothing to do with floppy disks per se. 8.3 filenames were a limitation of the 16-bit version of FAT; FAT32 introduced longer filenames but each file had an 8.3 alias which was used for compatibility with applications that hadn't been updated for FAT32. Not just on floppies, but hard disks too. Pretty sure it applied similar logic to non-FAT filesystems too, like NTFS, CD-ROMs, SMB shares, etc. The feature is likely still in existence, but applications that still use FAT16 API calls will be vanishingly rare.

8.3 filenames were a limitation of the 16-bit version of FAT; FAT32 introduced longer filenames but each file had an 8.3 alias which was used for compatibility with applications that hadn't been updated for FAT32. Not just on floppies, but hard disks too.

Technically speaking, the FAT size does not matter at all. FAT12, FAT16, and FAT32 all use 8.3 at their core. The so-called "long" filenames that also allow more characters than plain old MSDOS in filenames are implemented on top of the 8.3 names, by creating extra directory entries to store the "long" filename. This is usually called VFAT. Note that VFAT does not create a "long" alias name for names that are 8.3 compatible (i.e. all upper case, restricted character set).

More details: File Allocation Table, Long Filename, VFAT design

Note that a "long" filename may actually be shorter than 8.3. This happens when it contains characters not allowed in the 8.3 core, like spaces.

Pretty sure it applied similar logic to non-FAT filesystems too, like NTFS, CD-ROMs, SMB shares, etc.

NTFS can use up to 255 16-bit value except for 0 in Filenames (NTFS), it can operate case-sensitive and case-insensitive. Windows creates 8.3 aliases for all names not fitting into 8.3, you can see that by running dir /x on an NTFS volume.

CDROMs usually use ISO 9660, which has three restriction levels for filenames. Level 1 is 8.3 for filenames, up to 8 characters for directory names. Level 3 allows 31 characters for directories, 30 characters for files, including extension. Also, file names, file extensions, and directory names are limited to /^[A-Z0-9_]+$/, additionally a single dot is allowed for files. Directories may not nest deeper than 8 levels.

On top of that, Rock Ridge extensions implement essentially a fully-featured Unix filesystem with allow longer names, more characters, less restrictons, deeply nested directories, symlinks, device files, file modes, etc.

Joliet (file system) does roughly the same for Windows, with UTF-16 characters and longer filenames.

SMB shares on Windows export more or less just the underlying filesystem, including the 8.3 short name aliases. SMB shares from Samba fake that pretty well, including completely virtual 8.3 aliases for file names not compatible with 8.3. Try running dir /x on a Samba share. You will see 8.3 aliases that actually do not exist on the host filesystem.

The feature is likely still in existence, but applications that still use FAT16 API calls will be vanishingly rare.

There is nothing like a FAT16 API for filenames. Windows (starting at Windows 95) simply allowed longer names using the same API functions as before, and added functions like GetLongPathName() and GetShortPahName() to convert between "long" and 8.3 names.

Using the 8.3 names may help in cases where path names are too long for the normal API functions. Some people tend to name files and directories using literally hundreds of characters. Using the usually shorter 8.3 names allows to copy those directory trees, see deepcopy.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Yes, that is correct.
Floppies used the FAT file system instead of NTFS. I don't know for sure, but if I installed a floppy disk on my Win 10 system and formatted a disk, it would probably format it with the FAT32 file system. Most Win 10 systems don't have floppy disk hardware - mine doesn't. The floppies FAT32 file system would accept a long filename.

I don't see the need to pass a 8.3 filename unless your are trying to run an ancient app in the "DOS BOX".

(PC DOS) Floppies are always FAT12. If Windows 10 formats one with FAT32, then Microsoft is up to their old tricks again — nothing else will read that.

use strict;
use warnings;
my $browser = 'C:\Program Files\Internet Explorer\iexplore.exe';
$browser = '"' . $browser . '"';
#my $browser = 'C:\PROGRA~1\INTERN~1\iexplore.exe'; #workaround
exec $browser;
[download]

The windows shell requires double quotes around paths which contain spaces

This doesn't accurately describe Windows behaviour. In the cmd.exe shell (on Windows 7) I can do:

C:\>mkdir "with a space"

C:\>cd with a space

C:\with a space>
[download]

Sure, the first command needed the quotes. Otherwise I create 3 directories - namely "with", "a", and "space".
But the second command does not need any quotation at all.

Contrast this with the bash shell on Debian:

sisyphus-sis@debian-sis:~$ mkdir "with a space"
sisyphus-sis@debian-sis:~$ cd with a space
-bash: cd: with: No such file or directory
sisyphus-sis@debian-sis:~$ cd "with a space"
sisyphus-sis@debian-sis:~/with a space$
[download]

There's a similarity with Windows - without the quotes in the first command, directories "with", "a" and "space" will again be created.
However, here we see that, unlike the Windows cmd.exe shell, the Debian bash shell also requires quotes for the second (cd) command.

It therefore seems to me that your assertion is more applicable to Debian than to Windows.

Cheers,
Rob

C:\>cd with a space

C:\with a space>
[download]

I think this is a very special case in cmd.exe (and maybe also in command.com): cd/chdir needs exactly one parameter since MS DOS 1.0, so if it is passed more than one, cmd.exe silently combines them into a single parameter.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Win32::ShellQuote