Статьи по Assembler


Ms devstudio - среда разработки asm - часть 2


Ваш пакет MS Developer Studio готов к разработке приложений win32 на MASM.

Любознательный читатель спросит: почему бы не использовать для разработки приложений inline-ассемблер, являющийся, как известно, неотъемлемым атрибутом C++. Вообще-то ничего невозможного на свете нет. Можно и отверткой в ухе ковыряться, только не очень глубоко. Но надо помнить, что inline-ассемблер предназначен для улучшения языка C++, а не для разработки самостоятельных приложений. Поэтому из него исключены большинство директив и, самое обидное, все макросредства, сильно помогающие облегчить процесс программирования.

 

Следующий шаг - это подготовка включаемых файлов:

  • Получите файл includes.zip
  • Распакуйте его и поместите файлы @struct.inc и windows.inc в папку включаемых файлов пакета MS DevStudio (по умолчанию - C:\Program Files\DevStudio\VC\INCLUDE).

Файл @struct.inc - это авторская отсебятина, которой в принципе можно и не пользоваться, а можно и наоборот, добавить в него что-нибудь свое, полезное. Что и для чего в этом файле, вы можете прочитать здесь.

С файлом windows.inc все гораздо сложнее. Это файл заголовков API, ассемблерный аналог той тучи h-файлов, которые содержатся в пакете Visual C++ и начинаются с файла windows.h (и, возможно, не только). Поскольку Microsoft официально не поставляет файл windows.inc (в отличие от windows.h), у ассемблерного программиста в связи с этим возникает большая-пребольшая проблема. Ее можно попытаться решить несколькими путями:

  • транслировать windows.inc из windows.h с помощью специальной программы-переводчика H2INC, поставляемой в составе пакета MASM 6.11+. Сразу скажем, что следует смело отправить эту надежду в мусоропровод. Продравшись сквозь частокол багов H2INC, вы обнаружите, что ее интеллекта хватает лишь на трансляцию тривиальнейших заголовочных файлов, к которым windows.h, безусловно, не относится. Вы утонете в бездне сообщений о некорректном переводе, и ваш сизифов труд по их обходу будет вознагражден получением совершенно негодного результата
  • найти windows.inc (вариант - win.inc) в Интернете. Это гораздо более реально. Существует некоторое количество чудаков (возможно, это дети миллионеров, которым наплевать на необходимость зарабатывать на жизнь), которые тратят свое время на формирование и актуализацию этого файла и раздают его всем желающим. Некоторых из них вы найдете в разделе ссылок. Есть мнение, что пользоваться такими файлами настоятельно не рекомендуется. Представьте себе ситуацию к концу второго месяца возни этого доброго человека с каким-нибудь пятым по уровню вложенности заголовочным файлом в пирамиде windows.h. Возьмет, да и перепутает с устатку порядок описания членов какой-нибудь структуры. Или забудет указать ее выравнивание относительно умалчиваемого. Хорошо еще, если соответствующая функция API при использовании ее вами будет вываливаться с фатальной ошибкой вроде нарушения общей защиты. А может ведь и не вываливаться. И будете вы разбираться, почему глючит ваше приложение, дольше, чем добрый дядя переводил заголовочный файл
  • описывать структуры, объявлять прототипы и делать все прочие действия, которые делает windows.h, внутри собственного проекта. Это еще более реальный вариант. Для этого вам потребуется оперативный доступ к содержимому windows.h из своего проекта (см.ниже). Каждый раз, как у вас возникнет необходимость обратиться к какой-нибудь функции API, вы должны будете найти в windows.h все, что касается ее вызова, и включить это в свой проект, предварительно переведя вручную на язык ассемблера. При наличии небольшого навыка такой перевод выполняется довольно быстро и проблем не вызывает
  • делать все то же самое, но не в рамках текущего проекта, а в едином файле windows.inc, чтобы не повторять эти действия в последующих проектах. Со временем необходимость править windows.inc будет возникать у вас все реже и реже




- Начало -  - Назад -  - Вперед -