Отличительные особенности системы unix по сравнению с системой windows nt

From Julio Merino’s newsletter:

Over the years, I’ve repeatedly heard that Windows NT is a very advanced operating system and, being a Unix person myself, it has bothered me to not know why. I’ve been meaning to answer this question for years and I can do so now, which means I want to present you my findings.

My desire to know about NT’s internals started in 2006 when I applied to the Google Summer of Code program to develop Boost.Process. I needed such a library for ATF, but I also saw the project as a chance to learn something about the Win32 API. This journey then continued in 2020 with me choosing to join Microsoft after a long stint at Google and me buying the Windows Internals 5th edition book in 2021 (which I never fully read due to its incredible detail and length). None of these made me learn what I wanted though: the ways in which NT fundamentally differs from Unix, if at all.

Картинка с сайта: unixism.net

[…]

NT was groundbreaking technology when it launched. As I presented above, many of the features we take for granted today in systems design were present in NT since its inception, whereas almost all other Unix systems had to gain those features slowly over time. As a result, such features don’t always integrate seamlessly with Unix philosophies.

Today, however, it’s not clear to me that NT is truly “more advanced” than, say, Linux or FreeBSD. It is true that NT had more solid design principles at the onset and more features that its contemporary operating systems, but nowadays… the differences are blurry. Yes, NT is advanced, but not significantly more so than modern Unixes.

What I find disappointing is that, even though NT has all these solid design principles in place… bloat in the UI doesn’t let the design shine through. The sluggishness of the OS even on super-powerful machines is painful to witness and might even lead to the demise of this OS.

Brilliant read for those of you interested in operating system design.

Время на прочтение7 мин

Количество просмотров111K

Введение

В последнее время наблюдается большой приток пользователей Linux. Как правило это люди уже имеющие вполне приличный опыт в общении с компьютером, но этот опыт в большинстве случаев ограничен одной системой. Естественно, что этой системой является самая распространенная на сегодня на дескотопах операционная система компании Microsoft MS Windows. Большое число пользователей Windows также ставят Linux, или запускают его с «Live CD» «на посмотреть».

И тут возникает сразу несколько проблем, связанных с тем, что новые пользователи Linux ожидают увидеть перед собой «еще один Windows». А Linux — это совсем не клон Windows, это совсем другая система, с другой основой, другими традициями, другими возможностями и другими требованиями к пользователю.

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

Очень глубоко лезть в устройство этих двух операционных систем нам, я думаю, ни к чему, будем рассматривать их в основном с точки зрения пользователя.

Экскурс в историю (очень краткий)

Для сравнения, думаю невредно освежить в памяти краткую историю сравниваемых операционных систем.

История Unix

Операционная система UNIX была создана еще до эры коммерческого софта. Она писалась инженерами, как система «для себя». Поэтому в нее были заложены передовые на то время концепции. В дальнейшем своем развитии при добавлении новых черт, обычно считалось, что делать нужно «правильно». Т.е. например если нужно было выбирать из двух решений, одно из которых было с инженерной точки зрения «неправильным», например повышало производительность сегодня, но могло принести затруднения в дальнейшем, как правило, такое решение отвергалось и выбиралось «правильное» решение, пусть и с определенной потерей производительности.

Первые версии UNIX были написаны на Ассеблере, затем система была переписана на СИ. Это дало системе уникальную переносимость. На PC UNIX был портирован, а точнее заново написан (Linux) сразу, как только развитие PC, а точнее выпуск PC на процессоре i386, позволило это сделать.

В 1985 году стартовал проект POSIX. Это стандарт на интерфейсы UNIX-подобных ОС. Во многом благодаря наличию такого стандарта, так быстро смог появится на свет и достигнуть зрелости Linux — свободная воплощение UNIX.

Развитие интернета с самого начала и до нашего времени неразрывно связано с серверами под управлением ОС UNIX. Сначала с коммерческими, а теперь все больше и больше со свободными.

С точки зрения коммерциализации развитие UNIX можно разделить на три этапа.

1. Некоммерческое распространение в университетах.
2. Распространение коммерческих UNIX систем.
3. Появление свободных реализаций (Linux, FreeBSD) и вытеснение коммерческих систем (настоящий момент).

До появления системы X Window System UNIX была системой с текстовым интерфейсом, затем добавился графический, но традиционно текстовый интерфейс сохраняет важное значение.

Очень важно то, что UNIX с самого начала был многозадачной и многопользовательской системой. Т.е. на одной машине могут работать сразу несколько пользователей, и выполняться несколько программ одновременно.

Фирменной чертой всех UNIX-подобных ОС была и остается надежность.

Табличка:

История Windows

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

Первой ОС из этого семейства была DOS. Может показаться, что DOS собственно имеет косвенное отношение к обсуждаемому предмету. Но, многие традиции, база пользователей и разработчиков, их привычки, идут именно оттуда.

DOS была однозадачной однопользовательской операционной системой с текстовым интерфейсом. Первая версия Windows представляла собой нечто, негодное для работы и распространения не получила. Работать стало в Windows стало возможно, начиная с версии 3. В версии Windows For Workgroups 3.1 появилась возможность работы с сетью. Winodws серии 3 представляли собой запускаемую поверх DOS систему. Отличались невысокой надежностью.

В 1995 годы вышла новая версия — Windows 95. Код частично был 32 разрядным, частично 16 разрядным, встроенная сеть. По сравнению с Windows серии 3 это был серьезный шаг вперед. Повысилась надежность, но до надежности UNIX-подобных ОС было еще далеко. В качестве рабочей станции с натяжкой конечно, надежности хватало, в качестве сервера, нет. Позже были выпущены еще две ОС этой линии, Windows 98 и Windows Me. После этого линия была закрыта.

В 1993 году вышла новая версия — Windows NT 3.1. Это уже была полностью 32 разрядная система. Разработана она была с нуля, для ее разработки были наняты известные специалисты. Были внедрены новые концепции. Это подняло надежность почти до уровня надежности UNIX-подобных систем. Эта ОС уже могла работать в качестве сервера. Продолжение этой линии, операционные системы Windows 2000, Windows XP и Windows Vista.

ОС линии NT были многозадачными, начиная с Windows XP появилась и возможность работать нескольким пользователям, хотя и более ограниченная и гораздо менее удобная, чем у UNIX-подобных ОС.

Табличка:

Техническое устройство с точки зрения пользователя

UNIX

С точки зрения пользователя UNIX устроен примерно так:

1. Ядро. Работает с устройствами, управляет памятью и процессами.
2. Текстовая подсистема, работа с системой через терминал. Причем для управления всеми возможностями ОС достаточно только текстовой подсистемы. Возможно вход через эту подсистему многих пользователей. Богатый набор как встроенных утилит, так и приложений, работающих в текстовом режиме.
3. Графическая подсистема Xwindow. Запускается как процесс в системе.
4. Система удаленного доступа в текстовом режиме. Позволяет полноценную работу с ОС в текстовом режиме. Потребляет мало ресурсов. Позволяет работать на сравнительно слабых компьютерах одновременно десяткам и сотням пользователей. Количество сессий ограничено ресурсами компьютеров.
5. Система удаленного доступа в графическом режиме. Позволяет одновременно работать нескольким пользователям в графическом режиме. Количество сессий ограничено ресурсами компьютеров.
6. Система передачи графического окна приложения на другой компьютер. Позволяет запустив приложение на одном компьютере, управлять им с другого компьютера, через окно приложения, передаваемое на этот другой компьютер. Количество сессий ограничено ресурсами компьютеров.

Windows

1. Ядро. Работает с устройствами, управляет памятью и процессами, управляет графической подсистемой.
2. Графическая подсистема. Обеспечивает интерфейс с пользователем. Приоритетная система для пользовательского интерфейса.
3. Текстовая подсистема. Обеспечивает текстовый интерфейс с пользователем. Текстовый интерфейс весьма урезанный. Набор утилит текстового режима как встроенных, так и других производителей весьма куцый. Синтаксис и состав команд текстового режима меняется от версии к версии. Запускается только поверх графического режима.
4. Система удаленного доступа. Появилась впервые, как встроенная в систему, в Windows NT Server 4.0. До этого были только продукты других фирм. В связи с тем, что запускается полноценная графическая сессия, кушает очень много ресурсов. Наличие системы удаленного доступа и количество одновременных сессий может вообще отсутствовать или быть ограничено в разных версиях из коммерческих соображений.

Сравнение концепций

Давайте теперь рассмотрим, чем отличается подход к работе в этих двух системах.

UNIX: Концепция «Toolbox»

Поскольку UNIX разрабатывалась инженерами и для инженеров, в ее основу была положена концепция toolbox (ящик с инструментами). Что это значит? Это значит, что при создании софта и встроенных утилит для UNIX не делали универсальные программы, каждая из которых выполняла бы внутри себя все, необходимые пользователю действия, а для каждой небольшой задачи создавалась своя утилита, которая выполняла свою задачу, только одну, но делала это хорошо. Дело пользователя было при помощи набора этих утилит выполнить операции, которые ему нужно сделать.

При этом из этого набора утилит можно составлять цепочки и последовательности действий, что позволяет легко автоматизировать рутинные, часто повторяющиеся операции.

Для того, чтобы утилиты могли обмениваться между собой результатами своей работы, в качестве носителя информации был выбран текстовый файл. Для обмена информацией между утилитами были изобретены «pipes» (трубы). При помощи «труб» информация с выхода одной команды может быть передана на вход второй, та ее обрабатывает, выдает свою информацию на выход, которая может быть передана на вход третьей и так далее.

В общем, в результате UNIX позволяет пользователю легко создавать простые программные комплексы, выполняющие повторяющиеся действия как по команде пользователя, так и в автономном режиме.

Такой подход имеет как плюсы, так и недостатки. С одной стороны он дает больший контроль над системой, гибкость в настройке, но при этом повышается порог вхождения в систему, или говоря простыми словами, прежде, чем что нибудь сделать, как правило, нужно изучить основы.

Windows: Концепция «Тостер»

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

Ухудшает ситуацию о построением комплексов на базе Windows то, что большинство программ — коммерческие и используют свои, бинарные и как правило закрытые форматы данных и файлов. Такой подход превращает компьютер в устройство, которое может выполнять ограниченный изготовителем ПО набор функций, в пределе в этакий своеобразный «тостер», который выполняет только то, что задумал его изготовитель.

Плюс такого подхода — легкость вхождения неподготовленного пользователя. Минус — то, что обманутый кажущейся легкостью пользователь вообще не хочет ничему учиться и не выполнять необходимых действий. На поводу идут и производители софта. Это одна из причин такого обилия документов отформатированных пробелами, пренебрежения безопасностью и как следствие вирусных эпидемий.

Заключение

Конечно, в обоих системах не доминирует свой подход на 100 процентов. Как в Windows есть возможность пользоваться текстовой консолью и создавать .bat файлы, так и в UNIX есть большой набор программ, со свойствами присущими скорее «тостерному» подходу. И все таки описанная разница в подходах есть и она достаточно ярко выражена.

Литература

1. http://ru.wikipedia.org/wiki/UNIX
2. http://ru.wikipedia.org/wiki/Windows
3. http://ru.wikipedia.org/wiki/ДОС
4. http://posix.ru/
5. http://ru.wikipedia.org/wiki/POSIX

Чем важны различия между графическими интерфейсами Windows и Unix?

Мог ли единичный просчет разработчиков Windows вызвать тот грандиозный рост суммарной стоимости владения, который мы наблюдаем? В этой статье — третьей в серии «Ближайшие десять минут» мы подробно исследуем вопрос о том, почему важны различия между графическими средами Windows и Unix.

Серия «Ближайшие десять минут» представляет собой исследование эволюции Windows NT, цель которого — проложить через шумиху и рекламные обещания путь к выявлению факторов, реально влияющих на формирование этой ОС.

Предлагаемая вашему вниманию статья — третья по счету. В первой — «В поисках будущей Windows NT» (русский перевод см. http://www.pcworld.ru/1998/11/98.htm) анализируются последствия того, что Microsoft рассматривает защиту своей монополии на рынке ПО для настольных компьютеров как задачу номер один. Вторая — «Новые Unix-системы меняют орбиту NT» (сокращенный русский перевод см. «Мир ПК», 1998, N 11, с. 62, полный — http://www.pcworld.ru/1998/11/62.htm) посвящена влиянию, которое способна оказать на развитие NT вновь возросшая популярность Unix.

В этой публикации мы более подробно обсудим влияние Unix на NT, а также остановимся на сделанном в начале мая заявлении Microsoft о том, что корпорация собирается выпускать для NT пакет служб Unix (см. врезку «Новаторский взгляд на критику»).

Покупатель всегда прав

Большинство слабых сторон Windows NT в конечном счете проистекают из одного-единственного источника — тезиса рыночной философии Microsoft, гласящего «Windows повсюду». Его применение порождает не только бесконечные дискуссии о том, действительно ли Microsoft стремится к мировому господству, но и совершенно конкретные технические решения. Заметим, что «Windows повсюду» обязательно предполагает «Windows на каждом рабочем столе».

Этот тезис определил одну из наиболее существенных особенностей эволюции Windows NT, отличающую ее от Unix. Создатели Unix никогда не исходили из предположения, что все поголовно будут работать в Unix и на клиентских, и на серверных машинах, и в дальнейшем распространение этой ОС на все рабочие места считалось — вполне справедливо — ненужной и неоправданно дорогой затеей. Лишь в самые последние годы Unix-системы стали достаточно дешевыми и дружественными к пользователю для того, чтобы рассматриваться как возможная альтернатива Windows в качестве клиентской ОС.

В случае же Windows цель распространить систему на все рабочие места, наоборот, всегда рассматривалась как реально достижимая, и Windows действительно присутствовала чуть ли не на любом ПК, когда проектировалась NT. Создавая NT, Microsoft стремилась вовсе не к тотальному внедрению Windows — оно уже произошло. Нужно было добиться лишь всеобщего перехода на новую версию.

Но эта проблема оказалась трудноразрешимой. Windows NT имела слишком мало достоинств, способных привлечь внимание пользователей Windows 3.1. Будучи относительно дешевой, NT стоила все-таки дороже, чем Windows 3.1, а памяти требовала намного больше; ее пользовательский интерфейс не содержал нововведений, облегчающих или ускоряющих работу. Сама по себе Windows NT 3.1 была стабильнее, чем Windows 3.1, но с существующими 16-разрядными Windows-программами (которых накопилось великое множество) работала не очень хорошо. В довершение всего, первый вариант поддержки NetWare оказался настолько неустойчивым, что журналисты прозвали реквестер NetWare «вирусом».

И тогда Microsoft в соответствии со своими неоднократно декларировавшимися принципами прислушалась к мнению потребителей и сосредоточила усилия на том, чтобы ускорить работу Windows NT путем встраивания графической подсистемы в ядро ОС. Это грозило снижением стабильности системы, зато позволяло упростить ее интерфейс.

Windows в заложниках у локальной машины

«Усовершенствуя» таким образом NT, Microsoft ни на мгновение не упускала из виду конечную цель — Windows на каждом рабочем столе. Поэтому в одном весьма важном отношении Windows NT не менялась: машины должны были работать со своими локальными пользовательскими контекстами.

Иначе говоря, и система, и прикладные программы предполагают, что все элементы служб ОС, взаимодействующие с пользователем, управляемые и настраиваемые им, от графической подсистемы до конкретного пользовательского интерфейса выполняются целиком на машине пользователя.

А поскольку Microsoft сосредоточилась на задаче поставить Windows на каждый рабочий стол, возможность иной, более удачной организации работы клиентов и серверов в сети предприятия никогда не рассматривалась. (Аргументы в пользу того, что Windows NT до сих пор остается ОС для настольной машины, приводятся во врезке «Рабочий стол вашей ОС».)

И тут, словно по воле злой судьбы, почти одновременно приключилось несколько событий:

• Windows NT стала достаточно быстрой и дружественной, чтобы привлекать покупателей;
• снижение цен на вычислительную технику сделало доступной аппаратуру, необходимую для Windows NT;
• Internet вторглась в компьютерные сети компаний.

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

Землетрясение Internet, колеблющее сейчас основы Windows, началось тогда, когда люди стали осознавать, что «опыт работы с браузером» определяется информацией на сервере, а не на клиентской машине, и никак не зависит от того, браузер какой фирмы используется. Этот опыт остается с вами, куда бы вы ни двинулись. С появлением Java и смарт-карт толчки усилились еще на несколько баллов по шкале Рихтера: стало возможным взять с собой куда угодно также программы и информацию личного характера, не подлежащую разглашению.

Эта идея не нова для тех, кто привык к зеленому экрану Unix-терминала, но миллионы пользователей Windows восприняли ее как поистине революционную.

Критики сетевых компьютеров поднимают много шума вокруг того обстоятельства, что при «сетецентрическом» подходе единичный сбой сервера способен парализовать работу всех пользователей. В действительности в этом есть некая ирония: ведь они не учитывают, что абсолютно все пользователи Windows были и остаются заложниками одной-елинственной ошибки — своей собственной машины.

Даже сейчас отделы информационных технологий с большим трудом признают очевидный вывод: безудержный рост стоимости владения вызван тем, что Windows спроектирована в расчете на наличие на каждой машине локального пользовательского контекста.

Этот момент следует подчеркнуть особо. Фактически все косметические решения, предлагаемые Microsoft в качестве реакции на усилившееся беспокойство по поводу суммарной стоимости владения, вращаются вокруг все той же проблемы локального пользовательского контекста.

Проект Zero Administration Windows представляет собой попытку организовать управление пользовательским контекстом на сервере с передачей элементов этого контекста на клиентскую машину по мере необходимости, проект Intellimirror — попытку делать моментальные снимки локального контекста (включая пользовательские прикладные программы и файлы конфигурации) и хранить их на сервере, чтобы пользователь мог извлекать их с других рабочих станций. И то, и другое — «заплаты», обходные маневры, предпринятые с вполне осознанной целью избежать переработки NT и непосредственного обращения к реальной проблеме: необходимо, чтобы Windows вообще не ожидала наличия на машине локального пользовательского контекста.

Окна, которые ходят по проволоке

Угрожает ли теперь Unix господству Windows NT на настольных машинах вследствие описанного дефекта? Вполне возможно. Благодаря ли достоинствам Unix или из-за разочарования в Windows все больше людей открывают для себя тот факт, что Unix-системы для процессоров Intel предлагают «лучшее из двух миров»: пользователь получает все преимущества локальной обработки данных на недорогом ПК без ограничений, накладываемых присущим Windows требованием локального пользовательского контекста.

Как уже говорилось выше, при создании Unix предполагалось, что новая ОС будет слишком дорогостоящей для того, чтобы устанавливать ее на каждый рабочий стол. Разработчики видели Unix скорее системой для серверов, и в результате она стала многопользовательской в совершенно ином смысле, чем Windows NT.

Поскольку в Unix нужно было обеспечить параллельное выполнение программ несколькими пользователями, взаимодействующими с машиной через графический или алфавитно-цифровой терминал, там с самого начала требовалось организовать работу с многопользовательскими контекстами на сервере. (Это, разумеется, справедливо не только для Unix, но и для ряда других ОС, однако такие системы, как MVS или OS/400, в отличие от Unix, не проникают на настольные машины с процессором Intel.)

Позже для Unix были разработаны графические стандарты X11, и, хотя это не было необходимо, систему X Window спроектировали состоящей из двух частей — X-клиента и X-сервера.

Существует возможность запустить и X-клиент, и X-сервер на Unix-севере, чтобы работать на нем с графическими утилитами администрирования (а счастливые обладатели рабочих станций Unix используют и X-клиент, и X-сервер при выполнении своих локальных программ). Но по большей части система X Window использовалась для запуска программ на Unix-сервере с недорогого графического терминала или другого устройства. (В действительности X-терминалы стоили немало, но были все-таки дешевле, чем полноценные RISC-станции с Unix.)

В пользовательском контексте

При использовании стандарта X11 локальный контекст не нужен, поэтому для Unix нет необходимости в проектах типа Zero Administration или Intellimirror. Пользователь и так может (в пределах своих полномочий) запускать на сервере какие угодно программы и даже администрировать сервер с клиента любого из перечисленных ниже типов, причем не требуется, чтобы клиент этому пользователю «принадлежал» или был для него сконфигурирован. (Разумеется, алфавитно-цифровые терминалы поддерживают только программы текстового режима; они включены в перечень, чтобы подчеркнуть, что Unix-сервером можно управлять из командной строки, а NT-сервером — нет.)

• любой алфавитно-цифровой терминал, чаще всего типа ANSI или VT100;
• любой ПК с любой ОС, для которой реализован клиент Telnet;
• любой X-терминал;
• любой ПК, на котором запущена программа X-сервера, например Exceed для Windows NT компании Hummingbird Communications или Reflection компании WRQ (таких программ очень много);
• любая рабочая станция с любой версией Unix, поддерживающей стандарт X11R6, — от UltraSPARC с Solaris до ПК на базе процессора 386 с FreeBSD.

В противоположность этому, Zero Administration Windows и Intellimirror будут работать только с операционной системой Microsoft, умеющей их понимать (вероятнее всего, такой способностью будут обладать Windows 98 и Windows NT 5.0).

Реальных, не косметических вариантов решения проблемы пользовательского контекста всего два: нужно либо полностью перестроить графические службы и многопользовательские контексты в Windows, либо соорудить некое подобие многопользовательского контекста и на его основе — альтернативу «тонкого клиента», работающую по принципу, сходному с применяемым в X11.

На сегодняшний день Microsoft объявила, что стремится осуществить второй вариант. Она заключила с компанией Citrix соглашение о создании Windows NT 4.0 Terminal Server Edition. Однако сама по себе версия Terminal Server Edition работает только с Windows-клиентами. Чтобы иметь возможность подключать другие платформы, нужно дополнительно установить Citrix pICAsso (MetaFrame).

Красиво, но непрочно

Отметим, что Microsoft, получив от Citrix полностью готовый продукт (WinFrame 2.0) и пользуясь поддержкой специалистов компании, по прошествии целого года была еще не готова выпустить свой собственный Windows Terminal Server (о выходе окончательной версии было объявлено 16 июня, уже после публикации оригинала статьи. — Прим. ред.).

Конечно, очень мешало то, что графические службы не предусматривали работу даже с одним протоколом поддержки «тонкого клиента», а нужны были целых два: RDP, стандартный для Microsoft, и дополнительно Citrix MetaFrame. Но самой серьезной проблемой стала неспособность сервера вполне корректно обрабатывать одновременно несколько пользовательских контекстов. Специалистам из Citrix так и не удалось ее полностью решить, и вряд ли вообще удастся, пока Windows NT будет развиваться по прежнему пути.

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

Однако не все программы работают с реестром так, как ожидалось, и в некоторых случаях запись реестра используется как общая (либо указывает на файл, который в результате используется как общий), когда по замыслу настройка должна быть своей для каждого экземпляра программы (в зависимости от пользователя).

Слабейшее звено

Помимо сложностей с многопользовательской работой, графические службы и драйверы NT вместе образуют слабейшее звено системы. Не нужно быть экспертом, чтобы увидеть, что графическим службам нехватает гибкости и расширяемости. Достаточно запустить любой диспетчер виртуальных рабочих столов (как минимум два есть в составе пакета Windows NT Resource Kit), и, если только вы не используете низкое разрешение экрана или очень быстрый процессор, медлительность программы по сравнению с аналогами для Unix или OS/2 сразу бросится в глаза.

Хуже того, как вы, наверное, уже догадались, некоторые диспетчеры пытаются для каждого виртуального рабочего стола генерировать отдельный виртуальный пользовательский контекст. В результате многие из программ, «интегрированных» в рабочий стол Windows, начинают выдавать сообщения об ошибках, поскольку не способны существовать в нескольких экземплярах. (Программа Paperport компании Visioneer, например, пытается загрузить себя в каждом рабочем столе и не получает доступа к драйверу Paperport.)

Не будем также забывать, что NT в принципе не может обеспечить такую же стабильность, как Unix, — чтобы этого добиться, пришлось бы пересмотреть применяемую в NT модель графического драйвера. Графическим драйверам Windows NT, в отличие от Unix, доступны критически важные области системной памяти. Это и есть «опасная модель драйвера», упоминавшаяся в предыдущей статье (см. «Мир ПК», 1998, N 11, с. 62).

И на клиенте, и на сервере работа Windows NT всецело зависит от качества графических драйверов и использующих их программ. Мелкая ошибка в драйвере может оставаться незамеченной до тех пор, пока не проявится при запуске какой-либо прикладной программы или сочетания программ в виде чего угодно от незначительного сбоя (бессмысленный текст в окне) до самого что ни на есть настоящего «синего экрана смерти».

В Unix механизм X11 и драйверы дисплея изолированы от ядра системы, и благодаря этому Unix гораздо лучше подходит для многопользовательской (читай: корпоративной) среды, чем Citrix WinFrame или Windows Terminal Server. Unix-сервер по самой своей природе более надежен, поскольку сбои графических драйверов не влияют на его работу.

Здесь мы исходили из предположения, что на сервере выполняются программы, использующие графику. Однако в действительности даже и это не обязательно: для того чтобы пользователи со своих графических терминалов, рабочих станций и ПК могли обращаться к графическим программам, запущенным на Unix-сервере, поддержка графики на самом сервере, вообще говоря, не нужна. X Window позволяет выполнять на сервере расчетную часть программы, просто отправляя результаты на удаленный терминал или рабочую станцию и получая оттуда входную информацию.

Угроза со стороны бесплатных Unix-систем

Совершенно очевидно, что недорогие и бесплатные Unix-системы для процессоров Intel должны представлять угрозу для Microsoft. И факты подтверждают это.

В первой публикации серии — «В поисках будущей Windows NT» (русский перевод см. http://www.pcworld.ru/1998/11/98.htm) было сделано следующее утверждение: «Если вы хотите знать, что Microsoft рассматривает как потенциальную угрозу для своей монополии на ПО для настольных компьютеров в будущем году, посмотрите, кого она пытается дискредитировать в нынешнем». Запомним это и отправимся на Web-страницу Microsoft, находящуюся по адресу http://www.microsoft.com/ie/unix/devs.htm и озаглавленную Getting Unix Out the Microsoft Door («Unix выходит из дверей Microsoft»). Здесь можно найти много интересных материалов, проливающих свет на отношение Microsoft к Unix.

Страница посвящена версии Microsoft Internet Explorer для Unix. Сначала автор текста эксплуатирует распространенное заблуждение о том, что ОС Unix погрязла в допотопном интерфейсе командной строки:

…неизбежно следовало учитывать, что их [программистов, которым был поручен перенос Internet Explorer в среду Unix], возможно, будут воспринимать как марсиан, что им предстоит пересечь технологическую пропасть шириной с Атлантический океан, отделяющую Старый свет Unix с его традициями командной строки от Нового света Windows и GUI, и столкнуться с враждебностью по отношению к непонятным новым ценностям: интуитивности, открываемости, практичности.

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

«Поразительно, насколько далеко NT сегодня ушла вперед по сравнению с Unix», — говорит [Дэвид] Доусон. «В качестве примера возьмите хотя бы поддержку многопоточной обработки. У Unix все еще есть определенные преимущества, но NT обеспечивает гораздо более полный набор возможностей».

Не вполне понятно, что имеет в виду Доусон. Поддержка потоков в Unix есть, хотя они обрабатываются иначе, чем в NT. Каждый из двух подходов имеет свои преимущества в зависимости от решаемой задачи.

Если же Доусон имел в виду не обработку потоков, а системы в целом, то поразительно, насколько далеко он зашел в отрицании реальности. Может быть, графическому ядру Unix X11 помог счастливый случай, но тем не менее оно, как было продемонстрировано выше, лучше подходит для распределенной обработки в среде клиент-сервер при решении критически важных задач, чем Windows NT Terminal Server или Citrix WinFrame. Даже с проверенной технологией Citrix создание аналога X11 оказалось для Microsoft очень непростым делом.

Один сервер WinFrame с 512 Мбайт оперативной памяти стандартно способен поддерживать до 50 пользователей, а один Unix-сервер — несколько сотен. X11 тяжелее для сетевого соединения из-за своей большей распределенности, WinFrame же просто переносит всю нагрузку на сервер. Unix далеко впереди NT.

И, наконец, хотя Microsoft и свидетельствует свое почтение Linux,..

Что же касается Рэнди Чэпмена, то он уже много лет назад, в 1993 г., сделал своей основной платформой Unix в варианте Linux. Из них двоих [разработчиков IE для Unix] Чэпмен, видимо, наиболее искренне и прочно привязан к Unix: он сохранил Linux на одной из второстепенных машин у себя дома и даже вспоминает, как загружал свой первый дистрибутив Linux по модему на 2400 бод, добавляя: «Вскоре после этого я завел себе модем на 14,4».

…мы должны подчеркнуть, что лучше всего проверять, какие ОС корпорация рассматривает как угрозу для себя, по тому, каким из них она отказывает в поддержке. Например, Microsoft обещала обеспечить поддержку OS/2, если объем ее продаж достигнет 2 млн. экземпляров, но продолжала игнорировать платформу даже после того, как эта цифра составила 12 млн.

Коль скоро ностальгия по Linux согревает сердце, Microsoft лучше всего продемонстрировала бы благожелательное отношение к этой ОС, а заодно и к другим популярным Unix-системами для Intel (FreeBSD, BSDI, SCO Unix, Solaris x86), реализовав для них версию Internet Explorer. Однако пока браузер существует в Unix-варианте лишь для Solaris на машинах SPARC.

Свою судьбу творим мы сами

Похоже, Microsoft рассматривает угрозу со стороны Unix-систем для Intel как вполне реальную. Если учесть поддержку Linux со стороны таких знаменитых производителей ПО, как Corel и Netscape (чуть позже к ним присоединились Informix, Computer Associates, Oracle. — Прим. ред.), может показаться, что Unix действительно начинает отвоевывать утраченные было позиции. Однако на рынке далеко не всегда побеждают решения, наиболее совершенные в техническом отношении, даже если они доступны бесплатно. В конечном итоге только время покажет, насколько обоснованны опасения Microsoft и угрожает ли Unix будущему Windows.

Об авторе

Николас Петрели был главным редактором журнала NC World; в настоящее время возглавил редакцию нового электронного журнала Linux World; также является обозревателем журналов InfoWorld, где ведет колонку Down to the Wire, и NT World Japan. E-mail: nicholas.petreley@ncworldmag.com

Поистине активный каталог

Ваша любимая программа для Windows работает неправильно. Вы немного разбираетесь в компьютерах, и вам приходит в голову мысль заглянуть в конфигурационный файл.

Но где же хранится INI-файл? В том же каталоге, что и сама программа? В каком-то из его подкаталогов? В каталоге Windows? SYSTEM? SYSTEM32? А может быть, конфигурация целиком записана в системном реестре?

В определенных случаях можно столкнуться с любой комбинацией перечисленных выше возможностей. Это одно из злосчастных следствий необходимости поддерживать в NT совместимость с DOS и Windows 3.1. В противоположность этому, типичная файловая система Unix состоит из стандартным образом организованного набора каталогов. Различия между вариантами Unix не слишком значительны, так что если вы знакомы с какой-то одной Unix-системой, то без труда разберетесь в каталогах почти любой другой.

Практически каждая Unix-система обладает стандартной структурой каталогов примерно следующего вида:

Сравните это со стандартной структурой каталогов Windows NT:

Таблица 2. Типовая структура каталогов NT

Во многих отделах информационных технологий только сейчас начинают осознавать последствия столь непродуманного подхода. Мало того, что ручное конфигурирование превратилось в кошмар, программы устанавливают прилагаемые к ним библиотечные файлы общего пользования (DLL) где попало. Одни записывают свои DLL-файлы в каталоги WINNT, SYSTEM и SYSTEM32, затирая оказавшиеся там одноименные файлы, другие помещают их в собственный каталог программы или один из его подкаталогов, третьи используют смешанный подход. В результате в вашей системе могут оказаться несколько версий одного и того же DLL-файла, причем с одинаковыми именами.

Наверное, разработчики всех этих программ действуют в противоречии со стандартной процедурой, предписываемой Microsoft? Нет, предписаний на этот счет просто не существует. Скажем, пакет Microsoft Office 97 должен установить до 114 DLL-файлов в каталог WINNT и 84 — в каталог SYSTEM. Некоторые из них, в том числе библиотеки OLE automation и MFC (которые, кстати, скорее всего перепишет следующая же установленная вами программа), представляют собой новые версии библиотечных файлов, поставляемых с Windows NT. Фактически Office 97 интегрирована с Windows в той же степени, что и Internet Explorer, в соответствии с определением, на основании которого Microsoft настаивала, что IE неотделим от Windows 95.

Новаторский взгляд на критику

Рекламная кампания Microsoft под девизом «свобода инноваций» (ее целью было повлиять на действия Департамента юстиции США) вызвала настоящую бурю возмущения.

Разумеется, критики Microsoft имели полное право рассвирепеть по поводу бесчестности проводимой кампании. Но многие из них были склонны неверно оценивать тот факт, что Microsoft, как правило, не создает сама новаторских решений, и приравнивать недостаток новизны к плохому качеству.

Это просто совсем не тот случай. Apple совершенно справедливо хвалят за популяризацию графического интерфейса и подъем его качества до такого уровня, которого немногим удалось с тех пор достигнуть, а тем более превзойти. И все же графический интерфейс не является изобретением Apple.

Вполне можно уважать компанию Borland как создателя недорогих и исключительно простых в использовании пакетов для разработки программ. Однако не Borland изобрела Turbo Pascal, да и большинство других ее средств разработки тоже придуманы не в ней.

Так что фирма, которая продает выдающиеся продукты, заслуживает восхищения и в том случае, когда «не она их изобрела».

Запомним это и отметим, что центральная тема нашей серии публикаций — не неспособность Microsoft создать что-то действительно новое, а способность неправльной расстановки рыночных приоритетов отрицательно повлиять на развитие NT. Это различие очень важно, поскольку Microsoft, вероятно, сумела бы решить некоторые проблемы Windows NT, если бы вела конкурентную борьбу скорее формально, чем всерьез. И тогда пресловутый «недостаток новизны» мог бы послужить поводом разве что для аплодисментов, а не для оскорбительных выкриков, как сейчас.

Фактическое положение дел заключается в том, что Microsoft планирует просто скопировать определенные особенности Unix (в свете чего, кстати, ее позиция, выраженная в словах «поразительно, насколько далеко NT сегодня ушла вперед по сравнению с Unix», выглядит по меньшей мере забавно).

На весенней выставке Networld+Interop, проходившей в начале мая в Лас-Вегасе, Microsoft объявила, что планирует разработать дополнительный пакет для NT под названием Windows NT Services for Unix (в сентябре появилась его вторая бета-версия. — Прим. ред.). Джим Оллчин, старший вице-президент Microsoft по системам для бизнеса, сообщил, что продукт будет обеспечивать функции клиента и сервера NFS, включать демона Telnet, командную оболочку Mortice Kern Systems (MKS, версия Korn shell) и систему синхронизации паролей с хост-машинами Unix, использующими службу безопасности Kerberos.

За сам факт признания важности перечисленных функций, Microsoft заслуживает всяческих похвал, однако ее подход имеет два потенциальных недостатка. Во-первых, службы Unix не включаются в состав NT: это дополнительный продукт. Во-вторых, если они не будут встроены в NT, клиенты, возможно, ничего или почти ничего не выиграют. Независимые производители уже не один год предлагают на рынке поддержку NFS и командных оболочек в стиле Unix для NT. Проблема не в том, что таких инструментов нет, а в том, что в NT недостает возможностей, без которых они не смогут приносить такую же пользу, как в Unix.

Командная оболочка MKS, например, предоставит NT более изощренный язык для написания сценариев, но не станет как по волшебству полезнее благодаря тому, что Microsoft ее лицензирует. Сценарии мало чем помогут вам, если в системе не предусмотрен запуск из командной строки утилит администрирования сервера и сети.

Будет ли Microsoft поставлять соответствующие средства командной строки, пока неясно; в сообщении Оллчина на выставке Networld+Interop об этом ничего не говорилось.

Рабочий стол вашей ОС

Сейчас, когда Microsoft поддерживает две серии Windows-систем — Windows 95 и Windows NT, легко позабыть о том, что в соответствии с первоначальным планом Windows NT должна была непосредственно сменить Windows 3.x. (Строго говоря, самый первый план состоял в том, что ее сменит OS/2, но когда альянс Microsoft и IBM распался, Microsoft приступила к созданию Windows NT. Возможно, NT даже сохранила существенную часть кода OS/2, а возможно, и нет — так или иначе Билл Гейтс однажды признался, что Windows представляет собой «настоящую следующую версию» OS/2.)

По мере развития Windows NT представители Microsoft неоднократно давали разнообразные обещания и делали предсказания касательно ее будущего. Одно из них состояло в том, что система будет выпускаться в двух вариантах: как ОС для настольной машины и со встоенной версией LAN Manager. К моменту выхода Windows NT 3.1 корпорация перестала рассматривать LAN Manager как отдельный продукт.

С технической точки зрения Windows NT Server так и остается ОС для настольной машины со встроенной версией LAN Manager. На сегодняшний день все различия между Windows NT Workstation 4.0 и Windows NT Server 4.0 сводятся лишь к содержанию двух записей системного реестра и лицензионного соглашения, а также к тому обстоятельству, что инсталляционный диск Windows NT Server содержит и устанавливает больше программ, чем диск NT Workstation.

«Чтобы найти истину, каждый должен хоть
раз в жизни освободиться от усвоенных
им представлений и заново построить
систему своих взглядов»
— Рене Декарт.

Статья, которая сейчас открыта в вашем браузере, посвящена детальному рассмотрению архитектуры UNIX и Windows. В ней мы постарались заглянуть внутрь этих двух операционных систем, опустившись на уровень ядра. Без внимания не остались и ошибки (исключения), которые могут возникнуть во время работы ОС. В заключение мы попросили сравнить различия между Windows и UNIX экспертов российской компании ASPLinux (www.asplinux.ru), которым каждый день на практике приходится сталкиваться с операционными системами на низком уровне.

Структуру UNIX проще всего представить в виде двух слоев. Первым является ядро. Оно непосредственно взаимодействует с железом и обеспечивает переносимость всего остального ПО на компьютеры с разным аппаратным обеспечением. Ядро предоставляет программам определенный набор системных API, с помощью которых производятся создание процессов, управление ими, их взаимодействие и синхронизация, а также файловый ввод/вывод. Вторым слоем является программное обеспечение, прикладное или системное: командный интерпретатор, графическая оболочка и т. д.

Заглянем глубже в ядро системы. Оно позволяет всем остальным программам общаться с периферийными устройствами, регулирует доступ к файлам, управляет память и процессами. Ядро — это связной, к которому обращаются посредством системных вызовов (запрашивая какую-то услугу). Связь эта — не односторонняя: ядро может и возвращать в случае необходимости какие-то данные. Основным достоинством ядра является строгая стандартизация системных API. За счет этого во многом достигается переносимость кода между разными версиями UNIX и абсолютно различным аппаратным обеспечением.

Картинка с сайта: fcenter.ru

Структура ядра UNIX

Все обращения к ядру системы можно разделить на две категории: программа вызывает подсистему управления файлами или подсистему управления процессами. Первая отвечает за все, что связано с файлами: управление, размещение, доступ. Процессы же — это, в общем случае, любые запущенные программы. Поэтому подсистема управления процессами служит для их жизнеспособности, синхронизации и управления. Важно так же и то, что файловая подсистема и подсистема управления процессов могут общаться друг с другом: любой процесс может вызывать системные API для работы с файлами. Прелесть UNIX состоит в том, что эти API универсальны (да и в Windows наблюдается та же картина). Вот самые главные из них: open, close, read, write, stat, chown, chmod (суть почти всех вызовов интуитивно понятна из названия, кроме, разве что, последних трех, поэтому поясню — они служат для управления атрибутами файлов, информации о владельце и прав доступа) и др. Каждый из этих системных вызовов в программе на языке С является обычной функцией. Информацию по любому из них можно запросто найти в man.
Подсистема управления файлами — почти единственная из всех работает с драйверами, которые являются модулями ядра. «Почти», потому что есть еще и сетевая подсистема, которая работает, например, с драйвером сетевой карты и с драйверами различных современных сетевых устройств. Ее, однако, мы рассматривать не будем. Обмен данными с драйверами может проходить двумя способами: с помощью буфера или потока. Суть первого метода заключается в том, что для информации выделяется кэш (или сверхоперативная память, как его называли раньше), в который заносится необходимый блок данных. Далее информация из кэша передается к драйверу. Драйвер — единственный элемент ядра, способный управлять периферийными устройствами. Но подсистема управления файлами может взаимодействовать с драйвером и через поток. Поток представляет собой посимвольную передачу данных драйверу. Следует отметить, что способ взаимодействия с драйвером определяется не пользователем и не приложением. Он является характеристикой того устройства, которым управляет драйвер. Очевидно, что потоковое общение позволяет взаимодействовать более оперативно, чем общение через буфер. Ведь на заполнение буфера тратится время и, следовательно, возрастает время отклика.

Теперь более подробно рассмотрим подсистему управления процессами. Она отвечает за синхронизацию и взаимодействие процессов, распределение памяти и планирование выполнения процессов. Для всех этих целей в подсистему управления процессами включены три модуля, которые наглядно продемонстрированы на схеме. Хорошим примером взаимодействия подсистем управления файлами и процессами является загрузка файла на исполнение. В этом случае подсистеме управления процессов требуется обратиться к коллеге, чтобы считать исполняемые файлы.

Чуть выше мы перечисляли системные API для управления файлами. Теперь рассмотрим вызовы, служащие для работы с процессами: fork (создает новый процесса), exec (выполняет процесс), exit (завершает исполнение процесса), wait (один из способов синхронизации), brk (управляет памятью, выделенной процессу), signal (обработчики исключений) и др.

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

Виртуальная память была изобретена в 1962 году, в Англии при создании суперкомпьютера Atlas. В большинстве современных компьютеров оперативная память не так велика, как используемое процессором адресное пространство. Размер ОЗУ типичного персонального компьютера варьируется от десятков до сотен мегабайт. При запуске программа загружается с какого-либо накопителя в оперативную память. Если же программа не помещается в ОЗУ, то те её части, которые в данный момент не выполняются, хранятся во вторичном запоминающем устройстве, чаще всего винчестере, и такая память называется виртуальной. Безусловно, перед выполнением необходимая часть программы должна быть перемещена в оперативную память. Данные функции выполняет ядро операционной системы (диспетчер виртуальной памяти, находящийся в микроядре). И для программы и для пользователя эти действия прозрачны. Естественно, на запросы к виртуальной памяти уходит гораздо большее время, нежели к ОЗУ.

Второй модуль — планировщик. Его задача не менее важна. UNIX — мультизадачная ОС, то есть одновременно может выполняться множество процессов. Мы, однако, знаем, что в фиксированный момент времени на одном процессоре может выполняться только одна команда. Именно поэтому нужен виртуальный рефери, который будет определять, какому процессу исполняться сейчас, а какому — через секунду. На практике же планировщик переключает контекст, то есть перед тем, как остановить исполнение какого-то процесса, он запоминает состояние регистров, памяти и т. д., а уже после этого запускает другой процесс в его собственном адресном пространстве. И еще один тонкий момент: каждый запущенный процесс «думает», что он единственный. Дополнительно существует механизм приоритетов. Очевидно, чем выше приоритет, тем быстрее начнет исполняться процесс. Процессы могут также обмениваться между собой информацией. В случае их синхронного взаимодействия синхронизацию осуществляет модуль взаимодействия (например, функция wait).

Вот мы и подошли к последнему уровню — аппаратному контролю. На данном уровне происходит обработка прерываний и связь ядра с железом. Здесь следует отметить лишь пару моментов, во-первых, прерывания могут «прерывать» работу процессора и требовать внимания к себе (после этого процессор без проблем возвращается к выполнению оставленных процессов), а, во-вторых, обработку прерываний осуществляют специальные функции ядра.

Windows 2000/XP построены на архитектуре микроядра (microkernel architecture). ОС Windows 95/98 используют монолитное (monolithic) ядро. Микроядра являются сравнительно небольшими и модульными. Благодаря последнему новые устройства зачастую добавляются как модули, которые можно загружать/выгружать на этапе исполнения без перекомпиляции ядра. На архитектуре микроядра построены также FreeBSD и Mac OS X. Монолитные же ядра используются еще и в Linux. Они оптимизированы для более высокой производительности с минимальными контекстными переключениями. Такая архитектура упрощает поддержку кода ядра для разработчиков, но требует перекомпиляции ядра при добавлении новых устройств. Следует отметить, что описанные здесь различия являются «классическими», на практике монолитные ядра могут поддерживать модульность (что зачастую и происходит), а микроядра могут требовать перекомпиляции.

Архитектура Windows

Структура Windows 2000/XP не отличается оригинальностью: ядро системы (исполняется на максимально приоритетном уровне процессора) и пользовательские подсистемы (исполняются на минимально приоритетном уровне).

Ядро системы является критичной частью кода, любые ошибки, происходящие в ядре, приводят к фатальному краху системы — «синему экрану». Фактически — это ошибки типа «Нарушение общей защиты». Как только код ядра начинает обращаться в запрещенные для него области памяти (попытка прочитать или записать данные, исполнить неверную инструкцию, переход на запрещенную область), срабатывает система защиты памяти процессора, и управление передается системному обработчику исключений. Обработчик исключений не может восстановить корректное поведение кода. Все, что он делает — это вывод дампа на синий экран с указанием типа ошибки и содержимого памяти в области, где сработала защита.
Пользовательские подсистемы не столь критично влияют на работу системы в целом, так как они изолированы друг от друга и от ядра средствами управления памятью и собственно процессором. Ошибки, возникающие в приложениях, исполняются на уровне пользователя, то есть на менее привилегированном уровне, нежели ядро. Поэтому, система в состоянии контролировать процесс. При возникновении же ошибки или сбоя управление передается обработчику ошибок, который называется «Doctor Watson». Он принудительно завершит приложение. Ядро системы и остальные подсистемы остаются в целости и сохранности.

Ядро UNIX/Linux имеет два вида исключений, которые обычно называют «oops» и «panic». Почти в каждой операционной системе паника происходит в тех случаях, когда ядро обнаруживает серьезную неисправность. Если система каким-либо образом повредила сама себя, ей требуется остановиться немедленно, пока она не произведет необратимых критических изменений (типа уничтожения файловой системы). Везде, где только возможно, UNIX/Linux пытается детектировать проблему и справиться с ней без остановки всей системы. Например, многие ситуации типа «oops» приводят к завершению процесса, который нормально запустился, но потом зациклил систему. Бывают, однако, ситуации, когда все настолько плохо, что полная паника является наилучшим выходом. Считается, что пользователи стабильных версий ядра не должны встречать ни «паник», ни «oops». Но в реальном мире они иногда происходят.

Недавно найденный «TF-баг» (смотрите здесь) является хорошим примером паники. Процессор пытается передать управление процессу, которого не существует. Это приводит к краху всей системы. В данном случае, у системы нет другой альтернативы, чем запаниковать.

Ядро, поставляемое с Red Hat Linux 7.3 (и некоторыми другими дистрибутивами), содержит баг в файловой системе ext3. Эта ошибка приводит к «oops», завершая время от времени некоторые процессы (также этот баг приводит к замедлению всей системы). Хотя данная ошибка уже исправлена (патч есть и в обновлении от Red Hat), этот случай познакомил многих пользователей с ошибками типа «oops».

Ядро Windows 2000/XP состоит из нескольких системных компонентов, каждый из которых отвечает за определенный набор задач. Основные компоненты ядра:

Микроядро (Microkernel) — компактный код, можно сказать, сердце системы. В рамках микроядра работают ключевые службы: диспетчер памяти, диспетчер задач и другие.

Слой абстрагирования (Hardware Abstraction Layer, HAL). Полностью абстрагирует код системы от конкретного аппаратного оборудования. Использование HAL позволяет обеспечить переносимость 99% кода системы между различным оборудованием.

Диспетчер Ввода/Вывода (Input/Output Manager). Полностью контролирует потоки обмена между системой и устройствами. Драйверы устройств работают в контексте I/O Manager. Если драйвер написан с ошибками и может привести к сбою — это вызовет фатальный крах ядра и всей системы. 70% случаев фатальных сбоев («синий экран») — есть результат некорректного поведения драйверов устройств.

Windows XP содержит встроенный механизм контроля драйверов: правильно написанный и тщательно протестированный драйвер поставляется с цифровой подписью (Driver Signing). Правильная настройка системы заключается в запрещении установки драйверов без корректной подписи.

Модуль управления объектами (Object Manager), управления виртуальной памятью (Virtual Memory Manager), управления процессами (Process Manager), управления безопасностью (Security Reference Monitor), управления локальными вызовами (Local Procedure Calls Facilities) — важные компоненты ядра системы подробно рассматриваться не будут.

Наконец, особое по значению и важности место в ядре системы занимает модуль графического интерфейса — Win32k.sys. Фактически — это часть подсистемы Win32, отвечающая за прорисовку и управление графическим интерфейсом. Этот модуль расположен в ядре специально для того, чтобы существенно повысить производительность графических операций ввода/вывода. Однако размещение столь критической части в ядре накладывает чрезвычайно строгие требования к корректности его исполнения. Фактически, ошибка в коде Win32k.sys приведет к краху системы. Разработчики Windows уделяют огромное внимание этому модулю, и именно он наиболее тщательно протестирован. Опыт эксплуатации систем Windows показывает, что код Win32k.sys работает абсолютно корректно и не содержит фатальных ошибок. Однако некорректный драйвер видеосистемы может все испортить.

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

Итог

Различия между Windows и UNIX для нас прокомментировали разработчики из компании ASPLinux.

«Операционные системы Unix и Windows достаточно сильно отличаются в реализации различных сервисов и служб. В соответствии с темами, затронутыми в этой статье, можно отметить несколько глобальных различий.

В Unix/Linux графическая система существует отдельно от ядра и функционирует как обычное приложение. В операционных системах Windows графическая система интегрирована в ядро. В случае использования операционной системы на рабочей станции, особенно при запуске графикоемких приложений, возможно, лучше, когда графическая система входит в ядро — в этом случае она может быстрее работать. А при работе на сервере предпочтительней отделение графической системы от ядра ОС, так как она загружает память и процессор. В случае Unix/Linux графическую систему можно просто отключить, к тому же, если системный администратор ее все-таки хочет использовать, в Linux есть несколько графических оболочек на выбор, некоторые из них (например, WindowMaker) достаточно слабо загружают машину. Эта же особенность Unix-образных операционных систем позволяет запускать эти ОС на машинах с весьма скромными объемами ОЗУ и т.п. В случае Windows же графическая система слишком тесно интегрирована в ОС, поэтому она должна запускаться даже на тех серверах, на которых она вовсе не нужна.

Отметим также методику разделения прав доступа в Windows 2000 и Unix/Linux. В первом — разделение прав доступа основано на ACL (access control lists), то есть, к примеру, можно настроить систему таким образом, чтобы администратор не имел возможности управлять файлами пользователей. У Unix/Linux же всегда есть суперпользователь — root, который имеет доступ абсолютно ко всему. То есть теоретически модель безопасности в Windows лучше: чтобы полностью завладеть хорошо настроенной системой Windows, хакеру придется ломать больше, в Unix/Linux же достаточно взломать доступ к root. (В Unix/Linux используются более старые технологии, тем не менее, некоторые дистрибутивы Linux сейчас начинают поддерживать ACL, среди них — ASPLinux 7.3 Server Edition). Но теория несколько смазывается практикой с той стороны, что в Windows не так быстро, как в Linux, заделываются «дыры», что уже относится к плюсам открытой модели разработки. В результате оказывается, что в Windows по статистике больше дыр, через которые злоумышленник может пробраться в систему. Но, опять же, точно о количестве дыр в Linux и Windows можно будет сказать только тогда, когда количество пользователей обоих видов ОС будет примерно одинаковым.

В Linux поддерживаются несколько файловых систем, наиболее продвинутые — это Ext2, Ext3, XFS. ОС Windows завязана по большому счету на одну файловую систему — NTFS или FAT 32. Файловые системы Ext2, Ext3, XFS по оценкам работают быстрее. Принципиальное же отличие в том, что в UNIX/Linux вообще нет понятия диска, физического или логического. Вся работа с устройствами хранения данных организуется через специальные файлы устройств, которые отображают физический носитель (диск, лента и т. п ) или его части (разделы) в файловую систему.

Важное отличие — наличие в Windows технологии ActiveX, нечто подобное в Unix/Linux реализуется с помощью CORBA и Bonobo. Эта технология, с одной стороны, предоставляет пользователю множество удобств, с другой стороны — она же допускала в свое время такие вещи, как автоматический запуск Outlook’ом вируса, пришедшего по почте. Одно из важных отличий этих технологий в том, что элементы ActiveX могут внедряться в текст HTML, что имеет как ряд достоинств, так и недостатков.

Можно перечислить еще ряд отличий Unix-подобных операционных систем от Windows, например, встроенную поддержку удаленного доступа в Unix и отсутствие оной в Windows по умолчанию (она реализуется в серверных версиях Windows, а также с помощью дополнительных средств, например, Citrix). В Unix/Linux и Windows сильно различаются сетевые подсистемы (IP-stack), по ряду оценок сетевая подсистема Unix/Linux эффективнее.

Можно было бы упомянуть богатый набор ПО, которое может поставляться вместе с Linux, между тем, Windows также развивается в этом направлении. Дополнительные отличия же в архитектуре в основном сводятся к отличиям работы монолитных и модульных ядер, которые также зачастую не являются преимуществами или недостатками, а просто отличиями. При всем при этом можно с уверенностью сказать, что характеристики работы Windows или Linux гораздо больше зависят от аккуратности и квалификации пользователя, чем от архитектуры той или иной ОС».

Мы искренне надеемся, что нам удалось описать основные различия двух систем. Если вы считаете, что какой-то аспект «анатомии» Windows или UNIX незаслуженно пропущен, милости просим в наш форум. Автор статьи (e-mail в начале) с удовольствием выслушает все ваши мысли.