NT – переработанная VMS
Большинство основных проектировщиков NT продолжило работать и над VMS в Digital. Многие пользователи верят, что разработчики NT перенесли концепции VMS в NT, но большинство не знает, как похожи NT и VMS на уровне ядра (совпадение или нет, если вы увеличите каждую букву в названии VMS вы получите WNT).
Первая версия Windows NT, Windows NT 3.1, была выпущена в июле 1993 и была названа так, чтобы соответствовать номеру версии текущего на тот момент 16-битного продукта Windows. С этих пор команда разработчиков NT работала над совершенствованием выпусков и все разработки велись на одной и той же кодовой базе. Следующей версией NT стала 3.5, которая носила кодовое имя Daytona и была выпущена в сентябре 1994. Первоначальными возможностями для Daytona были размер, производительность и совместимость с Netware.
Рис. 4. Загрузочный экран NT 3.1.
Как в UNIX, и в большинстве коммерческих ОС, у NT есть два режима исполнения кода. В пользовательском режиме выполняются приложения, подситемы OS/2, DOS, и POSIX. Эти компоненты являются непривилегированными, потому что NT управляет ими, а также аппаратными средствами, на которых они работают. Без разрешения NT эти компоненты не могут непосредственно получить доступ к аппаратным средствам. Кроме того, компоненты и оборудование не могут получить доступ ни к другим адресным пространствам, ни к адресному пространству ядра. Компоненты в пользовательском режиме должны обратиться к ядру, если они хотят получить доступ к аппаратным средствам или выделить физические или логические ресурсы.
Ядро исполняется в привилегированном режиме: оно может непосредственно получить доступ к памяти и апаратуре. Ядро состоит из нескольких исполнительных подсистем, которые отвечают за обслуживание ресурсов, включая диспетчер процессов, диспетчер воода/вывода, диспетчер виртуальной памяти, справочный монитор безопасности, и микроядро, которое обслуживает планирование и прерывания. Система динамически загружает драйверы устройств, которые являются компонентами ядра и служат интерфейсом между NT и различными периферийными устройствами.
Уровень абстрагирования от оборудования (HAL) скрывает специфичные особенности процессора и материнской платы от NT. Родной (native) API NT – это API, который приложения пользовательского режима используют для вызова ядра. Этот родной API главным образом недокументирован, потому что приложения, как предполагается, вызывают подсистему Win32, DOS, OS/2, POSIX, или Win16, и соответствующая подсистема взаимодействует с ядром от имени приложения.
Разработчики Digital написали ядро VMS почти полностью на ассемблере VAX. Чтобы код был портируемым на различные архитектуры процессоров, разработчики Microsoft написали ядро NT почти полностью на C. При разработке NT, разработчики переписали VMS на C, избавили ее от недостатков, настроили, и добавили некоторый новый функционал и совместимость. Они создали новый API (то есть, Win32), новую файловую систему (то есть, NTFS), и новую графическую подсистему интерфейса, исполнительную среду, поддерживая т. о. обратную совместимость с DOS, OS/2, POSIX, и Win16. Однако, перемещение внутренностей VMS в NT было настолько полным, что в течение нескольких недель после выпуска NT, инженеры Digital заметили поразительные общие черты.
Рис. 5. Обобщенная архитектура ядра VMS.
Рис. 6. Обобщенная архитектура ядра NT.
Из этих общих черт можно составить книгу. Фактически, можно прочитать разделы книги «VAX/VMS Internals and Data Structures» (Digital Press) как точное описание внутренностей NT, просто переводя термины VMS к терминам NT. Рассмотрим некоторые из главных общих черт и различий между Windows NT 3.1 и VMS 5.0, последней версией VMS, на которую Дейв Катлер и его команда, оказали большое влияние.
Процессы в NT фактически идентичны процессам VMS. В NT, как в VMS, планировщик процессов реализует 32 уровня приоритетов. Процесс с самым высоким приоритетом всегда активен, а процессы с тем же самым приоритетом планируются по принципу карусели. Система выделяет 16 уровней высокого приоритета - реального времени или уровней с фиксированным приоритетом.
В таких процессах планировщик не манипулирует приоритетами. 16 низкоприоритетных уровней (исключая нулевой, который система резервирует для потока простоя idle, он выполняется в том случае, когда нет готовых к выполнению потоков) являются динамическими, потому что планировщик, часто, совместно с драйверами устройств, увеличивает приоритеты, при отклике на различные события. Например, когда процесс получает данные от устройства, приоритет соответственно увеличивается. Особенность диспетчеров процессов NT и VMS в том, что они никогда не понижают приоритет процесса ниже приоритета, на котором изначально работает приложение. Планировщики и VMS 5.0 и NT 3.1 поддерживают симметрическую мультипроцессорную обработку (SMP), которая позволяет им выполнять процессы одновременно на различных центральных процессорах, для увеличения производительности приложения.
Главное различие между NT и VMS в управлении процессами в том, что процессы NT содержат один или более потоков, и планировщик NT предоставляет процессорное время не процессам, а потокам. Digital не вводила потоки режима ядра в VMS до версии 7.0 в 1995. Это дополнение - одно из нескольких улучшений, сделанных Digital для VMS, начиная с выхода NT, которые появились в ответ на возможности NT. В свою очередь, Microsoft добавила легкие потоки пользовательского режима к NT 4.0 в 1996, которые она скопировала с реализации потоков VMS.
Рис. 7. Загрузочный экран NT 4.0.
Диспетчеры памяти в NT и VMS также похожи. Обе ОС осуществляют трансляцию виртуальных адресов, которые система разделяет между выполняемым приложением и ядром. И NT и VMS полагаются, в большой степени, на проецируемые в память файлы, особенно для проецирования кода, выполняемого приложением и реализацию функционала копирование при записи (copy-on-write). Физическое управление памятью в NT и VMS осуществляется через подкачку виртуальной памяти по требованию (demand-paged virtual memory). Диспетчер памяти VMS назначает каждому процессу верхние и нижние пределы количества физической памяти (такой алгоритм называется рабочий набор, working set).
Эта возможность регулирует распределение физической памяти между приложениями, чтобы процесс, требующий много памяти не смог воздействовать, таким образом, на другие приложения.
Как и с диспетчером процессов, примечательные отличия существуют между диспетчером памяти NT и VMS. Диспетчер настройки баланса VMS (VMS's Balance Set Manager) перемещает всю память процессов из памяти в файлы подкачки и обратно в память, в ответ на требования системы. Microsoft не перенесла этот механизм, известный как свопинг (swapping, устаревший механизм подкачки, согласно которому процесс выгружался из памяти не постранично, а целиком) в диспетчер настройки баланса NT, хотя некоторые из вторичных обязанностей диспетчера настройки баланса NT сходны с обязанностями диспетчера VMS.
Диспетчер ввода/вывода NT непосредственно основан на диспетчере ввода/вывода VMS. У обеих ОС он поддерживает многоуровневую модель драйверов через стек драйверов устройств, а также реализует асинхронные команды ввода/вывода, основанные на пакетах (специальных структурах данных), и способен динамически загружать и выгружать драйверы устройств. Стековые и загружаемые драйверы делают NT и VMS очень расширяемымыми ОС. Любая из них может делить функциональность между несколькими драйверами устройств, при этом каждый из них будет реализовывать свой уровень абстракции. Например, система может вставить отказоустойчивый драйвер диска (fault-tolerant disk driver) между драйвером файловой системы и дисковым драйвером. Эта конфигурация позволяет отказоустойчивому драйверу диска получать запрос, который система посылает на один логический диск (например, C), и далее отправить запрос на несколько физических дисков, чтобы осуществить зеркалирование или чередование. Асинхронный ввод/вывод позволяет приложениям и подсистемам ядра инициировать запросы на устройства и продолжать работу, и это предпочтительнее, чем просто ждать завершения запроса (синхронный ввод/вывод). Архитектура драйвера устройства NT и схема приоритетов запросов перерываний основаны на аналогичных в VMS.
NT и VMS представляют ресурсы как объекты, которыми система управляет через диспетчер объектов, он реализует унифицированный механизм подсчета ссылок и учета объектов. Диспетчер объектов регулирует выделение ресурса и вызывает функции исполнительной подсистемы, которые запросили уведомление об определенных операциях на объекте. Управление объектами в VMS не формализовано как в NT, и диспетчер объектов VMS - только свободная связь функций. Microsoft расширила диспетчер объектов в NT так, чтобы он предоставлял единую схему именования для всех ресурсов ядра.
Подсистема безопасности NT основана на объектах со списком избирательного управления доступом (discretionary access control lists). Эти списки определяют, какие пользователи и какие операции они могут выполнить на этих объектах. Digital добавила улучшенный DACL к модели безопасности VMS в версии 4.0 в 1984. Поэтому, реализация безопасности VMS - предшественник NT. Microsoft даже включала системные утилиты из VMS в NT, включая, Монитор Производительности (Performance Monitor), который основан на программе MONITOR, расширяемом мониторе производительности VMS (extensible VMS performance monitor). VMS включала утилиту под названием BACKUP задолго до того, как Microsoft разработала подобную ей для NT.
Статья "Почему Самый быстрый Чип не Победил", "Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) заявляет, что, когда инженеры Digital заметили общие черты между VMS и NT, они донесли свои наблюдения до высшего руководства. Вместо предъявления иска, Digital просто разорвала связи с Microsoft. Летом 1995, Digital анонсировала Affinity для OpenVMS, программу, которая требовала от MS помощи в обучении работе с NT технического персонала Digital, а также помощи в продвижении NT и OpenVMS как части сетевого решения клиент-сервер, и обещания встроить в NT поддежку Alpha процессора. Microsoft также заплатила Digital сумму между 65 миллионами и 100 миллионов долларов.
