If you have developed Windows applications since the early 1990s, chances are that you have seen and used raw Windows APIs such as RegisterClass, CreateWindow, ShowWindow, GetMessage, TranslateMessage, and DispatchMessage. You certainly had a WinMain entry point in your application. Inside this function, you registered your application with Windows, created and showed the window, and handled messages from the system. Every Windows application has to have a message loop that collects Windows messages and dispatches them to the message-handler function that you’ve registered through RegisterClass function. As the developers, much of your job is handling Windows messages, such as WM_CREATE, WM_SIZE, or WM_CLOSE, that you create and pump into the system with PostMessage or SendMessage.

Classic Windows development is tedious and error-prone. The result is that application frameworks were built as an abstraction on top of all these Windows APIs. Frameworks such as the Microsoft Foundation Class Library (MFC) and Active Template Library (ATL) were created to help Windows application developers focus more on the task of solving business problems than on how to handle certain Windows messages. These frameworks provide the plumbing, or the template, of a Windows application. The developer’s responsibility is to deal with business logic.

While it is much easier to develop Windows applications using these frameworks, it is again sometimes necessary to go down to the Windows API level when the Framework does not give you the controls you need. This situation causes inconsistency in the code. Moreover, there exist numerous frameworks similar to MFC and ATL, such as the Object Windows Library (OWL) from Borland, zApp from Rogue Wave, Windows add-on scripts for Python such as the Win32 Extensions or PythonWin GUI Extensions, Visual Basic, and other homegrown frameworks, causing developers much grief when switching from one to another.

Windows Forms provides a unified programming model for standard Windows application development. It is similar to the native Windows API with regard to level of abstraction; however, it is much richer and more powerful. Instead of depending on functions like the native Windows API, Windows Forms provides a hierarchy of classes. Instead of calling CreateWindow for any type of user-interface widgets, you create the particular type of user-interface control using the appropriate class. You might think that MFC and other frameworks already provide hierarchy of classes. What other benefits can Windows Forms bring that make it stand out from the crowd? The answer is the language-independent aspect of this new framework. Any .NET language can use this collection of classes that make up the Windows Forms object model.

If you’ve developed Windows applications in C++ and Visual Basic, you might think that it would be nice to have the power of C++ to work in an integrated development environment like that of VB. It is now possible with Visual Studio.NET and Windows Forms. Windows Forms brings a VB-like integrated development environment to C#, Managed C++, and other languages.

In current Windows application development, if you use COM, DCOM, or ActiveX components, deployment of your application requires extensive configuration. You would probably at least use the regsvr32 utility to register and unregister components from the Windows Registry on the client machine. All these setup-related deployment tasks are eliminated by Microsoft .NET—by Windows Forms in particular. Now, all you have to do to install an application is copy the executable onto the client machine.

Because Windows Forms is part of the Microsoft .NET grand scheme, it fully supports and integrates with Web Services, ADO.NET, and the .NET classes. You can have Windows Forms as the frontend to your web application by using .NET classes such as HttpWebRequest and HttpWebResponse. These classes allow your Windows Forms application to communicate with web servers. Remember that Windows Forms applications are not always standalone applications.