Re: Re: another fatal bug in NT/2000 "Command Prompt" I/O

["Peter Gründl" <prg () image dk>]

As far as I can tell, it is a matter of CMD/Command not keeping correct tabs
of where the pointer (cursor) is located. You can visualize this if you type
in the original "code" and put a sleep(1) in it. You will notice that the
cursor slowly moves backwards in your command prompt(and incorrectly deletes
text on its way, shame on you Microsoft for coding that). When the cursor
reaches the top of the command buffer (top left of your screen) it should
stop, but apparently they failed the good'ol' if point<=0 :) and it continues
on to a negative value and overwrites whatever is in the memory next to the
memory allocated for the command prompt. The next is purely guesswork, since
I don't have the means of verifying it, I hope someone will correct me if
I am wrong (which I hope I am).
Windows NT has undergone quite a few optimization steps from it's birth to
the Windows 2000 monstrosity we see before us now (no disrespect intended).
One is to put as much into the kernel as possible to improve performance.
I'm wondering if the command memory allocated is in kernel space (next to
it)? The reboot signifies a major problem, such as a kernel failure, so I
wouldn't call it far-fetched. My problem here is, that I tested the overwriting
with a normal user account on my Windows 2000 (yes, I use it myself) and
it worked, meaning the machine rebooted... If it is possible to correctly
overwrite the memory content, would it be possible to get code executed?
If so, it appears a normal user can do it. If it's simply a problem with
a command subroutine that doesn't handle negative pointers, why doesn't it
just cause a dr. watson?

Peter Gründl