In my last post, I made some observations about the state of Windows C++ code I’ve encountered recently, having started out in “them days” with 16-bit code, DOS and Windows 3.1. After lamenting the drop in the quality of C++ code in general, I’m coming out and saying it: The Microsoft Windows API I’ve been using for the last eighteen months is pretty good.

I’m serious.

I know I can expect to be kneecapped by my fellow Mac fanbois, but the improvement in the Windows API between the early 1990s and the early 2010s is profound. Stuff does what you need, it’s documented, and it works as documented.

After my rant about the quality of C++, one might think that my expectations aren’t that high, but that’s not true. My high expectations are the reason for the ‘old man’ ranting in the last post. The real question (and a slight mystery to me) is why the Microsoft Windows API should be an exception.

In the early and mid 90s, the Windows API was terrible. This wasn’t entirely Microsoft’s fault… but frankly, a lot of it was. First of all, the documentation sucked. It really did. Every time you had to drop below whatever application framework you were using, and actually work with the OS, you always got a little bit scared, because you never knew whether the docs for the particular functionality you needed to use were present or correct. And even if they were present, and substantially correct, there were always special cases to bite you on the bum over and over again.

By contrast, the higher-level frameworks like Borland’s OWL or VCL and Microsoft’s own MFCs had excellent documentation, and worked pretty well at the application level. They were hiding all the underlying crud, and most of the bugs that app programmers had to deal with were rooted either in compiler issues, or the mind-bending DOS / Windows combination. So, the App frameworks were pretty good, but the Windows API itself wasn’t.

It was inconsistent, stuff broke at random, and you had to build up a massive corpus of arcane knowledge about all of this if you wanted to do anything clever or powerful.

Remember I said that I don’t think it was all Microsoft’s fault?

It’s a hindsight view, but go with me on this. Yes, we all liked a good round of Bill-bashing back then (which seems to have gone out of fashion, now that it turns out he’s actually a pretty nice person), but on (somewhat more) mature reflection it’s pretty clear that Microsoft were tramping through a lot of new territory. They were doing an OS for microcomputers, a class of machine that was basically considered a clever toy by most of the pundits of the age, and Microsoft wanted to be taken seriously. How ridiculous.

The whole idea was a minefield made up of good intentions on top of a teetering tower of instability. Semi-standardised hardware (anyone remember the term “IBM compatible”?) coupled to semi-standardised firmware (different BIOS-es had infuriating differences back in ‘them days’) was hardly a good platform on which to build the computing revolution.

But it happened anyway.

Yes, compromises were made. Many of them had long-term bad effects. The 640K barrier drove us all nuts (and no, Bill Gates never said that 640K should be enough for anyone… well, he certainly denies it now). 16-bit versus 32-bit memory pointers gave us plenty of headaches too, but the thing is that these compromises gave a measure of continuity and stability to an environment that was very, very difficult.

Lots of organisations had made commitments to this system that was changing much more rapidly than anyone had anticipated. Microsoft’s decisions – unpopular as they were – helped real people get stuff done. It was a pragmatic balancing act that amounted to pleasing most of the people most of the time.

Except me, obviously…

… And people like me, who had to code with the stupid thing. Microsoft was the platform we all loved to hate, and we’d look over the fence at the Unix or OS/2 people, and have fantasies about APIs that actually worked. Remember that at this point, BSD was just a hobby some people had, and Linux was a toy for the cool kids – no one hired you to actually work on them, and no one expected them to be documented, or to work.

And the only people who cared about this stuff were us nerds. Everyone else was content to muddle through with DOS and Windows, in exchange for being able take their software and data home from work on floppies, and play their favourite game. That’s what mattered to most people at the time, and although it drove software people nuts, it ended up being good enough.

So how have things changed? Well, for a start, a lot of the underlying platform problems have been resolved. You can’t get anything to market unless it works with everything else, so compatibility is king on _every_ level. So OS people have got an easier job.

Conversely, this has meant that pressure has increased for Microsoft, in terms of competition. Linux isn’t going anywhere any time soon, especially with distros like Android and Ubuntu heading to a device near you, and that mob from Cupertino have been making a bit of ruckus recently, too. This means that the Redmond lot have had to rethink their approach to the market, just to hold on, let alone make progress.

And let’s face it, it’s as if there hasn’t been much since the early 2000s. There was the whole Vista thing (which Windows 7 seems to have fixed). Windows 8 has gone all cool and Metro and touch-y, but that’s barely off the ground at this point. Setting that aside, I think everyone’s been asking Microsoft “what have you done for me lately?”

• “What can I do with my Windows box that I couldn’t do before?”
• “What can I do with my Windows box that I can’t do with a Mac or <insert favourite Linux>?”

And unless you’re a gamer, or have some specific industry need, I don’t think Microsoft’s had much of an answer. Windows 8 may be that answer, but, like I said, it’s too early to tell.

But here’s the thing – under the hood, a lot has happened. It really has. Dot-net has brought some pretty interesting stuff to the table, and with Bill Gates’ famous memo in January 2002, Microsoft “got serious” about security, and have arguably been pretty successful with it.

And really, the Windows API just seems to work these days. This is important to application programmers, because for most of us, the API of the OS is about as hardcore as we get. We tend to be reluctant to get our hands dirty with “below the line” stuff – not because it’s scary (although it is) – but because it tends to reduce the versatility and portability of what we’re doing. When we do dip our toes into the murky waters of the OS, it’s generally to build abstraction layers for the API functionality. Unless I only need to do something really simple with stuff like sockets or threads or shared memory, I either use a good library or build my own.

Now, all this stuff ‘just works’ in Windows. It really does. In the last year, I’ve used the sockets, threads, shared memory, and DLL-loading APIs in Windows 7, in serious contexts, with no intervening wrapper or library (that I didn’t write myself), and in all but ONE function call, I got exactly what I expected from the documentation first time. And the docs are clear, accessible and easy to read. Bang. Done.

This surprised me, not only because of my prejudice from the past, but also because of my expectations around the current standard of code (yes, I’m still harping on that). Microsoft have done a sterling job to provide an interface that gives you what you need, doesn’t break too often, and still gives some measure of backward compatibility. I can only imagine the kind of herculean effort that takes.

“Oh, one more thing” (just to quote someone different)… just as it wasn’t totally Microsoft’s fault that everything was so bad back then, I don’t think they can take all the credit for the good state of their stuff today. For one thing, documentation is way easier to distribute on the Internet, as opposed to shipping a suitcase-load of dead trees, the way we used to do it. I can look stuff up in a flash, and it’s far more likely to be right (for obvious reasons). The same thing goes for code patches – getting them out is a lot easier.

Microsoft didn’t give us the Internet, or the Web. In some ways, it’s arguable that they slowed that progress down. But they sure took advantage of it.

Next post, I’m going to talk about punishing the young folk by making them do C++. That should be fun.