Linked by Thom Holwerda on Tue 19th Nov 2013 23:28 UTC, submitted by Anonymous
General Development

A couple nights ago I was looking over the UEFI spec, and I realized it shouldn't be too hard to write UEFI applications in Rust. It turns out, you can, and here I will tell you how.

Language gets me giddy, but thank god lots of other people get giddy over stuff like this.

Thread beginning with comment 577125
To read all comments associated with this story, please click here.
UEFI using UTF-16
by Desiderantes on Wed 20th Nov 2013 12:10 UTC
Desiderantes
Member since:
2012-04-14

Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings

Reply Score: 2

RE: UEFI using UTF-16
by saso on Wed 20th Nov 2013 13:40 in reply to "UEFI using UTF-16"
saso Member since:
2007-04-18

Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings

It's actually worse, because it's not even UTF. It's just stupid UCS-2 limited to 16 bits. So it's a mistake on top of a mistake.
The UEFI code signing structures are also MS-derived, to the point where the structure members start with 'win'.

Reply Parent Score: 3

RE: UEFI using UTF-16
by dnebdal on Wed 20th Nov 2013 14:09 in reply to "UEFI using UTF-16"
dnebdal Member since:
2008-08-27

Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings


There's two different 16-bit unicode encodings:
UCS-2 uses two bytes per character, and can thus encode codepoints up to 65536 (the Basic Multilingual Plane, BMP - also known as plane 0).
UTF-16 uses two bytes per character, but also has escape codes that can be used to encode 32-bit codepoints.

UEFI uses UCS-2. On the positive side, it's easy to work with (strings take fixed amounts of space, and it's trivial to cut/paste at positions that leave valid strings), and the lower 64k of unicode still covers enough to cover all modern languages. It's also got decent language support - even C has wchar (for a 16 or 32bit single character) and supporting functions.

On the negative side, it can't encode the higher planes of unicode (which would allow e.g. using unicode symbols instead of bitmaps ; the emojis are encoded in plane 1), and it's considered obsolete, superceded by UTF-16. There's also some extensions to the CJK range; I don't honestly know if those are in daily use or if they're historical variants for scholarly purposes.

Everything considered, UCS-2 isn't a horrible choice for something like this, since it's simple to work with while still covering all the characters needed to present text in currently-used languages (modulo the CJK extensions - but I suspect those aren't required for decent enough everyday Chinese/Japanese/Korean.)

Edited 2013-11-20 14:21 UTC

Reply Parent Score: 4

RE: UEFI using UTF-16
by Alfman on Wed 20th Nov 2013 15:30 in reply to "UEFI using UTF-16"
Alfman Member since:
2011-01-28

Desiderantes,

"Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings."

Like others said, it uses UCS-2, which was the standard text coding used up through windows 2000.

Another example of mandated legacy microsoft tech in the UEFI standard is FAT32. It's reasonable to support fat32 on the basis that's it's already common for removable media (aka thumb drives). However it's a real shame UEFI didn't include a standard vendor neutral file system like UDF to provide a non-breaking migration path away from FAT32. Even windows already supports UDF disks formatted elsewhere. Paint me unsurprised, now we're stuck with legacy FAT32 due to UEFI compatibility restraints.


http://en.wikipedia.org/wiki/Universal_Disk_Format

Reply Parent Score: 2