It happens to everyone. It's near 5:00 pm on a Friday and you're typing furiously away in WordPerfect, finishing a five page report. You press to exit, "N" to not save it again, and "Y" yes to exit. But wait a minute! Not only did you make some major changes, you hadn't saved it since the first page! Never mind the fact that WordPerfect warns you when you try to exit if you haven't saved. The warning only tells you if you are safe by displaying (Text was not modified) in the lower right hand corner. It doesn't tell if you need to save your document. But none of that makes you feel any better. You've just lost your document and with that, several hours of work.

What you need is a hero, a Harrison Ford computer whiz to come into your office with a fedora hat, bullwhip, and a briefcase replete with utility disks. Who can you call upon? Well, providing that you have not turned off your machine or run any other programs in the interim, the answer is as old as DOS 1.1 -- DEBUG. And like a hero's quest for what was lost in antiquity, the journey is not always pretty. DEBUG is a powerful DOS tool that ranges in abilities from letting you create assembly language programs to displaying the contents of your memory. DEBUG let's you get under DOS's skin, and accordingly it has the ability to hurt your hard disk as well as help. Roll up your sleeves, take a deep breath, and get a formatted floppy diskette before you begin. If you don't have a copy of DOS on your hard drive, you will need your DOS diskette, too. Your first and most important job is to rescue your file from memory. Once that's done you can begin looking for other parts of it that may be scattered across your hard disk. This example assumes you are not working with an enormous file that is spread across several memory segments. The process isn't really difficult, but it can be tricky enough to someone who has never seen a hexadecimal based number or used DEBUG. If your file does extend across two or more segments, the process gets more complicated.

It is convenient here to divide your computer's one megabyte of base RAM into 16 segments each of which are 64 kilobytes long. You can normally address the lower ten 64 K segments (for a total of 640 K). The other six are for ROM programs, video displays, hard disk interfaces, network connections, and other special functions provided by your system. A map of these ten segments of user memory starts with the lowest segment, 0000, which is the bottom of RAM. It increases from 0000 to 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, and 9000. Your lost or unsaved file is probably somewhere between 3000 and 9000.

Follow these instructions carefully:

1) If DEBUG.COM is on your hard disk, just type DEBUG. If it is not, stick the DOS diskette in drive A:, and type A:DEBUG. In either case, you will see the DEBUG prompt, which is just a hyphen at the left edge of your screen.

2) Try to remember a key word near the very beginning of your file. If you were writing a report and it was titled "BUDGET REPORT", the word "BUDGET" will do just fine. Chop off the last letter, since some word processors modify final letters slightly. This would leave you with "BUDGE".

3) Give DEBUG the command to search for this word. You need to tell it which memory segment to search (9000 to 0000). DEBUG will search every nook and cranny of each 64 K segment, but it can't handle more than one segment at a time. For the purposes of this example, use the word "BUDGE". You would replace "BUDGE" with a key word in your document if this was your lost file. Type in everything below except the hyphen:

-S 9000:0 LFFFF "BUDGE"

What this command says is: "Search though memory starting at the beginning of segment 9000, continue for 65,535 (hex FFFF) bytes, and report the address each time it finds the letters 'BUDGE'." DEBUG will zip all the way though segment 9000, searching for this exact string of letters. If it finds the string, it will print one or more eight digit hexadecimal numbers with a colon in the middle:

9000:2F3D
9000:301E
9000:317F
-

These hexadecimal numbers would represent the addresses in memory segment 9000 of any occurrences of the letters "BUDGE". DEBUG may print one of these numbers, a list of them, or nothing except another hyphen. If it prints one or more of these hex numbers, go to step 5. If not, then it didn't find anything, so you have to tell it search the next lower segment of memory.

4) Since DEBUG didn't find the word in segment 9000, work your way down the following commands one by one, remembering not to type the hyphen.

-S 8000:0 LFFFF "BUDGE"
-S 7000:0 LFFFF "BUDGE"
-S 6000:0 LFFFF "BUDGE"
-S 5000:0 LFFFF "BUDGE"
-S 4000:0 LFFFF "BUDGE"
-S 3000:0 LFFFF "BUDGE"
-S 2000:0 LFFFF "BUDGE"
-S 1000:0 LFFFF "BUDGE"

It is extraordinarily unlikely that it would find something in the lowest segments, but when you're desperate, you can't lose anything by checking. If you work you way down the ladder far enough, DEBUG will definitely find something, since it will stumble over itself. When you tell DEBUG to do something, it uses a part of memory to hold the instructions you gave it, and at some point it will find these instructions and end up telling you its own address. If you get to the end of the file without having DEBUG print out any hexadecimal addresses, something is wrong. Make sure you removed the last letter of the word you're searching for, and that you spelled the word correctly. If that doesn't work, pick another word and start over.

5) It is a good idea to work your way down the list for two reasons. First, one of the addresses DEBUG reports is an artifact of the search itself, since it will uncover its own workspace and find the search command you just typed it. Second, its possible that a duplicate copy of the word might be lurking in memory from another file you created earlier. Write down the addresses DEBUG reports. If it prints out a whole long string of them, the first in the list is the most important.

6) Once you have written down the list of addresses that DEBUG reported, you have to figure out which one represents the address of the first occurrence in your file of the word you are seeking. Look at the list and pick the lowest address. Each address comes in two parts. The segment is on the left and the offset is on the right. In our example of 9000:2F3D, 9000 is the segment and 2F3D is the offset. To better understand segment and offset, think of the segment as an area code, and the offset as a local phone number. It's easy to put the segments in order, since 9000 is the highest and 0000 is the lowest. If you wrote down the addresses inside each segment in the order in which DEBUG reported them, the lowest should be at the top.

7) Now that you have identified the lowest address reported by DEBUG, examine the area in memory just before that specified by that address. If the lowest address you found was 4000:D1F6, you would change the rightmost digit (here it is a 6), to a 0. This will put you a few bytes before your actual key word. Finally, type in everything below except the hyphen:

-D 4000:D1F0

The DEBUG D command stands for Dump and will display the contents of the 128 bytes of memory immediately following the hexadecimal address you specified. Again, you would substitute the lowest address you found in your own search for the 4000:D1F0 used above. You should then see a three part display that is comprised of a listing of 1) the hex addresses, 2) hexadecimal numbers representing the actual characters in that memory area (including the word "BUDGE"), and then finally 3) the actual characters in your document.

If you do see something like this, congratulations! The hard part is over. Now you simply have to find the beginning and ending address of your file and copy the information from the memory area between these two addresses to a disk. However, if the right hand column contains a series of periods "." and then the key word "BUDGE", select the next address on your list and keep looking. In this latter case, you simply have found another remnant of a program that used your key word. It might even be from DEBUG's search program.

We now have found the text or a good portion of it in your computer's RAM, and now you have two major steps remaining: 1) find the beginning and ending address of your file, and 2) copy the information from the memory area between these two addresses to a disk.

Follow these instructions carefully:

8) Okay. You have found the key word in your document. We know what memory location that key word is in, 4000:D1F6, pronounced segment 4000 and offset D1F6. Tiptoe backwards in memory a bit just to see where your text actually starts. To do this, you will search the same segment (4000), but you will use a smaller offset (from D1F0 to D100 or D000, for example). You may not have used the word "BUDGET" until the second or third sentence, and the goal here is to recover as much of your file from memory as possible. In our example, we will take 4000:D1F6 and change the rightmost two digits (here it is F6), to 00, then type in everything below except the hyphen:

-D 4000:D100

If the righthand column of the DEBUG display is filled with gibberish, type in just: D

We do this because we probably have looked back too far, and we are in a region of memory just before the start of the file. Keep typing D and pressing repeatedly and DEBUG will work its way upward though memory 128 characters at a time. Stop when you see the very beginning of your text. Look at the eight digit hex address at the left edge of your screen in the same row as the beginning of your text and write it down on your notepad. Now it is time to find the end of your text. Keep hitting D and as long as your text is displayed. When you reach the end, look at the eight digit hex address at the left edge of your screen that's in a row directly after the very last sentence of your text and write down the rightmost four digits on your notepad. You needed all eight digits for the starting address, but only four digits are significant here.

9) Now you know the starting and ending addresses of your file. It may be a little chopped up, and the entire file may not be there, but you can breathe easier knowing you're about to recover everything you just found. But first, you have to do a little hexadecimal math. Fortunately, DEBUG has a built in hex calculator. For the time being, ignore the segment portion of the two addresses you found (they should be the same). Type in the letter H, then the last four digits of the ending address, and finally the last four digits of the starting address, so it looks like:

-H FB70 D1F0
DEBUG will respond with:
CD60 2980
-

The first number is the sum of the two hex numbers you typed in. The second is the difference. You're interested in the second one, because this is equal to the length of the file in RAM. Write down the second number (2980).

10) Now that you know the length of the file, the starting address in memory, and the ending address in memory, you're ready to copy, or "write" the file from memory to a disk. Always be extremely careful in using the DEBUG W (Write) command, since writing files to the wrong place can destroy good data by writing bad data over it. Always copy (write) your file to a new floppy diskette. Not only is this good safety practice, but some of your unsaved document may be written to disk and you might need a program like Norton Utilities to search for the remaining portion of your file. If you were to write to your hard disk under certain older versions of DOS, you might obliterate these files and ruin your chances of recovering them.

Put a blank formatted disk in drive A:. Since you are going to create a file on the disk, you have to give it a name like BUDGET.TXT. Be sure to put the drive letter in front of the name, so it is really A:BUDGET.TXT. To have DEBUG assign this name, type:

-N A:BUDGET.TXT

Next, you have to tell DEBUG how much memory to copy to this file, and where to start. Telling it how much is a two step operation. First type in:

-RBX
DEBUG will respond with:
BX 0000
:

Since this example assumes your entire file was within a single 64 K segment, you want the value in BX to be 0000 as shown. Just press . Then type:

-RCX
DEBUG will respond with:
CX 0000
:

Type in the four digit hex length, 2980, after the colon and press the key. It will look like:

CX 0000
:2980
-

Remember, the 2980 is just for the purpose of this example. You would actually type in the length of the file you were trying to restore.

10) One more step to go and then you're done. At the DEBUG prompt, type in a W followed by the starting address. In this example the starting address was 4000:D1F0. You would type in: W 4000:D1F0

Now exit DEBUG by typing Q and then pressing . Take a look at the file BUDGET.TXT on drive A:. You can use the DOS TYPE command to do this:

TYPE A:BUDGET.TXT

Or you can copy it to your printer with the command:

COPY A:BUDGET.TXT PRN

Don't use any programs to examine the file, since these may overwrite part of memory, and you want to be sure you recovered everything before disturbing what's in memory. If you made a mistake, and the BUDGET.TXT file contains gibberish, you can go back and step through with the instructions again. After what it has been through, the file will probably need some cleaning up. Once you've determined that you rescued as much of it as you can, you can load WordPerfect and retrieve it as a text file to remove extraneous characters, fill in gaps, and move the parts around in their proper positions. You may not recover your tabs, indents, printer codes and such, but you'll be far better off than you were when you first realized what happened. What happens if you had a big file that was stored in more than one memory segment? If you repeatedly typed D in step 7 to find out where your text ends, and you noticed that the rightmost four digits changed from FFF0 to 0000, then your file crossed a segment boundary. If this happened, the easiest thing to do is to extract your file from memory and save it to disk in separate chunks such as A:BUDGET1.TXT, and A:BUDGET2.TXT. You can later call up WordPerfect to combine these individual files into one big file. Use FFFF as the ending address for the first chunk and step through the whole rescue process described above.

While this works well with WordPerfect and should work well with other word processors, it won't do very well with spreadsheets or databases, since these files are often in non- ASCII formats. The rule is back up those files early and often. For Foxpro and dBASE database files, there are utilities such as dSALVAGE by Comtech Publishing which will under special circumstances (such as when you perform an unwanted ZAP on a database) let you recover your database. As with our DEBUG method here, it is important that you don't run other programs before attempting to recover your lost data.

If you didn't recover your entire file, and you walked through the above process a second time to make sure that you didn't miss anything, load a copy of a program like Norton Utilities' FileFind (FILEFIND.EXE or FF.EXE) in version 5.0 or 6.0 and search through the original disk for overflow files. It is a fairly straightforward process where you search the data area of your hard disk for key words that you believe were contained in the missing text. It may take awhile, but it can be worth your time. The program will do all the work once you've given it the proper instructions on what and where to search.