The Future

The Windows 8 architecture  is one of the most advanced operating system (OS)  in the world today. Preserving it’s state of the art Windows NT Kernel and excellent work done from Windows 7, it adds a layer of abstraction for applications that will ensure a fast OS throughout the lifetime of the machine. This module is known as WinRT, Windows Runtime API.

WinRT

Evolution from Win32

WinRT is the direct evolution of the Win32 API. All the Objected Oriented Programming (OOP) advances are shown off in it, especially with the recent acceptance and ratification of the C++ 0x11 standard.  Win32’s creation came from the C-era, where functional programming was still prevalent. Today, WinRT is doing the same with the prevalence of OOP. Moreover, it demonstrates efficient use of lambdas, templates and other programming advances that truly make this module next-gen.

Improvements from .NET

Unlike .NET which has been the major previous effort to bring about inter-operability (interop) between languages and components, WinRT is geared to be in speed parity with native languages such as C/C++ and highly flexible with higher ones such as C# and Javascript. The other improvement from .NET is the integration with the IDE Visual Studio 2012. This high coupling between the module and editor allows developers to focus on creating awesome products without having to deal with the details and maintenance challenges of COM objects that more often than not plagued the .NET platform.

Structure of WinRT (and Win32)

The main reason why WinRT’s architecture is geared towards the future is because of it’s heavy usage and bias towards Asynchronous operations. With tablets, phones and computers having more and more cores/processors, it is ever so necessary to adopt and evangelize this programming shift. Async operations are non-blocking so when your program requests a resource whether that be internet, file or other, it won’t halt while that resource is being retrieved. This will ensure a smooth program execution and more importantly a fluid user experience!

The WinRT module sits right under our languages, abstracting the native and complex “Windows Kernel Services”. The need for this layer allows to free up bandwidth so developers can focus on building applications instead of dealing with the intricacies of the operating system. Nevertheless this mode exists along side the old paradigm for more classical apps that are geared towards productivity and professionals as well as to support all the legacy programs since Windows 95.

 

Asynchronous Operations

The old way of programming on one core processors was to do one operation per cycle and move to the next one. All well and good until a resource external to the program is needed (file, image, sound etc.).

 
//...
    ReadFile();                      // Blocking, program will wait before moving to next line
    DownloadImage();                 // Blocking....
    UpdateScreen();                  // Display will starve causing a bad user experience
    ReadMouseInput();                // This too might block although common current implementations shouldn't (1:n Writer to Readers Paradigm).
//...

 Each function in line 2,3 and 5 is dependent on an external resource that could be reserved for another process/thread which will block our program. The Async paradigm counters such a scenario by having the program not be dependent on these functions in order to continue.

 
//...
    FileReader fileReader = new FileReader( filepath );
    fileReader.onLoading = new Function() { /* Display Loading Bar? */ };
    fileReader.onComplete = new Function() { /* Do Something on complete */ };
    fileReader.onFail = new Function() { /* Handle a failure (display user a message?) */ };
    fileReader.Start();              // This Function is Non-Blocking!    

    DownloadAsset dlAsset = new DownloadAsset( address );
    dlAsset.Start();                 // This Function too is Non-Blocking

    UpdateScreen();                  // Consequently our screen is not starved and we display fresh data to the user!

    ReadMouseInput();
//...

Although the code churn does increase (30% to 50%), the benefits gained justify the effort and then some. Applications won’t halt for whatever reason and near constant fluidity is ensured. Moreoverefficient Processor utilization and they will scale adequately in the future with machines containing more than the typical quad-core chips.

ARM Processor Support

WinRT module comes at a time to leverage support for ARM processors which are at the heart of Tablets and other portable devices. They are the answer to the x86 and amd64 energy hungry processors for desktops. Hence writing an application for Windows not only means the x86 instruction set but also the ARM one. WinRT again abstracts the differences between Windows 8 flavors running on these two different processors and allows the developers to focus on the applications instead of figuring out compatibility divergences between the two worlds.

ARM with it’s “Reduced Instruction Set Computer” (RISC) and x86’s (Intel/AMD) “Complex Instruction Set Computer” (CISC) have different assembly operations mainly due to the fact that the size of of ARM instructions are smaller than the x86’s. This has huge implications on how program’s are compiled. Where an x86 operation would take one line, an ARM equivalent one would take two or three. Although one’s first instinct is to point ARM’s inefficiency out, this is reduced by such things as Processor Pipelining and efficient branching. This is one of many reasons why although ARM performs a tad slower than x86, it is a couple orders of magnitude better on energy consumption and production costs.