Операционная система Windows

3.5 Операционная система Windows

3.5.1 Общие сведения об операционной системе Windows

Microsoft Windows – это высокопроизводительная, многозадачная и многопотоковая 32-разрядная операционная система с графическим интерфейсом и расширенными сетевыми возможностями, работающая в защищенном режиме, поддерживающая 16-разрядные приложения без всякой их модификации. Windows 9х – интегрированная среда, обеспечивающая эффективный обмен текстовой, графической, звуковой и видеоинформацией между отдельными программами. Базовые функциональные возможности Windows 9х перекрывают все, что заложено в MS-DOS, Windows 3.х и Windows для рабочих групп 3.х. Windows 9х – первая полномасштабная операционная система семейства Windows, не требующая MS-DOS. Она полностью совместима с используемыми в настоящее время программными и аппаратными средствами.

Усовершенствования, внесенные в архитектуру Windows 9х, дают пользователю ряд преимуществ, основные из которых связаны со следующими понятиями:

-     интегрированная операционная система;

-     вытесняющая многозадачность;

-     многопоточность.

Ядро интегрированной операционной системы загружаемое в момент включения компьютера, активизирует графический интерфейс пользователя и обеспечивает полную совместимость с операционной системой MS-DOS.

При использовании Windows 9х отпадает необходимость в отдельной копии MS-DOS.

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

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

82)      В Windows 9х для 32-битовых приложений используется механизм вытесняющей многозадачности, основанный на многопоточности.

83)      Многопоточность – свойство операционной системы выполнять операции одновременно над потоками нескольких 32-битовых приложений, называемых процессами.

84)      Процесс состоит из потоков.

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

86)      32-битовые приложения Windows 9х способны порождать или инициировать несколько потоков внутри данного процесса. Каждый процесс состоит как минимум из одного потока. Многопоточное приложение значительно эффективнее в работе, быстрее реагирует на действия пользователя и выполняет многие операции в фоновом режиме.

87)      Распределение времени между активными приложениями в Windows 9х осуществляет ядро ОС, а поддержка вытесняющей многозадачности обеспечивает плавное переключение между одновременно выполняемыми процессами и не позволяет одному приложению занять все системные ресурсы.

88)      Windows 9х выполняет 32-битовые и MS-DOS-приложения в режиме вытесняющей многозадачности, а 16-битовые приложения – в режиме кооперативной многозадачности.

89)      Везде, где не ущемляется совместимость с 16-битовыми приложениями и повышается производительность, Windows 9х использует 32-битовый код. Такие компоненты, как планировщик, диспетчер памяти, подсистема ввода-вывода и драйверы устройств, являются 32-битовыми. Многие графические функции, включая печать, растеризацию шрифтов True Type, ключевые графические операции, переведены в 32-битовый код. Вместе с тем значительная часть кода User, осуществляющая управление окнами, оставлена для совмещения с существующими приложениями в 16-битовом формате.

На рисунке 3.16 схематически показаны основные компоненты Windows 9х.

Рис. 3.16. Архитектура системы Windows 9х

Системная виртуальная машина (или просто системная ВМ) – так называется входящая в состав Windows 9х операционная среда, которая поддерживает работу всех Windows-приложений и таких подсистем Windows, как Интерфейс Графического Устройства (Graphics Device Interface, GDI).

32-разрядные приложения Windows – это новые приложения, которые используют 32-разрядную модель памяти 80386 процессора и подмножество разработанного Microsoft интерфейса прикладного программирования Win32. В Windows 9х каждое из приложений Win32 имеет собственное адресное пространство, которое недоступно другим приложениям. Windows 9х может управлять этими приложениями на основе принципа вытесняющей многозадачности.

Оболочка – это 32-разрядное приложение Windows, которое обеспечивает взаимодействие пользователя с системой. Оболочка Windows 9х объединяет функции, знакомые по Windows 3.1, Диспетчера Программ, Диспетчера Файлов и Диспетчера Задач в одном приложении.

16-разрядные приложения Windows – это "старые" приложения Windows. Они используют модель сегментной адресации памяти семейства процессоров Intel (модель памяти 80286 процессора). Так же как, и в Windows 3.1, 16-разрядные приложения при работе под Windows 9х делят между собой единое адресное пространство и не могут управляться в соответствии с принципом вытесняющей многозадачности. Microsoft называет их "приложениями Win16".

Уровень функций Windows API (Application Program Interface) интерфейса прикладного программирования Windows 9х обеспечивает полную совместимость с существующим Windows 3.1 API, а также поддержку нового 32-разрядного API, который доступен только 32-разрядным приложениям Windows. 32-разрядное API является подмножеством разработанного Microsoft интерфейса Win32, который впервые появился в Windows NT и в Win32s-расширении для Windows 3.1.

Модуль Windows Kernel поддерживает необходимые Windows низкоуровневые функции, такие как динамическое размещение памяти и др. В Windows 9х Kernel обеспечивает соответствующий сервис как для 16-разрядных, так и для 32-разрядных приложений.

Модуль Windows GDI обеспечивает графические возможности Windows и поддерживает работу с цветом, шрифтами и изобразительными примитивами для дисплея и принтеров. В Windows 9х модуль GDI продолжает поддерживать существующие 16-разрядные приложения, однако теперь он обладает еще и множеством новых возможностей, которые доступны только 32-раз-рядным программам.

Модуль User – это диспетчер окон. Он занимается созданием и управлением видимыми на экране окнами, диалоговыми окнами, кнопками и прочими элементами интерфейса Windows.

MS-DOS виртуальные машины (MS-DOS BM) обеспечивают работу приложений MS-DOS под Windows. Так же, как и в Win-dows 3.1, пользователь может одновременно запустить несколько MS-DOS BM. В Windows 9х появилось несколько нововведений, которые позволяют пользователю более эффективно управлять виртуальными машинами, однако в целом поддержка MS-DOS BM изменилась незначительно.

Остальные модули реализуют функции базовой системы.

Базовая система. Управление файловой системой в Windows 9х претерпело ряд серьезных изменений. В Windows 3.1 файловой системой локального диска управляла MS-DOS, что существенно снижало производительность Windows. До тех пор пока за управление файловой системой отвечала MS-DOS, внести в этот процесс какие-либо улучшения не представлялась возможным. В Windows 9х все обстоит совсем по-другому, а именно MS-DOS уже не используется для управления хранящимися на локальном диске файлами. Новая файловая подсистема обеспечивает набор интерфейсов, который делает возможным совместное использование различных файловых систем локальных дисков (включая и файловые системы, хранящиеся на компакт дисках) и сетевых файловых систем.

Сетевая подсистема представляет собой последнее воплощение разработанной Microsoft одноранговой сети, которая впервые появилась в Windows for Workgroups в 1992 г., а впоследствии и в Win-dows NT. Сетевая подсистема осуществляет доступ к удаленным файлам при помощи новой файловой подсистемы. Фирмы-производители сетевого программного обеспечения могут подключать свои продукты к новой файловой подсистеме, что обеспечит пользователю одновременный доступ к нескольким сетям. Сама Windows поддерживает протоколы SMB, Novell и TCP/IP.

Сервис операционной системы включает такие серьезные компоненты, как подсистема конфигурирования аппаратных средств Plug and Play, а также набор всевозможных полезных функций, вроде тех, что выдают информацию о текущих дате и времени.

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

Драйверы устройств в Windows могут быть самыми разнообразными, в том числе драйверы реального режима и так называемые виртуальные драйверы, или виртуальные драйверы внешних устройств (V×D). Некоторым программам для поддержки отдельных аппаратных средств могут потребоваться старые драйверы MS-DOS реального режима, однако при разработке Windows одна из главных задач состояла в создании драйверов защищенного режима для мыши, приводов компакт-дисков и большинства жестких дисков.

Виртуальные драйверы устройств, или V×D, помогают нескольким приложениям совместно использовать одно устройство. Например, запуск двух приложений MS-DOS в отдельных окнах требует от системы создания двух виртуальных машин MS-DOS, каждой из которых необходимо осуществлять вывод на единственный физический экран. Виртуальный драйвер экрана и должен обеспечивать возможность такого совместного применения. Термин "V×D" также используется как общее наименование некоторых 32-разрядный модулей операционной системы.

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

При рассмотрении виртуальных машин Windows важно обратить внимание на следующие моменты:

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

-     системная виртуальная машина все время работает в защищенном режиме. В Windows 3.1 системная ВМ для того, чтобы могли выполняться программы MS-DOS, в определенные моменты переключается из защищенного в виртуальный 8086-й режим, однако в Windows подобное происходит крайне редко;

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

Независимо от того, имеете вы дело с MS-DOS или системной виртуальной машиной, которая поддерживает работу всех приложений Windows, мощность и текущий контекст виртуальной машины определяются теми ресурсами, которые ей выделены. Каждая виртуальная машина включает в себя следующие компоненты:

-     карту памяти, которая определяет, какой объем виртуальной памяти доступен программе, выполняющейся в данный момент на этой виртуальной машине;

-     контекст выполнения, который определяется состоянием регистров виртуальной машины (регистров процессора прямого доступа, а также рядом других управляющих параметров, таких как, например, уровень привилегированного доступа к процессору);

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

Рассмотрим карту памяти Windows как компонент виртуальной машины (рис. 3.17).

386-й процессор поддерживает четырехгигабайтное виртуальное адресное пространство, и Windows способна использовать его целиком. В его пределах различные компоненты системы и приложения занимают участки с фиксированными границами. Одна из обязанностей Диспетчера виртуальных машин (Virtual Machine Manager – VMM) состоит в отображении этого четырехгигабайтного адресного пространства в доступную физическую память.

90)      На карте системной памяти нижний мегабайт виртуального адресного пространства используется для работающей в данный момент MS-DOS ВМ. Кроме того, каждая ВМ имеет в своем распоряжении еще и участок памяти в области между вторым и третьим гигабайтами. Подобное распределение памяти позволяет самой системе использовать память ВМ независимо от того, активна она или нет. Впрочем, когда работает MS-DOS ВМ, ее память отображается в начало первого мегабайта.

Рис. 3.17. Карта системной памяти Windows 9х

91)      В пределах виртуального адресного пространства 32-раз-рядных приложений стандартные средства разработки используют четвертый гигабайт как адрес загрузки по умолчанию. Можно, конечно, указать адрес и поменьше, однако это приводит к серьезному увеличению объема вычисления, которые будут связаны с тем, что системе придется производить пересчет адресов при загрузке приложений. Загрузка в адресное пространство, расположенное между четвертым и вторым гигабайтами, происходит мгновенно.

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

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

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

92)      Все действия MS-DOS по работе с файлами реализуются путем программного прерывания INT 21H, которое вызывает глобальную ошибку защиты (general protection fault), которую операционная система перехватывает и должным образом обрабатывает. Windows 3.1 временно переключает системную ВМ в виртуальный 8086-й режим, чтобы код, содержащий инструкцию MS-DOS INT 21H, мог отработать корректно. По завершении операции с файлом системная ВМ снова переключается в защищенный режим, и код приложения Windows продолжает выполняться.

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

Виртуальные машины MS-DOS – это точная копия работающего под управлением MS-DOS компьютера. С точки зрения приложения, ВМ обладает мегабайтом памяти, карта которой соответствует аппаратной карте памяти. Так, например, адресуемая напрямую видеопамять располагается, начиная с адреса В8000H. Обычно контекст MS-DOS представляет собой отображенную в виртуальное адресное пространство ВМ среду виртуального 8086-го режима с копией MS-DOS.

93)      MS-DOS ВМ настраиваются посредством ВМ, которую можно увидеть при помощи специальных средств отладки: эта ВМ никогда не содержит реально выполняющихся приложений. Она создается и настраивается в соответствии с начальным состоянием среды после того, как завершится начальная загрузка системы и обработка инструкций, содержащихся в файлах CONFIG.SYS и AUTOEXEC.BAT. Внутри скрытой BM содержится вся глобальная для среды MS-DOS информация. Например, если перед запуском Windows в файле AUTOEXEC.BAT предусмотрен запуск резидентной программы, она будет загружена и станет частью глобальной среды MS-DOS. Даже в Windows 9х, крайне мало зависящей от MS-DOS, можно использовать CONFIG.SYS для загрузки драйверов устройств и AUTOEXEC.BAT для запуска резидентных программ, которые необходимо сделать частью глобальной среды MS-DOS.

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

Новая архитектура файловой системы состоит из множества отдельных составляющих. На самом деле называть ее "файловой системой" не вполне правильно. Она имеет уровневую структуру, при этом на высшем уровне располагается устанавливаемый диспетчер файловой системы Installable filesystem manager (IFS), а на низком уровне – набор драйверов портов или драйверов минипортов, которые взаимодействуют с отдельными аппаратными средствами. В пределах той функциональности, что обеспечивают указанные компоненты, система может поддерживать несколько активных файловых систем. Некоторые из них (например FAT) Windows 9х поддерживает непосредственно. Поддержка файловых систем, разработанных не в Microsoft, осуществляется при помощи устанавливаемых модулей, которые поставляются самими фирмами-разработчиками. На рисунке 3.18 показаны все основные компоненты архитектуры файловой системы.

Выбор уровневой управляемой IFS структуры должен был снять проблемы, связанные с использованием прерывания MS-DOS INT 21H как единственного интерфейса для всех действий файловой системы.

На рисунке 3.18 показано весьма незначительное число уровней файловой системы, хотя именно эти компоненты должны присутствовать в стандартной системе.

Всего файловая система поддерживает 32 уровня: от подсистемы ввода-вывода (I/O subsystem – IOS) и далее до аппаратных средств. При инициализации компоненты регистрируют себя в IOS и объявляют уровни, на которых они хотели бы работать. Для того чтобы работать на более чем одном уровне, модуль должен передать IOS различные точки входа – по одной для каждого уровня. Над IOS располагаются файловые системы и устанавливаемый диспетчер файловой системы (IFS manager).

94)      Основные функции наиболее употребительных уровней и компоненты, которые могут в них находиться:

95)     

Рис. 3.18. Уровни архитектуры файловой системы Windows 9х

Диспетчер IFS находится на самом верхнем уровне и представляет собой единственный V×D, обеспечивающий интерфейс между запросами приложения и конкретной файловой системой, к которой обращается это приложение. Диспетчер IFS принимает как динамические обращения к функциям API от приложений Win32, так и обращения к прерыванию INT 21H, генерируемые Win16 или MS-DOS-приложениями. Диспетчер IFS преобразует эти обращения в обращения к следующему уровню – уровню файловой системы.

Работающая на этом уровне VFAT представляет собой работающую в защищенном режиме реализацию FAT файловой системы. VFAT может служить примером драйвера файловой системы (filesystem driver – FSD). Каждый FSD поддерживает определенную организацию файловой системы и обслуживает запросы. Диспетчер IFS – это единственный модуль, который может обращаться к FSD, приложения не могут обращаться к FSD напрямую.

Сам по себе VFAT – 32-разрядный модуль, написанный в виде реентерабельного кода, что позволяет многим задачам параллельно выполнять один и тот же код файловой системы.

CDFS представляет собой реализованную в виде реентерабельного кода для защищенного режима, соответствующую стандарту ISO 9660 файловую систему компакт-дисков. Это еще один пример FSD. В большинстве случаев CDFS заменит резидентную программу MSCDEX, используемую для поддержки компакт-дисков, и таким образом все взаимодействие с приводами компакт-дисков будет проходить в защищенном режиме.

Подсистема ввода-вывода (IOS) – это высший уровень подсистемы блочных устройств. Модуль IOS постоянно находится в памяти и обеспечивает другим компонентам файловой системы разнообразный сервис, включая перенаправление запросов и уведомлений о тайм-аутах.

Драйвер отслеживания томов (Volume Tracking Driver – VTD) занимает следующий после IOS уровень и отвечает за управление сменными устройствами. Обычно такими устройствами являются дисководы для дискет, однако сервисом VTD может пользоваться любое устройство, соответствующее "правилам сменности" Windows 9х. Основная задача VTD заключается в слежении за тем, чтобы в дисководе находился нужный диск или устройство. Если вытащить дискету из дисковода в то время, пока файл еще открыт, именно VTD просигнализирует об ошибке.

Драйвер определенного типа (Type Specific Driver – TSD) управляет всеми устройствами какого-то одного типа, например, жесткими дисками или накопителями на магнитной ленте. TSD проверяет запросы к устройству, которым он управляет и осуществляет преобразование входных параметров из логических в физические. Необходимо обратить внимание на то, что TSD в большей степени относится к устройствам определенного логического типа, например, к сжатым дискам, нежели конкретным аппаратным средствам.

Драйверы, поддерживаемые поставщиками (Vendor Supplied driver – VSD) представляют уровень, на котором работают драйверы, перехватывающие запросы к конкретным блочным устройствам. На этом уровне, например, можно частично изменить поведение существующего драйвера блочного устройства, а не подключать совершенно новый драйвер. Хорошим примером потенциального VSD служит модуль шифрования данных.

Драйвер порта (Port Draiver – PD) управляет конкретным адаптером. На персональном компьютере, оснащенном шиной ISA, будет работать драйвер порта IDE. Он занимается взаимодействием с устройством на самом низком уровне, включая инициализацию адаптера и обслуживание аппаратных прерываний.

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

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

Драйвер минипорта (Miniport Driver) – это модуль, специфичный для SCSI-устройств. Взаимодействуя со SCSI-диспетчером, он делает все то же самое, что и драйверы портов, но только для SCSI-адаптера. Драйверы минипортов Windows 9х строятся в соответствии с теми же правилами, что и драйверы минипортов Windows NT.

Преобразователь (Mopper) защищенного режима – модуль, который позволяет использовать существующие MS-DOS-драйверы в Windows, что очень важно для обеспечения совместимости. Преобразователь защищенного режима маскирует драйверы реального режима для обеспечения большей отдачи от модулей новой файловой системы таким образом, чтобы им не приходилось учитывать разницу в интерфейсе.

Хранение длинных имен

97)      Требования совместимости, которым должна удовлетворять Windows 9х, означают, что невозможно просто изменить существующий формат хранения данных на диске, который применяется в FAT файловой системе.

Формат элемента каталога FAT файловой системы для короткого имени файла представлен на рисунке 3.19.

Рис. 3.19. Формат элемента каталога FAT

98)      Новая VFAT файловая система поддерживает как длинные, так и короткие имена и, если не считать того, что она не использует поле "дата последнего изменения файла", 32-байтный элемент каталога идентичен тому формату, который поддерживают предыдущие версии MS-DOS.

99)      Метод работы с длинными именами файлов строится на использовании байта атрибута элемента каталога для короткого имени файла. Установка младших четырех бит этого байта (значение OFH) задает элементу каталога атрибуты "только для чтения", "скрытый", "системный" и "метка тома" (read only, hidden, system file и volume). Добавление атрибута "метка тома" дает "невозможное" сочетание. Как это ни удивительно, проведенное Microsoft тестирование показало, что ни одна из существующих дисковых утилит не обратила внимания на такую комбинацию бит. В отличие от других, не имеющих смысла комбинаций, заметив которые дисковые утилиты пытаются "исправить" ошибку, эта (OFH) защищает элемент каталога от изменения.

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

Каждый 32-байтный элемент, описывающий длинное имя файла, содержит порядковый номер (seguence number), защитный байт атрибута (protective attribute bute), значение типа (type value) и контрольную сумму (checksum). Порядковый номер помогает Windows 9х узнать о непоследовательном или некорректном изменении структуры каталога.

Разнообразие функций интерфейса прикладного программирования Windows 9х является по меньшей мере всеобъемлющим. Windows 9х API представляет собой подмножество разработанного Microsoft интерфейса Win32, и он обеспечивает совместимость за счет поддержки прикладных Windows-программ и приложений MS-DOS. С появлением Windows 9х Microsoft рекомендует прекратить разработку 16-разрядных приложений и, желая побудить разработчиков сделать такой выбор, делает новые возможности системы Windows 9х доступными только для 32-разрядных приложений. Впрочем, для большинства разработчиков достаточным поводом для такого перехода может служить одна только возможность наконец-то отказаться от использования сегментной адресации памяти. Если добавить к этому те новые возможности, что доступны теперь приложениям Win32, переход к 32-разрядному API становится весьма привлекательным.

Windows поддерживает свои API при помощи трех главных компонентов системы – модулей Kernel, User и GDI. Kernel берет на себя большинство функций операционной системы, таких как выделение памяти, управление процессами и пр.

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

Каждое приложение Windows использует код этих модулей. В Windows 9х модули Kernel, User и GDI присутствуют в системе резидентно в виде 16- и 32-разрядной реализации. Кроме того, много кода используется совместно, как, например, 16- и 32-разрядные воплощения CGI.

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

Если разобрать откомпилированную для Windows программу, то обнаружится набор ссылок на функции Windows API; ссылок, которые необходимы для того, чтобы Windows могла правильно загружать приложения. Так делают все программы Windows. На самом деле модули Kernel, User и GDI – это не что иное, как динамически компонуемые библиотеки Windows (Dynamic Link Library – DLL). Windows интенсивно использует такие библиотеки, а метод, который позволяет приложению обращаться к DLL, называется динамическим связыванием (Dynamic Linking).

У проекта Plug and Play было несколько основных задач, которые должны были решить сама спецификация и любые ее воплощения. Самая главная цель состояла в том, чтобы не только облегчить добавление к системе новых аппаратных средств или изменение конфигурации уже подключенных устройств, но и предельно упростить эти действия. Пользователи изменяют конфигурацию устройств быстрее, чем раньше и не испытывают при этом раздражения, а значит, гораздо меньше переживаний выпадает на долю групп поддержки, в которые обычно звонят пользователи, если у них что-то не получается. У разработчиков аппаратных средств появляется четкий стандарт, которому они могут следовать вместо того, чтобы пытаться самим решать все потенциальные проблемы, связанные с установкой и конфигурированием. В случае если все новые аппаратные средства будут разрабатываться в соответствии со стандартом Plug and Play, становится вполне реальной ситуация, при которой все, что останется сделать для добавления устройства к сис-теме – это подключить его и скопировать на жесткий диск все необходимое программное обеспечение. С существующим в настоящее время программным обеспечением достичь такого уровня простоты очень сложно, поскольку аппаратные средства не соответствуют стандарту Plug and Play. Впрочем, можно сделать очень многое в смысле улучшения программного обеспечения, и стандарт Plug and Play действительно способствует совершенствованию драйверов устройств, которые могут позволить существующим соответствующим ISA аппаратным средствам поддаваться управлению в среде Plug and Play.

Спецификация Plug and Play насчитывает пять целей:

1.   Простота установки и конфигурирования новых устройств.

2.   Единые динамические изменения конфигурации.

3.   Совместимость с уже установленными устройствами.

4.   Независимость от аппаратных средств и операционной системы.

5.   Упрощенность и повышенная гибкость аппаратной реализации.

В пределах подсистемы Plug and Play взаимодействует множество модулей, основные из которых показаны на рисунке 3.20.

Функциональное назначение элементов:

1.Дерево аппаратных средств. Это база данных, в которой содержится информация о текущей конфигурации системы, стро-ится диспетчером конфигурации и хранится в памяти. Каждая вершина дерева называется узлом устройства (device node) и содержит логическое описание либо конкретного устройства, либо шины.

2..INF-файлы – это набор дисковых файлов, содержащих информацию о конкретных типах устройств. Например, в файле SCSI.INF хранится информация обо всех известных SCSI-устройствах. В ходе установки нового устройства, соответствующего Plug and Play, будет использован новый .INF-файл. Обычно такой файл находится на дискете, поставляемой вместе с устройством.

Рис. 3.20. Составляющие подсистемы Plug and Play

3.Реестр. Дерево аппаратных средств, которое описывает устройства, входит в состав реестра Windows 9х как поддерево.

4.События – это набор функций API, используюемых для уведомления об изменениях текущей конфигурации системы. В Windows 9х о событиях сигнализирует система сообщений. В других реализациях о них может сообщать один из компонентов операционной системы.

5.Диспетчер конфигурации. Этот модуль отвечает за построение базы данных, в которой содержится информация о конфигурации компьютера, помещаемой в реестр, и за уведомление драйверов устройств о том, какие ресурсы им выделены. Диспетчер конфигурации при работе системы представляет собой центральный модуль подсистемы Plug and Play.

6.Энумератор (Enumerator). Это новый тип драйвера, взаимодействующий с драйвером устройства и с диспетчером конфигурации. Энумератор обслуживает конкретное устройство (обычно шину), к которому могут подключаться другие устройства. С каждым описанным в дереве аппаратных средств устройством шины связан свой энумератор. Особый энумератор (root enumerator), называемый корневым, входит в состав диспетчера конфигурации. Он помогает настраивать устройства, которые не соответствуют стандарту Plug and Play.

7.Арбитр ресурсов. Этот модуль отвечает за управление выделением конкретных ресурсов и предотвращение конфликтов.

8.Plug and Play BIOS. Новая системная BIOS, которая поддерживает действия Plug and Play. Любое устройство (например, видеоконтроллер) также может иметь свою BIOS, соответствующую стандарту Plug and Play. Кроме того, Plug and Play BIOS выступает в качестве энумератора для материнских плат, и в этом качестве играет важную роль при присоединении к докам портативных систем.

9.Драйверы устройств Plug and Play. Это драйверы защищенного режима, которые отвечают за управление устройствами и, кроме того, участвуют в работе подсистемы Plug and Play.

10.    Интерфейс пользователя – набор стандартных диалоговых окон, служащих для получения информации в тех случаях, когда подсистеме Plug and Play для конфигурирования необходима помощь пользователя. Они дают пользователю возможность ознакомиться с конфигурацией системы, которую строит подсистема Plug and Play.

11.Приложение. С точки зрения стандарта Plug and Play, это написанная для Windows 9х программа, которая способна воспринимать и обрабатывать сообщения системы о смене конфигурации.

Деятельность подсистемы Plug and Play состоит, главным образом, в том, что она от имени различных устройств управляет четырьмя видами ресурсов:

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

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

3.   DMA – список необходимых устройству каналов прямого доступа к памяти и любых альтернативных каналов, которые оно может использовать.

4.   IRO – требования устройства к линии запроса прерываний, альтернативные IRQ, а также сведения о том, может ли устройство использовать IRQ как разделяемый ресурс.

Подсистема Plug and Play включает множество модулей, написанных на Си и Ассемблере. Большинство своих компонентов система загружает динамически. Главным элементом подсистемы Plug and Play является дерево аппаратных средств, описывающее текущую конфигурацию системы.

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

1. Системная BIOS "заглядывает" в энергонезависимое запоминающее устройство (СМ OS) и определяет конфигурацию компьютера. Затем BIOS конфигурирует все устройства, для которых ей удается обнаружить соответствующую информацию; в данном случае речь идет об устройствах материнской платы. При этом BIOS отключает все адаптеры, для которых отсутствует информация о конфигурации.

2. Начинается процесс загрузки. Система по-прежнему работает в реальном режиме. Корневой энумератор диспетчера конфигурации использует поддерево аппаратных средств из реестра Windows для справки о том, какой должна быть конфигурация системы.

3. Корневой энумератор просматривает поддерево реестра в поисках информации об устройствах, не соответствующих стандарту Plug and Play. Обнаружив очередное такое устройство, он создает узел устройства и добавляет его к корню хранящегося в памяти дерева аппаратных средств. Кроме того, корневой энумератор конфигурирует все те устройства, которые не сконфигурировала BIOS.

4. Продолжается загрузка системы в реальном режиме. Системный загрузчик обрабатывает файл SYSTEM.INI и загружает все указанные в нем статические виртуальные драйверы внешних устройств.

5. После этого загружаются остальные энумераторы. Например, BIOS отметила тот факт, что в состав системы входит шина ISA. В реестре указано, какой энумератор следует загрузить для данной шины.

6. Энумератор изучает подключенные к шине устройства и загружает либо статический V×D (если таковой необходим), либо еще один энумератор, если необходимо обследовать дополнительную шину.

7. Теперь в памяти уже находятся все необходимые драйверы реального режима и статические V×D. Ядро операционной системы заканчивает свою собственную инициализацию и переключается в защищенный режим.

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

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

10. Если после всех этих действий останется какое-нибудь неопознанное, не поддерживающее стандарт Plug and Play устройство, Windows начинает процесс его установки, в ходе которого пользователю приходится помогать системе разобраться с конфигурированием. Если необходимости в этом не возникает, система начинает работать.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1.      Богумирский Б. Руководство пользователя ПЭВМ: В 2 ч. – СПб.: Ассоциация AILCO, 1992. - 298 с.

2.      Герасименко В. Защита информации в автоматизированных системах обработки данных: в 2 кн. Книги 1, 2. - М.: Энергоиздат, 1994. - 576 с.

3.      Герасименко В., Малюк А. Основы защиты информации. - М.: МОПО, МИФИ, 1997. - 537 с.

4.      Доктрина информационной безопасности Российской Федерации от 9 сентября 2000 г. № Пр-1895.

5.      Жигарев А. Основы компьютерной грамоты. - Л.: Машиностроение, 1988. - 285 с.

6.      Информатика: Учебник / Под ред. проф Макаровой Н.. - М.: Финансы и статистика, 1997. - 768 с.

7.      Каранчук В. и др. Основы применения ЭВМ. - М.: Радио и связь, 1988. - 276 с.

8.      Копылов В. Информационное право: Уч. пособие. - М.: Юрист, 1997. - 472 с.

9.      Медник С. Защита ЭВМ. - М.: Мир, 1982. - 263 с.

10.    Мельников В. Защита информации в компьютерных системах. - М.: Финансы и статистика, 1997. - 364 с.

11.    СТ ИСО 2382/1–84.

12.    Острейковский В. Информатика: Учебник для вузов. - М.: Высш. шк., 2000. - 508 с.

13.    Петров В., Пискарев А., Шеин А. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах: Уч. пособие. Изд. 2-е, испр. и доп. - М.: МИФИ, 1995. - 84 с.

14.       Романец Ю.В и др. Защита информации в компьютерных системах и сетях / Под ред. В.Ф. Шаньгина. – М.: Радио и связь, 1999. - 328 с.

15.    Спесивцев А., Вегнер В., Крутяков А., Серегин В., Сидоров В. Защита информации в персональных ЭВМ. - М.: Радио и связь, МП "Веста", 1992. - 192 с.

16.    Соболева Т. Тайнопись в истории России. - М.: Международные отношения, 1994. – 382 с.

17.    Теория и практика обеспечения информационной безопасности/ Под ред. Зегжды П.. - М.: Издательство Агентства "Яхтсмен", 1996. - 192 с.

18.    Федеральный Закон Российской Федерации от 20 февраля 1995г. № 24-ФЗ (с изменениями от 10 января 2003 г.) "Об информации, информатизации и защите информации".

19.    Хоффман Л. Современные методы защиты информации: Пер. с англ. / Под ред. Герасименко В. А. - М.: Советское радио, 1980. - 263 с.

20.    Цигичко В., Смолян Г. Оценка систем информационной безопасности. - М.: ИСА РАН, 1995. – 43 с.

21.    Черешкин Д., Аносов В. и др. Концепция информационной безопасности Российской Федерации / Под ред. Черешкина Д. и Вирковского В.. – М.: ИСА РАН, 1994. – 44 с.

22.    Шураков В. Обеспечение сохранности информации в системах обработки данных. - М.: Финансы и статистика, 1985. - 224 с.

Похожие работы

Базовые понятия и определения информатики

Скачать

22013

0

0

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

Программное обеспечение

Скачать

21932

0

4

... – набор утилит и некоторые инструментальные программы (пользовательский интерфейс). К третьему уровню относятся все остальные программы. Программы второго и третьего уровней хранятся в файлах. Программное обеспечение первого уровня является машинно-зависимым [computer-independent]. То есть для каждого микропроцессора или семейства ЭВМ набор данных программ уникален. Операционная система имеет ...

Программное обеспечение для ЭВМ

Скачать

40481

2

3

... Вы сможете работать на своем компьютере. От выбора ОС зависят также производительность вашей работы, степень защиты Ваших данных, необходимые аппаратные средства и т.д. [9] 5. Персональная ЭВМ: развернутая структура; структура программного обеспечения; выбор ПЭВМ (если возможно, то по прайс-листу некоторой фирмы). Развернутая структура (тонкие линии показывают управляющие связи, толстые – ...

Программное обеспечение сетей ЭВМ

Скачать

59285

1

8

... » (Zero Administration Initiative), которая будет реализована во всех следующих версиях Windows. SMS- сервер управления системами У SMS две задачи — централизовать управление сетью и уп­ростить распространение программного обеспечения и его модернизацию на клиентских системах. SMS подойдет и ма­лой, и большой сети — это инструмент управления сетью на базе Windows NT, эффективно использующий ...