Использование Browse Info при разработке ассемблерных приложений — Архив WASM.RU

  Всякий сколько-нибудь значительный программный проект содержит сотни, а то и тысячи идентификаторов. Как у программистов хватает фантазии их придумывать - это отдельная тема для исследования, пока что ждущая своего Фрейда, или Павлова, или Кастанеду, или, на худой конец, Маркеса.

Тут сразу следует напомнить о настоящих ассемблерщиках, которые не признают даже структурных директив MASM 6.1+. Ко всем прочим бедам они подбрасывают своему серому веществу еще и задачку придумывать имена для прорвы меток. Не заботясь о своем здоровье, надо сказать. Потому что, как известно, ничто так не разрушает здоровье, как работа, связанная с необходимостью принятия микрорешений. Позволим себе напомнить вам общеизвестный факт, что уровень преступности, суицида, алкоголизма, сексуальных извращений и политической активности среди сортировщиков куриных яиц примерно в восемь раз выше, чем среди трактористов!

А ведь сортировщики куриных яиц еще не сталкиваются с такой проблемой, как глобальность идентификаторов в пределах модуля! Спасибо любимой Microsoft за то, что хоть метки стали локальны в пределах процедуры. Впрочем, специально для садомазохистов разработчики предусмотрели директиву OPTION NOSCOPED - кайфуйте, ребята.

  Каждый крутится как может. Шаблонно мыслящие конформисты идут на поводу у Чарльза Симони и украшают свои исходники венгерской тавтологией вроде lpSomeTable. Аристократические отпрыски Йеля и Итона, сложив губки гузкой, выстукивают холенымы ногтями имя функции: PleaseGiveMeAnErrorCode. Раздолбанные хакеры, вытерев рукавом пиво с клавиатуры, без раздумий используют получившуюся комбинацию: p9ijhbgfd, и в течение следующей минуты навешивают на нее как минимум сорок строк кода. Стиль русских программистов старшего поколения, заставших время, когда их называли советскими программистами, особый, и не меняется уже много лет: vodka362, kolbasa220. Изредка попадающиеся в этой экологически нездоровой среде женщины широко используют свои специфические ассоциации: carnation, champagne, alwaysultraplus. Педанты же как всегда педантичны: proc_for_scan_table_of_strings_00000001.

  И всех этих таких разных людей объединяет одна неизбежная, как желание выпить, проблема. Однажды (раньше или позже в зависимости от того, насколько способен программист организовать программу) мозг перестает контролировать расплодившихся идентификаторов. Всякий раз вы легко опознаете этот момент, застав себя запускающим контекстный поиск по папке проекта. Обычно после этого следуют коренные изменения в архитектуре программы: переформируются модули, рождаются новые классы, форматируется диск, наконец. Отсюда и известная присказка, что мол-де каждая программа пишется два раза.

  Спасибо Microsoft: у нас теперь есть средство, позволяющее отложить этот тяжелый момент на этап, когда переписывать программу заново будет уже поздно. Это средство называется Browse Info. Оно встроено в MS Developer Studio и занимается вот чем. Стоит вам обнаружить где-нибудь в тексте упоминание какого-нибудь идентификатора, как ваш самый длинный палец получает возможность щелкнуть по правой кнопке мыши, и в появившемся контекстном меню тот палец, что покороче, может выбрать пункт "Go to Definition Of..." или пункт "Go to Reference Of...". И выбрав один из этих пунктов, вы мгновенно оказываетесь прямо в точке, где этот идентификатор описан, либо в точке, где на него ссылаются. Причем независимо от того, где это точка находится, включая все до единого файлы проекта и всю громаду заголовочных файлов API. DevStudio заботливо откроет перед вами нужный файл и подсветит искомый идентификатор.

Особенно полезна эта возможность для чудаков, пытающихся писать прикладной софт под win32 на ассемблере. Поскольку Microsoft не поставляет заголовочных файлов API в ассемблерной транскрипции, а имеющим хождение в Интернете файлам независимых разработчиков полного доверия нет, рекомендуется строить файл windows.inc самостоятельно. Это совсем не сложно.

  Прежде чем обсуждать особенности настройки DevStudio, несколько слов о организации работы Browse Info.

  Информация об используемых в проекте идентификаторах и их местоположении собирается в файле, имеющем расширение .bsc и имя, по умолчанию совпадающее с именем проекта. Этот файл (опять же по умолчанию) располагается в папке Debug. Как Browse Info обращается к этому файлу, как он извлекает из него информацию, и как с ее помощью подставляет пользователю нужный ему фрагмент исходного текста проекта, мы разбираться не будем. Работает - и слава богу.

  А вот откуда берется файл .bsc - разобраться надо, потому что без понимания этого процесса запустить Browse Info в ассемблерном проекте вряд ли удастся.

  Процесс создания базы данных .bsc, как и следует ожидать, происходит на обоих этапах построения проекта - и на этапе компиляции, и на этапе компоновки.

  Компилятор (будь то cl.exe для C++ или ml.exe для MASM) создает промежуточный файл базы данных, содержащий, естественно, только информацию об идентификаторах данной единицы компиляции - cpp-файла или asm-файла. Этот промежуточный файл имеет расширение .sbr и имя, по умолчанию совпадающее с именем компилируемого файла. Размещается он там же, где и создаваемый объектный файл - в папке Debug. Для того, чтобы компилятор озаботился созданием sbr-файла, в его командную строку следует включить опцию /FR или /Fr.

Опции отличаются друг от друга тем, что первая из них включает в sbr-файл информацию обо всех идентификаторах (в том числе локальных), а вторая - только об объявленных внешними и публичными. Выбор - за программистом.

Опции предоставляют возможность изменить местоположение и имя создаваемого sbr-файла, как, например: /FR"..\Support Files\browseinfo.sbr"

Поскольку компиляция файлов C/C++ поддерживается MS Developer Studio, то для того, чтобы заставить компилятор создавать sbr-файл, следует запустить диалог Project Settings, открыть вкладку C/C++, выбрать в списке Category пункт Listing Files, и поставить галочку в чекбоксе Generate browse info. Если нужно заменить местоположение или имя sbr-файла, следует воспользоваться полем Intermediate browse info file destination. А замена опции /FR на опцию /Fr производится галочкой в чекбоксе Exclude local variables from browse info.

Для ассемблерных файлов опцию в нужной форме следует прямо указать в командной строке на вкладке Custom Build при настройке MS Developer Studio.

  На этапе компоновки проекта из промежуточных sbr-файлов, созданных компилятором для каждого из модулей, собирается один на весь проект bsc-файл. Правда, слова "на этапе компоновки" отнюдь не означают, что этим занимается сам компоновщик. Для сборки bsc-файла существует специальная утилита - bscmake.exe, находящаяся в папке исполняемых файлов Vc\bin MS Developer Studio.

Включить вызов утилиты bscmake.exe можно с помощью чекбокса Build browse info file, находящегося на вкладке Browse Info диалога Project Settings. Там же можно при необходимости поменять местоположение и имя bsc-файла, подавить выдачу баннерного текста и задать другие опции командной строки утилиты.

  Учитывая обширность заголовочных файлов API, следует ожидать, что удовольствие от применения Browse Info хорошо оплачено ресурсами компьютера. Так оно и есть. Sbr-файл, образованный из чистого windows.h, весит почти восемьсот кило. А образованный из него bsc-файл - в два с лишним раза больше. При включенном Browse Info соответственно увеличивается время компиляции и компоновки проекта. Это обстоятельство могло бы превратить жизнь программиста в сущий ад, если бы не добрые дяди из Microsoft, предусмотревшие инкрементную обработку этих файлов. Суть ее в том, что сборка bsc-файла выполняется каждый раз не заново, а только с учетом реально произошедших изменений в проекте. Определить же, какие именно изменения произошли, утилита bscmake.exe умудряется очень просто. Всякий раз после очередной сборки она усекает до 0 размер участвовавших в сборке sbr-файлов. Таким образов в следующем сеансе сборки примут участие только те sbr-файлы, которые с прошлого раза прошли реальную перекомпиляцию.

  Ну и, наконец, самое интересное. Как настроить Browse Info для работы с ассемблерным проектом. Специфика организации рабочей среды такова, что имеет смысл рассматривать два варианта настройки:

• рабочая среда (workspace) содержит один проект
• рабочая среда содержит несколько проектов

Вариант с одним проектом:

1. Создайте и настройте рабочий проект так, как указано в статье "ms devstudio - среда разработки asm"
2. В диалоге Project Settings на вкладке Custom Build в командную строку компилятора включите опцию:
   Код (Text):

   1. /FR"Debug\$(InputName).sbr"
   Это необходимо сделать для всех asm-файлов, для которых вы хотели бы иметь включенным средство Browser Info.

   Как видно, sbr-файлы будут помещаться в папку Debug с именем, соответствующим имени asm-файла. Эта папка выбрана нами потому, что по умолчанию в нее же помещаются sbr-файлы модулей, написанных на C/C++. Учтите, что в начале работы с проектом она не существует, поэтому попытка компиляции даст ошибку. Создайте ее вручную.

3. Если проект смешанный и содержит также файлы С/C++, включите для них опцию Browser Info установкой чекбоксов в диалоге Project Settings на вкладке C/C++ так, описано выше в этой статье.
4. Если проект чисто ассемблерный, то следует обеспечить доступ к заголовочным файлам C/C++ windows.h с тем, чтобы использовать их как справочные при построении собственного файла windows.inc. Для этого:
   • создайте файл brinfo.cpp и включите его в проект
   • содержимое файла brinfo.cpp должно представлять собой единственную строку:
     Код (Text):

     1.  
     2. #include <windows.h>
     3.  
   • включите для этого файла опцию Browser Info как для обычного C++-файла
   • откомпилируйте его
5. В диалоге Project Settings на вкладке Browse Info:
   • установите чекбокс Build browse info file
   • установите чекбокс Suppress startup banner
   • дополните содержимое поля Project options следующим текстом:
     Код (Text):

     1.  
     2. Debug\*.sbr
     3.  
     Таким образом вы дадите утилите bscmake.exe команду включить в сборку все sbr-файлы, содержащиеся в папке Debug
6. Выполните компиляцию всех модулей проекта, а затем его компоновку. Browser Info готово к работе.

  Следует учесть одно неприятное обстоятельство. Рабочая среда определяет необходимость запуска утилиты bscmake.exe по факту выполнения компиляции хотя бы одного файла C/C++. Ассемблерные же файлы, будучи компилируемы посредством Custom Build, к сожалению, такой команды рабочей среде не дают. Поэтому все изменения в составе идентификаторов в ассемблерных файлах остаются втуне до тех пор, пока не будет перекомпилирован хотя бы один cpp-файл проекта и после этого не выполнена его компоновка. В чисто ассемблерных проектах придется вручную вызывать компиляцию файла brinfo.cpp.

В этой беде мог бы помочь вынос вызова утилиты bscmake.exe на этап Post-build step. Однако, этот фокус не проходит: дело в том, что однажды активизировавшись, Browse Info открывает bsc-файл и держит его в дальнейшем в открытом состоянии, запрещая таким образом запись в него всем внешним программам. Этот запрет отменяется только на этапе компоновки проекта, но не на этапе Post-build step.

  Вариант с несколькими проектами базируется на тех же идеях, что и вариант с одним проектом, но с учетом некоторых коррекций:

• прежде всего следует определиться, имеется ли необходимость иметь единое для всех проектов пространство идентификаторов (не в смысле программирования, а в смысле просмотра их с помощью Browse Info), или у каждого проекта должно быть свое пространство, или проекты можно разбить на группы, с отдельным пространством для каждой группы
• для каждого пространства следует определить одну папку, в которой должны содержаться все sbr-файлы модулей, относящихся к этому пространству
• для каждого пространства следует использовать отдельный файл brinfo.spp

© Svet(R)off