Как создается Windows
Мало кто знает, когда началась разработка Windows NT - больше, чем 20 лет назад, в ноябре 1988 года. Ходят слухи, что Microsoft купила/украла Windows NT. Конечно, это всё не так. Для работы над новой операционной системой, Microsoft пригласила Дэйва Катлера (Dave Cutler), который работал в корпорации DEC и был одним из разработчиков операционной системы DEC VAX VMS. В 1988 году группе разработки новой операционной системы было всего 12 человек, среди которых, наряду с Дэйвом Катлером, были также бывшие сотрудники DEC, принимавшие участие в разработке DEC VAX VMS. И весь код новой Windows NT был написан в Microsoft. Аббревиатура "NT" маркетингом расшифровывается как "New Technologies", но в проектной документации, она означала совсем другое. Дело в том, что Windows NT разрабатывалась для нового, еще не выпущенного в 1988-м году, процессора Intel i860. Его кодовое название было "N10" (N Ten).
Первая версия - Windows NT 3.1, вышла через 5 лет, в 1993 году. На этот момент в команде было уже 250 разработчиков.
Windows сегодня
*1 миллиард пользователей
*140 миллионов строк кода (включая тестовый код и инструментарий)
Код Windows очень разный. Какие-то части написаны 20 лет назад, какие-то появились только в текущей версии. Например, код Web Services on Devices (WSD) в Windows Vista существует в своей первой версии, код GDI находится на завершающей стадии своего развития и почти не изменяется, код DirectX уже хорошо разработан, но активно изменяется и в настоящее время.
*8000 разработчиков
*36 языков локализации
*20 лет разработки
Разработка Windows
20-30 лет назад использовалась только одна методология программирования "Водопад". Она представляет собой последовательность:
Спецификации → Дизайн → Реализация → Тестирование → Поставка.
Но такая методология работает только для небольших проектов. Для такого продукта, как Windows сегодня, нужны другие методологии:
*Product Cycle Model
*Team Software Process
*"Экстремальное программирование"
У всех этих методологий есть и преимущества и недостатки. В зависимости от размера команды и этапа развития компонента разные группы разработчиков Windows применяют разные методологии разработки.
Для Windows, как продукта в целом, используется Product Cycle Model:
*Периоды по 3-4 месяца
*Внутри периода - "водопад"
Самая главная проблема в разработке продукта такого масштаба состоит в том, что разработка требует времени. На начальном этапе решаются те проблемы, которые существуют в текущем времени и существующими средствами. Но единственная вещь, которая постоянна, это то, что все изменится. За годы разработки:
*Требования изменятся
*Возможности изменятся
*График работ изменится
*Проект изменится
*Пользователи изменятся
Несмотря на то, что разные команды ведут разработку по-разному, существуют "универсальные" правила:
*Выпуск промежуточных версий (milestones, beta, CTP) для широких масс тестеров
Выпуск внутренних сборок с короткими циклами (1 сутки)
Простота и надежность дизайна
Личные и командные вычитывания кода
*Unit-тесты
*Верификационные тесты (Build Verification Tests)
*Любая промежуточная сборка должна быть качественной (то, что написано, должно работать)
От себя отмечу, что за месяц работы с Windows 7 build 6801 в качестве основной ОС на домашнем компьютере, у меня сформировалось положительное впечатление об этой сборки.
Весь процесс разработки Windows построен вокруг ежедневной сборки:
Это пульс продукта
Разработка никогда не прекращается
Ежедневное автоматическое тестирование
Интеграция на ранней стадии
Ответственность разработчиков
Очевидное состояние продукта
Когда-то раньше была только одна ветка исходного кода, и все разработчики вносили изменения прямо в неё. Сейчас команда разработчиков настолько большая, что это не работает. Поддерживается множество веток, среди которых есть основная - WinMain. У каждой лаборатории есть своя локальная ветка разработки, в которую интегрируются изменения. Проверенные изменения со временем интегрируются в WinMain.
Ежедневный цикл разработки:
*15:00 - Допущенные к интеграции изменения в систему контроля исходного кода
*Сборка 6 версий (Free/Checked - x86, x64, IA64)
*18:00 - Новые версии доступны для тестирования
*Новая версия устанавливается на несколько тысяч рабочих станций и серверов для тестирования
*Автоматизированный стресс-тест
*05:00 - Протоколы тестов анализируются, сбои диагностируются
*09:00 - Сводные отчеты автоматически рассылаются командам
*09:30 - Сводное совещание руководителей команд для определения целей
Все участники проекта, включая самых высокопоставленных руководителей, используют промежуточные версии на своих рабочих (а обычно и домашних) компьютерах.
На чем пишется Windows?
*C, C++, C#, Ассемблер (x86, x64, IA64)
*Ассемблеры применяются в довольно ограниченном объеме в тех ситуациях, когда без этого не обойтись
*Visual Studio, Source Insight, build, nmake
**Source Depot - система контроля исходных текстов
WinDbg, KD, NTSD - отладчики
Многие внутренние инструменты, такие как build, можно скачать с microsoft.com/whdc/devtools.
Изменения ядра Windows 7
Ядро Windows 7 претерпело следующие изменения:
*Рефакторинг
Почему в Windows нельзя удалить графическую подсистему?
Ответ на этот вопрос с технической точки зрения состоит в том, что графическая подсистема в Windows не самостоятельна, это часть подсистемы Win32.
В Windows 7 произошел рефакторинг многих низкоуровневых компонентов для того, чтобы разбить зависимости. Пользователям это не будет заметно, появятся только новые Dll, например kernel32.dll разделилась на kernel32.dll и kernelbase.dll.
Это разбиение дало возможность выделить минимальное ядро, называемое MinWin (20 мегабайт на диске).
*Поддержка EFI для x86 и x64 (как в Vista SP1)
Многие производители пытаются избавиться от BIOS в пользу EFI.
*Загрузка с VHD (виртуальный жесткий диск)
*Параллельная инициализация устройств и старт сервисов
При загрузке Windows довольно длительное время занимает построение дерева устройств. PNP-менеджер должен опрашивать драйверы шин (PCI, USB, FireWire и др.) на предмет того, какие устройства на них есть. И большую часть времени процессор ждет, пока устройства ответят (или нет). Ведь для того, чтобы определить устройства на шине нужно их опросить. Если они есть, то они ответят, а если нет, то приходится ждать, и процессор простаивает. Параллельное выполнение этих задач сокращает время загрузки.
*Удаление Dispatcher lock из планировщика и PFN lock из менеджера памяти
Последние несколько лет тактовые частоты процессоров не растут, и развитие идет в сторону увеличения кол-ва параллельно выполняющихся инструкций как на уровне одного ядра, так и на уровне системы (multicore). В связи с этим, была проведена большая работа по улучшению масштабирования.
Два самых "горячих" лока, которые были в ядре, это Dispatcher lock и PFN lock были удалены.
Dispatcher lock использовался планировщиком при изменении состояния потоков. Этот лок был удален, и состояние потока "ожидание" разделилось на несколько:
**Ожидание: В процессе
**Ожидание: Завершено
**Ожидание: Отменено
PFN lock использовался при изменении атрибутов физических страниц памяти. В мультипроцессорной системе каждый процессор запрашивал доступ к этому локу, что вело к большим затратам времени.
*Поддержка 256 логических процессоров
Раньше в Windows в качестве affinity mask использовалось машинное слово. Это было сделано из-за того, что так было легко находить свободные процессоры - каждый бит представляет собой процессор. Соответственно, в 32-битной системе поддерживалось 32 логических процессора, а в 64-битной - 64.
В Windows 7 в результате перехода на сегментную модель affinity mask стала возможна поддержка 256 логических процессоров. Процессоры стали группироваться в группы/сегменты. В каждой группе могут находиться до 64-х процессоров. В результате получается обратная совместимость, старые программы "видят" только процессоры в одной группе, а новые программы, использующие новые интерфейсы, работают со всеми процессорами в системе.
*Улучшенное энергосбережение: отключение процессорных сокетовСегодня стоит серьезная проблема энергосбережения не только перед владельцами ноутбуков, но и владельцами датацентров. В США 2% электроэнергии потребляются компьютерными датацентрами. Многие из них выключают часть своих серверов на время низкой активности пользователей (выходные дни).
Было выяснено, что гораздо выгоднее отключать весь процессорный сокет, чем по одному ядру на нескольких, т.к. в этом случае можно отключить и всю инфраструктуру поддержки сокета (контроллер памяти).
Сопровождение Windows, обновления
Раньше обновления зачастую были кумулятивными(накапливаемыми). Это означало, что если ошибочный код содержался в раннем обновлении компонента, то и поздние версии будут содержать этот код. Но не всем пользователям нужны все обновления, у них разная конфигурация.
Теперь после выпуска (RTM) в Windows существует 2 версии исходного кода:
*RTM GDR (General Distribution Release)
Включает те немногие изменения, которые предназначены для всех. В основном исправления безопасности.
*RTM LDR (Limited Distribution Release)
Во время установки обновления клиент Windows Update выбирает нужную ему ветку и устанавливает код из нее.
Создание обновления безопасности
Работа по созданию обновления безопасности начинается с обнаружения уязвимости. Есть масса разных способов обнаружения - внутренние команды безопасности, партнеры безопасности, разработчики. Когда уязвимость обнаружена, начинается 2 параллельных процесса:
*Разработка исправления для всех платформ
*Поиск "вариантов"
*Масштабный поиск похожих вариантов уязвимостей на всех платформах. Поиск не идентичного кода, а похожего.
После разработки исправления, начинаются проверки его кода. Когда они завершатся, исправление интегрируется в сборку, и сборка отправляется на тестирование:
*Ручное и автоматическое тестирование компонент
*Автоматическое тестирование искажений форматов файлов, сетевых компонент и т.п. (больше миллиона вариантов)
*Тестирование системы в целом, включая тестирование обратной совместимости
Только исправления, удовлетворяющие всем критериям качества, допускаются к выпуску на Windows Update и Download Center.
|
