Windows APIs: Microsoft's hidden guide to architecture

Windows APIs: Microsoft's hidden guide to architecture

Summary: Want to know what Microsoft thinks enterprises want? Look at the APIs in each generation of Windows to read the architectural tea leaves


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.

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.

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.

Topics: Microsoft, Software Development, Windows, Web development, Windows 8, Windows Server, Windows 8 in Business

Simon Bisson

About Simon Bisson

Simon Bisson is a freelance technology journalist. He specialises in architecture and enterprise IT. He ran one of the UK's first national ISPs and moved to writing around the time of the collapse of the first dotcom boom. He still writes code.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • WinRT seems to be the future.

    Asynchronous programming is much easier using the new Win RT API. BTW, nice article.
  • Will WinRT Be Abandoned?

    WinRT was the brainchild of Sinofsky, who has been sacked. It was looking to oust Dotnet, but perhaps that plan will be abandoned now, and a commitment to Dotnet reaffirmed. Will Windows Phone 9/RT9 be a complete reboot of Microsoft's mobile platforms? Perhaps redone on a Dotnet foundation, to be more compatible with the traditional desktop. Of course, they'd have to get rid of ARM support and require Intel-only devices.
  • Back to their roots

    They've forgotten that Windows is not really their bread and butter per se. Office, developer mindshare, and "software" is. They need to do what made them great in the first place. Extend their reach. Expand into environments rather than compete with them. MS stuff use to be on every computer, not just PC's (they were everywhere: Commodore, Apple, Atari, etc).

    1) Buy Xamarin, improve on it, and make a big big effort to extend Visual Studio development to Android and iOS environments. Xamarin, while nice, is at best a beta effort and needs a lot of work.
    2) Extend Office to iOS and Android. Google bought QuickOffice... but, um, have you ever used QuickOffice? It's buggy, can't handle complicated documents, texboxes, messes up formatting often, etc. Real Office on iOS and Android would be killer apps.
    • I agree.

      Xamarin is a great idea for an addition to Visual Studio, but it still needs alot of work. As for Office on iOS and Android, I suspect those are already finished and will be included as part of the Gemini update for Office. With the Office 365 subscriptions, it just makes sense. Although I think they would come out with a touch version of Office for Windows RT and 8 first though.
      Jason Joyner
    • MS is not going to go to iOS fast

      They would have to give iApple 30% of the revenue.
    • MS stuff on other computers?

      No intent to be argumentive, but how could MS stuff be on the Commodore, Apple, Atari and other early desktops when they predated MS? Also, the Commodore 128 used the MFM format, while IBM/MS used FAT. Apple has always had their own format. Plus, the early computers had hard-wired OSs, while the early MS products were DOS shells. Windows 3 was written on an Apple, and based on the Mac UI. MS has been following Apple from the earliest days - being careful to mimic, not copy.
      • Microsoft was founded in 1975

        Plenty of time to write software for other platforms.
  • all is good and well

    But the world does not revolve around Microsoft and their strange ideas how protocols and APIs should look like.

    The internet was built with the idea of interoperability and adherence to commonly agreed protocols. No company, much less Microsoft can expect the world to bend to their "technology" desires, because well --- it is just too easy to route around them. The likes of IBM already learned that. Someday, Microsoft will too -- the sooner, the better (for Microsoft).

    This article has too much copy/paste from Microsoft propaganda, by the way.
    • Ho, hum

      Just the type of anti-Microsoft gibberish expected from you.

      The article (if you had read it) was about the history of APIs within Microsoft - nothing more.

      I guess, by your standards, since it didn't say anything bad about Microsoft, it must in praise of them. With you, there's no such as objective observation.
  • So True

    WCF is not necessarily hard it's just different. It is widely used (just check the job boards), however it's for communicating w/disparate systems so your average solo dev is NOT going to use it for their everyday client/server development. WCF is for high performing communication and interoperability between MS and NON- MS systems. Even the Java boys use WCF.

    Next REST is not usurping WCF, you just have added support in Windows Azure API's and in Web API. But this is a good thing because it allows devs to tap into the full potential of the HTTP.

    Finally, all my WCF buffs, of which I'm one, WCF still has a bright future there's too much enterprise architecture built upon it including Microsoft's. I'd just advise one to know both.
    • Even in heterogeneous...

      Even in heterogeneous Windows client/server environments WCF is superior (performancewise) to all other remoting techniques that I'm aware of. It's even (and I was surprised to learn) faster than basic .NET Remoting, which is as pedal-to-the-metal basic as it gets.
  • Put More Accurately... this will explain where MS stands w/REST and WCF.
  • Another excellent post by Simon

    Thanks, surprisingly few people write with such clarity, accuracy these days.
  • From monochrome to N^2-Tier

    Nice article! For my part, as an enterprise developer, WCF is an important and evolving pillar for comms between native applications and services. One of my wishes is for .NET to and Windows to merge to ease the pain of .NET version disparities - .NET updates should be Windows Updates.
  • You forgot COM! - That's a huge ommission

    COM (and DCOM) were the expression of where the world was going in the 90s (think back to the time of ORBs and CORBA). It was the backbone of MTS (which you mention), a kinda-sorta starting point for the design of .NET, and the underpinning of much of WinRT.

    I also strongly disagree with your opinion that "Windows Communications Framework (WCF) [is] a complex and hard-to-implement remnant of what could have been a compelling vision."

    It's complex, but, for the most part, developers can ignore that complexity (you only need to worry about the complexity if you want to take advantage of the system's flexibility). It is, by far, the easiest and most flexible inter-application communication I've ever worked with.

    Yeah, the "M" and "Oslo" work were left behind. But, that was less about Vista and more about a realization that the world was changing and that the Entity Framework and OData made more sense today.
    • Aero was the vision

      the original Aero; WCF is what the team built when Jim Allchin lost faith in Longhorn and needed something in a hurry. M, like WinFS and the Object File System before it, went back into the database world where people will accept it. I didn't think many people understood how, let's say, comprehensive the idea of a universal modelling language really is and couldn't quite believe they could stay the course and ship it...
      • WPF/WCF

        having a pre-coffee moment there, I see. Indigo was what became WCF, Aero became WPF. Both were watered down from their initial vision. I still wish we'd seen all-XAML interfaces.
    • True...

      Yup, I managed to leave out COM and DCOM, though that was more as I tend to think of them as extensions of Win32 rather than Windows APIs in their own right....

      But with regards to WCF as finally delivered, it never matched the original Indigo vision that Don Box et al were trying to build. That way the WS* protocols would have delivered a SOA Windows long before Windows 8...
    • DCOM

      I did build some powerful programs in Win32 platforms, but I haven't used those features of DCOM.
      I don't know anything about DCOM except I always closed those ports opened by DCOM. It is dangerous and can be used by worms. So this DCOM port can only be leveraged by worm writers who can tap unto this port to propagate.

      Hence, after a fresh install I pull my hair and hunt down, scavenge old posts in forums, on how to disable and remove this open port.