MS-DOS. РУКОВОДСТВО РАЗРАБОТЧИКА



На главную

Подписка

Новости

Главная / MS-DOS / MS-DOS. РУКОВОДСТВО РАЗРАБОТЧИКА / Глава 11 / Восстановление после сбоев, произошедших во время обработки текста или редактирования текста

Восстановление после сбоев, произошедших во время обработки текста или редактирования текста

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

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

Вероятно, самым простым способом исследования системной памяти является моделирование ситуации сбоя. Загрузите выбранный вами текстовый процессор или текстовый редактор, создайте короткий простой текстовый файл и обычным способом вернитесь в работу с операционной системой MS-DOS. Сразу после этого загрузите программу отладки DEBUG и, используя команду D (отобразить на экране), начните сканирование содержимого памяти. Программа DEBUG всегда в качестве начальной рассматривает точку памяти со смещением 0100h. Вам не нужно заботиться об установке адреса сегмента (программа DEBUG по умолчанию устанавливает это значение в любом случае), но отметьте значение этого адреса на случай, если Вам понадобится вернуться к нему позже.

В данном случае мы использовали программу обработки текстов WordStar в персональном компьютере IBM PC. Если вы будете использовать другой текстовый процессор или другую персональную систему, не беспокойтесь. Несмотря на то, что никакие два текстовых редактора не работают с памятью совершенно одинаково (есть даже разница в работе разных версий одного и того же текстового редактора 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 (или команды ControlKD, затем Х). Сразу же после этого загрузите программу DEBUG и начните просмотр памяти на экране в поисках потерянного текста.

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

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 байтов текста может содержаться в памяти. Если мы можем так много байтов текста восстановить из памяти, мы может избежать огромных объемов повторного набора текста. В предыдущем примере, однако, мы знаем, что достигли конца текста в адресе 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, наберите имя файла на экране, чтобы проверить его содержимое. Позже вы можете объединить этот файл с другими частями восстанавливаемого файла при использовании вашего текстового процессора.

Но что мы должны делать, когда не весь потерянный текст можно найти в памяти ОЗУ? Текстовый редактор WordStar, подобно большинству других программ обработки текстов, постоянно перемешивает текст, то занося его в память, то выводя его из памяти по мере вашей работы с редактируемым текстом. Если вы редактируете уже существующий файл, скажем, файл с именем TEST.TXT, текстовый редактор WordStar создает некий файл с именем TEST.$$$, которое используется для хранения нового отредактированного текста. После того, как вы закончили редактирование и сохранили результаты своей работы на диске, программа переименовывает файл TEST.TXT в TEST.BAK (производя запись поверх старого файла TEST.BAK, если таковой существовал), а файл TEST.$$$ никогда не будет виден в каталоге в момент возврата в операционную систему MS-DOS. Если, однако, программа завершится аварийно, вы обнаружите файл с именем TEST.$$$ в каталоге. Если нельзя будет найти весь текст в памяти, используя программу DEBUG, проверьте содержимое файла с расширением $$$ на наличие в нем остального текста. Если нельзя сразу же определить состояние вашего файла из непосредственного просмотра каталога, возможно, вам придется обратиться к дисковой утилите (такой, как "Norton-утилита" или "Ultra_утилита", описанные в предыдущей главе), которая может отображать скрытую на диске информацию прежде, чем делать это. Однако, проверьте состояние диска программой CHKDSK. Это позволяет вам узнать, есть ли на диске какие-либо перемешанные кластеры. Если такие кластеры появились на диске после неудачно проведенного сеанса редактирования, часть потерянного текста может оказаться в этих потерянных кластерах. Вы можете восстановить их, задав параметр /F в команде CHKDSK, но делать это нужно только после того, как проверили содержимое памяти ОЗУ и сохранили перепутанный текст на диске.

Как было замечено выше, способы, которыми различные программы текстовой обработки и текстового редактирования используют память, сильно отличаются друг от друга. Все они работают с разными адресами в памяти. Одни занимают больше места в памяти, чем другие. Некоторые программы требуют множества областей памяти для работы с текстом, которые иногда называют "буферами", что еще больше усложняет работу. Если, однако, вы никогда раньше не пытались восстанавливать смешанные данные из памяти, представленные выше примеры предоставят вам полезные для этого инструменты и средства.