Just a quick one, in Win32, hPrevInstance is always NULL.
Even though its sort of off topic, I want to explain anyway!
Back in 16-bit Windows they had a function called GetInstanceData - you gave it an HINSTANCE and various other things. What it did was copy a buffer from that instance into your current instance.
So your theory kind of applies to 16-bit Windows, but not Win32. If this was not NULL then you could use GetInstanceData to initialize your current instance faster. One example I can think of would be copying a window handle from the previous instance so you could talk to it (say, to load a new document into it).
But now here comes the tricky part - window class registration. So if hPrevInstance was NULL this meant you were the first copy of the program. In 16-bit Windows only this instance registered window classes. Subsequent instances just continued to use the classes already registered. So essentially every 16-bit program that was well behaved would skip over class registration if hPrevInstance was non-NULL.
Enter Win32: When the Win32 guys came to shift WinMain from Win16, they ran into the problem of what to pass for hPrevInstance. Modules and instances doesn't exist in Win32 (HMODULE and HINSTANCE are the same and are just the base address of the module in memory) and unlike Win16, Win32 has separate address spaces. So they just pass NULL, fooling each program into thinking it was the first one. Since the address spaces are separate, there's no issue with re-registering window classes. This still works today
Nowadays, in order to turn your theory into reality most programs hold a mutex object (which has an owner and can only have one owner).
Back on topic - I like this tutorial, seems to explain a lot which is essential, well done
Also, am I seeing this right? The frame doesn't get rendered until you get WM_QUIT? This doesn't make sense to me