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.

What is .NET?

Today I was asked to explain what .NET actually is. Hopefully I won’t show too much ignorance here.

The .NET Framework refers to two things: the Common Language Runtime (CLR) and the Base Class Libraries (BCL). The CLR is a virtual runtime environment for applications which provides basic features such as code security, memory management, and exception handling. It is based on an open specification written by Microsoft called the Common Language Infrastructure (CLI). “.NET” specifically refers to Microsoft’s implementation of the CLI. In theory, anyone can implement the CLI on non-Windows environments. In reality, the only other major implementation is Xamarin’s Mono for Linux/OSX/Android. The BCL is a set of core .NET DLLs from Microsoft.

The CLR provides interoperability between all CLI compatible languages including C#, VB.NET, F#, IronRuby, IronPython, Nemerle, Boo, and many others so code written in one language can natively call code in assemblies compiled from another. The CLR is a just-in-time compiler. .NET code is actually compiled to CIL (Common Intermediate Language, formerly MSIL), a quasi-assembly language. Before each method is called for the first time, the CLR converts it to machine code compatible with the processor it is running on. It also monitors what code paths are frequently executed and optimizes them further. The CLR does runtime boundary checking so it’s guaranteed not to call memory addresses it shouldn’t. It’s not possible to have a buffer overflow in .NET.

The BCL DLLs abstract away interfacing with the Windows API and provides common data structures, file system and network access, user interface elements, LINQ, XML parsing, encryption tools, and tons of other useful features. The BCL is far larger than the standard C++ libraries.

One point of confusion may be the difference between classic Visual Basic and VB.NET. The final version of classic Visual Basic was VB6, which was introduced in 1998 and officially retired in 2008. The first version of VB.NET was introduced in 2002 and is actively developed today. While VB.NET is seen as the next evolution of VB6, it is only similar in syntax. VB.NET eliminated pointers, the variant type, Option Strict/Explicit, and ActiveX dependencies. It introduced formal object-oriented features including inheritance and function overloading. VB6 arrays were 1-indexed while VB.NET arrays are 0-indexed. Directly porting programs between the two languages is not generally feasible. A subset of VB6 lives on today as VBA, a scripting language for Windows and Office.