A History Lesson on Windows UIs

At the bottom it’s all Win32. This is the Windows API. All input originates here and (nearly) all output eventually gets translated to API calls. Windows is based on message passing, so most applications spend the majority of their time waiting for the next message to arrive. A message could indicate that a key was pressed, mouse clicked at (x,y), or a window gained focus.

// The core of every Windows app:
public int WinMain()
{
    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0))    // blocks until Windows tells us something
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return 0;
}

Handling individual key presses and mouse clicks gets very tedious so Microsoft has introduced many frameworks over the years aimed at simplifying working with user interfaces.

In the early versions of Windows, most applications were written in assembly or C using the raw Windows API. By the time Windows 3 rolled around, serious application development was being done in C++. Microsoft realized the need for a more efficient development environment, so they created MFC to provide a thin wrapper around the Windows API. Most of the methods kept the same name as the original API functions so it quickly became the de facto standard and remained so until quite recently. MFC apps are still C++ apps so programmers have to do their own memory management and exception handling.

In 1992, Microsoft introduced the Visual Basic language to simplify development for new programmers. Visual Basic apps used MFC but provided basic memory management and type safety. However, there were still many problems with development. C++ and VB don’t enforce good programming practices and by shutting off some VB safety options you could make your program run faster, though commonly with less stability.

In response to demands on software developers to become more efficient while writing faster, internet-aware, and secure code, Microsoft introduced the .NET Framework in 2000. As mentioned in my previous post, the .NET Framework greatly simplified interacting with Windows through the BCL and provided a safety net for developers against accessing bad memory addresses. Along with .NET, Microsoft also introduced a new UI library called WinForms. WinForms hid the Windows messaging details behind events like Button.Click and TextBox.TextChanged. They also introduced a similar event-driven framework for web applications that attempted to (albeit poorly) hide the details of HTTP sessions called WebForms.

In 2008, Microsoft introduced a second, more customizable user interface library for .NET called the Windows Presentation Foundation (WPF). WPF did away with dependencies on the Windows API for drawing controls and replaced it with with DirectX based rendering on the graphics card. WPF and it’s browser-based sister, Silverlight, use XAML to define interfaces and comes with a suite of tools to customize the interface. A lot of new development is now done in WPF, although it is still not nearly as mature as MFC.

The introduction of Windows RT for ARM devices like the Surface adds another development environment to this mix. Windows RT will not run WPF apps. It appears that you can compile MFC applications against the ARM dev kit to support Windows RT, however. There is also a new blend of .NET called .NET for Windows Store that will run on Windows 8, Windows RT and Windows Phone 8. .NET for Windows Store is also capable of running applications written using HTML and Javascript.