Comments by mwb1100 (Top 1 by date)

`RtlZeroMemory()` evaluates to a `memset()` call. The reason you might want something like `RtlZeroMemory()` is that it can help prevent bugs caused by passing the parameters in the wrong order to `memcpy()` (it's easy to swap the last two parameters, and the compiler will not complain). POSIX has/had `bzero()` for similar reasons I think.

Also, early versions of the DDK did not have CRT support, so 'runtime' functionality came from the DDK/NT native API (I'm not really sure how true this might be for RtlZeroMemory()). I think that all Windows SDK `RtlXxx()` functions came from the DDK or NT native API at some point.

The names without `Rtl` in them probably came about because someone thought that the SDK should have names that didn't conflict with the DDK (there was a time when DDK headers and SDK headers could not coexist in the same project - separating these names may have been a result of trying to get the headers to play nice with each other to some extent). Or maybe they just plain didn't like the names with `Rtl` as a prefix (there was a time when the APIs in Windows were probably just whatever someone on the Windows team happened to think was a good idea, without a lot of rules/standards).

The reason for RtlSecureZeroMemory() is that because `memcpy()` is often inlined/intrinsic, the compiler optimizer may determine that the buffer need not be cleared at all. That's fine for 'program' correctness; however, there are times when you want memory that will no longer be used to still be cleared (ie., you don't want remnants of a password floating around on the stack or on the heap).