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

  I'm starting this Blog to keep an account of projects I'm working on, and whatever other interesting things I learn!

Primary Language:
C/C++

Other Vested Interests, In No Particular Order:
Win32, MFC, ATL, OpenGL, Java

/*----- (0.o) -----*/
And to get things started:

When you're getting input from keyboard in C, scanf just doesn't cut it. It's *masked* and too specific in what it can take as input. Sometimes you just want the "any" key...so what to do? kbhit() is an amazingly useful function that requests the keyboard buffer for the next character hit (button hit). The inherent problem lies in that all the buttons will accumulate in the keyboard buffer. So here's a simple way of forcing a clear in the kbbuffer:

// Before your code to ask for the "any" key...
for( ; kbhit(); getch() )
/* Code that asks for "any" key.
Code that checks kbhit() and uses the input.
Use getch() to grab the char */


Thats all! Simple wasn't it?1? And now you know...

Until next time...stay frosty...

and dont' forget: NULL often isn't.  ¶ 10:46