3 ms·

You need two versions of functions. You need two modes for lots of text programs to use. It doubles the space for things like storing identifiers for programmin

by malkia 13y ago

You need two versions of functions. You need two modes for lots of text programs to use. It doubles the space for things like storing identifiers for programming languages, which normally would use up to 7 bits (for big percentage of the languages). UTF-8 can work with all 7-bit ASCII characters, and that's what it's great about it.

asveikau 13y ago
> You need two versions of functions. For Windows this is entirely a compatibility thing. One could imagine a world in which that was not strictly necessary. A good best practice for a Win32 app is to always use 16-bit strings when calling system APIs and pretend the "ANSI" versions don't exist; I would not recommend anything else. In NT the 8-bit versions generally do nothing but convert to 16-bit and call the "real" function. In recent versions (I think Win7 was the first to do this), AFAIK the 8-bit shims typically exist in another module, so if you don't use them they don't get loaded. In NT on ARM the 8-bit shims are not even there. > It doubles the space for things like storing identifiers for programming languages Which is why GetProcAddress() still takes an 8-bit string. Just because the kernel (and hence the syscall interface) uses 16-bit everywhere doesn't mean you can't use 8-bit strings in your own process, or that you can't selectively pick what makes sense for your use. (By the way, none of what I'm saying is a criticism of UTF-8. I think it's a very clever encoding.)
- option_greek 13y ago
  If they were using UTF-8, wouldn't just one version of function suffice ? That is, instead of using a shim, just determine which version to call based on the encoding.
- nitrogen 13y ago
  There would be no need for the 16-bit versions if they had used UTF-8. The same function signatures would work for ASCII, ISO-8859, or UTF-8.
  - asveikau 13y ago
    NT development began before UTF-8 existed. Surely you're not suggesting that the authors should have used an encoding that did not yet exist?

by malkia 13y ago

asveikau 13y ago

> You need two versions of functions. For Windows this is entirely a compatibility thing. One could imagine a world in which that was not strictly necessary. A good best practice for a Win32 app is to always use 16-bit strings when calling system APIs and pretend the "ANSI" versions don't exist; I would not recommend anything else. In NT the 8-bit versions generally do nothing but convert to 16-bit and call the "real" function. In recent versions (I think Win7 was the first to do this), AFAIK the 8-bit shims typically exist in another module, so if you don't use them they don't get loaded. In NT on ARM the 8-bit shims are not even there. > It doubles the space for things like storing identifiers for programming languages Which is why GetProcAddress() still takes an 8-bit string. Just because the kernel (and hence the syscall interface) uses 16-bit everywhere doesn't mean you can't use 8-bit strings in your own process, or that you can't selectively pick what makes sense for your use. (By the way, none of what I'm saying is a criticism of UTF-8. I think it's a very clever encoding.)

option_greek 13y ago
If they were using UTF-8, wouldn't just one version of function suffice ? That is, instead of using a shim, just determine which version to call based on the encoding.
nitrogen 13y ago
There would be no need for the 16-bit versions if they had used UTF-8. The same function signatures would work for ASCII, ISO-8859, or UTF-8.
- asveikau 13y ago
  NT development began before UTF-8 existed. Surely you're not suggesting that the authors should have used an encoding that did not yet exist?