For "Get used to the lack of a C standard library" mentioned in https://kevinboone.me/efitest4.html there's always https://github.com/tianocore/edk2-libc.
And on "Be aware of the Windows-ness of EFI" commentary the resemblance to Windows coding style https://computernewb.com/~lily/files/Documents/NTDesignWorkb... is no accident. We leveraged this coding methodology as we evolved the original Intel Boot Initiative then EFI and then UEFI code and specification https://www.intel.com/content/dam/www/public/us/en/documents...
There's also https://libc.llvm.org/uefi/index.html, but not sure if it's still receiving updates.
Be aware EDK II has a recent severe CVE to watch out for.
https://app.opencve.io/cve/CVE-2026-97631
That's just in the PXE driver AFAIK.. shouldn't be an issue here.
I think "leveraged this coding methodology" is an unjustifiably positive way to describe the results of the process. I think "spread this disease" would be more accurate. UTF-16 strings, really? VFAT? PE32+ is maybe justifiable (I'd prefer ELF, but that's because it's more familiar, not because it's actually better), but VFAT? And even in 01998 it should have been apparent that UTF-16 was not a sane format for strings, much less in 02005 when the EFI → UEFI transition happened.
To me, UEFI is like "leveraging the waste disposal methodology" of dumping your toxic waste in a lake. Yes, it's more convenient for you, but it does lasting damage and causes years of suffering for millions of people; and eventually somebody else has to clean up your mess, at far greater cost than if you'd just done something sensible to begin with.
I could probably say the same thing about X-Windows.
I've never _actually_ implemented a filesystem, but when researching OS dev it seemed like FAT32 was pretty close to what you'd write as a minimum viable filesystem while being a very well known quantity.
Yes, I think that's a fair assessment, although the fractal of stupid runs deep in FAT32: a separate 5-bit field for seconds within a minute? Separate fixed-width fields for filename and extension? A 4 GiB file size limit?
But, although FAT32 does indeed have the virtue of relative simplicity, that's no excuse for VFAT.
I might be unfamiliar with the terms - is there a distinction between FAT32 and VFAT?
VFAT is the way that some operating systems implement long filenames in FAT - PROGRA~1 and whatnot. It's pretty messy.
Windows 95 introduced long filenames to FAT, and implements the file system in the VFAT.VXD driver. “VFAT” is thus sometimes thus shorthand for FAT with “Windows style long filenames”. It can be applied to all variants of FAT, such as FAT16 and FAT32.
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.).
Not really, no. Linux regards various ways of looking at the same on-disc filesystem format as distinct filesystem types: msdos, umsdos, vfat. Old Microsoft doco from the 1990s that is still lying around explains things in the way that they historically progressed rather than structurally, describing VFAT as an extension of FAT32.
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.
* https://jdebp.uk/Proposals/hpfs2.html
HPFS2 looks appealing. Did you implement it? And what were the design blunders in LEAN you decided not to go into in the footnote?
Given that normally UEFI only needs to read the filesystem, not write it, I think a more appropriate filesystem might be something like ZIP.
In the eternal words of the Microsoft Game Development Kit docs[0], "Windows operates natively in UTF-16 [...]. This is a unique burden that Windows places on code that targets multiple platforms."
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...
> They did it again to LSP, and that was in 2016.
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).
> Javascript uses UTF-16 for strings
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.
https://en.wikipedia.org/wiki/UTF-16
> 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.
Absolutely, UTF-16 is bad and inexcusable in most contexts. Perhaps you misinterpreted my comment or I wasn't expressing myself properly.
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.
I understood, I was just providing context. Windows, JavaScript, Java are all UTF-16. 65k characters is all you need.
I always thought the js libraries throwing emojies around was stupid.
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.