Developers Tiring of Windows?

I’ve not much cared for Windows Programming for years. I read Charles Petzold’s Programming Windows, 4th Edition years ago, and I was absolutely astounded at the large number of inconsistencies and bizarre API decisions that appear to have been made for the API. Even as a beginning programmer, which I was at the time, I knew that something about the Win32 API was seriously messed up.

For me, my first glimpse of true computing nirvana was the first time I installed Linux. I was a subscriber to the Maximum PC/Boot magazine, which sent out monthly CDs with software. One month, they included Debian 1.2 (Rex) on the CD, which happened to just about coincide with the building of my first Personal Computer, one that I didn’t need to share with the rest of the family. I’d already partitioned my massive 6.2 GiB hard-drive for a secondary OS, and I proceeded to install Debian. This was before apt, when the only option was dselect. And dselect would easily let you force it to do system-breaking things. I installed all the software off the disk, including dozens of conflicting packages that couldn’t operate together. A book on Linux, and a brief stint on Redhat later, I was back on Debian by ‘99, and went Linux full time in 2001 when I reached College.

The birthing pains on Linux were rough, but the idea of a completely free OS was really interesting to me, though I was definitely more interested in the as-in-beer aspect at the time. However, I suddenly found myself at a system with a full development environment and really excellent documentation available. Once I discovered the joy of the GTK+/GNOME GUI, and how superior Widget Packing is to Canvas-Based layout for GUIs, I was forever against the Windows API. I’ve used it, certainly, but I’ve always kept in mind that there is something better.

On Ars Technica, Peter Bright has begun posting a series of articles claiming that Windows is going to fade away, because applications on Windows Suck, largely because developing applications for Windows sucks. His first article, in which he lays out why he feels that Mac OS X is the second coming, and many of the reasons he presents from a developers perspective, I can completely relate to, though I’ve done no programming on Mac OS X yet. Windows simply isn’t fun to develop for. For the majority of developers, for whom programming is simply a job, this really isn’t a problem. However, the people for whom this is a problem, tend to be the people leading the industry, and as better and better alternatives to Windows arise, and market penetration of those alternatives increase (which is slowly, but surely is), then developers will begin to be lulled away.

Mr. Bright’s argument amounts to the fact that a very large portion of the Windows API is still tainted by decisions made inside of Windows 25 years ago, that at the time may have been perfectly reasonable, but today impose bizarre and unnecessary restrictions on the users. Additionally, Microsoft is so concerned with backwards-compatibility, that the system has almost as many workarounds as it does actual rules. Working at an institution with more special-cases than actual rules, I am particularly pained by this method of doing things. It’s a difference in culture though. In the Windows World, a program written for Windows 1.0 has a decent chance of compiling and running on Windows Vista. In the Mac World, a fair number of applications developed for Mac OS X 10.4 required refactoring to make work on Mac OS X 10.5. Apple wants to provide the best API possible, and if doing so breaks an application which depends on broken behavior, then so be it. For Microsoft, this was simply unacceptable.

In my opinion, many Linux libraries have reached a better compromise for this problem. The API should be stable between patch-level releases, and only minor refactoring will possibly be necessary for minor-releases. If the major version changes, odds are a significant amount of the application will need to be reinstalled, but it is easy to have multiple versions of a library available to be linked against. And developers can be as specific or general about which version they’re linking against as they want. Do you require a specific patch-level? Link against that a file matching that patch-level (if you don’t fix your app, which you should). Only require a certain minor release? Just link against that, and all will be well, regardless of how many patches are released for it. I still have a couple of apps on my computer which link against GTK+ 1.2 instead of the 2.x series, and while I can kind of tell that they’re different, they run perfectly fine.

Microsoft’s best chance to correct the mistakes of the past and forge a new way forward was squandered in the .NET Framework. Windows.Forms, in particular, was a huge let down for me, as it’s little more than an incremental update to Windows GUI programming. Yes, I do like .NET in many respects, but the Microsoft APIs are often very frustrating to use. And any .NET bindings outside of the core .NET framework (in other words, most of the Microsoft namespace) is remarkably poorly documented. Want to know how to access the permission model in Sharepoint? Prepare to spend the next several hours digging through painfully inadequate documentation.

Bright [really dislikes .NET[(http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars). I tend to disagree with him about most of his complaints. I think .NET offers a lot, and is quite a step up from the C and C++ APIs. It’s got a fast VM, the specs were open, the API began pretty clean and clear. For the most part, the core API has remained pretty solid, though the Microsoft extension APIs can be pretty weak.I still can’t quite figure out why they didn’t rename the DTS namespace SSIS when they changed the product name.

There is a forthcoming article which should explain what Bright thinks Microsoft needs to do to protect their ecosystem, but I think he may be a bit premature in how dire he behaves like the situation is. Users really fear change, and there are many examples of superior technology failing once turned over to consumers. Pressure on Microsoft is good, though. It will take pressure to force Microsoft to improve, but also a product needs to be good to apply that pressure. The industry is changing, and I’m not sure Microsoft can change with it, though I’m not willing to call them out of the game.