Peter Bright has written a multi-page post on Ars Technica explaining the myriad technical failures of Microsoft’s tools strategy that have driven him off the Windows platform and over to OS/X. It’s just been slash-dotted and is getting the predictable level of commentary from the nominally MS-bashing crowd over there.
Ok, let’s leave aside for the moment the simple fact that if Mr. Bright was free to drop Windows and move over to OS/X he’s not working on anything that matters very much. I mean that he doesn’t have a lot of people depending on what he’s doing, otherwise he wouldn’t be so free to make that choice. Whatever. If he’d rather work on a Mac then who the hell am I to comment? But along the way he feels the need to rant a little on the “miserable” Windows development experience on .Net, and that’s where he goes straight off the rails.
Not that he was really on the rails to begin with. Before getting to his laundry list of .Net’s weaknesses Mr. Bright felt the need to categorize the world of software developers according to his own schema. In that world, there are three types of programmers: Excel-wielding macro-cowboy pseudo-coders in business suits; lazy, uninspired cube drones writing clunky, misshapen enterprise applications that nobody really cares about; and those conscientious, intelligent, detail-oriented super coders like himself. Hilariously, he characterizes that last group as the people who might use C++ or “whatever beret-wearing funky scripting language was à la mode at the time.” Like anyone who uses C++ regularly considers a funky scripting language to be real programming (“Look, Bjarne! Anything can be an object!”). Hey, if we push hard enough maybe we can cram the mainly gray-haired, uber-serious C++ programmer community into the same can with all those cool, messy-mopped script-slinging web-onauts. Maybe, but I doubt it.
With the offensive part of the article out of the way he can finally move on to the real weaknesses of Microsoft’s strategy. The first one is: Microsoft did nothing while Apple bought NeXT. According to Mr. Bright in 1996 there was XP and NeXT, and Microsoft hasn’t done a thing since. XP is unchanged since 1996. Oh, wait a sec… Windows XP wasn’t released until 2001, five years after Apple bought NeXT. I’m not making this up. These are his own words…
The purchase of NeXT gave Apple a buzzword-compliant OS with a healthy ecosystem of high-quality third-party applications. Meanwhile, Microsoft was lumbering along with Windows XP.
Of course in the next paragraph he begins with “In 2001, when XP was released, this was not such a big deal.” So I take that back: I obviously have no idea what the hell he’s talking about. Windows XP is over a decade younger than NeXT, and the system we run today is hardly the exact same system released in 2001, but enough about that. Let’s get to some of those real weaknesses.
Because everything now has to live “within” the .NET world, .NET has to be all things to all people. Well actually, that’s not true. It’s trying to be good enough for the first and second kind of programmer. The third type—well, just ignore them. They’re too demanding anyway. They’re the ones who care about their tools and get upset when an API is badly designed. They’re the ones who notice the inconsistencies and omissions and gripe about them.
Well, at least one of them does. Leaving the briefly recurring elitist stereotyping aside, what is he comparing the framework to? Java? Well, I hear that, brother. It’s a good thing Java isn’t dumbed down and palatable to every kind of programmer writing every kind of application on every kind of platform. Ahem.
One practical manifestation of this is that .NET reflects a lot of the bad decisions made in Win32. For example, .NET provides an API named Windows Forms for writing GUIs. Windows Forms is based heavily on the Win32 GUI APIs; the same GUI APIs that owe their design to Win16.
Does WordPress have a WTF quicktag? Windows Forms is heavily based on the Win32 GUI APIs? Well only in the sense that it has to draw stuff… like windows. Somewhere deep inside, on XP anyway, Windows Forms have to get a device context and paint rects. Other than that Windows Forms resembles Win32 the same way I resemble Brad Pitt. And on Vista the WPF doesn’t even use GDI+ to draw anymore. It uses a brand new rendering layer based on Direct3D. What the heck is he talking about? I’m sorry, I’m nearly repeating myself.
To properly write Windows Forms programs, you need to know how Win32 works, because there are concepts from Win32 that make their presence felt in Windows Forms. In Win32, every window is related to a specific thread. There can be multiple windows that belong to a thread, but every window is owned by exactly one thread. Almost every action that updates a window in some way—moving it on-screen, changing some text, animating some graphics, anything like that—has to be performed within the thread that owns the window.
I don’t quibble with the technical content, although it is a little less than earth-shattering news, but does Mr. Bright actually believe the average Windows developer needs to know how GUI thread management is performed in order to get real work done? Are we all champing at the bit to write multi-threaded GUI applications?
This restriction in itself is not entirely uncommon. There are very few truly multithreaded GUI APIs, because it tends to make programs more complicated for no real benefit.
Whew. I thought I was in trouble there for a moment. I certainly agree with the conclusion, but for the record the bulk of the .Net GUI API is thread-safe. Maybe he meant to say there are very few multithreaded GUI APIs other than .Net.
The problem lies in how .NET makes developers handle this restriction. There’s a way to test whether an update to a window needs to be sent to the thread that actually owns the window or not, along with a mechanism for sending the update to the window’s thread. Except this way doesn’t always work.
So it’s a good news/bad news thing. The good news is that almost nobody needs to write multithreaded GUI applications because the additional complexities outweigh the benefits. The bad news is the whole mechanism for testing which thread in your multi-threaded GUI application owns a particular Window is broken. To be honest I’ll have to take his word for it. I avoid multiple threads at the GUI like I avoid booth time at tradeshows. Is that it, then? No it’s not. There’s still the abomination of OpenFile to discuss.
For example, there’s a function called OpenFile. OpenFile was a Win16 function. It opens files, obviously enough. In Win32 it was deprecated—kept in, to allow 16-bit apps to be ported to Win32 more easily, but deprecated all the same. In Win32 it has always been deprecated. The documentation for OpenFile says, “Note: Only use this function with 16-bit versions of Windows. For newer applications, use the CreateFile function.” But in spite of that, Win64 still has OpenFile. No one should be using it, but it’s still there.
It’s there, yes. Do you have to use it? No. Does Mr. Bright have to use it? No. Does Mr. Bright know enough not to use it? Apparently so. Is it documented? Abundantly. Then exactly why is this a problem? Is Microsoft’s track-record on backwards compatibility so poor that we need to question them on it even when the techniques they use don’t impact us at all? I have some stuff written in C++ and assembler fifteen years ago that pokes the VGA hardware directly and it still runs on XP/SP2 today, so I’ll give them the benefit of the doubt on that one.
Is there anything else? Oh yeah, file sizes are still returned as two dwords rather than a quadword. Son of a bitch. I’m out of here. The conclusion?
So Windows is just a disaster to write programs for. It’s miserable. It’s quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it’s all pain. I thought before that Microsoft cared about people like me. But it doesn’t.
Wow. I… um. I don’t know. One sec. I need to step outside and catch a breath. Ok. Let me just say this: I was writing Windows applications fifteen years ago. In fact I like to think I wrote some pretty complicated ones. One of them was a backgammon game that used GDI and sprite-blits and neural networks in 1993 and is still being used in some corners of the Middle East and Europe today. I can tell you that the techniques I used to create the GUI are nothing… and I do mean nothing… like what I use on .Net today (which isn’t Windows Forms, by the way, it’s XAML and WPF). They weren’t even anything like ATL, or MFC. Windows GUI technology hasn’t been standing still. To suggest it has is almost breathlessly ignorant. I don’t mean to give offense here, but Jesus H. Christ, man, what in the name of God is he talking about? Now I am certainly repeating myself.
I admit I had to stop reading the article at this point. I’m not a regular Ars reader, and I don’t really know Mr. Bright’s work. He’s a digerati somebody, and I’m very much a nobody. I might even have sunk down to that clueless second layer of drones he keeps referring to, now that my kids are teenagers and I don’t have as much time as I used to. I’m sure Mr. Bright means well, and truly feels like the Mac is a better platform for him. That’s awesome. I applaud choices. I use Debian and Ubuntu and XP and Vista and in the future I’ll damn well use whatever will put Yuengling in the fridge. I thought MS-bashing had about reached its pinnacle when I started reading praise from certain quarters for Jerry Yang’s big wave-off on $34 a share that he (and his investors) will never see again. But this article sort of restores my faith that the heights have not yet been reached. And that’s all good, since it gives us something to write about.