| Date: | May 16, 2006 / year-entry #168 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060516-17/?p=31183 |
| 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)
Comments are closed. |
This didn’t post until 07:02. Check the server’s time!!!
Hmm, maybe Raymond manually changed the post time, as it says 7:00 on my screen…
raymond why the hell did you use
_IsNonwritableInCurrentImage
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.
People are still using exe packers? What a terrible thought.
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)
Another quick overview that attmpts to assist in the digestion of those documents is given by Kevin Frei (http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx)
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.
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!
Mike
Regarding EXE packers, what about copy protection systems like Armadillo?
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).
Officially, I believe anything using the VC8 runtime MUST use an installer anyway. Have to add the CRT to the SxS assemblies doodad.
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).
pourpose-made exe packer: http://www.crinkler.net/
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!)
As Raymond mentioned in his post, the MSDN site finally has some decent documentation on the x64 calling…
I use exe packers to save download time, and save the user the hassle of having to decompress it.
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.
Melissa
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: http://board.flatassembler.net/topic.php?t=4155
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.
Melissa