So I was given this really cool task.

Apparently, DOS is organized into segments, hence it's known as segmented address OS.

My job was that we were having a problem...the checksum of our program wasn't giving the right numbers. Whats a checksum. Let me backtrack:

So there's this really cool thing called a checksum. It's more of a concept than anything, but it basically is used to determine whether the code you're executing has been tampered with from the code that you originally intended. similar to a CRC check.

There are of course, different ways to do a checksum...but one of the more popular ways is to loop through the code segment (area of DOS mem that stores the program code line by line - machine language ) and add each value of the byte. It eventually then stores this byte. In subsequent runs, it can quickly loop through the loaded code and see if the checksum is the same. Of course for our real world applications, one would have to do this a little differently, possibly resolving the code before counting the bytes because the checksum will rely on the size of the jumps required between instructions.

In any case, the checksum I dealt with was static. But it didnt' match the installed checksum, so my job was to write a program that would clear the memory before our program loaded. We had determined that the cause of the bad checksum was garbage data in the memory which our code counted, but did not overwrite.

I'm beginning to see a problem.

Let me say it again:

I need to write a program that will set the memory to zero so that it does not interfere as garbage data in our program.

What I percieve as the problem is that I can clear the heap and the stack fine, but at some point I'l need to clear the code segment, which means I run the danger of overwriting either some device drivers (bad), command.com (REAL BAD), or my own program (This will crash DOS ). Problem? I think so...

But upon further investigation, I managed to find that the checksum was changing not because of garbage data, but in reality, from TSR's and preloaded DOS commands. Things like PATH=c:\ will take up memory that changes from box to box. So what was apparently happening was that the config.sys and autoexec.bat's were different from the normal boxes and the good boxes.

Now in our program, we need to change and switch these configuration files...so at some point it was being messed up and they were using the wrong config.sys. DOS was loaded into HIGH mem and hence the recorded checksum was assuming DOS=HIGH, whereas subsequent runs of our program will assume it's normal. Hence the checksum error! :)

Now you know!  ¶ 14:45