Windows 8 -- from a gas engine to hybrid!
As a programmer I like to know how things work under the hood. I am also a decent backyard mechanic, and I look at automobiles the same way. People who work on cars may have spent years learning how a gas engine works, but what happens when they finally have to work on a hybrid? The difference between a gas engine and a hybrid engine are like night and day. I believe we are seeing something similiar with Windows too!
Windows Started Out As Procedural In Nature
It took me years to learn the Windows API (WIN32) and to fully appreciate how things work under the hood. Windows originally was an operating system based on functions and subroutines. These functions (or API) provided features for programmers to use. At its core, Windows uses a very simple architecture based on a messaging system -- when messages (from user input and the system) are sent to a window procedure (a function), where they are parsed out and processed. This appeals to me since I am not a fan of OOP (Object Oriented Programming), and I prefer a more procedural approach to programming. I like things simple.
Microsoft Went OOP!
While popular programming languages like Visual Basic were object-oriented, this was more a feature of the programming language rather than the operating system. Progressively over time, the OS has become more and more object-oriented. Personally I think when .NET became the rage, the procedural nature of Windows receded and OOP began to rule. Yet despite all the OOP of .NET, amazingly the core operating system was still very procedural in nature.
Much of OOP is based on two things: COM (Component Object Model, which itself is based on OLE) and C++ classes. To appreciate what this means, one must appreciate how programming language code is compiled to machine code. In laymens terms, OOP is the epitome of indirection. Rather than calling a function or subroutine in memory, one instead gets a pointer to a pointer to a vtable before any code is even called.
The Windows Registry
In this mix is something else -- the Windows Registry. Components and classes in Windows need to be registered with the operating system. To make it all work, the operating system has to get the Registry involved. Windows XP users have great insight into the Registry. Because Windows XP has been in use for so long a time, users have progressively seen their computers get slower and slower over time. Why? Because the Registry gets bloated (especially if you have installed and removed many apps over the years). Some even may consider the Registry one of Windows' biggest weaknesses.
Windows 8 WinRT Goes Crazy For OOP!
Check out this video from the BUILD developer conference.
I wanted to know how Metro works under the hood and this video, while quite boring at times, is very telling. If you read my previous article about the BUILD Windows Architecture slide, after viewing this video you can see I may need to totally redo my version of the slide. I gave the Win32 API too much credit and now I realize that WinRT is a radical change for Windows. I don't mean Metro and how the user interface appears to users. I mean a radical change in the underlying operating system.
I have two concerns about the WinRT. First its dependence upon COM and C++ classes. As a long-time WIN32 programmer, I can tell you there is a significant difference between the procedural style coding using the Windows API and a COM-based API. The benefits of .NET at times have been clouded by slower and more bloated applications compared to using the pure WIN32 API's directly. Now WinRT is going far beyond even .NET. It pushes COM even to a new level that takes over the operating system (the Metro side).
OOP may have benefits, but it also has some downsides and now the Metro side of Windows has become COM and OOP on steroids. Remember, one of the keys of quality software development is the ability to easily debug one's code. Both COM and OOP add significant layers to code (albeit under the hood) that only adds more overhead, which may need to be debugged as well as the core code itself. Procedural code by its nature tends to be simpler to debug, at least from my own experience anyway.
The second concern is the increased dependency of the operating system (WinRT) on the Windows Registry. Accessing the Registry simply adds more overhead, more opportunities for something to go wrong and extra work for the OS to do things. WinRT pushes dependency upon the Registry to a level that really surprises me. Anyone who has ever had his or her computer's Registry get trashed should know what I mean. When the Registry fails, Windows goes with it.
Keep Things Simple No Longer Applies.
One of the lessons I learned early on, which applies to many things including programming, is to "keep things simple". Many an auto mechanic longs for the days when cars were easier to figure out and fix. In the old days mechanics didn't need a computer.
The Windows was never simple, but compared to the new WinRT the old WIN32 API is very simple. Will the extra complexity of Windows pay off in the end? Microsoft has some very good people who are experts and know what they are doing. Yet a lone programmer like myself does wonder, will all this added complexity improve software or are there dangers lurking in the dark? Only time will tell.
I like Metro, really. I don't think the desktop is obsolete, or should be, and I plan to continue to developing primarily for the desktop. I, like an old-time mechanic, do feel rightly concerned when I hear terms like "legacy" when refering to the desktop. I surely don't like the idea of someday having to learn how to work on a hybrid car, so don't be surprised when I say that the direction Windows is going does give me some concern.
Windows Is Here To Stay, No Matter How It Works.
Just like with cars, we just have to live with changes the future brings. Windows (in some form or another) likely will be around for awhile, and we just have to learn to grow with it. I don't see myself moving to a different platform, such as iPad or Android. I may have to make changes in the development tools I use, in the worst-case scenario (I don't use Microsoft programming languages if you are wondering). Maybe at some point I will have to just "throw in the towel" and leave programming to the younger generation, who will grow up with the new technologies.
The only thing I can ask of Microsoft right now is, please don't let WinRT replace the Windows desktop in the future. I can live with Metro and the desktop working side by side, each doing what it is best suited for. Please, please, don't be thinking the Windows API (WIN32) and the Windows desktop are obsolete or simply a temporary fix for so called legacy applications. If you can only stop for a moment and take a good look at what some of us "legacy" programmers can do with your WIN32 API, you might realize that maybe the desktop still has a purpose and should be a core part of Windows for years to come.
I plan on redoing my version of the BUILD conference slide, since I have learned some very interesting things about how Metro works under the hood.
Links to articles which discuss the other side of OOP:
Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.