Odpověď na názor

[32] Samozřejmě Windows nepoužívají 8-bitový char, ale 16-bitový wchar_t. Řetězce z wcharů jsou ukončeny 16-bitovou nulou, podobně jako řetězce z charů jsou ukončeny 8-bitovou nulou.
To pochopitelně vyžaduje API pro zpětnou kompatibilitu s apikacemi používajícími codepages. Takové API ale není problém. Funkci CreateFile máte ve verzi CreateFileW (wide), a CreateFileA (ANSI). Unicodové aplikace používají CreateFileW. Pravěké aplikace používají CreateFileA. Ta funkce převede chary na widechary, a případně při návratu přeloží výsledek zpět. Sice to stojí nějaké prostředky, ale týká se to jen starých aplikací bez podpory Unicode.

Jak jsem psal i v původním příspěvku, protože unixy se už ze zásady nerady mění (viz například absence řady API), nebylo zřejmě realistické mít Unicode API, jako ve Windows. Proto se skrz původní char API tlačí UTF-8. Úpravy jsou přesto potřeba úplně všude. Například unixové FS ukládají chary. Jenže v jaké code page? FS to neví, kernel také ne. Pokud aplikace A píše názvy v UTF-8, a aplikace B je píše v 8859-2 (aplikace je totiž potřeba pro podporu UTF-8 předělat), vznikne na disku chaos v názvech souborů. Aby to bylo zajímavější, některé aplikace se dodávají například s nápovědou v souborech jejichž jména obsahují UTF-8 znaky, i pokud provedete instalaci na disk, kam běžně píšete názvy v 8859-2. To je pak pravý, nefalšovaný chaos. No a řadu problémů má i libc. Pár funkcí (NLS) jede s 32-bit wide charactery, zbytek jen v charech (a krmí se UTF-8). Ovšem například standardní funkce strchr, která hledá znak ve stringu, nemůže v UTF-8 fungovat, protože znak Unicode v UTF-8 (třeba ruské JA) může mít více bytů. Autoři glibc to vyřešili "rafinovaně" tak, že změnili dokumentaci funkce, takže už nehledá *znak*, ale *char*, přičemž problém zůstává nevyřešen.
Další lahůdkou jsou toolkity. Qt běží kompletně v Unicode UTF-16. Pokud přečtete název souboru z adresáře, tento je považován za UTF-8 (když je to náhodou 8859-2, máte asi smůlu). To UTF-8 se převede na UTF-16, a aplikace má název souboru. Když pak ten soubor chcete otevřít, zavoláte Qt s UTF-16 stringem, Qt ho převede na UTF-8, a zavolá glibc. Případný vrácený string by se opět překládal, pořád dokola. Ve Windows se překládá dost podobně, ale pouze pro *ne-Unicode* aplikace, které postupně vymírají. MS možná bude muset udržovat ANSI API ještě řadu let, ale unixy budou překládat chary na widechary při každém volání asi navždy, při každém jednom volání. Abych nezapomněl, GTK používá 32-bit wide char, to aby v tom nebyl zmatek.

Ano, do 16 bitů se některé znaky nevejdou. To se řeší pomocí surrogate pairs. Jejich podpora je za běžných okolností vypnutá, a ani asiaté je nemají rádi (mají k tomu dobrý důvod, kterému se říká CJK multibyte code page). Pokud je podpora surrogatepairs zapnutá, je ve Windows stejný problém, jako v Qt. V případě .NETu je to ale celkem jedno.

Autor Total Commanderu je bohužel idiot. Ten člověk například ukládal dlouhá léta konfiguraci TC do ini souboru, umístěného v adresáři aplikace spolu s binárkou. Fuj! A jaké bylo jeho překvapení, když ne-admin uživatel ve Windows 2000 do toho adresáře nezapsal, a TC zhavaroval. Podpora Unicode se samozřejmě nekoná. Resp. podle autora TC6 umí přistupovat k souborům s názvy v Unicode pomocí generovaných 8.3 názvů pro MS-DOS (fuj!), a podporu Unicode hodlá dopsat v TC 7.5 nebo 8. Možná už v roce 2009-2010 bude mít TV podporu Unicode, asi 16-17 ket po uvedení první verze Windows NT!