> If the function retrieves a message other than WM_QUIT, the return value is nonzero.
> If the function retrieves the WM_QUIT message, the return value is zero.
> If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.
I think that many of these inane inconsistencies in Win32 stem from the desire to sneak in "just a bit more features" while officially maintaining full compatibility with Win16.
In the book Showstopper!, which documents the creation of Windows NT (a rather fascinating read), there's a revealing passage about how Microsoft got this Windows backwards compatibility religion. Windows had been intended to be a transitional DOS-based system on the way to OS/2, but then Windows 3.0 became an enormous success almost overnight, and Microsoft decided to break up with IBM over OS/2 development.
NT had been intended to have "multiple personalities" in the form of multiple user-level APIs, with OS/2 as the primary one. The breakup had left them without a 32-bit API. With the success of Windows 3 depending to such a large degree on backwards compatibility with DOS, it made sense that the new API should match the existing Windows API as closely as possible. Besides, there was no time to spend on redesigning anything -- they couldn't afford to let IBM's 32-bit OS/2 to steal the market before NT.
To ensure that the new "Win32" matched the old "Win16" as closely as possible, it's mentioned in the book that any API changes had to be presented for approval by Ballmer himself...! Perhaps the group in charge of the GetMessage() function figured that they could manage just fine with the existing BOOL return type (which is just a typedef for int), rather than risk Ballmer's wrath over the cosmetic API change.
