Why is RtlFillMemory/RtlCopyMemory defined as macro

Question

From definition (winnt.h):

#define RtlCopyMemory(Destination,Source,Length) memcpy((Destination),(Source),(Length))
#define RtlFillMemory(Destination,Length,Fill) memset((Destination),(Fill),(Length))

we see this functions are actually macros, which calls memset/memcpy functions.

Questions is why?

Originaly this functions are exported by kernel32.dll (but only as stub to ntdll.dll), so what is the reason use them as CRT functions?

Maybe relevant that these are considered "unsafe" and are in the process of being deprecated - http://blogs.msdn.com/b/sdl/archive/2009/05/14/please-join-me-in-welcoming-memcpy-to-the-sdl-rogues-gallery.aspx — Roger Rowland, Apr 15 '13 at 07:45
"Historical reasons is not answer." Why not? Do you want us to answer the question? Why are you telling us what is not the answer? — David Heffernan, Apr 15 '13 at 08:32
@Roger Rowland: This is not answer, because dont explain why are defined as macros, also in this article are dont mention RtlZeroMemory, nor RtlFillMemoery. — Xearinox, Apr 15 '13 at 12:24
@David Hefferman: If historical reason is answer, why are not guarded NTDDI_VERSION or _WIN32_WINNT macros? Also how is the purpose export function, which is not used? (Only dynamic linking) — Xearinox, Apr 15 '13 at 12:28
Well historical reasons is clearly the answer. But you won't allow that. Which makes the question hard to answer. So I won't bother. — David Heffernan, Apr 15 '13 at 12:34
@Xearinox - ok, so if *we* don't know the answer, what's *your* idea? — Roger Rowland, Apr 15 '13 at 12:34
No I won't. I don't like questions where you ask, but then tell us not to answer. I've been here before. It always leads to lots of pointless arguments. — David Heffernan, Apr 15 '13 at 12:36
@RogerRowland: I dont know answer, maybe therefore I ask. :) — Xearinox, Apr 15 '13 at 12:36
But you seem to know what's *not* the answer, so where do we go from there? — Roger Rowland, Apr 15 '13 at 12:37
@DavidHeffernan: Well, historical reasons is not the *right* answer. The real reason these are macros is performance -- `memcpy` and `memset` are compiler intrinsics which will emit unrolled register moves for small fixed-size blocks, using a function call only for large or variable-sized blocks. In addition the oft-updated C runtime implementation is likely to be faster, making use of SIMD instructions for wider copies with better cache hinting. — Ben Voigt, Dec 02 '14 at 20:24

score 11 · Accepted Answer · answered Apr 15 '13 at 13:30

11

The Windows api is implemented using layers. There's the well-documented winapi on top, the one that every Windows program should use to make operating system calls. Microsoft can never change it, doing so would break a lot of legacy programs. The one on the bottom is the native operating system api, functions whose name start with Nt or Zw. Undocumented beyond the ones that are required to write a driver. Microsoft changes it regularly with each Windows release, the basic way it can innovate on Windows without breaking too much code. Vista was the last version of Windows with really drastic changes in that bottom layer, the complaints that generated have been well published.

And there's a layer in between, the helper functions that translate from the published api to the undocumented one and back. Its names start with Rtl.

They were also meant to be undocumented, but programmers have reverse-engineered them and ended up taking a dependency on them. Some have been documented by Microsoft because they were generally useful for debugging or filled a gap in the winapi. That's painful for Microsoft, inevitably when the bottom layer changes, those Rtl functions need to change as well. RtlCopyMemory and RtlFillMemory have been particularly abused, lots of VB6 code used it because it didn't have a published function that did the same thing.

Well, that cat is out of the bag. So the declarations you found are an attempt by Microsoft to get programs to use a documented function and stop relying on functions that may need to change. The only reasonable thing it could do to address the problem.

answered Apr 15 '13 at 13:30

Hans Passant

922,412
146
1,693
2,536

Thanky you, for your interest in this problematic. You are right, I see many VB6 code used this functions. :) – Xearinox Apr 15 '13 at 13:33
1

Well done Hans. You waited until we got the "Historical reasons is not answer" prohibition lifted. – David Heffernan Apr 15 '13 at 19:51
There was a prohibition? Glad I didn't know about it, I get half of the answer marks from being an old fart ;) – Hans Passant Apr 15 '13 at 19:54
@Hans Passant: Still I dont understand why in this KB article - http://support.microsoft.com/kb/99456/en-us are used WINAPI replacements for CRT functions(for example memset ----> FillMemory, ZeroMemory), when FillMemory is pointed in macro to memset. I dont ask again, because some people(Roger Rowland) downvoted question, when his comment is totally out(from 2004, but winnt header which I have is around 2000 - VC++). – Xearinox Apr 16 '13 at 10:49
That's prohibited history as well. Going back to the 16-bit version of Windows, back when they had to shoe-horn a GUI operating system and its apps in 640KB of memory. They exposed the internal CRT functions that Windows used to give an app a shot at staying small enough to fit. Made sense at the time, it no longer does. But of course they can't fix it, those 16-bit apps are still being used. – Hans Passant Apr 16 '13 at 11:04
User code took a dependency on `RtlXXXMemory` mostly because the header files aliased public APIs `CopyMemory`, `MoveMemory`, and `FillMemory` to these private functions. And Microsoft [published articles](http://support.microsoft.com/kb/99456/en-us) encouraging developers to use these instead of the standard C functions. So this entire answer is misleading, and the final paragraph is just wrong. – Ben Voigt Dec 02 '14 at 20:36

Why is RtlFillMemory/RtlCopyMemory defined as macro

1 Answers1