18

Министерство образования и науки Российской Федерации

Казанский государственный технический университет

имени А.Н. Туполева

____________________________________________________

Межкафедральный филиал факультета № 4 в ОАО ICL-КПО ВС

Методическое руководство к

лабораторной работе

“ Каркас программы под Windows. Создание окна.”

по дисциплине “Системное программирование”

Р.Ф. Миннибаев

Казань 2004

Содержание

1. Концепция программирования под Windows. Основные понятия 3

1.2. Интерфейс вызовов функций в Windows 3

1.3. Библиотеки динамической загрузки 3

1.4. Win16 или Win32 4

1.5. Интерфейс GDI 4

1.6. Многозадачность в Windows 4

1.7. Взаимодействие программ и Windows 5

1.8. Основы программирования под Windows 5

1.8.1.Функция WinMain() 5

1.8.2. Функция окна 6

1.8.3. Цикл сообщений 6

1.8.4. Класс окна 6

1.8.5. Специфика программ для Windows 6

1.8.6. Типы данных в Windows 7

1.8.7. Соглашение об использовании имен 7

1.9. Элементы окна 8

2. Каркас программы под Windows. Создание окна 9

2.1. Каркас программы для Windows 95 9

2.1. Определение класса окна 11

2.2. Создание окна 13

2.3. Цикл сообщений 15

2.4. Функция окна 16

3. Порядок выполнения работы 17

1. Концепция программирования под Windows. Основные понятия

1.1. Программная среда Windows

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

1.2. Интерфейс вызовов функций в Windows

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

Благодаря этому интерфейсу доступ к системным ресурсам осуществляется через целый ряд системных функций. Как уже упоминалось раннее, совокупность таких функций называется прикладным программным интерфейсом, или API (Application Programming Interface). Для взаимодействия с Windows приложение запрашивает функции API, c помощью которых реализуются все необходимые системные действия, такие как выделение памяти, вывод на экран, создание окон и т.п.

1.3. Библиотеки динамической загрузки

Поскольку API состоит из большого числа функций, может сложиться впечатление, что при компиляции каждой программы, написанной для Windows, к ней подключается код довольно значительного объема. В действительности это не так. Функции API содержатся в библиотеках динамической загрузки (Dynamic Link Libraries, или DLL), которые загружаются в память только в тот момент, когда к ним происходит обращение, т.е. при выполнении программы. Рассмотрим, как осуществляется механизм динамической загрузки.

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

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

1.4. Win16 или Win32

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

Была реализована поддержка потоковой многозадачности, новых эле­ментов интерфейса и прочих нововведений Windows. Если прежде вам не приходи­лось программировать под Windows, подобные изменения не покажутся вам существенными, поскольку вы, очевидно, с самого начала будете писать 32-разрядные приложения. Если же необходимо переписать старый код для работы под Windows 95 или Windows NT, то изменения придется учитывать.

Так как Win32 поддерживает полностью 32-разрядную адресацию, то логично, что целые типы данных (integers) также объявлены 32-разрядными. Это означает, что переменные типа hit и unsigned будут иметь длину 32 бита, а не 16, как в Windows 3.1. Если же необходимо использовать переменную или константу длиной 16 бит, они должны быть объявлены как short. (Дальше будет показано, что для этих типов определены независимые typedef-имена.) Следовательно, при переносе программного кода из 16-разрядной среды необходимо убедиться в правильности использования целочисленных элементов, которые автоматически будут расширены до 32 битов, что может привести к появлению побочных эффектов.

Другим следствием 32-разрядной адресации является то, что указатели больше не нужно объявлять как near или far. Любой указатель может получить доступ к любому участку памяти. В Windows 9x и Windows NT константы near и far объявлены (с помощью директивы #define) пустыми.