В этот раз давайте отвлечемся от вопросов исправления AD и поставим вопрос более широко - как обеспечить надежность и гибкость операционных систем семейства Windows, как для настольных систем, так и для серверных. К сожалению, Microsoft отказывается признать тот факт, что серверная и профессиональная версии являются совершенно различными операционными системами. Я уже не говорю о так называемых редакциях для домашнего использования, так как мне непонятно, чем, кроме маркетинговых соображений, оправдано их существование. Честно говоря, мне кажется, Microsoft пора прекратить это дробление версий операционной системы, но, похоже, говорить об этом пока рано.

В Microsoft приняли решение строить серверную и настольную системы на общем ядре. Поначалу это показалось отличной идеей, поскольку такая методика позволяет компании добиться существенной экономии на разработке и сопровождении. Представьте себе, например, что после выпуска NT Server 4.0 и NT Workstation 4.0 была обнаружена серьезная ошибка в менеджере виртуальной памяти (что, кстати, и было на самом деле - именно поэтому пакет исправлений SP1 был выпущен так быстро). Поскольку обе системы построены на одном и том же ядре, Microsoft выпускает единый пакет исправлений для обеих операционных систем сразу. А еще общая база исходного кода позволяет быстрее и проще реализовывать новые идеи. Например, Microsoft разрабатывает технологию Indigo - новую коммуникационную инфраструктуру на основе web-служб в Windows .NET Framework. Благодаря единой базе исходного кода, теоретически, Indigo сразу будет готова к внедрению во все возможные варианты операционных систем Microsoft - Longhorn Server, Longhorn professional edition, home edition, web edition, media edition (профессиональный выпуск, версия для домашних пользователей, редакция для Сети, мультимедийная редакция) и т.д.

Вышеупомянутые достоинства использования общей базы исходного кода являются очень привлекательными, но, на мой взгляд, делать ядро Windows Server идентичным ядру операционных систем для настольных компьютеров - это как если бы инженеры Форд проектировали легковушку Focus и грузовик F350 с одинаковым двигателем. Может быть, это и упростило бы разработку и позволило сэкономить за счет унификации деталей и узлов, но в результате получился бы либо Focus с фантастически высоким расходом топлива, или грузовик F350, который сам не стронется с места. За двумя зайцами погонишься...

Вот отличный пример, поясняющий, почему версии операционной системы для сервера и клиента должны иметь различные базы исходного кода: вопрос заключается в том, располагаются ли драйверы видео и принтеров в режиме ядра или в пользовательском режиме. Почему этот вопрос важен для нас? Когда системы поколения NT только появились на рынке, драйверы графики и принтеров исполнялись в пользовательском режиме, а не в режиме ядра. Такой подход имеет свои плюсы и минусы. Положительный момент заключается в том, что когда происходит отказ драйвера в пользовательском режиме, в остальном система остается работоспособной. Происходит только отключение плохого драйвера, а при отказе драйвера, исполняющегося в режиме ядра, пользователь увидит "голубой экран смерти". С другой стороны, если драйвер исполняется в пользовательском режиме, он работает существенно медленнее.

При создании Windows NT 3.1 разработчики старались исполнять в пользовательском режиме все, что можно, надеясь, что это обеспечит значительную устойчивость системы. Но этот подход, конечно, имеет свои ограничения - если происходит сбой в драйвере файловой системы, исполняемом на уровне пользователя, система зависнет, так как для продолжения работы требуется выполнить операции с диском для повторной загрузки драйвера, что оказывается невозможным. Но дисковые драйверы более важны для работы сервера, чем драйверы графических адаптеров и принтеров (и не так разнообразны). Поэтому Дэйв Катлер, первый архитектор систем NT, проектировал графические и принтерные подсистемы именно в пользовательском режиме. С одной стороны, ошибка в этих драйверах не обрушит сервер, но это будет достигнуто ценой некоторого снижения производительности при обработке графики и печати.

Лично я согласился бы на такое снижение производительности. Мой сервер, выполняющий множество задач, может временно перестать обслуживать сетевую печать из-за, допустим, ошибки в наскоро написанном драйвере принтера, но пусть при этом продолжают работать SQL Server, Exchange Server и файловый сервер. Пусть у меня будет возможность выбора, когда перезапустить сервер для восстановления функции печати, или же просто перезапустить сервис Spooler. Это достаточно логично, не правда ли?

Но ведь у серверных систем и настольного клиента общее ядро. И хотя клиент Windows не зависнет от плохого драйвера принтера или видео, он будет медленно обрабатывать графику. Другими словами, операционная система Microsoft не очень подходит для игрушек. По какой-то непонятной причине высшее руководство Microsoft сочло, что NT Workstation 4.0 должна быть лучшей платформой для компьютерных игр. Так, было принято решение исполнять драйверы графики и принтеров (поскольку они тесно взаимосвязаны, и трудно изменить один драйвер, не затронув другой) в режиме ядра, а не в пользовательском режиме. Если бы серверная и настольная версии NT имели различные ядра, можно было бы оставить эти драйверы в пользовательском режиме для сервера и исполнять их в режиме ядра для рабочей станции. Это, конечно, привело бы к необходимости иметь различные наборы драйверов для рабочей станции и сервера, но, я думаю, пользователи пошли бы на это ради увеличения надежности систем.

Недавний всплеск распространения вирусов, использующих уязвимость JPEG, лишний раз подчеркивает еще одну проблему использования общей базы исходного кода. Интерфейс графических устройств GDI (Graphics Device Interface) представляет собой подсистему Windows для работы с графикой. Эта подсистема работала прекрасно много лет, но в Windows XP корпорация Microsoft решила заменить ее усовершенствованной подсистемой GDI+. Как можно догадаться, для настольных компьютеров высокая производительность графической подсистемы очень важна. Старые программы GDI обрабатывали JPEG без проблем. Но в код JPEG подсистемы GDI+, как недавно выяснилось, закралась "классическая" ошибка переполнения буфера. А раз Windows 2003 Server и Windows XP используют общую базу исходного кода, сервер нового поколения унаследовал ошибочный код обработчика JPEG и оказался уязвимым для вирусов, передающихся через JPEG.

Представьте себе, насколько более производительным и защищенным мог бы быть сервер Windows 2003 Server, если бы он не был жестко привязан к коду для настольных систем Windows. Например, можно было бы создать версию сервера без графического интерфейса пользователя или с отключаемым графическим интерфейсом. В свою очередь, версия Windows для настольных систем тоже могла бы стать более простой, компактной и эффективной, если не включать в нее лишние функции сервера.

Microsoft лишает себя многих возможностей, вкладывая массу сил и средств в поддержку единой базы исходного кода, но в действительности коды настольного и серверного вариантов Windows все равно различны. Это следует, например, из того факта, что пакет исправлений XP SP2 был выпущен в августе, а обновления Windows 2003 SP1 будут готовы только в конце 2004 или начале 2005 года. Вряд ли это можно считать общей базой исходного кода. На мой взгляд,  Microsoft следовало бы принять компромиссное решение и разделить исходный код настольных и серверных систем. Это приведет к увеличению затрат на поддержку и сопровождение систем, зато обеспечит значительно большую надежность и гибкость их работы и настройки.

Марк Минаси (mark@minasi.com) - Редактор Windows & .NET Magazine, имеет сертификат MCSE; является автором книги «Mastering Windows NT Server 4.0» (издательство Sybex).