Комментарии 22
Поддержка Юникода в Windows появилась раньше, чем в большинстве остальных операционных систем.
Вызывающе неверная информация: раньше всего появилась в Linux-е (сразу всё в комплексе локаль, приложения, библиотеки и ФС и т.д.), а в Windows гораздо позже, неполноценно и криво (на ФС не было).
Прям уж «вызывающе неверная»! На самом деле «появилась раньше, чем в большинстве» никак не противоречит «раньше всего появилась в Линуксе». «Большинство» же не значит «все остальные». И да, когда конкретно поддержка Юникода в Линуксе появилась?
Вызывающе неверная информация: раньше всего появилась в Linux

Если имеется ввиду использование utf-8 в Linux то это теоретически невозможно.
utf-8 в том виде который мы ее знаем была разработана в рамках работы над ОС Plan-9,
поэтому естественно первая ОС с utf-8 это Plan-9 и в Linux utf-8 могла появиться только позже Plan-9.

В линуксе поддержка Юникода оставала от Windows. utf-8 они использовали, так как было огромное количество программ, рассчитанных на 8-битные кодировки.

В чём отставала?! В линуксе давно на UTF-8 сидел, когда в винде (параллельно стояла) ещё и в помине не было, может возможность была, но в приложениях, ни в локали, ни ФС (и сейчас кажись нету) не было.
Мир не ограничивался Windows 95/98, которые были временным решением для домашних пользователей, пока линейка NT созревала для этих целей.

Windows NT 3.1 вышла в 1993, и она уже поддерживала Unicode. NTFS появилась тогда же, и она изначально поддерживает исключительно Unicode.
Удивительно! :) Значит я пропустил: я сидел на пользовательских 3.1/95/98/XP… и там с кодировками была ж…

Windows 95 — все они использовали кодировку UCS-2 — Windows 95 не использовала кодировку UCS-2, т.к. у неё не было никаких w-функций, только A функции (CreateWindowsW VS CreateWindowsA).

Ну тащем-та это не совсем так, для 95/98/ME была такая штука под названием Microsoft Layer for Unicode (MSLU), в ней были w-версии всех этих функций.
Если совсем строго, то еще в Win 3.x вместе с родным Win16 API было еще некоторое подмножество Win32 (Win32S = Win32 Subset), в котором A-функции шли вместе с W-функциями, только вместо имплементаций у W-функций там были заглушки, возвращающие ошибки.
95/98/ME хоть и имели формально полную Win32-подсистему, но большинство W-функций там тоже шло заглушками. Большинство, но не все. Некоторые функции (их довольно мало) для работы с ресурсами (e.g. EnumResourceNamesW), командной строкой (e.g. GetCommandLineW), диалоговыми сообщениями (e.g. MessageBoxW) имели рабочую реализацию, также были доступны вспомогательные функции для конвертации W-строк в A-строки (MultiByteToWideChar, WideCharToMultiByte) с кодированием MBCS (Multibyte Character Set). В 98 добавили еще чуток функций (lstrlenW, lstrcpyW, lstrcatW). Полноценная поддержка Win32 через MSLU (так же известная как unicows) для них появилась только в 2001 году.
Зачем, вообще, использовать указатель на wchar? char вполне нормально работает и для UTF-8, и для UTF-32. А гарантировать, что один видимый символ = один символ юникода даже UTF-32 не может.
Так-то оно так, но… насколько я понимаю, изначально wchar_t вводился для того, чтобы работали штуки типа str[i]. Это не юникод, и вообще не какой-то стандарт, а просто некое такое компиляторозависимое представление символов, что все символы имеют фиксированную длину в байтах.
> char вполне нормально работает и для UTF-8, и для UTF-32

char, если он 8-битный, не работает для UTF-32 так, как надо: нельзя прочитать/записать один кодовый пункт целиком, нельзя проверять на NUL ограниченные им строки, нельзя простым ++ или — перейти на следующий/предыдущий пункт.
Для этого всего нужен char32_t вместо char.

> А гарантировать, что один видимый символ = один символ юникода даже UTF-32 не может.

Не может. Но обращение по тому размеру, в котором хранится, упрощает большинство операций с текстом.
нельзя проверять на NUL ограниченные им строки
Какие проблемы? NUL не может появиться внутри другого символа, это всегда отдельный байт. То же самое с поиском любой подстроки в строке — неоднозначности исключены.

нельзя простым ++ или -- перейти на следующий/предыдущий пункт
Но и не сильно это сложно:
if (*ptr++ & 0x80) while ((*ptr & 0xC0) == 0x80) ptr++;
> NUL не может появиться внутри другого символа, это всегда отдельный байт.
> if (*ptr++ & 0x80) while ((*ptr & 0xC0) == 0x80) ptr++;

Это вы всё говорили про UTF-8, а я про UTF-32.
За прошедшие к тому моменту шесть лет для Windows было написано огромное множество программ объёмом в миллиарды строк.

Ого! Миллиарды :)

Пора уже забыть про TCHAR и, соответственно, _tprintf, и, хуже того, _tmain.
А где ссылки из статьи? А то есть [1], [2], а самого списка ссылок нету.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2008
Местоположение
Россия
Сайт
www.viva64.com
Численность
31–50 человек
Дата регистрации

Блог на Хабре