Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Dos7book

.pdf
Скачиваний:
76
Добавлен:
09.02.2015
Размер:
5.1 Mб
Скачать

Глава 9: Примеры композиции исполняемых файлов

заглавные. Если ячейка 005Dh не заполнена или если туда вписан знак вопроса, то Reassign.com выведет на экран сообщение помощи (help) из секции 12 и вернет управление командному интерпретатору, оставив код уровня ошибки (errorlevel) 240. Во всех других случаях будет считаться, что начиная с ячейки 005Dh в блок FCB вписано имя переменной окружения, значение которой надлежит заменить.

Секция 2 начинается в строке 122 с вызова процедуры поиска переменной с указанным именем в текущем и нижележащих пространствах окружения. Процедура поиска включает подпрограмму проверки PSP из секции 5, а также подпрограмму поиска имени из секции 6. Подлинность PSP проверяется в строках 175 – 183 по характерным сигнатурам в ячейках [0000] и [0050]. Когда подлинность PSP подтверждена, адрес пространства окружения из ячейки [002C] передается подпрограмме поиска имени, вызываемой из строки 18B.

Подпрограмма поиска заданного имени просматривает все пространство окружения и выходит с установленным флагом ZF, если заданное имя не удается найти. Если же переменная найдена, то полный адрес ее значения, включающий сегмент и смещение, записывается в ячейку памяти, причем адрес этой ячейки вычисляется вычитанием 4 байт из указателя в ячейке [0165]. Благодаря такому

смещению адреса значений переменной из разных пространств окружения не "затирают" друг друга, а располагаются в свободном конце префикса сегмента программы последовательно, один за другим.

При возврате в подпрограмму проверки PSP со сброшенным флагом ZF процесс поиска надо будет продолжить в нижележащем ("родительском") пространстве окружения. Для этого необходимо сначала найти сегментный адрес нижележащего PSP. В качестве кандидатов рассматриваются сегментные адреса в ячейках ES:[0016] и ES:[0010], и затем по отношению к избранному сегментному адресу подпрограмма проверки PSP в строке 1A3 рекурсивно вызовет сама себя. Все процессы проверки и поиска повторятся в нижележащем PSP и в относящемся к нему пространстве окружения. Рекурсивный спуск в нижележащие PSP будет продолжаться дальше и завершится только тогда, когда очередной PSP окажется недействительным или когда в пространстве окружения очередного PSP заданное имя переменной не удастся найти.

После выхода из цепи рекурсивных вызовов продолжится исполнение команд в секции 2. Там в строке 12F адрес значения искомой переменной, найденный в ближайшем ("верхнем") пространстве окружения, записывается в регистры ES:DI. Этот адрес прямо указывает на первую цифру значения, которая определяет основную миссию программы Reassign.com: какое именно новое наполнение должна получить указанная переменная окружения. Допустимых функций всего три, и им соответствуют коды знаков 31h, 32h, 33h. Если код первой цифры в значении переменной будет какой-нибудь другой, то Reassign.com выведет сообщение "Неверное значение переменной" и вернет управление командному

– 519 –

Глава 9: Примеры композиции исполняемых файлов

интерпретатору. Но если все проверки успешно пройдены, то в строке 144 произойдет вызов подпрограммы, исполняющей запрошенную функцию. Адрес точки входа в подпрограмму будет взят из списка 0167 в секции 4.

Исполнение функции 1 начинается со смещения 0213h в секции 8. Сначала вызовом INT 2F\AX=4300h (8.03-22) производится проверка, загружен ли драйвер

HIMEM.SYS (5.04-01). Если драйвер не загружен, то Reassign.com возвратит управление командному интерпретатору, не выводя на экран никакого сообщения и оставив код уровня ошибки (errorlevel) 255. Если же драйвер загружен, то следующим будет вызов INT 2F\AX=4310h (8.03-23) с намерением получить адрес точки входа для запросов к драйверу. Возвращаемый полный адрес используется в строке 22D для запроса функции 08h драйвера Himem.sys (A.12-3) посредством команды CALL FAR. Запрошенная функция возвращает несколько параметров, в том числе размер наибольшего свободного блока XMS-памяти. По нему в строках 236 – 252 определяется оставляемый программой код уровня ошибки, позволяющий потом автоматически задать приемлемый объем RAM-диска. В строках 256 – 263 этот размер переводится в форму десятичного числа. В строках 265 – 277 цифры этого числа переводятся в знаки кода ASCII и записываются в то место, где было прежнее значение переменной в текущем ("верхнем") пространстве окружения. Если места оказывается недостаточно, Reassign.com выводит на экран сообщение "прежнее значение было слишком короткое" и возвращает управление командному интерпретатору, оставляя код уровня ошибки (errorlevel) 240. Если же места достаточно, то происходит возврат из подпрограммы в заключительную секцию 3. Оттуда из строки 14C вызывается подпрограмма копирования, которая

по мере надобности дополняет записанное значение пробелами и копирует его в нижележащие пространства окружения. На том миссия функции 1 завершается.

Исполнение функции 2 начинается со строки 029A в секции 9. Вводимые с клавиатуры знаки воспринимаются и записываются в то место, где было прежнее значение переменной в текущем ("верхнем") пространстве окружения. Ввод знаков посредством прерывания INT 16\AH=10h (в строке 29C) и выведение их на экран посредством прерывания INT 29 (в строке 297) не подвержены перенаправлениям ввода-вывода на уровне DOS. Команды в строках 2AF – 2BD заполняют место предыдущего знака кодом пробела, когда пользователь нажимает клавишу Backspace. Reassign.com выходит из цикла ввода знаков по нажатию клавиши ENTER или клавиши ESC. При нажатии клавиши ESC команды в строках 2CD – 2D0 устанавливают флаги так, что после возврата из подпрограммы копирование нового значения в нижележащие пространства окружения не осуществляется. Переменная сохранит свое прежнее значение, и программа завершится с кодом уровня ошибки (errorlevel) 255. После нажатия клавиши ENTER возврат из подпрограммы и все дальнейшие операции будут происходить так же, как было описано выше применительно к функции 1. Переменная получит новое значение, и программа завершится с кодом уровня ошибки (errorlevel) 000.

– 520 –

Глава 9: Примеры композиции исполняемых файлов

Исполнение функции 3 начинается со строки 2DC в секции 11. Буква диска запрашивается через прерывание INT 21\AH=19h, переводится в код ASCII и записывается в то место, где было прежнее значение переменной. Если там есть место еще хотя бы для одного знака, то к букве диска приписывается двоеточие.

Поскольку "текущий" диск заведомо существует, постольку коду уровня ошибки в функции 3 дана другая миссия определение числа флоппи-дисководов в компьютере. Это нужно знать адаптивным процедурам загрузки, потому что в компьютерах с одним флоппи-дисководом все обращения к диску B: MS-DOS автоматически отсылает к единственному имеющемуся флоппи-дисководу A:. Задачу дополнительно осложняет возможность эмуляции флоппи-дисковода при загрузке компьютера с компакт-диска, не учитываемая в тех данных, которые предоставляет CMOS-память системы BIOS.

Для выяснения числа флоппи-дисководов команды в строках 2F1 – 30C обращаются к таблицам DDT (Disk Data Table, A.03-2). Только в них имеются

сведения о принадлежности каждого логического диска конкретному физическому дисководу. По последовательности таблиц DDT подсчитывается число флоппи-дисководов, причем повторные отсылки к одному и тому же физическому дисководу не засчитываются. Потом в любом случае выполняется возврат из подпрограммы, и Reassign.com завершается исполнением заключительных команд из секции 3. Полученные значения кода уровня ошибки помогают правильно выбрать порядок тестирования дисков в ходе загрузки (пример в разделе 9.09-02).

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

В заключение полезно обратить внимание на модульную структуру программы Reassign.com. Каждая функция выполняется отдельной подпрограммой, не зависимой от остальных. Более того, список адресов подпрограмм в секции 4 содержит три незаполненных позиции (16D, 16F, 171). Если Вас не устраивает предлагаемый набор функций, Вы можете вписать туда адреса вызова Ваших собственных подпрограмм (вместе с тем надо будет изменить верхнюю границу допустимых номеров в строке 13B). Но прежде чем дело дойдет до модернизации программы Reassign.com, следует побеспокоиться о том, чтобы имеющийся ассемблерный текст был бы набран без ошибок. Он не настолько прост, как тексты предшествовавших программ из раздела 9.05, так что было бы опрометчиво сразу запускать на исполнение тот файл, который создаст отладчик Debug.exe в ответ на перенаправление ему ассемблерного текста.

Избежать нежелательных осложнений Вам помогут приведенные в следующем разделе 9.07 полезные советы по обнаружению ошибок в ассемблерных текстах и по тестированию "сырых" исполняемых файлов.

– 521 –

Глава 9: Примеры композиции исполняемых файлов

Примечание 1: если в нижележащем пространстве окружения имеется одноименная переменная с другим значением, то программа REASSIGN.COM переопределит и эту переменную тоже, причем ее новое значение может быть обрезано по длине прежнего. Повторного пользования одним и тем же именем в разных контекстах желательно избегать.

9.07Рекомендации по проверке и испытанию программ

Обычная практика проверки программ, написанных на языке ассемблера, включает анализ листинга, исправление отмеченных там ошибок, и последующее пошаговое отлаживание программы. Исправлять ошибки необходимо в любом случае, но при этом рассчитывать на существенную помощь отладчика DEBUG.EXE не приходится, потому что он не выявляет не-синтаксические ошибки и не расставляет адреса по меткам автоматически, как это делают более совершенные ассемблеры.

При всех очевидных недостатках отладчика DEBUG.EXE встречаются ситуации, когда реальной альтернативы ему нет. Так бывает, когда отладка

выполняется в условиях неопределенности или сопряжена с воздействием на системные установки BIOS и DOS. Поэтому умение пользоваться скромными возможностями отладчика DEBUG.EXE может оказаться очень полезным.

9.07-01 Анализ листинга.

По ходу исполнения команд, из которых состоит ассемблерный текст, отладчик DEBUG.EXE выводит на экран листинг. В нем отмечены выявленные отладчиком ошибки. Листинг смещается по экрану быстро, так что строку с отмеченной ошибкой легко пропустить. Чтобы рассмотреть выведенную на экран часть листинга внимательнее, Вы можете в любой момент приостановить исполнение, нажав на клавишу PAUSE. Нажатие на любую другую клавишу возобновит ассемблирование, но потом оно снова может быть временно остановлено в любой нужный момент. Такие манипуляции клавишами были достаточны при работе на старых компьютерах, но современные компьютеры смещают листинг по экрану слишком быстро. Поэтому бывает удобнее анализировать листинг после перенаправления его в отдельный файл, например, так:

Debug.exe < Reassign.scr > Listing.txt

Выведенный файл Listing.txt теперь можно распечатать или просмотреть с помощью любого текстового редактора. В качестве примера фрагмент листинга программы Reassign.com (из раздела 9.06) показан на рис. 6.

– 522 –

Глава 9: Примеры композиции исполняемых файлов

Рис. 6

Каждая выявленная ошибка отмечена в листинге отдельной строкой с направленной вверх стрелочкой и словом "ошибка" (^Error). Стрелочка указывает на тот знак предыдущей строки, который отладчик не может интерпретировать. Стрелочка вверх на рис. 6 показывает на ошибку в предыдущей строке: действительно, там вместо команды "jmp" набрано "imp". Однако иногда стрелочка указывает на конец строки или на знак точки с запятой, с которого начинается комментарий. Так бывает, когда в спецификации ассемблерной команды отсутствует какой-то необходимый элемент. Выяснить "пропажу" помогут сведения из главы 7, где приведены все допустимые варианты спецификаций ассемблерных команд, которые "понятны" отладчику DEBUG.EXE.

В любом случае строка с выявленной ошибкой не ассемблируется, и вся последующая адресация становится неправильной. По этой причине выявленные отладчиком ошибки должны быть исправлены в первую очередь, и до их исправления какие-либо дальнейшие действия не имеют смысла.

Информативный листинг позволяет выявлять даже такие ошибки, которые отладчик не обнаруживает. Но для этого надо заранее постараться, чтобы сделать листинг достаточно информативным: вписать правильные значения адресов в комментарии к ассемблерному тексту, причем предпочтительно к каждой строке.

В разделах 9.05, 9.06, 9.08 и 9.10 почти каждая строка любого ассемблерного текста содержит комментарий, в котором сразу же после знака точки с запятой указано смещение соответствующей машинной команды. Его надо сверять со смещением в адресе, с которого начинается строка листинга. Если смещения неодинаковы, значит, в предыдущие строки вкралась ошибка. На рис. 6 смещения

– 523 –

Глава 9: Примеры композиции исполняемых файлов

различны начиная со строки 147, и потому ошибку следует искать в предшествующей строке 144. Действительно, сопоставление строки 144 на рис. 6 с исходным текстом выявляет ошибку: набрано "call [BX+005]" вместо "call [BX+0105]". Отладчик эту ошибку пропустил. Такие ошибки часто происходят из-за неправильного набора текстовых сообщений и данных. В любом случае ошибки, вызывающие расхождение смещений, нельзя оставлять без исправления.

Не выявляемые отладчиком ошибки также встречаются в адресах, содержащихся в составе некоторых команд. Если комментарий к строке начинается со знака звездочки, значит, в этой строке имеется команда с адресом назначения.

Он должен быть точно равен фактическому смещению первого байта адресуемой команды или адресуемого блока данных. Для облегчения зрительного поиска строк назначения комментарии к ним начинаются со знака равенства. Помимо того, в

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

Последним важным значением смещения является то, которое отмечает в листинге пустую строку, выводящую отладчик DEBUG.EXE из режима ассемблирования. В ассемблерном тексте из раздела 9.06 эта строка 8-я с конца. Как правило, ассемблирование начинается с адреса 100h, и потому смещение пустой строки должно быть точно на 100h байт больше, чем полная длина файла компилируемой программы. Если нужно сохранить весь ассемблированный код в файле, то перед записью в файл надо ввести в регистр CX число, которое на 100h байт меньше смещения пустой строки в листинге. Если же Ваша цель обнаружить вероятные ошибки, то надо сравнить смещение пустой строки в листинге с числом, вводимым в регистр CX. В частности, в ассемблерном тексте из раздела 9.06, в третьей строке с конца, в регистр CX вводится число 03E0h. Следовательно, в листинге смещение пустой строки должно быть 04E0h: это будет свидетельством отсутствия смещений адресации в сформированной последовательности команд.

9.07-02 Интерактивное отлаживание при составлении программ.

Когда нужно что-либо уточнить, тогда бывает нетрудно набрать вручную 5 – 7 строк ассемблерного текста и тут же их исполнить. Длинные последовательности команд набирать вручную не удается, их приходится набирать отдельно с помощью программы редактирования, а потом посылать полученные файлы отладчику через перенаправление ввода. Но когда ввод перенаправлен, отладчик перестает воспринимать команды с клавиатуры, и преимущества интерактивного взаимодействия с пользователем пропадают. Это обычно принимают как должное, потому что ничего другого не дано. Тем не менее такое мнение ошибочно.

Через перенаправление ввода отладчик готов принять и исполнить команды,

которые отменят это самое перенаправление и вернут ему способность

– 524 –

Глава 9: Примеры композиции исполняемых файлов

интерактивного взаимодействия. Требуемая последовательность команд может выглядеть, например, так:

CS:

 

; Восстановление содержания JFT

mov word ptr

[0018],0101

;

в PSP отлаживаемой программы

mov

AH,62

; Запрос сегментного

адреса

int

21

;

PSP отладчика DEBUG.EXE

mov

DS,BX

; Сегментный адрес –

в регистр DS

mov word ptr

[0018],0101

; Восстановление JFT

в PSP отладчика

int

20

; Возврат к командной строке отладчика

Первые две командные строки восстанавливают ссылки на первый блок описания таблицы SFT в ячейках таблицы JFT (примечание 3 к A.07-1) со смещениями CS:0018h и CS:0019h. Эти ячейки относятся к каналам STDIN и STDOUT, а первый блок описания таблицы SFT (A.01-4) активизирует драйвер консоли (CON), обслуживающий ввод с клавиатуры и вывод сообщений на дисплей. Следовательно, выполненная подстановка восстановит нормальное взаимодействие команд отлаживаемой программы с клавиатурой и дисплеем.

Однако отладчик DEBUG.EXE не руководствуется ссылками, вносимыми в ту копию своего префикса PSP, которую он создает для отлаживаемой программы. Для отладчика изменения должны быть внесены не в копию, а в его собственный PSP (A.07-1), сформированный интерпретатором COMMAND.COM. Сегментный адрес этого PSP возвращает в регистре BX функция INT 21/AH=62h (8.02-73), вызываемая в 4-й строке. В 5-й и 6-й командных строках найденный сегментный адрес используется для того, чтобы выполнить аналогичную подстановку в собственную таблицу JFT отладчика DEBUG.EXE. Тем самым оказываются

подготовлены все условия для восстановления интерактивного взаимодействия отладчика с пользователем. Возврат из процесса исполнения ассемблированных команд выполнен без обычно используемой команды RET (не так, как в примерах из раздела 9.02), а посредством обработчика прерывания INT 20 (8.02-01). В отличие от команды RET, этот обработчик сохраняет положение вершины стека, что бывает полезно для продолжения отладки испытуемой программы.

Во избежание путаницы с командами отлаживаемой программы показанную выше группу команд целесообразно приписывать в форме машинных кодов к концу посылаемого файла. Адрес размещения этих кодов в памяти может быть любым, лишь бы он был не занят. Допустим, что ячейки за смещением F00h заведомо свободны. Тогда строки, которыми нужно заменить обычные последние команды "w" и "q" в посылаемом файле, будут иметь следующий вид:

e F00 2E C7 06 18 00 01 01 B4 62 CD 21 8E DB C7 06 18 00 01 01 CD 20 g=F00

– 525 –

Глава 9: Примеры композиции исполняемых файлов

Если послать через перенаправление ввода командный файл, заканчивающийся этими двумя строками, то будут выполнены все содержащиеся в нем команды, но

исполнение завершится выходом не в командную строку интерпретатора Command.com, а в командную строку отладчика Debug.exe. Очевидное преимущество такого завершения состоит в том, что теперь не нужно заранее определять длину того файла, который должен быть сформирован отладчиком. Фактическая длина любого ассемблированного кода будет показана в листинге, и ее можно ввести в регистр CX с клавиатуры. Еще одно преимущество в том, что снимаются ограничения (примечание 1 к 6.05) на отладку команд, обращающихся к каналам STDIN и STDOUT. Наконец, отпадает необходимость формировать заново

исполняемый файл отлаживаемой программы после каждого внесенного исправления: все коррективы до окончательного завершения отладки теперь достаточно вносить в исходный ассемблерный текст отлаживаемой программы.

Перечисленные преимущества особенно полезны, когда программу формируют по частям, последовательно дополняя уже отлаженный ассемблерный текст новыми группами подлежащих отладке команд. Последовательное отлаживание модулей способствует своевременному обнаружению не-синтаксических ошибок и снижает трудоемкость исправления их последствий. Преимущества последовательной модульной компоновки в полной мере проявили себя при написании тех программ, которые представлены готовыми в разделах 9.06, 9.08 и 9.10.

9.07-03 Отлаживание с использованием batch-файла.

Когда все ошибки из листинга исправлены, и последний прогон ассемблирования новых ошибок не выявил, тогда, значит, настала пора разбираться со всей остальной массой ошибок в ходе отлаживания и тестирования.

Полученный при последнем прогоне ассемблирования файл программы, как правило, еще слишком "сырой", запускать его на исполнение опасно. Для отлаживания его можно передать отладчику DEBUG.EXE прямо из командной строки, как показано во вводной статье к разделу 6.05. Но лучше начинать отлаживание с помощью специально подготовленного batch-файла. Во-первых, отлаживание приходится повторять, и batch-файл избавляет от необходимости набирать строки каждый раз заново. Во-вторых, batch-файл обеспечивает общее пространство окружения. В-третьих, в batch-файле можно задать дополнительные процедуры, которые сделают результат более информативным.

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

– 526 –

Глава 9: Примеры композиции исполняемых файлов

особенности проверяемой программы. Ниже приведен пример batch-файла, написанного для отлаживания функции 2 программы Reassign.com из раздела 9.06.

@echo off

set input=22222

echo Original value of input=%input% Debug.exe Reassign.com input < Reassign.scr set E=

set Z=00 set N= :ErrCycle

for %%Y in (0 1 2 %N%) do if errorlevel %E%%%Y%Z% set E=%E%%%Y if %Z%"==" goto OUT

if %Z%"==0" set Z= if %Z%"==00" set Z=0 set N=3 4 5

if not %E%"==2" if not %E%"==25" set N=%N% 6 7 8 9 goto ErrCycle

:OUT

echo Errorlevel is %E%

echo New value of input=%input% pause

Первые три строки в предложенном batch-файле составляют подготовительную часть, а 4-я строка запускает процесс отлаживания. Чтобы не потерять ориентацию в последовательности проверяемых машинных команд, полезно заранее заготовить распечатку ассемблерного текста отлаживаемого файла с комментариями.

Вызываемый в четвертой строке отладчик DEBUG.EXE получает группу параметров из командной строки и, кроме того, командный файл через перенаправление ввода. Здесь основная роль параметров командной строки их участие в заполнении префикса сегмента (PSP) отлаживаемой программы. В простейшем случае файл Reassign.com может быть вообще пуст, но важно, чтобы его имя вместе с последующими параметрами, если они имеются, было бы вписано в соответствующие поля PSP (A.07-1), обеспечив таким образом формирование должного окружения отлаживаемой программы. Если файл Reassign.com не пуст,

то содержащийся в нем код будет выложен отладчиком в памяти начиная с адреса CS:0100, и этим целесообразно пользоваться при отладке больших программ.

Перенаправление ввода в четвертой строке заставит отладчика ассемблировать команды из строк файла Reassign.scr. Получающийся машинный код будет выложен в память начиная с любого указанного адреса, причем как поверх того

– 527 –

Глава 9: Примеры композиции исполняемых файлов

кода, который изначально скопирован из файла Reassign.com, так и в дополнение к нему. Поэтому файл Reassign.scr может содержать только неотлаженную часть ассемблерного текста составляемой программы. Это не относится к предлагаемым здесь программам: готовый ассемблерный текст нет смысла делить. Однако в любом случае при необходимости отлаживания ассемблерного текста, посылаемого через перенаправление ввода, он должен заканчиваться теми двумя строками, которые предложены в разделе 9.07-02 и которые по окончании ассемблирования обеспечат переход отладчика к приему команд с клавиатуры.

Ожидая ввода команд с клавиатуры, отладчик DEBUG.EXE покажет свое приглашение мигающий знак подчеркивания и предоставит пользователю действовать дальше по своему усмотрению. Лучше начинать отлаживание программы по частям (или по подпрограммам) с помощью команд "G" (= Go, 6.05-07) и "P" (= Proceed, 6.05-14). Проверка по частям менее трудоемка, чем пошаговая. Полезно записывать состояния значимых флагов, регистров и ячеек памяти в критически важных точках, например, в моменты выхода из подпрограмм. Эти сведения упростят поиск причин возможных сбоев. Если будет выявлена ошибка в какой-либо части, то ее нужно будет потом более детально обследовать по группам машинных команд, а затем и по отдельным шагам.

Если Вы сочтете целесообразным закончить сеанс отлаживания, то достаточно набрать команду "Q" (= Quit) и нажать клавишу ENTER. При таком завершении отладчик всегда оставляет нулевой код уровня ошибки. Но когда важно правильно передать тот код уровня ошибки (errorlevel), который оставляет отлаживаемая программа, тогда надо завершать сеанс вызовом обработчика прерывания INT 21\AH=4Ch (8.02-55), то есть так же, как отлаживаемую программу следовало бы закрывать при исполнении вне "оболочки" отладчика DEBUG.EXE.

По окончании каждого сеанса отлаживания исполняются команды в завершающей части испытательного batch-файла, призванные показать последствия сеанса. Результаты исполнения программы Reassign.com выражаются кодом уровня ошибки и изменением значения одной из переменных окружения. Иногда для "отлова" кода уровня ошибки исполняют тестируемую программу в "оболочке" командного интерпретатора COMMAND.COM, запущенного с параметром /Z (6.04), однако из такой "оболочки" значения переменных окружения не передаются. Поэтому здесь испытательный batch-файл в строках 5 – 16 дополнен процедурой, которая определяет оставленное значение кода уровня ошибки. Потом команды в строках 17 – 18 выводят на экран значение кода уровня ошибки и той переменной, которую должна была изменить программа Reassign.com. Последняя строка с командой PAUSE служит только для того, чтобы выведенные на экран значения не были бы сразу же скрыты под панелями файл-менеджера.

Для проверки другой функции испытуемой программы нужно изменить параметры, задаваемые в подготовительной части испытательного batch-файла, а

– 528 –

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]