Windows is basically a message-driven system. Unlike the programming model we get to play with, where we "receive events" when they occur, each application actually has to make system calls to get messages for the application from the system. These messages are generated by the OS and/or other programs and represent information such as a key changing state from up to down, the mouse moving, the program needs to redraw itself, and a gazillion other things. So crudely put, and surely leaving out lots of detail, the Run() method displays the form passed to it, implements a loop that calls the Windows GetMessage() function and processes the messages in the queue. Messages received will be passed to relevant controls and the controls in turn raise events, providing us with a way of plugging our custom code into this loop. When the application receives a WM_CLOSE message or the form closes, the loop terminates and the Main method returns, terminating the program. This is also why normal Windows Forms apps are terrible for implementing things like games. The GetMessage() function blocks when the message queue for an application is empty, which is very good when the application *is* event-driven and doesn't need to do anything other than in response to some external event - because it let's Windows allocate CPU to other programs that do have something in their message queue. Games however need to keep working and drawing and calculating object movements and so on even if there are no external events. They therefore implement the message loop a little differently, calling the system function PeekMessage() instead, which never blocks but returns immediately even if there are no messages. That's great for games, but it also explains why games are so unfriendly multi-taskers - they always take a lot of resources. A digression if I may: Unfortunately this does make some seemingly simple things a bit tricky to implement in Windows Forms apps. For example, let's say you want to do something *while* a mouse button is pressed, as opposed to in response to the transition from up to down or down to up. You could do this with a timer (which is a WM_TIMER message - the lowest-priority message of all Windows Messages), but it wouldn't be very nice. You might have to start another thread doing the work when the button is pressed and cause it to stop when the button is released, but that's a bit complicated too, because the controls are not thread-safe so this other thread can't update anything in the UI, but instead has to marsh
