Comment by kragen
21 hours ago
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?
4 replies →
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.
3 replies →