Messages and Multitasking

In Windows 3.1, the message loop had another important role in the interaction between the application and the operating system: it enabled the application to yield control. As Windows 3.1 is not a preemptive multitasking operating system, it does not wrestle away control of the processor from an uncooperative application. Proper functioning of the system depended on the cooperative behavior of applications; namely, that they called specific message processing functions frequently. This behavior is still required of applications that are intended to run under Windows 3.1 using Win32s.

Message Queues

This section starts with the simple and moves to the more complex. First, I describe the workings of the 16-bit Windows messaging and task scheduling architecture.

In 16-bit Windows, the operating system maintains a single message queue. Messages that are generated by various operating system events--such as a keyboard or mouse interrupt--are deposited into this message queue. When an application makes an attempt to retrieve the next message in the queue through the GetMessage or PeekMessage function, the operating system may perform a context switch and activate another application for which messages are waiting in the queue. The message at the top of the queue is then retrieved and returned to the active application via an MSG structure.

If an application fails to make a call to GetMessage, PeekMessage, or Yield (which enables an application to relinquish control without checking the message queue), it effectively hangs the system. Messages keep accumulating in the message queue; as the queue is of a fixed size, eventually it overflows. Windows responds to this by generating a nasty beep every time a new message is received that cannot be placed into the queue; the result is a very ill system that is beeping continuously even at the slightest mouse movement.

In Win32 (that is, both in Windows NT and Windows 95) the message queue mechanism is much more sophisticated. In these preemptive operating systems, the orderly cooperation of competing tasks or threads is no longer guaranteed. Two or more threads can quite possibly attempt to access the message queue at the same time; furthermore, as task switching is no longer dependent on the next available message in the queue, there are no guarantees that a task would retrieve only the messages addressed to it. This is just one of a number of reasons why the single message queue of 16-bit Windows has been separated into individual message queues for each and every thread in the system.

Операционные системы Обзор

32-разрядная версия Visual C + + может быть использована для разработки программ для трех платформ Win32: Windows NT (на нескольких процессорах), Windows 95, и Win32s.

Windows NT является Microsoft’s высокого класса портативным сервером операционных систем. Это полнофункциональная 32-разрядная многопоточная операционная система с интегрированной графической средой и с расширенными возможности сервера. Её разработка была направлена ​​на максимальную портативность, стабильность и безопасность. Хотя её совместимость с хорошим поведением приложений MS-DOS и Windows 3.1 удивительно хороша, она изначально отстает на 100 процентов от замененной для вашей старой MS-DOS системы, и если вы хотите выполнить сложную игровую программу, вам, возможно, придется перезагрузиться к старой доброй командной строке DOS. (Будет ли DOOM работать под управлением Windows NT? Не спрашивайте меня, я еще не пробовал.)

Windows 3.1, конечно же, вездесущая графическая среда находящаяся, использующаяся или не использующаяся, в каталоге практически на каждом ПК в настоящее время. Хотя это доставляет неудобства некоторым операционным системам, это существенная графическая среда, находящаяся на верхней части MS-DOS, и не требующая его замены. Из-за ограничений в обеих архитектурах DOS и 16-битной Windows 3.1,комбинации DOS-Windows систем внутренне нестабильны, склонны к сбоям, и подвергаются жестокой оптимизации приложений. Подсистема Win32s еще один слой поверх Windows 3.1; она реализует подмножество Win32 системных вызовов, которые позволяют запустить многие простые 32-разрядные приложения (или сложные, которые были написаны в совместимости с Win32s).

Новая операционная система от Microsoft, Windows 95, предлагает лучшее из обоих миров. В отличие от Windows NT, Windows 95 была написана с обратной совместимостью, как одним из основных критериев дизайна. Несмотря на это и тот факт, что Windows 95 унаследовала значительную часть старого кода из Windows 3.1, она имеет на удивление мало недостатков. Её стабильность сравнима с Windows NT, ее производительность превосходит как Windows NT, так и Windows 3.1, и требования к аппаратным ресурсам минимальны, в сравнении с Windows 3.1.

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

Окна и сообщения

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

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

Приложения, Темы для Windows

Какая связь между приложениями и окнами? Типичное применение Win32 состоит из одного или более потоков, которые в основном имеют параллельные пути исполнения. Задумка таких потоков как многозадачность в рамках одного приложения, например, один поток в текстовый редактор может быть обрабатываться пользовательским вводом, а другой занят отправкой документа на печать.

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

Есть много типов окон в Windows – это не случайно! Наиболее очевидные, конечно, большие прямоугольные области, которые мы обычно ассоциируем с приложением. Также очевидно, что диалоговое окно единственное в своем роде, оно может быть перемещено куда-либо, изменено иногда размером, развернуто, или сведено к минимуму, как главное окно приложения. Менее очевидно, что многие элементы отображаются в главном окне или диалогах окна самостоятельно. Каждая кнопка, поле ввода, полоса прокрутки, список, значок, даже сам фон экрана рассматриваются как окно в операционной системе.

Весьма показательное упражнение, если вы еще не сделали этого раньше, тратить некоторое время с приложением Spy + +, которое поставляется вместе с Visual C + +. Используйте свою Найти Window команду из меню Spy и перетащите инструмент поиска по экрану, чтобы узнать, как даже казалось бы, простым приложением окна может быть много компонентов окна.

Окно классов.

Основные параметры поведения окна определяются его классом окна. Класс окна несет информацию о первоначальном виде окна, об иконках по умолчанию, курсорах, а также о ресурсах меню, связанного с окном, и, возможно, самое главное, адресе функции, называемой оконной процедурой. Когда приложение обрабатывает сообщения, оно, как правило, делает это с помощью вызова функции Windows, «Отправка сообщений», для каждого полученного сообщения; «Отправка сообщений», в свою очередь, требует соответствующей оконной процедуре проверку класса окна для сообщения. Это окно - процедура, которая на самом деле процессы сообщения, отправленные на это окно.

Есть много стандартных классов окон самостоятельно предоставляемые в Windows. Например, эти системы глобальных классов реализуют функциональность стандартных элементов управления. Любое приложение может использовать эти классы для своих окон, например, любое приложение может выполнять редактирование элементов управления с помощью окна класса редактирования.

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

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

ПРИМЕЧАНИЕ: Глобальное создание подклассов ведет себя иначе в Win32 и в 16-битных Windows (Win32s). В случае с Win32, это влияет только окна под контролем приложений создающих подклассы, а в 16-битной Windows, эффект глобальный, влияющий на окна каждого приложения.

Создание суперклассов создает новый класс на основе существующего класса, сохраняя свою оконную процедуру. Для суперкласса классов окна, приложение получает информацию класса с помощью функции «получить информацию о классе», изменяет полученную структуру WNDCLASS, таким образом, и использует измененную структуру при вызове «класса регистров». Через «Получить информацию о классе», приложение также получает адрес оригинальной процедуры окна, которые она должна сохранить; сообщения, что новая процедура окна – это не процесс, должны быть переданы этой функции.

Хотя терминология напоминает объектно-ориентированную терминологию, понятие класса окна, не следует путать с понятиями C + + (или, в частности, концепции библиотеки MFC). Концепция окна классов предшествует использованию объектно-ориентированных языков в Windows на несколько лет.

Типы сообщений.

Сообщения приходят во многих разновидностях, представляющих события на самых разных уровнях. Опять же, инструмент Spy + + поможет вам оценить сложный набор сообщений направленных в каждом окне для процесса. Используйте инструмент Spy + +, чтобы выбрать несколько простых элементов, таких как диалоговое окно, чтобы подглядывать, а потом смотреть бесконечный каскад сообщений потоковым путем в Spy + + окнах, и, при перемещении указателя мыши на кнопку в диалоговом окне, щелкните по нему. Таблица 7.1 показывает список сообщений, которые появляются, как «я отклонить Слово для Windows "О"», появляющееся при щелчке на кнопку ОК.

Таблица 7.1: Сообщения, отправленные на Слово для Windows "О" диалог, когда пользователь нажимает кнопку ОК. Символьный идентификатор Описание WM_LBUTTONDOWN левая кнопка мыши была нажата. WM_PAINT кнопку ОК перекрасить, как будет нажата. WM_LBUTTONUP левая кнопка мыши, была освобождена. WM_PAINT кнопку ОК перекрасить, как он будет выпущен. WM_WINDOWPOSCHANGING позиция окна, вот-вот изменится. WM_WINDOWPOSCHANGED позиция окна только что изменилась. WM_NCACTIVATE область заголовка окна были активированы. WM_ACTIVATE клиентская область окна был активирован. WM_WINDOWPOSCHANGING позиция окна, вот-вот изменится. WM_KILLFOCUS Окно собирается терять фокус. WM_DESTROY окно разрушается. WM_NCDESTROY области заголовка окно разрушается.

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

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

Listing 7.1. The MSG structure.

typedef struct tagMSG {

HWND hwnd;

UINT message;

WPARAM wParam;

LPARAM lParam;

DWORD time;

POINT pt;

} MSG;

Первый элемент этой структуры, HWND, однозначно идентифицирует окно в котором это сообщение было отправлено. Каждое окно в Windows, имеет такой идентификатор.

Следующий элемент определяет само сообщение. Этот элемент может иметь сотни различных значений, что указывает на один из многих сотен (в буквальном смысле) различных сообщений, которые Windows приложения могут получать. Сообщения могут быть организованы в несколько групп в зависимости от их функции. Сообщения - идентификаторы обычно называют символическими (например, WM_PAINT, WM_TIMER), а не числовыми значениями, эти символические значения определены в стандартных заголовочных файлах Windows. (Вам нужно только включить windows.h, это, в свою очередь, содержит директивы # включить для всего остального.)

До сих пор самой густонаселенной группой сообщений Windows, являлась группа сообщений управляющим окном. Символические идентификаторы для этих сообщений начинаются с WM_. Эта группа является настолько большой, она имеет смысл только для дальнейшего разделения её на категории. Эти категории включают DDE (Динамические обмены файлами) сообщения, буфер обмена сообщениями, сообщения от мыши, клавиатурные сообщения, сообщения нерабочей области (сообщения, которые относятся к названию, границе и области меню из окна, как правило, те области, которые управляются операционной системой , а не приложениями), MDI (Многоканальный интерфейс документа) , а также многие другие виды. Эти категории являются несколько неточными, не всегда строго определенными, они просто служат инструментом удобства для программистов, пытающихся сформировать мысленную картину большого набора сообщений, управляемых окнами. Также есть множество фиксированных WM_ сообщений, они постоянно растут, как добавляются и новые возможности операционной системы.

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

Приложения также могут определять свои собственные сообщения. Уникальные идентификаторы сообщений могут быть получены через вызов функции «Регистратор сообщений окна». Использование закрытых типов сообщений позволяет объединить части приложения для общения друг с другом; отдельные приложения могут также обмениваться информацией таким образом.

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

Сообщения и многозадачность.

В Windows 3.1, цикл обработки сообщений играл еще одну важную роль во взаимодействии между приложением и операционной системой: это применение позволило получить контроль. Так как Windows 3.1 нет вытесняющей многозадачности операционной системы, она не прочь побороться за контроль процессора с отказывающимися от сотрудничества приложениями. Надлежащее функционирование системы зависит от кооперативного поведения приложений, а именно, от того, что они часто называют специфическими функциями обработки сообщений. Такое поведение все еще требуется от приложений, которые предназначены для работы под Windows 3.1 при работе в Win32s.

Очереди сообщений

Этот раздел начинается с простого и переходит к более сложному. Во-первых, я описываю работу 16-битной Windows, по обмену сообщениями и планированию архитектурных задач.

В 16-битных Windows, операционная система поддерживает одну очередь сообщений. Сообщения, которые создаются различными средствами операционной системы - такими как клавиатура или мышь, - откладываются в эту очередь сообщений. Когда приложение делает попытку получить следующее сообщение в очереди с помощью функции «Получить сообщение» или «Посмотреть сообщение», операционная система может выполнять переключение контекста и активировать другое приложение, для которого сообщения в очереди. Сообщение идет в начало очереди, затем извлекается и возвращается к активному приложению через MSG структуры.

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

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