Нефть Brent
$74.23
+1.25%
19
Если вы являетесь участником программы тестирования Windows Insider и обладаете наблюдательностью, то могли заметить несколько дней назад появление сборки под номером 17000 в ленте BuildFeed, которую затем сменила сборка 16350. Некоторые считали, что это два совершенно разных уровня разработки, однако можно предложить и другое объяснение. Одна из подсказок была найдена в Твиттере. Брендон Ле Блан из Microsoft написал, что ответ на вопрос займёт больше, чем 140 символов Twitter.
Казалось бы, почему простое увеличение нумерации сборки должна сопровождаться длинным объяснением? С другой стороны, не всегда публичные персоны в Твиттере говорят всю правду.
Разобраться решили на портале Inside Windows. Для чего используются номера сборок? Всё дело в версиях. Сначала нужно было понять, как программа получает версии в нынешних вариантах Windows. После исследования многочисленных файлов исследователи добрались до NTOSKrnl в сердце операционной системы на ядре NT.
Первым сюрпризом стала фрагментация. Сможете ли вы угадать, сколько раз номер сборки был найден в ядре? Номер хранится в 17 различных местах.
Первая идея заключалась в модификации ядра, чтобы система определялась как версия 17000, и поиске проблем в операционной системе. После работы с дисассемблером редактор выдал исправленное ядро и редактор BCD загрузил его. Далее удалось запустить виртуальную машину на сборке Windows 10 17000. Всё работало нормально, загрузка не была долгой, войти в учётную запись без проблем удалось без проблем, рабочий стол также работал. Однако это впечатление длилось недолго, до запуска командной строки.
Там исследователи увидели странный номер сборки 616. Ядро говорит о том, что это не сборка 17000, хотя изменения были дважды проверены перед применением. Нужно было узнать причину этой странности. При помощи различных математических операций исследователи пытались понять, как появился такой номер. В результате они пришли к следующей операции:
17000-616=16384
Опытные инсайдеры Могут узнать номер 16384 (0х4000). Это номер версии RTM, который используется начиная с Windows Vista и заканчивая Windows 10 TH1. Есть и другой вариант получения 616 из 17000 кроме вычитания — нужно выполнить логическую операцию AND с номерами 17000 и 16383 (0х3FFF). Если вы не знакомы с этой операцией, она объясняется на рисунке. Остаются только совпадающие биты, остальные обнуляются.
Непонятно, для чего используется номер 0х4000 в версиях Windows, поэтому было принято решение поближе рассмотреть номер 0х3FFF. На этот раз удалось наткнуться на нечто интересное. Функция под названием MmCreatePeb использует номер сборки и операцию AND 0x3FFF. Поиск этой функции в Google показал статью 2009 года на Microsoft Press Store, там описывается создание процесса PEB, в котором один из шагов содержит переменную номер сборки, есть AND и 0х3FFF.
После этого стало понятно, что заставляет номера сборок практически попадать в петлю, когда они достигают номера 16384. Дальше нужно было понять, какая первая сборка показала такое поведение. Казалось, что это должно было произойти во времена Windows Vista. Именно тогда впервые был использован номер 16384. На самом деле даже первые доступные пользователям сборки Windows Vista уже имели данный код, поэтому нужно было копать глубже.
Началось путешествие обратно во времени. Windows Server 2003. Windows XP. Windows 2000. Исследование продолжалось до Windows NT 3.51. Операция AND было введено во время разработки Windows NT 4.0. Благодаря наличию бета-версий этой системы удалось найти первую сборку с данной функцией — 1264.
Чтобы проверить теорию, было изменено ядро этой сборки, чтобы она отображалась как сборка 16384. Экран загрузки показывает версию 16384, а интерфейс операционной системы показывает номер 0.
Это позволило сделать интересный вывод. Причина, по которой сборка 17000 была заменена сборкой 16350, своими корнями уходит в март 1996 года, то есть этой проблеме уже 21 год. Хочется верить, что Microsoft сможет решить её вовремя, поскольку остался месяц до тех пор, пока она доберётся до номера 16384, даже если выпускать по одной сборке в день. После этого при нынешнем состоянии дел нумерация сломается.
Можно предположить, что подобные исследования можно провести и в других частях операционной системы со своими нумерациями, поэтому данная проблема может быть не единичной.
