I have finally finished reading that code complete book. Before I had been thinking of drawing diagram for every piece of code that I need to build. Now I am thinking that the best way to do everything is to ask a lot of questions at every level. For example, my next program is a back to basics windows program. I have done this dozens of times before so there is no point going over it again. However, while I always got it to work right, I can never get past it to build more complex code. Drawing a diagram or making a plan would not work simply because I have no idea what I am doing. The only way I can fix this properly is to ask a series of simple questions about why each small thing is done. First: What is the point of all this code. This code does three main things. One: It initializes a window object by defining a custom class and then creating it. Two: I runs a message loop to get event messages from the window object. Three: it processes those messages, using them to update the window and close the program. Question: Why does it take so much code to create the window. Windows are very generic objects that are used all over the operating system. They all have to work the same way because they must all work together on the same screen. All these options in the two create functions are there to allow a whole set of customizations that most people will not ever need. You can mostly pick a preference and stick with it. Question: Why do we need the running global variable. The problem with the message loop is that it controls the entire program, but there is not safe way for the loop to know by itself when the program is over. The running variable is set to true before the loop starts, and then set to true when the event procedure receives a message to terminate the entire program. The event loop simply checks each time if running is true, and exits the loop, and the entire program when it is not. Why does the event procedure call a default event procedure. The window objects works entirely by responding to messages. The program can respond to messages that it cares about and modify the window accordingly, it can just ignore the ones it does not need. However there are a large number of messages and some of them will cause the window to not work properly if they are ignored. The default window procedure is there to make sure that everything works properly why allowing a program to just ignore anything it does not need. How can I simplify all this useless code. Creating a window, like most things in coding, can be encapsulated. There are too many details to put it all inside one function, but we can put it inside a class. The parts that are required for the class are the application Instance, and the window procedure. The application Instance is obtained from the first parameter of the win-main procedure, the window procedure is created for each application. Why can't we just encapsulate the window procedure along with everything else. The window procedure is a function that is defined entirely by the operating system, and can only be called by the operating system. There is no simple way to tell it what window class it should be working on. There is a difference between our window class and the window object created by the operating system. While it is possible to make the window object point to our custom class, this is not an elegant solution. On top of all that, the window procedure takes care of things that are unique to each application, so it would not make sense to make a generic one for each class. Is there a point where a generic window procedure would be useful. Yes, there are window classes, like those that require scrolling ability, that need to respond to very specific messages. It would not make sense to have each application know about what those messages are and call the class to deal with them. This is a case where having a class would not make everything simpler.There are some big problems that I will have to solve tin the future if I am going to make this work properly, but this is enough just to get started.