Отладка приложений

       

истории р-кода


Visual Basic 1, представленный в 1991 году, был многообещающим прогрессом в средствах программирования. В начале 90-х, разработки для Microsoft Windows необходимо было писать на языке С средствами SDK, что было, вообще говоря, довольно сложно и требовало больших усилий. Visual Basic обещал и, в большинстве случаев, предоставлял возможность "рисовать" интерфейс пользователя (UI) при помощи инструмента, получившего название WYSIWYG (What-You-See-Is-What-You-Get — "что -вы -видите, то -вы -и получаете"), и легкий способ связывать код с событиями пользователя, такими как щелчок кнопкой мыши. Необычным свойством в Visual Basic I было то, что он компилировал окончательное приложение не в "родной" выполняемый код, а в форму, называемую р-кодом.

Термин р-код (p-code — сокращение от packed code, переводится как "упакованный код") происходит от названия метода сокращения объема памяти для хранения двоичных файлов (размер р-кода намного меньше, чем код языка ассемблера для процессоров Intel x86). При "компиляции" приложения в Visual Basic 1 создается регулярный выполняемый код, но это только оболочка для р-кода. Когда запускается "компилированный" двоичный файл (с этого начинается так называемое "время выполнения" (run-time) программы), по определенному смещению в памяти отыскивается р-код и начинается его выполнение. Известно, что вместе с приложением должна быть загружена большая библиотека динамической компоновки (DLL) VBRUN100.DLL, которая содержит интерпретатор р-кода.

DLL иногда называют также библиотеками времени выполнения (run-time library). — Пер.

Интерпретатор р-кода — стековая машина, которая транслирует специальные коды операций в операции CPU. Во времена MS-DOS и 16-разрядных Windows компания Microsoft предлагала иную форму р-кода, генерировавшуюся в системах программирования C/C++ 7.x. В действительности, первоначальные 16-разрядные версии продуктов Microsoft Word, Excel и PowerPoint широко использовали р-код этой системы в своих UI-кодах, чтобы достичь компромисса "размер памяти/производительность" и обеспечить выполнение этих приложений в операционных системах с ограниченной памятью (например, выпускавшихся тогда Windows 3 и 3.1).
С идеей реализации р-кода в системах C/C++ 7.x, которая, вероятно, близка к реализации р-кода в Visual Basic, можно ознакомиться в библиотеке MSDN, найдя тему "Microsoft P-Code Technology" (Технология р-кода компании Microsoft).
Все версии Visual Basic от 1-й до 4-й генерировали только р-код. Самая большая проблема в его применении состояла в том, что он был медленнее, чем исполняемый двоичный. Старая шутка гласила, что вы общались с Visual Basic на расстоянии в целую милю (потому что приложение работало очень медленно, т. к. использовало трехмерные элементы управления для всех текстовых кнопок). Компания Microsoft никак не могла повлиять на выбор разработчиками элементов управления, но учла просьбу "номер один" разработчиков Visual Basic, требовавших возможности компилировать исполняемые файлы.
Начиная с Visual Basic 5, выпущенного в 1997 году, компания Microsoft добавила специальный режим, который поддерживал такую компиляцию. Разработчики Microsoft также переписали исполнительную (run-time) систему Visual Basic, сделав ее быстрее. Результатом обоих изменений было фантастическое повышение производительности приложений Visual Basic. Единственный недостаток заключался в том, что Microsoft сделала лишь точечную прививку свойства родной компиляции к дереву свойств системы Visual Basic, а не полностью интегрировала компиляцию и отладку со средой VB IDE. После компиляции приложения в исполняемый код программисту предоставлялась "полная свобода" в его отладке. Поскольку двоичные файлы Visual Basic не имеют достаточного количества отладочных символов, что обсуждалось в разделе "Отладка компилированного кода Visual Basic" главы 5, разработчик почти вынужден отлаживать программу на необработанном языке ассемблера.
Самый большой недостаток компиляции в исполняемый код заключается в том, что VB IDE понимает только интерпретируемый р-код. Таким образом, VB-отладчик имеет дело с р-кодом, а это совсем не то, что получается в результате — исполняемый компилированный код.С точки зрения отладки и тестирования ситуация неприятная, — даже отдавая предпочтение компиляции в двоичный р-код, вы не отлаживаете точно те биты, которые посылаете заказчикам. К сожалению, ничего не остается, как мучиться с отладкой компилируемого двоичного VB-файла под отладчиком Visual C++. Остается надеяться, что в будущей версии Visual Basic или Microsoft Visual Studio эта проблема будет исправлена, и приложения, отлаженные разработчиками, будут точно соответствовать тому, что получат заказчики.

Содержание раздела