But, although FAT32 does indeed have the virtue of relative simplicity, that's no excuse for VFAT.
FAT32 is a variant of FAT introduced in the mid 90s with Windows 95 OSR2 that better supports large hard drives (beyond size limits, cluster sizes were getting too large on FAT16 drives etc.).
The reality, certainly in respect of the headlined subject, is that the bitness of the FAT and the style of the root directory (fixed location or variable length) are the only meaningful variants. In 2026, no-one aims not to support long filenames on FAT, and EFI understands them natively. EFI copes with all three bitnesses. And it does the conventional thing of variable length root directory on 32-bit and fixed-length root directory on 16-bit and 12-bit.
FAT is a very poor filesystem format, and no, it's not a minimum filesystem format if one is writing one's own operating system. It's a lazy filesystem format, inasmuch as the cross-development tooling for it exists. But if one were writing a minimum filesystem for one's own operating system, one could start from much better places. FAT is not minimal by any reasonable definition even if one is not writing one's own operating system, and requires an awful lot of hoops to be jumped through that are only there because one is being compatible with the cross-development tooling, several decades of historical changes, and whatnot.
One could use the original UFS, for example. LEAN exists. Over 20 years ago, I invented HPFS2.
Given that normally UEFI only needs to read the filesystem, not write it, I think a more appropriate filesystem might be something like ZIP.
I wonder when Microsoft will stop being a "UTF-16 house" adding UTF-16 to new projects... They did it again to LSP, and that was in 2016. Maybe by 2045 Microsoft will use UTF-8 for new projects, and then by 2100 we can switch to UTF-8 by default.
[0] https://learn.microsoft.com/en-us/gaming/gdk/docs/gdk-dev/ov...
That one is explainable by the fact that it was developed for VS Code, a typescript/javascript project. Javascript uses UTF-16 for strings (for historical reasons unrelated to Microsoft, though they are the same reasons that made MS use UCS-2 during the same time period).
I don’t think the spec requires that. charAt indexes on UTF-16 code points, but I don’t remember ever seeing that it has to do that in O(1) time, so that doesn’t imply the implementation has to use UTF-16 internally.
Also, for modern JavaScript, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... says:
“Note: Avoid re-implementing the solutions above using charAt(). The detection of lone surrogates and their pairing is complex, and built-in APIs may be more performant as they directly use the internal representation of the string. Install a polyfill for the APIs mentioned above if necessary.”
Because of that, I would hope most modern implementations to at least have a variant internal representation that is similar to UTF-8.
> UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.
I was trying to say: If all the components in your stack are javascript-based, it makes sense that your RPC-API would also use UTF-16. It wasn't Microsoft pushing it for historical Windows reasons as GP implied, it was dictated by a JS stack they chose but didn't create.
Then I finally sat down to understand enough JS for LLM slop and the having rockets all over the place wasn't just cringe but the quickest way to show you handled utf 16.