The real scoop on the the x64 calling convention on 64-bit Windows

Date:May 16, 2006 / year-entry #168
Orig Link:
Comments:    19
Summary:Official (though preliminary) documentation on the x64 calling convention is available on MSDN, for those who want more than my quack overview. (Oops, I meant "quick overview". Little Freudian slip there.)

Official (though preliminary) documentation on the x64 calling convention is available on MSDN, for those who want more than my quack overview. (Oops, I meant "quick overview". Little Freudian slip there.)

Comments (19)
  1. Father Time says:

    This didn’t post until 07:02.  Check the server’s time!!!

  2. PatriotB says:

    Hmm, maybe Raymond manually changed the post time, as it says 7:00 on my screen…

  3. ssss says:

    raymond why the hell did you use


    in CRT’s code??? Now most of exe-packers wont be able to compress VS8 executables, another great idea from MS, to kill its own market.

  4. Adam G says:

    People are still using exe packers? What a terrible thought.

  5. - says:

    People are still using exe packers? What a terrible thought.

    As opposed to worse compression (.ZIP) or installers? Anytime.

    As long as you don’t have to share code, it’s a great idea; with disk I/O being so slow and CPUs so fast, it’s often a speedup. Granted the extracted image will have to be paged back to the swapfile on memory pressure, but it’s usually a speedup. (Relocated DLLs are a much bigger problem with everyone using 0x10000000 as the base address and MS shipping several system DLLs with 0x20000000)

    There are still many applications distributed packed. uTorrent and VirtualDub come to mind.

  6. Dean Harding says:

    How on earth could an exe packer give you better compression than a standalone compressor? You’ve got to at least include the unpacking program uncompressed with your data, so if the algorithm it uses is so great, why wouldn’t you just include the decompressor separately, unpack the exe once and delete the decompressor?

    Once you’ve unpacked the executable, there’s no reason to keep it compressed (and plenty of reasons not to)

  7. Richard McNally says:

    Another quick overview that attmpts to assist in the digestion of those documents is given by Kevin Frei (

    I don’t think that ‘-‘ is suggesting that a packer will achieve better compression than a standalone compressor. What I think he’s suggesting is that you could speed up load time.

    This would be possible because with a seperate compressor you still end up having to load an uncomressed image off the disk to execute it. On the other hand a packed EXE could expand itself directly into memory and execute pass execution to its uncompressed version.

    I’m not sure it would be worth it though, it’d probably mean that you have to do some extra work, either calling GetProcAddress a whole bunch of times or implementing some kind of indirect calling scheme for imported functions.

  8. Mike says:

    Any clues as to why the x64 compiler doesn’t support inline assembler?  I realize you’re not on the compiler team.  This makes it difficult to use for OS dev…  but tell whoever’s responsible thanks for all those useful intrinsics!


  9. Starfish says:

    Regarding EXE packers, what about copy protection systems like Armadillo?

  10. ssss says:

    Adam G. where were you in the past 10 years???

    Get real man, now most of the software (shareware, freeware, even spyware) is packed/protected, even video codecs are protected by exe-protectors and this is common practice.

    And MS with each new OS is trying to make harder and harder to deploy this wonderful software by adding some unnecessary code checks (which can be easily bypassed) while at the same time they’re doing completly stupid things (like a lame DEP patch in WinXP kernel for aspack/starforce/safedisc applications).

  11. josh says:

    Officially, I believe anything using the VC8 runtime MUST use an installer anyway.  Have to add the CRT to the SxS assemblies doodad.

  12. Phaeron says:

    There are compression algorithms specific to binary code that are not always used by general purpose compressors. I believe the Windows 95 compressor attempted to detect and compress relative branches as though they were absolute. And it is not always desirable or even possible to have a separate installer, or to cache the uncompressed copy in persistent storage.

    I was under the impression that the x64 ABI information in the DDK was out of date compared to the SWConventions.doc file in the Bin/win64/x86/AMD64 folder of the Platform SDK. Is this incorrect? SWConventions.doc appears to be newer and has more information. For instance, the DDK says that x87/MMX registers are preserved across context switches; the PSDK clarifies this by saying that they are unusable in kernel mode, but preserved and merely unspecified for user mode. Testing shows that the registers are indeed preserved in user mode. Also, the DDK makes no mention of the requirement for hot-patchable functions (2-byte first instruction + 6 unused bytes prior).

  13. Antonio Vargas says:

    pourpose-made exe packer:

  14. - says:

    Yes, I was implying good EXE packers will defeat ZIP. Why compare against ZIP? Because ZIP is what everybody will be able to decompress.

    EXE packers have entropy reduction filters such as jump converters (as Phaeron said) and have a specialized algorithm specially targeted towards code. See UPX, it beats ZIP every time (even including the decompressor stub, which is tiny).

    Of course there are better compressors, for example both RAR and 7z do have filters for executables, that when combined with their robust general-purpose compression algorithms will give better compression. But you need to either have an application that decompresses them, or make a SFX (self-extractor) (And usually the SFX module is packed too!)

  15. As Raymond mentioned in his post, the MSDN site finally has some decent documentation on the x64 calling…

  16. 8 says:

    I use exe packers to save download time, and save the user the hassle of having to decompress it.

  17. Myria says:

    I ran into the craziness of the CRT security stuff recently.  I couldn’t use the CRT as-is because my code was not a real PE image (it’s VirtualAlloc’d into memory).  When an exception occurred, it didn’t trust my address and threw a security error up.

    The problem I had was that Microsoft doesn’t disclose the source to the whole CRT – the function I needed to modify, __ValidateEH3RN, was not in the CRT source.  So I had to hex edit the .obj file to get my code to work – not fun at all.

    x64 support was much easier.  RtlAddFunctionTable on the copied .pdata section did the trick.


  18. vid says:

    Why are ecx and edx still used? especially ecx which has very special meaning (rep, jcxz). Why couldn’t they use r12-r16 for example? Fastcall was stupid in 16 bit code, and is even more stupid now.

    More here:

  19. Myria says:

    vid, you have to draw the line somewhere.  Every x86 register is special in some way.  edx is an implied target of a 32×32=64 multiply and an implied source of a 64/32=32 divide.

    eax = too many to list

    ebx = xlatb

    ecx = jecxz, rep, shifts

    edx = (i)mul, (i)div, cmpxchg8b

    esp = push, call, SS default

    ebp = enter, leave, SS default

    esi = string ops source

    edi = string ops destination

    ebx is I think the least special of all the registers, but that was long ago defined as nonvolatile.  I’m guessing that it’s a carryover from x86-16, where it was special because you could use it in addressing.


Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index