1) you cannot depend on ANY register state on program entry. The win32
standard doesn't specify any, and even though some registers have had
interesting values on some windows versions, this has changed a lot.

2) if you have an image without relocs that can't be loaded at its preferred
image base, the win32 loader will give an error and wont load the executable.
Not a crash, a loader error.

What can you learn from these two examples? Play clean.
Theoretically I couldn't give a **** about this, but some programmers might
thing that stupid tricks are honky-dory and end up implemeting crap in
commercial programs. And I'm tired of fixing other peoples bugs when I do
not have source code.
Posted on 2002-06-28 21:28:35 by f0dder
/me sends f0dder some valium
Easy there, big fella!
Posted on 2002-06-28 21:56:34 by comrade
Thanks for clearing that up. I wasn't sure if there was a documented entry to win32 programs or not. Finding information on stuff like this is like pulling teeth. For example, what Maverick has said about hInstance not being less than 400000h. I'm not sure where he found this, I tried to find it myself, but you can imagine searching MSDN for hInstance :) However, I figure Maverick knows what he's talking about, ditto for you. So I trust what you guys say, even if it's second hand information.

As for cheap tricks in programming, I think there's a place for them, but not always. As you've pointed out before, GetModuleHandle is reliable whereas other methods are speculation. Furthermore, there isn't any "performance" gain.

However, I think any good windows programmer should recognize that some APIs can be replaced by better programming habits. One example I can think of is GetClientRect. I used to use this function in WM_PAINT processing a lot until I realised I could just save the value from WM_SIZE, and bingo, there's one less API I can use.

But GetModuleHandle isn't really one of those APIs :)

Posted on 2002-06-28 22:11:08 by chorus