Конспект лекций по дисциплине «Операционные системы и среды»

Вид материала

Конспект

Содержание 3.4.Подсистема Win32 32-разрядный API

Подобный материал:

• Конспект лекций по дисциплине " Операционные системы", 1459.26kb.
• Ые системы", "Операционные системы, среды и оболочки" и "Операционные системы и системное, 1294.27kb.
• Рабочая программа по учебной дисциплине Операционные системы, среды и оболочки наименование, 623.3kb.
• В. Ф. Панин Конспект лекций по учебной дисциплине "Теоретические основы защиты окружающей, 1559.17kb.
• Программа предназначена для изучения учебного курса по дисциплине "Операционные системы,, 53.62kb.
• Методические указания для выполнения Курсовой работы по дисциплине «Операционные системы», 72.86kb.
• Программа по дисциплине «Технологии программирования и операционные системы», 42.87kb.
• Вопросы к экзамену по дисциплине «Операционные системы и среды», 34.81kb.
• Экзаменационные билеты по дисциплине «операционные системы и среды», 429.29kb.
• Конспект лекций по дисциплине «Маркетинг», 487.79kb.

3.4.Подсистема Win32

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

8. 32-разрядный API

Microsoft затратила много энергии и ресурсов, чтобы Windows стала выдающей­ся средой разработки приложений. В 1990 году Стив Балмер (Steve Ballmer), тог­дашний старший вице-президент подразделения систем Microsoft, стал провоз­глашать свои любимые новые лозунги для всех, кто мог его слышать: "Windows, Windows, Windows!" и "Windows Everywhere!"⁶ ("Windows повсюду!"). Хотя его бьющий через край юмор всегда вызывал смех на собраниях фирмы, второй лозунг имел некоторый особый подтекст. Как говорилось в гл. 1, в Microsoft ви­дели необходимость создания ОС старшей модели, которая могла бы использо­вать новейшие достижения технологии аппаратного обеспечения. API Windows 3.0, который работал поверх MS-DOS, был ограничен в этом отношении. Чтобы стать продвинутой ОС, этот API должен был эволюционировать.

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

Несмотря на эти амбициозные цели, главным приоритетом Microsoft при развитии API Windows было: сделать новый API совместимым с API 16-разряд­ной Windows по именам функций, семантике и используемым типам данных везде, где только можно. Все функции API Win32 должны были обеспечить об­ратную совместимость для переноса существующих 16-разрядных приложений для Windows под Windows 2000.

Твердо помня об этой задаче, разработчики Windows и Windows 2000 опре­делили следующие дополнительные цели проекта нового Windows API:

• Изменить API так, чтобы использовать 32-разрядную линейную мо­дель памяти. API не должен более полагаться на сегментную модель, установленную процессорами семейства Intel x86, чтобы освободить приложения от ограничения в б4 Кбайт на размеры кода и данных и позволить им достичь максимальной переносимости на RISC и другие не сегментные платформы.
  
• Сделать этот API одинаковым и под MS-DOS, и под Windows 2000, чтобы разработчики могли запускать свои приложения на широком диапазо­не машин, от младших моделей до самых старших.
  
• Сделать среду приложений защищенной путем введения системы виртуальной памяти, где каждое приложение работает в отдельном
  
• адресном пространстве, и предоставления в составе API механизмов защиты объектов.
  
• Добавить в API средства ОС высокого уровня, такие как многопоточные процессы, средства ввода-вывода, синхронизация, управление памятью и поддержка национальных языков (интернационализация).
  

Для создания нового API Win32 разработчики Microsoft просматривали API Windows 3.0 и модифицировали его так, чтобы он удовлетворял перечис­ленным выше задачам. Затем Microsoft привлекла "подопытных кроликов" как из самой компании, так и извне, чтобы добиться большей простоты в исполь­зовании и переносимости.

Подсистема Win32 обеспечивает в Windows 2000 доступ приложений к API Win32. Так как система виртуальной памяти исполнительной системы NT ба­зируется на использовании 32-разрядного линейного адресного пространства, отдельного для каждого процесса, то приложения Win32 API имеют меньшие накладные расходы, чем приложения для API 16-разрядной Windows или MS-DOS. В связи с этим Microsoft поощряет программистов использовать в новых приложениях Win32 API, который доступен как в Windows 2000, так и в MS-DOS.

Функции API Win32 имеют ряд типовых отличий от аналогичных функций API Windows 3.0. Самое большое отличие состоит в том, что некоторые структу­ры данных, такие как описатели, указатели и координаты для рисования, расши­рены с 16-битного до 32-битного представления и более не используют сег­ментную модель памяти. В тех случаях, когда параметры большей длины могут повлиять на существующие приложения, API Win32 вводит новую функцию, с возможностями, аналогичными возможностям существующей функции — так, чтобы не ломать старых приложений и чтобы они могли быть со временем пере­несены под Windows 2000. Например, формат целочисленных параметров и ука­зателей был изменен с формата "сегмент:смещение" на линейный, 32-битный формат, а координаты функций рисования имеют длину 32 бита, а не 1б.

Полностью новая группа функций API Win32 предоставляет продвинутые средства ОС, такие как ввод-вывод, синхронизация, управление памятью, защи­та и потоки. Хотя они и разрабатывались так, чтобы сохранить дух старого API Windows, новые функции более или менее непосредственно экспортируют ба­зовые сервисы NT, делая ее мощь доступной программистам Win32. И хотя мно­гие из средств Win32 напрямую заимствованы из исполнительной системы NT, они также были продублированы для MS-DOS. Однако, некоторые продвинутые средства, например, асинхронный ввод-вывод, доступны только под Windows 2000.

Еще одно новое средство, предоставляемое API Win32 — защита — прони­зывает весь интерфейс. Защита Win32 была реализована Джимом Андерсоном (Jim Anderson), разработчиком, чей обширный опыт включал, помимо всего про­чего, создание компьютеров контроля качества для заводов по производству дви­гателей компании Ford Motor. Средства защиты, разработанные им для подсис­темы Win32, являются расширениями (пользовательского режима) для средств защиты, встроенных Джимом Келли (Jim Kelly), Робертом Рейчелом (Robert Reichel) и другими в объектную архитектуру исполнительной системы NT

Подсистема Win32 реализует защиту объектов так же, как это делает ис­полнительная система NT; она защищает совместно используемые объекты Windows от несанкционированного доступа, помещая в них дескрипторы за­щиты NT. Как и в исполнительной системе NT, когда приложение в первый раз будет выдан первый запрос на рисование. Кэширование атрибутов (attribute cashing), как называется этот метод буферизации, минимизирует количество переключении контекста и объем времени, затраченный на передачу сообще­ний между клиентом и сервером.

Для уменьшения числа переключении контекста между клиентом и серве­ром GDI использует аналогичный способ оптимизации, пакетирование (batching). Пакетирование — это метод, при использовании которого, например, DLL GDI сохраняет несколько вызовов функций в очереди и посылает их на сервер од­ним сообщением, когда очередь переполняется или когда пользователь выпол­няет ввод. При получении такого сообщения сервер Win32 последовательно выполняет все функции, прежде чем управление возвращается клиенту. Прежде чем использовать эту технику, разработчики GDI провели тесты и проверили, не будет ли вывод на экран прерывистым или неравномерным. Тесты показали, что вызовы функций посылаются серверу достаточно часто, и вывод на экран про­ходит плавно и ровно.

Авторам прикладных программ следует иметь в виду эти методы оптими­зации производительности при создании новых многопоточных приложений. Если два потока работают вместе, то их исполнение должно быть синхронизи­ровано, чтобы гарантировать выполнение действий в надлежащем порядке. На­пример, нужно учитывать, что результат не появится на экране сразу же после вызова потоком функции API. Вызов функции может сохранен в буфере потока, ожидая своего вывода на экран. GDI предоставляет функцию GdiFlush(), при помощи которой поток может осуществить принудительную посылку кэшированных вызовов функций на сервер Win32.

Другим результатом использования модели клиент-сервер является то, что приложения, которые постоянно изменяют и перерисовывают большие бито­вые поля, могут работать медленно, в сравнении с прорисовкой аппаратно-независимых образов с использованием вызовов GDI. Так как каждый объект или битовый образ являются локальными для клиентского приложения, они должны пересылаться в составе сообщения на сервер при всякой перерисовке экрана. Для обеспечения оптимальной производительности приложениям следует либо перерисовывать, по возможности, только измененные фрагменты битового об­раза, либо рисовать при помощи функций GDI, что позволяет реализовывать преимущества методов кэширования и пакетирования. Новый Win32 GDI API предоставляет более полный, чем GDI API 16-разрядной Windows, набор средств рисования, необходимый сложным приложениям.