Memory is a fickle thing, but the format dialog enforcing a FAT32 limit is probably Dave's biggest failing when it comes to telling old stories.
I don't know if FAT32 was in development in late 1994, it's possible, but it sure didn't ship in Windows NT 4, nor the original Windows 95. Even when it did land in Windows 95 OSR2, the format command happily accepted partitions up to 128GiB; but okay, Windows 95 isn't NT.
Windows 2000's internal formatting functions appear to be the real reason FAT32 is limited to 32GiB on new formats. The GUI, format command, and diskpart are all equally incapable of creating a >32GiB file system. Why? Who knows, it's not like drives of that size or larger didn't already exist at the time. If you use, say, mkdosfs on Linux, the VFAT driver in Windows 2000+ will take volumes up to 2TiB, you can even install Windows 2000 on such large volumes.
> are all equally incapable of creating a >32GiB file system. Why? Who knows,
Win95osr2 could format FAT32 volumes up to at least 128GiB IIRC, the 32GiB came when the filesystem was officially added to the NT line in Windows 2000⁰.
Part of the reason, I always assumed, was to push people to use NTFS where they otherwise wouldn't, which gave MS a bit of lock-in because NTFS wasn't particularly stable on Linux at the time. ExFat as a compromise didn't exist until a fair while later either.
> If you use, say, mkdosfs on Linux, the VFAT driver in Windows 2000+ will take volumes up to 2TiB
2TiB is only the limit if you stick to 512 byte blocks, the filesystem supports up to 4096 byte blocks giving 16TiB. Some filesystem tools didn't like this, and the larger cluster sizes could be very wasteful of space for small files³, so it was often avoided. I don't know if the Linux tools supported this from the start, but they certainly did eventually.
--
[0] there was at least one common 3rd a party driver, from sysinternals to support it on NT4
[1] for safety the most common methods for using NTFS under Linux defaulted to read-only, then and for some time after
[2] sometimes to the extent of causing corruption rather than just refusing to work
[3] the main reason to use FAT32 over FAT16 at the time⁴ being that above 32MiB the cluster size needed to increase about the minimum 512B, up to 32KiB for 2GiB filesystems⁵ meaning an average of 16KiB wasted per file.
[4] later the 2GiB limit⁵ was more significant as drive sizes grew
[5] 4GiB was possible with 64KiB blocks though while officially supported by the format this was not supported by all tools
> 2TiB is only the limit if you stick to 512 byte blocks, the filesystem supports up to 4096 byte blocks giving 16TiB.
Aye, I'm aware, but a 16TiB FAT32 file system in that configuration is only usable on Linux, at which point... why? Use exFAT in that range!
Windows NT 5.x's storage drivers don't support hard disks larger than 2TiB, and there's nothing to do about that. It puts the upper limit of FAT32 on those systems at 2TiB.
IIRC FAT32 supported larger sectors in part for future proofing. It was made because of storage length limits on its predecessor so it makes sense that the devs were very conscious of the need.
Also some storage systems are more efficient speed-wise with larger sectors (though if that was a concern for you, you probably weren't using FAT<anything>). It also made switching between 16 & 32 in-place easier, though I can think of a reason off the top of my head why you would want/need to, and none of the standard tooling could do that.
As an aside, and connected to the failing memory thing, Raymond Chen has repeated multiple times that Space Cadet Pinball couldn't get working on a 64-bit build and never shipped with any version of Windows, and that's why it was gone in Vista. Windows XP Professional x64 Edition has a working 64-bit native build of Pinball.
Well, it was a game from 1995 and wouldn't fit in with Vista's style revamp. Even the old Minesweeper and Solitaire games became Direct3D accelerated in Vista. Maybe the effort to do the same overhaul to Pinball was discarded, but the idea that a 64-bit native build couldn't get working is absurd when the previous Windows version included the very thing.
There were issues with Pinball on "Windows XP 64-bit Edition", or the Itanium version. A great video explaining this is https://youtube.com/watch?v=3EPTfOTC4Jw
I don't know if FAT32 was in development in late 1994, it's possible, but it sure didn't ship in Windows NT 4, nor the original Windows 95. Even when it did land in Windows 95 OSR2, the format command happily accepted partitions up to 128GiB; but okay, Windows 95 isn't NT.
Windows 2000's internal formatting functions appear to be the real reason FAT32 is limited to 32GiB on new formats. The GUI, format command, and diskpart are all equally incapable of creating a >32GiB file system. Why? Who knows, it's not like drives of that size or larger didn't already exist at the time. If you use, say, mkdosfs on Linux, the VFAT driver in Windows 2000+ will take volumes up to 2TiB, you can even install Windows 2000 on such large volumes.