Nothing you can give PeekMessage will make it hang, so without being able to see the code it's probably one of a couple things:
while (PeekMessage(&amp;msg, NULL, 0, 0, PM_REMOVE | PM_QS_PAINT | PM_QS_...))
InputProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);
Still makes the program hang. It never recieves input
1. Like in the first post, invalid flags are being passed to the only / all PeekMessages and the window hangs because no messages are being retrieved at all. You'd also see that if you run the message pump on a different thread to the one that created the window.
2. There's a rogue Sleep / WaitForSingleObject that rarely returns
3. It's working fine except that InputProc isn't calling DefWindowProc for some window or keyboard messages so certain things it does for you (like letting you double click the title bar to move the window or pressing Alt to start the window menu) aren't happening
On a stylistic note, it's not the best idea to call your custom message dispatching function the same thing as the Windows one, especially when they share the same signature. At least, I thought the DispatchMessage in the snippets here was the Windows function before I checked your repo. Or maybe you changed back, and it is!
You don't have to call it, but even if you only explicitly create one window things like COM or plugins (if you allow those) can create other windows that run on the same thread. Without a (Windows) DispatchMessage, any messages picked off the queue intended for them will never make it to their WndProc, unless you do it manually. It also does other stuff like translate unicode messages for non-unicode WndProcs and vice versa. It's not anything you couldn't do yourself though.
Does this not imply that there's no need to call DispatchMessage in a PeekMessage loop?