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

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

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

NT значительно надежнее и устойчивей в работе, чем Windows-95. Это связано с несколькими важными системными механизмами, которые по-разному реализованы у этих систем.

На разницу в надежности в первую очередь влияют отличия в двух механизмах - механизме защиты памяти и механизме обработки сообщений. Как в Windows 95, так и в NT каждый процесс работает в виртуальном пространстве адресов размером 4G. Нижняя часть этого пространства отводится под код и ресурсы процесса, а верхняя - под область системного ядра. Область эта является разделяемым ресурсом, видным всем процессам. Отличие Windows 95 и NT заключается в том, что если в Windows NT процесс может получить доступ к ядру только посредством вызова особых функций, то в Windows 95 возможно непосредственное обращение к ядру как для чтения, так и для записи. Правда, для этого требуется выполнить достаточно сложный и, судя по всему, не предусмотренный фирмой Microsoft сценарий. Однако, произведя необходимые действия, процесс может модифицировать любую системную информацию. Надо ли говорить, что такая возможность сильно снижает надежность системы.

Код Windows NT действительно, а не по словам Microsoft, является полностью 32-битным. Этого нельзя сказать о коде Windows 95, в котором до сих пор сохранились участки, написанные для реального режима MS-DOS. Адская смесь из 32- и 16-разрядных фрагментов, соединенных хлипкими переходниками, была выполнена с целью как можно более облегчить выполнение 16-разрядных задач в новой системе. Но, как говорится, за что боролись, на то и напоролись. Именно эта гонка за совместимостью привела к некорректной работе 16-битных приложений под Windows 95.

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

Центральное место в жизненном цикле любой вычислительной единицы Windows занимают сообщения. Это некие блоки информации, описывающие события, происходящие в системе и передаваемые задачам. Процессорное время не выделяется задачам, для которых нет сообщений. В Windows 3.1 16-битные задачи должны были сами отдавать управление системному ядру после обработки очередного сообщения (это называется корпоративная многозадачность). Если одна из задач зацикливалась и не возвращала управление, общая для всех задач системная очередь сообщений переполнялась и система зависала. В Windows 95 использована другая модель многозадачности, при которой системное ядро само отбирает управление у процесса по прошествии определенного количества тактов процессора, независимо от того, завершилась обработка текущего сообщения или нет (многозадачность с вытеснением). Кроме того, каждая задача теперь имеет свою собственную очередь сообщений, так что переполнение одной из них не приводит к переполнению всех и гибнет только некорректно работающий процесс.

Так выполняются "родные" 32-битные приложения. Для 16-битных же действителен следующий механизм. Поскольку 16-битные задачи, в отличие от 32-битных, могут использовать для обмена данными общую память, то они должны "видеть" друг друга. Поэтому выполняются они все в общем виртуальном пространстве адресов и имеют общую очередь системных сообщений. Зато, как и 32-битные задачи, они используют полутридцатидвухбитное ядро. Для того, чтобы это было возможно, Microsoft написала специальный 16-битный переходник к новому 32-битному диспетчеру сообщений. С этим-то переходником и связана следующая неприятная ситуация. Когда 16-битная задача после получения сообщения не возвращает управление, переходник, а, следовательно, и вся система диспетчеризации сообщений, оказывается намертво захваченным ею. Это приводит к зависанию всех (а не только 16-битных) процессов, включая системные.

В Windows NT все 16-битные задачи просто-напросто сгружаются вместе с функциями эмуляции 16-битного ядра в общую область виртуальной памяти и никуда оттуда не выпускаются. Внутри ее этим задачам можно делать все, что угодно, но ни в коем случае не пересекать ее границы (своеобразная песочница). Это надежно работает, однако любая палка, особенно если это палка от Microsoft, имеет два очень твердых конца. В данном случае проблема в том, что многим 16-битным задачам такое обращение не нравится и они отказываются работать (так же, как и большинство приложений MS-DOS). Кроме того, это приводит к снижению производительности для 16-битных приложений. Зато работающие в среде полностью 32-битного ядра 32-битные задачи выполняются существенно быстрее, чем в Windows 95.

Необходимо признать следующий неприятный факт: не существует совместимости по 32-битным задачам Windows 95 и NT, как не существует единого 32-битного API. Некоторые из приложений могут работать только под Windows 95, некоторые только под NT (хотя большинство работает и там, и там).

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

Денис МАРГОЛИН