Вероятно, самым простым способом исследования системной па-
мяти является моделирование ситуации сбоя. Загрузите выбранный
вами текстовый процессор или текстовый редактор, создайте корот-
кий простой текстовый файл и обычным способом вернитесь в работу
с операционной системой MS-DOS. Сразу после этого загрузите прог-
рамму отладки DEBUG и, используя команду D (отобразить на экра-
не), начните сканирование содержимого памяти. Программа DEBUG
всегда в качестве начальной рассматривает точку памяти со смеще-
нием 0100h. Вам не нужно заботиться об установке адреса сегмента
(программа DEBUG по умолчанию устанавливает это значение в любом
случае), но отметьте значение этого адреса на случай, если Вам
понадобится вернуться к нему позже.
В данном случае мы использовали программу обработки текстов
WordStar в персональном компьютере IBM PC. Если вы будете исполь-
зовать другой текстовый процессор или другую персональную систе-
му, не беспокойтесь. Несмотря на то, что никакие два текстовых
редактора не работают с памятью совершенно одинаково (есть даже
- 12-2-
разница в работе разных версий одного и того же текстового редак-
тора WordStar), сам характер проведения загрузки программ опера-
ционной системы MS-DOS поможет нам в наших стараниях. Почти все
текстовые процессоры или текстовые редакторы сначала загружают
программу, а потом используют память, находящуюся выше программы,
для хранения текста. Когда мы загружаем программу DEBUG в систе-
му, чаще всего программа DEBUG будет накладываться на часть текс-
тового процессора или текстового редактора, позволяя нам вести
сканирование памяти снизу вверх в поисках нашего потерянного
текста. Если случайно выбранный вами текстовый редактор окажется
меньше чем программа DEBUG (с точки зрения используемого прост-
ранства в памяти), некоторые данные могут оказаться утерянными,
но для файлов среднего размера большинство данных все еще будет
находиться там, над программой DEBUG.
Приведенные ниже примеры начинаются с создания образца текс-
тового файла, потом следует описание содержимого памяти после
загрузки текстового редактора WordStar и текстового файла, а за-
тем происходит обратный возврат в операционную систему MS-DOS.
Загрузите текстовый редактор WordStar и создайте показанный
ниже файл TEST.TXT:
xxxx1xxxx2xxxx3xxxx4xxxx5xxxx6xxxx7xxxx8xxxx9x10
xxx11xxx12xxx13xxx14xxx15xxx16xxx17xxx18xxx19x20
xxx21xxx22xxx23xxx24xxx25xxx26xxx27xxx28xxx29x30
xxx31xxx32xxx33xxx34xxx35xxx36xxx37xxx38xxx39x40
xxx41xxx42xxx43xxx44xxx45xxx46xxx47xxx48xxx49x50
xxx51xxx52xxx53xxx54xxx55xxx56xxx57xxx58xxx59x60
xxx61xxx62xxx63xxx64xxx65xxx66xxx67xxx68xxx69x70
xxx71xxx72xxx73xxx74xxx75xxx76xxx77xxx78xxx79x80
xxx81xxx82xxx83xxx84xxx85xxx86xxx87xxx88xxx89x90
xxx91xxx92xxx93xxx94xxx95xxx96xxx97xxx98xxx99100
Содержимое файла TEST.TXT может показаться сначала несколько
странным, но задача организации текста становится ясной, когда вы
видите его (или его часть) в памяти. Этот файл состоит из ста пя-
тисимвольных или пятибайтовых слов. Каждое слово нумеруется с 1
до 100, что позволяет нам подсчитывать количество частей или слов
текста, которые мы действительно видим в памяти. Отметим, что
последние "слова" в каждой строке (х10, х20, ... 100) состоят
только из трех символов. Поскольку мы должны располагать символы
"возврата каретки" и "подачи строки" в конце каждой строки, эти
трехсимвольные слова превращаются в пятисимвольные слова. Отме-
тим, что некоторые программы текстовых процессоров и текстовых
редакторов вставляют только символ возврата каретки клавиши
Return (возврата) или Enter (ввода). Такие программы выполняют
функцию подачи на строку автоматически, в действительности не
вставляя этот символ в текст. В таких случаях следует расширять
последние слова каждой строки до четырех символов (хх10, хх20,
... х100).
Выйдем теперь из работы с текстовым редактором WordStar,
сохранив файл при помощи команды Control-KX (или команды Control-
KD, затем Х). Сразу же после этого загрузите программу DEBUG и
начните просмотр памяти на экране в поисках потерянного текста.
Используйте команду D (отобразить на экране) для вывода дампа
- 12-3 -
содержимого памяти на экран и его просмотра до появления искомого
текста в правой стороне экрана дисплея. Ниже показано, как выгля-
дит текст образцового файла в нашей системе. (Отметим, что
действительные адреса скорее всего будут другими в вашей системе).
A> debug
-d 7e10
68F8:7E10 00 00 00 00 00 00 00 00-B9 00 78 78 78 78 31 78 ........9.xxxx1x
68F8:7E20 78 78 78 32 78 78 78 78-33 78 78 78 78 34 78 78 xxx2xxxx3xxxx4xx
68F8:7E30 78 78 35 78 78 78 78 36-78 78 78 78 37 78 78 78 xx5xxxx6xxxx7xxx
68F8:7E40 78 38 32 78 78 78 39 78-31 30 0D 0A 78 78 78 31 x8xxxx9x10..xxx1
68F8:7E50 31 78 32 78 31 32 78 78-78 31 33 78 78 78 31 34 1xxx12xxx13xxx14
68F8:7E60 78 78 78 31 35 78 78 78-31 36 78 78 78 31 37 78 xxx15xxx16xxx17x
68F8:7E70 78 78 31 38 78 78 78 31-39 78 32 30 0D OA 78 78 xx18xxx19x20..xx
68F8:7E80 78 32 31 78 78 78 32 32-78 78 78 32 33 34 78 78 x21xxx22xxx23xxx
-d
68F8:7E90 32 34 78 78 78 32 35 78-78 78 32 36 78 78 78 32 24xxx25xxx26xxx2
68F8:7EA0 37 78 78 78 32 38 78 78-78 32 39 78 33 30 0D 0A 7xxx28xxx29x30..
68F8:7EB0 78 78 78 33 31 78 78 78-33 32 78 78 78 33 33 78 xxx31xxx32xxx33x
68F8:7EC0 78 78 33 34 78 78 78 33-35 78 78 78 33 36 78 78 xx34xxx35xxx36xx
68F8:7ED0 78 33 37 78 78 78 33 38-78 78 78 33 39 78 34 30 x37xxx38xxx39x40
68F8:7EE0 0D 0A 78 78 78 34 31 78-78 78 34 32 78 78 78 34 ..xxx41xxx42xxx4
68F8:7EF0 33 78 78 78 78 34 78 78-78 34 35 78 78 78 34 36 3xxx44xxx45xxx46
68F8:7F00 78 78 78 34 78 78 78 78-34 38 78 78 78 34 39 78 xxx47xxx48xxx49x
-d
68F8:7F10 35 30 0D 0A 78 78 78 35-31 78 78 78 35 32 78 78 50..xxx51xxx52xx
68F8:7F20 78 35 33 78 78 78 35 34-78 78 78 35 35 78 78 78 x53xxx54xxx55xxx
68F8:7F30 35 36 78 78 78 35 37 78-78 78 35 38 78 78 78 35 56xxx57xxx58xxx5
68F8:7F40 39 78 36 30 0D 0A 78 78-78 36 31 78 78 78 36 32 9x60..xxx61xxx62
68F8:7F50 78 78 78 33 78 78 78 78-36 34 78 78 78 36 35 78 xxx63xxx64xxx65x
68F8:7F60 78 78 36 36 78 78 78 36-37 78 78 78 36 38 78 78 xx66xxx67xxx68xx
68F8:7F70 78 36 39 78 37 30 0D 0A-78 78 78 37 31 78 78 78 x69x70..xxx71xxx
68F8:7F80 37 32 78 78 78 37 33 78-78 78 37 34 78 78 78 37 72xxx73xxx74xxx7
-d
68F8:7F90 35 78 78 78 37 36 78 78-78 37 37 78 78 78 37 78 5xxx76xxx77xxx78
68F8:7FA0 78 78 78 37 39 78 38 30-0D 0A 78 78 78 38 31 78 xxx79x80..xxx81x
68F8:7FB0 78 78 38 32 78 78 78 38-33 78 78 78 38 34 78 78 xx82xxx83xxx84xx
68F8:7FC0 78 38 35 78 78 78 38 36-78 78 78 38 37 78 78 78 x85xxx86xxx87xxx
68F8:7FD0 38 38 78 78 78 38 39 78-39 30 0D 0A 78 78 78 39 88xxx89x90..xxx9
68F8:7FE0 31 78 78 78 39 32 78 78-78 39 33 78 78 78 39 34 1xxx92xxx93xxx94
68F8:7FF0 78 78 78 39 35 78 78 78-39 36 78 78 78 39 37 78 xxx95xxx96xxx97x
68F8:8000 78 78 39 38 78 78 78 39-39 31 30 30 0D 0A 1A 1A xx98xxx99100....
-d
68F8:8010 1A 1A 1A 1A 1A 1A 1A 1A-1A 1A 00 E8 EC 01 E8 C2 ...........hl.hb
68F8:8020 ......
Запишите адрес, в котором вы найдете текст. В нашем случае
это был адрес 68F8:7E1 (шестнадцатеричное значение). Продолжим
просмотр памяти до тех пор, пока больше не будет видно подлежащего
восстановлению текста, и запишем адрес конца этого текста (в нашем
примере - это значение 68F8:8019).
На предыдущем экране мы видели, что весь файл еще находится в
памяти. Если мы создали файл больший, чем имеем доступной памяти,
только часть этого файла (та, что была подвержена редактированию
последней) будет оставаться резидентной в памяти. Просматривая па-
мять за пределами границ, показанными на предыдущем экране, мы об-
наруживаем, что в нашей системе 19449 байтов текста может содер-
жаться в памяти. Если мы можем так много байтов текста восстано-
- 12-4 -
вить из памяти, мы может избежать огромных объемов повторного на-
бора текста. В предыдущем примере, однако, мы знаем, что достигли
конца текста в адресе 8019, поскольку это то место, где закончи-
лись значения строки Control-Z (шестнадцатиричное значение 1А в
коде ASCII). Эти значения требуются для текстового редактора
WordStar в качестве маркеров конца файла, поэтому эти значения за-
писываются на диск при сохранении файла.
Ниже показано, как перепутанный в памяти текст может быть
сохранен на диске, пока вы по-прежнему работаете в программе
DEBUG.
-n test.sav
-h 8019 7e1a
FE33 01FF
-r bx
BX 0000
:
-r cx
CX 0000
:1ff
-r
AX = 0000 BX = 0000 CX = 01FF DX = 0000 SP = FFEE BP = 0000
SI = 0000 DI = 0000
DS = 68F8 ES = 68F8 SS = 68F8 CS = 68F8 IP = 0100 NV UP DI PL NZ
NA PO NC
68F8:0100 C9 DB C9
-w 7e1a
Запись 01FF байтов
-q
A>dir test.sav
Tом в дисководе А не имеет метки Kаталог тома в дисководе А:\
TEST SAV 522 4-09-85 11:03a
1 Файл(ы) 188416 байтов свободны
A>
Первый шаг в приведенном выше примере заключается в указании
имени файла, которое использует программа DEBUG при операциях счи-
тывания и записи на диск при помощи команды N (имя). Новое имя
файла должно использовать, например, имя TEST.SAV. Далее исполь-
зуйте адрес смещения начала текста (7EA) и адрес конца (8019) для
вычисления того сколько байтов должно записываться на диск. Встро-
енная в программу DEBUG команда Н ("Шестнадцатиричное арифмети-
ческое действие") является полезным инструментом для вычисления
нужного нам результата. При задании адресных значений после коман-
ды Н убедитесь, что вы указали конечный адрес перед начальным ад-
ресом, потому что разность должна быть положительным целым числом.
На предыдущем экране результат в левой части представляет собой
сумму двух шестнадцатиричных адресных значений. Разность между
двумя адресными значениями (справа) представляет количество бай-
тов, которое мы хотим записать на диск. Загрузите это значение в
регистр СХ, готовясь к выполнению команды W (запись). Отметьте,
что регистр ВХ также используется вместе с регистром СХ для раз-
мещения значений, больших, чем FFFF (в противном случае этот ре-
гистр должен содержать нулевое значение). Далее мы будем записы-
вать данные на диск, задавая начальный адрес.
После того, как файл был сохранен и вы вернулись в операцион-
ную систему MS-DOS, наберите имя файла на экране, чтобы проверить
