5.1 Оконные сообщения
Разрабатывая подсистему управления окнами в Windows 2000 и Windows 98, Microsoft преследовала две основные цели:
обратная совместимость с 16-разрядной Windows, облегчающая перенос существующих 16-разрядных приложении,
отказоустойчивость подсистемы управления окнами, чтобы ни один поток не мог нарушить работу других потоков в системе.
К сожалению, эти цели прямо противоречат друг другу. В 16-разрядной Windows передача сообщения в окно всегда осуществляется синхронно отправитель не может продолжить работу, пока окно не обработает полученное сообщение. Обычно так и нужно. Но, если на обработку сообщения потребуется длительное время или если окно «зависнет», выполнение отправителя просто прекратится. А значит, такая операционная система не вправе претендовать на устойчивость к сбоям.
Это противоречие было серьезным вызовом для команды разработчиков из Microsoft. В итоге было выбрано компромиссное решение, отвечающее двум вышеупомянутым целям. Помните о них, читая эту главу, и Вы поймете, почему Microsoft сделала именно такой выбор.
Для начала рассмотрим некоторые базовые принципы. Один процесс в Windows может создать до 10 000 User-объектов различных типов — значков, курсоров, оконных классов, меню таблиц клавиш-акселераторов и тд. Когда поток из какого-либо процесса вызывает функцию, создающую один из этих объектов, последний переходит во владение процесса. Поэтому, если процесс завершается, не уничтожив данный объект явным образом, операционная система делает этo за него. Однако два User объектa (окна и ловушки) принадлежат только создавшему их потоку. И вновь, если поток создает окно или устанавливает ловушку, а потом завершается, операционная система автоматически уничтожает окно или удаляет ловушку.
Этот принцип принадлежности окон и ловушек создавшему их потоку оказывает существенное влияние на механизм функционирования окон поток создавший окно, должен обрабатывать все его сообщения. Поясню данный принцип на примере До пустим, поток создал окно, а затем прекратил работу Тогда его окно уже не получит сообщение WM_DESTROY или WM_NCDESTROY, потому что поток уже завершился и обрабатывать сообщения, посылаемые этому окну, больше некому.
Это также означает, чью каждому потоку, создавшему хотя бы одно окно, система выделяет очередь сообщений, используемую для их диспетчеризации. Чтобы окно в конечном счете получило эти сообщения поток должен иметь собственный цикл выборки сообщений. В этой главе мы детально рассмотрим, что представляют собой очереди сообщений потоков. В частности, я расскажу, как сообщения помещаются в эту очередь и как они извлекаются из нее, а потом обрабатываются.
- Оглавление
- Введение
- Цель работы
- 1 Процессы, задания и потоки.
- 1.1 Процессы.
- 1.2 Задания.
- 1.3 Потоки.
- 2. Управление памятью в операционных системах
- 2.1 Память и отображения, виртуальное адресное пространство
- 2.2 Виртуальное адресное пространство
- 2.3 Распределение памяти статическими и динамическими разделами
- 2.4 Разделы с фиксированными границами
- 2.5 Разделы с подвижными границами
- 2.6 Сегментная, страничная и сегментно-страничная организация памяти.
- 3 Динамически подключаемые библиотеки.
- 4 Обработка исключений
- 4.1 Обработчики завершения
- 4.2 Примеры использования обработчиков завершения
- 5 Операции с окнами
- 5.1 Оконные сообщения
- 5.2 Очередь сообщений потока
- 5.3 Посылка асинхронных сообщений в очередь потока
- 5.4 Посылка синхронных сообщений окну
- Приложение 1. Справочник api-функций и сообщений Windows.
- Приложение 2. Темы курсовой работы.
- Список литературы
- Литература