6 ms·

Makes me sad to realise just how much of EFI, the new universal standard, was dictated by Microsoft norms (UTF16, binary format, etc)

dbaupp 13y ago
Yeah, the author even had to add support for the appropriate calling convention (win64) to the compiler[1] to get it to work. [1]: https://github.com/mozilla/rust/pull/10527 https://github.com/mozilla/rust/pull/10527 not yet landed.
- orf 13y ago
  That was hardly challenging, look at the number of changes.
  - dbaupp 13y ago
    I didn't say it was challenging. (And yes, most of the changes are actually fixing a different bug, not just adding support for the new ABI.)
- eholk 13y ago
  To be fair, Rust probably would have needed this for some other reason in the future. I see this more as making Rust a more complete language.
Xylakant 13y ago
I fail to see the major issue here: The standard needed to specify those points, otherwise one EFI implementation would expect UTF8, another ASCII and yet another UTF-16. The calling conventions, the binary format and UTF-16 are widely supported across platforms and known. Windows calling conventions are probably more widely implemented than any other (since the popular linux compilers can cross compile to win and not the other way round). Just because Rust had no support for the windows calling conventions that doesn't imply that C for example has the same problem. UTF-16 is used in different places as well, notably in Java. No problem here as well. It also has the major advantage of being a fixed width encoding over UTF8. That might be fairly useful when your code doesn't have full OS and library support when running. All in all: It's probable that Microsoft influenced the standard here, but there's also sufficient technical reasons for those choices. There's other places where Microsofts influence on the standard is a much bigger problem.
- masklinn 13y ago
  > The standard needed to specify those points Yes, the problem is those which were specified. > The calling conventions, the binary format and UTF-16 are widely supported across platforms and known. The calling conventions are W64's, which is by far the least common across platform (especially since the AMD64 ABI defines calling conventions) > UTF-16 Is a shit encoding and there is no justification for such a technical low-level API to use it[0]. > UTF-16 is used in different places as well, notably in Java. Not a justification (unless you also assert that most UEFI applications will be written in Java), explained by Java (and Windows NT) having standardized their Unicode implementation between Unicode 1.0 and Unicode 2.0, 20 years ago. UEFI was not created 20 years ago, that it bears the trace of that event is a disgrace. Plus technically Java does not use UTF-16, it's UCS2. Support for astral plane codepoints and APIs taking surrogate pairs in account were only introduced in JDK 1.5, separately from the old UCS2 APIs (including char, which remains a code unit) > It also has the major advantage of being a fixed width encoding over UTF8. You're high as a kite[2], UTF-16 is no more fixed-width than UTF-8, and UTF-16 implementations are far more commonly broken than UTF-8 ones as 1. astral planes support is rarely exercised and 2. they have to contend with the UCS2/UTF16 duality. > All in all: It's probable that Microsoft influenced the standard here, but there's also sufficient technical reasons for those choices. I assert that there is no technical justification whatsoever for the choices of calling conventions and encoding beyond "it's how Windows works and we couldn't be arsed to do things correctly". [0] the only potentially acceptable justification for UTF-16 is low-markup asian script[1] with a vast majority of codepoints living in the upper segments of the BMP (U+0800 to U+FFFF) and encoded as a single UTF-16 code unit but as 3 UTF-8 code units. This is pretty much irrelevant to UEFI. [1] mostly, some african and american scripts also live there [2] no seriously, personal attacks may be bad but when you assert UTF-16 is a fixed-width encoding — even ignoring that Unicode makes the concept laughably useless — you're in a separate plane of reality than just about all of humanity.
  - forgottenpass 13y ago
    Plus technically Java does not use UTF-16, it's UCS2. Well then I've got good news! EFI, too, also means UCS2 when it says UTF-16 in the spec.
forgottenpass 13y ago
EFI even talks FAT and there exists licensing such that you can use FAT for EFI reasons without any patent worries. I'm not saying that's a bad decision, just pointing out it is another thing that happened. I heard that fact in a linux.conf.au talk by the guy what did UEFI work for linux [0]. If you're sad to hear about the Microsoft influence, dude isn't too hot on the implementation of this new standard in general. Interesting talk though, digging up the link to post it here means I'm going to give it another watch. [0] EFI and Linux: the future is here, and it's awful - Matthew Garrett http://www.youtube.com/watch?v=V2aq5M3Q76U http://www.youtube.com/watch?v=V2aq5M3Q76U
- Aloisius 13y ago
  EFI even talks FAT and there exists licensing such that you can use FAT for EFI reasons without any patent worries. Surely all the patents on FAT have expired by now regardless. Even FAT32 was introduced 17 years ago.
- daurnimator 13y ago
  Thanks for the reminder about that talk; I was actually in the audience for it :)
deleted 13y ago
[deleted]

dbaupp 13y ago

Yeah, the author even had to add support for the appropriate calling convention (win64) to the compiler[1] to get it to work. [1]: https://github.com/mozilla/rust/pull/10527 https://github.com/mozilla/rust/pull/10527 not yet landed.

orf 13y ago
That was hardly challenging, look at the number of changes.
- dbaupp 13y ago
  I didn't say it was challenging. (And yes, most of the changes are actually fixing a different bug, not just adding support for the new ABI.)
eholk 13y ago
To be fair, Rust probably would have needed this for some other reason in the future. I see this more as making Rust a more complete language.

Xylakant 13y ago

I fail to see the major issue here: The standard needed to specify those points, otherwise one EFI implementation would expect UTF8, another ASCII and yet another UTF-16. The calling conventions, the binary format and UTF-16 are widely supported across platforms and known. Windows calling conventions are probably more widely implemented than any other (since the popular linux compilers can cross compile to win and not the other way round). Just because Rust had no support for the windows calling conventions that doesn't imply that C for example has the same problem. UTF-16 is used in different places as well, notably in Java. No problem here as well. It also has the major advantage of being a fixed width encoding over UTF8. That might be fairly useful when your code doesn't have full OS and library support when running. All in all: It's probable that Microsoft influenced the standard here, but there's also sufficient technical reasons for those choices. There's other places where Microsofts influence on the standard is a much bigger problem.

masklinn 13y ago
> The standard needed to specify those points Yes, the problem is those which were specified. > The calling conventions, the binary format and UTF-16 are widely supported across platforms and known. The calling conventions are W64's, which is by far the least common across platform (especially since the AMD64 ABI defines calling conventions) > UTF-16 Is a shit encoding and there is no justification for such a technical low-level API to use it[0]. > UTF-16 is used in different places as well, notably in Java. Not a justification (unless you also assert that most UEFI applications will be written in Java), explained by Java (and Windows NT) having standardized their Unicode implementation between Unicode 1.0 and Unicode 2.0, 20 years ago. UEFI was not created 20 years ago, that it bears the trace of that event is a disgrace. Plus technically Java does not use UTF-16, it's UCS2. Support for astral plane codepoints and APIs taking surrogate pairs in account were only introduced in JDK 1.5, separately from the old UCS2 APIs (including char, which remains a code unit) > It also has the major advantage of being a fixed width encoding over UTF8. You're high as a kite[2], UTF-16 is no more fixed-width than UTF-8, and UTF-16 implementations are far more commonly broken than UTF-8 ones as 1. astral planes support is rarely exercised and 2. they have to contend with the UCS2/UTF16 duality. > All in all: It's probable that Microsoft influenced the standard here, but there's also sufficient technical reasons for those choices. I assert that there is no technical justification whatsoever for the choices of calling conventions and encoding beyond "it's how Windows works and we couldn't be arsed to do things correctly". [0] the only potentially acceptable justification for UTF-16 is low-markup asian script[1] with a vast majority of codepoints living in the upper segments of the BMP (U+0800 to U+FFFF) and encoded as a single UTF-16 code unit but as 3 UTF-8 code units. This is pretty much irrelevant to UEFI. [1] mostly, some african and american scripts also live there [2] no seriously, personal attacks may be bad but when you assert UTF-16 is a fixed-width encoding — even ignoring that Unicode makes the concept laughably useless — you're in a separate plane of reality than just about all of humanity.
- forgottenpass 13y ago
  Plus technically Java does not use UTF-16, it's UCS2. Well then I've got good news! EFI, too, also means UCS2 when it says UTF-16 in the spec.

forgottenpass 13y ago

EFI even talks FAT and there exists licensing such that you can use FAT for EFI reasons without any patent worries. I'm not saying that's a bad decision, just pointing out it is another thing that happened. I heard that fact in a linux.conf.au talk by the guy what did UEFI work for linux [0]. If you're sad to hear about the Microsoft influence, dude isn't too hot on the implementation of this new standard in general. Interesting talk though, digging up the link to post it here means I'm going to give it another watch. [0] EFI and Linux: the future is here, and it's awful - Matthew Garrett http://www.youtube.com/watch?v=V2aq5M3Q76U http://www.youtube.com/watch?v=V2aq5M3Q76U

Aloisius 13y ago
EFI even talks FAT and there exists licensing such that you can use FAT for EFI reasons without any patent worries. Surely all the patents on FAT have expired by now regardless. Even FAT32 was introduced 17 years ago.
daurnimator 13y ago
Thanks for the reminder about that talk; I was actually in the audience for it :)

deleted 13y ago

[deleted]