Если вы активно следите за происходящим вокруг Windows 10, то могли заметить появившийся несколько дней номер сборки 17000 (rs_prerelease) на сайте BuildFeed. Подобные большие скачки в номерах сборок случались и раньше, однако на следующий день произошло что-то невероятное. В этой же ветке была собрана сборка с номером 16350. Изначально многие предположили, что это разные этапы разработки системы, однако эту информацию официально опровергли сотрудники компании.
О наличии проблемы со сборкой 17000 сообщил Брэндон ЛеБланк в своём Twitter:
Not necessarily false but perhaps a more complicated "story" that requires more than 140 characters to explain.
— Brandon LeBlanc (@brandonleblanc) 26 августа 2017 г.
Но разве простая смена номера сборки могла привести к возникновению ошибки? Как оказалось, могла. В первую очередь, номера сборок используются для управления версиями системы. Программы получают номер сборки из NTOSKrnl, являющегося основой для всех операционных систем Microsoft на базе ядра Windows NT.
И первая вещь, с которой столкнулись энтузиасты, связана с фрагментацией. Номер сборки системы хранился в 17 различных местах ядра системы. Не самое приятное открытие, но что есть, то есть.
Энтузиасты модифицировали ядро системы, чтобы система идентифицировала себя как сборку 17000. Для этого пришлось поработать с дизассемблером, найти нужные смещения, создать исправленное ядро и отредактировать BCD для загрузки ядра. В итоге удалось запустить виртуальную машину под управлением «Windows 10 Build 17000». И вначале казалось, что всё работает хорошо, однако… Открытие «Командной строки» (CMD) раскрыло сущность проблемы.
Что это? Сборка 616? Это не так. Ядро явно заявляет, что это сборка 17000. Все изменения были проверены несколько раз, ошибки быть не могло. Что же это значит?
Для ответа на этот вопрос энтузиасты применяли различные математические операции, чтобы понять, как рассчитывается это число.
17000 – 616 = 16384
Если вы довольно давно следите за операционной системой Windows, то наверняка увидите знакомое число 16384 (0x4000). Это номер версии RTM, использующийся во всех версиях Windows, начиная с Vista и заканчивая 10 TH1. К слову, получить номер 616 можно ещё одним способом, кроме простого вычитания. Речь о логическом умножении (конъюнкции, логическом "И") с номерами 17000 и 16383 (0x3FFF). Если вы не знакомы с такими логическими операциями, то ниже вы можете наглядно увидеть, как это работает. Проще говоря, сохраняются только совпадающие биты двух чисел.
В процедурах, связанных с версией системы, не использовалось число 0x4000, поэтому энтузиасты принялись искать 0x3FFF. И на этот раз удалось обнаружить необходимое. Функция MmCreatePeb использует номер сборки и логическую операцию «И 0x3FFF». Поиск имени функции в Google позволил найти интересную статью от 2009 года, опубликованную в Microsoft Press Store, в которой подробно описывалось создание «PEB». В этом из этапов задействовалась переменная Build Number, логическая операция «И», а также число 0x3FFF.
Стало понятно, что номера сборок, фактически, завершаются, когда достигают числа, кратного 16384. Решено было выяснить, в какой же сборке впервые появилась данная функция. Изначально ожидалось, что она появилась на раннем этапе разработки Windows Vista. Тем более это была первая версия Windows, которая использовала число 16384 в теге сборки. Но, как оказалось, даже самая первая публичная версия Windows Vista содержала этот кусок кода.
Изучение продолжилось. Windows Server 2003? Присутствует. Windows XP? Присутствует. Windows 2000? Присутствует. Невероятно, но энтузиасты добрались до Windows NT 3.5, где данного куса кода не встречалось. Таким образом, логическая операция «И» с номером сборки была реализована ещё в ходе разработки Windows NT 4.0. Но и на этом изучение не прекратилось. Благодаря друзьям, сохранившим первые публичные бета-версии NT 4.0, удалось найти сборку, в которой впервые появилась эта «функция» — сборка 1264.
Ядро сборки также было модифицировано, чтобы система определила себя как сборку с номером 16384. На экране загрузки отобразилась необработанная информация, а номер оказался корректен — 16384. А вот интерфейс операционной системы выводил уже обработанную информацию, а именно «0».
Вот такое вот приключение. Корни причины, по которой сборка 17000 была заменена на 16350, уходят в 1996 год, а значит данной проблеме уже 21 год. Будем надеяться, что Microsoft сможет оперативно решить проблему, ведь до достижения номера 16384 осталось около месяца.
Авторы оригинальной статьи: Inside Windows и Indigo.