[roel_v]

"If you think about this system as one in which a window handle is a window object and a message to that window represents a function call, then the WM_CLOSE is a public method that anyone can call. WM_DESTROY, on the other hand, would be a protected method that can only be evoked by the window system."

Yeah well there's the error in your thinking, and exactly what the OP was about: window messages aren't that. Every message is a callback, a 'notification' if you will. If you call RegisterClass() and pass a WNDPROC that does nothing (ignores all messages), it can still be created/destroyed with CreateWindow()/DestroyWindow(), and the 'notifications' it gets (WM_CLOSE and WM_DESTROY) can happily be ignored ('happily' as far as the window manager is concerned).

Win32 is not an OO API, and thinking of it too much in those terms will cause all sorts of confusion. Win32 is a C api, and yes things like MFC put an OO wrapper around it, but at some point the abstraction will start to leak if you take it to the extreme without thinking about the underlying system. Win32 is based around the OS calling back into your code through a well-defined callback function (the WNDPROC), a function with a fixed signature, and taking two arguments that are for all intents and purposes void*'s. The message ('WM_xxx') is a way to tell you how to interpret its arguments, and inform you about changes in the life cycle or state of the window. Everything else (like being able to 'send' messages to HWND's and make them behave in a certain way) comes from there, and much of it is convention - which often works, but when it doesn't, it's not the design's 'fault'.