Ibm os/2

Первая 32-разрядная версия OS/2 2.0 широко использовала прием, описанный в примере П.1, и представляла собой сочетание 32- и 16-разрядных подсистем. Так, подсистема ввода-вывода была полностью 16-разрядной и, тем самым, обеспечивала полную совместимость со старыми драйверами и другими модулями ядра. Тем не менее, система в полной мере использовала преимущества, предоставляемые новым процессором, такие, как страничная подкачка и режим виртуального 8086 [Минаси/Камарда 1996]. Реализованный в OS/2 2.x эмулятор DOS является одним из крупнейших достижений в сфере разработки виртуальных машин — фирма IBM имеет немалый опыт создания, поддержки и эксплуатации систем виртуальных машин для System/370-390 — и, безусловно, он остается лучшим в мире эмулятором DOS на момент написания книги (в связи с общим снижением интереса к приложениям DOS, вполне возможно, что этот эмулятор останется таковым навсегда). Для сравнения, эмулятор DOS в Windows NT/2000/XP уступает ему как по возможностям настройки, так и по универсальности; сессия DOS в Windows 95/98/ME не является эмулятором — запущенное в этой сессии приложение имеет возможность модифицировать критичные для системы данные и проблемы в этом приложении часто приводят к необходимости перезапуска всей ОС, иногда даже холодного. Про эмуляторы DOS в SVR4/X86 и Linux автор может сказать лишь словами поэта:

Иных не стану поминать Они под солнцем хладным зреют Бумаги даже замарать И то, как надо, не умеют. С. Есенин

Система имеет объектно-ориентированный пользовательский интерфейс, основанный на компонентах SOM (System Object Model). Еще одной, менее известной, но не менее важной на взгляд автора, уникальной особенностью IBM OS/2, является возможность установки пользовательской программой собственного обработчика страничных отказов. Данная особенность уникальна — во всяком случае, среди известных автору промышленно используемых ОС, и позволяет реализовать в пользовательском адресном пространстве функции, которые в других ОС могут исполняться только модулями ядра. Так, свободно распространяемая библиотека ЕМХ использует этот механизм для реализации полного функционального аналога системного вызова fork ОС семейства Unix; известен ряд реализаций отображения файлов в адресное пространство памяти. Развитие системы сопровождалось постепенной заменой 16-разрядных подсистем на 32-разрядные. В версии 4.5 — Warp Server for e-Business — была наконец-то реализована 32-разрядная подсистема ввода-вывода, и это позволило перенести в OS/2 сугубо 32-разрядный код журнальной файловой системы jfs, первоначально разработанной для IBM AIX. В версии 4.0 появился, а в версии 4.5 был включен в стандартную комплектацию стек TCP/IP, совместимый с BSD 4.4, с поддержкой IPSec и фильтрации пакетов[redbooks.ibm.com sg245393]. Первые версии системы отличались большими по тем временам требованиями к ресурсам (для нормальной работы требовалось около 16 Мбайт ОЗУ, по меркам начала 90-х — чрезвычайно много), и поэтому тоже имели успех преимущественно в качестве серверов. Некоторые мелкие улучшения позволили в версии 3.0 снизить минимальные требования до 8 Мбайт. Параллельно шло снижение цен на оперативную память, поэтому шансы OS/2 на получение массового признания в качестве ОС для настольного компьютера все возрастали и достигли максимума примерно в 1995—1996 гг. 203ак 86 В это время, однако, подразделение персональных систем IBM увлеклось другим проектом, на который сообщество пользователей OS/2 также возлагало большие надежды — OS/2 for PPC. Дело в том, что в описываемый период и среди пользователей, и среди производителей вычислительных систем преобладала точка зрения, что Intel исчерпал резервы повышения производительности своих процессоров и не может ни поднять тактовую частоту ЦПУ выше 60—80 Мгц, ни значительно повысить количество операций, исполняемых за один такт. Единственной перспективой повышения производительности представлялись RISC-архитектуры, в том числе — разрабатываемый совместно компаниями IBM, Apple и Motorola микропроцессор архитектуры PowerRISC. Первые процессоры с такой системой команд были разработаны фирмой IBM для рабочих станций и серверов серии RS/6000, но реализовались на нескольких микросхемах. Однокристальный процессор и соответствующие микросхемы окружения (адаптеры системной и периферийной шин и т. д.) должны были резко снизить стоимость системы, переведя ее из категории рабочих станций в персональные компьютеры. IBM рассчитывала воспроизвести успех IBM PC, опубликовав полные спецификации и, таким образом, привлечь производителей клонов новой архитектуры, получившей название Power PC. Для этой системы была начата разработка новой версии OS/2. Бинарная совместимость с существующим кодом на новом процессоре была, конечно же, невозможна, поэтому IBM с легким сердцем пошла на пересмотр архитектуры. Новая система должна была стать полностью 32-разрядной и микроядерной, совместимой с OS/2-x86 лишь на уровне исходного кода приложений. К несчастью, пока новая система разрабатывалась, Intel все-таки посрамил скептиков и преодолел барьеры в 60, а затем и 100 Мгц, и выпустил новое семейство суперскалярных микропрограммируемых ядер — сначала двухкристальные сборки Pentium Pro и Pentium II (на самом деле, тот же Pro, только с более удачной конструкцией корпуса) и, наконец, однокристальный Pentium III. Новое ядро позволило исполнять по несколько команд за такт и, таким образом, перейти второй якобы непреодолимый для х86 барьер. Для проекта PowerPC это было крахом. Хотя система по-прежнему превосходила машины на основе х86 как по абсолютной производительности, так и по отношению производительности к цене, теперь разница была не настолько велика, чтобы оправдать для конечного пользователя переход на новую архитектуру и отказ от старых приложений. Микропроцессоры Power имели успех в составе новой линии персональных компьютеров Apple (PowerMac) и рабочих станций, но не смогли составить конкуренции на рынке PC. Эталонная реализация спецификаций РРС была выпущена и изготавливалась небольшими сериями, вышли версии Linux, Solans и Windows NT 4.0 для новой архитектуры, но коммерческого успеха машина не имела и не могла оправдать разработку полностью новой ОС. Работы по OS/2 for PPC были свернуты. Разочарование руководства IBM было столь сильным, что были также прекращены работы по другим перспективным технологиям — объектной модели SOM (System Object Model) и стандарту OpenDOC. Чувствуя потерю интереса к системе со стороны ее поставщиков, многие разработчики приложений отказапись от ее поддержки. К моменту написания книги слухи о смерти OS/2 сильно преувеличены. В 2001 г. был выпущен совместный продукт IBM и Serenity Systems — eComstation[www.ecomstation.com], клиентская версия системы, основанная на ядре версии 4.5. Тем не менее, очевидно, что система вытеснена на периферию сферы внимания пользователей и разработчиков программного обеспечения для х86.

Windows NT/2000/XP

Наработки Microsoft no OS/2 New Technology были в 1993 г. выпущены на рынок под названием Windows NT. Версии 3.x и 4.0 этой системы обеспечивали совместимость с 16-разрядными приложениями для OS/2 1.x в отдельной подсистеме, без возможности обращаться из 16-разрядных приложений к 32-разрядным DLL и наоборот. В описываемый период из DEC в Microsoft в полном составе перешла команда разработчиков ядра VMS под управлением Д. Катера. Microsoft широко рекламировал этот факт и утверждал, что Windows NT находится с VMS в гораздо более близком родстве, чем с OS/2 1.x. Из табл. П.1 видно, что это утверждение не очень-то согласуется с действительностью.

Таблица П.1. Сравнение OS/2 1.2, Windows NT и VMS

	OS/2 1.x	Windows NT 3.x	VMS
Mногозадачность	Вытесняющая	Вытесняющая	Вытесняющая
Ядро	Монолитное	Монолитное	Монолитное
Ввод-вывод	Асинхронный	Асинхронный -	Асинхронный
Защита памяти	Сегментная	Страничная	Страничная
	Трехуровневая	Двухуровневая	Трехуровневая
Сборка при загрузке	Динамическая	Динамическая	Статическая
Подкачка	Задачная	Страничная	Страничная
Поиск жертвы	—	FIFO	FIFO
Файловая система	Без транзакций	Журнальная	Журнальная
Программный RAID	RAID I	RAIDO I 5	RAIDO 1
Длина имени файла	256	256	32+16
Версии файлов	Нет	Нет	Да
Форматы файлов	Потоковый	Потоковый	Блочный
			Относительный
			Индексно- последовательный
Командный процессор	cmd.exe	cmd.exe	DCL
Граф, подсистема	РМ	Win32	X Window
Ид. пользователя	Вся система	Задача	Задача
БД учетных записей	Распределенная	Распределенная	Локальная
Сетевой протокол	NETBIOS/SMB	NETBIOS/SMB	DECNet

Наиболее важные заимствования из VMS — страничная подкачка и идентификация пользователя на уровне процессов — являлись ответом на насущные требования развития системы и могли быть заимствованы из любой ОС, адекватной времени. В остальном, табл. П.1 показывает, что OS/2 1.x, безусловно, приходится Windows NT гораздо более близкой родней, чем VMS. Наиболее важной заимствованной концепцией была журнальная файловая система NTFS, представляющая собой любопытный гибрид HPFS (основной ФС OS/2) и FCS2 (основной ФС VAX/VMS). Это заимствование следует признать довольно удачным. Гораздо менее удачным было заимствование своеобразной стратегии управления рабочими множествами процессов в ОЗУ, используемой в VMS: разработчики Microsoft устранили из этой стратегии одно из ключевых понятий, квоту размера рабочего множества. В результате получилась система, практически не способная воспользоваться преимуществами страничной подкачки, потому что даже небольшая нехватка оперативной памяти приводит к резкому падению производительности из-за неспособности системы сбалансировать потребности приложений и дискового кэша. Еще одна ключевая для понимания архитектуры Win32 концепция была позаимствована вовсе не из VMS и даже не из OS/2 1.x, а была, скорее всего, введена по настоятельным просьбам разработчиков графических приложений для Apple Macintosh. Речь идет о системном реестре (system registry), централизованной базе данных, в которой все модули системы, стандартные утилиты и прикладные программы хранят все, что считают нужным сохранить. Системный реестр впервые был реализован в Mac OS. Эта система имеет довольно простое ядро и небогатый набор системных настроек, поэтому реестр Mac OS в основном содержит настройки прикладных программ и в такой форме вполне терпим. Напротив, довольно сложная многопользовательская Windows NT, поддерживающая широкий спектр внешних устройств, нуждается в большом объеме конфигурационных данных для самой системы. Характер обращений к разным частям этих данных сильно различается — некоторые, например, нужны только при загрузке системы, а изменению подлежат только при изменении аппаратной конфигурации. Другие же меняются при каждом открытии нового окна пользовательской программой. Относительная ценность этих данных также различается очень резко: искажение некоторых может привести к невозможности загрузить систему или к потере пользователями доступа к ней, некоторые другие можно было бы и не хранить вовсе. В свете этого, идея общей "свалки", в которой содержится все на свете, — начиная от слов, которые произносил пользователь, пытаясь убрать с экрана знаменитую скрепку, и заканчивая БД учетных записей -представляется автору не очень-то здравой мыслью. В Windows NT этот концептуальный недостаток усугубляется недостатками реализации — реестр не имеет адекватных средств резервного копирования и восстановления (при фатальных повреждениях реестра Microsoft рекомендует переустановку системы) и фактически лишен средств самоконтроля и диагностики. Во всяком случае, в версии 4.0 (автор не имел случая проверить это на более поздних версиях системы, но судя по тому, что исправление этой ошибки не анонсировалось, в 2000/ХР ситуация не изменилась) ОС никогда не уменьшала объем реестра, даже после удаления большого количества ключей. Еще одним важным новшеством была поддержка нескольких процессоров — кроме х8б первые версии Windows NT были реализованы для RISC-процессоров MIPS и DEC Alpha, и, существенно позднее, для PowerPC. Большинство RISC-процессоров не имеют многоуровневых режимов доступа, характерных для VAX и 80286Д86, поэтому разработчики Windows NT были вынуждены отказаться от привилегированных разделяемых библиотек (понятие, которое в той или иной форме присутствовало как в OS/2 1.x, так и в VAX/VMS) и перейти к двухуровневой системе привилегий. Разработчики приложений не проявили интереса к альтернативным аппаратным архитектурам, поэтому NT на этих архитектурах не имела большого успеха, и в 1999 г. без большого шума была прекращена поддержка Windows NT для последнего неинтеловского процессора, который к тому времени уже назывался Compaq Alpha [techupdate.zdnet.com]. К тому же, пока NT была малоиспользуемой системой с бедным набором сетевых сервисов, мало кто всерьез интересовался ее взломом. Это привело к усилению давления со стороны управленцев - "вот видите, у соседей стоит -- и ничего", поэтому серверы под управлением NT все чаще и чаше подключались к Internet, иногда даже без закрытия каким-либо брандмауэром (надо отметить, что firewall (брандмауэр) в данном случае мало чем может помочь — сайт [www.microsoft.com] закрыт маршрутизатором с фильтрацией пакетов "по самые уши", и то его "роняют" несколько раз в год). Распространение системы привело к тому, что взломщики из спортивного интереса заинтересовались ею всерьез. Первой ласточкой был выпущенный в 1997 г. свободно распространяемый продукт Back Orifice (дословно — "задний проход"), демонстрировавший целый набор способов получения неавторизованного доступа (в том числе и с последующей установкой троянских программ) к системам Win32. Устанавливаемый в качестве троянской программы компонент пакета долгое время был лучшим из доступных инструментов удаленного управления Win32-системами и автор знает немало системных администраторов, которые использовали его в своих сетях [www.sourceforge.net bo2k]. Впрочем, одна ласточка весны не делает, и еще три года пользователи Win32-cHCTCM жили относительно спокойно (если можцо считать спокойной жизнью постоянную борьбу с макровирусами для MS Office, почтовыми вирусами и другими порождениями больной фантазии). За это время в систему добавились новые сетевые сервисы и расширилась номенклатура сервисов, запускаемых при установке ОС по умолчанию — например, в их число попал флагманский серверный продукт, сервер ftp/HTTP и ряд других протоколов, IIS (Internet Information Server). Собственно весна настала в августе 2001 г. с пандемией сетевого червя Code Red, который, как и червь Морриса, использовал несколько каналов распространения, в том числе срывы буфера в сетевых сервисах IIS. Как и червь Морриса, заразив одну из машин домена, Code Red распространялся на другие машины того же домена простым копированием по сети. Дальнейшее развитие событий, впрочем, резко отличалось от последствий атаки червя Морриса: Microsoft довольно быстро выпустила заплаты (patches), исправлявшие часть используемых вирусом ошибок — однако полное количество ошибок, оставшихся в коде системы и сетевых сервисов, от этого почти не изменилось. Атаки червей и поливалентных (использующих несколько каналов распространения) вирусов, которые легко преодолевают корпоративные брандмауэры (firewalls), продолжались на протяжении всего 2001 г., демонстрируя все новые и новые проблемы в системе безопасности Windows NT/2000/XP. В опубликованном в сентябре 2001 г. докладе аналитическая компания Gartner Group рекомендовала ни при каких обстоятельствах не использовать IIS из-за огромного количества известных и весьма пессимистических прогнозов на количество неизвестных уязвимостей. К моменту написания книги прогнозировать дальнейшее развитие событий не представлялось возможным. Очевидно, что ситуация с безопасностью Windows может только ухудшаться — или, точнее, абсолютная нетерпимость положения дел с безопасностью в Windows может становиться только более и более очевидна все большему и большему кругу людей. Попытки исправить положение законодательными мерами, например, применяя уголовные наказания к разработчикам вирусов или запрещая публикацию сведений о проблемах с безопасностью, вряд ли могут изменить тенденцию. Так, наказание для разработчиков вирусов, хотя и морально оправданно, но вряд ли может быть эффективным, потому что в большинстве случаев создателя практически невозможно идентифицировать, а идентифицировав — весьма сложно доказать его вину по стандартам судопроизводства демократических стран. В свою очередь, законодательный запрет публикации сведений об ошибках, разговоры о котором начались в 2001 г., не только абсолютно не оправдан морально, но и крайне вреден с прагматической точки зрения, хотя бы только потому, что сделает невозможным принятие контрмер администраторами уязвимых систем. Оптимистический сценарий развития событий может состоять в том, что пользователи начнут массовым образом отказываться от применения Windows, или Microsoft пересмотрит свой подход к проектированию, разработке и тестированию программного обеспечения (или в данном случае включающее). Так или иначе, исправление положения потребует значительных вложений в перестройку всей вычислительной инфраструктуры и не может пройти безболезненно. Впрочем, исторический опыт дает автору весьма мало оснований для оптимизма.

Windows 95/98/ME

В первой половине 90-х годов XX столетия практически всем разработчикам и техническим специалистам было очевидно, что MS и DR DOS доживают последние дни: они не удовлетворяли запросам пользователей практически ни по одному из параметров: приложения требовали больших объемов памяти и перехода к 32-разрядной архитектуре, пользователям требовались большая надежность, многозадачность, более развитые сетевые средства. Напротив, преимущества DOS, такие, как небольшая потребность в памяти, становились все менее и менее критичными. Основным препятствием на пути перехода пользователей на другие платформы было требование совместимости с существующими приложениями и драйверами нестандартных внешних устройств для DOS. Наилучшим образом удовлетворяла этому требованию IBM OS/2, в виртуальной машине которой можно было запустить не только практически любое приложение DOS, но и использовать многие модули ядра DOS, в том числе — загружая в разных виртуальных машинах разные версии ДОС и разные наборы драйверов. Однако высокие требования этой системы к ресурсам и ориентированная на корпоративных пользователей схема лицензирования приводили к тому, что система не получила большого распространения на массовом рынке. В 1992-1993 гг. Microsoft занялась разработкой системы, которая должна была заполнить перспективную рыночную нишу "многозадачной ДОС защищенного режима". Подобно марксизму, разрабатываемая ОС имела три источника и три составные части.

1. 1. Windows NT

2. 2. DesqView и другие многозадачные среды для DOS

3. 3. Windows 3.x

От Windows NT новая система получила интерфейс системных вызовов — Win32 API — и формат загружаемого модуля РЕ (Portable Executable — переносимый исполняемый [модуль]). У многозадачных сред разработчики новой ОС позаимствовали идею преобразования DOS в многозадачную среду защищенного режима: эти среды демонстрировали, что помещение ядра DOS в виртуальный 8086 и окружение его семафорами позволяет относительно малой кровью получить как многозадачность, так и совместимость. Такая архитектура была довольно-таки трудоемка в реализации и создавала специфические проблемы (так, DOS не отдавала управления при обращениях к приводу гибких дисков, поэтому работа с дискетами из любой сессии приводила к остановке всех остальных сессий), но не представляла непреодолимых концептуальных сложностей и была в целом работоспособна. Windows 3.x представляла собой пример системы, реализовавшей интерфейс между пользовательскими программами, работающими в защищенном режиме, и ядром DOS, исполняющимся в виртуальном 8086. К 1993-1994 гг. на рынке существовало более десятка других продуктов, предоставляющих аналогичный интерфейс, так называемых расширителей DOS (DOS Extender), среди которых нельзя не упомянуть PharLap DOS Extender, Rational DOS/4G и свободно распространяемый на условиях GPL djgpp. С точки зрения разработчиков новой ОС Windows 3.x представляла наибольший интерес в качестве отправной точки, потому что, в отличие от остальных расширителей DOS, она предоставляла динамическую сборку в момент загрузки и реализовывала также событийно-ориентированную архитектуру, пусть и более примитивную, чем асинхронная очередь сообщений Win32. К тому же, Windows 3.11 имела собственную дисковую подсис- тему, позволявшую работать с жестким диском в обход DOS (так называемый 32-битный доступ к диску). Первым получившим признание результатом работ над новой системой был продукт Win32s — набор DLL для Windows 3.x, позволявший исполнять загрузочные модули формата РЕ, использовавшие подмножество Win32 API. После длинной последовательности публичных бета-версий, многократного переноса сроков и большой шумихи в прессе новая система, получившая название Windows 95, вышла на рынок в 1995 г. Система с самого начала задумывалась как переходная, предназначенная для облегчения перевода пользовательской базы DOS на Windows NT, однако прошло не менее 4—5 лет, прежде чем совместимость с приложениями DOS перестала быть решающим параметром при выборе ОС для настольного компьютера. За это время успело выйти несколько версий "переходной" системы (OSR2, 98, 98SE, Millennium Edition) и даже после выхода ХР Microsoft еще не готова объявить о прекращении поддержки этой линии ОС.

Windows СЕ

Система, предназначенная для кросс-разработки приложений, прошиваемых в ПЗУ, сверхпортативных компьютеров. К моменту написания книги это единственная система из семейства СР/М, поддерживающая процессоры, отличные от х86. Использование ПЗУ позволяет отказаться от целого набора подсистем, обслуживающих виртуальную память, загрузку исполняемых модулей и сборку в момент загрузки. Система предоставляет графический пользовательский интерфейс с асинхронной очередью сообщений, вытесняющую многопоточность и базовый стек TCP/IP. В поставку системы входит среда кросс-разработки (компилятор, эмулятор целевого процессора, удаленный отладчик и интегрированная оболочка), работающая под Windows NT [Boling 2001]. Интерфейс системных вызовов этой ОС в целом похож на Win32 API — тем не менее, складывается впечатление, что основным источником требований было не обеспечение совместимости с приложениями для Win32 вообще, а пожелания разработчиков Mobile Office (пакет, включающий в себя функциональные аналоги некоторых программ из пакета Microsoft Office). Любопытно, что, рекламируя эту систему, Microsoft делает большой упор на то, что она разработана с нуля, т. е. без использования существующего кода Wiii32-cHcreM. На взгляд автора, это является косвенным признанием той репутации, которой качество кода этих систем заслуженно пользуется среди разработчиков и эксплуатационщиков.

27