Собрание русскоязычных статей сайта wasm.ru о программировании, ассемблере, реверс-инжиниринге и компьютерной безопасности. Том 2 из 11. Разделы: 3. COM и OOP; 4. DirectX/OpenGL. Все приложенные файлы находятся в wasm_files.zip.
Больше крутых материалов в моём телеграм канале @grogrigs
Автор: Bill T., пер. Aquila
Дата: 2002-06-27
В этой статье будет расказано о том, как использовать COM-интерфейсы в ваших программах, написанных на ассемблере. Не будет обсуждаться, что такое COM и как он применяется, но как его можно использовать, программируя на ассемблере. Здесь будет затронуто только применение существующих интерфейсов, а не реализация своих собственных, это будет рассмотрено в другой статье.
Это краткое введение в основы COM.
Получить доступ к COM-объекту можно только через один или большее количество наборов связанных с ним функций. Эти наборы функций называются интерфейсами, а функции интерфейса называются методами. COM требует, чтобы существовал только один путь доступа к методам интерфейса - через указатель на интерфейс.
По терминологии COM, интерфейс - это "контракт", состоящий из группы связанных друг с другом прототипов функций, чье использование определено, а реализация - нет. Определение интерфейса задает функции интерфейса, называемые методами, типы возвращаемых ими значений, количество и типы их параметров, и что они должны делать. С интерфейсом не ассоциируется какая-то конкретная его реализация. Реализация интерфейса - это код, который предоставляет программист для выполнения действий, заданных определением интерфейса.
Экземпляр реализации интерфейса - это указатель на массив указателей на методы (таблица указателей, ссылающиеся на реализацию всех методов, указанных в интерфейсе). Любой код, у которого есть подобный указатель, может вызывать методы этого интерфейса.
Доступ к COM-объекту осуществляется через указатель, который указывает на таблицу указателей на функции (эту таблицу еще называют таблицей виртуальных функций или vtable для краткости). Эта таблица содержит адреса каждого из методов объекта. Чтобы вызывать метод, вы косвенно вызываете его через эту таблицу указателей.
Здесь приводится пример интерфейса на C++, и как называются его методы:
То же самое можно реализовать на ассемблере следующим образом:
Вы можете видеть, что это отличается от вызова обычной функции. Здесь pObject указывает на таблицу интерфейса. По смещению Function1 (0Ch) в этой таблице находится указатель на саму функцию, которую мы хотим вызвать.
Возвращаемое значение функциями OLE API и методами является HRESULT. Это не хэндл чег-нибудь, а просто 32-х битное значение с несколькими полями. Части HRESULT показаны ниже.
HRESULT - это 32-х битное значение со следующей структурой.
Если вы используете MASM для ассемблирования ваших программ, вы можете использовать некоторые из его возможностей, чтобы сделать вызов COM-функций очень простым. Используя invoke, вы можете сделать COM-вызовы почти такими же понятными как вызовы обычных функций, плюс вы можете добавить проверку типов для каждой функции.
Определение интерфейса:
Использование интерфейса для вызова COM-функций:
Как вы можете видеть, синтакс может выглядеть немного странно, но это дает возможность использовать имя функции вместо смещений, а заодно и проверку типов.
Вот исходник, который написан так, чтобы быть максимально совместимым с любым ассемблером, который вы предпочтете (по крайней мере, чтобы вам не пришлось делать глобальных изменений).
Эта программа использует интерфейсы Windows Shell, чтобы отобразить содержиом Рабочего стола. Программа не закончена, но она показывает, как инициализровать библиотеку COM, деинициализировать и использовать. Я также покажу, как использовать shell-библиотека, чтобы получить папки и объекты, и выполнять над ними различные действия
Хорошо, вот и все об использовании COM при программировании на ассемблере. Вероятно, что моя следующая статья расскажет о том, как определить собственные интерфейсы. Как вы можете видеть, использование COM вовсе не сложно, и с его помощью вы можете добавить очень мощные возможности в вашу программу, написанную на ассемблере.
Автор: Bill T., пер. Aquila
Дата: 2002-06-27
В моей предыдущей статье объяснялось, как использовать COM-объекты в ваших программах, написанных на ассемблере. Там говорилось только о том, как вызывать COM-методы, а не как создавать свои COM-объекты. Эта статья расскажет, как это делать.
В этой статье будет затронуто реализация COM-объектов, используя синтаксис MASM. Здесь не будут браться в расчет ассемблеры TASM или NASM, хотя используемые методы легко применить к любому ассемблеру.
В этой статье не будут объсняться продвинутые технологии COM, такие как повтороное использование, трединг, серверы/клиенты и т.д. Об этом будет рассказано в будущих статьях.
Определение интерфейса задает методы интерфейса, возвращаемые ими значения, количество и типы их параметров и что эти методы должны делать. Далее идет пример простого определения интерфейса:
STDMETHOD используется для упрощения объявления интерфейса и определяется следующим образом:
Использование этого макроса значительно упрощает объявления интерфейсов и делает возможным использование команды invoke. (Макрос написан Ewald'ом :) )
Какую форму записи использовать - дело вкуса. В обоих случаях генерируется один и тот же код.
Все интерфейсы должны наследоваться от интерфейса IUnknown. Это означает, что первые 3 метода vtable должны быть QueryInterface, AddRef и Release. Цель и реализация этих методов будет обсуждаться ниже.
GUID - это глобальный уникальный ID. GUID - это 16-ти байтное число, которое уникально у каждого интерфейса. COM использует GUID'ы, чтобы отличать интерфейсы друг от друга. Использование этого метода предотвращает проблемы с совпадением имен или версий. Чтобы получить GUID, вы можете использовать утилиту, которая включена в большинство пакетов разработки программ под Win32.
GUID можно представить как следующую структуру:
Затем GUID объявляется в секции данных:
Как только GUID ассоциирован с интерфейсом и опубликован, никаких дальнейших изменений в его определении быть не должно. Обратите внимание, это не означает, что не может меняться реализация интерфейса. Если необходимо изменение интерфейса, должен быть использован новый GUID.
COM-объект - это просто реализация интерфейса. Детали реализации не затрагиваются стандартами COM, поэтому мы можем реализовывать объекты как угодно, пока это удовлетворяет всем требованиям определения интерфейса.
Типичный объект будет содержать указатели на различные интерфейсы, которые он поддерживает, счетчик ссылок и другие данные, которые могут потребоваться объекту. Вот простое определение объекта, реализованное в виде структуры:
Также мы должны определить vtable'ы, которые будут использоваться. Эти таблицы должны быть статическими и не могут меняться во время выполнения программы. Каждый член vtable - это указатель на метод. Далее показывается, как определить vtable.
COM-объект управляет продолжительностью своей жизни с помощью подсчета ссылок. У каждого объекта есть счетчик ссылок, отслеживающий, как много экземпляров указателя на интерфейс было создано. Счетчик объекта должен поддерживать значение до 2^32, то есть он должен быть DWORD.
Когда счетчик ссылок падает до нуля, объект больше не используется и разрушает сам себя. Два метода интерфейса IUnknown AddRef и Release обрабатывают подсчет ссылок для COM-объекта.
Метод QueryInterface используется, чтобы определить, поддерживается ли объектом определенный интерфейс, и если да, позволяет получить указатель на него. Есть три правила реализации метода QueryInterface:
1. Объекты должны быть идентичны - вызов QueryInterface должен всегда возвращать одно и то же значение.
2. Набор интерфейсов объекта не должен меняться - например, если вызов QueryInterface с неким IID был однажды успешен, то он должен быть успешным всегда. Таким же образом, если вызов однажды не удался, то не должен удасться в другой раз.
3. Должно быть возможно проверить наличие одного интерфейса объекта из другого интерфейса.
QueryInterface возвращает указатель на указанный интерфейс объекта, указатель на интерфейс которого уже есть у клиента. Эта функция должна вызывать метод AddRef указателя, который она возвращает.
Вот описание аргументов QueryInterface:
QueryInterface возвращает следующее:
Вот простая ассемблерная реализация QueryInterface:
Метод AddRef используется для повышения значения счетчика ссылок для интерфейса объекта. Он должен вызываться для каждой новой копии указателя на интерфейс объекта.
AddRef не принимает параметров, кроме указателя на интерфейс, что требуется для всех методов. AddRef должен возвращать новое значение счетчика ссылок. Тем не менее, это значение должно использоваться вызывающими только в тестовых целях, так как в определенных ситуациях оно может быть нестабильно.
Далее идет простая реализация метода AddRef:
Release понижает значение счетчика ссылок вызывающего интерфейса объекта. Если значение счетчика объекта снижается до 0, то объект выгружается из памяти. Эта функция должна вызываться, когда в указателе на интерфейс больше нет надобности.
Как и AddRef, Release пpинимает только один аpгумент - указатель на интеpфейс. Он также возвpащает текущее значение счетчика ссылок, котоpый также следует использовать только для тестиpования.
Вот простая реализация Release:
Создание объекта состоит из резервирования памяти для объекта, а затем инициализации его данных. Как правило, инициализируется указатель на vtable и обнуляется счетчик ссылок. Затем можно вызывать QueryInterface, чтобы получить указатель на интерфейс.
Есть и другие методы для создания объектов, такие как CoCreateInstance и использование фабрик классов. Эти методы не будут обсуждаться в данной статье.
Здесь приводится простая реализация COM-объекта. Демонстрируется, как создать объект, вызвать его методы, а затем освободить их. Вероятно, будет довольно познавательно скомпилировать данный пример и пройтись по нему отладчиком.
Мы увидели (надеюсь), как реализовать COM-объект. Мы можем видеть, что это связанно с определенными трудностями и увеличивает избыточность кода нашей программы. Тем не менее, это может добавить гибкость и силу в наши программы. Подробности по данной теме вы можете найти на моей маленькой странице, посвященной COM: http://lordlucifer.cjb.net.
Помните, что COM определяет только интерфейсы, а реализацию оставляет на программиста. Эта статья показывает только одну возможную реализацию. Это не единственный метод и не самый лучший. Читатель не должен бояться экспериментировать с другими методами.
Автор: Ernie, пер. Aquila
Дата: 2002-06-27
COM (Component Object Model) используется операционной системой Windows различным образом. Например, shell.dll использует COM для доступа к некоторым из своих API методов. Интерфейсы IShellLink и IPersistFile shell32.dll будут продемонстрированы путем создания ярлыка. Предполагается базовое знание COM. Использованный код выдержан в стиле MASM.
COM может показаться весьма сложным из-за своих многочисленных особенностей, но в реальности многие из этих сложностей вырождаются в простой вызов функций. Самой сложной частью является понимание вовлеченных в процесс структур данных, которые необходимо использовать при определении интерфейсов. Я извиняюсь за всю эту С++'нутую терминологию, использованную в этом туториале. Хотя COM является языконезависимой технологией, большая часть терминологии для его определения была заимствована из C++.
Чтобы использовать COM-методы какого-либо объекта, сначала вы должны инстанцировать или создать этот объект из соответствующего com-класса, затем получить от него указатель на его интерфейс. Этот процесс производится с помощью API-функции CoCreateInstance. После того, как вы выполните все, что нужно, вам необходимо вызвать его метод Release, и com-класс удалит объект, а COM выгрузит com-класс.
COM-объект называется сервером, а программа, которая его вызывает, называется клиентом.
Чтобы использовать COM-методы, вам необходимо знать структуру интерфейса. Даже если вы используете "позднее связывание" через IDispatch, вам все равно нужно знать структуру IDispatch. COM-интерфейс - это всего лишь таблица указателей на функции. Давайте начнем с интерфейса IUnknown. Если бы вы создавали компонент, который просто экспортирует интерфейс IUnknown, то получили бы полностью рабочий COM-объект (хотя и на уровне "Hello, world"). IUnknown имеет три основных метода, которые есть в любом интерфейсе, потому что любой интерфейс наследуется от IUnknown. Держите в уме, что все интерфейсы являются структурой указателей на функции. Для IUnknown это будет выглядеть так:
Именно так, всего лишь 12 байтов длиной. Он состоит из трех 4-х байтных указателей на процедуры, которые фактически и являются методами. Это и есть печально известная "vtable", о которой вы уже могли слышать. Указатели определены так, чтобы MASM мог делать для нас кое-какую проверку типов при компиляции наших вызовов. Так как виртуальная таблица содержит адреса функций (указатели), эти указатели определены в нашем описании интерфейса через typedef.
Наконец мы определяем прототипы функций следующим образом:
Подобное определение интерфейса позволяет выявлять множество ошибок в процессе компиляции. На практике мы определять эти интерфейсы в заголовочных файлах, чтобы они не засоряли исходный код.
Одно довольно большое замечание относительно определения интерфейсов: MASM не может использовать подобные косвенные ссылки, поэтому мы определяем заранее прототипы функций через typedef'ы, а потом виртуальную таблицу интерфейса. В заголовочных файлах программы-примера интерфейсы определяются именно таким образом.
Чтобы использовать интерфейс, вам нужно получить на него указатель.
Функция CoCreateInstance может быть использована для получения этого косвенного указателя на структуру интерфейса. Таким образом, один уровень "виртуальности" убран и у нас есть указатель на "объект", который содержит структуру. Окончательно все это выглядит так:
Как видите, здесь очень много косвенных ссылок, что может заставить вас спятить, пока вы будете писать код, в котором все элементы будут ссылаться друг на друга правильно, поэтому в дальнейшем будут определены макросы для облегчения данной задачи.
Когда клиент делает вызов на COM-библиотеку, чтобы создать COM-объект, он передает адрес переменной, в которую будет помещен указатель на объект. Этот изначальный указатель часто называют "ppv", от С++'нутого "pointer to pointer to (void)", где (void) значит неопределенный тип. Ppv содержит адрес другого указателя ("pv"), который, в свою очередь ссылается на всю таблицу указателей. В ней на каждую функцию интерфейса приходится один элемент таблицы.
Например, предположим, что мы использует CoCreateInstance и успешно получили интерфейсный указатель ppv и узнать, поддерживает ли он другие интерфейсы. Мы можем вызвать его метод QueryInterface и запросить новый ppv (ppv2, указатель на интерфейс) на другой интерфейс (pIID, указатель на Interface Indentifying GUID), который нам нужен. В C++ QueryInterface имеет следующий прототип:
(HRESULT) SomeObject::QueryInterface (this:pObject, IID:pGUID, ppv2:pInterface)
Подобный вызов будет выглядеть примерно так:
Это может быть выполнено с помощью встроенного в MASM макроса 'invoke' следующим образом:
Я надеюсь, что это для будет настолько же просто, как и для меня.
Обратите внимание, что мы должны передать функции использованный нами указатель, так как это позволяет знать интерфейсу какой объект (в C++ этот указатель обозначается как "this") мы используем.
Также заметьте, что необходимо делать привод регистра к соответсвующему типу. Это позоволяет компилятору знать, какую структуру использовать, чтобы получить правильное смещение в виртуальной таблице для функции .QueryInterface (в данном случае это означает нулевое смещение от [edx].
Еще один момент, который может быть не совсем ясен. Обратите внимание, что я изменил имя функции с "QueryInterface" на "IUnknown_QueryInterface". Я считаю подобное изменение имени функций необходимым, так как когда вы перейдете к COM-проектам со множеством похожих интерфейсов, в которых будут встречаться методы с одинаковыми именами. В этом нет ничего неправильного, фактически это и есть то, что называется полиморфизмом, но это может немного смутить компилятор.
Таким образом, тот же метод QueryInterface теперь можно вызвать одной строчкой кода:
Обратите внимание, что теперь преобразованием имени делает макрос.
Единственный 'подводный камень' (хорошо, наиболее очевидный) - это то, что параметры COM-функции не должны передаваться через edx, так как он используется для хранения ссылки на 'this'. Использование edx'а в качестве параметра сгенерирует ошибку компиляции.
Shell32.dll предоставляет простой, легкий путь для создания ярлыков. Тем не менее, она использует COM-интерфейс для этого. Приведенный ниже пример основан на секции MSDN "Shell Links" из "Internet Tools and Technologies".
Эту статью вы можете найти по адресу http://msdn.microsoft.com/library/psdk/shellcc/shell/Shortcut.htm.
Мы получим доступ к нескольким членам интерфейсов IShellLink и IPersistFile. Обратите внимание, что каждый интерфейс включает параметр "ppi", это интерфейс, который мы вызываем (это параметр THIS). (Следующая информация является копией той, что предоставленна Микрософтом).
• IShellLink::QueryInterface, ppi, ADDR riid, ADDR ppv
• riid: идентификатор требуемого интерфейса.
• ppv: указатель на переменную, которая получает интерфейс.
• Описание: проверяет, поддерживает ли объект требуемый интерфейс. Если это так, то заполняет ppv указателем на интерфейс.
• IShellLink::Release, ppi
• Описание: понижает количество ссылкок на интерфейс IShellLink на один.
• IShellLink::SetPath, ppi, ADDR szFile
• pszFile: указатель на текстовый буфер, содержащий новый путь на объект-ярлык.
• Описание: задает путь к файлу, на который указывает ярлык.
• IShellLink::SetIconLocation, ppi, ADDR szIconPath, iIcon
• pszIconPath: указатель на текстовый буфер, содержащий новый путь к иконке.
• iIcon: индекс иконки. Отсчет идет с нуля.
• Description: устанавливает какую иконку будет использовать ярлык.
• IPersistFile::Save, ppi, ADDR szFileName, fRemember
• pszFileName: указывает на ASCIIZ-строку, содержащую абсолютный путь к файлу, в который должен быть сохранен объект.
• fRemember: указывает, должен ли файл, заданный в pszFileName, стать текущим рабочим файлом. Если TRUE, то pszFileName становится текущим файлом и объект должен очистить свой флаг занятости после сохранения. Если FALSE, то это сохраняет операцию как "Save A Copy As ...". В этом случае текущий файл не изменяется, а объект не должен очищаеть свой флаг занятости. Если pszFileName равен NULL, флаг fRemember должен игнорироваться.
• Описание: выполняет операцию сохранения для объекта-ярлыка или сохраняет созданный ярлык.
• IPersistFile::Release, ppi
• Description: уменьшает счетчик ссылок на интерфейс IPersistFile на один. Эти интерфейсы содержат гораздо больше методов (смотри полное определение интерфейса в прилагающемся к туториалу коде), но мы сконцентрируемся только на тех, которые реально используем.
В файле ярлыка (.lnk) содержится следующая информацию:
• Путь к файлу и имя программы
• Откуда берется иконка, используемая при отображении ярлыка (обычно берется из самого экзешника), и какая конкретна иконка берется из этого файла. Мы будем использовать первую иконку из этого файла.
• Путь к файлу, в котором должен быть сохранен ярлык.
Использование этих интерфейсов достаточно просто и прямолинейно. Это выглядит примерно следующим образом:
• Вызываем CoCreateInstance CLSID_ShellLink, чтобы получить интерфейс IID_IShellLink, Queryinterface IShellLink, чтобы получить интерфейс IID_IPersistFile.
• Вызываем IShellLik.SetPath, чтобы указать, где находится файл, на который будет ссылаться ярлык.
• Вызываем IShellLink.SetIconLocation, чтобы указать, какую иконку использовать.
• Вызываем IPersistFile.Save, чтобы сохранить наш ярлык.
• Вызываем IPersistFile.Release.
• Вызываем IShellLink.Release.
Вам следуется знать о нескольких полезных утилитах, входящий в MSVC: консольная утилита "FindGUID.exe", которая просматривает регистр в поисках определенного интерфейса или com-класса или выведет список всех классов и интерфейсов с ассоциированными с ними GUID'ами, а также приложение OLEView, которамя позволит вам получать информацию из различных библиотек.
Будьте внимательны во время определения интерфейса. Пропуск методы в виртуальной таблице может повлечь странные результаты. Выкиньте метод из определения таблице вы получите неверный интерфейс. В оригинальное определении интерфейса IShellLink, которое я использовал, была пропущена одна функция. Вызовы, которые я осуществлял, возвращали в hResult "SUCCEDED", но в некоторых случаях стек очищался неправильно (поскольку не совпадало количество параметров, а это, в свою очередь, приводил к GPF, как только я выходил из процедуры. Держите это в уме, если у вас начинают происходить "странные" вещи.
Эта программа делает очень немного, как и полагается хорошей программе-туториалу. Как только вы ее запустите, она создаст ярлык на саму себя в той же директории. Довольно необычно запускать ее из файлового менеджера и смотреть, как появляется ярлык. Затем вы можете испытать ярлык и увидеть, как изменится время его создания.
Исходник программы находится в masm32\COM\examples\shortcut. Он начинается с "хакерского" кода, с помощью которого программа получает полный путь к программе и формирует необходимые строки, которые затем передаются интерфейсу IShellLink, после чего ярлык сохраняется.
Процедура CoCreateLink используется для запуска соответствующих COM-методов и создания ярлыка так, чтобы эта процедура могла использоваться в других программах.
Автор: Hangatyr
Дата: 2004-01-03
Предисловие В этой статье (а возможно и цикле статей) я попытаюсь рассказать о том, как добавить поддержку скриптовых языков в программу, написанную на ассемблере. Наверное, это самый простой путь реализовать поддержку макросов в своей программе и, может быть, кому-то это и пригодится ;). Пара слов о компиляторе
Я не буду здесь поднимать бесполезный вопрос о том какой компилятор самый лучше и т.п. - в конце концов это дело вкуса. Скажу только, что я буду использовать fasm (http://flatassembler.net) и, соответственно, полагаю, что для читателя не будет сюрпризом увидеть
вместо
Но вообще-то это, наверное, не проблема ;)
Colib Говоря о использовании COM в ассемблере нельзя не сказать о работах Ernest Murphy, в том числе о библиотеке Colib, которая предоставляет нам набор удобных функций для работы с COM-объектами. Но у нее есть один минус - она ориентирована на MASM. Хотя минус это или плюс решать не мне и если ваш любимый ассемблер - MASM32 (с которым, кстати, и поставляется вышеозначенная библиотека), то вы вполне можете радоваться, т.к. часть работы уже сделана за вас. Но изучить прилагающиеся к ней примеры не помешает в любом случае. Еще советую почитать статью "Using COM in Assembly Language" by Bill Tyler. Основы Component Object Model В этом разделе я постараюсь кратко объяснить некоторые основы технологии COM, которые необходимы для понимания материала, изложенного в данной статье. Как обычно, те кто уже имеет нужные знания (а нужно нам не так уж и много) могут спокойно пропустить этот раздел и перейти сразу ко второй части. А для оставшихся продолжаем.
Технология COM - это мощный инструмент, позволяющий разбить монолитное приложения на самостоятельные компоненты. Такая необходимость неизбежно должна была возникнуть, учитывая темпы развития индустрии программирования.
Что же такое COM? Не более, чем набор правил, определяющих каким образом могут взаимодействовать компоненты, написанные в общем случае разными людьми и на разных языках программирования, это стандарт, призванный обеспечить возможность их совместной работы. Идея, лежащая в основе, довольно проста - код, который должен стать всеобщим достоянием оформляется в виде своеобразного мини-приложения, так называемого COM-объекта. А функции, которые должны быть доступны извне группируются в интерфейсы этого объекта. Через них и осуществляется взаимодействие с клиентами. Интерфейсов может быть сколько угодно - правило здесь только одно - спецификация COM требует, чтобы каждый объект содержал специальный интерфейс IUnknown, а также чтобы любой другой интерфейс так или иначе наследовался от него.
Этот интерфейс занимает в COM особое место и это не случайно - с его помощью можно всегда получить остальные интерфейсы, поддерживающиеся объектом, кроме этого он предоставляет нам некоторые базовые средства управления жизнью объекта. Вот 3 его метода (функции интерфейсов называются методами):
_ HRESULT QueryInterface(REFIID iid, void ppvObject) - данный метод используется для получение указателя на интерфейс объекта по идентификатору. Если запрошенный интерфейс поддерживается объектом, то будет возвращено значение S_OK и указатель на интерфейс помещен в ppvObject. В противном случае возвращается E_NOINTERFACE._
_ ULONG AddRef(void) - инкрементирует счетчик использования объекта и должен вызываться всякий раз, когда некто собирается использовать объект (например, он должен вызывается всякий раз, когда метод QueryInterface возвращает указаетель на какой-нибудь интерфейс объекта). Возвращаемое значение - новое значение счетчика ссылок._
_ ULONG Release(void) - этот метод выполняет обратные действия и должен вызываться, когда клиент закончил работу с объектом._
Как было сказано выше, эти методы должны быть первыми методами любого интерфейса и именно в таком порядке (порядок следования очень важен - это следует из структуры интерфейса, принятой в COM).
Так как спецификация COM не предусматривает никаких особых стандартов в отношении реализации объектов, то мы не будем заострять на этом внимания, скажу лишь, что любой объект можно условно разделить на две части - первая содержит указатели на интерфесы, а вторая - различные данные (в том числе и вышеупомянутый счетчик ссылок).
А вот интерфейсы в отличии от объектов должны иметь четко оговоренную структуру.
Основой интерфейса является массив адресов функций (часто называемый просто "vtable"). В качестве примера рассмотрим простейший интерфейс, состоящий из четырех методов (три из них - методы IUnknown).
Довольно просто, не так ли? Чтобы вызвать определенный метод нужно знать только его положение в vtable, правда тут есть одна тонкость - первым параметром методу всегда передается указатель на интерфейс - даже если в описании метода значится void т.е. вызов Release будет выглядеть не так:
а вот так:
Дело в том, что описания методов даются, как правило, для языков высокого уровня, а там эту работу за нас выполняет компилятор и, например, на C аналогичный вызов действительно будет таким:
Script Engines.
Предположим, что у нас в наличии есть такая программка:
(Легко заметить, что она ничего не делает кроме того, что показывает окно открытия файла по нажатию на кнопку)
А также имеется скрипт:
(Да простят меня Боги за появление здесь этих крамольных строк ;)
И кроме этого есть еще желание заставить его выполнятся. Ну что же приступим...
На сегодняшний день всеми нами любимая корпорация Microsoft предоставляет скиптовые движки JavaScript и VBScript совершенно свободно - единственное, чего они хотят, так это упоминание о них в AboutBox'e программы, что, согласитесь, довольно нетипично.
Физически эти движки находятся в файлах jscript.dll и vbscript.dll, но оформлены в виде COM-объектов, а значит наша цель - написать приложение, которое может работать с COM, чем мы сейчас и займемся.
Самое первое, что нужно сделать - это поставить вызов функции CoInitialize где-нибудь в начале, например, при создании окна:
Данная функция инициализирует библиотеку COM и должна быть вызвана перед использованием любых CoXXX-функций.
Теперь с помощью API CoCreateInstance попросим систему создать для нас объект, который предоставит интерфейсы для управления движком VBScript.
Первый параметр представляет собой идентификатор класса, к которому принадлежит создаваемый объект. Нужный нам объект принадлежит к классу "VB Script Language", имеющему ID 0b54f3741h-5b07h-11cfh-0a4b0h-00aa004a55e8h Второй параметр указывает где должен быть запущен код, создающий объект. Значение CLSCTX_INPROC_SERVER говорит, чтобы это было сделано в контексте нашего процесса.
Третий представляет собой идентификатор запрашиваемого интерфейса. В нашем случае он должен быть таким: 0bb1a2ae1h-0a4f9h-11cfh-8fh20h-0805f2c0d064 Как вы уже знаете, COM-объекты доступны только через свои интерфейсы и нужный нам VBScript здесь не исключение - для управления движком нам предоставляются два интерфейса (хотя, если быть точным, то их больше, но здесь мы рассмотрим только два): IActiveScript - содержит методы для инициализации движка и управления его состоянием. А с помощью IActiveScriptParse мы можем указать скрипт, который нужно выполнить.
В случае успешного заверешения вызова CoCreateInstance в pIActiveScript будет помещен указатель на интерфейс IActiveScript, который мы запросили, указав GUID 0bb1a2ae1h-0a4f9h-11cfh-8fh20h-0805f2c0d064.
Но нам нужен еще и интерфейс IActiveScriptParse, давайте его сейчас получим. Так как он является интерфесом того же объекта, что и IActiveScript мы можем воспользоваться методом QueryInterface последнего.
Этот код поместит указатель на IActiveScriptParse в переменную pIActiveScriptParse.
Теперь у нас есть все, чтобы управлять скриптовым движком. Думаете это все? Самое интересное еще впереди ;)
IActiveScriptSite и IActiveScriptSiteWindow.
Теперь у нас есть движок, исполняющий скрипт и средства управления им. В принципе, мы можем попробовать скормить ему что-нибудь уже сейчас, но осталась одна проблема - движок живет своей внутренней жизнью и мы все равно ничего не узнаем о результатах. Значит, мы должны обеспечить его средствами связи с нашим приложением.
Надеюсь, ни для кого не станет сюрпризом, что это "средство связи" является ничем иным, как еще одним объектом ;) Стало быть, настало применить на практике все теоритические знания о COM, потому что нам предстоит создать этот объект и реализовать все методы его интерфейсов. Интерфейсов будет два - IActiveScriptSite и IActiveScriptSiteWindow.
IActiveScriptSite для нас чрезвычайно важен т.к. помимо все прочего с его помощью движок информирует приложение о всех событиях, произошедших при обработке скрипта. Вот его методы в порядке следования в vtable:
• QueryInterface
• AddRef
• Release
• GetLCID
• GetItemInfo
• GetDocVersionString
• OnScriptTerminate
• OnStateChange
• OnScriptError
• OnEnterScript
• OnLeaveScript
А вот интерфейс IActiveScriptSiteWindow реализовывать строго говоря необязательно, но мы все же это сделаем. И вот почему - когда скрипт захочет как-нибудь взаимодействовать с GUI (например, отобразить обычный мессадж бокс) движку потребуется хэндл окна, которому этот месседж бокс принадлежит. Что он сделает? Запросит указатель на интерфейс IActiveScriptSiteWindow и с помощью метода GetWindow получит вожделенный hWnd. Если обнаружится, что объект не поддерживает IActiveScriptSiteWindow или что-нибудь в этом роде, то движок сообщит об ошибке и прекратит выполнение скрипта. Вот именно поэтому нам нужно реализовать этот интерфейс - чтобы увидеть результаты работы.
Реализация объекта.
Как я уже говорил спецификация COM не предусматривает никаких особых стандартов реализации объектов. Мы выберем самый простой путь - наш объект будет содержать:
- указатели на интерфейсы IActiveScriptSite и IActiveScriptSiteWindow ,
- счетчик ссылок (любой хороший объект должен содержать счетчик ссылок или хотя бы делать вид, что содержит ;)
Перво-наперво нужно определить, где это все будет храниться. Мы воспользуемся API LocalAlloc и выделим для него немного памяти.
Теперь у нас есть объект - дело за интерфейсами. Сперва реализуем методы IUnknown:
Здесь мы с помощью API IsEqualGUID сверяем переданный нам GUID с эталонным и если они совпадают, то возвращаем указатель на соответствующий интерфейс. Пояснение здесь требуется только одно - так как наш объект не имеет самостоятельного IUnknown, то в ответ на идентификатор 00000000-0000-0000-0c00000000000046h (GUID IUnknown) мы вернем указатель на IActiveScriptSite, что в данном случае одно и тоже.
Тут вообще комментариев не требуются ;)
Наконец, последний метод - Release - он уменьшает значение счетчика до тех пор, пока оно не станет равным 0, затем память освобождается с помощью LocalFree.
Теперь остается имплементировать следующие методы:
• GetLCID
• GetItemInfo
• GetDocVersionString
• OnScriptTerminate
• OnStateChange
• OnScriptError
• OnEnterScript
• OnLeaveScript
• GetWindow
• EnableModeless
Как видите, их довольно много, однако спешу вас обрадовать - не все из них требуется реализовывать полностью. Например, если вы не планируете какой-либо особой реакции своего приложения на начало исполнения скрипта можно вполне обойтись такой реализацией OnScriptEnter:
Или например, если вы хотите доверить движку пользоваться для вывода текста установками по умолчанию, то можно GetLCID реализовать так:
На такой манер можно написать все методы IActiveScriptSite, что мы и сделаем.
Только в метод OnScriptError (угадайте в какой ситуации он вызывается;)) мы кое-что добавим:
Теперь при обнаружение ошибки в скрипте будет появляться окно с соответствующим сообщением.
OK, с IActiveScriptSite вроде разобрались - настала очередь IActiveScriptSiteWindow. Тут будет проще - нужно написать все два метода.
Так как оба эти интерфейса принадлежат одному объекту, то пусть используют одни и те же стандартные методы. Обе Vtable разместим в сегменте данных, они будут такими:
Ну и напоследок поместим указатели на интерфейсы в выделенной для объекта памяти:
Все! Наш объект готов, методы имплементированы, осталось только подготовить и запустить скрипт.
Подготовка.
Что же скрывается за словом "подготовить"? Ну во-первых, конечно же открыть файл со скриптом (если вы помните, его имя мы получаем при помощи GetOpenFileName). Открываем как обычно, используя API CreateFile:
Кроме этого нам нужен его размер:
Вычислим сколько памяти нужно выделить (зачем умножать на 2 объясню чуть позже):
Выделяем память при помощи VirtualAlloc:
Первые FileSize байт будут заняты содержимым файла, остальные пока свободны:
За ненадобностью закрываем файл.
Вот теперь раскажу зачем была выделена дополнительная память. Дело в том, что сейчас наш скрипт в памяти представляет собой обычную ASCII-последовательность, а VBScript engine оперирует со строками в формате Wide-Character (т.е. каждый символ занимает слово, а не байт). Поэтому наш скрипт еще предстоит конвертировать, что проще всего сделать с помощью MultiByteToWideChar:
Запуск.
В этом разделе мы рассмотрим как инициализировать движок и передать ему скрипт.
Во-первых нужно увеличить значение счетчика нашего объекта, чтобы он не уничтожился раньше времени ;)
Далее скажем IActiveScript, что использовать в качестве IActiveScriptSite необходимо реализованный нами интерфейс, для чего используем метод SetScriptSite, передав ему соответствующий указатель:
Теперь инициализируем движок с помощью метода InitNew интерфейса IActiveScriptParse:
Загружаем скрипт, используя метод ParseScriptText. У этого метода куча аргументов, но в данном случае мы можем заменить их нулями. Хотя последний, конечно, не желательно, но я, лентяй этакий, поленился найти описание структуры EXCEPINFO и добавить его в заголовочный файл ;)))
После этого движоку будет загружен исходный код скрипта, но выполняться он не будет, до тех пор, пока движок не получит от нас соответствующей команды. Это объясняется тем, что движок сейчас пребывает не в том состоянии. Всего состояний 6, вот они:
Собственно, названия говорят сами за себя, отмечу лишь, что для нас наиболее важно состояние SCRIPTSTATE_CONNECTED - именно оно заставит выполняться загруженный скрипт, поэтому, пользуясь методом SetScriptState, говорим движку, что пора бы уже исполнить чертов скрипт:
Ну вот мы заставили выполниться скрипт, теперь дело осталось за малым - правила хорошего тона требуют, чтобы мы по завершении работы прибрали за собой весь мусор. Давайте сделаем это в процедуре диалогового окна.
Надеюсь, коментарии излишни ;)))?
Код приложения
На сегодня все :).
Файл (находится в архиве wasm_files.zip: files/0299/runscript.zip) к статье.
Автор: Hangatyr
Дата: 2004-02-24
Введение
Если вы помните, в предыдущей статье было рассказано об основах управления скриптовыми движками, в частности о том, как заставить выполняться простейший скрипт. В том примере было мало интересного - скрипт жил сам по себе и, отработав, просто возвращал управление основной программе. Сейчас настало время рассмотреть более полезные техники, а именно, как передать скрипту какие-нибудь параметры и наоборот - получить от него информацию (например, о результатах работы). В качестве иллюстрации рассмотрим такой пример:
Сделаем так, чтобы текст в EditBox’е можно было изменять из скрипта.
В прошлый раз я говорил о том, что необходимым условием для использования COM-объекта является знание структуры его интерфейсов. Однако далеко не всегда такое возможно, как например в нашем случае. Например, так будет выглядеть скрипт, устанавливающий содержимое контрола Edit равным "some text":
Edit1 - это имя нашего объекта, а Text - свойство, подлежащее установке. Ясно, что никаких данных о структуре интерфейса из этого извлечь нельзя, поэтому нужно располагать некоторым средством, позволяющим вызывать методы по их именам. Такое средство есть, в COM оно известно, как "позднее связывание" (late binding).
LATE BINDING.
Скажу сразу, что здесь мы рассмотрим только тот минимум, что необходим для работы. Как уже было сказано выше, позднее связывание применяется в тех случаях, когда по каким-либо причинам невозможно (или неудобно) предоставить информацию о структуре интерфейса.
Выходом является использование интерфейса IDispatch , который возволяет вызвать нужную процедуру по ее имени. Он содержит следующие методы:
• GetTypeInfoCount
• GetTypeInfo
• GetIDsOfNames
• Invoke
(нет необходимости говорить о том, что IDispatch тоже наследуется от IUnknown).
Из этих методов нам интересны два последних, обычно их использование выглядит так: сначала методу GetIDsOfNames передается массив с адресами имен нужного метода (свойства) и его параметров, он этот массив просматривает и устанавливает соответствие между именем и некоторым числом, представляющим собой уникальный (в пределах интефейса) ID (обычно говорят “DISPID”) данного элемента. Далее этот DISPID передается методу Invoke, который и производит вызов процедуры.
Имя объекта
С именем объекта все гораздо проще – достаточно указать движку, что за именем “Edit1” скрывается объект.
Делается это при помощи вызова IActiveScript::AddNamedItem.
pstrName– указатель на имя в формате WideCharacter. dwFlags может принимать разные значения, в зависимости от поставленной задачи, мы укажем флаг SCRIPTITEM_ISVISIBLE, показывающий, что pstrName – это имя объекта и мы предоставляем средства для доступа к его методам и свойствам.
Теперь, когда движок встретит конструкцию Edit1.Method он вызовет метод IActiveScriptSite::GetItemInfo, чтобы получить интерфейс IDispatch, который контролирует данный объект.
• SCRIPTINFO_IUNKNOWN – запрашивается IUnknown
• SCRIPTINFO_ITYPEINFO – запрашивается ITypeInfo
ppunkItem, ppTypeInfo– адреса переменных, в которые будут помещены указатели на интерфейсы. Здесь есть один момент, который заслуживает внимания – дело в том, что вышеописанный IDispatch– не едиственный способ осуществить связывание имен. В качестве альтернативы может использоваться интерфейс ITypeInfo, но мы не будем его реализовывать и все сделаем через IDispatch, поэтому если наш метод GetItemInfo получает параметр dwReturnMask с установленным SCRIPTINFO_ITYPEINFO, он должен будет вернуть 0 в ppTypeInfo.
Теперь, чтобы вызвать нужный метод движок предпримет следующие действия:
1. Использует метод QueryInterface, полученного IUnknown для получения указателя на IDispatch.
2. С помощью GetIDsOfNames преобразует имена методов (свойств) в их идентификаторы.
3. Вызовет нужный код с помощью Invoke
Следовательно, первое, что нам нужно сделать – подправить метод IUnknown::QueryInterface :
Теперь QueryInterface способен воспринимать GUID IDispatch
Методы GetTypeInfoCount и GetTypeInfo мы здесь рассматривать не будем – заменим их чем-нибудь вроде этого:
А вот без Invoke и GetIDsOfNames не обойтись.
riid– reserved (всегда 0). rgszNames– указатель на массив указателей на строки, содержащие имена (первый представляет собой имя метода/свойства, следующие - имена параметров). cNames– количество элементов массива. rgDispId– указатель на массив, в который будут помещены ID, соответствующие именам из rgszNames. Если имя не опознано, то в соответствующий элемент массива rgDispId должно быть помещено значение -1. lcid нам не понадобится, т.к. предполагаем, что имена будут только на английском.
Вот примерная (и не совсем корректная) реализация:
Позволю себе сделать небольшое отступление, перед тем, как привести исходный код метода Invoke. Дело в том, что IDispatch представляет из себя только диспетчер, который вызывает нужную процедуру в зависимости от переданного DISPID, поэтому нам нужно написать код, устанавливающий текст в EditBox’е (правда, текст этот надо сначала привести в божеский вид):
Теперь займемся самим методом IDispatch::Invoke
dispIdMember– вызываемый ID (в нашем случае 1). riid - Reserved. Должен быть IID_NULL. wFlags может принимать значения:
• DISPATCH_METHOD
• DISPATCH_PROPERTYGET
• DISPATCH_PROPERTYPUT (в нашем случае будет именно это значение)
pDispParams– указатель на структуру DISPPARAMS , через которую передаются параметры.
Так как параметр нам передается всего один (строка), то достаточно разобрать только rgvarg. Единственная проблема – элемент этого массива – указатель не на саму строку, а на структуру VARIANTARG:
Как видите, сам указатель находится по смещению +08 от начала структуры.
Вот теперь можно привести код Invoke:
Код приложения
Продолжение ожидается...
Файл к статье (находится в архиве wasm_files.zip: files/0305/runscript2.zip)
Автор: Roustem
Дата: 2006-12-01
wasm_files.zip: files/recovered/443/comkit1.rar)
Технология COM для многих программистов так и остается желанным, но слишком дорогим и поэтому недоступным ресурсом. Лишь беглый взгляд на все это нагромождение объектов, интерфейсов, правил их взаимодействия, отягощенный способами их реализации на том или ином языке и громоздкими вспомогательными конструкциями тех или иных сред разработки, призванными "облегчить" использование COM, способен надолго отбить охоту заниматься этим вопросом. А тот счастливчик, кому все же удалось продраться сквозь эти дебри и который вроде начал использовать объекты COM в своих программах, зачастую оказывается совершенно беспомощным вне своей привычной среды программирования.
В чем-то подобной этой ситуации оказался в свое время и автор этих строк, за тем разве исключением, что ему так и не удалось продраться через все эти услужливо придуманные высокоуровневые конструкции. Двигаясь вместо этого с противоположной стороны, я вдруг с удивлением обнаружил, что казавшаяся ранее неприступной преграда начинает отступать, если выкинуть изрядную долю отягощающего хлама. Проблема с COM не в том, что эта технология сложна сама по себе или что она использует какие-то неизвестные доселе принципы. Сами используемые элементы как раз просты и обыкновенны, но их много и они перемешаны со множеством других вещей, не имеющих отношения к COM, и все это приводит к тому, что суть COM теряется и растворяется в этой массе. В этой статье (вернее, серии из трех статей, в соответствии с названием) я попытаюсь описать мои собственные эксперименты и тот путь, который я прошел в надежде, что это может пригодиться кому-нибудь еще .
Предполагается, что читатель уже знаком или хотя бы слышал об основных концепциях COM. Здесь не будут описываться модели компонентного программирования, принципы инкапсуляции, полиморфизма, наследования и т.п. - разве что они будут упомянуты мимоходом. Вместо этого будет предложен подход с точки зрения низкоуровневого программирования, не отягощенного теоретическими абстракциями - своего рода "вид снизу" на архитектуру COM. Возможно, больше всего эти статьи подойдут тем, кто не раз начинал и бросал изучение COM, не справившись и изобилием разнородной информации, но все же не оставил желания разобраться в существе и механизмах этой технологии, а также тем, кто работает с COM на высоком уровне, но хотел бы заглянуть "за кулисы".
В качестве примера рассматриваются несколько утилит, созданных с использованием пакета MASM32. Предполагается, что читатель умеет работать с ним - вопросы создания графических Win32-приложений здесь вообще не будут рассматриваться. (Желающие могут обратиться к обучалкам Iczelion'а; в частности, хорошенько просмотрите раздел о диалоговых окнах - главы 10 и 11.) Более того, исходный код содержит некоторую мешанину - высокоуровневые конструкции MASM (.IF-.ELSE, INVOKE и т.д.) используются для "обыкновенного" каркаса Win32-приложения, а элементы COM реализованы на самом низком уровне - например, в качестве виртуальных таблиц используются даже не структуры (не говоря уже о макросах), а ряд последовательных значений. Это сделано намеренно, чтобы акцентировать внимание именно на имеющих отношение к COM деталях и дать возможность "почувствовать" их и "пощупать руками", по возможности не зацикливаясь на Win32-программировании вообще.
COM и реестр
Ну что ж, пора покончить со вступлениями и перейти к нашим китам. Одна из важнейших основ, которая активно используется и без которой невозможна сама инфраструктура COM, - это системная база данных. На платформе Windows в качестве таковой выступает системный реестр. Прежде чем двинуться дальше, придется все же сказать пару слов предупреждения.
Здесь будут описаны эксперименты с изменениями значений в реестре. Следует помнить, что эти операции нужно производить очень аккуратно, поскольку они чреваты большими неприятностями. При порче реестра компьютер перестанет загружаться, и информация на диске может оказаться утраченной. Поэтому настоятельно рекомендуется перед началом манипуляций с реестром создать аварийную загрузочную дискету (если она не была создана до этого), сделать резервную копию всех важных данных на диске (не забыв и про электронную почту с адресной книгой), а также скопировать файлы реестра (для Win9* - USER.DAT и SYSTEM.DAT в каталоге Windows) в отдельную папку. Сложнее обстоит дело с WinNT/2k/XP, установленным в раздел NTFS. Для WinXP нужно хотя бы создать дополнительную точку восстановления.
Это лишь чрезвычайный минимум сведений; рассказ о методах восстановления реестра сам потребовал бы отдельной статьи. Существует серия книг с названиями "Реестр Windows [98, NT, 2000, XP и др.]", в которых говорится и о методах восстановления реестра; в случае необходимости следует обратиться именно к ним.
Вернемся к нашим китам. Давайте посмотрим на несколько небольших примеров. Если на вашей системе установлен MS Excel, вы можете создать такой файл с расширением .vbs и запустить его:
Если установлен Word XP, то можно запустить другой файл .vbs:
Если при установке MS Office был установлен элемент управления "Календарь", можно создать и просмотресть в браузере такой html-файл:
[Кстати, если этот элемент управления действительно установлен на вашем компьютере, вы можете увидеть его здесь под этим абзацем, если читаете статью в IE ]
Вы, наверное, обратили внимание на постоянное повторение "если". Это неотъемлемое свойство компонентного ПО: к сожалению, никогда нельзя быть на 100% уверенным в том, что нужный компонент будет присутствовать на платформе пользователя. К тому же, простого копирования файлов для запусков компонентов недостаточно. Программы должны быть установлены либо с использованием setup, либо отдельной регистрацией компонентов или созданием соответствующих записей в реестре вручную.
После этого становится возможным обращение к компонентам по именам. В нашем случае это были соответственно "Excel.Application", "Word.Application" и "CLSID:8E27C92B-1264-101C-8A2F-040224009C02". Вся эта и другая относящаяся к COM/OLE/ActiveX информация хранится в разделе реестра "HKEY_LOCAL_MACHINE\Software\CLASSES". Этот раздел настолько важен, что для него был создан алиас под видом отдельного корневого раздела реестра "HKEY_CLASSES_ROOT".
Рис. 1. Редактор реестра.
Структура информации о COM в реестре
Теперь самое время запустить редактор реестра (набрав в командной строке "regedit"; см. рис. 1) и начать знакомиться с рассматриваемыми вопросами на практике. Относящиеся к COM данные объединяются в 5 групп, для большинства из которых предусмотрены соответствующие разделы реестра: ProgID, CLSID, TypeLib, Interface, AppID. В качестве раздела для ProgID выступает сам корневой раздел "HKEY_CLASSES_ROOT". Вот здесь-то мы и можем обнаружить те самые имена "Excel.Application", "Word.Application", которые мы использовали ранее в скриптах, наряду с расширениями файлов и оставшимися 4 разделами для COM.
ProgID - это так называемый программный идентификатор, он является на самом деле лишь "дружественной для пользователя" меткой "настоящего" имени компонента - CLSID. Считается, что ProgID не способен обеспечить подлинной глобальной уникальности имени, особенно в распределенной межсетевой среде, поэтому в последнем случае в качестве идентификаторов компонентов должны использоваться исключительно CLSID. Но на локальной машине, особенно в скриптах, ProgID широко используется. Однако в любом случае для идентификации компонента используется его CLSID; для этой цели между ключами CLSID и ProgID компонента установлены перекрестные ссылки.
Рассмотрим, например, ключ "Excel.Application". Он имеет подключ CLSID, значение по умолчанию которого и является искомым CLSID в строковом представлении. Это значит, что в разделе "HKEY_CLASSES_ROOT\CLSID" имеется соответствующий ключ, содержащий всю необходимую для загрузки компонента информацию. Наверняка вы обратили внимание и на то, что рядом с ключом "Excel.Application" имеется еще один такой же ключ, только с цифрой в конце (на разных машинах она может быть разной; у меня, например, "Excel.Application.5"); а сам ключ содержит также другой подключ - CurVer. На самом деле именно "Excel.Application.5" и является ProgID, а "Excel.Application" называется VersionIndependentProgID - "независимый от версии идентификатор прогаммы" (именно такие подключи для перекрестных ссылок вы найдете в разделе "HKEY_CLASSES_ROOT\CLSID" для соотвествующего компонента). Таким образом, в скрипте можно не указывать конкретную версию установленного компонента; а если со временем был сделан апгрейд, старые скрипты будут успешно работать с новыми версиями, если в качестве имен объектов они использовали VersionIndependentProgID. Для получения одного ключа из другого система COM предоставляет вспомогательные функции API CLSIDFromProgID и ProgIDFromCLSID.
Чтобы получше впитать в себя эту теорию, можно слегка похулиганить (не забывая, однако, сделанного ранее предупреждения). Убедимся, что "настоящее" имя компонента - это действительно CLSID. Для этого создадим новый ключ в разделе "HKEY_CLASSES_ROOT" и назовем его для разнообразия, скажем, собственным именем. Затем под этим ключем создаем подключ с именем "CLSID". Скопируем значение подключа CLSID для ProgID "Excel.Application" и вставим его в качестве значения по умолчанию нашего вновь созданного CLSID. А теперь слегка перепишем наш скрипт:
Естественно, вместо "MyName" у вас должно быть то имя, которое вы выбрали для своего ProgID. Если все было сделано правильно, теперь Excel послушно "откликается" на новое имя.
Утилита для ProgID
Копаясь в реестре, можно обнаружить множество интересных вещей. Однако, ручной поиск по перекрестным ссылкам, особенно если компонентов очень много, весьма утомителен. Сочетая приятное с полезным, создадим для наших поисков небольшую утилиту, которая будет переводить данный ProgID компонента в его CLSID и наоборот.
Рис.2. Интерфейс утилиты COM_1
Дизайн пользовательского интерфейса утилиты приведен на рис. 2. Он реализуется следующим файлом ресурсов (COM_1.rc):
Исходный код программы содержится в файле COM_1.asm. Начало стандартное; функции COM API содержатся в OLE32.dll, поэтому необходимо включить файлы для поддержки этого модуля.
Утилита реализована в виде модального диалогового окна, создаваемого из шаблона ресурса:
Алгоритм работы следующий. При нажатии кнопки "Get ProgID" окно для ProgID очищается и считывается текст окна для CLSID.
Если текста нет - вывести сообщение с предложением его ввести:
Здесь нас ожидает небольшой сюрприз - в COM используются строки в формате Unicode. Поэтому придется преобразовать текст в буфере buf с помощью функции MultiByteToWideChar. Эта функция принимает 6 параметров:
• кодовая страница преобразуемого текста (в нашем случае - ANSI, параметр CP_ACP);
• флаги, указывающие на способ преобразования сложных композитных символов; нам это не требуется - оставляем 0;
• адрес буфера с преобразуемой строкой;
• число символов в преобразуемой строке; если -1, строка заканчивается нулем и длина строки определяется автоматически;
• адрес буфера для преобразованной строки;
• размер буфера для преобразованной строки.
Еще одно затруднение. Функция ProgIDFromCLSID принимает в качестве аргумента адрес структуры с числовым представлением CLSID, а не с его строковым представлением. Подробнее этот нюанс мы обсудим в разделе о CLSID, а сейчас используем для преобразования строкового представления в числовой еще одну вспомогательную функцию COM API - CLSIDFromString (где cls - оставленный под структуру CLSID буфер размером 16 байт):
Мы получили в bufaddr строковое представление ProgID в формате Unicode, теперь нужно преобразовать его обратно в ANSI с помощью функции WideCharToMultiByte ("напарницей" MultiByteToWideChar). Она принимает 8 аргументов:
• кодовая страница, в которую нужно преобразовать строку Unicode; в нашем случае - снова CP_ACP;
• флаги, указывающие способ обработки неотображаемых символов. Нам это не требуется, оставляем 0;
• адрес строки Unicode;
• число символов в строке Uinicode. Если -1, строка считается завершающейся нулями и ее длина определяется автоматически;
• адрес буфера для преобразованной строки;
• размер буфера для преобразованной строки;
• символ по умолчанию - нам не нужно, оставляем 0;
• флаги, указывающие на способ использования символа по умолчанию - 0.
Дальше - блок обработки ошибки функции CLSIDFromString, что рассматривается как неправильный формат введенной строки CLSID:
Блок обработки нажатия на кнопку "Get ProgID" завершен. Сходным же образом обрабатывается нажатие кнопки "Get CLSID".
На этом обработка сообщений диалогового окна заканчивается:
Файлы с исходным кодом данной утилиты (COM_1.rc и COM_1.asm, а также makefile) находятся в каталоге COM_1 архива ComKit1.rar. Makefile написан в предположении, что пакет MASM32 установлен в каталоге \masm32 на текущем диске; если это не так, необходимо его отредактировать.
Раздел CLSID
Вся основная информация о компонентах размещается в разделе реестра "HKEY_CLASSES_ROOT\CLSID". Для каждого компонента создается отдельный ключ, в качестве имени которого выступает строковое представление его CLSID. Как отмечалось выше, CLSID (как и другие виды GUID, например, идентификаторы интерфейсов (IID) или библиотеки типов) имеет две формы представления: числовую и строковую. Числовая форма представляет собой 128-битное значение. В принципе это значение можно было бы разместить, скажем, в регистре XMM; однако COM создавалась еще во времена 16-разрядных машин, когда ни о каких XMM-регистрах и не помышляли. Поэтому для представления этого 128-битного значения была использована структура следующего вида:
В реестре же для представления GUID используется строка такого формата:
где х обозначает 16-ричную цифру (0-F), а фигурные скобки и дефисы должны присутствовать на своих местах без всяких разделяющих пробелов. На самом деле, эта запись может послужить источником путаницы: обратите внимание, что блок цифр для поля Data4 в строковой записи разделен на две части в 4 и 12 шестнадцатеричных цифр, и часть в 4 цифры можно спутать с предыдущими WORD-значениями. Первое DWORD и два последующих WORD значения записываются в строковом представлении, как обычные числа, т.е. старшие байты идут вначале, тогда как третий "WORD" (первые 2 байта поля Data4) записывается в порядке "little-endian" - вначале идет младший байт.
Как мы уже видели в коде первой утилиты, для преобразования строковой формы представления CLSID в числовую и обратно используются соотвтественно функции CLSIDFromString и StringFromCLSID. Существуют варианты и для других типов GUID - StringFromIID, IIDFromString, StringFromGUID2.
Ключ компонента CLSID содержит, в свою очередь, множество подключей. С двумя из них - ProgID и VersionIndependentProgID - мы уже познакомились. Стоит упомянуть лишь о том, что у компонента не обязательно должно присутствовать ProgID.
Прежде, чем двинуться дальше в изучении раздела CLSID, нам понадобится еще одна небольшая утилита - универсальный клиент COM. Пользовательский интерфейс ее приведен на рис. 3. Этот клиент позволяет загружать объект COM, CLSID которого вводится в первое окно редактирования, и запрашивает у него указатель на интерфейс, IID которого содержится во втором окне редактирования. Тип сервера указывается набором флажков опций (одновременно может быть указано несколько типов). Кнопка IUnknown позволяет отобразить во втором окне редактирования IID часто употребляемого интерфейса с тем же названием.
Рис.3. Интерфейс утилиты COM_2
Вот соответствующий файл ресурсов (COM_2.rc):
Чтобы не выписывать каждый раз стандартные define'ы, целесообразно скопировать файл "resource.h" из 10 урока обучалки Iczelion'а в каталог "Include" пакета MASM32, а затем вставлять в rc-файлы соответствующую ссылку, как это сделано в данном случае.
Реализация в файле COM_2.asm:
Поскольку на этот раз нам необходимо задействовать библиотеку COM, нужно также вызвать функцию CoInitialize. При завершении программы необходимо соответственно вызвать функцию CoUninitialize.
"Ядром" данной утилиты является использование функции CoCreateInstance, которая делает всю работу - локализует соответствующий объект COM, загружает его, запрашивает указанный интерфейс и возвращает указатель на него. Значительная часть кода обработки сообщения WM_COMMAND сводится к сбору данных для передачи в качестве параметров функции CoCreateInstance и проверке введенных значений. CoCreateInstance принимает 5 аргументов:
• адрес структуры, содержащей CLSID запрашиваемого объекта (мы получаем это значение в первом окне редактирования);
• указатель на так называемый внешний IUnknown, если объект агрегируется в состав другого объекта. Если агрегирование не применяется (как в нашем случае), значение аргумента равно 0;
• контекст создания объекта: флаги, указывающие на то, является ли сервер объекта внутрипроцессным, локальным, удаленным или это внутрипроцессный обработчик (данный флаг мы вычисляем на основе проверки состояния флажков опций);
• адрес структуры с IID интерфейса, указатель на который мы хотим получить. Значение IID мы получаем во втором окне редактирования;
• адрес переменной, в которой будет возвращен указатель на запрашиваемый нами интерфейс (или 0, если этот интерфейс не поддерживается).
При нажатии на кнопку IUnknown во второе окно редактирования копируется IID для соответствующего интерфейса (это значение "вшито" в код в виде строки szUnk). Итак, обработка команд:
Теперь необходимые параметры собраны: CLSID находится в cls, IID - в iid, тип сервера - в ctx. Функция CoCreateInstance находит объект COM с данным CLSID и создает его экземпляр, запрашивая у него указатель на интерфейс IID. Если объект реализует интерфейс с данным IID, он помещает указатель на него в переменную, адрес которой был передан CoCreateInstance в последнем параметре, а сама функция возвращает S_OK. Если объект не поддерживает данный интерфейс или объект с данным CLSID не зарегистрирован в реестре, или зарегистрированный тип сервера не указан в флаге типа сервера, возвращается сообщение об ошибке.
На этом вся "полезная" работа нашего приложения завершается - мы освобождаем объект. Делать это придется уже средствами COM, т.е. с использованием полученного указателя интерфейса. Для этого через полученный указатель интерфейса (pUnk) необходимо вызвать метод Release интерфейса IUnknown (абсолютно все интерфейсы COM наследуются от IUnknown, поэтому метод Release можно вызвать для любого объекта COM одним и тем же способом).
Указатель на интерфейс объекта представляет собой адрес некоей структуры, в которой содержатся данные с состоянием экземпляра объекта. Доступ к ним возможен лишь косвенно, посредством вызова методов соответствующего интерфейса, поэтому каждый метод получает в качестве первого параметра адрес этой структуры (т.н. указатель "this", в терминологии языка С++). Об этой структуре можно сказать лишь то, что первое ее поле является указателем на другую структуру - "виртуальную таблицу", содержащую адреса процедур, реализующих методы интерфейса. Для вызова того или иного метода необходимо найти адрес его реализации по заранее известному и постоянному смещению в виртуальной таблице. Подробнее "кухню" этого вопроса мы разберем во второй статье, а пока просто приведем код:
На этом обработка WM_COMMAND и любых других сообщений закончена.
Теперь можно продолжить эксперименты с реестром. Важнейшими подключами раздела "HKEY_CLASSES_ROOT\CLSID" является ряд подключей, позволяющих определить местонахождение сервера в системе: InprocServer, InprocServer32, InprocHandler, InprocHandler32, LocalServer, LocalServer32. Каждый тип сервера представлен двумя подключами; суффикс "32" означает, что сервер 32-разрядный, подключ без этого суффикса указывает на то, что сервер 16-разрядный (для совместимости со старыми компонентами). Случай удаленного (remoute) сервера обрабатывается особым образом; об этом мы поговорим в разделе, посвященном AppID.
Начнем хулиганить. При создании новых интерфейсов и компонентов для получения уникальных GUID используются специальные утилиты типа guidgen и т.п. Microsoft зарезервировала для собственного употребления большой интервал удобных GUID-ов с наборами нулей; мы же поступим еще круче - используем GUID'ы типа {00000000-0000-0000-0000-000000000001}. Зачем нам париться, выискивая свой компонент среди массы цифр, когда можно удобно разместить его в самом начале раздела? Можно было бы (и вначале автор так и поступал) использовать и GUID со всеми нулями, но это специальный зарезервированный GUID_NULL, употребляющийся в особых случаях; во избежание неприятностей лучше оставить его в покое.
Создадим в разделе "HKEY_CLASSES_ROOT\CLSID" ключ {00000000-0000-0000-0000-000000000001}. Этот ключ может иметь значение по умолчанию, которое является описанием компонента, предназначенным для пользователя. Обратите внимание, это не то же самое, что ProgID (хотя некоторые авторы компонентов используют в качестве описания ProgID). Можно вставить сюда какую-нибудь строку, например, "Мой любимый компонент". Далее, создаем подключ с именем "LocalServer32". А вот значение по умолчанию этого подключа как раз и содержит полный путь к файлу сервера. Запишем сюда "c:\windows\calc.exe" (нужно указать каталог windows на вашей машине). Теперь запустим наш клиент (COM_2.exe), наберем CLSID, нажмем на IUnknown, в качестве сервера выбираем "Local server", жмем "Connect" и... Калькулятор можно закрыть. А наш клиент, похоже, завис - но к этому надо было быть готовым, поскольку калькулятор понятия не имеет о том, что он вдруг стал компонентом COM; тогда как система COM все еще дожидается от него ответа - наш клиент в это время "сидит внутри" CoCreateInstance. Впрочем, примерно через минуту она вернет ошибку таймаута, и наш клиент выдаст соответствующее окно сообщения.
Я не буду описывать здесь все прочие эксперименты - путь указан, утилиты есть; экспериментируйте! Технология COM постигается лишь на практике. Только не забудьте в пылу увлечения предупреждение об аккуратности работы с реестром.
Рассмотрим другие подключи. Важными являются TreatAs и AutoTreatAs, поскольку они позволяют сменить сервер компонента. Если в ключе с данным CLSID имеется подключ TreatAs (значение по умолчанию которого содержит другой CLSID), то будет создан объект с этим другим CLSID, независимо от наличия подключей InprocServer, LocalServer и т.д. Проделаем такой эксперимент. Создадим подключ "TreatAs" в нашем ключе {00000000-0000-0000-0000-000000000001}. В качестве значения вставим CLSID для компонента Excel.Application (воспользовавшись для преобразования ProgID утилитой COM_1.exe). Если теперь с помощью COM_2.exe попытаться загрузить наш компонент, будет загружен Excel (правда, он останется скрытым. Чтобы убедиться, что он запущен, придется посмотреть в менеджере задач).
Подключ TreatAs позволяет осуществлять эмуляцию одного сервера другим. Функция CoGetTreatAsClass позволяет получить значение этого ключа, а функция CoTreatAsClass - установить (или удалить) его. Если подключ TreatAs удаляется с помощью функции CoTreatAsClass, эта функция проверяет значение подключа AutoTreatAs. Если ключ с таким именем существует, его значение копируется в подключ TreatAs; если нет, подключ TreatAs вообще удаляется. Подключ же AutoTreatAs можно создавать или удалять только вручную, с использованием функций API реестра. Таким образом, в подключе AutoTreatAs может сохраняться значение предыдущего CLSID, если данный сервер эмулируется сначала одним, а затем другим сервером, обеспечивая своего рода "постоянную" эмуляцию (в отличие от "временной" эмуляции с помощью подключа TreatAs).
Будучи основным источником сведений о компоненте, раздел "HKEY_CLASSES_ROOT\CLSID" содержит подключи с перекрестными ссылками на другие разделы. О подключах ProgID и VersionIndependentProgID мы уже говорили. Подключ TypeLib содержит GUID, который является идентификатором библиотеки типов для данного компонента; соответствующий подключ содержится в разделе "HKEY_CLASSES_ROOT\TypeLib". Подключ AppID содержит GUID, идентифицирующий подключ другого раздела - "HKEY_CLASSES_ROOT\AppID", и указывает на то, что объект является распределенным (DCOM). Подробнее об этих подключах будет сказано в соответствующих разделах.
В разделе CLSID имеется еще множество других подключей; мы не будем рассматривать их все. Упомянем лишь о тех, которые являются своего рода флагами, указывающими на тип компонента. Наличие подключа "Control" указывает, что компонент является элементом управления; "Insertable" - что объект может внедряться в контейнеры OLE; "OLEScript" - объект является исполнителем сценариев (scripting engine); "DocObject" - объект-документ; "Printable" - объект может быть распечатан; "Programmable" - объект является сервером автоматизации (и, соответственно, им можно управлять с помощью скриптов); "Ole1Class" - объект OLE 1.0 (старой версии).
Создадим еще одну небольшую утилиту, которая будет отображать список зарегистрированных в реестре объектов, относящихся к одному из 7 перечисленных в конце предыдущего параграфа типов. Внешний вид приложения показан на рис. 4. Тип объекта можно выбрать в выпадающем списке; после нажатия кнопки "List" в окне списка отображаются описания соответствующих объектов (значения по умолчанию, связанные с тем или иным CLSID). Если описания нет, строка останется пустой.
Рис.4. Интерфейс утилиты COM_3
Для экономии места мы не будем приводить здесь полный код приложения; соответствующие файлы находятся в каталоге COM_3 архива ComKit1.rar. Вместо этого рассмотрим лишь некоторые существенные моменты, имеющие отношение к логике работы программы.
Начинаем с того, что открываем раздел реестра "HKEY_CLASSES_ROOT\CLSID", сохраняя описатель в переменной HKey. При успешном открытии начинается основной цикл по перечислению имеющихся в открытом разделе ключей.
При любой ошибке перечисления цикл прерывается, причем если ошибка не связана с просмотром всех ключей, выводится соответствующее сообщение. Для каждого нового найденного ключа составляются две строки вида: "CLSID\{clsid компонента}" и "CLSID\{clsid компонента}\<тип объекта>", где <тип объекта> означает одну из 7 строк с типом объекта, выбранную из выпадающего списка.
Затем делается попытка открыть ключ реестра "CLSID\{clsid компонента}\<тип объекта>". Успешная попытка означает, что ключ с данным CLSID имеет подключ с выбранным нами именем; в этом случае открываем другой подготовленный ключ ("CLSID\{clsid компонента}") и запрашиваем значение по умолчанию, которое пересылаем в окно списка и переходим к новой итерации:
Раздел Interface
В отличие от остальных разделов, "HKEY_CLASSES_ROOT\Interface" относится не к отдельным компонентам, а к системе в целом. Приведенные здесь данные об интерфейсах используются при стандартном маршалинге. Подключей немного: BaseInterface, NumMethods, ProxyStubCLSID и ProxyStubCLSID32. BaseInterface содержит имя интерфейса, от которого унаследован данный интерфейс; если он не указан, в качестве базового принимается IUnknown. NumMethods содержит число методов в интерфейсе. ProxyStubCLSID(32) подобен InprocServer(32): он содержит полный путь к серверу (dll), реализующему вспомогательные объекты (т.н. представители и заглушки), которые используются системой при маршалинге методов данного интерфейса. Как обычно, суффикс "32" в имени означает 32-разрядный сервер, его отсутствие - 16-разрядный.
Подробное обсуждение маршалинга и связанных с ним проблем выходит за рамки данной статьи; кое-что будет рассказано во второй статье, а здесь приведем описание полезной утилиты, использующей данный раздел реестра. Внешний вид ее приведен на рис. 5. При нажатии кнопки "List" приложение создает экземпляр COM-объекта, CLSID которого указан в окне редактирования. Затем у созданного объекта запрашиваются все возможные интерфейсы, сведения о которых имеются в системном реестре. В окне списка выводятся имена всех интерфейсов, которые реализованы объектом.
Рис.5. Интерфейс утилиты COM_4
Здесь опять приведем лишь ключевые моменты кода, исходные файлы содержатся в каталоге COM_4 архива ComKit1.rar.
Поскольку приложение использует библиотеку COM, при инициализации диалогового окна вызывается процедура CoInitialize, а при его закрытии - соответственно CoUninitialize. При нажатии кнопки "List" окно списка очищается, а из окна редактирования извлекается CLSID уже знакомым нам способом:
Затем создается экземпляр объекта с данным CLSID; в качестве начального интерфейса запрашивается IUnknown (его IID содержится в IUnk), а контекст объекта допускает любой тип сервера:
Если указатель успешно получен (в pUnk), открываем раздел реестра "HKEY_CLASSES_ROOT\Interface" и входим в главный цикл перечисления подключей (т.е. интерфейсов):
Выход из цикла осуществляется, когда функция перечисления возвращает ошибку; причем если это не связано с отсутствием ключей для дальнейшего перечисления, отображается сообщение об ошибке. Каждый новый ключ перечисления (IID интерфейса в строковом виде) преобразуется в числовой вид (если в ходе преобразования происходит ошибка, данный ключ просто игнорируется и цикл продолжается).
А вот теперь нужно запросить у нашего объекта интерфейс, IID которого мы только что получили. Для этого необходимо вызвать метод QueryInterface интерфейса IUnknown, со следующими аргументами:
• указатель на экземпляр текущего объекта ("this");
• адрес структуры с IID запрашиваемого интерфейса;
• адрес переменной, в которой будет возвращен указатель затребованного интерфейса.
Адрес метода QueryInterface располагается в самом начале виртуальной таблицы (со смещением 0):
В случае успешного получения указателя нового интерфейса QueryInterface возвращает S_OK. Нам нужен просто факт поддержки объектом данного интерфейса, он сам не нужен; поэтому мы сразу же освобождаем только что полученный указатель, вызвав через него метод Release:
Одновременно с этим создаем строку вида "Interface\{IID интерфейса}" и открываем соответствующий раздел реестра, запрашивая значение по умолчанию этого раздела (имя интерфейса). Это имя добавляется в окно списка.
В случае, когда QueryInterface или RegOpenKeyEx возвращают код ошибки, данный ключ просто игнорируется, а цикл продолжается дальше.
После выхода из цикла метод Release вызывается также через указатель pUnk интерфейса IUnknown, полученный нами при создании экземпляра объекта (аналогично тому, как это было сделано ранее).
Раздел TypeLib
В разделе "HKEY_CLASSES_ROOT\TypeLib" содержатся ключи, имена которых представляют собой строковую форму идентификаторов (GUID) установленных в системе библиотек типов. На данные ключи ссылаются подключи TypeLib компонентов раздела "HKEY_CLASSES_ROOT\CLSID", но обратных ссылок нет. Библиотеки типов обязательны для компонентов, использующих позднее связывание и автоматизацию; в частности, они широко применяются с элементами управления ActiveX. Остальные компоненты могут и не иметь библиотеки типов.
Каждый ключ раздела TypeLib содержит иерархическую структуру подключей. На первом уровне находятся подключи версии библиотеки типов, представленные в строковой форме major.minor (цифры, соответствующие версии). В разделе версии находятся, в свою очередь, подключи HelpDir (полный путь к файлу справки), Flags (флаг библиотеки типов) и строковое представление локального идентификатора языка (lcid). Ключ <lcid> содержит еще один или два подключа: win16 и/или win32 - полные пути к библиотеке типов для соответствующей платформы.
В качестве примера работы с библиотекой типов рассмотрим еще одно приложение (рис. 6). Диалоговое окно приложения имеет всего один элемент управления - окно просмотра списков. В первом столбце отображаются описания компонентов, а рядом с ними во втором - идентификаторы соответствующих библиотек типов. При двойном щелчке мышью на названии компонента либо отображается общая информация о данном компоненте, содержащаяся в его библиотеке типов, либо (если имеется) открывается файл справки, связанный с данным компонентом.
Рис.6. Интерфейс утилиты COM_5
Приложение работает следующим образом (детали реализации графического интерфейса опущены; полный исходный код содержится в каталоге COM_5 архива ComKit1.rar). При обработке сообщения WM_INITDIALOG открываем раздел реестра "HKEY_CLASSES_ROOT\CLSID", затем входим в главный цикл перечисления содержащихся в нем ключей:
Как и в предыдущей утилите, если RegEnumKeyEx возвращает ошибку, цикл прерывается. Для каждого нового ключа составляются по две строки вида: "CLSID\{clsid компонента}" и "CLSID\{clsid компонента}\TypeLib", затем делается попытка открыть раздел реестра со второй строкой в качеcтве имени.
Успешное открытие ключа TypeLib говорит о том, что для компонента имеется библиотека типов. В этом случае запрашиваем значение ключа "CLSID\{clsid компонента}" и помещаем соответствующую строку в первую колонку окна просмотра списков, а значение ключа "CLSID\{clsid компонента}\TypeLib" (строковое представление идентификатора библиотеки типов) - во вторую колонку:
Двойной щелчок на элементе окна просмотра списка обрабатывается в сообщении WM_NOTIFY. Соответствующий код вынесен в отдельную процедуру FindHelp, причем в регистре ebx передается адрес структуры NMLISTVIEW с информацией об элементе списка, на котором был произведен двойной щелчок:
Процедура FindHelp начинается с проверки того, что щелчок действительно произведен на элементе списка:
Теперь можно скопировать в буфер buf содержимое второй колонки соответствующего элемента (GUID библиотеки типов в текстовом виде).
Из полученного значения составляем название раздела реестра "TypeLib\{GUID библиотеки}" и открываем его.
Нужно обработать не очень удобную форму представления данных для библиотеки типов. Чтобы получить путь к файлу библиотеки типов, необходимо сначала указать версию, а о ней заранее невозможно сказать ничего определенного. Плохо то, что функция для загрузки LoadRegTypeLib требует точного указания старшей (major) версии и отказывается загружать библиотеки с другими версиями. Поэтому придется "вручную" просмотреть подключи с версиями и выделить из имени подключа старшую версию.
Мы получили номер старшей версии; теперь можно обычным способом преобразовать строковое представление GUID в числовое и передать всё функции LoadRegTypeLib, которая принимает следующие аргументы:
• адрес структуры с GUID загружаемой библиотеки;
• старшая версия загружаемой библиотеки (необходимо указать точно; в нашем случае она находится в переменной mjver);
• младшая версия загружаемой библиотеки (здесь можно оставить 0, потому что система загрузит любую младшую версию, превышающую указанную);
• локальный языковой идентификатор (lcid; можно оставить нейтральный - 0);
• адрес переменной, в которой будет возвращен указатель на интерфейс ITypeLib.
Возвращенное значение S_OK говорит о том, что у нас есть действительный указатель на интерфейс ITypeLib. Нас интересует метод GetDocumentation, имеющий следующие аргументы:
• индекс описания типа; если -1, возвращаются данные для самой библиотеки типов (что нам и нужно);
• адрес переменной, в которой будет возвращен указатель на строку типа BSTR с именем запрашиваемого элемента (в нашем случае – самой библиотеки типов);
• адрес переменной, в которой будет возвращен указатель на строку типа BSTR с описанием запрашиваемого элемента;
• адрес переменной, в которой будет возвращен контекстный идентификатор для файла справки;
• адрес переменной, в которой будет возвращен указатель на строку типа BSTR с полным путем к файлу справки.
Если какой-нибудь вид данных не нужен, можно передать в соответствующем аргументе 0. Адрес функции GetDocumentation расположен в виртуальной таблице интерфейса ITypeLib по смещению 24h.
Если по возвращении из метода в переменной HelpFile окажется 0, это значит, что файла справки нет. В этом случае выведем простое окно сообщения с полученными сведениями:
Если же файл справки указан, преобразуем соответствующую строку из Unicode в ANSI и передадим ее адрес в качестве аргумента функции ShellExecute (чтобы иметь возможность загружать как hlp-, так и chm-файлы):
Строки типа BSTR необходимо освободить, во избежание утечки ресурсов:
При ошибке вызова метода GetDocumentation отображаем соответствующее сообщение. В любом случае после этого необходимо освободить указатель интерфейса ITypeLib (pTlib):
Завершают функцию обработки других ошибок:
С помощью данной утилиты можно обнаружить множество интересных вещей. Попробуйте!
Раздел AppID
Раздел реестра «HKEY_CLASSES_ROOT\AppID» совместно с разделом «HKEY_LOCAL_MACHINE\Software\Microsoft\OLE» определяют установки для распределённой системы COM (DCOM).
Распределённая система имеет дело с передачей данных по сети, и перед ней сразу же встают вопросы аутентификации, авторизации и другие проблемы обеспечения безопасности. Общая схема конфигурирования обычно такова: в разделе «HKEY_LOCAL_MACHINE\Software\Microsoft\OLE» описываются значения параметров безопасности по умолчанию. Раздел «HKEY_CLASSES_ROOT\AppID» содержит ключи (GUID), в которых параметры безопасности могут задаваться для отдельных групп компонентов (в этом случае «HKEY_CLASSES_ROOT\CLSID\{clsid компонента}\AppID» содержит ссылку на соответствующий ключ раздела «HKEY_CLASSES_ROOT\AppID»). Значения из раздела AppID имеют преимущество перед соответствующими значениями по умолчанию. Кроме того, параметры безопасности и другие связанные с распределенной системой параметры могут задаваться явным образом при создании компонента с использованием функции CoCreateInstanceEx или ей подобной. В этом случае используются явно заданные значения.
Раздел «HKEY_LOCAL_MACHINE\Software\Microsoft\OLE» может иметь следующие именованные значения:
• EnableDCOM – разрешает (Y или y) или запрещает (N или n) удаленным клиентам запуск компонентов на данной системе;
• DefaultLaunchPermission – определяет список участников (ACL), кто может запускать по умолчанию компоненты на данной машине;
• DefaultAccessPermission – определяет список участников (ACL), кто может по умолчанию получать доступ к запущенным объектам;
• LegacyAuthenticationLevel – устанавливает уровень аутентификации по умолчанию;
• LegacyImpersonationLevel – устанавливает уровень имперсонации по умолчанию;
• LegacyMutualAuthentication – разрешает (Y или y) или запрещает (любое другое значение или отсутствие именованного значения) взаимную аутентификацию;
• LegacySecureReferences – указывает, охраняются (Y или y) или нет (любое другое значение или отсутствие именованного значения) вызовы AddRef и Release.
Ключи «HKEY_CLASSES_ROOT\AppID\{GUID}» могут иметь следующие именованные значения:
• RemoteServerName – имя сервера, на котором должен быть запущен компонент;
• ActivateAtStorage – указывает, что компонент должен быть запущен на той же машине, на которой хранятся данные объекта;
• LocalService – указывает, что компонент реализован в виде Win32-сервиса;
• ServiceParameters – используется совместно с LocalService. Значение этого параметра передается при запуске соответствующего сервиса в виде аргументов командной строки;
• RunAs – позволяет запустить компонент, не являющийся сервисом, от имени определенного пользователя;
• LaunchPermission – определяет список участников (ACL), кто может запустить сервер с данным компонентом;
• AccessPermission – определяет список участников (ACL), кто может получить доступ к объектам данного класса;
• DllSurrogate – содержит полный путь к программе-оболочке (exe), в которой должен быть запущен удаленный внутрипроцессный (dll) сервер;
• AuthenticationLevel – определяет уровень аутентификации для компонента.
Указанные в реестре значения могут быть перекрыты явным вызовом функции CoInitializeSecurity.
Автор: Roustem
Дата: 2006-12-26
wasm_files.zip: files/recovered/444/comkit1.rar)
COM technology remains desired but too expencive and therefore inaccessible resource for many programmers. Just fleeting glance on all that conglomeration of objects, interfaces, rules of their interaction overburdened with implementation techniques in this or that programming language and cumbersome auxiliary constructions intended for "facilitation" of COM using can kill any desire to engage in this matter. And that lucky beggar who succeeded in making his or her way through all this maze and who began as though to use COM objects in his or her own programs often finds himself or herself quite helpless outside of his or her usual programming environment.
The author of this article turned out to be in somewhat similar situation in his time except that he just could not pass through all these helpfully made-up high-level constructions. Moving instead from the opposite side I discovered suddenly that seeming earlier inaccessible barrier begun to step back if one threw away a fairly good part of this overburdening trash. The problem with COM is that not the technology is difficult in itself or that it uses some unknown so far principles. Elements used are just ordinary and simple but there is a great number of them and they are mixed with a lot of other things not related to COM; all this hides and diffuses the essence of COM. In this article (or rather in series of three articles in compliance with the title) I'll try to describe my own experiments and the way I have passed in hope it will be helpful for somebody else.
It is presumed that the reader is familiar with the basic concepts of COM or at least has heard about them. You won't find here descriptions of component programming models, principles of encapsulation, polymorphism, inheritance etc. - unless of only incidentally mentioning. Instead you'll be presented with the low-level programming approach without excess theoretical abstractions - the "bottom view" onto COM architecture in a way. Maybe these articles will best fit to those who repeatedly began and gave up studying COM beeng not able to cope with abundance of heterogeneous information, but who kept desire to understand the essence and machinery of this technology, ant to those who worked with COM on high level but who wanted to look "under hood".
Several utilities created using MASM32 package are examined as examples. It is supposed that the reader is able to work with this package - issues of creating Win32 GUI applications won't be considered here. (Those who wish that can address to Iczelion's tutorials; specifically you must look through the sections about dialog boxes - 10 and 11. Moreover the source code in this article contains some mixture of high-level MASM constructions (.IF-.ELSE, INVOKE etc.) used for "ordinary" skeletons of Win32 applications and of quite low-level implementation of COM elements - for example, not even structures (not to mention macros) but a set of successive values is used in place of virtual tables. It is done intentionally to attract attention just to details relating to COM and to give a chance to "feel" them without drawing away to Win32 programming in general.
COM and registry
So, it's time to give up with preambles and pass on to our whales. One of the most important actively used bases without which COM infrastructure is impossible at all is a system database. The system registry plays this role on Windows platform. Before we advance further it's necessary to say a couple of words of warning.
Experiments with modification of registry values will be described here. You must remember to be utterly cautious making such operations because you may fall in troubles. If the registry becomes corrupted the computer will cease from booting and information on disks may turn out to be lost. Therefore it is strongly recommended to create emergency repair disk (if it wasn't created earlier) before manipulations with the registry, make a backup copy of all important data on hard disks (including email and an address book) as well as backup registry files (for Win9* these are USER.DAT and SYSTEM.DAT in the Windows folder) in a separate folder. It's more complicated for WinNT/2k/XP installed on a NTFS partition. For WinXP it's necessary to create at least one additional recovery point.
It's only the exraordinary minimum of information; the description of registry repair methods would require a separate article in itself. There are series of books devoted to Windows [98, NT, 2000, XP etc.] registries; these are the books that you should address to when necessary.
Coming back to our whales. Let's consider a few small examples. If you have installed MS Excel on your system you can create the following file with the .vbs extension and launch it:
If you have installed Word XP you can launch another .vbs file:
If the control "Calendar" was installed when installing MS Office you can create and examine in your browser the following html-file:
[By the way, if this control is indeed installed on your computer you can see it here below if you are reading the article in IE ]
You probably have noticed the continual repetition of this "if". It's an integral feature of the component software: unfortunately, you can't be sure for 100% that the needed component will be present on a user's platform. Besides it's insufficient simply to copy files for loading components. The programs must be installed either by using setup or by separate registering of components or creating the necessary records in a registry by hand.
After that you can address components by their names. In our case these are "Excel.Application", "Word.Application", and "CLSID:8E27C92B-1264-101C-8A2F-040224009C02". All this and other COM/OLE/ActiveX related information is stored in registry under "HKEY_LOCAL_MACHINE\Software\CLASSES" key. This key is so important that an alias was created for it as the separate root key "HKEY_CLASSES_ROOT".
Fig. 1. Registry editor.
The sturcture of COM related information in the registry
Now it's time to launch the registry editor (by entering "regedit" in the command prompt; see fig. 1) and to begin to examine these questions in practice. COM related data are joined in 5 groups: ProgID, CLSID, TypeLib, Interface, AppID. The majority of them have their own registry keys. The root key "HKEY_CLASSES_ROOT" stands for ProgID section. Here we can find the names "Excel.Application" and "Word.Application" that we had used earlier in our scripts together with the remaining 4 COM sections and with file extensions.
ProgID is so called program identifier, it is in fact only "user friendly" label for the "real" name of a component - CLSID. It is accepted that ProgID cannot ensure the true global uniqueness of the component name especially in the distributed internetwork environment so in the latter case only CLSIDs must be used as component identifiers. But on a local machine ProgID is widely used especially in scripts. However the component's CLSID is used for identification of the component in any case; for that crossreferences are established between CLSID and ProgID keys for the component.
Let's examine the key "Excel.Application" for example. It has a subkey CLSID, the default value of which is the required CLSID in a string representation. It means that "HKEY_CLASSES_ROOT\CLSID" contains the corresponding key storing all necessary information for loading the component. Certainly you have paid attention to another key near "Excel.Application" but with a number at the end (the number may differ on various machines; it is "Excel.Application.5" on my machine, for example). The key itself contains another subkey - CurVer. In fact it's "Excel.Application.5" that is ProgID and "Excel.Application" is so called VersionIndependentProgId - "component identifier, independent from the component version" (exactly these subkeys for crossreferences you can find in "HKEY_CLASSES_ROOT\CLSID" key for the corresponding component). Thus it is possible not to indicate the specific version of an installed component; and if in the course of time the component was upgraded, old scripts would successively work with the new versions if they had used VersionIndependentProgIDs as object names. The COM system has auxiliary funcions CLSIDFromProgID and ProgIDFromCLSID for getting one key using another.
In order to better understand this theory we can have some fun (but not forgetting warnings above). Let's make sure that the "real" name of a component is actually CLSID. For that create a new key under "HKEY_CLASSES_ROOT" and designate it with your own name for variety. Then copy the CLSID value under ProgID "Excel.Application" and paste it as the default value for our newly created CLSID. And now rewrite our script a bit:
Naturally instead of "MyName" you must paste the name chosen for your ProgID. If all Ok Excel now readily responds to the new name.
The utility for ProgID
Examining the registry you can find a great number of interesting thins. Howerer, manual retrieving data following crossreferences is very boring especially when too many components. Combining pleasantness with the profit let's create for our searches a small utility that will translate given ProgID of the component to its CLSID and vice versa.
Fig.2. The user interface of COM_1 utility
The user interface design of the utility is shown in fig.2. It's implemented in the following resource file (COM_1.rc):
The program's source code is in the file COM_1.asm. The beginning is standard; COM API funcions are located in OLE32.dll so you must include files supporting this module.
The utility is implemented as a modal dialog box created from resource template:
The algorithm is like that. On pressing "Get ProgID" button edit control for ProgID is cleared and the CLSID control text is read.
If the string is empty a message suggesting to enter the text is displayed:
A bit of surprise here - COM uses Unicode strings. So we'll have to convert the text in the buffer buf using MultiByteToWideChar function. This function takes 6 parameters:
• code page (in our case - ANSI, the parameter is CP_ACP);
• flags indicating how to translate precomposed or composite wide characters; we don't need it - 0;
• address of string to map;
• number of bytes in string; if -1 the string is null terminated and the length is calculated automatically;
• address of wide-character buffer;
• size of wide-character buffer.
One more complication. The function ProgIDFromCLSID accepts as an argument the address of a structure with the numeric representation of CLSID and not with the string representation. In more detail we'll discuss this nuance in the section about CLSID and now to convert the string representation into numeric one we'll use one more auxiliary COM API function - CLSIDFromString (where cls is a 16 bytes buffer left for CLSID structure):
In bufaddr we've got string representation of ProgID in Unicode format, now we need to convert it back to ANSI using the function WideCharToMultiByte ("twin" of MultiByteToWideChar). It takes 8 arguments:
• code page we need to convert the Unicode string to; in our case - again CP_ACP;
• performance and mapping flags. We don't need them, so leave 0;
• address of Unicode string;
• number of characters in Unicode string. If -1 the string is null-terminated and the length is calculated automatically;
• address of buffer for the translated string;
• size of buffer for the translated string;
• address of default symbol - we don't need it, leave 0;
• address of flags for default symbol - 0.
Further the block for handling errors of function CLSIDFromString goes which are considered as a wrong format of an entered CLSID string:
The block handling pressing "Get ProgID" button is complete. Pressing "Get CLSID" button is handled in a similar way.
After that the processing of dialog box messages is over:
The files with sources of this utility (COM_1.rc, COM_1.asm, and makefile) are located in COM_1 folder of ComKit1.rar. The makefile is written with the assumption that MASM32 is installed in \masm32 folder on a current disk; if not it's necessary to edit the makefile.
CLSID key
All primary information about components is stored under the registry key "HKEY_CLASSES_ROOT\CLSID". A separate subkey is created for each component, the subkey name being a string representation of component's CLSID. As was previously mentioned CLSID (like other GUIDs, for example, interface identifiers (IID) or type libraries) has two representations: a numeric one and a string one. The numeric form is presented as a 128-bit value. Theoretically this value could be stored, say, in a XMM register; however COM was created in time of 16-bit machines when nobody knew about any XMM-registers. So the following structure was used for representation of this 128-bit value:
But in the registry a string of the following format is used for representation of GUID:
where x stands for a 16-bit digit (0-F), and braces and hyphens must be present in place without any delimiting spaces. Actually such a record can cause confusion: note that the block of digits for Data4 field in the string representation is divided into two parts of 4 and 12 hexadecimal digits, and the part with 4 digits may be confused with the previous WORD-values. The first DWORD and the two following WORD values are recorded in the string representation as usual numbers, i.e. high bytes go first, whereas the third "WORD" (the first two bytes of Data4 field) is recorded in the "little-endian" order - the low byte goes first.
As we've already seen in the first utility source the functions CLSIDFromString and StringFromCLSID are used for converting CLSID from the string representation into the numeric one and vice versa correspondingly. There are choices for other GUID types - StringFromIID, IIDFromString, StringFromGUID2.
CLSID key stores in turn a number of subkeys. We know already two of them - ProgID and VersionIndependentProgID. It's worth mentioning only that the presence of ProgID for a component is not mandatory.
Before we advance in examining CLSID section we'll need one more utility - a universal COM client. Its user interface is showed on fig.3. This client allows to load COM object with CLSID entered in the first edit control and to acquire the interface pointer with IID entered in the second edit control. The server type is indicated with a set of checkboxes (it's possible to check more than one type at once). IUnknown button allows to display the IID of the often used interface with the same name in the second edit control.
Fig.3. The user interface of COM_2
Here's the corresponding resource file (COM_2.rc):
So as not to write out standard defines every time it's advisable to copy "resource.h" from the 10th lesson of Iczelion into "Include" folder of MASM32 and then put into rc-file the proper reference as it's done in this case.
The implementation is in COM_2.asm:
Since this time we need to enable the COM library, it's also necessary to call the function CoInitialize. In the end of the program it's necessary to call CoUninitialize correspondingly.
The core of this utility is made up of CoCreateInstance function that makes all work - locates the proper COM object, loads it, requests the indicated interface and returns a pointer to it. The bulk of code handling WM_COMMAND collects data for CoCreateInstance for passing as its arguments and checks the entered values. CoCreateInstance takes 5 arguments:
• address of structure containing CLSID of the requested object (we get this value in the first edit control);
• pointer to the so called outer IUnknown in the case if an object is being created as part of an aggregate. If not (as in our case) the value is 0;
• context for running code: flags indicating whether an object server is inprocess, local, remoute or it is an inprocess handler (this value is calculated basing on checking the state of checkboxes);
• address of structure containing IID of the interface which pointer we want to get to. The IID value we get in the second edit contol;
• address of pointer variable that receives the requested interface pointer (or 0, if the interface is not implemented).
When pressing IUnknown button IID of the corresponding interface is copied into the second edit control (this value is hardcoded as szUnk string). So, here's handling of commands:
Now the necessary parameters are collected: CLSID is in cls, IID - in iid, the server type - in ctx. CoCreateInstance locates COM object with the given CLSID and instantiates it, requesting pointer to IID on it. If the object implements an interface with the given IID, it places the pointer to it in a variable, address of which was passed to CoCreateInstance as the last parameter, and the function itself returns S_OK, If the object doesn't implement this interface or an object with the given CLSID isn't registered in the registry, or if the registered server type isn't indicated in the flag of server type, an error message is returned.
At this place all "useful" work of our application is up - we free the object. It's necessary to do it using COM facilities, i.e. using obtained interface pointer. For that it's necessary to call a Release method of the IUnknown interface using the obtained interface pointer (pUnk). Absolutely all COM interfaces are inherited from IUnknown, therefore the Release method may be called by means of the same technique for all COM objects.
A pointer to an object interface is an address of a structure storing data related to the state of an object instance. Only indirect access to this data is possible by calling methods of the proper interface so each method receives an address of this structure (a so called "this" pointer in terms of C++ language) as the first parameter. It's possible to say about this structure only that its first field stores a pointer to another structure - "virtual table" - containing addresses of functions implementing methods of the interface. To call this or that method one needs to find an address of its implementation. The address of the method is stored in the virtual table with the well-known and constant offset. Machinery of this process we'll examine in more detail in the next article and now just the code:
At this place handling of WM_COMMAND and of any other messages is completed.
Now it's possible to continue experiments with the registry. The major subkeys of "HKEY_CLASSES_ROOT\CLSID" are a number of subkeys allowing to locate a server in the system: InprocServer, InprocServer32, InprocHandler, InprocHandler32, LocalServer, LocalServer32. Each of the server types is represented with two subkeys; the suffix "32" means that the server is 32-bit, the subkey without this suffix indicates that the server is 16-bit (for backward compatibility). The case of the remote server is handled in a particular way; we'll discuss it in more details in the section about AppID.
Let's begin to play tricks. Special utilities such as guidgen etc. are used for getting unique GUIDs when creating new interfaces and components. Microsoft has reserved a large number of handy GUIDs with sets of zeros for its own use; but we'll handle it yet cooler - we'll use GUIDs like {00000000-0000-0000-0000-000000000001}. Why to bother ourselves seeking for our component among the bulk of digits, when we can comfortably put it in the very beginning of the section? It would be possible (and the author had done it indeed at first) to use GUID with all zeros but it's the special reserved GUID_NULL used in special cases; to avoid trouble it's better to leave it alone.
Create the key {00000000-0000-0000-0000-000000000001} under "HKEY_CLASSES_ROOT\CLSID". The key may have a default value which represents the textual description of the component for a user. Note that it isn't ProgID (though some component programmers use ProgID as the component description). You may put here some string, for example, "My favourite component". Then create a subkey with the name "LocalServer32". The default value of this subkey stores just the full pathname to the file implementing the server. Write here "c:\windows\calc.exe" (replace "windows" with the windows folder on your machine). Now launch our client (COM_2.exe), enter CLSID, press IUnknown, check "Local server" as the server, press "Connect" and... You may close the calculator. And our client is like hung - but you must have been ready to this, because the calculator has no idea about such an occasion that it became a COM component. While the COM system is still waiting for a responce from the calculator, our client sits inside CoCreateInstance at that time. Though about half a minute later it'll return the timeout error and our client will display the corresponding message box.
I shan't describe here all other experiments - the way is showed, the utilities are created - experiment! COM technology may be understood only in practice. But don't forget about the warning concerning accuracy when working with registry in the heat of enthusiasm.
Let's consider other subkeys. The important ones are TreatAs and AutoTreatAs because they allow to change the server of a component. If there is a subkey TreatAs (its default value contains another CLSID) under the key with the given CLSID then an object will be created with this other CLSID regardless of presence of subkeys InprocServer, LocalServer, etc. Make the following experiment. Create a subkey "TreatAs" under our key {00000000-0000-0000-0000-000000000001}. Put CLSID for the component Excel.Application (using the utility COM_1.exe to convert ProgID to CLSID) as the value of this subkey. Now if you'll try to load our component using COM_2.exe, Excel will be loaded (though it remains hidden. To make sure it runs look into the task manager).
The subkey TreatAs permits one server to emulate the other one. The function CoGetTreatAsClass allows to get a value of this key and the function CoTreatAsClass - to assign this value or delete it. If the subkey TreatAs is being deleted using CoTreatAsClass this function examines the value of the subkey AutoTreatAs. If a key with this name does exist its value is copied in the subkey TreatAs; if not the TreatAs subkey is deleted alltogether. And the subkey AutoTreatAs may be created or deleted only by hand using registry API functions. Thus the value of preceding CLSID may be stored in the AutoTreatAs subkey if this server was emulated at first by one server and then is emulated by the other providing in a sense "permanent" emulation (as opposed to "temporary" emulation using TreatAs subkey).
Being the main source of data about the component the "HKEY_CLASSES_ROOT\CLSID" key contains subkeys with crossreferences to other keys. We've already talked about ProgID and VersionIndependentProgID subkeys. The TypeLib subkey stores GUID that is an identifier of the type library for the given component; the corresponding subkey is located under "HKEY_CLASSES_ROOT\TypeLib". AppID subkey stores GUID identifying the subkey of another section - "HKEY_CLASSES_ROOT\AppID" - and indicates that the object is distributed (DCOM). These subkeys will be described later in more details.
There is a few other subkeys; we shan't examine them all. We'll mention only about those that are in a sense flags indicating types of components. The presence of "Control" subkey indicates that the component is a control; "Insertable" indicates that the object can be embedded in OLE containers; "OLEScript" - that the object is a scripting engine; "DocObject" - a document object; "Printable" - the object can be printed; "Programmable" - the object is an automation server (and accordingly it can be managed with scripts); "Ole1Class" - OLE 1.0 object (old version).
Let's create another small utility that will display a list of objects registered in the registry and relating to one of seven types listed at the end of the previous paragraph. The user interface of the utility is shown in fig.4. The type of an object can be chosen in the dropdown list; after pressing the "List" button descriptions of proper objects are displayed in the listview (these descriptions are default values for corresponding CLSID keys). If there is no description the string will be left empty.
Fig.4. The user interface of COM_3 utility
To save space we shan't give here the full source code of the application; the respective files are located in COM_3 folder of ComKit1.rar. Instead let's examine only some of essential aspects concerning the logic of program operation.
First the registry key "HKEY_CLASSES_ROOT\CLSID" is opened; its handle is stored in HKey variable. On successful opening of the key the main loop starts enumerating subkeys stored in the opened key.
On any enumeration error the loop is being broken and if the error is not because the enumeration is up, the proper message is displayed. For each new key found the two strings are constructed: "CLSID\{clsid of component}" and "CLSID\{clsid of component}\<type of object>", where <type of object> represents one of the seven strings describing the type of the object chosen from the dropdown list.
Then an attempt is made to open the registry key "CLSID\{clsid of component}\<type of object>". The successful attempt means that the key with the given CLSID has a subkey with the chosen name; in this case the other prepared key ("CLSID\{clsid of component}") is opened and the default value is requested which is then sent to the listview and the loop continues with the next iteration:
Interface section
Unlike other keys "HKEY_CLASSES_ROOT\Interface" relates not to individual components but to the system in the whole. Given here data about interfaces is used on standard marshaling. There are not so many subkeys: BaseInterface, NumMethods, ProxyStubCLSID, and ProxyStubCLSID32. BaseInterface stores the name of the interface which the given interface is inherited from; if it isn't indicated IUnknown is used as the base interface. NumMethods stores the number of methods in the interface. ProxyStubCLSID(32) is like InprocServer(32): it stores the full pathname to the server (dll) implementing auxiliary objects (so called proxies and stubs), which are used by the systm on marshaling of methods of the given interface. As usual the suffix "32" in the name means the 32-bit server and its absence means the 16-bit one.
Detailed discussion of marshaling and related problems is beyond the scope of this article; something will be told in the second article, and now we'll give the description of a useful utility using this registry section. Its user interface is shown in fig.5. On pressing "List" button the application creates an instance of the COM object with CLSID indicated in the edit box. Then the created object is requested for all possible interfaces names of which can be found in the system registry. The names of all interfaces implemented by this object are displayed in the listview.
Fig.5. The user interface of COM_4 utility
Here again only key features of the cource code will be given; source files are located in the folder COM_4 of ComKit1.rar.
Since the application uses the COM library CoInitialize procedure is called on initilizing of the dialog box and on its closing CoUninitialize is called appropriately. On pressing "List" button the listview window is cleared and CLSID is got from editbox by means we already know:
Then an instance of the object with the given CLSID is created; IUnknown is requested as the first interface (its IID is stored in IUnk) and the object context permits any type of the server:
If the pointer is obtained (in pUnk) successfully the registry key "HKEY_CLASSES_ROOT\Interface" is opened and the main loop of enumeration of subkeys (i.e. interfaces) is entered:
The loop is exited when the enumeration function returns an error; if it isn't the error because of lack of keys for further enumeration then an error message is displayed. Each new enumerated key (IID of an interface in the string representation) is converted into numeric form (if an error takes place when converting then this key subsequently is simply ignored and the loop continues).
Now it's necessary to request our object for the interface with the just got IID. To do it we need to call QueryInterface method of IUnknown interface with the following arguments:
• pointer to an instance of the current object ("this");
• address of a structure where IID of the requested interface is stored;
• address of output variable that receives the requested interface pointer.
Address of the QueryInterface method is located at the very beginning of the virtual table (with offset 0):
In the case of successful receiving of the new interface pointer QueryInterface returns S_OK. We need just the fact that the object implements this interface, the interface itself is not required; therefore we release just received pointer right away calling Release method on it:
At the same time a kind of "Interface\{IID of interface}" string is created and the respective registry key is opened requesting the default value of this key (the interface name). This name is added into the listview.
In case if QueryInterface or RegOpenKeyEx returns error this key is simply ignored and the loop continues.
After exiting the loop Release method is called on pUnk pointer to IUnknown interface that was received on creating the object instance (in a similar manner it was done earlier).
TypeLib section
"HKEY_CLASSES_ROOT\TypeLib" contains keys the names of which represent the string form of identifiers (GUIDs) of istalled in the system type libraries. Subkeys TypeLib of components under "HKEY_CLASSES_ROOT\CLSID" reference these keys but there are no backreferences. Type libraries are mandatory for components that use late binding and automation; in particular they are widely used with ActiveX controls. Other components may not have type libraries.
Each key under TypeLib contains a hierarchical structure of subkeys. Subkeys of type library version are stored on the first level, being represented in the string form like major.minor (digits corresponding to the version). In turn a version subkey contains HelpDir subkeys (that store full pathnames to help files), Flags (flag of type library) and the string representation of the locale identifier (lcid). The <lcid> key contains yet one or two additional subkeys: win16 and/or win32 - full pathnames to type libraries for the corresponding platform.
Let's consider one more application as an example of work with a type library (fig.6). The dialog box of the application has only one control - a listview. Descriptions of components are displayed in the first column and identifiers of the corresponding type libraries are displayed next to them in the second column. On double click on component name either general info about the given component stored in its type library is displayed or help file related to this component (if any) is opened.
Fig.6. The user interface of COM_5 utility
The application works as follows (details of implementation of GUI are omitted; full source code is located in COM_5 folder of ComKit1.rar). On handling WM_INITDIALOG message the registry key "HKEY_CLASSES_ROOT\CLSID" is opened, then the main loop enumerating stored there subkeys is entered:
As in the previous utiltity if RegEnumKeyEx returns an error the loop is being broken. The two strings in the form of "CLSID\{clsid of component}" and "CLSID\{clsid of component}\TypeLib" are created for each new key, then an attempt is made to open the registry key with the second string as the name.
The successful opening of TypeLib key means the component has a type library. In this case a value of "CLSID\{clsid of component}" key is requested and the corresponding string is placed in the first column of the listview and a value of "CLSID\{clsid of component}\TypeLib" subkey (the string representation of the type library identifier) is placed in the second column:
A double click on an element of the listview is handled as WM_NOTIFY message. The proper code is located in the separate procedure FindHelp, the address of NMLISTVIEW structure with info about the clicked list element being passed in ebx registry:
FindHelp procedure begins with checking whether double click is acually made on a listview element:
Now it's possible to copy into buf contents of the second column of the proper element (GUID of the type library in the text representation).
Then using the given value the name of the registry key "TypeLib\{GUID of type library}" is created and the key is opened.
It's necessary to handle the not very handy form of representation of type library data. To get a pathname to the file containing the type library, first we need to indicate the version but it's impossible to say anything about it in advance. The trouble is that the function LoadRegTypeLib requires indicating of the exact major version and refuses to load type libraries with other versions. Therefore we'll need to examine version subkeys on hand and pick out the major version from the subkey name.
The number of major version is obtained; now it's possible to convert the string representation of GUID into the numeric one and pass it to LoadRegTypeLib function that accepts the following arguments:
• address of a sturcture holding GUID of the library being loaded;
• major version number (the exact value must be indicated; in this case it's in the mjver variable);
• minor version number (may be 0 here, because the system will load any library having minor version number greater than the indicated one);
• national language code of the library being loaded (lcid; may be neutral - 0);
• address of a variable that receives a pointer to ITypeLib interface on return.
The returned value S_OK means we've got a valid pointer to ITypeLib interface. We need GetDocumentation method; it accepts the following arguments:
• index of the type description; if -1, then the documentation for the library itself is returned (just that we need);
• address of a variable that receives a pointer to a BSTR string with the name of the requested element (in this case - of the type library itself);
• address of a variable that receives a pointer to a BSTR string with the description of the requested element;
• address of a variable that receives the Help context identifier;
• address of a variable that receives a pointer to a BSTR string that contains the fully qualified name of the Help file.
If you don't need any type of data you may pass 0 as the value of the proper argument. The address of GetDocumentation function is located in the virtual table of the ITypeLib interface with offset 24h.
0 in HelpFile on return means there is no help file. In this case a simple message box with the received data is displayed:
But if the Help file is indicated the corresponding string is converted from Unicode into ANSI and its address is passed as an argument to ShellExecute function (in order to have possibility to load both hlp- and chm-files):
BSTR strings must be freed aftewords to avoid memory leaks:
On error of GetDocumentation method the proper message is displayed. In any case the ITypeLib interface pointer (pTlib) must be freed after that:
The function is concluded with handling of other errors:
You can find out many interesting things using this utility. Try it!
AppID section
The registry key "HKEY_CLASSES_ROOT\AppID" jointly with the key "HKEY_LOCAL_MACHINE\Software\Microsoft\OLE" determine settings for the distributed COM (DCOM) system.
The distributed COM system deals with data transmission via network and right away faces questions of authentication, authorization and other problems of data protection. The general configuration scheme is usually as follows: values of default security parameters are described under "HKEY_LOCAL_MACHINE\Software\Microsoft\OLE" key. The key "HKEY_CLASSES_ROOT\AppID" contains subkeys (GUID) that can store security parameters for separate groups of components (in this case "HKEY_CLASSES_ROOT\CLSID\{clsid of component}\AppID" containes a reference to the corresponding key under "HKEY_CLASSES_ROOT\AppID"). The values under AppID prevail over the respective default values. Besides the security parameters and other related to distributed system parameters may be indicated explicitly when creating component using the function CoCreateInstanceEx or like. In this case the explicitly specified values are used.
"HKEY_LOCAL_MACHINE\Software\Microsoft\OLE" key may have the following named values:
• EnableDCOM - permits (Y or y) or prohibits (N or n) remoute clients to launch components on this system;
• DefaultLaunchPermission - defines the default list of principals (ACL) who can launch components on this machine;
• DefaultAccessPermission – defines the default list of principals (ACL) who can access loaded objects;
• LegacyAuthenticationLevel – sets the default authentication level;
• LegacyImpersonationLevel – sets the default impersonation level;
• LegacyMutualAuthentication – permits (Y or y) or prohibits (any other value or the lack of this named value) mutual authentication;
• LegacySecureReferences – indicates whether invocations of AddRef and Release methods are secured (Y or y) or not (any other value or the lack of this named value).
The keys "HKEY_CLASSES_ROOT\AppID\{GUID}" can have the following named values:
• RemoteServerName – the name of the server where the component is to be launched;
• ActivateAtStorage – indicates that the component must be launched on the same machine as object data;
• LocalService – indicates that the component is implemented as Win32 service;
• ServiceParameters – is used in common with LocalService. The value of this parameter is passed on invocation of the proper service as parameters;
• RunAs - sets an application to run only as a given user;
• LaunchPermission - determins the list of principals (ACL) who can launch the application;
• AccessPermission - determins the list of principals (ACL) who can access objects of the given class;
• DllSurrogate - contains the full pathname to the wrapper application (exe) in which the remote inprocess (dll) server is to be activated;
• AuthenticationLevel - sets the authentication level for AppID.
The indicated in the registry values may be overlapped through the explicit call to CoInitializeSecurity function.
Sorry for my English; I hope you did understand it.
Автор: Roustem
Дата: 2007-01-03
wasm_files.zip: files/0446/comkit2.rar)
Второй важнейшей основой, без которой невозможна инфраструктура COM, является использование DLL. Причем не просто использование, а очень активное использование; и использование не только самих DLL, но и тех принципов, которые применяются в технологии динамического связывания.
Технология COM претендует на универсальность своей компонентной модели. Это значит, что безболезненно взаимодействовать между собой должны не только компоненты, написанные на разных языках и созданные с использованием различных сред разработки, но и разные виды компонентов: и созданный специально для внедрения в другие приложения код DLL; и компоненты, входящие в EXE-модули самостоятельных приложений; и код, размещенный на другой машине и потенциально созданный для другой платформы. Естественно, сразу возникает проблема передачи данных через границы процессов и систем, а также единообразия работы с внутрипроцессными и внепроцессными объектами.
COM в качестве решения этой проблемы использует единый и единственный указатель интерфейса: все, что нужно для работы с объектом - это получить указатель на его интерфейс, и ничего более. Этот указатель представляет собой некий адрес в адресном пространстве клиента, по которому соответствующая область памяти структурирована определенным образом в соответствии с бинарным стандартом. А это значит, что область эта может принадлежать только DLL, и любой объект - будь он в другом процессе или на другой машине - имеет свою DLL (неважно, созданную разработчиком компонента или предоставленную системой), которая внедряется в адресное пространство клиента. Более того, именно эта часть объекта и предоставляет клиенту собственно интерфейс; можно сказать, что интерфейс объекта всегда реализуется в DLL, независимо от того, внутрипроцессный это объект, внепроцессный или удаленный.
"Интерфейсная" область структурируется иерархически с использованием других указателей наподобие связанного списка. Начинающих - и даже не только начинающих - COM-программистов часто смущает это обилие вложенных указателей. Чего стоит, например, аргумент метода QueryInterface в виде двойного указателя на неопределенный тип! Один этот void языка С++ способен свести с ума, потому что понять его смысл невозможно в принципе. А если кто-то попытался использовать С и выяснил, что там на самом деле есть еще и скрываемая объектными языками виртуальная таблица - чтобы добраться до метода, необходимо тройное перенаправление?..
Даже авторы некоторых статей по COM-программированию на ассемблере как-то слишком уж поспешно проскакивают этот момент, бросаясь сразу в объятия спасительных макросов и предопределенных структур и пробормотав что-то невнятное о запутанности указателей, так что возникает подозрение, что они сами не до конца разобрались с этой проблемой. Между тем это вопрос, в котором можно (и нужно) разобраться - один раз, но досконально.
Попробуем спроектировать собственную объектную модель и посмотрим, какие проблемы при этом возникают. Главной идеей ООП было объединить данные и обрабатывающие их и семантически связанные с ними функции в одну конструкцию. Предположим, что у нас есть указатель на некий объект, представляющий собой область с данными, за которой непосредственно следуют обрабатывающие их методы (рис. 1). Доступ и к данным, и к методам этого объекта можно получить, используя простое смещение, добавляемое к значению указателя - как при работе с обычной структурой. Например, если указатель на объект находится в регистре eax, метод 2 можно вызвать следующим способом:
Рис. 1. Гипотетическая модель объекта, доступ к методам и данным которого осуществляется через один и тот же указатель
Какие могут тут быть проблемы? Если создаются несколько экземпляров одного и того же объекта, в памяти оказываются несколько копий одного и того же кода, хотя это совершенно излишне. Для решения этой проблемы данные и код можно разместить в различных секциях, причем секцию кода сделать общей, а секцию данных для каждого экземпляра объекта выделить свою. Именно по такому принципу строятся DLL (хотя формат PE-файла и соответствующие опции компиляторов позволяют создавать при необходимости и общие секции данных).
Как только появляется общая секция кода, возникает и вопрос отслеживания количества ссылок на него, чтобы своевременно освобождать память после завершения работы. Обычно эта проблема решается созданием счетчиков, значение которых увеличивается на один при создании нового экземпляра и уменьшается на один при его разрушении. Когда значение счетчика при очередном уменьшении достигает 0, секцию кода тоже можно выгрузить из памяти. Этот механизм используется операционной системой при загрузке и выгрузке DLL, но он не виден приложениям; в компонентной же модели он становится явным.
Рис. 2. Модель с различными секциями данных и единой секцией кода.
Для того, чтобы обращаться и к данным, и к коду через один и тот же указатель объекта, в области данных можно записать указатель на общую для всех экземпляров секцию кода с реализацией методов объекта (рис. 2). При такой схеме методы объекта не имеют непосредственного неявного доступа к данным и последние придется передавать через аргументы, как в случае самых обычных процедур. А это разрушает саму идею объектного подхода - стоило ли ради этого огород городить?
Поэтому возникает еще одна схема, реализующая один из основных принципов ООП - инкапсуляцию: непосредственный доступ к данным объекта через указатель на объект закрывается - он превращается в "чёрный ящик" (рис. 3). Из всех данных доступным остается лишь указатель на секцию кода (благодаря тому, что он расположен в самом начале структуры данных и именно его адрес содержит указатель объекта) с реализацией методов объекта, которые непосредственно имеют дело с данными. Поскольку у каждого объекта своя секция данных, тогда как реализация методов одна для всех объектов, каждый метод при своем вызове в качестве первого параметра получает указатель на секцию данных именно того объекта, для которого вызывается метод. (В терминологии языка С++ этот параметр получил название указателя "this").
"Расплатой" за это является один уровень перенаправления, добавляемый на пути от указателя объекта к его методу. Теперь, если указатель объекта находится в регистре eax, метод вызывается следующим образом:
Рис. 3. Реализация принципа инкапсуляции.
Еще одна проблема возникает в связи с реализацией другого основного принципа ООП - полиморфизма. В среде COM времени исполнения нет имен. В принципе можно было бы создать и систему с использованием имен во время исполнения - например, DLL пользуются именно такой схемой. (К слову сказать, основанный на COM большой раздел OLE - автоматизация - использует модель позднего связывания, построенную именно по такому принципу. Но об этом поговорим как-нибудь в другой раз). Для доступа к методам вычисляются их адреса с использованием указателя интерфейса и постоянных смещений, а имена могут существовать лишь во время компиляции.
Традиционные языки программирования и среды разработки используют подобную же схему, однако в их случае вычисляемые смещения уникальны для каждой конкретной компиляции и они не используются нигде, кроме данного приложения. В случае же с компонентной моделью один и тот же интерфейс могут реализовать совершенно различные компоненты, и тут проявляется проблема смещений.
Предположим, имеются две реализации одного и того же интерфейса, содержащего три метода. Как видно на рис. 4, в двух реализациях методы требуют разного количества памяти, поэтому их смещения относительно начала секции кода оказываются различными. В результате код, который может работать с первой реализацией, не может работать со второй, и наоборот - полиморфизм невозможен.
Рис. 4. Проблема различных реализаций одного интерфейса.
Для решения этой проблемы вводится еще один посредник между указателем на объект и реализацией его методов - виртуальная таблица (рис. 5). В секции данных объекта теперь располагается указатель не на секцию кода, а на виртуальную таблицу, в которой содержатся указатели на соответствующие методы. Смещение указателя на один и тот же метод относительно начала виртуальной таблицы всегда постоянно, хотя объем кода метода и его расположение в секции кода в различных реализациях могут сильно различаться. Но это вводит еще один уровень перенаправления. Вызов метода выглядит теперь следующим образом:
Правда, это может быть записано короче таким образом:
Рис. 5. Реализация принципа полиморфизма.
Полиморфизм означает, что в качестве реализации метода интерфейса может выступать абсолютно любой код, удовлетворяющий данному синтаксису вызова метода. Именно это и используется в реализации знаменитой "прозрачности удаленного доступа" COM (хотя этот подход использовался еще до COM в RPC). Благодаря полиморфизму код, реализующий интерфейс в той части сервера, которая размещается в DLL и загружается в адресное пространство клиента, может исполнять не алгоритм метода, а заниматься совершенно другими вещами - упаковывать полученные для метода параметры со всеми сопутствующими данными в некую структуру и отправлять ее куда-то в адресное пространство другого процесса или даже по сети на другую машину, где находится другая часть кода, реализующая собственно алгоритм метода. DLL выступает в этом случае "представителем" кода, размещенного в другом процессе или на другой системе. Клиент же ничего этого не видит; максимум, что он может заметить - увеличение задержек при выполнении методов.
Если свести все воедино, мы получим схему, приведенную на рис. 6. Это и является бинарной структурой интерфейса, используемой в COM. Таким образом, несколько упрощая, можно сказать, что первое перенаправление указателя интерфейса COM на пути к реализации метода делается "во славу" и ради принципа инкапсуляции, а второе - "во славу" и ради принципа полиморфизма. Возможно, это поможет кому-нибудь лучше запомнить эту схему и не запутаться в ней. :)
Рис. 6. Бинарная структура интерфейса COM.
Осталось лишь выяснить, откуда берутся двойные указатели на интерфейс и зачем нужно третье перенаправление. На самом деле, это искусственное абстрактное образование, создаваемое языками высокого уровня и не имеющее собственно к COM никакого отношения. Дело в том, что указатель интерфейса должен быть возвращен функцией, создающей объект. Но функции COM по соглашению возвращают результат типа HRESULT, сообщающий об успешности или ошибке хода выполнения. Для возврата указателя используется аргумент функции, а это значит, что указатель передается по ссылке: его значение копируется в переменную, которую подготовил клиент и передал функции ее адрес. Формально тип соответствующего аргумента функции оказывается двойным указателем; но гораздо проще понимать его как адрес переменной (на стороне клиента), в которую должен быть возвращен указатель интерфейса. И соответственно, следует не создавать переменную типа двойного указателя (в нотации С - void ppv) и передавать функции ее значение (ppv), а создать переменную типа указателя на интерфейс (void* pv) и передать функции ее адрес (&pv).
Раз уж речь шла о принципах ООП, придется упомянуть еще и третий основной принцип - наследования. На уровне интерфейсов COM он проявляется в том, что интерфейс-потомок наследует всю виртуальную таблицу интерфейса-родителя, добавляя указатели к собственным методам в ее конец. Поскольку все интерфейсы COM прямо или косвенно наследуются от IUnknown, мы можем с абсолютной уверенностью заявить, что первые три указателя виртуальной таблицы любого интерфейса COM содержат адреса реализаций трех методов IUnknown в одном и том же порядке: QueryInterface, AddRef и Release (со смещениями относительно начала виртуальной таблицы соответственно 0, 4 и 8 байт). Т.е. если у нас есть указатель некоторого интерфейса pSomeInterface, эти методы вызываются так:
Обратите внимание, здесь речь идет о наследовании интерфейсов - т.е. абстрактных структур - а не реализаций, как в объектно-ориентированных языках программирования. Для наследования реализаций или, как это называется в COM, повторного использования кода, существует другой, специально для этого созданный механизм, но это уже тема отдельной большой статьи.
Структура dll-сервера
Ну что ж, пора приступить к практике и посмотреть, каким образом задействуется та самая бинарная структура интерфейса COM, которую мы так долго разбирали. Система предоставляет своего рода "точки входа в COM". Клиентскую сторону мы уже видели - это функция API CoCreateInstance, с помощью которой мы создавали универсальный клиент в прошлой статье. Со стороны же сервера DLL это функция DllGetClassObject, которая должна быть реализована и экспортирована DLL. Система передает ей такие параметры:
• адрес структуры, содержащей CLSID объекта класса;
• адрес структуры, содержащей IID интерфейса, который запрашивается у объекта класса;
• адрес переменной, в которой возвращается указатель на затребованный интерфейс.
Эта вызываемая системой функция создает объект класса - но это не запрашиваемый клиентом объект. Да, вы узнали страшную тайну. COM - это царство посредников. Объект класса - это еще один посредник, имеющий даже собственное имя - "фабрика классов". Именно эта фабрика создает экземпляры объектов компонента для клиента, предоставляя для этой цели собственный интерфейс - чаще всего это IClassFactory, хотя могут быть и другие варианты.
Функция CoCreateInstance, которую мы использовали в нашем клиенте (COM2.exe (находится в архиве wasm_files.zip: files/0446/comkit1.rar)), на самом деле является "оберткой" вокруг функции, которая является действительной точкой входа со стороны клиента - CoGetClassObject. Параметры этой функции:
• адрес структуры, содержащей CLSID компонента, для которого создается фабрика классов;
• тип сервера (внутрипроцессный, локальный, удаленный или внутрипроцессный обработчик);
• адрес структуры, содержащей имя и другие параметры удаленного сервера (этот параметр может быть 0);
• адрес структуры, содержащей IID интерфейса фабрики классов (обычно IClassFactory);
• адрес переменной, в которой будет возвращен указатель на требуемый интерфейс.
CoCreateInstance вызывает CoGetClassObject, запрашивая у нее указатель на интерфейс IClassFactory для компонента с данным CLSID. Затем через полученный указатель вызывает метод CreateInstance интерфейса IClassFactory, запрашивая уже указатель на интерфейс самого компонента, а указатель на IClassFactory сразу же освобождает (вызвав через него метод Release).
Но об этом позже; а сейчас построим простейший сервер, вернее, псевдосервер COM - потому что он экспортирует DllGetClassObject, но функция эта все время возвращает код ошибки CLASS_E_CLASSNOTAVAILABLE. Сервер DLL должен экспортировать еще одну функцию - DllCanUnloadNow, которая в зависимости от состояния внутренних счетчиков реализуемых объектов возвращает S_OK или S_FALSE, в соответствии с чем система может выгрузить DLL из памяти. Вот исходный код полностью (файл COM_6.asm):
Необходимо создать еще def-файл (COM_6.def):
Ключевое слово "PRIVATE" используется для того, чтобы экспортируемые функции не попали в создаваемый при построении DLL lib-файл - чтобы кто попало не мог импортировать эти функции, ибо они предназначены только "для своих" (т.е. системы COM). Хотя это обстоятельство может остановить разве что делающих все по правилам прикладных программистов, но никак не низкоуровневиков, способных подключиться непосредственно к DLL. :)
Строим DLL со следующими опциями (обратите внимание, наша DLL в данном конкретном случае не имеет функции инициализации и соответственно точки входа):
Предполагается, что MASM32 расположен в каталоге \MASM32 текущего диска; если это не так, необходимо соответствующим образом отредактировать пути.
Теперь запускаем редактор реестра и находим созданный в прошлый раз "хулиганский" ключ {00000000-0000-0000-0000-000000000001} в разделе "HKEY_CLASSES_ROOT\CLSID". Удалим оттуда подключ "TreatAs", если он там есть, и создадим новый: "InprocServer32". В качестве значения запишем полный путь к созданной нами DLL (например, "C:\COM_6\COM_6.dll"). Запускаем наш универсальный клиент (COM_2.exe), заполняем CLSID, для IID жмем кнопку "IUnknown", тип сервера - "InProc server" и - "Connect". Остальное не описываю - сами увидите. Надеюсь, то, что клиент сообщает об ошибке, никого не удивляет. :)
IClassFactory
Интерфейс IClassFactory, помимо функций-членов IUnknown, содержит два собственных: CreateInstance и LockServer. Приступим к реализации второй версии нашего "сервера" (файл COM_7.asm):
Эти две переменные и составляют содержание простейшего инстанциированного "экземпляра интерфейса" - указатель на виртуальную таблицу (в соответствии с бинарным стандартом COM) и счетчик ссылок для данного объекта. Других данных у нашей реализации этого объекта нет. Дальше расположим саму виртуальную таблицу:
На самом деле названия функций не играют никакой роли - можно было использовать любые названия. Важен порядок расположения функций в виртуальной таблице - он должен строго соответствовать интерфейсу. Само собой, указатели на функции нельзя чередовать с посторонними данными. В данном случае, в названии первых трех функций имеется префикс IUnknown, чтобы подчеркнуть, что эти члены наследуются от базового интерфейса, хотя все эти функции являются членами интерфейса IClassFactory.
Далее следуют обычные данные:
Теперь реализации функций и методов.
В данной реализации эта функция (как и остальные) отображает окно сообщения, а затем просто перенаправляет вызов функции интерфейса IUnknown_QueryInterface. Параметр rclsid нужен в тех случаях, когда один сервер dll реализует сразу несколько компонентов с различными CLSID (и функция DllGetClassObject должна решить, объект какого именно класса создавать). В нашем случае "компонент" всего один - вернее, его нет вообще, поэтому этот "сервер" будет работать с любым CLSID. В случае реального сервера именно в этом месте CLSID реализуемых компонентов жестко вшиты в код.
Обратите внимание, что мы вызываем IUnknown_QueryInterface напрямую. Хотя это и метод интерфейса COM, но мы, как авторы реализации, обладаем знанием внутреннего устройства нашего объекта, которого нет у клиента. При желании ничто не может нам помешать вызвать этот метод стандартным для COM способом, т.е. через указатель интерфейса - в данном случае, например, используя регистр eax, хотя это не имеет смысла.
Поскольку теперь у нас есть счетчик объекта, DllCanUnloadNow должна возвращать результат, зависящий от его значения:
Переходим к самому интересному - реализации QueryInterface:
Сначала с помощью вспомогательной функции IsEqualGUID (принимающей в качестве аргументов адреса двух содержащих GUID'ы структур, которые необходимо сравнить между собой) проверяем, является ли запрошенный интерфейс IUnknown или IClassFactory. Если ни то, ни другое, возвращается ошибка. Если же запрошен один из этих двух интерфейсов, в переменную, адрес которой передан в аргументе ppvObject, копируется адрес переменной pVtbl, находящейся в самом начале нашего виртуального "объекта". Поскольку функция возвращает новый указатель на объект, должен быть увеличен его счетчик, что также делается непосредственным вызовом IUnknown_AddRef:
Реализации AddRef и Release тривиальны - они просто соответственно увеличивают или уменьшают значение счетчика объекта и отображают окно сообщения с его текущим содержимым. Обычно при достижении счетчиком 0 реализация Release должна удалить объект, освобождая занимаемую им память. В нашем же случае никакой объект реально не создавался, все данные были статическими, поэтому и уничтожать ничего не надо.
Теперь собственные функции интерфейса IClassFactory. CreateInstance принимает, помимо указателя 'this', еще 3 аргумента:
• указатель на "внешний" IUnknown, который применяется при агрегировании объектов. Если агрегирования нет, этот аргумент равен NULL;
• адрес структуры, содержащей IID запрошенного интерфейса;
• адрес переменной, в которую должен быть возвращен указатель интерфейса.
Поскольку наш "сервер" не реализует ни одного компонента, он просто на все запросы возвращает E_NOINTERFACE:
Метод LockServer кроме 'this' принимает лишь один аргумент - булевую переменную, указывающую, увеличить (TRUE) или уменьшить (FALSE) значение счетчика замка сервера. Замок позволяет сохранить сервер в памяти (невыгруженным), даже когда счетчики всех объектов равны 0. В нашем случае замок использует общую со счетчиком объекта глобальную переменную:
Вот и вся программа. Def-файл такой же, как в предыдущем случае (COM_7.def):
Это одна из возможных реализаций "точки входа" COM и фабрики классов, притом не самая оптимальная (зато простая). Реализация сильно зависит в том числе и от применяемой модели многопоточности COM (это тема для отдельной большой статьи). В нашем случае как сервер, так и его клиент однопоточные - система COM будет осуществлять принудительную синхронизацию поступающих серверу запросов, что в некоторых случаях может сильно снижать производительность. Некоторые свидетельства "посредничества" COM можно пронаблюдать, экспериментируя с данной утилитой; в частности, попробуйте повторный вход (re-entrance) в сервер из клиента, нажав на кнопку "Connect" (с теми же параметрами) в середине процесса обработки первого запроса (при отображении окна сообщения с AddRef), и сравните это с результатами, когда запущены одновременно два (или более) клиента для одного и того же сервера.
Реализация простейшего объекта
Добавим к нашему серверу "компонент". Для простоты он будет содержать единственный интерфейс IUnknown, но создавать его экземпляры мы будем с выделением памяти из кучи. Благодаря этому мы сможем, наконец, увидеть настоящее применение указателя "this" (даже в таких простейших, казалось бы, методах как AddRef и Release).
Каждый экземпляр объекта будет представлен небольшой структурой, первый член которой (в соответствии со спецификацией COM) является указателем на виртуальную таблицу реализации методов IUnknown. У нас уже есть реализация IUnknown для объекта класса, но мы должны написать другую реализацию методов этого же интерфейса, поскольку объект компонента и объект класса - разные объекты (вот вам принцип полиморфизма в действии). Вторым элементом в структуре объекта компонента будет счетчик ссылок для данного экземпляра объекта, а третьим - идентификатор объекта (для того, чтобы отображать его в окне сообщения). В качестве идентификатора используем простой счетчик созданных объектов, который будет вести объект фабрики классов; при создании это значение будет скопировано в соответствующее поле структуры объекта.
Для представления экземпляра объекта удобнее всего было бы использовать структуру MASM, но в данной реализации я использовал непосредственное обращение к соответствующим данным на низком уровне, чтобы как следует "прочувствовать", что же это такое. Желающие могут переписать этот пример, используя высокоуровневые конструкции MASM'а - весьма неплохое упражнение для закрепления материала.
Перейдем к коду (COM_8.asm):
Статическая структура для "объекта класса":
За ней следуют две виртуальные таблицы: первая - для реализации интерфейса IClassFactory объекта класса, вторая - для реализации (единственного) интерфейса IUnknown объекта компонента:
Далее идут обычные данные:
Реализация "точек входа" и интерфейса IUnknown объекта класса практически не претерпела никаких изменений, за исключением того, что в DllCanUnloadNow было добавлено условие проверки значения счетчика созданных объектов objcnt.
Зато существенные изменения претерпел метод CreateInstance. Теперь он создает настоящие объекты, выделяя для них память из кучи. Кроме того, нужно организовать проверку параметров и соответствующую обработку ошибок:
Если кто-то пытается агрегировать наш объект в состав какого-то другого объекта, необходимо сообщить ему, что мы на это вовсе не рассчитывали. Параметр pUnkOuter должен содержать NULL. Необходимо проверить также параметр riid: наш компонент поддерживает единственный интерфейс - IUnknown.
Теперь "сердцевина" метода: создаем объект. Как уже упоминалось, он представлен структурой из трех полей размером DWORD каждое, поэтому необходимо выделить из кучи блок памяти в 12 байт:
Выделенную память необходимо инициализировать. Указатель на выделенный блок памяти остался в регистре eax; первый DWORD по этому адресу должен быть указателем на виртуальную таблицу реализации методов нашего объекта (Vtbl1):
Второй DWORD содержит счетчик ссылок на экземпляр данного объекта; при создании заносим сюда 0:
Третий DWORD - идентификатор объекта, в качетве которого выступает счетчик созданных объектов фабрики классов:
Осталось вернуть указатель на вновь созданный объект клиенту, который для этой цели передал через аргумент ppvObject адрес соответствующей переменной (в начале метода мы скопировали его в ebx), а также увеличить счетчик ссылок на наш объект на 1:
Реализация метода LockServer осталась без изменений:
Перейдем к реализации IUnknown нашего компонента. Как и в реализации фабрики классов, методы отображают простые окна сообщений, по наличию которых можно судить об их вызове.
Проверка переданных параметров:
Сюда попадаем, если затребован интерфейс IUnknown; возвращаем указатель на текущий объект (т.е. "this"), просто увеличив его счетчик ссылок. Указатель на объект был сохранен в регистре ebx, а в регистре esi содержится адрес переменной клиента, в которую надо записать возвращаемое значение:
Перейдем к оставшимся двум методам. Их особенность в том, что теперь счетчик объекта располагается в выделенной памяти, и обращаться к ней необходимо через указатель "this". Кроме того, Release должна уничтожить текущий объект при достижении счетчиком значения 0; это осуществляется путем освобождения выделенной ранее под структуру объекта памяти через тот же указатель "this".
Def-файл и опции ассемблирования такие же, как ранее. Для экспериментов не забудьте изменить значение пути к серверу в реестре.
Exe-серверы
Внепроцессные серверы COM оформляются в виде exe-модулей. Обычно они представляют собой построенные из компонентов самостоятельные приложения (такие как Word или Excel), доступ к которым можно получить с помощью интерфейсов COM. Такое приложение может быть запущено как обычным способом (например, двойным щелчком на названии соответствующего exe-файла в проводнике), так и системой COM с помощью содержащихся в реестре данных. Чтобы приложение могло различать эти два способа запуска, COM запускает приложение с аргументом командной строки '-Embedding'.
Чтобы убедиться в этом, создадим простейшее приложение (COM_9.asm):
Это приложение отображает в окне сообщения командную строку, с помощью которой оно было запущено. Запишем в подключе 'LocalServer32' нашего "хулиганского" ключа в реестре путь к построенному exe-файлу. Затем запустим наш клиент (COM_2.exe), пометив галочкой "Local server". Как видите, к пути файла добавлен аргумент '-Embedding'. (Наш клиент на время зависнет, как и в случае любого не-COM приложения).
Построим внепроцессный вариант нашего простейшего dll-сервера. Exe-сервер по сравнению с dll-сервером имеет несколько особенностей.
Во-первых, поскольку exe-сервер находится в собственном процессе, он сам должен инициализировать библиотеку COM, вызвав функцию CoInitialize(Ex):
Во-вторых, он должен создать и зарегистрировать объекты класса для компонентов, которые поддерживает. Для этого используется функция CoRegisterClassObject со следующими аргументами:
• адрес структуры, содержащей CLSID компонента, для которого создается фабрика классов;
• указатель интерфейса созданного объекта фабрики классов;
• тип сервера;
• флаги, указывающие, какой тип соединения с данным сервером поддерживается (например, могут ли сразу несколько клиентов одновременно вызывать объект фабрики классов);
• адрес переменной, в которой будет возвращен регистрационный номер (он используется для последующего освобождения объекта класса).
На этот раз CLSID создаваемого компонента указывается при регистрации сервера явным образом, поэтому халявы, как в прошлый раз, не будет. Придется вшить CLSID компонента в код (используем наш старый {00000000-0000-0000-0000-000000000001}; он размещен в переменной clsid).
В-третьих, exe-сервер должен иметь цикл обработки сообщений независимо от того, создает он окна или нет. Дело в том, что модель многопоточности COM реализована через механизм т.н. апартаментов: любой объект COM может находиться лишь в одном апартаменте. При инициализации COM создает апартамент для того потока, который вызывает CoInitialize(Ex). Апартамент, в свою очередь, создает скрытое окно, которому посылаются сообщения при вызове методов объекта из других апартаментов (в т.ч. и из других процессов). Именно таким образом (через очередь сообщений потока) осуществляется принудительная синхронизация доступа различных потоков к одному объекту в том случае, если этот объект не создан специально многопоточным. Поэтому любой поток (как клиента, так и сервера), который вызывает CoInitialize(Ex), должен иметь цикл обработки сообщений, содержащий функцию DispatchMessage.
В-четвертых, функция CoRegisterClassObject при регистрации объекта в системной таблице вызывает через интерфейс IClassFactory объекта AddRef. Поэтому необходимо вести отдельный счетчик созданных фабрикой классов объектов и замков сервера, по достижении 0 которым вызывается функция CoRevokeClassObject. Этой функции передается единственный аргумент - регистрационный номер, полученный при вызове CoRegisterClassObject для соответствующего объекта.
Наш exe-сервер реализован "ленивым" способом: фабрика классов не создает новые объекты "компонента" (реализующего, как и в случае с dll-сервером, единственный интерфейс IUnknown), а лишь увеличивает счетчик ссылок единственного статического псевдообъекта, который к тому же имеет общий с замком сервера счетчик. При достижении этим счетчиком значения 0 (при вызове либо метода IUnknown_Release "объекта" компонента, либо метода IClassFactory_LockServer объекта класса) нужно отменить регистрацию фабрики классов. Вот реализации соответствующих методов:
В-пятых, при удалении последней ссылки на объект класса для завершения работы сервера необходимо выйти из цикла обработки сообщений. Для этого посылается сообщение WM_QUIT; однако, наш сервер не создавал собственных окон, поэтому сообщение должно быть послано потоку (параметр дескриптора окна функции PostMessage равен 0):
В остальном реализация данного exe-сервера повторяет реализация нашего dll-сервера. Полностью исходные файлы можно найти в каталоге COM_10 архива ComKit2.rar.
Однако, тема нашей статьи не построение exe-серверов, а dll как основа COM, что мы и можем обнаружить в экспериментах с помощью только что созданной утилиты. Построив exe-модуль и записав путь к нему в подключ "LocalServer32", можно запустить нашего клиента (COM_2.exe) и посмотреть, каким образом осуществляется вызов методов внепроцессного сервера. Если до этого вы не имели дела с exe-серверами COM, вы будете удивлены обилием вызовов, которые поступают к нему от системы. Все дело в том, что в дело вступают очередные многочисленные посредники. Попробуем это выяснить.
Для этого реализуем в нашем компоненте простейший нестандартный интерфейс, назвав его, скажем, IFoo. Впрочем, название, как вы уже знаете, не играет особой роли; интерфейс должен иметь уникальный IID. В наших славных традициях присвоим ему IID {00000000-0000-0000-0000-000000000002}. :) Переделка потребуется самая минимальная (COM_11.asm):
• в области данных добавать IID интерфейса:
• добавить одно смещение для дополнительного метода в виртуальной таблице для компонента:
• переделать код проверки IID интерфейса в методе QueryInterface для интерфейса компонента:
• и, наконец, добавить реализацию самого дополнительного метода:
Строим модуль, записываем путь к нему в подключе LocalServer32 и запускаем клиента. Сначала запросим у компонента интерфейс IUnknown, чтобы убедиться, что все построено правильно и ошибок нет. Если все нормально, запрашиваем IID для нашего IFoo. Ошибка клиента! И по коду (80004002h) мы можем определить, что это E_NOINTERFACE. Но как может отсутствовать интерфейс, который мы реализовали собственными руками (или головой?)?
"Интерфейсная" часть объекта, как уже говорилось, всегда реализуется в dll. И если мы ее не строили, это не значит, что ее нет - она предоставляется системой. То, что мы в своем exe-сервере тоже реализовали "интерфейсную" часть, это явление вторичное - этот интерфейс нужен лишь для взаимодействия с системой COM стандартным образом; внепроцессный сервер может быть реализован вообще без использования интерфейсов COM, по крайней мере, нестандартных. Для этого ему нужно реализовать так называемый нестандартный маршалинг. Но это отдельная тема, и сейчас мы говорить о ней не будем.
Если же внепроцессный сервер не использует нестандартный маршалинг, как в нашем случае, система обеспечивает его средствами стандартного маршалинга. Однако и здесь есть нюанс: система может обеспечить полную автоматизацию маршалинга лишь для тех интерфейсов, которые ей известны, т.е. стандартных. Если интерфейс нестандартный, как наш IFoo, система пытается найти средства для поддержки этого интерфейса, реализованные разработчиком интерфейса или использующего его сервера, через реестр.
Чтобы лучше узнать об этих запросах, слегка модернизируем наш сервер (COM_12.asm). Вероятно, вы обратили внимание, что система запрашивала у сервера множество посторонних интерфейсов. Попробуем узнать, что это за интерфейсы, изменив соответствующий участок IFoo_QueryInterface следующим образом (и заодно убрав лишние окна сообщений, оставив их лишь для QueryInterface):
Следующий после IUnknown интерфейс, который система запрашивает у внепроцессного объекта, - IMarshal. Именно этот интерфейс позволяет осуществлять нестандартный маршалинг, и реализуя его, компонент заявляет системе, что он сам будет осуществлять маршалинг своих интерфейсов. Если же система в ответ на свой запрос получает E_NOINTERFACE, она пытается выяснить, есть ли у компонента собственный внутрипроцессный обработчик (запрашивая интерфейс IStdMarshalInfo). Выяснив, что и он не реализован, система окончательно переключается на стандартный маршалинг.
Стандартный маршалинг
Вот тут и вступает в действие раздел реестра "HKEY_CLASSES_ROOT\Interface", который мы обсуждали в прошлой статье. Система ищет в данном разделе ключ, соответствующий IID запрошенного интерфейса, и если не находит, мы получаем ответ E_NOINTERFACE. Если же такой ключ существует, возможны два варианта. Если этот ключ содержит подключ ProxyStubClsid32 (ProxyStubClsid для 16-разрядной версии), его значение по умолчанию является CLSID компонента, который служит для маршалинга данного интерфейса. Если же такого подключа нет, система пытается использовать свой собственный маршалер по умолчанию; если он не поддерживает данный интерфейс, также выдается ошибка E_NOINTERFACE.
Посмотрим, чего хотят от этого компонента. Напишем очередной фиктивный dll-сервер (COM_13.asm):
Def-файл и опции ассемблирования те же, что использовались ранее при построении dll-сервера. При вызове DllGetClassObject эта функция отображает окно сообщения, указав запрошенные у нее CLSID и IID и каждый раз возвращая ошибку. Для внедрения этой dll в систему придется опять повозиться с реестром.
В разделе "HKEY_CLASSES_ROOT\Interface" необходимо создать ключ с IID нашего интерфейса ({00000000-0000-0000-0000-000000000002}). Под ним создадим еще два подключа: "NumMethods" со значением 4 и "ProxyStubClsid32" со значением CLSID компонента-маршалера нашего интерфейса; в качестве последнего выберем {00000000-0000-0000-0000-000000000003}. Такой же ключ нужно теперь создать и в разделе "HKEY_CLASSES_ROOT\CLSID", указав в подключе "InprocServer32" полный путь к построенной dll.
Вот теперь снова пробуем вызвать интерфейс IFoo. Как видим, после всех запросов интерфейсов у exe-сервера очередь доходит и до нашего ProxyStub - запрашивается интерфейс, по IID которого можно узнать, что это IPSFactoryBuffer.
Интерфейс IPSFactoryBuffer является своего рода фабрикой классов для объектов двух типов: представителей и заглушек нестандартных интерфейсов. Помимо методов IUnknown, этот интерфейс имеет еще два метода: CreateProxy и CreateStub, создающие соответствующие типы объектов.
Создадим "болванку" для интерфейса IPSFactoryBuffer (COM_14.asm):
Чтобы этот сервер запускался, необходимо изменить путь в соответствующем подключе "InprocServer32".
Как можно видеть, ProxyStub - обычный внутрипроцессный сервер COM, реализующий другой тип фабрики классов. Чтобы и дальше проследить действия системы COM, можно было бы реализовать методы CreateProxy и CreateStub по-настоящему, но здесь мы уже выходим из царства COM и вступаем в царство RPC, а это совсем другой разговор.
Автор: W[4Fh]LF
Дата: 2007-02-17
1. Для чего мы здесь сегодня собрались или о чём на самом деле эта статья?
Навеяло недавней статьёй о COM с этого сайта и его использовании в ассемблере. Всплыла у меня в голове старая задумка: разобрать интерфейс VBScript Regular Expressions 5.5 и использовать все его потрясающие возможности при программировании на ассемблере.
На самом деле, назвать потрясающими возможности этого препроцессора можно с трудом, т.к. он не является самым мощным из всех препроцессоров, скорее являются потрясающими возможности самих регулярных выражений, как средства работы со строковыми данными, которое рано или поздно должно было быть изобретено. Познакомившись с ними уже довольно давно, я по-настоящему стал фанатом регулярных выражений и на данный момент с трудом представляю себе, как можно работать с больших объёмом текстовых данных стандартными функциями, или как можно работать в большом объёме, с любыми объёмами текстовых данных, без использования регулярок. Тем не менее, как показывает практика, очень многие люди до сих пор не пользуются возможностями регулярных выражений в тех случаях, когда их использование даёт огромные плюсы и преимущества. Прежде всего нетривиальные задачи, которые описываются и решаются с помощью кучи циклов, функций и прочих конструкций языка, могут быть описаны и решены очень просто с помощью регулярного выражения(далее просто выражения). Понятно, что это позволяет экономить кучу времени, объёма кода и, что очень важно, нервов программиста. Вдобавок ко-всему прочему, не стоит забывать, что речь идёт о программировании на ассемблере, где все вышеперечисленные плюсы заметны гораздо сильнее. Нет, я конечно понимаю, что мы любим ассемблер за отсутствие каких-либо удобств и предоставления права выбора и контроля всех ситуаций нам. Однако, я считаю, что данный материал будет полезен, в конце-концов, если вы являетесь ярым фанатиком низкого уровня, можете закрыть эту страницу или всё-таки прочесть и иметь право выбора, а главное представление о том, что это такое - регулярные выражения(если такого представления на данный момент вы не имеете).
2. О предмете наших рассуждений или ради чего мы всё это делаем?
Тот, кто знаком с понятием регулярное выражение может смело пропустить эту часть статьи. Разбор синтаксиса регулярных выражений и демонстрирование всех его возможностей - это тема отдельной статьи, если не книги. Ссылки на литературу я дам ниже, здесь же я хотел немного рассказать о том, что это такое и какие проблемы призваны решать выражения. В совокупности, написание регулярных выражений можно назвать программированием на отдельном, небольшом языке программирования, которое в общем случае призвано решать одну задачу: проверка соответствия какой-либо части или всего текста регулярному выражению. Можно сказать, вы задаёте универсальную маску для поиска соответствий в тексте, а на выходе имеете результат: True или False. Конечно, со временем эта возможность обросла другими полезными методами, которые мы рассмотрим в этой статье. Самый простой пример. Допустим, есть у нас некоторая строка, мы хотим проверить, является ли эта строка шестнадцатеричным числом, введённым в С-подобном формате. Ну, представили, сколько это строк на ассемблере?:)
А теперь выражение: ^0x[0-9A-Fa-f]{1,8}&
Я знаю, что поначалу для людей незнакомых с регулярными выражениями эта строка может показаться загадкой. Эта маленькая строчка полностью исключает возможность ввода несоответствующего формату числа. Давайте разберём его, дабы вы поняли, что не всё так страшно: ^ - Этот метасимвол означает начало строки. 0x - эта последовательность говорит о том, что сразу после начала строки должна следовать эта пара символов. Проще говоря, наша строка должна начинаться с этих двух символов. [0-9A-Fa-f] - эта конструкция называется символьным классом. Она определяет, какой символ может идти сразу за парой 0x, а говорит она о том, что после этой пары может идти любой символ из диапазона 0-9 = 0123456789, A-F = ABCDEF, a-f = abcdef. {1,8} - говорит о том, что символ из диапазона, который определён символьным классом ранее, должен повториться от 1 до 8 раз. & - конец строки.
А теперь прочтём это выражение: Вначале строки должны идти символы 0x, сразу за ними должны следовать 1-8 символов из числа тех, которые характеризуют цифры шестнадцатеричной системы, после чего строка должна заканчиваться и не содержать больше в себе ничего. При этом хочу сделать оговорку, если выражение не содержит в себе метасимволов начала и конца строки(^$), то ищется соответствующее маске значение по всём тексте, т.е. текст стоящий до и после числа, значения иметь не будет.
Давайте представим другую ситуацию: допустим, мы знаем, что человек может написать:
• Сегодня 0 градусов Цельсия/Фаренгейта
• Сегодня ноль градусов Цельсия/Фаренгейта
• Cегодня нуль градусов Цельсия/Фаренгейта
Итого мы имеем 6 вариантов правильной последовательности, что бы вы сделали? Вызвали 6 раз lstrcmp? А если бы я сказал, что регистр не играет роли? Ок, ещё пару вызовов функции для преобразования к одному регистру. А если бы я сказал, что между словами могут быть несколько пробелов? Вы бы сказали, что тогда лучше будет использовать поиск по словам, но и это бы выглядело громоздко и довольно некрасиво.
Теперь внимание, регулярное выражение, которое описывает все эти варианты:
"Сегодня +(0|ноль|нуль) +градусов +(Цельсия|Фаренгейта)"
Впечатляет?:) Должно впечатлять.;)
Вы скажете: "Где здесь учитывается непостоянство регистра?", - Мы могли бы конечно это учесть в самом выражении, оно бы выросло ровно в два раза и выглядело не так элегантно. К счастью, для этого препроцессоры обычно предусматривают специальные флаги, о которых будет сказано ниже.
Теперь самое время сказать и о недостатках регулярных выражений. А, собственно, какие недостатки? Недостаток только один: такая гибкость и универсальность налагает определённые условия на время обработки. Нет, за все движки не скажу, но что касается VBScript Regular Expressions, то с уверенностью могу сказать, что он очень хорошо оптимизирован. Само собой реализация под конкретный формат, с небольшим числом вариаций, будет работать быстрее, да собственно оно и понятно, так и должно быть. В общем же случае, я думаю все уже поняли, что возможности, которые предоставляются, позволяют забыть о скорости и в большинстве случаев регулярные выражения всё-таки должны преобладать в задачах направленных на обработку текста. Тем более, что, как правило, задачи которые призваны решать проблемы обработки текста по сложным правилам, в итоге реализуются громоздкими функциями, которые не всегда не то, что быстрее регулярных выражений, а наоборот.
3. Собственно библиотека и разбор интерфейса
Сам компонент VBScript.RegExp находится в библиотеке vbscript.dll, которая поставляется с IE(начиная с 4 версии и выше). Описание методов и свойств этого объекта можно прочесть в MSDN, просмотреть все методы и их id можно с помощью дополнительных утилит(например "OLE/COM Object Viewer" из комплекта VS), но никто нам не говорит о смещениях этих методов в так называемой виртуальной таблице методов объекта, именуемой vftable, о ней будет сказано позже. Языки высокого уровня позволяют абстрагироваться от этого, но чтобы нам получить желаемый результат придётся всё-таки лезть в дебри и исследовать методы вызова. Походу дела я, конечно, буду объяснять, что мы делаем и в чём суть, но всё-таки предполагается, что вы уже знакомы с COM, если нет, то настоятельно рекомендую заглянуть в раздел литература.
Сначала нужно создать копию объекта в памяти, запросить его интерфейс, получить указатель на управляющую таблицу. Создаваемый нами класс именуется VBScript.RegExp и имеет свой идентификатор(CLSID): {3F4DACA4-160D-11D2-A8E9-00104B365C9F} Подробнее описание этого класса можно посмотреть в разделе реестра: HKEY_CLASSES_ROOT\CLSID\{3F4DACA4-160D-11D2-A8E9-00104B365C9F}
На основе всего этого мы имеем достаточно данных, чтобы создать объект и получить его интерфейс, в этом нам поможет следующая функция:
Ключевым моментом является вызов CoCreateInstanceEx, функции, которая принимает следующие параметры:
• rclsid - CLSID класса, объект которого мы хотим получить.
• punkOuter - интерфейс агрегирующего объекта, в нашем случае агрегирование не применяется, поэтому 0.
• dwClsCtx - контекст, в котором будет создан объект. В нашем случае это сервер внутрипроцессорный локальный, поэтому 5(CLSCTX_INPROC_SERVER+ CLSCTX_LOCAL_SERVER).
• pServerInfo - Информация о компьютере на котором создаётся объект. Т.к. в нашем случае создание объекта идёт локально, то 0.
• cmq - Кол-во структур, в массиве, описывающих создаваемые объекты. Мы хотим создать только один объект, поэтому и передаваемое значение будет равно 1.
• pResults - Массив структур MULTI_QI, каждая из которых определена следующим образом:
Теперь пару слов о pIID и GUID_I. Дело в том, что какой бы ни был интерфейс у создаваемого объекта, он наследуется от базового интерфейса в COM - IUnknown(его GUID и содержит переменная GUID_I) и должен реализовывать все его методы. А методов всего 3:
Последние два метода предназначены для управления счётчиком ссылок:
• AddRef - функция инкрементирует счётчик ссылок на объект и возвращает его новое значение.
• Release - функция уменьшает счётчик ссылок на объект. При этом, если значение счётчика обратилось в 0, то объект освобождается из памяти.
Первый метод:
QueryInterface - Данная функция запрашивает интерфейс. Передавая в неё первым параметром GIUD IUnknown, в случае, если такой интерфейс реализуется объектом, во втором переданном параметре(это должен быть указатель на DWORD) на выходе мы получаем указатель на запрашиваемый интерфейс. При этом функция вызывает AddRef , тем самым, инкрементируя счётчик ссылок на объект.
Реализацию этих методов вы можете посмотреть в приложении к статье.
Получилось немного сумбурно, поэтому давайте подытожим:
• Нужный нам объект имеет свой идентификатор класса - CLSID.
• Чтобы создать копию объекта в памяти мы вызываем CoCreateInstanceEx, эта функция создаёт копию объекта с указанным CLSID. Так же функция запрашивает реализуемый всеми COM-объектами интерфейс IUnknown, который имеет стандартный GUID. Метод QueryInterface этого интерфейса запрашивает все прочие интерфейсы реализуемые объектом.
• После вызова этого метода(QueryInterface)1 мы имеем в памяти интерфейс IRegExp, имеем мы его в виде некоторой виртуальной таблицы адресов методов, именуемой vftable. Все реализуемые методы вызываются косвенно, т.е. относительно начала этой таблицы. Теперь наша цель узнать смещения методов относительно начала этой таблицы.
1 Этот метод вызывается CoCreateInstanceEx по умолчанию.
4. Методы, их назначение и использование.
Итак, IRegExp имеет несколько свойств, я бы их назвал флагами, которые характеризуют способ восприятия и обработки входных данных:
• Global - Этот флаг говорит препроцессору, что он должен обрабатывать текст целиком, в ином случае текст будет обработан до первого совпадения.
• IgnoreCase - Регистронезависимый режим, тут всё понятно.
• MultiLine - Говорит о том, что входной текст многострочный, если данный флаг установлен не будет, то переносы строк не учитываются.
Каждое из этих свойств устанавливается аналогично другим, с одним лишь отличием: смещение в vftable у каждого метода будет разным. Вычислив смещение всех методов, я определил их как константы:
Последние две константы тоже вопросов вызывать не должны, они устанавливают в False или True соответствующие свойства объекта.
Теперь процедура, которая работает с этими свойствами:
Процедура принимает два параметра: Method - характеризуется одной из вышеперечисленных констант и является смещением относительно начала vftable; Bool - переменная, которая говорит о нашем намерении установить значение свойства в True или False. Далее, как видно, мы кладём в стек два параметра:
Значение флага.
Указатель на некую управляющую структуру, о ней я могу сказать лишь то, что первым параметром этой структуры является указатель на vftable, а четвёртым счётчик ссылок на объект. Вообще, вызов любого метода принимает минимум один параметр - указатель на эту структуру, поэтому данная конструкция будет использоваться везде.
Теперь в ecx указатель на vftable.
Суммируя смещение vftable со смещением соответствующего метода относительно начала vftable, мы вызываем нужный нам метод.
Хорошо, нужные свойства объекта перед работой мы установили, теперь следует поговорить о методе Pattern, который устанавливает маску поиска. Вызов этого метода реализован следующим образом:
• Expression - указатель на ANSI строку, которая содержит маску поиска, т.е. регулярное выражение.
• lpWideCharStr - Указатель на буфер, который будет содержать преобразованную в UNICODE строку Expression.
• cchWideChar - размер буфера в байтах.
Теперь я объясню для чего нам преобразовывать строку в UNICODE. Всё дело в том, что методы IRegExp работают со строками в формате BSTR, который характеризуется UNICODE строкой и двойным словом перед ней, содержащим длину в символах. Этот тип является родным для VB и поэтому там особых проблем с этим нет, однако, чтобы привести к этому типу ANSI строку нужно преобразовать её сначала в UNICODE, а потом вызвать специальную функцию SysAllocStringLen, которая принимает в качестве параметров указатель на UNICODE строку и её длину в символах, а возвращает указатель на BSTR в памяти.
Вторым параметром у нас идёт указатель на BSTR, который вернула функция SysAllocStringLen, а первый параметр указатель на уже знакомую управляющую структуру объекта.
Опытным путём было установлено, что смещение метода Pattern в vftable равно 20h, вызываем его и освобождаем память от выделенной ранее строки.
На данном этапе мы можем менять свойства, которые влияют на характер обработки текста и можем устанавливать маску поиска. Самое время разобрать методы, которые направлены непосредственно на обработку самого текста. Первым из них является метод Test. Test позволяет сделать поиск совпадений в тексте. Объединив всё нужное в одну функцию получаем:
• lpData - указатель на данные(ANSI) в которых будет осуществлён поиск.
• lpWideCharStr - указатель на буфер, в который будет помещёна преобразованная в UNICODE строка lpData.
• cchWideChar - размер буфера в байтах.
Действия, которые мы проделываем вначале над буфером lpData Вам уже известный, поэтому их пояснять я не буду, а вот с параметрами, передаваемыми в метод, я немного поясню:
Первым в стек попадает указатель на слово. В это слово, после вызова метода Test, будет возвращён результат проверки текста на соответствие маске. Не знаю почему MS сделали этот параметр равным слову, но это так. Ко всему прочему привычные результаты 0 - False; 1- True тут тоже не имеют силы, в данном случае при успешном поиск в Result будет возвращён -1, а при отсутствии совпадений - 0.
Вторым параметром мы кладём указатель на BSTR, его опять же нам вернула уже знакомая функция SysAllocStringLen. И, наконец, последним в стек уходит указатель на управляющую структуру объекта.
Вызываем метод, его смещение относительно начала таблицы равно 40h, далее освобождаем память и обрабатываем результат. Чтобы не изменять традициям и не путаться, я сделал всё привычным образом, т.е. в случае успешного поиска совпадений функция в eax вернёт 1, в случае неудачи 0.
В продолжении хочется рассмотреть обёртку над основным методов Test, метод который именуется Replace. Метод ищет совпадения в тексте по маске и заменяет их на другой текст. Иногда бывает очень полезен, поэтому я решил его разобрать. Метод кажется немного нагромождённым и большим, но на самом деле всё просто.
• lpData - Указатель на данные в которых будет осуществлён поиск совпадений и при необходимости производиться замена.
• lpWideCharStr - Буфер для преобразования lpData в UNICODE.
• cchWideChar - размер буфера lpWideCharStr в байтах.
• ReplaceVar - указатель на ANSI строку которой будут заменены все совпадения в тексте.
• ResultLPSTR - указатель на результирующий буфер. Туда будет записан результат в формате ANSI
• szResultLPSTR - размер буфера в байтах.
Теперь давайте со всем этим добром по-порядку разбираться:
Прежде всего нужно выделить буфер и привести RaplaceVar к типу BSTR. Эта часть кода вычилсяет требуемый размер буфера и выделяет память под него.
После чего мы преобразовываем ANSI строку на которую указывает ReplaceVar в формат UNICODE, далее приводим её к типу BSTR и освобождаем выделенную ранее память, т.к. буфер с UNICODE представлением ReplaceVar нам больше ненужен. В результате bReplaceStr указывает на участок памяти содержащий строку для замены приведённую к типу BSTR.
После чего мы проделываем уже знакомые операции над буфером lpData.
Чтобы было удобней, я буду нумеровать параметры в том порядке, в котором они попадают в стек.
Первым в стек попадает указатель на ResultLPSTR, но после вызова метода Replace он не будет указывать на обработаную строку как может показаться, на самом деле по адресу ResultLPSTR будет лежать указатель на BSTR обработанной строки, я кладу туда его для удобства, т.к. этот указатель всего-лишь промежуточный параметр выделять под него отдельную переменную я не хотел.
Назначение второго, ровно как и четвёртого, параметра мною так и не было установлено, они всегда были равны 0, поэтому я решил не лезть в дебри и смириться.
Третьим в стек попадает указатель на BSTR строки для замены.
Пятый параметр является вероятно каким-то набором флагов, однако и его принадлежность установить не удалось, я всегда передаю туда 8 и пока никаких проблем не возникло, оставим так.
Шестым параметром мы кладём в стек указатель на текст который подлежит обработке, точнее на его "близнеца" приведённого к типу BSTR. Ну и седьмым идёт указатель на управляющую структуру.
Далее следует вызов метода и освобождение уже неиспользуемого буфера.
Ну и заканчивается это всё извелечением указателя на обработанный текст, конвертированием его в ANSI строку, которая будет находится по адресу ResultLPSTR.
5. Механизм в действии или примеры использования
Наверное уже достал всех с описанием всяких методов и интерфейсов, а в деле так ничего и не показал, что ж, сейчас покажу, обо всём по-порядку.
Объединив всё вышесказаное в один файл, именуемый regexp.inc(вы его можете утянуть в качестве приложения к статье) и положив его спокойно в include использовальние выражений становится предельно простым и удобным. Далеко ходить не буду, разберу всё на том же формате представления шестнадцатиричных чисел в С-подобном формате.
А данном примере я вызвал функцию RegExp_Test два раза с одной и той же маской, передавая первый раз валидные данные, а второй раз данные, которые не соответствуют маске. Можете скомпилировать и проверить результат, в обоих случаях на экране появится сообщение с результатом.
Теперь продемонстрирую работу функции RegExp_Replace:
Прежде всего обратите внимание на то, что я немного изменил само выражение, убрав метасимволы начала и конца строки(^$) я говорю препроцессору, что для меня не имеет значение, что стоит до и после выражения соответствующего маске. На момент вызова первый раз функции RegExp_Replace свойство Global установлено в True, что говорит препроцессору о том, что следует осуществить поиск по всему тексту, т.о. как результат мы видим такое сообщение:
После этого я присваиваю этому свойству значение False и в результате мы видим такое сообщение:
Т.е. текст был обработан до первого соответствия маске, всё, что после просто проигнорировалось.
6. Заключение и благодарности
Ну что ж, не знаю насколько был полезен вышеизложенный материал, однако я надеюсь, что он был интересным. Это мой первый опыт в написании подобных статей и поэтому я прошу отнестись с пониманием.
Хотелось бы выразить благодарность человеку с ником December, это очень отзывчивый и приятный в общении человек, спасибо ему за замечания по статье и за указания нужного направления. Остальные же люди просто залажали статью на стадии, когда она ещё только зарождалась, с чем это связано я так и не понял, однако это не отбило охоту дописать данный материал, наверное прежде всего для себя и благодаря December. Если я и не до конца следовал его наставлениям и исправил не всё, что он заметил, то только потому, что не знал как, в силу своего малого опыта в роли автора.
Литература:
1. Фридл Дж. Регулярные выражения (2-е изд.), Питер 2003.
2. 3 кита COM. Кит первый: реестр.
3. Много полезного материала по практической реализации COM можно подчерпнуть из drkb.ru.
4. Known IUnknown.
5. Получение информации о COM-интерфейсах.
В приложении (находится в архиве wasm_files.zip: files/0449/comregexp.zip) к статье вы найдёте файл regexp.inc и небольшой пример использования из статьи.
Автор: vid, пер. DarkWanderer
Дата: 2008-08-29
Как правило, большинству низкоуровневых программистов объектно ориентированное программирование кажется сложным. В этой статье объясняются некоторые моменты ООП и приводятся примеры их устройства с помощью языков C и Assembler.
Замечу, что примеры не всегда сто процентно читаемы, и не всегда правильны. Примеры не подходят для немедленного выполнения, они служат только иллюстрациями к тексту.
Главное достоинство ООП – возможность получить доступ к объектам посредством сходного интерфейса.
Эта мысль поясняется в остальной части статьи.
Простой объект (First object)
Создадим простой объект. Каким он будет? Хороший пример, когда ООП действительно нужно, это разработка игр. Представьте себе, что мы разрабатываем компьютерную игру. В нашей игре будут враги, оружие, ракеты и т.п. Вещи, которые вы привыкли видеть в компьютерных играх. И все они будут представлены как объекты, которые, в свою очередь, как структуры данных в памяти.
Естественно, типов объектов будет множество. Например, аптечка (medikit), для восстановления здоровья игрока, или ружье, из которого можно стрелять. Объектов какого-либо типа в игре тоже может быть много. Все эти объекты могут выглядеть одинаково и вести себя сходным образом, но, в тоже время, отличаться между собой. Иметь, например, различное местоположение на карте (в игровом мире) или отличаться количеством восстанавливаемого здоровья. В терминологии ООП тип объекта называют классом. Тогда объект – это экземпляр какого-либо класса. Характеристики объекта называют свойствами (реже полями).
Внутри каждого объекта сохраним идентификатор, позволяющий установить, к какому классу он относится. В примере это первое поле структуры. Другие поля структуры будут хранить свойства аптечки, это координаты x:y и количество здоровья, которое она восстановит при использовании. Описание аптечки, которая находится в точке [10;15] и восстанавливает 50 пунктов здоровья:
Определим теперь другой объект – бомбу (mine). Она также должна иметь координаты на карте. Но вместо количества здоровья понадобится количество урона, которое она нанесет. Кроме того, бомба имеет еще одну характеристику – время, через которое она сработает после активации. Объект может выглядеть следующим образом:
Методы (Methods)
Когда игрок встретит в мире один из таких предметов, мы получим сообщение об этом вместе с указателем на структуру данных, описывающих объект. Тогда мы прочитаем первое поле и узнаем, к какому классу относится встреченный объект. Если это аптечка, мы восстанавим здоровье игрока. А если бомба, начнем отсчет до взрыва.
Этот подход прост, но имеет недостатки. Части кода, где происходит обращение к объекту, могут быть разбросаны по всей программе. И если мы хотим изменить что-то в описании класса (изменить структуру данных, описывающую объект), мы должны изменить все места, где происходит обращение к объекту. Это неудобно, вдобавок, можно легко допустить ошибку.
Будет лучше, если мы сгруппируем код. Напишем функции, которые будут работать с объектами и сохраним их в одном месте. В нашем примере есть функция, восстанавливающая здоровье игрока при использовании аптечки, и другая функция, активирующая взрыватель при использовании бомбы.
Функции, которые работают с объектами, называют методами.
Виртуальные методы (Virtual Methods)
Однако, такой подход тоже нельзя назвать идеальным. Если нам понадобится добавить новый класс или новый метод, придется сделать слишком много исправлений. Но мы можем разместить указатель на метод внутри самого объекта. Тогда, вызывая метод мы не будем определять тип объекта, а сразу вызовем функцию:
Инкапсуляция
Здесь мы подошли к основному принципу объектно ориентированного программирования. Согласно нему объект закрыт для других объектов, а взаимодействие осуществляется только через методы. То есть, если другому объекту потребуется узнавать, сколько пунктов здоровья восстанавливает аптечка (чтобы отображать на экране, например) мы напишем еще одну функцию-метод, которая будет возвращать значение свойства hp. Если другому объекту потребуется изменять это свойство, мы также добавим еще один метод. Быть может, это кажется излишней расточительностью, но оно оправдывает себя. Разработав класс мы можем возвращаться к его коду только если хотим что-то добавить (есть специальные средства, чтобы не делать даже этого). А все взаимодействие сводится к вызову однажды разработанных методов, которые не изменяются вместе с измененным классом. Это также позволяет лучше организовать разработку больших программ. Однажды договорившись о взаимодействии классов программисты могут разрабатывать их независимо друг от друга.
Принцип объект-черный ящик называют инкапсуляцией.
Виртуальные таблицы (Virtual Table)
Давайте создадим другой метод, назовем его 'shot', он будет обрабатывать выстрел игрока по объекту. Теперь объекты аптечка и бомба выглядят следующим образом:
Вот примеры этого метода. 'medikit.shot' снижает запас здоровья в аптечке в два раза, а 'mine.shot' взорвет бомбу (таймер устанавливается на ноль).
Хранить указатели на методы удобно, но ведь для всех объектов одного класса они одинаковы. Будет лучше, если мы создадим статичные таблицы для каждого класса. Тогда внутри объекта можно будет хранить только указатель на такую таблицу. Кроме того, таблица будет уникальной для класса, а значит, хранить тип объекта тоже не нужно.
Заключение
Хотя ООП поддерживается многими языками программирования на уровне архитектуры, сам по себе метод является лишь парадигмой (методологией) программирования; наряду с такими методами, как процедурное программирование. Его назначение - обеспечить более удобную разработку больших проектов.
Автор: Star0, пер. Aquila
Дата: 2002-06-27
Я думаю, вы, как и я, смотрели на эти OpenGL'ные демки, как двигаются по экрану полигоны, меняются различные эффекты и так далее. Также, вполне вероятно, вы не очень сильны в математике и не хотите самостоятельно выводить все эти математические синусоидальные процедуры. OpenGL - это классная библиотека, которая позволит вам создать 3D-вселенную очень быстро, двигать ее и наложить серию спецэффектов, используя простую концепцию API.
В наши дни есть два основных вида программирования под OpenGL, в зависимости от операционной системы, которую вы используете. Обычный путь состоит в использовании glut-библиотеки, чтобы задавать анимацию, которая совместима с linux, win32, sgx-станциями и т.д... Другой путь - эт чистый win32. В последнем случае используются обратный вызов win32-клинта, чтобы переключиться на следующее изображение. Как бы то ни было, результат одинаков. Мы будем рассматривать программирование под win32. Поэтому для использования OpenGL вам сначала нужно инициализровать процедуру окна.
Процедура окна обычно обрабатывает все системные события, которые направляются текущему (отображаемому или нет) окну. Этот принцип очень хорошо работает для GUI и уменьшает количество потребляемых машиной ресурсов.
Для инициализации процедуры окна вам требуется определить класс, небольшую структуры, в которой задается различная информация, например адрес процедуры окна. Это очень легко сделать:
Как только вы зарегистрировали класс, вам необходимо создать свою процедуру окна
Это просто: один вызов функции API
Это правильно, но если вы вызовите его таким образом, приложение может повиснуть, почему? Потому что мы еще не создали процедуру окна.
Процедура окна получает 4 аргумента. Первый - это хэндл окна. Второй - это сообщение. Третий - это нижний параметр, а четвертый - это верхний параметр.
Так как Windows работает в C-подобной среде, аргументы лежат на стеке. Поэтому к ним легко получить доступ. Также вам потребуется позаботиться о некоторых регистра, не модифицировать ebp, например, или ваша программа будет закрыта.
Ваша процедура окна должна перехватывать некоторые сообщения, которые заданы как win32-константы. Давайте взглянем, на что похожа процедура окна.
В силу определенных причин некоторые сообщения принимаются, а некоторые посылаются. Поэтому вам нужно, чтобы текущить тред принимал сообщения, что стоит довольно мало ресурсов. Поэтому не паникуйте. Этот код достаточно общий, он может меняться от программиста к программиста, но делает он примерно одно и то же.
Как только ваша процедура окна инициализирована, вам требуется синхронизировать ее с OpenGL.
Сейчас у нас есть зарегистрированный класс, созданное окно и маленькая оконная процедура. Но теперь нам нужна помощь OpenGL, чтобы инициализировать систему, графику и множество других вещей. Нам необходимо будет делать их в два момента времени: при создании окна и при обновлении экрана.
Во-первых, вам нужно инициализировать пиксельный формат, который будет использоваться как двойной графический буфер. Для этого вам необходимо использовать PIXELFORMATDESCRIPTOR, это длинная и скучная структура, в которой нужно заполнить тольконесколько полей
Если результат равен 0, вызов API не удавлся, и пользователь не может отобразить разрешение. В противном случае вы можете напрямую установить пиксельный формат.
тогда это равно пиксельному формату. Получить текущий DC очень просто:
и eax равен текущему DC. Нам также требуется создать контекст OpenGL из этого DC.
Если eax == 0, то вызов не удался и лучшее, что мы можем сделать - это послать WM_CLOSE, чтобы благополучно закрыть приложение.
Далее мы синхронизируем оба контекста:
Сделано, OpenGL был проинициализирован, теперь вы можете наложить ряд эффектов, но прежде, чем сделать это, вы должны из разрешить. Делается это так:
Вы также можете попробовать другие значения: GL_DEPTH, G_LIGHTING.
Когда Windows закончила с инициализацией, она шлет сообщение WM_SIZE, которое озанчает, что настало время пофиксить все, связанное с графикой. Разрешение экрана посылается в lParam. Поэтому сначала устанавливаем порт просмотра.
После этого нам нужно определить модель матрицы, я не буду давать урок математики о матрицах и трансформациях, но как обычно это очень легко:
После этого мы вызываем функцию glLoadIndentity:
Затем мы вызываем библиотеку GL-эффектов, чтобы добавить перспективу порту просмотра. Эта функция принимает только числа двойной точности. Компилер может инициализировать такое число так:
А вот макрос, облегчающий загонку таких чисел в стек:
Теперь передадим необходимые параметры порту просмотра.
Перспектива - это необходимый аспект нашего 3D-мира. Перспектива бывает разных видов, например как при обзоре через камеру наблюдения или обзор сцены в формате 16/9.
И, опционально, вы можете установить модель теней для сложной 3D-сцены, установите ее в GL_F:AT, это может ускорить рендеринг изображения.
Вот и все с этим.
Windows говорит процедуре окна, что настало время обновить текущее изображение с помощью сообщения WM_PAINT.
Первое, что нужно сделать - это обновить текущее изображение с помощью сообщения WM_PAINT.
Теперь мы можем установить порт просмотра в виде камеры. У этой камеры есть 9 операндов.
Эти операнды также двойной точности, поэтому используйте pushdl, чтобы использовать эту функцию.
А теперь надо отрисовать окружение. Можно сделать много вещей: установить свет, тени, прозрачность, искажения и так далее.
Давайте сделаем такую простую вещь:
glColor3d и glVertex3i существуют во многих форматах. Последняя буква задает тип переменной, который вы хотите использовать. glVertex3d означается, что вы используете аргумент двойной точности.
Когда окружение построено, вы можете закончить это так:
И буфер окажется на экране.
Часто люди удивляются, почему их продукция отображается на экране очень странно. Причина проста: OpenGL не интересуется другими элементами, расположенными на экране, поэтому н может перерисовать их... Вы можете установить тест глубины во время создания окна:
Некоторые люди хотят полноэкранное разрешение, это можно сделать в два шага, меняя разрешение дисплея:
Не правда ли, это очень легко?
Автор: Chris Hobbs, пер. UniSoft
Дата: 2002-10-22
Я уверен, что многие из вас, уже задумывались о создании игр.
Многие из вас провели немало часов в интернете, в поисках какой-либо информации о том,
как писать игры на чистом ассемблере. Но, к сожалению, такой информации почти нет, а тем более на русском.
Я думаю, что этот туториал пополнит ряды русскоязычной документации и надеюсь,
что он вам понравится.
Этот туториал посвящен разработке игры полностью на ассемблере.
В нем будет рассмотрен широкий круг вопросов - от структурированного кода до графических аспектов.
В широком смысле - для тех, кто хотел бы научиться тому, чего возможно не знал прежде...
Да и вообще мало кто знает, что полностью виндовское приложение можно написать на чистом ассемблере.
Единственное требование - это способность читать.
Однако, если вы желаете писать и транслировать исходный код,
то вам понадобится компилятор MASM 6.12+. Вы также можете скачать пакет MASM32,
в котором есть все, что вам понадобится.
MASM32v7 можно взять здесь:
• http://www.movsd.com/ или
• http://wasm.ru/tools/7/masm32v7.zip или
• http://spiff.tripnet.se/~iczelion/files/masm32v7.zip.
Общеизвестно, что любой компилятор генерит код, в котором неизбежно присутствуют баги.
Ассемблер - трудный язык как для понимания, так и для написания, что особенно справедливо для
DOS'а.
С приходом Windows многое меняется.
В чтении труден не только ассемблер, даже в
Cи бывают такие дебри, что сам черт ногу сломает.
Читабельность исходников зависит от квалификации программиста и умения комментировать код.
Вообще-то тут еще надо разобраться, что сложнее: сложить 2 переменные на ассемблере или
проследить иерархию какой-нибудь виртуальной функции? Здесь комментарий решает все.
Помните: то, что известно вам, не значит, что это же известно другим.
Далее, проблема в переносимости. Предоставленный язык ассемблера не переносим на другие платформы.
Есть, конечно, способ обойти это, который позволяет вам писать код для любой x86 платформы,
но его описание не входит в рамки этого туториала.
Большинство игрушек пишутся под винды. Это означает, что код привязан к DirectX и к WIN32API,
следовательно вы не сможете переносить код, во всяком случае, без некоторой доработки.
Конечно, ассемблер труден в понимании. На этой странице будут показаны его основы.
Писать ассемблерный код под Windows, особенно с MASM, очень просто.
Это подобно написанию некоторого кода на C. Попытайтесь, и я уверен, что вы не будете разочарованы.
Если Вы уже знакомы с языком ассемблера под windows, то можете пропустить этот раздел.
Он является важным дополнением. Для его обсуждения, предполагается,
что вы по крайней мере знакомы с x86 архитектурой.
Первое, что вам нужно понять, это команды (инструкции).
• MOV
Эта инструкция копирует значение из одного места в другое.
Вы можете копировать только из регистра в регистр, из памяти в регистр или из регистра в память.
Но с помощью этой инструкции, вы не можете копировать напрямую из памяти в память.
В первой строке число 30 копируется в регистр EAX. Во второй строке регистр EAX копируется в регистр EBX.
В 3-ей строке регистр EAX копируется в память. В 4-ой строке регистр EAX копируется в то место памяти,
куда УКАЗЫВАЕТ пойнтер my_var , причем префикс DWORD указывает на то, что пересылаются 4 байта.
• ADD & SUB
Эти две инструкции выполняют сложение и вычитание, соответственно.
Прибавляем 30 к содержимому регистра EAX,
а затем вычитаем полученное значение из регистра EBX.
• MUL & DIV
Эти две инструкции выполняют умножение и деление, соответственно.
Рассмотрим пример: сначала загружаем в EAX=10 и в ECX=30.
EAX по умолчанию всегда один из 2-х сомножителей,
посему третья команда (в ней вы явно указываете второй сомножитель) перемножает EAX и ECX.
Результат от умножения (произведение) будет находится в EAX:EDX.
Перед выполнением деления, сначала Вы должны очистить регистр EDX, что и делает команда XOR,
выполняя исключающее ИЛИ с самим собой. После деления, целая часть результата будет находится в EAX,
а остаток (если есть) в EDX.
Вообще инструкций очень много, но этих пока достаточно для начала.
Вероятно мы будем использовать и некоторые другие, но их не сложно понять,
если только вы поняли основные. Теперь нам нужно разобраться с правилами вызова функций.
Мы будем использовать стандартные правила, такие же как Win32 API. Что это значит, а то,
что мы помещаем параметры в стек справа налево и нам также не надо будет заботиться
об очистке стека от параметров, все это будет для нас прозрачно.
Для вызова функции мы будем использовать псевдо-оператор INVOKE.
Далее, есть одна проблема с вызовом функций Windows.
Чтобы использовать invoke, вы должны иметь прототип функции.
Вообще, MASM обеспечивает высокий уровень синтаксиса при написании.
В нем есть конструкции, позволяющие писать логику If-Then-Else и циклы For loops
аналогично сишным конструкциям.
А теперь пришло время для проектирования игры. Этим процессом часто пренебрегают и сразу кидаются
кодировать то, что пришло в голову. Хотя такой подход иногда и проходит,
но чаще всего проваливается.
Как говорится, сначала было слово. Для написания игры нужно представить в голове,
как она будет работать. Иногда просто полезно описать СЛОВАМИ то, что вы хотите видеть в своей игре.
Простая часть закончена, теперь нужно продумать все детали. Будут ли в игре элементы соревнования?
Нужны ли опции сохранения/загрузки? Сколько уровней? Что должно происходить в конце уровня?
Имеется ли вводный экран? И еще много, много вопросов.
После этого нужно будет приниматься за наброски уровней. Какой должен быть экран и интерфейс?
Это не обязательно должно быть точно так, но это даст реальную картину,
как должна выглядеть финальная версия игры.
Всегда имеет смысл насыщать код возможно большим количеством комментариев, чем лично я, например,
всегда пренебрегаю.
Далее следует примерная схема организации ассемблерного игрового кода:
* * *
Вот мы и подошли к концу первой статьи.
А теперь хорошая новость - весь скучный материал в основном позади.
Есть еще и плохая новость - вы не видели код, который будет в
следующей статье. :)
Автор: Chris Hobbs, пер. UniSoft
Дата: 2002-10-29
• На чем мы остановились?
• Синтаксис MASM
• Основной игровой цикл
• Связь с Direct Draw
• Наша Direct Draw Library
• Наша Bitmap Library
• A Game ...
• В следующей статье...
-- > На чем мы остановились?
В прошлой статье были рассмотрены основы Win32 ASM программирования, основы создания игр, и сам процесс разработки. Пришло время зайти немного дальше. Сначала я расскажу о высокоуровневых конструкциях MASM, которые являются удобоваримыми в сравнительном смысле с аналогичными конструкциями на Си. Затем рассмотрим основной цикл и главные оконные процедуры. После чего обратим внимание на Direct Draw и вызовы связанные с ним. Поняв, как это работает, мы сможем построить свою собственную Direct Draw Library, после чего построим свою bitmap file library и в конце напишем программу, которая отображает экран 'Loading Game' и выходит из нее по нажатию клавиши Esc.
Для компиляции вам потребуется пакет MASM32, или по крайней мере MASM 6.11+.[
-- > Синтаксис MASM [
Досовские варианты ассемблерных листингов представляют в своем большинстве собрание весьма неудобоваримых сочинений, порой непонятных даже квалифицированным программистам. Очень много меток, jmp-ов и прочей нечисти. Но asm не стоит на месте, и в MASM 6.0 макро-конструкции становятся неотъемлемым инструментом разработки.
MASM ныне - такой же легкий в чтении язык, что и Си. Это, конечно, только мое мнение. Давайте теперь рассмотрим некоторые Си-шные конструкции и их аналоги в MASM.
• IF - ELSE IF - ELSE
• DO - WHILE
• WHILE
Это все - примеры рабочих конструкций, и как вы видите они чрезвычайно просты. При компиляции, MASM скомпилирует в коде, все те же нужные метки, jmp-ы, cmp-конструкции.
Есть еще и другие вещи, которые нам следует обсудить, это псевдо-операторы которые позволяют нам легко определить процедуры/функции, такие как PROTO и PROC. Использовать их очень легко. Для начала, также как и в Си, вам нужно иметь прототип. В MASM это делается с помощью ключевого слова PROTO. Вот несколько примеров объявления прототипов для ваших функций:
Вышеупомянутый код сообщает ассемблеру, о двух новых процедурах WinMain и WndProc. Каждая из них имеет список параметров связанных с ними. В каждой функции задаются 4 параметра (DWORD). Для тех кто использует пакет MASM32, то в нем уже есть прототипы всех Windows API функций, вам просто нужно подключить соответствующий файл. Но вам надо убедиться, что все пользовательские процедуры определены вышеупомянутым способом.
Породив прототип, мы можем породить и саму функцию с помощью ключевого слова PROC:
При такой записи имеется доступ ко всем параметрам функции. Не правда ли - слишком просто для Winmain?
-- > Основной игровой цикл
Теперь, когда мы все знаем, как писать на ассемблере, давайте приступим к написанию основного игрового цикла.
Начнем с WinMain().
Единственное, что здесь может оказаться немного странным [
А теперь сам код:
Давайте проанализируем. Обратите внимание: при инициализации локальной переменной (в нашем случае это структура WNDCLASS), в начале функции не нужно никакой возни со стеком push/pop, также как и в ее конце, за вас все сделает компилятор. Вы должны только объявить локальные переменные, как в Си. Далее, заполняем структуру значениями. Обратите внимание на использование макроса m2m. Это потому, что ASM не позволяет напрямую копировать из памяти в память, без использования регистра или стека в качестве посредника.
Далее, создаем окно и прячем курсор, так как он нам в игре не нужен. Показываем окно и вызываем Game_Init(). Если внутри процедуры Game_Init() произошла ошибка, то ее результат будет FALSE. Проверяем результат процедуры Game_Init() и в случае ошибки выходим из программы (прыгаем на метку shutdown). Вообще, при отладке asm-процедур всегда нужно помнить, что должна быть одна точка входа и одна точка выхода.
Дальше идет цикл сообщений (message loop), которые могут поступать откуда угодно. Если бы это была обычная программа, а не игра, то мы бы использовали GetMessage() для приема сообщений из очереди. Но здесь есть одна проблема, если нет никаких сообщений, то функция будет ждать, пока придет какое-нибудь сообщение. Это совершенно не подходит для игры. Нам нужно постоянно выполнять главный игровой цикл, независимо от того, придут ли какие-либо сообщения или нет. Есть один путь обойти это - использовать PeekMessage(). PeekMessage() возвращает ноль, если нет никаких сообщений, иначе вернет сообщение из очереди.
Обратите внимание, что главный игровой цикл (Game_Main), будет вызываться всегда, независимо от того, пришло ли какое-либо сообщение или нет. Если бы мы этого не сделали, то Windows мог бы обработать кучу сообщений, в то время, как главный игровой цикл - ни разу.
И в конце, когда мы получаем сообщение quit, мы выходим из цикла и соответственно завершаем программу.
-- > Связь с Direct Draw
Мы не будем рассматривать сам DirectX на уровне асм-а, а рассмотрим его на уровне основных концепций.
Прежде всего, необходимо понять саму концепцию Таблицы Виртуальных Функций. Делается запрос в нее в форме смещения, и получается АДРЕС расположения функции. Т.е. под вызовом функции понимается обращение к таблице, которая УЖЕ существует. Адреса функций имеются в DirectX-библиотеке.
Далее, необходимо определить адрес объекта, для которого вызывается функция. Вычисляем виртуальный адрес и сохраняем в стеке все параметры. Для этой цели существуют различные макросы, в частности, DD4INVOKE еще из 4-го DirextX.
Сначала определяем имя функции, затем имя объекта и параметры:
В этом примере создается поверхность, вызовом функции CreateSurface(), передавая ей в качестве параметров: указатель на объект, адрес структуры Direct Draw Surface Describe (ddsd), адрес переменной для хранения указателя на поверхность, и наконец NULL. Теперь, когда мы увидели, как делать запросы к DirectX, давайте построим небольшую библиотеку.
-- > Наша Direct Draw Library
Нам понадобятся функции для инициализации и выхода из игры, для определения формата пикселя, создания и прорисовки поверхностей, и загрузки в нее битмапа.
Далее код функции инициализации:
Рассмотрим подробнее.
Сначала создаем так называемый default Direct Draw object с помощью функции DirectDrawCreate(). Это не более, чем простой вызов функции с несколькими параметрами. Это еще не виртуальная функция. Поэтому мы можем вызывать ее с помощью INVOKE. Также, обратите внимание, что мы потом проверяем на ошибку. Это очень важно в DirectX!!! В случае ошибки, мы просто выводим сообщение, и переходим на метку err: в конце процедуры.
Далее делаем запрос на получение DirectDraw4 object. После чего устанавливаем режимы экрана с помощью SetCooperativeLevel() и SetDisplayMode(). Не забывайте проверять на ошибки, после каждого вызова функций.
На следующем шаге создаем первичную поверхность (primary surface), и в случае успеха создаем back buffer. При этом полученную структуру надо очистить с помощью макроса DDINITSTRUCT, который я включил в файл Ddraw.inc.
После, вызывается процедура для определения формата пикселя для нашей поверхности.
В следующей процедуре мы получаем формат пикселя:
Сначала, инициализируем структуру description, а затем делаем вызов из Direct Draw для получения surface description. Возвращенные маски мы разместим в глобальных переменных для их дальнейшего использования. Маска это значение, которое мы можем использовать для установки или очистки некоторых бит в переменной или регистре. В нашем случае маски используются для того, чтобы получить доступ к red, green, и blue - битам пикселя.
Следующие три секции кода используется для определения числа битов для каждой цветовой компоненты. Например, если нам нужен цветовой режим 24 bpp, то на каждую компоненту нужно отводить по 8 бит. Делается это путем битового сдвига вправо и операции AND.
В случае установки 16-битного режима, переменная Is_555 становится TRUE для режима 5-5-5, или FALSE для режима 5-6-5.
И еще одна функция - для прорисовки текста. Она использует GDI:
Далее, получаем контекст устройства (DC) для нашей поверхности - это первая вещь, которую нужно получить при рисовании. Устанавливаем background mode и цвет текста с помощью все той же Windows GDI - и мы готовы рисовать текст с помощью вызова TextOut(). После чего освобождаем DC.
Далее, напишем код для наложения bitmap.
-- > Наша Bitmap Library
Нам нужны 2 процедуры: для загрузки битмапа и его прорисовки. В данном случае рассматривается уникальный формат файла.
Этот формат, вероятно один из самых простых, с которым вы когда-либо столкнетесь. Он состоит из 5 основных частей: Width, Height, BPP, Size of Buffer, Buffer. Первые 3 дают информацию о самом образе. В данном случае применяется режим 16 bpp.
Сначала создаем файл, а потом выделяем для него память и читаем данные. После размещения файла в памяти определяем размер буфера.
Далее функция загрузки. Читаем 3 байта и определяем значение переменной ( 5-6-5 или 5-5-5 ) для буфера, после чего сохраняем ее там. Каждый пиксель битмапа конвертируем, для чего используется макрос.
После конвертации мы возвращаем буфер с отконвертированными пикселами.
После загрузки в память битмап можно нарисовать в back buffer:
Общеизвестно, что обращение к регистрам осуществляется намного быстрее, чем к памяти. Поэтому адреса источника и приемника мы размещаем в регистрах.
Затем вычисляем количество WORD-значений, которое делим на 2, и получаем количество DWORD-значений. Вообще, используем 640 x 480 x 16. Число 320 разместим в регистре ECX. Делаем классическое REP MOVSD. Двигаем DWORD-ми, вычитаем из ECX по 1, сравнивая с ZERO, если нет, то MOVE A DWORD, до тех пор пока ECX не станет равен 0. Все это здорово смахивает на Си-шный for со счетчиком в ECX. Повторяем 480 раз - по количеству строк.
Теперь осталось все это вывести на экран.
-- > A Game ...
Итак, функции библиотек мы написали, и теперь готовы приступать к основному коду игры. Начнем с инициализации, так как она выполняется в начале нашей программы:
Эта функция играет важную роль в нашей игре. В этой функции мы делаем вызов процедуры инициализации Direct Draw и в случае успеха загружаем с диска наш битмап. Далее беремся за back buffer и рисуем в него наш битмап. После чего делаем флиппинг видимого и невидимого буферов.
Далее у нас на пути функция WndProc, которая, как известно, обрабатывает сообщения. Если мы захотим добавить обработку еще какого-либо сообщения, то код его обработчика войдет именно в эту функцию.
Я думаю этот код не требует пояснений. Пока мы имеем дело только с 2-мя сообщениями - WM_KEYDOWN и WM_DESTROY. Мы обрабатываем сообщение WM_KEYDOWN для того, чтобы пользователь мог выйти из игры по нажатию клавиши escape. Обратите внимание, что те сообщения, которые мы не обрабатываем, обрабатываются функцией DefWindowProc(). Эта функция уже определена в Windows. Вы только должны вызвать ее всякий раз, когда не обрабатываете сообщение.
И далее процедура завершения:
Итак, здесь мы выгружаем Direct Draw library, и освобождаем память, которую выделяли под битмап.
-- > В следующей статье...
В следующей статье мы познакомимся с программированием Direct Input. А также создадим свое меню.
Счастливого кодирования!!!
Автор: Chris Hobbs, пер. UniSoft
Дата: 2003-02-22
-- > От переводчика...
По вашим многочисленным просьбам продолжаю перевод этой серии туториалов.
И начнем с того, что же такое DirectInput и для чего он нужен? DirectInput был создан с целью решить проблемы со скоростью ввода. То есть это компонент, который получает данные ввода от пользователя с различных устройств (клавиатура, мышь, джойстик и т.д.) в обход операционной системы.
Итак, основные преимущества:
• Максимальное быстродействие
• Поддержка дополнительных устройств (например, с обратной связью)
• Получение текущего состояния даже без фокуса ввода
• Получения информации из драйвера в обход настроек операционной системы (например, автоповтор)
-- > Так, и на чем же мы остановились в прошлой статье? Если я правильно помню, то в прошлой статье, мы написали код, который выводит загрузочный экран игры. Это значит, что у нас уже есть DirectDraw и Bitmap библиотеки, но это еще не все. А для обработки ввода с клавиатуры, вместо DirectInput, мы использовали сообщение WM_KEYDOWN.
Давайте продолжим. Сначала нам нужно создать DirectInput library. После этого напишем несколько процедур для синхронизации. Затем разработаем код для меню. -- > Direct Input Вы готовы? Отлично! Код DirectInput имеет почти тот же формат, что и код для DirectDraw.
Давайте рассмотрим код подпрограммы обработки чтения с клавиатуры. (В прилагаемом исходнике также имеется код для обработки мыши, но так как в нашей игре мы ее не используем, то в этих статьях я не буду затрагивать эту тему.)
Начнем с... думаю стоит начать с процедуры инициализации DirectInput.
Этот код совсем не сложный. И начинается он с создания основного объекта DirectInput, вызовом DirectInputCreate(). Это объект, который используется для получения всех объектов устройств.
Вот ее описание:
DirectInputCreate( HINSTANCE hInst, DWORD dwVer, LPDIRECTINPUT *lplpDI, LPUNKNOWN pU) ;
• hInst - Дескриптор экземпляра приложения или DLL.
• dwVer - версия объекта DirectInput. Использование DIRECTINPUT_VERSION позволяет использовать версию по умолчанию.
• lplpDI - указатель на указатель интерфейса, который примет в себя информацию.
• pU - указатель наследования или агрегирования COM. Нас он не интересует - достаточно передать NULL.
Затем вызываем процедуры инициализации клавиатуры и мыши.
А теперь посмотрим на саму процедуру инициализации клавиатуры:
Первое, что делает эта процедура, это пытается "создать" устройство, от которого мы хотим получать данные (в нашем случае, это клавиатура, но может быть и мышь, и джойстик, и т.д.). Для его создания воспользуемся функцией CreateDevice():
CreateDevice(REFGUID rg, LPDIRECTINPUTDEVICE *lplpDI, LPUNKNOWN pU);
• rg - уникальный идентификатор устройства. Для стандартных устройств заранее определены значения: GUID_SysKeyboard для клавиатуры; GUID_SysMouse для мыши. Остальные идентификаторы устройств (например джойстики) можно получить вызовом EnumDevices().
• lplpDI - указатель на указатель интерфейса, с помощью которого мы будем впоследствии работать с устройством.
• pU - все то же агрегирование.
[Примечание переводчика]
Получив указатель на интерфейс устройства, устанавливаем уровень доступа. Несмотря на то, что DirectInput сам устанавливает уровень доступа по умолчанию, лучше эту функцию все-таки вызвать, но важно определиться заранее - какой доступ необходим.
Уровни доступа:
• Эксклюзивный (exclusive)/Совместный (non-exclusive) - первое чем хорош эксклюзивный режим, это тем, что он "подавляет" большинство системных комбинаций (кроме Alt+TAB и Alt+Ctrl+Del, кстати говоря - есть и отдельный флажок при установке уровня кооперации запрещающий системные комбинации Windows), позволяя обработать нажатие, скажем, Ctrl+Esc. Следует помнить, что ни одно приложение не сможет получить эксклюзивного доступа к устройству, если такой доступ уже был получен другим приложением, однако сможет получить совместный.
• Активный (foreground)/Фоновый (background) - при фоновом доступе приложение сможет читать данные с устройства даже когда окно приложения не активно. В случае же активного доступа приложение сможет читать данные, только если его окно обладает "фокусом" (активно).
Уровень доступа устройства устанавливается вызовом SetCooperativeLevel(). HRESULT SetCooperativeLevel ( HWND hwnd, DWORD dwFlags );
• hwnd - Дескриптор окна связанный с устройством.
• flags - Флаг совместного доступа:
• DISCL_BACKGROUND - Приложение использует устройство когда имеет фокус ввода
• DISCL_FOREGROUND - Приложение может использовать устройство даже когда не активно
• DISCL_EXCLUSIVE - Монопольный доступ к устройству
• DISCL_NONEXCLUSIVE - Приложение не требует монопольного доступа
Приложение должно обязательно определить DISCL_FOREGROUND или DISCL_BACKGROUND и DISCL_EXCLUSIVE или DISCL_NONEXCLUSIVE.
После того как установлен уровень кооперации, обязательно нужно установить формат данных. Смысл установки формата данных в том, чтобы указать какие части устройства (например кнопки мыши) будут использоваться. Функция SetDataFormat() получает всего один параметр - указатель на структуру описывающую формат данных для устройства. Для стандартных устройств заранее определены глобальные переменные: c_dfDIKeyboard, c_dfDIMouse, c_dfDIMouse2, c_dfDIJoystick, c_dfDIJoystick2. Итак - формат данных установлен - DirectInput знает тип устройства.
И последнее - как и в случае с DirectDraw, когда приложение могло "потерять" память поверхностей - приложение DirectInput перед чтением данных с устройства должно "захватить"(Acquire) его. При чтении данных обязательно проверьте результат - приложение может "уступить" (Unacquire) устройство, например, при потере фокуса приложением (Кстати, это происходит автоматически, если приложение имеет "активный" доступ к устройству). Для захвата и освобождения устройств существуют функции Acquire() и Unacquire() соответственно.
А теперь мы готовы использовать то, что написали. Давайте теперь посмотрим на саму процедуру чтения клавиатуры:
А здесь мы сначала проверяем, верно ли получен интерфейс устройства. Если нет, то это могло произойти по некоторым причинам, например, отсутствует или не подключена клавиатура, неисправен сам порт, и т.д. Это, вряд ли, случится, но все же лучше убедиться.
Ну а если, интерфейс устройства получен верно, то получаем данные с устройства (в нашем случае с клавиатуры).
По умолчанию клавиатура использует непосредственные (не буферизированные) данные - для того, чтобы прочитать состояние клавиатуры нужно воспользоваться функцией GetDeviceState(). Параметрами для этой функции в случае непосредственных данных, будет являться размер массива (равный 256) и указатель на массив из 256 байт для данных о всех клавишах. Для удобства работы, для каждого индекса массива, в файле "DInput.inc" определены константы с именами клавиш, например: DIK_J, DIK_N, DIK_ESCAPE, и т.д.
Для определения нажата ли клавиша, достаточно проверить соответствующий ей байт, и если он имеет значение TRUE (или не равен 0), то значит клавиша нажата:
От переводчика. Обратите внимание, как автор проверяет, нажата ли клавиша. Если значение не равно 0, то считается, что клавиша нажата.
Так, конечно, работать будет, но в официальной документации по DirectX всё же говорится, что мы должны проверять только старший (последний) бит байта, и только если он установлен, то считать, что клавиша нажата.
Таким образом, правильнее было бы написать вот так:
Ну ладно, не будем задерживаться на мелочах и пойдем дальше.
На очереди у нас процедура завершения DirectInput:
Что же собственно делает эта процедура?
По завершению приложения мы должны "убрать за собой" - "уступить"(освободить) все устройства (которые захватили при инициализации), и удалить объекты DirectInput вызовом Release().
В действительности, DirectInput - одна из самых простых частей DirectX. И мы разобрались, как с ней работать. Теперь нам не обязательно зависеть от "оконной" процедуры и сообщений Windows - мы можем в любом месте программы и в любой промежуток времени прочитать данные с устройства.
Вот и все, теперь у нас есть все, что нам нужно для создания системы меню. Но прежде, чем мы этим займемся, давайте разберемся с синхронизацией.
-- > Синхронизация и Виндоуз
Тот, кто только что написал или начал писать свою первую игру обязательно обнаружит, что на компьютерах с разной конфигурацией или частотой процессора его игра будет работать по-разному. Кто-то сгоряча начнет добавлять циклы задержки. Ха! А теперь представьте, как это будет выглядеть на более медленных машинах? Кто-то будет определять или запрашивать частоту процессора... Все это неверно, ведь производительность зависит не только от ЦП. А как же тогда? Ответ прост, да и наверное вы его уже знаете - отталкиваться от пройденного времени.
Для определения времени в Windows можно воспользоваться следующими вызовами:
• GetTickCount() Функция kernel32.dll (ядро) возвращает количество миллисекунд прошедших с момента старта Windows. Возвращаемое значение переполняется приблизительно через 49,71 дней и отсчет начинается снова (это надо учитывать!).
• timeGetTime Функция winmm.dll(мультимедия-API) является копией функции GetTickCount. Возможно регулирование точности возвращаемого значения - снижение точности более 1 миллисекунды. [примечание] по утверждению автора эта функция более точная и надежная, чем GetTickCount
• Ну а если нужна большая точность, то можно воспользоваться вызовами QueryPerformanceFrequency и QueryPerformanceCounter, или как их еще называют, счетчиком производительности. Но, к сожалению, он поддерживается не всеми системами, а точнее процессорами. По сути это 64-х битный счетчик тактовых импульсов процессора (по моему он называется TSC), который есть в последних x86-совместимых процессорах (в Celeron и Pentium точно есть). По Микрософтовской документации функция QueryPerformanceCounter считывает в предоставленную Вами 64-битную переменную значение TSC, если он есть, либо 0, если его нет. А если быть немножко поточнее, то функция QueryPerformanceCounter возвращает не количество тактов процессора, а количество тиков, каждый из которых равен примерно 0,838 мкс. Хотя перед тем, как пользоваться этой функцией, нужно с помощью QueryPerformanceFrequency узнать частоту инкремента этого счетчика для данного компьютера (также 64-х битное значение). [примечание] Автор этой статьи, называет его высокоэффективным таймером (High Performance), отсюда и в названии переменных, связанных с этим таймером, присутствует аббревиатура HP.
Итак, для начала нам потребуется процедура инициализации нашей системы синхронизации - Init_Time() :
Эта процедура определяет, поддерживает ли установленное аппаратное обеспечение счетчик производительности, и в случае успеха, возвращает его частоту. Для чего и используется функция QueryPerformanceFrequency.
Вот ее описание:
BOOL QueryPerformanceFrequency ( LARGE_INTEGER *lpFrequency );
• lpFrequency - указывает на 64-х битную переменную, значение которой, в отсчетах в секунду, функция устанавливает в текущую частоту счетчика производительности. Если установленное аппаратное обеспечение не поддерживает счетчик производительности, значение этого параметра может быть равно нулю.
• Возвращаемое значение: В случае, если установленное аппаратное обеспечение поддерживает счетчик производительности, возвращается ненулевое значение (TRUE). В случае, если установленное аппаратное обеспечение не поддерживает счетчик производительности, возвращается нуль (FALSE).
Теперь предположим, что счетчик производительности у нас есть, тогда код сохраняет его частоту и подсчитывает количество тиков в миллисекунду.
Следующая функция - Start_Time(). Эта функция используется, для запуска таймера с переданным ей значением. Она будет использоваться, для управления скоростью смены кадров.
А вот собственно и сам код...
Этот код очень прост. Если счетчик производительности у нас доступен, то вызываем QueryPerformanceCounter(), а если недоступен, то вместо него вызываем timeGetTime().
Что же делают эти функции?
Функция QueryPerformanceCounter(), вот ее описание: BOOL QueryPerformanceCounter ( LARGE_INTEGER
• lpPerformanceCount - указывает на 64-х битную переменную, которую функция устанавливает в текущее значение счетчика. Если установленное аппаратное обеспечение не поддерживает счетчик производительности, этот параметр может быть установлен в нуль.
Функция timeGetTime(), вот ее описание: DWORD timeGetTime (VOID);
• Функция возвращает текущее системное время в миллисекундах.
И еще одна, последняя процедура Wait_Time(). Это однотипная процедура для Start_Time(). И вместе они используются для управления скоростью смены кадров, нашей игры.
А вот и сам код:
Эта процедура возможно самая сложная из описанных ранее. Что же она делает? Она ожидает прохождения определенного промежутка времени (переданного вторым параметром), от начального времени (переданного первым параметром). Другими словами, например, начальное время у нас было 100мс, и мы указали ожидать 50мс, то процедура не вернет управление, пока текущее время не станет больше или равно 150мс. Процедура возвращает время, затраченное на ее выполнение.
Вот и все о синхронизации, теперь мы можем перейти к нашему меню.
-- > Меню
Создание меню в игре, может быть довольно сложным занятием. Но, в нашем случае это будет легко. Основная идея состоит в том, чтобы обеспечить возможность выбора процесса в игре. В большинстве случаев, меню состоит из фонового битмапа и битмапа - "указателя", для выбора пункта меню. Я все же решил сделать это немного по-другому. Вместо "указателя", мы просто назначим соответствующие клавиши каждому пункту меню.
Есть еще одна важная вещь, это выбор типа системы меню. Вы хотите, чтобы код вошел в "цикл меню" и не возвращал управление, пока пользователь не сделает выбор? Или, Вы хотите вызывать функцию меню снова и снова? В случае с Windows, второй тип в миллион раз лучше, так как нам нужно обрабатывать сообщения. Если мы составим программу первым способом, то представьте, что произойдет, если пользователь нажмет "ALT+TAB". Возможно программа повиснет. (ПРИМЕЧАНИЕ: в игре пока нет поддержки "ALT+TAB ".... но это будет реализовано в более поздних выпусках!). Так что, будем использовать второй тип системы.
В процедурах инициализации и завершения, нет ничего, чего бы вы не видели ранее. Все, что они делают, это загружают два фоновых битмапа для нашего меню. Один из них для главного меню, а второй для файлового меню. А процедура завершения просто освобождает выделенную под них память.
Интересный код находится в процедурах Process_XXXX_Menu(). Давайте подробно рассмотрим одну из них, процедуру Process_Main_Menu(). Ну, и как обычно, вот ее код:
Интересная процедура, не так ли? Ну хорошо... возможно и нет. И что же она делает?
Начинается она с блокировки фоновой поверхности (back buffer), и прорисовки на ней битмапа меню. Затем разблокируем фоновую поверхность, и переключаем поверхности, для того, чтобы мы могли ее увидеть.
Вот мы и добрались до вызова одной из наших DirectInput процедур, до вызова процедуры DI_Read_Keyboard(). Эта процедура, как вы помните, получает состояние всех клавиш на клавиатуре. После ее вызова, мы проверяем, были ли нажаты интересующие нас клавиши. Если да, то возвращаем значение соответствующее нажатой клавише. Например, если пользователь нажимает клавишу 'N' для новой игры, то мы возвращаем значение MENU_NEW вызывающей программе. Эти значения известны и определены в начале модуля.
А если же ничего нажато не было, то мы просто возвращаем значение MENU_NOTHING. А если при выполнении кода произошли ошибки, то возвращаем значение MENU_ERROR.
Тот же метод используется и для процедуры Process_File_Menu(). Вот мы и связали код DirectInput с нашей системой меню. Все, что нам осталось сделать, это связать меню с кодом таймера. -- > Связываем все вместе
Вот мы почти и закончили. Пришло время связать все, что мы написали и поместить в один пакет. Так что давайте начнем с процедуры инициализации игры.
Эта процедура претерпела некоторые изменения, с тех пор, как вы ее последний раз видели. Сначала мы добавили несколько вызовов: один для инициализации нашей системы синхронизации, один для инициализации нашей системы меню, и еще один для инициализации нашей DirectInput библиотеки. А также, в конце процедуры, мы освобождаем память, выделенную под битмап загрузочного экрана. Это сделано для того, чтобы не использовать зря память, под битмап, который нам больше не понадобится. И еще одна вещь, на которую стоит обратить внимание, это то, что мы добавили глобальную переменную GameState, которая хранит текущее состояние игры, а также указывает главному игровому циклу, какое состояние обрабатывать. В конце процедуры инициализации игры, мы устанавливаем эту переменную в значение GS_MENU.
Вот собственно и все, что было изменено в процедуре инициализации. А в код завершения были добавлены вызовы процедур завершения для модуля DirectInput , и для модуля меню. А еще, мы должны сделать изменения в процедуре главного игрового цикла. Фактически, нам достаточно просто заменить старую процедуру новой, так как, с прошлых уроков она была пустой (помните, мы ее просто зарезервировали, но не использовали?).
А вот и сам новый код процедуры главного игрового цикла:
Первое, на что вы должны обратить внимание, это то, что код расположен между вызовами процедур Start_Time() - наверху, и Wait_Time() - внизу. Эти процедуры управляют скоростью кадров в нашей игре. Я сделал так, чтобы было 25 FPS (т.е. 25 кадров в секунду), или 40 миллисекунд.
Далее мы имеем одну большую конструкцию IF-ELSE, которая выбирает нужные действия, исходя из значения глобальной переменной GameState , которую мы специально и определили для этой цели.
Новый игровой цикл, это просто менеджер состояний. Он выполняет соответствующий текущему состоянию код. Все игры имеют нечто похожее в их ядре.
-- > До следующего раза ... Ура! Вот у нас и готов хороший, чистый каркас для игры, в котором фактически не хватает самого игрового кода. Но, для этого вам придется ждать следующей статьи. -- > В следующей статье...
В следующей статье мы охватим еще некоторый расширенный материал. Также сделаем упор непосредственно на сам игровой код, включая: основу анимации, "цикл", и, ... как обычно, ... что-нибудь еще, что придет в голову.
Другая вещь, о которой я должен упомянуть, состоит в том, что эта игра является неполной. Я знаю, что это очевидно, но многие из Вас вероятно задаются вопросом, почему нет никаких переходов, звуков, или "крутых спецэффектов" в игре. Ответ ..., потому что я и не стремился к этому. Но, если честно, то я планирую охватить это все. Ну, а для тех из Вас, кто более продвинут, и думает, что я иду слишком медленно, потерпите. Хороший материал впереди... Я обещаю.
--> Готовый исходник для этой статьи, можно взять здесь...
А для его компиляции вам также понадобятся LIB'ы DirectX, которые можно найти в DirectX SDK, либо скачать здесь... или здесь....[от переводчика]
P.S. Вот и все, наконец-то я выкроил время и перевел 3-ю часть (а всего их 6 !!!) данного туториала, и в будущем, планирую перевести остальные 3. Я также, хотел бы поблагодарить всех, кто откликнулся на прошлые статьи. P.S.S. В интернете очень много статей о том, как писать вирусы, и почти совсем нет информации о том, как создавать красивые игры, демо-сцены (демки), заставки и т.д., как реализовать некоторые алгоритмы, например: вода (Java апплет - Lake помните такой? А как такое же сделать на ассемблере под windows? Никто не задумывался?), как реализовать jpeg/mpeg/mp3 декодер, как реализовать огонь и многое другое (имеется в виду под windows и на чистом ассемблере)? Нет, есть конечно некоторые исходники реализации плазмы, огня и т.д., но ведь в них почти нет никаких комментариев, и начинающему демо-мэйкеру разобраться в огромных листингах кода очень тяжело.
Так почему же такой информации очень и очень мало, по сравнению с информацией о создании вирусов??? Да потому, что вирусы гораздо легче писать, правда я не понимаю для чего? Неужели вам станет легче, если кто-то пострадает от вашего вируса??? У всех вирусов почти один и тот же алгоритм: открыть файл, дописать в него тело вируса, закрыть файл, ну и возможно выполнить какие-нибудь деструктивные действия (типа убить инфу на винте), или стырить чей-нибудь пароль к интернету и т.д. А вот чтобы реализовать какой-нибудь видеоэффект, то тут надо сильно постараться, возможно даже подучить (или вспомнить) математику, геометрию, физику... к тому же, это намного интереснее! Это надо как-то исправлять!!! Надо учить начинающих ассемблерщиков не созданию вирусов, а созданию чего-нибудь более стоящего. Ох, что-то меня на философию потянуло... надо завязывать. И к чему я все это рассказываю? Ах да, если у вас есть свои разработки, свои программы, свои игры, которыми вы могли бы поделиться с людьми, то присылайте их мне (мой e-mail ниже), желательно с подробным (или хотя бы с кратким) описанием.
А также по всем вопросам (
e-mail: unis2@mail.ru, Andrey aka UniSoft Вот теперь все!!! До скорых встреч!!! Счастливого кодирования!!!
* * *
Автор: keYMax
Дата: 2003-02-26
Предисловие.
Привет всем ! Сидел я как-то в инете и наткнулся на сайт www.vvsu.ru/dkscs, а там, на цикл статей Дениса "Mr.Snow" Кожухова ( в данный момент сайт переехал на Xdev.ru ). Статьи были посвящены программированию Direct3D 8.1 на языке C++. Посмотрел я на них и подумал, а что если забацать тоже самое, но на MASM. Решение пришло из-за того, что меня несколько удивляет факт наличия в инете множества исходников на асме, использующих OpenGL, и совсем мало использующих Direct3D, да и то старых версий ( может я не там искал ? ). Конечно, OpenGL это рулез, скажете вы, а Microsoft c его DirectX полный отстой и мастдай форева. Таких "товарисчей" я попрошу сразу удалиться даже не читая дальше. На мой взгляд, DirectX не такой уж плохой API и на нем тоже можно что-нибудь состряпать, поэтому я постараюсь в меру своих сил и возможностей опубликовать цикл уроков по Direct3D 8.1, на этом сайте ( если организаторы позволят ;) ).
В общем, всем кому интересно прошу далее....
Урок 0. Создаем каркас приложения WIN32 для будущих экспериментов !
Чтобы было с чего начинать, я написал каркас приложения, который буду использовать во всех следующих уроках. Из каркаса я выбросил все лишнее, чтобы все внимание сосредоточить на работе с DIRECTX и не отвлекаться на всякие WinMain и прочую ерунду.
Первое, что я сделал, это вынес структуру класса в секцию DATA и сразу заполнил то, что можно. Меньше кода и более понятно я думаю.
Во-вторых, я убрал функцию WinMain. А также написал цикл обработки сообщений командами ассемблера, а не псевдокомандами .IF .ELSE и т.д.
В третьих оставил только два события: CREATE и DESTROY.
В итоге совсем немного текста !
Исходник прилагается (находится в архиве wasm_files.zip: files/0230/dx8masm00.zip).
Всем пока до следующего урока :)
В следующем уроке мы создадим объект DIRECT3D и осуществим небольшой опыт, чтобы проверить его работоспособность.
Авторство принадлежит Пономареву Михаилу ака keYMax.
Все вопросы и ругательства слать по адресу mybox@aib.ru
Автор: keYMax
Дата: 2003-03-01
Самое главное, что нам потребуется для работы с DirectX это заголовочные файлы и библиотеки. Можно взять их из Microsoft DirectX SDK 8.1. Все, что нам оттуда нужно, это только папка LIB. У меня не было возможности взять SDK с компакта, а качать более 100 метров ради пары десятков файлов полный идиотизм. Хоть мелгомягкие и запрещают выкладывать какие либо части их SDK, находятся еще добрые люди на свете и набрав в поисковике искомое мы всегда получим парочку адресов. Все ленивые могут посмотреть по адресу упомянутому мною в предыдущем уроке. До последнего момента там было то что нам нужно.
Так как SDK рассчитан на работу с языком C++, то заголовочные файлы необходимо адаптировать. Не переживайте. Для данных уроков я уже адаптировал все необходимые файлы и надеюсь, работа будет продолжена. Адаптированные INC файлы включены в исходник уроков, забирайте и пользуйтесь. Формат библиотек является родным и для С++ и для MASM, поэтому библиотеки подходят без проблем. Ну вот и все приготовления и прежде, чем мы перейдем собственно к нашему уроку, хотелось бы еще упомянуть, что все относящееся к DirectX я буду сопровождать подробной справкой. Справка является моим корявым переводом справочника из SDK, поэтому не ругайте меня за возможные ошибки.
Все что у нас сейчас имеется это приложение, при запуске выводящее на экран окошко размером 320х240, и нам надо заставить работать в этом окне Direct3D. Как это сделать? Нет ничего проще!
Первое что мы добавим это подключение необходимых файлов:
Теперь обьявим необходимые переменные и структуры:
Справка
Далее создадим три процедуры Init_Direct3D, Destroy_Direct3D и Render_Scene
итак Init_Direct3D
Создаем обьект Direct3D8:
Справка
Затем мы получаем информацию о текущих параметрах экрана:
Справка
Заполняем только те поля структуры которые нам необходимы:
А сейчас делаем самое главное ! Создаем устройство Direct3DDevice8.
Создавать Direct3DDevice в сообщении WM_Create нельзя ! ( проверено опытным путем :) )
То же самое можно найти в документации по Direct3D8.
CreateDevice мы должны передать hwnd полностью созданного окна на экране которое находится в фокусе.
Справка
Теперь наше устройство создано и настало время написать функцию Render_Scene !
итак Render_Scene
Для простого примера применим очистку backbuffer`а цветом и показа его на экране:
Справка
А теперь все покажем этой функцией
Справка
Откомпилировав и запустив это приложение, вы увидите, что оно работает. Но это еще не все. После того как наше приложение будет закрыто, нам необходимо удалить все созданные нами интерфейсы и занятые ими ресурсы. Для этого создадим функцию Destroy_Direct3D.
итак Destroy_Direct3D
На этом позволю себе откланяться. До следующих встреч !
Исходник прилагается (находится в архиве wasm_files.zip: files/0231/dx8masm01.zip).
PS
В следующем уроке мы рассмотрим запуск приложения в полноэкранном режиме, а также связанную с этим проблему потерянного устройства.
Авторство принадлежит Пономареву Михаилу ака keYMax.
Все вопросы и ругательства слать по адресу mybox@aib.ru
Автор: keYMax
Дата: 2003-03-07
Урок 2. Запуск приложения в полноэкранном режиме.
Привет ! Сегодня мы научимся запускать приложение в полноэкранном режиме. Но сначала о некоторых упущениях с моей стороны :(. В самом первом уроке, где представлен каркас приложения, присутствует ошибка, проявляющаяся в Windows 98 . При запуске окно не появляется на экране и программа висит в памяти ( у меня так было, когда решил проверить программу под Win 98 ). В Windows XP такой проблемы нет. Все из-за того, что я неосторожно обошелся с параметром hCursor в структуре WNDCLASSEX, поместив ID обычной стрелки сразу, а не получая его от Windows в процессе работы приложения. Чтобы ликвидировать это недоразумение, необходимо перед RegisterClassEx вставить следующие строчки:
После этого у меня все заработало :). Можно их и не писать, а занести в hCursor ноль, но тогда в окошке будет курсор в виде часов. Также можно курсор вообще отрубить. Не сомневаюсь, что, если у вас возникла эта проблема, вы сразу разобрались. Однако лучше обьявить об ошибке поздно, чем никогда. Чтобы избежать досадных багов в будущем, я буду проверять работу приложений и в 98 и в XP ( к NT и 2000 у меня доступа нет ).
Теперь комментарии к уроку номер 1.
Как вы могли заметить, я не проверяю коды возврата при вызове функций Direct3D, кроме тех случаев где это действительно необходимо. Конечно это плохо, если возникнет ошибка, то придется долго искать какая функция не сработала. Решение принято для того, чтобы меньше засорять исходник ( вы и сами можете добавить обработку ошибок ). Результатом такого шага является или идеальная работа приложения, или его полная неработоспособность при запуске. Аппаратура также бывает разная, и то, что работает на моем ускорителе, может не работать у вас. Особое внимание прошу обратить на CreateDevice и передаваемые ей значения, например, D3DDEVTYPE_HAL, D3DCREATE_SOFTWARE_VERTEXPROCESSING и т.д. Тоже самое относиться и к другим важным функциям. Если видеокарта не поддерживает какие-то параметры, то запуск приложения закончится крахом. В общем, в случае неудачи пробуйте и экспериментируйте, а не ругайте дядю, который написал хрен знает что ( сам иногда ругаюсь, если не получается ;) ). Cпециально для таких случаев я и привожу подробную справку.
Хотелось бы заметить еще об одной важной детали: включаемые файлы INC. Начиная с этого урока, я буду включать в исходник только те INC файлы, которые необходимы именно для него. Советую собрать их все в одной папке ( у меня это \MASM32\DirectX81\ ) и в исходнике менять мои пути на ваши ( это относиться и к LIB файлам ). Внутри каждого INC файла есть дата его последней правки. Так что смотрите и своевременно заменяйте их на более свежие ( они будут вкладываться в исходник в обязательном порядке ).
Ну вот вроде бы ничего не забыл. Переходим к уроку...
Запуск приложения в полноэкранном режиме почти не отличается от запуска в окошке. Все что нам нужно, это заполнить несколько новых параметров в структуре D3DPRESENT_PARAMETERS. Соответственно берем первый урок и после небольших изменений все готово.
В оригинальном хелпе рекомендуется создавать окошко таким размером, какое разрешение мы хотим включить. Т.е. включаем 640х480 - значит создаем окошко 640х480 и т.п. Также его рекомендуется помещать на экран в координаты 0,0.
Для большей наглядности я прописал содержимое структуры D3DPRESENT_PARAMETERS в секции DATA. Описание ее было в предыдущем уроке.
Для нас важно занести в нее следующее:
Формат поверхности я взял D3DFMT_X8R8G8B8. Можете использовать любой другой, который нравится. Число BackBuffer'ов равно 3, годится и 2. SwapEffect тоже выбирайте на вкус. В поле Windowed обязательно надо занести 0. В FullScreen_RefreshRateInHz ставите число герц, поддерживаемое данным режимом ( главное не переборщить ). Ну и PresentationInterval не забудьте.
Далее все как обычно: создаем устройство и работаем.
Вроде бы, на первый взгляд, все отлично. Но стоит нам нажать ALT+TAB, переключаясь на другую задачу, и затем снова перейти к нашему приложению, то возникнет небольшая проблема. Называется она "проблемой потерянного устройства" или LostDevice и решается легко. Всего то надо добавить пару лишних строчек кода.
Пишем в функции Render_Scene:
Справка
Проверяем устройство на кооперацию, если оно потеряно, то мы ничего поделать не можем и выходим из функции. Если устройство не потеряно, то проверяем его на предмет сброшено оно или нет. Если оказывается что оно не сброшено, то тогда сбрасываем его. Вот и все.
Добавив эти строчки, мы можем смело переключаться с задачи на задачу, и при возвращении в наше приложение все будет восстанавливаться и работать дальше !
Напоследок предлагаю вам небольшую задачу.
Данный кусок кода выполняется в функции Render_Scene всегда. Т.е. если у нас приложение выдает, например, 1000 FPS, то проверка потери устройства происходит 1000 раз. Такой расклад никуда не годится, потому что реально устройство оказывается сброшеным только тогда, когда мы нажимаем ALT+TAB и переключаемся на другую задачу. Отсюда вывод: надо сделать так, чтобы проверка осуществлялась вне цикла отрисовки сцены, а конкретно в сообщении, когда приложение получает, например, фокус и только тогда сбрасывать устройство.
Я пробовал такой вариант и он почти работоспособен. Вам его не предлагаю, так как он имеет маленькое неудобство. Если кто-то сможет решить задачу, то я с удовольствием бы взглянул на результат.
Вот и все.
В следующем уроке мы создадим диалог для определения всех доступных режимов экрана, и тогда приложение будет по настоящему правильным.
P.S.
Все еще только начинается ...
Мужики, вы чего такие стеснительные. Не верю, что всем все нравиться. Высказывайте свое мнение. Учту его при дальнейшей работе.
Успехов всем в труде и обороне :)
Все вопросы мыльте сюда mybox@aib.ru
Автор: keYMax
Дата: 2003-03-26
Урок 3. Создаем диалоговое окно для определения всех доступных режимов.
Как определить все доступные полноэкранные режимы и при этом сделать так, чтобы пользователь смог выбирать в каком режиме работать приложению ? В этом нам поможет диалоговое окно.
Если вы уже знаете, что такое диалоговое окно и представляете, как оно выглядит, как его создать и как с ним работать, то все равно советую вам почитать эту статью. Тем же, кто плохо понимает, что это за зверь такой, следует дополнительно посмотреть статьи на эту тему.
Готовы ? Тогда вперед !
Диалоговое окно в нашем приложении можно реализовать двумя путями. Первый путь - это встроить его в само приложение. Второй путь - это реализовать его как самостоятельное приложение. Что выбрать ? Оба варианта имеют свои плюсы и минусы.
Среди плюсов первого варианта то, что оно находится внутри нашего приложения. При этом нам нужно написать не такой уж большой обьем кода. Также все настройки, выбранные пользователем, доступны немедленно. Среди минусов то, что при каждом запуске приложения пользователю приходиться выбирать настройки.
Реализация второго варианта несколько сложнее. Нужно создавать два экзешника. Один для диалогового окна, другой - собственно для приложения. При этом все настройки, произведенные пользователем, придется записывать в файл. Но зато появляется возможность переделывать Setup снова и снова, не трогая при этом приложение, ведь всё равно все настройки сохраняются в файле.
В итоге каждый вариант подходит для определенных задач. Например, для какой - нибудь демки встроенное диалоговое окно самое то. А вот для игрушки - наоборот. Можно также придумать какой нибудь гибрид. Я долго размышлял какой вариант использовать для урока и в конце концов решил сделать оба, чтобы у вас была возможность сравнить. Это потребовало довольно много времени, и как следствие, урок был готов гораздо позже, чем было запланировано. Мы с вами рассмотрим только второй вариант, так как он немного сложнее.
По плану нам требуется: определить все доступные оконные режимы, определить все доступные полоноэкранные режимы, запихать всю эту информацию в диалоговое окно, вывести его на экран, обработать все действия пользователя, сохранить настройки в файле и при выходе из Setup запустить само приложение если требуется. Вроде бы целая куча работы, но на самом деле все гораздо проще.
Начнем с файла ресурсов. Берем любой редактор, пара минут и все готово. Кратко рассмотрим по частям, как он должен выглядеть.
Здесь у нас константы, в частности, номера от 10 до 24 - это идентификаторы элементов нашего диалогового окна. Они будут нам передаваться в сообщениях от Windows, так мы сможем узнать с каким элементом в данный момент работает пользователь.
Здесь имя диалога, его вид и размер, параметры вывода на экран, текст заголовка и используемый шрифт.
Между строками BEGIN и END располагаются строки, описывающие элементы расположенные на диалоговом окне. Здесь определены два RadioButton, три ComboBox, одно текстовое поле, одна рамка и три простых кнопки.
А вот и исходный текст Setup.exe:
Еще после SetupDialog находится текст функции DW2A. Я не стал ее тут приводить, т.к. она является слегка измененной dw2a из библиотеки masm32. Интересующиеся всегда смогут посмотреть ее в исходнике.
Теперь все разберем по косточкам.
Массив WinModeTable содержит размеры шести определенных нами окошек. Он также нужен нам для сравнения с текущими размерами рабочего стола. Массив WinModeStrTable содержит указатели на текстовые строки. Эти строки впоследствии будут занесены в ComboBox оконных режимов.
В массиве FullModeTable число 50 является количеством всех полноэкранных режимов, которые мы можем поместить. Я, на всякий случай, сделал его с запасом. Вообще, когда мы спрашиваем Direct3D о количестве доступных режимов он возвращает нам огромное их число, куда входят режимы с одинаковым разрешением, но с разным числом герц и форматом поверхности. Например, на моей видюхе он выдает 90 доступных режимов. Чтобы не возиться с разной частотой я решил определять только те режимы, в которых число Герц максимально. В результате мы ничего не теряем, т.к. при выборе настроек включать частоту в 60, 70 и т.п. Герц все равно никто не будет. Взяв на вооружение этот факт, мы сокращаем число режимов до двух - трех десятков (Примечание: В Win98 Direct3D выдает вместо числа Герц ноль, поэтому, если занести в структуру D3DPRESENT_PARAMETERS определенную частоту, а не ноль, то создать устройство не удастся). В массиве FullModeStrBuffer мы будем формировать строку вида: 1024х768х32 и затем заносить ее в ComboBox.
Invoke DialogBoxParam,400000h,ADDR szDialogName,NULL,OFFSET SetupDialog,NULL
Наш диалог из ресурсов вызываем вот такой строкой где 400000h - это hInstance.
Ну вот добрались до самого главного: определения доступных режимов. Вначале, устанавливаем отметку на RadioButton "В окошке" и снимаем с "Полноэкранное". Затем получаем ID всех наших ComboBox'ов. ( Примечание: При выходе из обработки сообщения INIT_DIALOG, когда мы уже возвращаем EAX=1 и передаем управление системе, в Win98 происходила ошибка. На мой взгляд, причина кроется в каких - то регистрах, которые мы изменили в процессе работы. Используя PUSHAD при входе и POPAD при выходе, этот баг можно ликвидировать. Что касается XP, то ему, похоже, до лампочки есть PUSHAD, POPAD или нет. )
Создаем Direct3D, получаем текущие параметры рабочего стола посредством GetAdapterDisplayMode. Так как мы помещаем данные в D3DPRESENT_PARAMETERS, нам придется провести небольшую манипуляцию, занося формат поверхности с четвертого поля структуры на третье. В четвертое поле заносим число BackBuffer равное трем. Сделав это, часть D3DPRESENT_PARAMETERS мы уже сформировали. Далее идет цикл на сравнение суммы текущих ширины и высоты с суммой размеров записанных нами в WinModeTable. Одновременно с этим заполняем ComboBox.
Далее получаем количество всех доступных полноэкранных режимов и уменьшаем его на единицу, т.к. нумерация начинается с нуля.
С загрузки адреса массива начинается цикл сравнения и заполнения его доступными полноэкранными режимами. Каждый раз, уменьшая номер режима и вызывая EnumAdapterModes, мы спрашиваем данные у Direct3D. Затем берем полученные ширину и высоту, складываем их и прибавляем к этой сумме формат поверхности. Сравниваем с предыдущим значением суммы и, если таковой у нас нет ( это значит новый режим ), заносим всю информацию по разным массивам, и начинаем формировать строку в буфере, чтобы ее можно было занести в Combobox. Соответственно, если эта сумма есть, то ничего заполнять нам не нужно.
Здесь у нас идет формирование строки. Функцией DW2A преобразуем значения в текст, добавляем иксы. Проверяем ID формата и то что получилось добавляем в качестве окончания строки. Теперь нам только осталось занести эту строку туда куда нужно и все. Это мы и делаем, посылая сообщение СomboBox. А далее снова на начало цикла. На первый взгляд все отлично, но есть здесь одно маленькое но - проверка на формат. Осуществляя сравнение с 24 и 32 битным форматом мы считаем все другие форматы 16-битными. Как мне кажется, это не столь важно. Сколько я ни запускал программу на разных видюхах, будь то ATI или NVIDIA они мне выдавали только 2 формата: D3DFMT_A8R8G8B8 и D3DFMT_R5G6B5 ( вроде эти :) ). Глубже лезть и выяснять, почему такое есть, мне неохота.
Последними командами устанавливаем выбранными первые строки в каждом из ComboBox и обработка WM_INITDIALOG завершена. Но впереди не менее увлекательное занятие: сделать так, чтобы все работало как единое целое. Приступаем к рассмотрению обработки события WM_COMMAND. В нем мы проверяем ID всех элементов и, в зависимости от результата, переходим на нужную метку.
Здесь у нас идет включение одних ComboBox и выключение других. Срабатывает это дело только, когда тыкнуть мышкой на одну из RadioButton.
А это срабатывает, когда нам нужно обновить содержимое ComboBox, содержащего информацию о частоте. Мы все стираем, берем номер выбранного элемента в ComboBox, содержащего доступные полноэкранные режимы, и по нему получаем из массива частоту. Преобразуем ее к удобному варианту и заносим в ComboBox.
Окончательное формирование D3DPRESENT_PARAMETERS, плюс сохранение всех настроек в файле. Поздравляю 90% работы позади. Сюда мы попадаем, если пользователь нажал кнопку "Сохранить". Ну значит проверяем какая RadioButton выделена и идем по нужному пути. Если "В окошке", то поле Windowed равно 1 и стиль окна WS_SYSMENU. Если "Полноэкранное", то берем номер выбранной строки в ComboBox полноэкранных режимов и уже от этого пляшем. Хватаем из массивов размеры, формат поверхности, частоту и в структуру все укладываем. Поле Windowed равно нулю, а стиль окна будет WS_POPUP. Окончательный штришок в виде SwapEffect и можно все записывать в файл.
Если мы хотим чтобы из диалога вызывалась еще и программа, то нужно написать следующее.
Закрываем диалог. Освобождаем все связанное с Direct3D. Затем получаем путь по которому лежит наш Setup посредством GetModuleFileName. На всякий случай размер буфера под путь равен 260 байт ( если не ошибаюсь это максимальный размер пути в окошках ). Вот мы получили путь, но в нем присутствует и имя нашего Setup. Как его убрать ? Делаем цикл для проверки на '\' ,начиная от конца пути. Найдя его, копируем на место следующего за ним имя файла, который хотим запустить. А дальше все просто. ShellExecute с командой open в качестве параметра, и приложение запущено по нашему приказу, а работа самого Setup завершена.
Осталось только написать текст самого приложения. В нем реализовать загрузку сохраненных настроек и на их основе запускать Direct3D. Описывать здесь я это не буду, лучше гляньте исходник.
Ну все, пора закругляться, а то и так много понаписал, да и чего - то под конец статьи совсем туго соображать стал.
PS: В следующей статье ждите полноценное трехмерное приложение с матрицами, векторами, полигонами и прочей математикой.
Да и не забудьте глянуть в папку Include там лежат файлы d3d.inc и d3dcaps.inc окончательной версии.
Исходник обоих вариантов прилагается (1, 2 (находится в архиве wasm_files.zip: files/0234/dx8masm03b.zip)).
Все вопросы мыльте сюда mybox@aib.ru
Автор: keYMax
Дата: 2003-05-19
Урок 4. Первое полноценное трехмерное приложение.
Основы трехмерной графики. Как это все работает. Я расскажу вам как устроен механизм визуализации в DirectX, и вы научитесь использовать в своей работе простые полигоны.
1. Система координат
2. Формат вершин
3. Полигоны
4. Что такое сцена. Как Direct3D работает с трехмерным миром.
5. Камера
6. Z буфер
7. Все знания применим на деле !
8. Послесловие
Предисловие
Как вы знаете, вся трехмерная графика основана на математике. "Линейная алгебра", "Векторная алгебра и начала анализа", "Начертательная геометрия" и еще много чего другого необходимо усвоить прежде чем приступать к успешной работе с 3D. Конечно, это не так интересно, но все равно придется этим заниматься. С вашей стороны необходимо всего лишь желание, а я в свою очередь постараюсь рассказать все как можно проще и доступней на примерах и картинках. Кому не терпится перейти сразу к делу начинайте с пункта 7.
1. Система координат
Начнем с самых основ. Загадочная буква "D" в словах 2D и 3D расшифровывается как Dimension - измерение. Соответственно 2D - это 2 измерения, а 3D - три. 2D представляет собой обычную систему координат на плоскости, которая знакома всем еще со школы. А что представляет собой 3D ? Это та же система координат, только к ней добавляется еще одно измерение обозначаемое как Z. На рисунке изображены обе системы.
Из рисунка видно, что новая координата Z отвечает за то, насколько далеко находится от нас какой - либо обьект. Обе системы координат ( 2D и 3D ) существуют в двух разных вариантах - левосторонняя и правосторонняя. Разница между ними в направлении отсчета. В левосторонней X и Y увеличиваются слева направо, а в правосторонней справа налево. Соответственно координата Z тоже меняет свое направление. На рисунке изображены как раз левосторонние системы. Direct3D позволяет использовать ту, которая вам нравится. Я, как все нормальные люди, буду использовать стандартную левостороннюю систему.
2. Формат вершин
Точка, точка, запятая - вышла рожица кривая. Самое простое, что существует в геометрии - это точка. В трехмерном пространстве точка трактуется как вершина - Vertex. В Direct3D у вершины помимо координат могут быть дополнительно какие - либо свойства. Координаты совместно со свойствами хранятся в одном месте и называются форматом вершины - Vertex Format. Direct3D позволяет задавать различный формат вершины, так называемый FVF - Flexible Vertex Format - гибкий формат вершин. Выбор формата зависит от тех задач, которые вы перед собой ставите. Он может состоять из нескольких флагов. Каждый флаг в отдельности описывает каким свойством будет обладать наша вершина. Допускается объединение сколько угодно таких флагов, если они не противоречат друг другу. Соответственно не забывайте, что чем больше флагов вы используете в формате вершины, тем больший размер она будет занимать в памяти.
Например, часто используемый формат содержит:
Теперь вы видите, что всего лишь на одну вершину при таком формате будет затрачено не так и мало памяти.
Хорошо. Вы выбрали формат, который подходит для ваших целей. Как его описать? Делается это так: D3DFVF_CUSTOMVERTEX equ D3DFVF_DIFFUSE or D3DFVF_XYZ or D3DFVF_NORMAL и т.д
D3DFVF_CUSTOMVERTEX - это простая константа, определенная вами, которая позволяет объединять все нужные свойства для вершины. Далее D3DFVF_CUSTOMVERTEX можно уже указывать в качестве параметра в нужной нам функции. Можно D3DFVF_CUSTOMVERTEX и не использовать, но тогда в каждой функции, где необходимо указывать формат вершины, нужно будет перечислять все флаги, что не очень удобно. Пока остановимся на этом. Далее в тексте статьи мы еще поговорим о вершинах.
3. Полигоны
Формат вершины уже не является для вас тайной. Ну а как же составить из разрозненных вершин какой либо обьект ? Все объекты состоят из треугольников, скажете вы и будете правы. Конечно в Direct3D можно использовать и другие фигуры, число углов у которых больше чем три. Это квадраты и многоугольники. Но, так как аппаратная часть ускорителя оптимизирована на работу с треугольниками, то перед отрисовкой ваших квадратов они все равно будут разбиты на треугольники, так что сэкономив на простоте описания обьекта, можно проиграть в скорости. Как и что лучше использовать, решать вам.
А почему выбрали именно треугольник ? Потому что он является самой простой фигурой и всегда выпуклый. А раз он выпуклый, то упрощаются различные расчеты при работе с ним ( пересечение прямой, лежит ли точка внутри него и т.д. ) Вы это поймете сами, когда еще более углубитесь в работу с 3D.
Все фигуры в трехмерной графике называют "полигонами" - если перевести буквально, то это означает многоугольник. Но так как используют практически одни треугольники, то и название полигон стало синонимом слова треугольник. И когда вы видите в какой - либо статье про новую игрушку, что в модели монстра используется 5000 полигонов, то это значит, что он состоит из 5000 треугольников.
Сейчас давайте рассмотрим, как описываются полигоны. Для быстроты просчета сцены ( это определение я раскрою чуть дальше ) в Direct3D ( да и в любом другом 3D API ) применяется схема, когда невидимые полигоны отбрасываются и просчитываются только те, которые мы с вами видим. Как же Direct3D может узнать какие полигоны рисовать, а какие нет? Все дело в том как они заданы. И огромную роль в этом играет порядок следования вершин в описании полигона. Догадались? Правильно. Они должны быть заданы либо по часовой стрелке, либо против. Стандартом является то, когда вершины, составляющие полигон, заданы по часовой стрелке. В Direct3D этот режим включен по умолчанию. Т.е. он будет отрисовывать только эти полигоны, а все другие, где вершины описаны против часовой стрелки, отбрасывать. Нижеследующий рисунок поможет вам прояснить все моменты.
Чтобы было еще более понятно, разберем пример. У нас есть куб. Он повернут к нам одной гранью. Начинаем писать вершины этой грани по часовой стрелке. Начинать можно с любой. Когда мы написали эти четыре вершины друг за дружкой, то поворачиваем к себе куб новой гранью и опять пишем вершины по часовой стрелке и т.д. пока все грани не будут описаны. Если теперь внимательно подумать и посмотреть в каком порядке будут находиться вершины той грани, которая повернута от нас, то окажется, что они будут расположены против часовой стрелки ( если смотреть на эту грань сквозь куб ). Вот и весь фокус. Соответственно раз они против часовой стрелки и грань куба нам действительно не видно, то и рисовать ее не надо, что и делает с успехом Direct3D ( с вашей помощью, конечно ). Если вы собираетесь вручную описывать обьекты для дальнейшего использования в программе, то от этой процедуры вам не избавиться как бы этого ни хотелось. Ну а если использовать 3D редактор, то он все сделает за вас автоматически и опишет каждый полигон в нужном порядке. Также довожу до вашего сведения, что в Direct3D в любой момент можно поменять условие, по которому будет определяться какие полигоны отбрасывать. Те которые по часовой стрелке или против. В некоторых случаях это действительно необходимо, но об этом как - нибудь в другой раз.
Теперь когда вы знаете о том, что такое полигоны и как их нужно описывать, пора переходить к следующей части.
4. Что такое сцена. Как Direct3D работает с трехмерным миром.
В трехмерной графике есть такое понятие как сцена. Вы были в театре и видели там сцену, на которой выступают актеры. Так вот здесь это тоже самое. На ней также происходят различные действия. Все обьекты, с которыми вы работаете в данный момент, манипулируете и пытаетесь отрисовать, и представляют собой в совокупности сцену. Простым языком, сцена - это то, что мы в данный момент видим на экране.
Допустим, мы имеем обьект из полигонов на сцене. Как мы можем им манипулировать, перемещать, вращать вокруг оси и т.д? Не забудьте при этом, что все присутствующее на сцене распологается в трехмерной системе координат. Для перемещения вдоль какой - либо оси достаточно изменить координаты каждой из вершин в ту или иную сторону. Для поворота все уже намного сложнее. Тут нужно применять формулы, основаные на синусе и косинусе. Все они уже давно написаны математиками и с блеском работают. Главное их неудобство заключается в громоздкости и в том, что для поворота вокруг нескольких осей сразу, нужно применять эти формулы по очереди для каждой оси в отдельности. Результат может оказаться не таким, какой мы ожидали ( думаю, то, что они применяются для каждой вершины отдельно, обьяснять вам не нужно ). Для избавления от этого недостатка была придумана, так называемая, однородная система координат, где все действия над обьектами было очень удобно производить с помощью МАТРИЦ. Если хотели произвести сразу много действий, то просто перемножали матрицы нужных операций и результирующую матрицу, содержащую в себе все преобразования, уже применяли к вершинам всего обьекта. Удобно и быстро. И теперь все системы просчета 3D графики работают на матрицах.
Что представляет собой матрица? Это обычная числовая таблица из строк и столбцов. Вот как она выглядит:
Именно такие матрицы 4x4 и использует в своей работе Direct3D. Описываются они обычным массивом из 16 элементов, размер каждого элемента 4 байта ( Real4 ). Соответственно, размер в памяти, который занимает одна матрица равен 64 байтам.
Существуют три основные матрицы, которые мы должны знать:
• World Matrix (мировая матрица)
• View Matrix (матрица вида)
• Matrix Projection (матрица проекции).
"Мировая матрица" отвечает за преобразование всей сцены (вращение вокруг осей, перемещение и т.д.). Именно всей, а не какого - либо отдельного обьекта на ней. "Матрица вида" отвечает за то, какая часть сцены будет видна на экране. "Матрица проекции" отвечает за то, как трехмерные координаты будут преобразованы в двумерные для отображения на экран.
Эти три матрицы и являются тем чудесным средством, с помощью которого Direct3D превращает трехмерный мир в плоскую картинку на вашем мониторе.
5. Камера
Хоть трехмерный мир почти и бесконечен, но вот возможности ускорителя и процессора далеко не безразмерные. Если просчитать пару тысяч полигонов не проблема, то десятки и тем более сотни тысяч за раз подчас является трудоемкой задачей, даже для самых последних hi-end-овых ускорителей ( естественно всякие там Cray не в счет :) ). Поэтому опять приходится как-то оптимизировать все это дело. Решение простое. Чтобы все быстро просчитывалось и отрисовывалось с достаточно приемлемым числом кадров, наша сцена при просчете ограничивается в размерах. Осуществляется это намеренно. Сколько бы мы ни помещали на сцену обьектов, время просчета будет увеличиваться не так сильно, как при отсутствии такого ограничения. Вспомните про полигоны. Отбрасываются те, которые нам не нужны. Здесь отбрасываются те части сцены, которые не попадают внутрь этого ограничения.
В Direct3D роль такого ограничения выполняет камера. То что видно в камеру, то и отрисовывается.
На рисунке видно, что ограничение представляет собой усеченную пирамиду, расположенную к нам вершиной. Помните про три чудесные матрицы? Так вот две из них и определяют камеру. Это "Матрица вида" и "Матрица проекции".
В "Матрице вида" мы задаем положение камеры в пространстве и ее направление. А заполнив нужными значениями "Матрицу проекции", мы тем самым определим какого размера будет эта ограничивающая пирамида.
Давайте остановимся на "Матрице вида" и разберем ее подробнее. Чтобы правильно заполнить эту матрицу нам необходимо задать значения трех векторов:
• EyeVector - координаты камеры в пространстве
• LookAtVector - указывает куда направлен обьектив камеры
• UpVector - указывает верх камеры
Если вы не знаете что такое вектор, то мы сейчас это исправим. Вектор - это направленный отрезок. Т.е. он указывает направление. Вот рисунок:
Направление, которое описывает вектор, получается при взгляде от исходной в конечную точку. В нашем случае каждый вектор имеет только конечную точку. За начальную берется местоположение камеры в пространстве.
Задав эти три вектора, мы смело вызываем Direct3D и передаем ему все заботы, связанные с правильным заполнением "Матрицы вида" нужными значениями на их основе. Как всегда есть и альтернативный путь - заполнить матрицу самим, используя всякие преобразования над векторами ( в документации по Direct3D имеется кое - какая информация ), но пока не будем забивать голову и пойдем дальше.
"Матрицу вида" разобрали, осталась только "Матрица проекции". За нас эту матрицу тоже будет заполнять Direct3D. Вот какие значения мы должны ему передать:
• FieldOfView - поле обзора камеры
• AspectRatio - соотношение сторон
• NearViewPlan - передняя отсекающая плоскость
• FarViewPlan - задняя отсекающая плоскость
Поле обзора камеры - это угол в радианах, который способен охватить обьектив камеры ( связано все это с фокусными расстояниями линз и пр. ) Разный угол и по - разному будет выглядеть сцена. Как его правильно выбрать я расскажу далее.
Соотношение сторон - это то, в каком отношении находятся горизонталь и вертикаль. В обычном телевизоре соотношение сторон 4:3, т.е. если поделить 4 на 3 то получим 1.333333..... Вот это 1.33333 и нужно передавать Direct3D. Т.е. на вас лежит ответственность за его вычисление. Попробуйте вместо такого указать единицу и вы получите на экране с соотношением сторон 4:3 из квадрата прямоугольник, т.к. Direct3D будет пытаться соблюсти пропорции.
Передняя отсекающая плоскость - ближайшая к нам плоскость ( вершина пирамиды ). Задается значением по координате Z. Т.е. полигоны, находящиеся к нам ближе чем эта плоскость, не будут отрисованы.
Задняя отсекающая плоскость - тоже самое что и передняя, только наоборот ( основание пирамиды ).
В итоге задав три вектора и четыре параметра и вызвав Direct3D, мы получим готовые матрицы для использования. Камера готова !
6. Z буфер
Ну вот, какой-то там Z буфер еще надо знать. На самом деле это полезнейшая вещь. Если вы все еще не догадываетесь, то Z буфер позволяет Direct3D правильно отображать обьекты на экране. Дело в том, что устройство визуализации рисует обьекты на экране в том порядке, в котором их передавать. Т.е. второй обьект нарисуется поверх первого, третий поверх второго и первого. Ну и что скажете вы? Если у нас статичная сцена, и мы передаем все обьекты в нужном порядке, то никакой Z буфер нам и впомине не нужен. Все правильно. А если сцена вращается, и еще обьекты меняют свое местоположение, что тогда? Тогда Z буфер незаменим.
Работает он так:
1. В начале отрисовки каждого кадра Z буфер заполняется нейтральным значением.
2. Когда просчитывается полигон, то его надо рисовать на экране. Он состоит из множества пикселей. У каждого из них есть координаты. Direct3D берет Z координату пикселя и сравнивает с тем значением, которое лежит в Z буфере. Если значение в Z буфере больше, то на его место заносится Z координата пикселя, а сам пиксель рисуется, если нет, то ничего делать не надо.
3. Берется следующий полигон. Выполняется пункт b). Так до тех пор пока все не будет отрисовано.
Говоря простым языком, проверяется на какой глубине в данном месте экрана нарисован пиксель, и если рисуемый пиксель находится к нам ближе чем тот, который уже нарисован, то старый затирается новым.
Z буфер имеет такие же размеры что и окно на экране. Если окно 320х240, то и Z буфер будет иметь размер 320х240. Размер значений, которые может содержать Z буфер, варьируются от 16 до 32 бит в зависимости от того, какой формат вы зададите. Соответственно, чем больше формат, тем больше времени будет уходить на его заполнение нейтральным значением. Такое заполнение называется очисткой Z буфера. При использовании буфера придется осуществлять такую очистку перед тем, как рисовать очередной кадр.
7. Все знания применим на деле !
Уфф... Ну как? Сложно? Думаю вы уже готовы все бросить и пойти отдохнуть. Действительно нужно время, чтобы переварить полученную информацию. Математика сложный предмет и с первого раза доходит не до всех. Я сам когда-то долго не мог въехать в некоторые термины :). Но когда приходится что-то изучать для любимого дела, то все понимается и усваивается гораздо быстрей.
Итак. Вы знаете что такое трехмерная система координат, вершина, полигон, матрица, вектор, сцена, камера и Z буфер. Теперь с этой информацией можно приступать к непосредственной работе с 3D.
В качестве примера я приготовил довольно занятную вещь. Обычные туториалы, которые встречались мне в инете, показывая работу простейшего трехмерного приложения, выводили на экран либо пару треугольников, либо вращающийся квадрат. Стопроцентно вы бы не хотели смотреть на этот примитивизм, да и я тоже. Из простых полигонов можно создать и нечто поинтереснее, не прилагая при этом слишком больших усилий. Вот наглядный пример:
То что вы видите, мы с вами и сделаем. Думаете сложно? Ничего подобного! Немного смекалки и умения. Если руки у вас растут из нужного места, то через пару уроков вы меня переплюнете и для вас не составит труда создать нечто похожее.
7.1 Об используемых библиотеках
При использовании в нашем приложении новых функций и методов, нужно подключать новые Inc файлы и библиотеки, тут мы останавливаемся перед выбором: либо подключать одну библиотеку, либо другую. Мне очень нравится, когда существует несколько путей для достижения желаемого. Microsoft'у видно тоже нравится, и специально для нас он приготовил две версии одной и той же библиотеки: d3dx8.lib и d3dx8d.lib. Разница у них не только в наличии буквы d, но и, как я понял, в реализации ( может буква d символизирует о debug версии ? ). Размер D3DX8D.LIB - 53 414 байт, и она содержит только ссылки на D3DX8D.DLL. А вот у D3DX8.LIB размер уже 2 с лишним метра, и она несет исходный текст функций d3dx внутри себя. Поэтому, когда мы пытаемся ее использовать для постройки приложения, текст всех функций, которые мы решили вызывать, включаются в наш exe'шник. К тому же эта библиотека еще ссылается на фунции, которые есть только в MSVCRT.DLL и в ADVAPI32.DLL. И чем больше мы используем разных функций, тем больше наш exe'шник. Исходя из всего выше изложенного выделим основные моменты:
Да... Как ни крути, а все равно плохо. Выбирайте то, что вам по душе, а мне больше нравится вариант с DLL. Именно его я и буду использовать в дальнейшем. Чтобы не пришлось искать эту DLL по инету, я включил ее в архив с исходником. Поэтому при скачивании оного с Wasm.ru, не удивляйтесь большому размеру архива ( сам exe примера занимает 7 кило ).
7.2. Новое в диалоге
Для работы нам понадобится каркас от предыдущего урока. Как вы помните, он разбит на две части: диалог и само приложение. На форму диалога были добавлены 2 новых ComboBox, 2 простых текстовых метки и рамка. Из нового в диалоге - это возможность выбирать формат Z буфера и количество BackBuffer. BackBuffer определяется просто числом, поэтому из добавленного нами на форму ComboBox берем значение, которое выбрал пользователь, и помещаем в D3DPRESENT_PARAMETERS. А вот на определении формата Z буфера стоит остановится. Всего форматов Z буфера имеется 4 штуки. Нам придется проверять поддержку каждого из них и только затем помещать название этого формата в ComboBox. Сложность заключается в том, что при проверке нужно знать в каком разрешении будет запускатся приложение, а именно число бит на пиксель. Число бит Z буфера при создании устройства Direct3D не может быть больше, чем число бит включаемого разрешения. Например Z буфер имеет 24 бита, а включаемое разрешение 1024х768х16 бит. При таких параметрах нам будет отказано в создании устройства, т.к. 24 больше чем 16. Вот на это и стоит обратить внимание.
В самом файле Dialog.asm я объявил новые массивы: это ZbufferFormatTable - содержащий все возможные форматы Z буфера и ZbufferStrTable - содержащий указатели на текстовые строки с названиями этих самых форматов ( да еще сами текстовые строки ). Как и в предыдущем уроке проверяем, поддерживает данный формат ускоритель или нет, и если нужно заносим его название в ComboBox. Проверка осуществляется методом CheckDepthStencilMatch.
Чтобы сообщить Direct3D что мы будем использовать Z буфер, нам еще придется заполнить дополнительно 2 параметра в D3DPRESENT_PARAMETERS. Это поле EnableAutoDepthStencil ( заносим туда TRUE ) и AutoDepthStencilFormat ( заносим туда значение формата Z буфера, который пользователь выбрал в ComboBox ). Все. Теперь наше приложение будет использовать Z буфер.
Все подробности смотрите в файле Dialog.asm
7.3. Новое в приложении
Чтобы мы могли использовать новые функции, нам необходимо подключить один Inc файл и одну библиотеку. Это d3dx8math.inc и d3dx8d.lib. Данные файлы поддерживают работу с матрицами и векторами, а также еще с несколькими математическими функциями на данный момент нам не нужными.
Изменились старые функции: Init_Direct3D, Destroy_Direct3D и Render_Scene.
Добавились новые: Set_Render_Parameters, Init_Scene и Animate_Scene.
7.4. Функция Init_Direct3D
Как обычно, после того как пользователь запустил приложение, мы получаем от диалога полностью заполненную структуру D3DPRESENT_PARAMETERS. На ее основе создаем устройство Direct3DDevice. Далее нам нужно создать камеру ( о ней см. пункт 6 ).
Стандартно UpVector берется равным <0.0f, 1.0f, 0.0f> - т.е он направлен строго вверх. Наклоняя его в ту или иную сторону вы наклоняете камеру. Поле обзора камеры стандартно берется равным D3DX_PI/4. Т.е обычное число "Пи" делится на четыре. AspectRatio вычисляется делением ширины на высоту, и полученное число сохраняется.
Для заполнения WorldMatrix стандартно применяется функция D3DXMatrixRotationY с числом радиан равным 0. Получается, что мы хотим повернуть всю сцену на угол 0 по координате Y. В примерах Microsoft используется именно такой подход. Ради интереса я решил посмотреть, какими значениями заполняет эта функция пустую матрицу. Оказывается матрица из пустой просто превращается в единичную ( единичная - это матрица из нулей у которой по главной диагонали стоят единицы ), плюс один из элементов содержит какое-то число. Я попробовал сам заполнить матрицу как единичную, опуская то непонятное число. И что вы думаете? Все работает. По крайней мере для данного урока. Значит матрицы можно смело заполнять самим, не используя функции из библиотеки. Правда никто не гарантирует, что это будет легко ( документация содержит информацию о том как формируются некоторые матрицы ). Если вам интересно, пишите, и я рассмотрю эту тему.
ViewMatrix заполняем с помощью функции D3DXMatrixLookAtLH, передавая ей три вектора. А ProjectionMatrix заполняем функцией D3DXMatrixPerspectiveFovLH, передавая ей четыре параметра. Буквы LH в названии обеих функций говорят о том, что матрицы заполняются, исходя из левосторонней системы координат ( см. пункт 1 ). Вызвав все эти функции, мы подготовили камеру к работе.
Осталось только заполнить сцену и установить параметры рендеринга. Сделаем это, вызвав написанные нами функции Init_Scene и Set_Render_Parameters. На этом Init_Direct3D заканчивается.
7.5. Функция Init_Scene
В этой функции я решил поместить подготовку сцены. На скриншоте вы видели некое подобие флага. Как его создать? Текстур мы не используем, все что у нас имеется - это треугольники, которые можно закрасить каким - либо цветом. Что делать? Давайте создадим флаг из квадратов и там, где нужно, закрасим квадраты красным цветом, чтобы получилась надпись.
Во - первых, описываем формат нашей вершины. Он будет содержать координаты и цвет.
Затем нам понадобится шаблон для клонирования:
Здесь определено 2 треугольника, а все вместе - квадрат. Нужно размножить этот шаблон в количестве 36 по горизонтали и 10 по вертикали. Всего 360 квадратов или 720 треугольников.
Не забудем о надписи. Для ее нанесения используем обычную битовую маску для определения того, где закрашивать нужный квадрат. Надпись WASM.RU укладывается в шесть 32 битных значений. Вот они:
Вопрос с флагом решен. Теперь подумаем, какой фон мы можем сделать. Обычный одноцветный можно получить, используя простую очистку экрана. Фон с градиентной заливкой выглядит привлекательнее. Возьмем еще два полигона, расположим их за флагом и раскрасим как нам нужно. Вот описание фона:
С данными разобрались, и наступило время узнать как же Direct3D с ними работает. Система хранения данных в Direct3D основана на буферах. Существуют разные типы буферов. Например, VertexBuffer - это буфер, содержащий данные вершин. Создав специальным методом нужный буфер, мы должны занести туда данные, и только затем указывать, что из него рисовать. После создания к буферу можно обращаться и менять какие - либо данные в нем. Переопределять размер в большую или меньшую сторону, как я знаю, нельзя ( тема рассмотрена мной мало, возможно это как-то все-таки осуществляется ). Вообще, ОЧЕНЬ не рекомендуется производить громоздкие манипуляции с буфером во время отрисовки сцены. Записывать данные еще можно, а вот считывать из него ... крайне не приветствуется. Создается VertexBuffer методом CreateVertexBuffer. Для нашего примера создание буфера выглядит так:
После создания буфера, доступ к нему осуществляется посредством блокирования. Оно необходимо, так как буфер может находится где угодно. В памяти на самом акселераторе, в AGP памяти, либо где-то еще. Методом Lock блокируем, а разблокирование осуществляется методом Unlock. Когда буфер блокирован, ускоритель не может с ним работать, учтите это хотя возможны и исключения.
Для нашего примера мы создаем буфер такого размера, чтобы в него как раз уместилось все необходимое. Затем блокируем его и начинаем заносить данные. Внимательно следите за размером заносимого, если он превысит размер буфера, то приложение вылетит с ошибкой о записи в недопустимое место памяти.
Так как трехмерная графика основана на цифрах с плавающей запятой, то без сопроцессора не обойтись. При клонировании мы просто добавляем нужное число по какой - либо координате. У меня прибавление по X идет, начиная от 0 в плюсовую сторону. По Y от 0 в минусовую сторону.
В итоге флаг займет нижнюю правую четверть экрана. Почему так? Потому что начало трехмерной системы координат располагается по центру экрана. Если вы хотите иметь какое - то другое расположение системы координат, то вам придется или сдвигать камеру в нужную сторону, или заполнять "Мировую Матрицу" нужными данными. Я просто сдвинул камеру и все.
Мы не используем освещение, но можно его немного симмитировать. В цикле клонирования очередного квадрата по координате X заносится цвет более темного оттенка, чем у его предыдущего собрата.
Посредством сдвига битовой маски определяем какой квадрат закрасить, одновременно увеличивая оттенок квадрата по координате X. Так как каждый квадрат состоит из двух треугольников, то всего надо заполнить цветом шесть вершин. Вообще Direct3D по умолчанию использует градиентную заливку, если у треугольника для каждой из вершин указать разный цвет, то он будет нарисован с плавными переходами из одного цвета в другой. Нам же нужен квадрат одного цвета, поэтому и приходится заносить одинаковый цвет во все шесть вершин.
Посмотрите на то, в какой последовательности я заношу данные в VertexBuffer. Сначала данные фона, а затем данные флага. Помните, в шестом пункте про Z буфер я упоминал, что все данные отрисоваются в порядке их следования? Фон находится дальше чем флаг, правильно? Значит нам по идее Z буфер вообще не нужен. Попробуйте его отключить, и посмотрите что произойдет. Все будет нарисовано как ни в чем не бывало. Используя такие вот особенности, можно увеличить скорость прорисовки, а именно FPS. Старайтесь отключать все, что только можно, и использовать лишь то, что действительно необходимо.
Все. Сцену можно рисовать в функции Render_Scene.
Хотелось бы еще остановится на одном важном моменте. Всегда записывайте на бумажку размер вашей вершины, чтобы не забыть. Исходя из него, нужно подсчитывать, сколько будет занимать один полигон, затем сколько будет занимать группа полигонов. Расчеты должны быть точными, если вы ошибетесь и, при создании буфера, его заполнении или при отрисовке, неправильно укажете данные, то рискуете ничего не увидеть на экране. Будьте очень внимательны.
7.6. Функция Set_Render_Parameters
Все, что содержит данная функция, можно было поместить в Init_Direct3D. Почему этого не было сделано, вы сейчас поймете. В уроке номер 2 я рассказывал о проблеме потерянного устройства. При возвращении в наше приложение по Alt+Tab нам нужно сбрасывать устройство. При этом теряется ВСЯ информация, связанная с ним, и нам необходимо ее восстанавливать. В этой функции содержатся все настройки касательно параметров рендеринга. Мы можем легко их восстановить, поместив вызов этой функции сразу после сбрасывания устройства.
Метод SetTransform позволяет устанавливать в механизме визуализации, все связанное с трансформацией. Вызвав его, мы окончательно даем знать Direct3D, что для просчета сцены будем использовать те три матрицы, которые заполнили ранее.
Метод SetRenderState нужен для включения и выключения тех или иных настроек рендеринга. Он является практически незаменимым, так как с его помощью устанавливается большинство параметров. Использовать этот метод очень просто. При вызове указывается нужный нам обьект или свойство механизма визуализации и что с ним нужно сделать.
Так как в нашем примере нет обьемных тел, то мы можем отключить проверку следования вершин в полигоне: D3DRS_CULLMODE, D3DCULL_NONE. Также мы не используем освещение: D3DRS_LIGHTING, NULL. Но мы используем Z буфер: D3DRS_ZENABLE, D3DZB_TRUE.
Методом SetVertexShader мы указываем, что будет использоваться тот формат вершин, который мы определили сами. Методом SetStreamSource устанавливаем, что исходные данные для рендеринга нужно брать из буфера вершин, а число 16 означает размер нашей вершины в байтах.
7.7. Функция Render_Scene
Самая главная функция. В ней происходит вызов Direct3D, чтобы он отрендерил сцену, а затем показал на экран.
Самое главное, обратите внимание, где происходит вызов Set_Render_Parameters. Если его не произвести при возвращении по ALT+TAB, то приложение вылетит. Еще раз повторюсь, вы не должны забывать, что при сбросе устройства теряются практически ВСЕ установки, за редким исключением. Старайтесь определить все настройки в какое - либо одно место, чтобы при сбросе вам было легко их восстанавливать.
В предыдущих уроках мы использовали только очистку экрана цветом. Теперь с использованием Z буфера, нам необходимо очищать также и его. Соответственно в вызываемом нами методе Clear добавляем флаг D3DCLEAR_ZBUFFER и само значение для заполнения Zvalue. Стандартно Z буфер очищается значением 1.0f
Так как вся наша сцена состоит из однотипных треугольников, то ее можно отрисовать всего лишь одним методом DrawPrimitive. Этот метод служит для отрисовки определенного числа примитивов. В качестве параметров ( для нашей сцены ) ему нужно передать следующее: D3DPT_TRIANGLELIST - у нас одиночные треугольники, каждый из них задан тремя вершинами, начинать нужно с нулевого по счету, всего рисовать n-треугольников. Метод позволяет рисовать и выборочно какую-либо группу треугольников, достаточно указать с какого начинать + количество.
Ну и как обычно, все показывается на экран методом Present. Удивительно что на подготовку всей сцены и установку параметров уходит довольно много строк кода, а на отрисовку нужен всего лишь один метод. Для маленьких сцен это обычное дело, но для чего-то навороченного так легко будет не отделаться.
Да, чуть не забыл, перед тем как начинать отрисовывать сцену, всегда должен вызываться метод BeginScene, а в конце, когда уже все передали для просчета, метод EndScene. Т.е все команды для рисования должны находиться между этими двумя методами. Почему этого нет у меня? В документации написано, что если эти методы не будут вызваны, то Direct3D сам принудительно вызовет их. Не указано только, для каждого рисующего метода это будет сделано или нет. Так как у нас используется всего лишь один рисующий метод, то я решил выкинуть BeginScene и EndScene, ведь все равно Direct3D вызовет их за меня. В дальнейшем, когда я буду использовать много рисующих методов подряд, тогда и всякие BeginScene придется использовать, а пока все и так отлично работает. Если возможно сократить обьем вызываемого, почему не сделать этого, да и размер программы меньше :).
7.8. Функция Animate_Scene
Довольно сносный флаг у нас уже имеется. Но где вы видели абсолютно плоский флаг висящий в пространстве. Анимируем наш флаг, чтобы он смотрелся еще лучше. Обычная функция Sin или Cos поможет нам в этом. Конечно супер реалистичного эффекта мы не получим, но кое-что несомненно. Предлагаю вычислять значение Sin на определенной координате X и применять к координате Z. Получится, что квадраты, составляющие флаг, будут циклически плавать по Z.
Вот исходный код:
Чтобы была плавная анимация, нам необходимо обновлять значения, ориентируясь на время. Я использовал функцию GetTickCount. Можно использовать функцию timeGetTime из библиотеки winmm, говорят она будет поточнее. Обновление значений у меня происходит только 20 раз в секунду, этого вполне хватает. Как вы помните, при занесении данных в буфер нам нужно его блокировать, так вот здесь он блокируется также 20 раз в секунду. Все остальное время он не трогается. Приложение при этом рисует его с максимальным количеством кадров, которое возможно, т.е я никак не ограничиваю число кадров ( при входе в функцию Animate_Scene просто проверяется наступило время обновления или нет. Если нет тогда сразу выход. ). Также одновременно обновляется значение цвета у фона.
Итого, фон меняет окраску, а флаг развевается :) То, что мы здесь осуществили, является вертексной анимацией. Наверное слышали о такой? Как видите, совсем не сложно.
7.9. Функция Destroy_Direct3D
Уничтожаем все обьекты относящиеся к Direct3D.
При уничтожении обьектов рекомендуется соблюдать порядок. Не думаю, что, если вы сразу уничтожите обьект Direct3D, то остальные будут уничтожены автоматически. Хотя возможно всякое. Кто его знает, что было у разработчиков на уме :).
8. Послесловие
Урок получился длинный. И хотя я старался расписать все как можно подробней, возможно некоторое сумбурное изложение с моей стороны. Для окончания позволю себе закрепить весь материал вкратце.
PS:
В следующем уроке будет рассмотрена возможность использования обычного шрифта для вывода различной информации, ну и, может, в качестве примера подсчет FPS.
Как всегда исходник прилагается (находится в архиве wasm_files.zip: files/0247/dx8masm04.zip).
Все вопросы мыльте сюда mybox@aib.ru
Автор: xzazet
Дата: 2003-07-08
Много тысяч лет тому назад наш прапрапрадедушка собрал травы и минералы и сделал из них краски. Рисовал он пальцами или использовал некое подобие кисти неизвестно. Но то, что создал этот первобытный Мастер до сих пор поражает воображение. Стремление человека выразить себя, рассказать о том, как прекрасен мир в котором он живет, до сих пор обитает во многих из нас. Времена изменились, появились новые технологии, но все еще не перестают удивлять нас звездное небо и краски восходящего солнца.
Почти сразу с первой вычислительной машиной появились настоящие произведения виртуального искусства. Картины рисовались на мониторах при помощи ASCII символов вручную. Уже потом появились программы, которые могли преобразовывать графическое изображение в ASCII-Art.
Появление мониторов с примитивным цветным графическим режимам, подняло виртуальное искусство на качественно новый уровень. Среди компьютерных фанатов появились художники, способные буквально из нескольких десятков байт создать нетривиальные анимированные графические изображения. У команд - "исследователей" коммерческих программ стали появляться визитные карточки - программы, рисовавшие оригинальные графические сцены. Они распространялись вместе с "патчами" (например, посмотрите файл protocols.com в архиве mental_klutt_by_psikorp.zip в конце этого текста).
Следующим этапом стало появление графических карт способных изображать достаточно убедительный 3D в реальном времени. Современная Demo Scene это виртуальное искусство, которое объединило в себе творчество художников и композиторов, людей с хорошей математической подготовкой, владеющих передовыми вычислительными технологиями.
Эти известные демо используют API OpenGL. Продолжайте чтение после просмотра h7-final.zip (находится в архиве wasm_files.zip: files/0256/h7-final.zip) и mentalkluttbypsikorp.zip (находится в архиве wasm_files.zip: files/0256/mental_klutt_by_psikorp.zip)
Этот текст предназначен для тех, кто впервые серьезно взялся за изучение художественного 3D моделирования с помощью API OpenGL. Прежде всего включите свое воображение, голову и поисковую систему www.google.com. Вам будут предложены задания в каждой главе, которые звучат примерно так "Постарайтесь понять в течении 10 минут как можно больше oб использовании функции 'wglCreateContext'". Не пренебрегайте этим - знаний много никогда не бывает, а добывать их эффективно нужно учится. Без этого не стоит браться за вдумчивую работу с этим текстом.
Мы будем работать в MASM32v7 из пакета пропагандиста ассемблера под Windows - Hutch'a. Знание основ ассемблера - обязательно, а изучение Уроков Win32API от Iczelion - необходимо. Неплохо иметь представление об языке С/C++, иначе будет трудно понимать описание параметров функций API OpenGL. Мы постараемся научится творчески программировать, старайтесь внести в исходник урока что-нибудь свое, не бойтесь экспериментировать, изобретать свои "эффекты". Читатели с чрезмерной тягой к "copy-paste" подходу будут отчислены от занятий.
Лучше всегда иметь под рукой следующие мануалы:
1. Microsoft MASM v6.1 Assembly-Language Development System (Описание языка МASM)
2. MSDN Library Visual Studio (входит в пакет Visual Studio)
3. Сальвадор Дали "Дневник одного гения"
4. OpenGL Programming Guide aka "The Red Book"
Единственная причина выбора МАSM - эстетическое удовольствие. Да, именно так. Кодировать на нем сложнее, он требует от Вас знаний намного более глубоких, чем язык Си. Хотя ассемблер и собирает программы меньшие по размеру (если сравнивать с VC) - не факт, что они будут всегда быстрее. Какой код (MASM или C/C++) будет выполнятся за меньшее время - зависит от Вас, от Вашего мастерства в нахождении самых быстрых алгоритмов - медленные алгоритмы на MASM с большой вероятностью проиграют в скорости хорошему коду на С.
Что же такое API OpenGL? Давайте договоримся, что под API (Application Programming Interface) мы будем понимать некий набор подпрограмм, которые cможем вызывать/исполнять из нашей программы. Тогда фраза "API OpenGL" будет звучать менее пугающе - это всего лишь набор подпрограмм для работы с 3D графикой. Теперь мы можем без труда понять, например, что означает фраза "Win32 API" - это просто набор подпрограмм для работы в операционной системе Windows. Рассмотрим следующий рисунок.
Художник очень упрощенно изобразил самую суть понятия API: его программа в машинном коде запускает/вызывает подпрограмму "MessageBox" из библиотеки "User32" (входит в состав Win32 API), которая показывает на экране небольшое диалоговое окно с кнопкой. Потом Художник заставил компьютер издать звуковой сигнал - просто запустил подпрограмму "Beep" из библиотеки "Kernel32" (также входит в Win32 API) Затем он обратился к API "AudioFM", которую написал его друг Музыкант. Художник разбирается в музыке плохо, а все-таки сумел воспроизвести вальс Шуберта (а затем и хруст французской булки). Как? Он просто вызвал подпрограмму из API "AudioFM".
Затем Художник мастерски изобразил на мониторе белый круг и белый же квадрат, используя API "ОpenGL". Постойте-ка, а как он это сделал? Просто вызвал пару подпрограмм из библиотеки (=API) "OpenGL"!
Почему Художник написал на схеме "программа в машинном коде"? Чтобы особо подчеркнуть - и Asm и C/C++ сгенерируют машинный код, который будет работать с одним и тем же набором подпрограмм API "OpenGL". Так или иначе, но программы на ассемблере и программы С/C++ будут обращаться к одним и тем же функциям API "ОpenGL", а как быстро будет выполнятся код "ОpenGL" зависит только от Вашей видеокарты. (Ассемблер или С++ - выбирать Вам, на скорость выполнения API OpenGL не влияет).
Все API (и API OpenGL в том числе) очень удобная штука. Попробуйте представить себе как работает ... например, телевизор. Что нужно сделать из транзисторов, ЭЛТ и электричества, чтобы телевизор включить, настроить каналы, подстроить цвета? Нам на спасенье к телевизору прилагается АPI "Пульт Дистанционного Управления". Нажал кнопку (вызвал подпрограмму) - включил телевизор, нажал другую кнопку - переключил на другой канал. Пульт работает с "железом" телевизора самостоятельно! А что будет если мы купим новую видеокарту? API OpenGL позаботится о "железе" (обратите внимание на связь API OpenGL и видеокарты на рисунке), а название ее подпрограмм и способ их вызова останутся прежними. Наша программа будет работать везде, где установлена API OpenGL и даже без помощи современных видеокарт (работать будет медленно, но работать будет :))
Итак, нам любезно предоставили дистанционный пульт управления (API "OpenGL") от наших видеокарт - на любом современном компьютере с операционной системой Windows уже установлена API OpenGL. А где у них та самая главная кнопка - "ВКЛ" мы увидим в следующей главе.
PS: Автор сознательно опустил некоторые, на его взгляд, несущественные нюансы - для облегчения понимания. Для любознательного читателя это не будет большой проблемой. В качестве разминки постарайтесь выяснить, верно ли это утверждение "API OpenGL доступен только на компьютерах с ОС Windows!", а также "Почему MASM не такой хороший язык для написания 3D редакторов на API OpenGL по сравнению, например, с Си".
Автор: xzazet
Дата: 2003-07-20
MASM.OPENGL - Глава 1
x z a z e t
787A617A6574406E61726F642E7275
GLьчатай, открой личико!
В предыдущей части мы занимались теорией, а сегодня пришло время практики. Давайте разбираться.
Синими рамками обведены процедуры нашей программы, в которых мы будем обращатся к подпрограммам API OpenGL. В принципе больше комментировать здесь нечего. Если вы хорошо поработали над уроками Win32API от Iczelion'a, остальная часть схемы (подпрограммы в черных рамках) не должна вызвать недоумения. Если это не так, то работу над Win32API придется продолжить. Остальным слушателям предлагаю перейти к следующей главе.
Давайте посмотрим на подпрограмму CreateOGLWindow повнимательнее. Ее название говорит само за себя - мы создаем окно, в котором будут отображаться результаты нашего творчества в построении 3D виртуальной реальности. В следующей таблице расписаны шаги нашей подпрограммы, а также состояние OpenGL после каждого из них.
Cразу договоримся - мы будем смотреть на работу нашей программы с API OpenGL как на общение Клиента (наша программа) с Сервером (OpenGL). Представим на минутку, что мы пытаемся взломать секретный Сервер "OpenGL". Что нужно сделать сначала? Определить по какому сетевому протоколу нам удобнее приконектиться к серверу! Допустим, мы выбрали протокол ABC_32бита. Это хорошо, но настоящие "кулхацкеры" не вламываются на секретные сервера со своего домашнего компьютера! Они вламываются с убитых PСишек (напомню, мы работаем в MASM) деревенских интернет-кафе.
Поддерживается ли на них нужный нам протокол ABC_32бита? Нужно обязательно проверить его наличие перед использованием. Если он не поддерживается, то выбираем другой протокол или отказываемся от идеи взлома. По-моему, пока все логично. На этот раз нам повезло – PCшка поддерживает протокол АВС_16бит (хуже, чем ABC_32бита, но хоть что-то). Мы посылаем команду серверу OpenGL с запросом на соединение по протоколу ABC_16бит и получаем сообщение, что сервер готов к соединению. Дальше дело техники - сделать соединение активным. И всё, сервер ОpenGL ожидает от нас команд для исполнения.
Не бойтесь контекстов устройств (device context) – они не кусаются. Вспомним наше дество: детский сад, строгую воспитательницу и неуемную страсть к рисованию. (на стенах, ватманах, на руках шариковой ручкой, на новеньком БМВ богатого дяди острым гвоздем). Но в детском саду у строгой воспитательницы всегда нужно было спрашивать ее разрешение перед тем, как расписывать что-нибудь – «Марья Ивановна (OC Windows), можно я пририсую усы фломастером на вашей фотографии (в окне моей программы)?». А как иначе? За плохое поведение могут и из детского садика исключить («Ваша программа пыталась выполнить недопустимую операцию и будет закрыта» © WIndows), а там столько красивых игрушек!
Давайте договоримся, что под контекстом устройства (device context) мы будем понимать некий объект на котором нам не терпится что-либо нарисовать. В детском саду такими объектами (контекстами устройства) могли быть: лицо лучшего друга (зубной пастой во время «тихого часа»), стена в туалете, асфальтовая дорожка (цветными мелками – милое дело).
В мире Windows мы будем пользоваться 3-мя такими объектами (контекстами устройств) – монитором, принтером и памятью компьютера. API OpenGL может обрисовывать наши картины не только на мониторе, но и на принтере (есть ограничения) и просто рисовать картинку в памяти компьютера (Off-screen rendering. Кстати, только в этом случае мы можем подправлять изображения OpenGL самостоятельно непосредственно в памяти.) Контекст изображения OpenGL (не путать с контекстом устройства) к Windows не имеет никакого отношения, это “внутренняя кухня” OGL.
Теперь, отягощенные знанием о контекстах устройств Windows и контексте изображения OpenGL, еще раз изучите таблицу «CreateOGLWindow».
Что автор имел в виду под «протоколом», например «ABC_32бита»?. Структуру под симпатичным названием PIXELFORMATDESCRIPTOR.
Я специально сделал фонт помельче, чтобы у вас не возникло желание с ним разбираться прямо сейчас. На данном этапе просто насладитесь количеством разных параметров, которые мы сможем выбирать для работы с OpenGL.
Для чего конкретно нужна эта структура? PIXELFORMATDESCRIPTOR определяет формат пикселей графического изображения, например, сколько цветов оно может отображать (16бит или 32бита - вы неоднократно делали этот выбор, играя в компьютерные игры). Механизм работы со структурой предельно простой. Мы «заказываем» нужный нам формат пикселей с которыми хотели бы работать в 3D. Затем отправляем «заказ» OC Windows. Система подбирает нам наиболее подходящий формат из списка тех, что поддерживаются «железом» на данном компьютере и возвращает его порядковый номер (индекс). Мы сообщаем Windows, что будем работать в предложенном формате, и настраиваем контекст устройства окна под него. Теперь мы уверены, что контекст устройства окна и контекст изображения OpenGL будут работать в одинаковых форматах пикселей, т.е. не будет ситуации, когда OpenGL пытается запихнуть 32бита туда, где могут поместится только 16бит. Логично?
Вот как выглядит подпрограмма CreateOGLWindow.
Как бы Вам понравилось, если на Вашей жилой площади совершенно чужие люди брали ваши кровные контекстные устройства и создавали разные контексты изображения, работали с ними в свое удовольствие, жутко при этом мусорили и, махнув ручкой на прощанье, убирались восвояси, не прибрав за собой? Вот и ОС Windows будет ужасно расстроена, если мы не приберемся.
Напомню, что, создавая наше первое OpenGL приложение, мы на время взяли для рисования контекст устройства окна. Затем по нашей просьбе добрый OpenGL выделил для программы частичку себя – контекст изображения. Настоящие джентльмены, поиграв в чужие игрушки, возвращают их хозяевам.
Мы узнали почти все, чтобы закончить этот отрывок из МASM.OpenGL.Chapters. На сладкое осталась структура формата пикселей – pfd.
Нули нас пока не интересуют.
Единица это pfd.nVersion – версия структуры (да и такое бывает). nVersion всегда равна единице.
32 – это pfd.cColorBits, определяет кол-во битов на один пиксель (bbp), т.е. количество разнообразных цветов в которые можно этот пиксель покрасить. Я взял 32 (а мог бы 24 или 16, например), что даст мне возможность отобразить 4,294,967,295 цветов.
PFD_TYPE_RGBA (pfd. iPixelType)– сообщает Windows, что цвета пикселей мы будем определять через Red Green Blue компоненты (подробнее в следующих главах)
И последним определяем элемент pdf. dwFlags:
PFD_DRAW_TO_WINDOW сообщает Windows о том, что мы будет рендерить (строить 3D сцены) в окно, а не в память, например.
PFD_SUPPORT_OPENGL – у меня нет информации.
В этой главе мы казалось бы ничего не сделали особенного. То, что получилось, Вы увидите, когда после внимательнейшего изучения исходника; сами скомпилируете его, если надо – отловите ошибки, а затем запустите. Напоминаю, СНАЧАЛА изучаете исходник, ПОТОМ компилируете, выдерживаете одни сутки, и в самую последнюю очередь запускаете. Так и только так.
Один мой хороший знакомый добился исключительных результатов за непостижимо короткий срок. Когда я попытался выяснить, в чем секрет и какими пособиями он пользовался, ZYtDHE грустно посмотрел в мою сторону и виновато промямлил «Рассыпался винчестер, а на старом не было компилятора». (!!!) Этот парень создавал программы, отлавливал свои ошибки в течении двух недель, так не разу и не запустив код на исполнение. «All errors are made by mistake» (c) ZYtDHE.
Вы замечали, что первое впечатление от знакомства с чем-то новым - самое сильное? Если именно сейчас в эти первые минуты после прочтения текста вы постараетесь вникнуть в философию OpenGL, с самых азов, с вызова его первой подпрограммы, с инициализации его первой структуры, то остальной более продвинутый материал покажется вам логичным продолжением, вы увидите в хаосе нулей и единиц, байтов и двойных слов, в контекстах изображения удивительную красоту и гармонию. И тогда вы сможете импровизировать, как хороший музыкант на любимом инструменте, а возможности API OpenGL будут ограниченны лишь Вашей фантазией.
Так как исходник без комментариев и обработки возможных ошибок после вызова подпрограмм API (на их месте стоят мои комментарии «и выходим», смотри выше по тексту), предлагаю следующий конкурс для любознательных – доработайте исходник. Лучший будет опубликован в следующей главе).
Еще необходимо предупредить читателя о том, что откомпилированный исходник может вообще не запуститься. Если это Ваш случай – остается только порадоваться. Ведь потратив некоторое время на самостоятельный поиск и исправление ошибок вы лучше усвоите материал, и значит потратили время не зря. Вам может понадобится отладчик. К сожалению, у меня сейчас при себе нет его номера телефона, а на email он не отвечает. Поищите его в Интернете. Встретите Сафонову Асю, передавайте привет.
Автор работает в редакторе AsmEditor, который можно скачать отсюда (http://www.avtlab.ru/) Так же скачайте и установите базу подсветки синтаксиса, которую любезно предоставил vkim, разработчик VKDEBUG (входит в пакет MASMv7).
Основные возможности AsmEditor:
• подключение различных компиляторов (Ассемблер, Си и другие);
• настраиваемые схемы подсветки ключевых слов;
• быстрый переход между процедурами, функциями, метками;
• возможность подключения файлов помощи (например, win32.hlp) для вызова контекстной справки по выделенному в редакторе слову;
• работа с исходными кодами в DOS-кодировке без потери символов псевдографики;
• меню и дополнительные кнопки с функциями, назначаемыми пользователем;
• настраиваемые "горячие клавиши"; быстрый переход по номеру строки; "закладки"; сохранение позиции курсора и т.д.
Не требует инсталляции, не вносит изменений в системные файлы и реестр. По умолчанию настроен на пакет MASM32
Также скачайте fraps (www.fraps.com) и испробуйте его на каких-нибудь программах.
Для развлечения, поиграйте с графическими режимами в своем любимом FPS, попереключайтесь с 16 на 32 цветность. Постарайтесь объяснить увиденное.
Просто вопросы на засыпку:
1. Если мы будем работать в режиме off-screen rendering’га (т.е. рисовать изображение в памяти компьютера, а не выводить на экран) сможем ли получить любой «заказанный» формат пикселей для роботы на этом контексте устройства (ограничений то по «железу» на память нет)?
2. Что такое wiggle?
3. Почему в нашей программе необходимо указывать WS_CLIPSIBLINGS и WS_CLIPCHILDREN при вызове CreateWindowEx?
Автор: keYMax
Дата: 2003-08-01
Часто, когда приложение уже запущено, необходимо вывести некоторую полезную информацию: подсказки пользователю, содержимое переменных, сообщения об ошибках и т.д. Легко и быстро это делается с помощью текста.
Как вы все знаете, вывод текста в приложениях, не использующих 3D, осуществляется посредством GDI, который может предложить несколько функций, различающихся параметрами и удобством применения. В трехмерном же приложении использование GDI практически невозможно за редким исключением. Даже если удастся каким-то образом его задействовать, то потери времени при использовании будут очень значительные. В качестве альтернативы Direct3D предлагает нам всего лишь один метод для вывода текста. Если вы ожидаете от него каких-то наворотов и спецэффектов, то спешу вас разочаровать, метод служит только для простого вывода текста и ничего более. Кстати, у него имеется довольно много различных флагов, но они не сильно скрашивают и так хилые возможности. Более подробно на преимуществах и недостатках мы остановимся в конце статьи, а пока... пока рассмотрим с чего собственно начинать.
Первым делом, необходимо подключить .inc файл, содержащий прототипы необходимых нам функций и методов. Называется он d3dx8core.
Далее у нас есть два пути создания шрифта. Почему два и не более? Просто разработчики создали по аналогии с GDI две функции: D3DXCreateFont и D3DXCreateFontIndirect, которые и помогут сделать всю работу.
Рассмотрим по шагам первый путь:
Вот и все. Проще просто не бывает.
А теперь второй путь:
Второй путь самый минимальный. Никаких тебе GDI функций и лишней головной боли.
Как видно из справки, без уже созданного устройства Direct3DDevice создать и зарегистрировать шрифт не представляется возможным.
После того, как мы получили от Direct3D указатель на шрифт, можно начинать с ним работать. Как уже упоминалось выше, у нас имеется в распоряжении только один метод отрисовки текста, он называется DrawText и существует в двух вариантах: DrawTextA - рисует текст в формате ANSI, DrawTextW - рисует текст в формате UNICODE.
Отрисовка не должна вызвать у вас затруднений, но на всякий случай я приведу пример:
Отрисовку текста нужно производить самым последним этапом перед показом буфера на экран. Думаю это обьяснять вам не надо.
Ну вот, почти всю информацию относительно DrawText вы получили. Осталось только упомянуть о нескольких важных моментах.
В документации сказано, что вызов DrawText обязательно должен осуществляться внутри методов BeginScene и EndScene ( они относятся к Direct3DDevice ). Если проигнорировать это утверждение, то якобы нас ожидает кара небесная. Использовав DrawText без этих методов ничего страшного я не обнаружил. Также у самого D3DXFont имеются методы Begin и End. Они тоже призваны служить обрамляющими DrawText. Т.е вызов отрисовки текста должен проходит опять таки между ними. Но и без этих методов все прекрасно работает. Далее решайте сами использовать их или нет.
Второй важный момент заключается в использовании флага DT_NOCLIP. Используйте его всегда! Лучше заранее подсчитать входит текст в прямоугольник или нет, чем ждать от Direct3D что он обрежет слова. Использование этого флага РЕАЛЬНО повышает скорость прорисовки.
Еще очень важно НЕ использовать шрифты больших размеров, чем больше размер тем дольше все отрисовывается. У меня с увеличением размера букв происходило падение fps и довольно заметно. Ну и соответственно это количество выводимого, если его много, тогда опять все тормозней и т.д. и т.п.
Стоит упомянуть и про потерю устройства, которую мы рассматривали в одном из предыдущих уроков. При сбрасывании устройства нам нужно восстанавливать все данные и о шрифтах. Делается это двумя методами OnLostDevice и OnResetDevice. Вызывать их нужно при каждой потере устройства.
Теперь о цвете шрифта. Он используется в формате ARGB, где буква A - альфа или прозрачность. Чем больше альфа тем непрозрачнее текст. Когда я впервые пытался отрисовать текст и ничего на экране не увидел, то не сразу сообразил в чем дело ( альфа была в ноль и соответственно текст абсолютно прозрачен ). Не повторяйте мою ошибку, всегда проверяйте значение альфа.
Ну и на последок, как я и обещал выше, поговорим о преимуществах и недостатках.
С помощью данного метода можно легко и быстро вывести информацию с подчеркиванием нужных букв, выравниванием, а также многострочный текст одним махом. Даже хоть справа налево по - арабски.
Не является слишком быстрым и расторопным. Нельзя напрямую указать координаты вывода, только посредством структуры типа RECT ( приходится ее все время модифицировать для вывода текста в различных местах ).
Подходит только для простого отображения не слишком большого количества текста.
В качестве примера даже придумывать нечего, я попробовал его хоть как-то поинтересней сделать. Что из этого получилось, судить вам. Скачивайте и смотрите непосредственно в действии. На этом спешу с вами попрощаться.
Да ! Чуть было не забыл, теперь стабильность работы всех примеров, начиная с этого урока проверяется в системах Windows 98, 2000 SP3, XP и под DirectX 8.1 и 9.0. Надеюсь, никаких проблем у вас при запуске примеров возникнуть не должно, как было ранее в Win2k.
PS:
В следующий раз будет рассмотрено использование стандартных обьектов типа куб, сфера, цилиндр и т.д.
Как всегда исходник прилагается (находится в архиве wasm_files.zip: files/0264/dx8masm05.zip).
Все вопросы мыльте сюда mybox@aib.ru
Автор: Tyler Durden
Дата: 2005-03-26
Привет всем (уважаемым читателям/телезрителям/"а также их родителям" и пр ;) Сразу хочу предупредить, что это моя первая статья, поэтому просьба не пинать меня ногами, никакого заме-е-ечательного Набоковского слога и живописных эпитетов вы тут не увидите :( Все выдержано в сухом "преподавательском" тоне без малейшего намека на "программерские" шутки про "юзеров", телепузиков, "Microsoft" и "г-на Била Гейтса" (а ровно и пауз на неопределенный срок фразой "я ушел бухать", так как я вовсе не "бухаю". Да да, не смейтесь, я спротЦмен ;) ) Разочаровавшись (многие уже потянулись к "Esc"/бутылке/соске) начнем собсен-н-но...
Как говорил товарищ Берлага, если приподнять завесу, то становится весьма очевидным что стандарт OpenGL разрабатывается фирмой Silicon Graphics (теперь SGI) с лета 1992 года. Этот программный интерфейс был во многом основан на библиотеке IRIS GL, поддерживаемой с 1982 года. Для развития нового интерфейса был организован консорциум The OpenGL Architecture Review Board (ARB). На данный момент OpenGL является стандартной библиотекой для всех 32 разрядных операционных систем (Unix, Mac, Windows). Ну и хватит на этом. В конце концов это вам не лезгинка, а твист... в смысле не "Большая Советская Энциклопедия".
Сразу скажу что писать мы будем на ассемблере (вообще говоря, все следует писать на ассемблере ;) , а точнее на FlatAssembler (FASM) т.к. он очень быстрый, компактный, постоянно развивается и не отягощен всякими бредовыми конструкциями (типа assume/offset) других ассемблеров (типа TASM ;)... а, ну да, самое главное, для читателей откуда-нибудь из Изгггаеля, его еще и на шару (конечно же под небо-о-ольшой процЭнт ;) можно скачать на www.flatassembler.net .Берем оттуда версию "for Win32 GUI" которая еще и, до кучи, оснащена простеньким IDE ! Далее... Распаковываем добро из скаченного архива "fasmw.zip" (находится в архиве wasm_files.zip: files/0366/OpenGLbyTylerDurden.zip) в какую-нибудь папку, и "усе готово шэф" !
Я предполагаю что вы уже писали под Win32 хотя бы и "Hello world !" (если нет то почитайте какой-нибудь tutorial по этому поводу, благо, их в сети туева хуча расплодилась). Окинув взглядом прилагаемый "simple.asm" в папке "simple" вы заметили что в нем нету даже оконной процедуры... Ой фу-у-у-у ! Но не спешите закрывать fasmw.exe, это всего лишь следствие моих небольших "оптимизаций" (а иначе накой хрен нам писать на ассемблере, как не из извращенческих соображений оптимизации ?) Но обо всем по порядку... Надеюсь следующий код понятен всем ? (fasminc можно установить например так (в файле autoexec.nt для WinXP) "set fasminc=путь_к_папке_fasm")
Для начала спрячем курсор, дабы некоторые "продвинутые" юзвери не начали тыкать им куда не попадя, пораниться ведь можно (Извращения начинаются, см. "push ebx" )
Для начала "урока рисования" нам нужно создать окно, а точнее его класс (и тут не без извращений ;) ) размером с экран. Можно, конечно, для начала изменить разрешение, а потом уже уверенно создавать окно с известным размером, но это будет слишком просто для нас (и долго) ;) Поэтому мы получим текущее разрешение экрана по X и Y (по Z пока не будем ;) ) и запихнем их в стек (перед этим забьем его нулями (ebx) это у нас будут другие параметры процедуры CreateWindowEx. Вообще многие функции подставляют вместо "0" (ebx) параметры "по умолчанию", этим, как говорит Microsoft, "интеллектуальным свойством" мы будем активно пользоваться во всех частях tutorial'а) Помним при этом что функции возвращают результат в "eax". Вообще, следите за стеком ! Это хоть и геморойно, но зато позволяет не сохранять кучу ненужных "промежуточных" результатов функций (вроде GetSystemMetrics).
Тут мы используем полученное разрешение экрана (его берем уже из стека... а накой нам лишние переменные ?) чтобы найти его (экрана) AspectRatio (разрешающую способность, т.е. "max_x/max_y") Потом она нам еще пригодится
По идее, для создания класса окна нам его нужно было бы с начала описать, зарегистрировать... В общем, скука ужасная (и еще байтов жрет кучу !) Вместо этого мы просто создадим окно с предопределенным классом, таких в винде множество, но мы выберем ну хотя бы класс "edit" (о чем красноречиво сообщает строка szClass) Помним о том что некоторые "недостающие" в invokе'е параметры мы уже положили в стек
И так, окно мы создали. Если вы уже рисовали что-нибудь под Win32, то вы знаете что для этого нужно получить его "контекст", это делается довольно просто (так как контекст окна нам еще пригодится, мы сохраним его в одном из "неиспользуемых" (в функциях Win32 API) регистров (ebx,ebp,esi,edi) )
Теперь нужно задать режим работы OpenGl'а, число бит на пиксель, режимы отображение и прочую белиберду (половину из которой мы оставляем нулевой (т.е. по умолчанию)
У нас есть контекст окна, у нас есть пиксельный формат ! "Мы сделаем из тебя парень новую звезду"... Аннннн нет, для начала нам еще осталось преобразовать контекст окна в "нечто" понятное OpenGL'у (т.к OpenGL не должен знать что такое Windows, для этого используется специальная "windows-compliant" функция API wgl*) и еще сделать его "текущим" (т.е. рисовать будем в него)
Фууу-х-х-х-х ! Самое сложное позади ;) Винды остались не у дел, теперь "познакомимся", собственно, с простым и удобным OpenGL'ем ;) Говоря голосом ведущего "в мире животных", эта забавная зверушка тоже требует некоторой настройки параметров (ОПЯТЬ ?!) Дело в том что нам нужно включить "перспективные преобразования", проще говоря перспективу, она зависит от текущей разрешающей способности экрана (т.е. max_x/max_y) вот для этого то мы ее и вычисляли. Так как некоторые извращенческие функции OpenGL воспринимают только параметры типа Double (8 байт) то придется пихать их в стек макросом glCall (который использует макрос glPush) А шо делать ? У нас же Intel Все-таки :( Число 90.0 это требуемый "угол обзора" можно поставить его 45.0 или 60.0 как кому нравится. Числа 0.1 и 100.0 это координаты "отсекающих плоскостей", все, что находится между ними, будет отображено на экране. Остальное - обрезано. Надо заметить что многие функции API OpenGL (glRotate, glTransform и пр.) работают с "текущей матрицей", коих 3 (GL_MODELVIEW, GL_PROJECTION и GL_TEXTURE) поэтому чтобы преобразовать матрицу перспективы мы выбираем ее функцией glMatrixMode.
Ура, а вот и он, "основной цикл". В нем вы "пока" ;) не увидите навороченной демы от haujobb, просто очистка экрана и выход по Esc. Т.к. мы работаем в режиме "двойной буферизации" то рендеринг идет в дополнительный буфер, для отображения его на экране нужно вызвать функцию GDI32 "SwapBuffers". Дабы впоследствии (когда мы добавим сюда что-нибудь) все не вертелось с бешеной скоростью, добавим сюда еще и синхронизацию с таймером
Не забудем выйти и описать переменные ;) Обратите внимание как (как просто ! ;) ) в Fasm'е описывается импорт и ресурсы.
Ну, вот в принципе и все, в первом OpenGL приложении. Это, типа, был "template", дальше я буду добавлять только измененные части.
Ну, покончив с пережитками Win32 программирования, откинувшись (и оттопырившись) на спинку стула, можно наконец приступить к OpenGL'у вплотную... Оказывается нарисовать на нем треугольник не просто, а, как говорится, очень просто ! Все что надо это задать его координаты. Для начала сообщим что мы хотим, собственно, рисовать треугольники (GL_TRIANGLES) т.е. каждые три точки определяют один треугольник (следующие три - уже другой)
Теперь задаем координаты его вершин и их цвет. Цвет представляет собой 3 float'а (красную, зеленую и синюю (чуть было не написал голубую ;) ) составляющие) о чем говорит постфикс функции "3f". Этими префиксами/постфиксами отличаются все функции OpenGL API (т.е. если надо задать еще и alpha-состовляющую - используем функцию glColor4f, если нужно задавать параметры в Double то 3d/4d или 3i/4i для Integer) То же самое относится и к функции glVertex3f (соответственно первый параметр - координата X, второй - Y, третий - Z)
Все, нарисовались !
Если все так и оставить, то мы ничего не увидим, т.к. треугольник будет лежать прямо в точке наблюдения, надо бы его отодвинуть. Но, так как мы будем делать это каждую итерацию цикла то наш треугольник будет все дальше и дальше отодвигаться от нас (проверьте это сами, удалив вызов glLoadIdentity) поэтому вначале мы будем "обнулять" матрицу изображения.
Просто нарисованный треугольник ничем не говорит нам о своей "трехмерности", надо его для этого повращать. Делается это функцией glRotate которая вращает (умножает текущую матрицу на матрицу поворота) на угол [theta] вокруг векторов с координатами (0,0,0) и (второй параметр, третий параметр, четвертый параметр) соответственно. Угол мы будем увеличивать каждую итерацию цикла (т.к. матрица изображения "обнуляется")
Вот и все ! И оч-ч-чень просто, по-моему...
Свет в OpenGL включается очень просто (как и многое другое) выключателем ;) т.е. функцией glEnable с параметром GL_LIGHTING (отключается соответственно функцией glDisable). Нужно еще включить еще и определенный источник GL_LIGHT* (номер источника). Мы не будем пока парить себе мозг разнообразными видами источников и их параметрами, включим для начала источник GL_LIGHT0 (для него параметры настроены по умолчанию)
Так как в этой главе мы будем рисовать объемную фигуру (кубик) то нужно еще включить режим отсечения не лицевых граней (а то все грани кубика будут рисоваться и перекрывать друг друга) т.е. z-буфер. Делается это опять же функцией glEnable. Цвет получившегося (освещенного) полигона зависит от свойств "материала" и только :( Чтобы правильно отображать его цвет нужно еще включить режим его отслеживания (GL_COLOR_MATERIAL).
Для того чтобы использовать освещение, для каждой грани нужно определить нормаль. Делается это функцией glNormal3f, координата X, координата Y, координата Z
Заметьте что мы вызываем glRotatef 3 раза, для придания траектории вращения большей random'ности
Для пущего реализЬма напялим на наш кубик текстуру. Делается это тоже проще пареной репы. Для начала нужно ее (текстуру) нарисовать (можно выдрать откуда-то, главное помните, что ее размер должен быть степенью двойки (256
Далее ее нужно перевести в понятный OpenGL'у формат функцией glTexImage2D. GL_TEXTURE_2D говорит что текстура у нас 2-х мерная, следующий ноль (ebx) определяет mip-map уровень для нее (для ускорения текстурирования из текстуры можно предварительно сгенерировать несколько уменьшенных копий, но у нас пока только одна), 3-ка - это число компонент в цвете (у нас RGB, а может быть и1-а (R), 2-е (RA), 4-е (RGBA)), затем размерность текстуры по x и y соответственно (256*256), "0" (ebx) это толщина "рамки" вокруг текстуры, далее формат текстуры (RGB, RGB, RGB, ...), тип каждой компоненты (у нас байт) и, собственно, смещение в файле (texture+16).
Теперь осталось определить еще некоторые параметры текстуры, такие как фильтры уменьшения/увеличения (GL_TEXTURE_MIN_FILTER/GL_TEXTURE_MAG_FILTER) (т.е. которые применяются когда текстура, соответственно, меньше/больше требуемой для текстурирования в данный момент времени) функцией glTexParameteri. Установим их в GL_LINEAR (лучшее качество, можно еще GL_NEAREST побыстрее, но похуже)
Вообще говоря, нужно было предварительно выбрать ID текстуры (1 для первой текстуры, 2 для второй и т. д.) функцией glBindTexture, но т.к. у нас только одна, и вся работа идет с 1-ой текстурой (по умолчанию), то нам ничего не мешает этого не делать.
Осталось только включить текстурирование функцией glEnable
Усе, однако OpenGL не знает как привязать координаты вершин объектов к текстурным координатам (за исключением автоматической генерации текстурных координат, но об этом позже) так что надо ей об этом сообщить функцией glTexCoord2f с двумя параметрами (для 2-х мерной текстуры) x и y координатами текстуры (они изменяются также как и все остальное в OpenGL - в относительных координатах от 0.0 до 1.0)
В случае с несколькими текстурами, их выбор осуществляется, как я уже говорил, функцией glBindTexture.
Alpha смешивание позволяет нам использовать эффекты прозрачности. Для этого нужно опять таки его просто включить функцией glEnable (вам даже не надо знать как оно работает ! Вот шара :) помучившись со своим дос-софтверным 3D движком можно вздохнуть спокойно ;) ), настроить его тип можно функцией glBlendFunc, параметры источника (что смешивается), параметры результата (с чем смешивается). Параметры зависят от требуемого результата.
Чтобы было с чем смешивать, нужно отключить режим отсечения не лицевых граней (попросту z-буфер) функцией glDisable.
либо вообще его не включать (как у нас в примере).
А теперь "офигенно" сложный этап tutorial'а ;) Туман ! Делается даже сложней чем alpha смешивание ;) а именно:
И все ! Параметры я думаю говорят сами за себя... Так как "туманятся" только объекты, то для пущей выразительности окрашиваем остатки экрана под цвет тумана (непонятно почему разработчики OpenGL не предусмотрели для glClearColor вариант с постфиксом fv (передается указатель на массив из Float'ов). Режим "работы" тумана можно выбрать и другой (ну, например, с 9 до 6 вечера, без выходных ;) ) GL_EXP или GL_LINEAR, поэкспериментируйте...
Заценим теперь, какую "титаническую" работу проделала Microsoft (ну вот, а говорил, что не будет про них) в своем scream-saver'е "3D Text". Для начала привычные для шрифтов вызовы Win32 API: создаем объект типа (ти-и-ипа) "шрифт" (все значения оставляем на совести Windows), и даем установку (а-ля Кашпировский) для "рисования".
Дальше вступает в дело OpenGL: преобразовывает векторный (именно векторный ! Шрифт "System" преобразовать не удастся, а жаль) в так называемый список (с... что ?!), т.е. последовательность OpenGL команд описания графических примитивов (те что обычно задаются между glBegin, glEnd). Для этого используется функция wglUseFontOutlinesA (или ее unicode версия wglUseFontOutlinesW для символов с кодами больше 255) Получаем "outline font". Мы будем преобразовывать символы начиная с нулевого (ebx) по 255 (всего, значит, 256 символов), единица означает что используются полигоны, а не линии ("0"), "0.2" это толщина нашего шрифта, в ebp, если помните, сохранен контекст OpenGL. Для операций с несколькими (у нас - 256) списками нужно выбрать первый список (вообще-то его их нужно было сгенерировать функцией glGenLists, но за нас это делает OpenGL). Для этого используется функция glListBase.
Посмотрим на предыдущие примеры tutorial'а, и офигеем ;) Зачем было столько носиться с оптимизацией, если размер какой-то завшивленной 256
Ндааа... Опять глава кончилась не успев начаться ;) Ах да, нужно еще написать какое-нибудь слово (желательно не из трех букв, хотя в OpenGL слава Богу еще не встроили Parental Lock ;) все-таки это не DirectX), для этого вызовем списки (хмм, с этим словом главное не описАться... ой) с номерами равными кодам желаемых букв (т.к. мы генерили символы от "0" до "255"). Делаем это функцией glCallLists.
Ура ! Получилось довольно красиво (и, главное, всего на три кило). Можно даже забацать из этого какое-нибудь "Newschool scrolltro". Дерзайте.
И так, мы уже вплотную подобрались к алгоритмам используемым в демках. Т.к. OpenGL не позволяет (нормальным образом) получить доступ к видеопамяти, поэтому и алгоритмы эффектов здесь соответствующие - извращенческие. Так что обычным образом motion blur нам сделать не удастся, будем юзать "встроенную" возможность OpenGL blur'ить текстуры при их растягивании (ну да, нам даже не надо знать как работают motion blur фильтры !) Вкратце план довольно прост:
1. Отрендерив сцену в окно размером blurSize
2. Идем дальше ("Строго на север, в порядке 50 метров"), нарисуем четырехугольник с полученной текстурой, размером с экран, поверх изображения.
3. Затем ("Проходя мимо пЫхты"), отрисуем сцену еще раз.
Все, т.к. альфа смешивание включено, то каждый раз смешивая текстуру с предыдущими сценами (с альфа компонентой меньше "1.0") и черный экран (с альфа компонентой "0.0"), она будет постепенно "исчезать". Так как мы будем рендерить все в пустую текстуру, то с начала нужно ее создать, делается это как и обычно:
Заметьте, что кубик мы предварительно "компилируем" в список.
Blur'ить мы будем не каждый раз, а только через 4 фрейма (иначе "хвост" будет слишком маленьким, да и тормознуто это).
С начала нужно установить окно размером blurSize*blurSize, и отрендерить туда нашу "сцену".
Скопируем то что получилось в текстуру, функцией glCopyTexImage2D. GL_TEXTURE_2D показывает что текстура двухмерная, следующий ноль (ebx) - это mip-map уровень, затем координаты текстуры (0,0), ее размер (blurSize*blurSize), и размер границы ("0"). Очистим экран, и вернем OpenGL'ое окно обратно.
Теперь как нам нарисовать четырехугольник точно размером с экран ? Ведь OpenGL'у плевать на пиксели, он оперирует какими-то "условными единицами" (зелеными, наверное ;) ). Для этого нам надо установить так называемую "Ортогональную (прямоугольную) проекцию" делается это не сложнее установки перспективной проекции:
Усе, рисуем нашу сцену четырехугольником (заметьте, что перспективную проекцию мы устанавливаем не функцией, а, просто, сохранив проекционную матрицу в стеке функцией glPushMatrix, и восстанавливаем ее функцией glPopMatrix)
В принципе ничего сложного тут нет, все абсолютно "прозрачно", смотрите код и все поймете.
Глава 10: Zoom blur
Ур-ра ! Последняя часть tutorial'а (пока, гы гы). Надоели вы мне, хех, как сказал один доцент (тоже ученый, у него 3 класса образования): "пришить бы вас, да возиться неохота" ;). Но пока, так... Копаем... Копать будем "zoom blur", или как его еще иногда (и неправильно) называют "radial blur", или даже "volumetric lights"... Но не в названии дело, а в его простоте. Собственно, после предыидущей главы, делать мне тут нечего, разве что так, "на шухере постою". Алгоритм довольно тормознутый (для моей отстойной видюхи GeForce4 MX), в 1024
Обратите внимание на, уже набивший всем оскомину, "эффект" широкоформатной пленки (типа, фи-и-и-ильму, фи-и-и-ильму !), который кое-кто уже умудрился впарить даже в 256b intro. Т.к. я поубивал много лишних вызовов процедур (к примеру, glViewport нужно было бы вставить после инициализации), то прога потеряла некоторую долю логичности (а заодно и пару "килограмм"), но к 10 главе мы уже все стали "хавцами" в OpenGl'е, неправда ли ?
Сам алгоритм, который очень похож на motion blur, состоит в следующем (неизмененные места оставлены специально):
1. Отрендерив сцену в окно размером blurSize
2. Нарисуем четырехугольники с полученной текстурой поверх изображения несколько (blurCount) раз, каждый раз увеличивая их размер, от blurSize до полноэкранного размера (640), и уменьшая значение альфа компоненты.
3. Рулим ;) (можно отрендерить сцену еще раз, поверх этого, но мы не будем).
Смотрим код:
Незабудем вернуть видеорежим обратно, для этого просто вызовем функцию "ChangeDisplaySettings(null,0)"
Вот и все ! Уже украли/обрили... Просто, но, черт возьми, эффЭктно (и впереди я, на белом верблюде). Так о чем это я ? Ага, пришло, наконец, время долгожданного прощания. Просьба не устраивать сцен и истерик ;) обнимемся как братья... Э-э-э-э, что там еще говорят ? Желаю счастья в личной жизни... Один маленький, но очень гордый птичка... Нет, не то... Типа, надобранич дитлохи, до зустричи (тут я прям прослезился, как все Хрюши, Степаши и тети Тани/Амаяки Акопяны, канала О.Р.Т., вместе взятые)...
Не успев обрадоваться от вышеописанного расставания (сцена с рыдающими детьми: "Папа ! Папа ! На кого ты нас покинул ?!"). Люба, я вернулся (wmplayer.exe c:\windows\media\tada.wav). Ну "да-ра-гггие мАи" ну не мог же я выпустить вас "в люди" голыми, так сказать ! Так бы сейчас и писали glBegin'ами. Шо вы ? Это уже совсем не модно ! Щас "в Европе, а также в лучших домах Филадельфии" все поголовно юзают массивы вершин. Вообще то, массив вершин (vertex array) - это почти тоже самое, что и команды между glBegin/glEnd, только их выполняет сама карта, подставляя значения из нашего массива. Как нам уже известно, описывать приходится не только, собственно, вершины, но и нормали, текстурные координаты, цвет и пр., поэтому и массивы бывают разные. Однако, мы не будем мучить себя подключением всех массивов, скинем просто все в кучу функцией "glInterleavedArrays" (т.е. данные в массиве идут последовательно, сначала нормаль одной вершины, потом ее текстурные координаты, цвет и пр. затем сами координаты вершины. Затем тоже самое для следующей вершины и т.д.). Она принимает параметрами тип "сваленных в кучу" массивов, тут это GL_N3F_V3F, т.е. N3F - массив нормалей, по 3 float'а на нормаль и V3F - массив вершин, тоже из 3-х float'ов на вершину, так называемый "stride" - "расстояние" между данными для соседней вершины (у нас будет "0" (ebx) т.к. данные в массиве идут подряд), и ,наконец, ссылку на массив с данными (mdlSheep). Но glInterleavedArrays только подключает массивы на отображение, их еще нужно, собственно, отобразить. Делается это функциейй "glDrawArrays". Первый параметр - это тип используемых примитивов (GL_TRIANGLES), второй - это первый элемент массива (ebx=0, т.е. рисуем все элементы) и третий параметр - это общее число элементов...
Дело за малым - осталось найти де взять этот массив ;) Можно, конечно, и ручками (как в следующем приложении), но я (для демонстрации "крутизны" массивов вершин) отконвертил модельку X-Wing'а (предварительно сохранив ее 3DStudio в формате "ASC"). Можно было вставить ее просто как переменную (mdlShip dd ...) но это б заняло полтора мегабайта ;) Так что пришлось вынести ее в отдельный файл, и скомпилить FASM'ом, в результате чего получился 600 Kb бинарник, который я засунул в ресурсы директивой "file".
Обратите внимание как я "генерил" текстуру (так вот откуда Cпилберг спер терминатора T1000 ;)) взяв за основу только красные компоненты "пикселей" (а на деле опкоды... красные уже и сюда добрались...) "GL_LUMINANCE_ALPHA". Для придания текстуре яркости, я использовал специальный режим обработки bitmap'ов (о них в следующем приложении) т.е. здесь - текстуры: "glPixelTransferf" с параметром "GL_RED_SCALE" (множителем красной (нет, ну хоть в кавычках это слово пиши) компоненты) и значением "10.0".
Ну, теперь все быстренько на борьбу с кубиками и торами ! Рисуйте свои модельки и вперед. Помните только (неоднократно натыкался на такое "недопонимание") что массив индексов, это на самом деле массив индексов цветов в режимах с маленькой глубиной цвета (256 цветов и т.д.) а не массив индексов вершин (как в 3D моделях).
Ну почему обязательно карты ? Есть много интересных и полезных спортивных игр ! Например литрбо... оуэ-э-э-э битмап шрифты ! Еще бы, как же иначе мы напишем в нашу демку кучу псевдо-философского бреда, и причем непременно (непреме-е-енно !) "разъежающейся-блендещайся" Tahoma'ой... После главы про outlined шрифты, здесь уже все прозаично. Как обычно "создадим" шрифт:
Теперь, по анологии с outlined шрифтами, преобразуем все это в список команд рисования битмап'ов функцией "wglUseFontBitmaps(контекст OpenGL (ebp),первый символ (ebx),число символов (256),список (берем 0-й))" :
Установим ортогональную проекцию (для битмап'ов работать в ней удобнее). Вот тут начинается самое интересное... Будем делать "Матрицу" ! Ну, ту самую, что "has Neo...". Надеюсь ему понравилось, но мы за него ОТОМСТИМ ! Вощ-щ-щем расклад такой:
1. Заведем массив на каждую "строку" "матрицы" с координатами X (dword), Y (dword) и ее начальным символом
2. Генерим каждой все вышеописанное
3. В основном цикле распихиваем "строки" по сгенереным координатам, каждый раз начиная с начального символа "строки" и "начального цвета" (черного), увеличивая их для каждой следующей буквы
4. Начальный символ увеличивается для каждой "charChangeFrequency" "строки"
5. Каждый последний символ "строки" выделяем голубым цветом (мстим за Нео)
6. Так как координата "Y" увеличивается на размер "строки" по вертикали, то вернем ее на место, пришьем, попутно, + 3 за побег (+ 5 за детсад), т.к. "строки" должны "бежать" вниз
7. Если какая-нибудь "строка" сЦучилась (читай, вылезла за края экрана) - обнулим ей "Y" (шоб неповадно было)
8. Просто матрица это ж страшный "порожняк", поэтому напялим эту в качестве текстуры, для начала, хотяб на кубик (месть продолжается). Делается это как обычно, копированием экрана в текстуру функцией "glCopyTexImage2D"
Надеюсь вы что-нибудь поняли... Если нет, то смотрите код, там понятней. Вообще-то это была задумка написать "город" а-ля в "Матрице", отсюда и кубик, но меня потом в конец обломало :( Пишите сами, в общем. На том и сказке/тьюториалу конец (делу венец и т.п.) а кто слушал #$%&@# !!!
Автор: SolidCode
Дата: 2005-08-04
исходники к статье (находится в архиве wasm_files.zip: files/0383/MultimonDX.zip)
Да, это снова SolidCode со своими мониторами. Очень уж меня интересует эта тема. В предыдущей статье мы разбирались, какую информацию о мониторах можно получить средствами Win32 API. Тогда я наивно полагал, что DirectX – это рулез, потому что глубже работает с видеодрайверами и железом.
Но меня мелкомягкие сильно разочаровали. Оказалось, что с помощью DirectX можно узнать ещё меньше информации по сабджу. Хотя и появляется кое-что дополнительное. Но расскажу обо всём по порядку. Эта статья предполагает, что вы прочитали предыдущую статью и знаете общую логику работы с мониторами в системе Windows . Исследования для этой статьи проводились в рамках DirectX 8.1. Большое спасибо keyMax за прекрасные статьи и переведённые инклюды. Более мелким шрифтом будет даваться информация по некоторым вопросам, которые изменились в DirectX от версии 8.1 до версии 9.
Для инициализации DirectX 8.1 требуется выполнить следующее:
Если функция вернула нормальный указатель на интерфейс, то начинаем исследование ситуации с видеоадаптерами/мониторами. Надо сказать, что DirectX более интересуется видеоадаптерами. А монитор уж там чего-нибудь покажет. В отличие от GDI , здесь можно узнать количество видеоадаптеров заранее. Вот объявление метода из MSDN.
И его вызов средствами MASM32.
Видимо DirectX каждому реальному монитору сопоставляет свою логическую «копию» видеоадаптера, что и определяет возвращаемое значение. При ОДНОМ физическом видеоадаптере и двух реальных мониторах мы получаем значение 2. Да, два видеоадаптера в системе, ни больше и не меньше.
Теперь в цикле будем перебирать адаптеры по номерам и получать доступную информацию в структуру D3DADAPTER_IDENTIFIER8 . Перебор начинаем с 0, что есть D3DADAPTER_DEFAULT . Это первичный адаптер/монитор. Он существует в любом случае. Последним будет адаптер под номером nAdapters -1 . Обычно это значение не превышает двух. Информацию о каждом мониторе получаем с помощью метода GetAdapterIdentifier . Вот его объявление из MSDN.
Далее следует пример кода в MASM 32, который циклом WHILE обрабатывает все адаптеры. Номер адаптера содержится в регистре ESI . Метод должен возвращать значение D3D_OK , если всё нормально и информация получена.
Этот метод предоставляет нам максимум интересующей нас информации, которую можно выжать из DirectX. При этом я рекомендую использовать флаг D3DENUM_NO_WHQL_LEVEL EQU 2. Это запрещает функции зависать надолго разыскивая бесполезные подписи мелкомягких ( WHQL расшифровывается Windows Hardware Quality Labs). У меня функция вообще вылетала в WinXP при использовании без этого флага. А OllyDbg ругался на кучу дополнительных потоков, которые она порождала и забывала убивать. Но использование этого флага рулез, имхо.
Самое интересное – это содержимое структуры D3DADAPTER_IDENTIFIER8.
Давайте посмотрим, что здесь есть интересного. Прежде всего разберём строку Driver. Здесь мы получаем имя основного файла драйвера. Строка Description даёт нормальное имя видеоадаптера, презентабельное для пользователя. Далее следует 64-битное число, представляющее версию драйвера. Оно делится на 4 16-битных числа. В примере, прилагаемом к статье, вы найдёте готовую функцию, превращающую это число в нормальную строку, идентичную той, которую показывает диагностическая утилита DirectX ( dxdiag. exe). Следующие 4 поля особой пользы для нас не предоставляют. В SDK о них сказано, что их можно использовать для определения конкретного чипсета, однако там же советуют использовать эти значения с осторожностью. Далее следует DeviceIdentifier в формате GUID. Функция для его превращения в нормальную строку также находится в примере к статье. WHQLLevel всегда будет ноль, если мы используем флаг D3DENUM_NO_WHQL_LEVEL.
Как видите, реально полезной информации мы получили весьма немного. Правда, узнали имя главного файла драйвера и версию драйвера.
Версия 9.
Применимо к методу GetAdapterIdentifier произошло следующее изменение. Убрали флаг D3DENUM_NO_WHQL_LEVEL и поставили флаг D3DENUM_WHQL_LEVEL . Видимо их достали с руганью по поводу лабораторий качества. Теперь, если в соответствующем аргументе передаётся NULL , то WHQL не получают, а если уж сильно захотели, то ставьте флаг D3DENUM_WHQL_LEVEL .
Структура D 3 DADAPTER _ IDENTIFIER тоже немного изменилась. Примечательно, что добавили строку DeviceName, в которой возвращается внутреннее имя дисплея (типа “\.\ DISPLAY 1”) с намёком на то, что дальше сами получайте информацию об устройстве с помощью стандартных API из user 32. dll.
В восьмой версии DirectX мы ещё можем получить текущий видеорежим соответствующего адаптера с помощью метода GetAdapterDisplayMode;
Для получения всех доступных видеорежимов используем метод GetAdapterModeCount, чтобы получить количество режимов. А потом в цикле перебираем все эти режимы, начиная с 0. В этом нам поможет метод EnumAdapterModes.
В DirectX видеорежимы описываются несколько иначе, чем в GDI. Вот объявление структуры D3DDISPLAYMODE , которая содержит информацию о видеорежиме.
Глубина цвета здесь описывается не количеством битов для описания цвета, а с помощью специальных форматов поверхностей (D3DFORMAT). Они более информативны, чем количество битов.
Если же вы всё-таки слишком любопытные и хотите узнать всё про мониторы, то используете метод GetAdapterMonitor.
Так мы получим стандартный хэндл монитора, а уже от него всю остальную информацию обычными функциями API, которые были рассмотрены в прошлой статье.
На этом наше повествование заканчивается. Более мне не удалось найти способы получить информацию о видеосистеме компьютера. Правда, в интерфейсах DirectDraw (версии DirectX 7 и меньше) можно ещё получить размер видеопамяти. В версии 8 мелкомягкие, по видимому, решили, что эта информация лишняя. Так что Win32API всё-равно незаменимы.
Успешного творчества.
Автор: FrostFix
Дата: 2006-03-16
Исходный код (находится в архиве wasm_files.zip: files/0399/d3d8.zip)
1. Введение
2. Идея
3. Алгоритмы
4. Реализация
5. Результаты
6. Применение
7. Источники
Целью статьи является исследование принципов, позволяющих извлекать трехмерные текстурированные модели из приложений Direct3D.
Задача: Разработать и проверить реализацией методы, которые позволяли бы (без принципиальных изменений) извлекать 3D модели и текстуры из любых приложений, использующих Direct3D.
Требования и ограничения: В силу жесткого ограничения по времени исследования, реализация разработанных методов должна позволять:
1. Извлекать данные из приложений Direct3D 8, поставляемых с SDK (dx8sdk\samples\Multimedia\Direct3D\bin), в силу того, что их исходный код легко доступен каждому;
2. Работать с приложениями не использующие шейдеры (для простоты реализации);
3. Сохранять: текущий установленный материал, значения вершинного буфера из потока 0, текущие значения буфера индексов и текстуру с индексом 0.
Идея состоит в подмене функций COM объектов Direct3D, из которых доступны необходимые для извлечения данные.
Все рассматриваемые приложения (1.1), используют для создания COM объекта Direct3D8 функцию Direct3DCreate8 из d3d8.dll. Эта функция возвращает адрес указателя на таблицу указателей на функции объекта Direct3D8 (согласно интерфейсу IDirect3D8). Необходимо ее подменить. При вызове функций CreateDevice из COM объекта Direct3D8 создается COM объект Direct3DDevice8 – основной объект приложения, использующего Direct3D, этот объект имеет функцию DrawIndexedPrimitive, которая используется для «отрисовки» трехмерных моделей в (1.1). Подмены функции IDirect3D8.CreateDevice, на функцию, которая выполнит действительную CreateDevice и подменит в объекте IDirect3DDevice8 DrawIndexedPrimitive, которая выполнит:
1. cохранение данных в файлы mesh.x и tex.bmp;
2. вызов действительной функции DrawIndexedPrimitive;
3. возврат к выполнению программы.
вполне достаточно для реализации цели.
Вся необходимая исходная информация получена из [1], [2], [3], [4], [5].
1. Подмена библиотеки d3d8.dll естественно позволяет подменить функцию Direct3DCreate8. Для этого необходимо создать соответствующую библиотеку dll, экспортирующую Direct3DCreate8 и скопировать ее в директорию целевого приложения [6].
2. Подмена функций СОМ объектов производится записью в таблицу адресов реализованных согласно (2) функций, с сохранением адресов действительных функций.
3. Параметр obj объектно-ориентированных подмененных функций позволяет получить доступ ко всем функциям COM объекта, и выполнить сохранение необходимых данных.
Реализация произведена в Flat assembler – version 1.62 by Tomasz Grysztar. При реализации проверка ошибок вызовов сознательно игнорируется, как не входящая в рамки рассматриваемой работы (целью которой не является создание приложения сохраняющего модели из любых программ).
1. Создание dll базируется на примере, поставляемом с fasm. Приведем реализацию функции Direct3DCreate8:
2. Функция замещения адресов в таблице адресов функций COM объекта имеет следующие параметры: IntTblAddr – адрес таблицы, MethodNumber – номер функции, NewFunction — адрес замещающей функции, SaveOldFunction – адрес переменной для сохранения адреса исходной функции.
3. Реализация функций MyCreateDevice и MyDrawIndexedPrimitive является типовой для всех замещаемых функций. В MyCreateDevice вызывается CreateDevice и замещается DrawIndexedPrimitive. В MyDrawIndexedPrimitive, если нажата клавиша F12 происходит сохранение данных, далее вызывается DrawIndexedPrimitive. Параметры функций соответствуют параметрам замещенных [6]:
4. Реализация функции сохранения текстуры и трехмерного объекта не представляет особого интереса с точки зрения текущего исследования, приведем ее вкратце:
1. У объекта obj получим установленную текстуру IDirect3DDevice8.GetTexture;
2. Далее сохраним текстуру с помощью D3DXSaveTextureToFile;
3. Получим текущий материал IDirect3DDevice8.GetMaterial;
4. Установим в материале имя файла текущей текстуры;
5. Получим объект индексов Direct3DIndexBuffer8 через IDirect3DDevice8.GetIndices;
6. Определим формат индексов и размер буфера индексов IDirect3DIndexBuffer8.GetDesc;
7. Посчитаем количество треугольников в 3D объекте: (размер буфера индексов)/(размер одного индекса)/3;
8. Получим объект Direct3DVertexBuffer8, хранящий данные вершин: IDirect3DDevice8.GetStreamSource;
9. Получим описание размера буфера вершин: IDirect3DVertexBuffer8.GetDesc;
10. Получим размер одной вершины: D3DXGetFVFVertexSize;
11. Посчитаем количество всех вершин: (размер буфера)/(размер одной вершины);
12. Создадим объект D3DXMesh для сохранения данных в файл: D3DXCreateMeshFVF;
13. Откроем буфер вершин obj для чтения, а D3DXMesh – для записи: IDirect3DVertexBuffer8.Lock, ID3DXMesh.LockVertexBuffer;
14. Запишем данные в буфер объекта D3DXMesh;
15. Закроем буферы: IDirect3DIndexBuffer8.Lock, ID3DXMesh.LockIndexBuffer;
16. Выполним шаги 12 – 14 для индексов;
17. Сохраним данные в файл формата DirectX: D3DXSaveMeshToX.
Созданная программа (несмотря на существенные ограничения ее применимости) позволяет доказать реализуемость рассматриваемой технологии.
Наиболее эффективные, на мой взгляд, способы применения описанной технологии в приложениях Direct3D это:
1. Модификация трехмерных объектов приложений и их текстур;
2. Извлечение моделей из приложений и использование их в собственных целях (если это не нарушает авторских прав создателей);
3. При замещении всех функций интерфейсов Direct3D возможна реализация «трехмерных» копий сцен приложений.
1. Эш Рофэйл, Яссер Шохауд. COM и COM+. Полное руководство. Пер. с англ. – К.: ВЕК +, К.: НТИ, М.: Энтроп, 2000.
2. April 2003 Release of the MSDN Library.
3. d3d8.h, входящий в состав Microsoft Development Environment 2003.
4. d3dfile.cpp из DirectX8 SDK.
5. DirectX 8.1 Programmer's Reference.
6. Рихтер Дж. Windows для профессионалов: создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows/Пер. с англ. – 4-у изд. — СПб: Питер; М.: Издательско-торговый дом «Русская редакция», 2001.