Comments 13
Ведь Windows любила UTF-16 (хоть и не должна была)Всё же стоит учитывать, что когда Windows NT была в разработке, UTF-8 ещё не существовало, поэтому и был выбран UTF-16, потому что на тот момент он казался лучшим стандартом будущего.
Если бы. Был рассчёт на не более, чем 65536 символов и UCS-2. А вот когда в 1996м стало понятно, что их не хватит… был выбран неверный подход с переходом на UTF-16, вместо UTF-8.
Ошибка была исправлена только через четверть века… но последствия мы будем расхлёбывать ещё очень долго.
P.S. Если бы во время разработки Windows NT уже существовали бы и UTF-8 и UTF-16, то, почти наверняка, выбрали бы UTF-8, так как UTF-16 — это восхитительное собрание всех мыслимых и немыслимых проблем без каких-либо преимуществ.
Ошибка была исправлена только через четверть века… но последствия мы будем расхлёбывать ещё очень долго.
P.S. Если бы во время разработки Windows NT уже существовали бы и UTF-8 и UTF-16, то, почти наверняка, выбрали бы UTF-8, так как UTF-16 — это восхитительное собрание всех мыслимых и немыслимых проблем без каких-либо преимуществ.
Разработка Windows NT началась в 1988 (когда она планировалась ещё как новая OS/2). UTF-8 появился в январе 1993. К этому времени Windows NT уже была почти готова (релиз в июле 1993), и ядро было полностью завязано на «широкие» юникодные строки с 16-битными кодпоинтами. Когда в UTF-16 появились суррогатные пары и вот это всё — дороги назад уже не было совсем. Microsoft нужно было завоёвывать рынок, и лишних 5 лет на переписывание внутренностей ещё совсем недавно созданной ОС не было. Тем более, что преимущества от переписывания были не очевидны: модные на тот момент технологии (вспомним Java и появившийся JavaScript) поддерживали Unicode именно в виде UTF-16, и скорее всего это всё ещё казалось светлым будущим.
То, что в последних Windows 10 для Win32-приложений можно выбрать UTF-8 в качестве однобайтовой кодировки не отменяет, что внутри ОС всё в UTF-16 всё равно. UTF-8 просто перегоняется в UTF-16 и обратно тем же образом, как раньше поддерживались легаси-кодировки.
P.S. Я знаю, что если придираться, то UCS-2 и UTF-16 — это разные вещи. Просто код, который работает с UTF-16, часто обращается с ним как с UCS-2 (программисты ленивы, или даже не в курсе про суррогатные пары, и в большинстве случаев это работает как ожидается); бывает и наоборот (имена файлов в NTFS в UCS-2 и могут быть невалидным UTF-16, но ОС пытается отображать эти имена именно как UTF-16). Такова реальность. Поэтому я воспринимаю UCS-2 и UTF-16 как нечто целое, где, так уж повелось, все по-разному обращаются с суррогатными парами.
То, что в последних Windows 10 для Win32-приложений можно выбрать UTF-8 в качестве однобайтовой кодировки не отменяет, что внутри ОС всё в UTF-16 всё равно. UTF-8 просто перегоняется в UTF-16 и обратно тем же образом, как раньше поддерживались легаси-кодировки.
P.S. Я знаю, что если придираться, то UCS-2 и UTF-16 — это разные вещи. Просто код, который работает с UTF-16, часто обращается с ним как с UCS-2 (программисты ленивы, или даже не в курсе про суррогатные пары, и в большинстве случаев это работает как ожидается); бывает и наоборот (имена файлов в NTFS в UCS-2 и могут быть невалидным UTF-16, но ОС пытается отображать эти имена именно как UTF-16). Такова реальность. Поэтому я воспринимаю UCS-2 и UTF-16 как нечто целое, где, так уж повелось, все по-разному обращаются с суррогатными парами.
Когда в UTF-16 появились суррогатные пары и вот это всё — дороги назад уже не было совсем.Дорога назад, конечно, была и она была столь же тривиальной, как и сегодня. Нужно было cp65001 завести не в XXI веке, а в 1995м году. И, соотвественно, Office97 (первый, где есть нормальная поддержка unicode) делать не на основе UCS-2, а на основе UTF-8.
Но… вышло, как вышло.
Microsoft нужно было завоёвывать рынок, и лишних 5 лет на переписывание внутренностей ещё совсем недавно созданной ОС не было.Не нужно было никаких «переписываний внутренностей». В те годы все операционки всё ещё работали со всякими ISO 2022. А софта, завязанного на UCS-2 или UTF-16 было нуль, нисколько.
UTF-8 просто перегоняется в UTF-16 и обратно тем же образом, как раньше поддерживались легаси-кодировки.А это уже как раз — личное дело Windows, что там у неё внутри. Пока приложения могут считать что ничего, кроме UTF-8, в мире нету — пусть «внутри» хоть троичную систему счисления используют.
Поэтому я воспринимаю UCS-2 и UTF-16 как нечто целое, где, так уж повелось, все по-разному обращаются с суррогатными парами.Собственно именно это и побуждает меня UTF-16 воспринимать только и исключительно как «ошибку истории». Потому что слишком много кода воспринимают UTF-16 как UCS-2, ломаются, тем или иным способом, на суррогатах — и слишком поздно это выясняется.
Потому наилучший способ исправления программ с UTF-16 — прекратить её использовать. В UTF-8 слишком большой процент символов требуют многобайтового представления, «забыть» при этом и не получить гневных жалоб — практически невозможно. А ошибки в поддержке UTF-16 могут не правиться годами (не знаю, когда Firefox решил проблему с удалением «половины символа» при использовании Backspace, но это точно заняло не один год).
Отдельная прелесть UTF-8 — возможность работать с строками как с обычными однобайтными, если у нас нет необходимости знать содержимое и считать «реальные» символы. Совместимость с ASCII очень сильно упрощает взаимодействие.
Учитывая эту совместимость нет проблем переводить софт под виндой на UTF-8, в хулшем случае будут кракозябры, но ничего не сломается.
Учитывая эту совместимость нет проблем переводить софт под виндой на UTF-8, в хулшем случае будут кракозябры, но ничего не сломается.
Учитывая эту совместимость нет проблем переводить софт под виндой на UTF-8, в хулшем случае будут кракозябры, но ничего не сломается.К сожалению всё не так просто. Вы можете вшить manifest в программу — и она будет даже использовать UTF-8 независимо от настроек системы… но вот только тот факт, что для этого требуется, чтобы ваши пользователи использовали «Windows Version 1903 (May 2019 Update)»… он так, чуть-чуть напрягает.
Не все пользователи ещё перешли, однако.
в Win версии все проще конечно. играл в Age of Mythology на Intel видео карте современной, определялась конечно же как старая и не давала поставить даже 32бита цвет, молчу про остальные графические настройки. Вылечил заменой текущей VendorID на самую крутую от nVidia доступную в конфиг файле. такой же файл есть и в win версии age of empires 3 называется configy.xml там содержится vendorid id и cardid id, заменяем их под самую топовую тогда GeForceFX 6800 и получаем на встроенной интел все доступные настройки
Не знаю, расстроит вас это или обрадует, но скоро выйдет официальный ремастер :)
Very High на скриншотах не только выглядит иначе по цветам (мне не нравится). Там еще кусты пропали по пальмами. На остальных скриншотах они есть, даже в самом простом качестве.
P.S. в игру не играл, может там, конечно пришел NPC и скосил траву, на я сомневаюсь :)
Этот файл довольно хаотичен. Но после меток Geforce FX 6800 мы видим несколько идентификаторов. Скорее всего, нам нужен один из них. Давайте попробуем 00F1.
Проще всего протестировать это — воспользоваться LLDB и задать нужные точки останова. Я пропущу это этап, но скажу, что 00F1 подошёл (к счастью).
На этом этапе нам нужно ответить на вопрос: «Как сделать это изменение постоянным?» Похоже, что проще будет изменить значения var_CC и var_D0 на 0X00F1 и 0X10DE. Для этого нам всего лишь нужно получить пространство для кода.
Интересно, автор пробовал менять XMB файл вместо кода. По идее если 00F1 заменить на индификатор своей карты, то таким образом игра должна думать что у нас Geforce FX 6800… по идеи
Что карантин с людьми делает :)
На самом деле довольно интересно было почитать.
Интересная статья! интересно почитать
Sign up to leave a comment.
Взламываем Age of Empires III, чтобы изменить настройки качества шейдеров