3. Сообщения и многозадачность
3.1 Процессы и потоки
Многозадачность в Windows обеспечивается посредством выделения квантов времени запущенным в системе потокам. Потоки принадлежат процессам. Одному процессу могут принадлежать несколько потоков. Они обладают правом доступа к памяти и другим ресурсам, принадлежащим этому процессу. Поэтому между потоками одного процесса легче организовать обмен данными и взаимодействие, чем между потоками разных процессов.
В начале работы каждый процесс обладает единственным первичным потоком. Информация о первичном потоке передается ОС в виде адреса функции. Поэтому все Windows-приложения содержат вызываемую при запуске функцию WinMain(), адрес которой и передается в качестве адреса первичного потока. Первичный поток может создать дополнительные потоки, и т.д. Потоки одного процесса имеют доступ ко всем его объектам. Такие потоки отличаются друг от друга лишь точкой входа и локальными переменными, расположенными в адресном пространстве процесса.
Потоки, принадлежащие разным процессам, не имеют между собой ничего общего, однако они могут получить доступ к общим ресурсам и памяти, используя механизмы межпроцессного взаимодействия.
В немногопоточных ОС (например, в большинстве версий UNIX) наименьшая исполняемая системная единица называется задачей или процессом. Алгоритм диспетчеризации задач в ОС переключает эти задачи, т.о., достигается многозадачность в среде двух и более процессов. Если приложению требуется выполнить одновременно несколько действий, то это приложение необходимо разбить на несколько задач (например, с помощью системного вызова fork в UNIX). У этого подхода есть несколько серьезных недостатков: 1) задачи являются ограниченным ресурсом (большинство ОС могут управлять лишь несколькими сотнями одновременно выполняющихся задач); 2) запуск новой задачи требует много времени и системных ресурсов; 3) новая задача не имеет доступа к памяти родительского процесса.
В ОС с многопоточной многозадачностью наименьшей исполняемой единицей является поток, а не процесс. Процесс может состоять из одного или нескольких потоков. Создание нового потока требует немного системных ресурсов; потоки в одном процессе имеют доступ к одному адресному пространству; переключение между потоками одного процесса требует небольших системных затрат.
3.2 Процессы и сообщения
В Windows окна принадлежат потокам. У каждого потока есть собственная очередь сообщений. В нее ОС помещает сообщения для окон данного потока. Очереди разных потоков независимы. Т.о. Windows обеспечивает каждому потоку среду, в которой он может считать себя единственным и самостоятельно управлять фокусом ввода с клавиатуры, активизировать окна, захватывать мышь и т.д.
Поток Windows не обязательно должен владеть окнами и содержать цикл обработки сообщений. Например, рассмотрим некоторое математическое приложение, в котором надо выполнить вычисления с элементами большого двумерного массива (матрицы). Проще всего сделать это с помощью цикла. В Win32 этот цикл можно поместить в отдельный поток, параллельно с которым первичный поток приложения продолжит обработку поступающих сообщений. Поток для вычислений не имеет окон, очереди сообщений и цикла обработки сообщений. При таком подходе приложение не будет выглядеть "зависшим" в течение выполнения вычислений.
Хотя на уровне ОС потоки не делятся на типы, но в библиотеке классов MFC на Си++ они называются и оформляются по разному: рабочие потоки (без окон и обработки сообщений) и потоки пользовательского интерфейса.
4. Вызовы функций Windows API
Приложение обращается к Windows при помощи так называемых системных вызовов. Они составляют интерфейс прикладного программирования (Application Programming Interfaces, API). Для программистов вместо термина "вызов" м.б. удобнее использовать термин "функция". Функции API располагаются в системных динамических библиотеках (DLL). Существуют функции для выделения памяти, управления процессами, окнами, файлами, для рисования графических примитивов и др.
Обращение к функциям API из большинства сред разработки на Си++ осуществляется очень просто, т.к. API специально спроектирован для использования в среде Си/Си++. В текст программы надо включить заголовочный файл, содержащий описания функций API (windows.h) и в процессе компоновки использовать необходимые библиотеки (Visual C++ обычно подключает их автоматически). После этого в текст программы можно включать любые обращения к API.
"Базовый" набор системных вызовов Windows можно разделить на три группы:
функции модуля KERNEL.DLL (управление процессами, потоками, ресурсами, файлами и памятью);
функции модуля USER.DLL (работа с пользовательским интерфейсом, например, с окнами, элементами управления, диалогами и сообщениями);
функции модуля GDI.DLL (аппаратно-независимый графический вывод).
Windows содержит большое количество вспомогательных API. Есть отдельные API для работы с электронной почтой (MAPI), модемами (TAPI), базами данных (ODBC). Степень интеграции этих API в системное ядро различна. Например, хотя интерфейс OLE и реализован в виде набора системных динамических библиотек, но рассматривается как часть "ядра" Windows. Остальные API, например, WinSock, можно рассматривать как дополнительные.
Различие между тем, что следует считать "ядром" Windows, а что – дополнительными модулями, довольно произвольно. C точки зрения приложения практически нет разницы между функцией API из ядра, например, из модуля Kernel, и функцией, реализованной в одной из библиотек DLL.
4.1 Функции ядра (модуль Kernel)
Функции ядра обычно делятся на категории: управление файлами, памятью, процессами, потоками и ресурсами. В эти категории попадают далеко не все, а только наиболее часто используемые функции модуля Kernel.
Для доступа к файлам в Windows можно пользоваться обычными потоками Си++ или функциями библиотеки Си. Но функции модуля Kernel имеют больше возможностей. Эти функции работают с файлами как с файловыми объектами. Например, они позволяют создавать файлы, отображаемые в памяти.
В отличие файлового доступа, библиотечных возможностей Си (функция malloc()) или Си++ (оператор new) для большинства приложений оказывается вполне достаточно. В Win32 эти вызовы автоматически преобразуются в соответствующие вызовы Win32 API. Приложения со специфическими требованиями к управлению памятью могут пользоваться более сложными функциями, например, для работы с виртуальной памятью (например, чтобы выделить блок адресного пространства размером несколько сотен мегабайт, но не передавать под него физическую память).
Один из важнейших аспектов в управлении потоками – синхронизация. Т.к. Windows является системой с вытесняющей многозадачностью, то потоки не могут получить никаких сведений о состоянии выполнения других потоков. Чтобы гарантировать, что несколько потоков всегда выполняются в заданном порядке, например, по очереди, и чтобы избежать ситуации блокировки (когда два или более потоков приостанавливаются навсегда), требуется применять один из механизмов синхронизации. В Win32 это делается с помощью объектов синхронизации, которыми потоки пользуются, чтобы проинформировать другие потоки о своем состоянии, для защиты фрагментов кода от повторного вхождения, или для получения информации о других потоках.
В Win32 многие ресурсы ядра (не следует путать их с ресурсами пользовательского интерфейса) представляются в виде объектов ядра. Примерами являются файлы, потоки, процессы, объекты синхронизации. Для обращения к объекту применяются уникальные идентификаторы – дескрипторы (описатели). Некоторые функции предназначены для выполнения действий, общих для всех объектов (например, открытие или закрытие), а другие – для манипуляций с объектами специфического типа.
Модуль Kernel обеспечивает функции для управления ресурсами пользовательского интерфейса. Они включают в себя пиктограммы, курсоры, шаблоны диалогов, строковые ресурсы, битовые карты и др. Функции Kernel не учитывают назначение ресурса. Они обеспечивают выделение памяти для ресурсов, загрузку ресурсов с диска (обычно из исполняемого файла приложения), удаление ресурсов из памяти.
4.2 Функции пользовательского интерфейса (модуль User)
Функции модуля User предназначены для управления компонентами пользовательского интерфейса: окнами, диалогами, меню, курсорами, элементами управления, буфером обмена и др. Эти ресурсы называются объектами модуля User.
В модуле Kernel есть функции для выделения памяти, управления памятью и некоторые другие, необходимые для функционирования окон. Модуль GDI обеспечивает рисование графических примитивов. Но именно модуль User, используя возможности двух других модулей, реализует высокоуровневые компоненты пользовательского интерфейса, например, окно.
Функции управления окнами позволяют изменять размеры окна, его местоположение на экране и внешний вид, заменять оконную процедуру, разрешать и запрещать работу окна, получать информацию о свойствах окна. Эти функции также используются для работы с элементами управления, такими, как кнопки, полосы прокрутки или строки ввода. В модуле User есть функции для управления дочерними окнами программ с многодокументным интерфейсом (MDI).
Перечислим еще несколько групп функций модуля User:
работа с меню (создание, отображение, изменение строки меню и выпадающих меню);
управление формой и положением указателя мыши и текстового курсора;
работа с буфером обмена;
управление сообщениями и очередью сообщений потока.
Приложения могут использовать функции User для проверки содержимого очередей сообщений, для получения и обработки сообщений, а также для посылки сообщений каким-либо окнам. Сообщения любому окну можно посылать либо синхронно (функция SendMessage), либо асинхронно (PostMessage). При асинхронной посылке сообщение просто помещается в очередь сообщений потока, который владеет окном-адресатом. В отличие от него, синхронное сообщение передается непосредственно в оконную процедуру окна-адресата. Функция SendMessage возвращает управление только после обработки сообщения окном-адресатом. Этот позволяет приложению-передатчику получить результат обработки перед продолжением выполнения.
4.3 Функции графического вывода (модуль GDI)
Функции модуля GDI (Graphics Device Interface, интерфейс графических устройств) обеспечивают рисование графических примитивов аппаратно-независимым образом. Для абстракции от конкретного устройства применяется понятие контекст устройства. Это системный объект, обеспечивающий интерфейс с конкретным графическим устройством. С помощью контекста можно выполнять графический вывод на устройство или получать информацию о его свойствах (имя устройства, разрешение, цветовые возможности и др.).
При рисовании примитивов (отрезков, прямоугольников, эллипсов, текста и т.п.) функциям рисования передается дескриптор контекста устройства. Контекст устройства преобразует общие, независимые от устройства, графические команды в набор команд конкретного устройства. Например, когда приложение вызывает из GDI функцию Ellipse, то сначала контекст устройства определяет, какой драйвер будет выполнять это действие. Затем драйвер устройства может передать вызов аппаратному ускорителю (если он есть в видеоадаптере) или нарисовать эллипс по точкам.
Контексты устройств GDI представляют широкий спектр устройств. Типичными контекстами являются дисплейный контекст устройства (для выполнения вывода непосредственно на экран компьютера), контекст устройства в памяти (для рисования поверх изображения, хранящегося в оперативной памяти), и принтерный контекст устройства (при выводе в этот контекст вызовы приложения в конечном счете преобразуются в управляющие коды принтера и посылаются на принтер).
Рисование в контексте устройства обычно производится в логических координатах. Эти координаты описывают примитивы посредством аппаратно-независимых физических единиц. Например, при задании прямоугольника можно указать его размеры в сантиметрах. GDI автоматически выполняет преобразование логических координат в физические координаты устройства. В качестве параметров преобразования приложение может задать начало координат и размер области вывода в логических и физических координатах. От положения начала координат в обеих системах зависит горизонтальное и вертикальное смещение примитивов в области вывода. Размер области вывода определяет ориентацию и масштаб примитивов после преобразования.
При рисовании примитивов часто указываются их свойства: цвет, толщина и стиль линии и т.п. Для этого служат объекты GDI: перья, кисти, шрифты, растровые изображения и палитры. Их можно создавать и выбирать в контексте устройства для того, чтобы рисуемые впоследствии примитивы выглядели нужным образом.
Кроме рисования графических примитивов, часто используются функции GDI для бит-блиттинга, предназначенные для быстрого копирования растровых изображений. В некоторых приложениях их скорости недостаточно, т.к. при рисовании эти функции используют контекст устройства в качестве посредника между приложением и устройством. Поэтому для непосредственного обращения к видеосистеме был разработан менее безопасный, но существенно более быстрый набор функций для манипуляций с растровыми изображениями – DirectDraw API.
Модуль GDI обеспечивает работу с регионами (структурами, описывающими экранные области, возможно, непрямоугольные) и выполняет отсечение (clipping). Отсечение – это очень важная операция для среды Windows, т.к. она позволяет приложениям рисовать на экране, не отслеживая границ области рисования (например, границы клиентской области окна). Отсечение применяется для корректного отображения на экране перекрывающихся окон.
4.4 Дополнительные API
Возможности Windows не исчерпываются набором функций, содержащихся в трех модулях "ядра". Существует также большое количество других динамических библиотек с дополнительными API, например:
Стандартные элементы управления. Эти функции позволяют работать с элементами управления, появившимися в Windows 95.
Стандартные диалоговые окна. Приложение может пользоваться стандартными окнами для открытия файла для чтения или записи, для выбора цвета из цветовой палитры, для выбора шрифта из набора установленных шрифтов, и некоторыми др. Эти диалоги можно использовать в стандартном виде или модифицировать их поведение путем замены оконных процедур.
MAPI служит стандартным интерфейсом для доступа к различным программам электронной почты и электронных сообщений.
DirectX API. Для некоторых приложений (в особенности, игр) опосредованный доступ к аппаратным устройствам через драйверы Windows оказывается неэффективным. Поэтому Microsoft разработала набор технологий под общим названием DirectX, который ускоряет доступ к аппаратуре. В набор библиотек DirectX входит библиотека DirectDraw для экранных операций, DirectInput для чтения информации с устройств ввода, DirectSound для работы со звуком и Direct3D для построения трехмерных сцен.
ActiveX, COM и OLE. Эти технологии предназначены для создания объектов, распределенных между приложениями. Они включают в себя создание контейнеров и серверов OLE, реализующих вставку объектов OLE в документы приложений-контейнеров (например, как редактор формул в MS Word), автоматизацию OLE, интерфейс "перетащи и оставь" и элементы управления ActiveX. В настоящее время Microsoft использует ActiveX в качестве основного механизма взаимодействия прикладных программ с системными службами Windows.
TAPI предоставляет доступ к телефонному оборудованию. Это аппаратно-независимый интерфейс для работы с модемами, факс-модемами, аппаратурой голосовой телефонии.
В Windows есть отдельные API для работы с сетями, например, WinSock (библиотека сокетов Windows), RAS (Remote Access Service, сервис удаленного доступа) и RPC (библиотека вызова удаленных процедур).
При программировании на Си с использованием API исходный текст программ получается довольно громоздким. Программирование существенно упрощается при использовании библиотек классов вроде MFC и языка Си++. Но еще одно изменение стиля программирования происходит на уровне API. В прошлом, когда компания Microsoft включала в Windows новую возможность, она также расширяла описание интерфейса API – набора системных вызовов. Сейчас многие новые механизмы Windows (например, DirectX) не поддерживают традиционного API. Вместо этого они используют технологию ActiveX. Термином ActiveX теперь принято обозначать последние версии стандартов, которые ранее назывались OLE и COM.
4.5 Соглашение о кодах ошибок
Большинство функций Windows API применяют единый способ возврата ошибок. Когда происходит ошибка, эти функции записывают ее код в специальную переменную потока. Приложение может получить значение этой переменной с помощью функции GetLastError. 32-разрядные значения кодов ошибок определены в заголовочном файле winerror.h и в заголовочных файлах дополнительных API.
Функции приложения также могут записывать собственные коды ошибок в эту переменную с помощью функции SetLastError. Внутренние ошибки приложения должны иметь коды с установленным 29-м битом. Этот диапазон кодов специально зарезервирован для использования приложениями в собственных целях.
|
