МОСКОВСКИЙ ОРДЕНА ЛЕНИНА, ОРДЕНА ОКТЯБРЬСКОЙ РЕВОЛЮЦИИИ ОРДЕНА ТРУДОВОГО КРАСНОГО ЗНАМЕНИ
ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
ИМ. Н.Э. БАУМАНА
Факультет ″Фундаментальных Наук″
Кафедра ″Программного Обеспечения ЭВМ, Информационных Технологий и Прикладной Математики″
Тема:
“Программирование графического режима”
Группа
Руководитель
Калуга 2006г.
Целью написания данной курсовой работы было написание графического редактора. Для реализации данной задачи была создана программа, которая позволяла работать с основными графическими примитивами и инструментами в стандартном GUIWin32: карандаш, линия, прямоугольник, эллипс, стирка, заливка и пипетка. Данная программа написана на языке Assembler.
1.1. Постановка задачи
1.2. Общие сведения
1.3. Теоретические сведения
2. КОНСТРУКТОРСКАЯ ЧАСТЬ
2.1. Общие сведения
2.2. Функциональное назначение
2.3. Описание логической структуры
2.4. Вызов и загрузка программы
2.5. Связь программы с другими технологиями
3. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
3.1. Руководство программиста
3.2. Руководство оператора
ЛИТЕРАТУРА
ПРИЛОЖЕНИЕ
Создать графический редактор для работы с графическими примитивами: точка, линия, прямоугольник, окружность.
Ассемблерные программы могут быть очень эффективными. Из программистов, с равными навыками и способностями, работающий на языке ассемблера создаст программу более компактную и быстродействующую, чем такая же программа, написанная на языке высокого уровня. Это так практически для всех небольших или средних программ. К сожалению, по мере возрастания размеров, программы на языке ассемблера теряют часть своих преимуществ. Это происходит из-за необходимого в ассемблерной программе внимания к деталям. Язык ассемблера требует от программиста планирования каждого действия компьютера. В небольших программах это позволяет оптимизировать работу программы с аппаратными средствами. В больших же программах огромное количество деталей может помешать эффективно работать над самой программой, даже если отдельные компоненты программы окажутся очень неплохими. Безусловно, программирование на языке ассемблера отвечает потребностям не каждой программы.
Программы на языке ассемблера очень точны. Поскольку этот язык позволяет программисту непосредственно работать со всем аппаратным обеспечением, ассемблерная программа может делать то, что недоступно никакой другой программе. Несомненно, что в программировании устройств ввода-вывода, где требуется контроль над отдельными разрядами регистров устройства, программирование на языке ассемблера - единственный подходящий выбор.
Ясно, что эффективность и точность языка ассемблера дают определенные преимущества. Но его детализированность создает и некоторые проблемы. Когда же стоит избирать для программирования язык ассемблера?
Конечно, следует пользоваться программами на языке ассемблера, когда нет другого способа написать программу. Например, программисты фирмы IBM писали с использованием процедур ассемблера все программы управления устройствами ввода-вывода для IBM PC. Для управления устройствами ввода-вывода и системой прерываний, потребовалась та точность языка ассемблера которую не может обеспечить ни один другой язык программирования. Аналогично, на языке ассемблера в фирме IBM писались процедуры диагностики, которые должны проверять каждую деталь аппаратуры.
Язык ассемблера необходим также и в тех случаях, когда главными являются рабочие характеристики программы. Это может быть время исполнения или конечный размер программы. Какая программа не подходит для языка ассемблера? Конечно, на нем можно написать любую программу, однако с большой программой лучше работать в языке высокого уровня. Эти языки позволяют сосредоточиться на конкретной задаче и не приходится непосредственно иметь дело с тонкостями аппаратного оборудования и процессора. Языки высокого уровня «позволяют отступить назад и за деревьями увидеть лес».
И последняя причина для изучения программирования на языке ассемблера. Только через написание программ на этом уровне детализации можно понять как работает машина на самом низком уровне. Если вы хотите узнать о компьютере все, вы должны быть знакомы с его языком ассемблера. Единственный способ добиться этого - писать программы на этом языке.
Данная курсовая работа написана с использованием только функций Win32 API. Т.о. данная программа могла быть реализована и на языке высокого уровня. Однако, по той причине, что в программе не использовались очень сложные и объемные алгоритмы, а сама программа хорошо структурирована, сложность написания данной программы сравнима с разработкой аналогичной программы на языке C/C++. Кроме того, ассемблер позволил написать многие участки программы максимально коротко, без использования шаблонов реализации структурных элементов языков высокого уровня, чем грешат многие компиляторы высокоуровневых языков. Также, при написании данной программы было четко известно, что будет в исполняемом файле после компиляции, в то время как многие компиляторы добавляют в исполняемые программы множество не необходимой и даже ненужной информации и кода. Поэтому готовая программа имеет минимальный размер и максимальное быстродействие. Из всего этого следует, что ассемблер является весьма подходящим для написания данной курсовой работы, являясь не то, что б не хуже, а даже лучше языков более высокого уровня.
Win32 программы выполняются в защищенном режиме, который доступен начиная с 80286. Но 80286 теперь история. Как известно, каждую Win32-программу Windows запускает в отдельном виртуальном пространстве. Это означает, что каждая Win32-программа будет иметь 4-х гигабайтовое адресное пространство, но вовсе не означает, что каждая программа имеет 4 гигабайта физической памяти, а только то, что программа может обращаться по любому адресу в этих пределах. А Windows сделает все необходимое, чтобы сделать память, к которой программа обращается, "существующей". Конечно, программа должна придерживаться правил, установленных Windows, или это вызовет GeneralProtectionFault.
Каждая программа одна в своем адресном пространстве, в то время как в Win16 дело обстоит не так. Все Win16-программы могут «видеть» друг друга, что невозможно в Win32. Эта особенность помогает снизить шанс того, что одна программа запишет что-нибудь поверх данных или кода другой программы.
Модель памяти также коренным образом отличается от 16-битных программ. Под Win32 мы больше не должны беспокоиться о моделях памяти или сегментах. Теперь только одна модель память: плоская, без 64-ти килобайтных сегментов. Теперь память - это большое последовательное 4-х гигабайтовое пространство. Это также означает, что не нужно работать с сегментными регистрами, зато можно использовать любой сегментный регистр для адресации к любой точке памяти. Это ОГРОМНОЕ подспорье для программистов. Это то, что делает программирование на ассемблере под Win32 таким же простым, как на C.
Windowsпредоставляет огромное количество ресурсов Windows-программам через Windows API (ApplicationProgrammingInterface). Windows API - это большая коллекция очень полезных функций, располагающихся непосредственно в операционной системе и готовых для использования программами. Эти функции находятся в нескольких динамически подгружаемых библиотек, таких как kernel32.dll, user32.dll, gdi32.dll и т.д. Kernel32.dll содержит API функции, взаимодействующие с памятью и управляющие процессами. User32.dll контролирует пользовательский интерфейс. Gdi32.dll ответственен за графические операции. Кроме этих трех "основных", существуют также другие динамические библиотеки, которые можно использовать при условии, что обладаете достаточным количеством информации о нужных API функциях. Windows-программы динамически подсоединяются к этим библиотекам, то есть код API функций не включается в исполняемый файл. Информация находится в библиотеках импорта. Нужно слинковать программы с правильными библиотеками импорта, иначе они не смогут найти эти функции. Когда Windows-программа загружается в память, Windows читает информацию, сохраненную в программе. Эта информация включает имена функций, которые программа использует и DLL-ок, в которых эти функции располагаются. Когда Windows находит подобную информацию в программе, она вызывает библиотеки и исправляет в программе вызовы этих функций, так что контроль всегда будет передаваться по правильному адресу.
Существует две категории API функций: одна для ANSI и другая для Unicode. На конце имен API функций для ANSI стоит "A", например, MessageBoxA. В конце имен функций для Unicode находится "W”. Мы обычно имеем дело с ANSI строками (массивы символов, оканчивающиеся NULL-ом). Размер ANSI-символа - 1 байт. В то время как ANSI достаточна для европейских языков, она не поддерживает некоторые восточные языки, в которых есть несколько тысяч уникальных символов. Вот в этих случаях в дело вступает Unicode. Размер символа UNICODE - 2 байта, и поэтому может поддерживать 65536 уникальных символов. Но по большей части, используются include-файлы, которые могут определить и выбрать подходящую для платформы функцию. Тогда достаточно обращаться к именам API функций без постфикса.
С точки зрения программиста Windows является системой, не зависящей от устройств (deviceindependent). Эту независимость со стороны Windows обеспечивает библиотека GDI32.dll, а со стороны устройства - драйвер этого устройства. С точки зрения программы связующим звеном между программой и устройством является контекст устройства (DeviceContext - DC). Если программе нужно осуществить обмен с внешним устройством, программа должна оповестить GDI о необходимости подготовить устройство для операции ввода-вывода. После того, как устройство подготовлено, программа получает хэндл контекста устройства, т. е. хэндл структуры, содержащей набор характеристик этого устройства. В этот набор входят: