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". ;-)
