Top level window receives WM_GETMINMAXINFO before WM_NCCREATE

Keep in mind, that on Windows top level window receives WM_GETMINMAXINFO message prior to WM_NCCREATE. Such behavior can be fatal for application that executes window initialization code in WM_NCCREATE message handler, since when receiving WM_GETMINMAXINFO window is not initialized yet.
Oh, that cruel, stupid world...

Another good reason not to run program by its name in Windows

When searching for executable by its name Windows always looks in:

• Current working directory
• Windows system directory (use GetSystemDirectory() to obtain it)
• Windows directory (use GetWindowsDirectory() to obtain it)
• Directories listed in PATH environment variable

This list (I will refer to it as search directories) can be expanded with more directories when performing specific tasks.
If name does not contains file extension (for example notepad or attrib), Windows will use glob "name.*" to find file with extension that is listed in PATHEXT environment variable.

It's okay if you need just to run notepad or mspaint from command line. But what if you need to execute some program many times? Well, running it by its name is definitely not your choice. I'll try to explain why.

Whether this windows binary is 32- or 64-bit?

The fastest way to answer on this question without using special software tools is:

1. Open windows binary file in any text/hex editor (notepad is enough)
2. Find first occurrence of "PE" string (it will be probably placed at offset 0xD0, 0xF0 or something like that after phrase "This program cannot be run in DOS mode")
3. Skip 2 non-printable symbols (both '\0')
4. Look on the symbol you are at:
   
   • 'L' - i386 binary (x86)
   • 'd' - amd64 binary (x64/x86-64)
   • '\0' (zero) - ia64 binary

p.s. You can use that method for any PE binary (like .exe, .dll and others)