--- In [email protected], andrew clarke <[EMAIL PROTECTED]> wrote:
<snip>
> Instead, it was used to check whether a particular file existed:
>
> // pseudocode again
>
> result = findfirst("COMMAND.COM")
> if result.returncode != 0:
> print result.filename + " exists"
> else:
> print result.filename + " was not found"
Wow, I've never thought of abusing these functions like that!
Interesting... was this way faster than just open()ing the suspected file?
Oh, probably the problem of running out of file handles; findfirst()
would not use any file handles.
<snip>
> Back in the DOS days a memory leak could have severe
> consequences, particularly if programs were not designed
> to detect them. Although, perhaps these days you could
> still have a serious problem if you wrote a Windows or
> Linux driver that leaked memory if its API was misused
> by an application. Maybe the trick is to have the
> application allocate the memory instead.
This wouldn't help either. When the application terminates, all memory
it allocates will be released by the OS. So what if any buffers
allocated by the application are in use by the driver? No, the driver
has to allocate its own buffers on its own. At least in my opinion. If
someone finds an error in this reasoning, please let me know.
<snip>
> result = findfirst("*.BAT")
> second_result = findfirst("*.EXE")
> result = findnext(result)
Phew, this one is even more fascinating than the original error you've
mentioned above. Why would anyone want to do such crap??? Except in
order to check whether the routines are implemented correctly. Funny...
My final 2 cents: you're right, this is a typical example of a memory
leak. Interesting to see how even MS-DOS showed up such opportunities
for such stupid exploits...
Regards,
Nico
