Thank you , BC_Programmer,
No I have not down programming is a NT environment. NT was after my days. I did assembly language in the old DOS environment . We just had to know where the segment was. I used to do this like this:
...
push cs
pop dx
...
Well, that is all i can remember, am not sure if it means anything anymore.
yep, good ol' Segment:offset, IIRC; actually, although MS seems to claim otherwise in their literature, Win 9x never had a "protected memory model" you could inspect the memory of any process through ASM in a DEBUG session, I think.
being based on a "protected memory pre-emptive tasking environment" was one of the requirements MS had to meet in order to get into the government market; It's more secure for the same reasons it's more difficult to work with in some scenario's. If you could inspect a command sessions memory for the command buffer you could just as easily inspect "super high profile banking application" for passwords stored directly in variables; or, if the program is designed properly, you'd be able to inspect the memory contents after the user typed in the super ultra secure password and copy it down. Of course they are contrived examples but it prevents spyware from being used against the government too much.
On the other hand, it's still possible to inspect the memory of any process; the trick is to get a piece of code to run within that process, and then communicate (perhaps via named pipes) to the "main" process that collects the information. There are a few methods of injecting code into other processes, but it's rather involved. the "easy" way is to simply write a small DLL that get's loaded via the appInit_DLLs key in the registry; then there will be a DLL loaded into every single EXE process that starts, and that problem is solved; and Interprocess communication can be initiated between any process since that process will have "your" DLL loaded.