Windows APIs: Microsoft's hidden guide to architecture

Whatever your business does to make money, it's also an IT business - in the sense that there are very few businesses that aren't built on IT foundations.

That means the right IT architecture is vital to having a successful business and no, being good at running a mail server isn't a business differentiator any more. This is about what you do with your IT to deliver business value from it.

What does Windows have to do with that? 

The truth is surprisingly simple: the Windows APIs are Microsoft's implementation of what it sees as likely to be the predominant programming model for the next decade or so. They may not be the cutting edge of systems architecture – and they often make it hard to write bleeding edge Windows applications as a result – but what they do is make it easy to build the types of applications enterprises are currently building.

The death of Windows XP: It's your permission to go Chromebook, tablet, Linux, whatever

The death of Windows XP: It's your permission to go Chromebook, tablet, Linux, whatever

• Read more

If we go back in time to the early days of Windows, when it was just a shell on top of DOS, the Windows APIs were purely focused on providing a new way for DOS-style applications to display their results on screen. As PCs evolved, third party tools let you access remote servers, and eventually early internet servers; but they weren't part of the official Windows APIs.

While Windows for Workgroups gave developers some networking capabilities, the real breakthrough came with Windows 95 and Win32. Microsoft was now ready to support the development of client-server applications, and Windows 95 included the tools needed to support their development.

The same APIs evolved into those used by Windows NT, Windows 2000 and Windows XP, all excellent client OSes for client-server application development – and for Visual Basic, the Swiss Army chainsaw of application development.

The arrival of .NET in the early 2000s as a downloadable extra was part of Microsoft’s response to the growing trend for N-tier applications, and the separation of presentation, business logic and data. Earlier attempts had arrived server side (especially with IIS 4.0's Transaction Server), but there hadn't been a consistent developer story that covered both PC and server.

The .NET model became the predominant Microsoft development model for most of the first decade of the 21st century, as it was tightly aligned to Visual Studio and the increasingly popular C# language.

Microsoft tried to take .NET beyond N-tier with the Longhorn platform and the Indigo service-oriented-architecture framework. Building on the embryonic web services model, it promised a component architecture that would let client applications connect securely, and asynchronously, with server APIs that used the SOAP protocols. Microsoft invested heavily in standardising web services, but the collapse of the Longhorn programme and its hasty replacement with Vista left the resulting Windows Communications Framework (WCF) a complex and hard-to-implement remnant of what could have been a compelling vision.

WCF and its tooling remained part of .NET through Vista and into Windows 7, but it was never widely used. Instead of complex XML-based SOAP architectures, application developers chose a simpler approach, based around JavaScript and Representational State Transfer. REST has become the lingua franca for distributed systems, and it's not surprising that it's at the heart of Microsoft's latest set of Windows APIs, WinRT.

Leaving Windows 8's modern design language aside, the underlying WinRT APIs and architecture codify Microsoft's hardware and services vision (as does the latest iteration of .NET). Instead of working with local servers in a typical N-tier application, WinRT is designed to build a new generation of client applications for distributed systems – so that means support for high-latency, asynchronous connections is built in.

Read this

Windows XP: How one company said goodbye to the ageing operating system

• Read more

WinRT is Microsoft finally delivering on the SOA distributed systems vision, using the modern tooling of RESTful architectures. It's about building Windows client applications for cloud services, apps that take advantage of PC smarts to do much more than the browser, while still taking advantage of what the internet brings to cloud-scale development.

That's not surprising, of course, as Microsoft's investment in cloud services and tooling has been immense. If you're building a cloud application on Azure, it's easy to spin up Windows 8 WinRT endpoints as part of the development process – and make them part of the same project in your development environment alongside mobile clients (and if you've plugged Xamarin into Visual Studio, with iOS, MacOS and Android).

Microsoft’s Windows APIs are a complex and powerful tool – with considerable amounts of backward compatibility. You can be building WinRT applications today, while using the same dev tools to maintain Win32 code and to add more features to .NET applications.

Those apps will still run on Windows 8, but if you're thinking about how Windows will support distributed service-centric applications, you're going to be increasingly drawn to WinRT and to the next generation of tools.