A few weeks ago, Ars published part one in a series called “From Win32 to Cocoa: a Windows user’s conversion to Mac OS X”. In this series, Peter Bright details why he believes “Windows is dying, Windows applications suck, and Microsoft is too blinkered to fix any of it”. Part one dealt with the history of both Windows and the Mac OS, and part two deals with .Net, the different types of programmers, and Windows Vista.In part one, Bright heavily criticised the Win32 API, saying it was filled with legacy stuff and hindered by 15 year old design decisions. In part two he explains that as an answer to the complaints, Microsoft introduced the .Net framework, which was supposed to replace the Win32 API as the API of choice for Windows; in fact, the next release of Windows, Longhorn, would make heavy use of .Net. “It could have provided salvation,” Bright writes.
But it didn’t. According to Bright, .Net was fine technically, with a “sound” virtual machine, “reasonable” performance, and an “adequate” language (C#), but the library – “used for such diverse tasks as writing files, reading data from databases, sending information over a network, parsing XML, or creating a GUI” – the library is “extremely bad”. Bright explains that this is due to the target audience of .Net.
.Net had to roughly appeal to three groups of developers:
At one level, you have people who are basically business analysts; they’re using Access or Excel or VB6 to write data analyzing/number crunching applications. They’ll never write the best code or the best programs in the world; they won’t be elegant or well-structured or pretty to look at. But they’ll work.
At the next level, you have the journeyman developers. Now these people aren’t “business” people – they are proper programmers. But it’s just a job, and they’ll tend to stick with what they know rather than try to do something better. They might be a bit more discerning about their tools than the business types, but they’re not going to go out of their way to pick up new skills and learn new things.
At the final level, you have the conscientious developers. These are people who care about what they’re doing. They might be writing business apps somewhere (although they probably hate it, unless they are on a team of like-minded individuals) but, probably more likely, they’re writing programs in their own time. They want to learn about what’s cool and new; they want to do the right thing on their platforms; they want to learn new techniques and better solutions to existing problems. They might be using unusual development platforms, or they might be using C++, but they’ll be writing good code that’s appropriate to their tools. They’ll heed UI guidelines (and only break them when appropriate); they’ll use new features that the platform has to offer; they’ll push things to the limit. In a good way, of course.
Because .Net had to appeal to all of these groups all at once, .Net had to make various concessions. Before .Net, this was not a problem; the first group had Access and Excel macros, the second group used VB6, and the final group used C++ or whatever other was the cat’s miauw at that point. Win32 catered to this because it was designed for C. C is relatively simple and ubiquitous; “As a consequence of this, pretty much every other programming language created in the last couple of decades can, one way or another, call C APIs.”
Bright explains that .Net doesn’t really do that. .Net can of course still use different languages, but in the end, they all use .Net’s APIs for things like drawing windows on screen, or saving files, or querying databases, or whatever. .Net is trying to be a one-size-fits-all solution, which made it “good enough” for group one and two programmers – but not for the final group.
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.
And this is the main problem with .Net, he states. It’s too “dumbed down”, making it frustrating to use for the type 3 programmers. Win32 shines through everywhere in .Net, making what should be a brand new API into something resembling Win32 much more than a new platform should. Bright gives an example about Windows Forms, how it depends heavily on Win32.
Bright then moves on to Win64, the next big opportunity for Microsoft to clean up the Win32 API. And again – it didn’t. He gives a few examples, such as OpenFile, a Win16 function to open a file (you didn’t see that coming did you?). It was deprecated in Win32, and replaced by CreateFile, so you’d think they would have removed it from Win64. Except – they didn’t. It’s still there, even though no one is supposed to use it.
There are other problems too, such as the name of the system folder. It was called system in 16bit Windows, system32 in 32bit Windows, and, well, system32 in 64bit Windows, because many programmers had hard-coded the system32 directory instead of using the specific API call to determine the correct system directory. Oh, and on 64bit Windows, 32bit files go into a directory named syswow64.
And then Microsoft showed us Longhorn. It was built using .Net, had a consistent look-and-feel, and we’ve all seen the demos of what Longhorn could look like according to Microsoft – it looked stunning. But it got cancelled. “What we got was Windows Vista,” Bright grumbles.
Bright gives a whole list of inconsistencies in Windows Vista and Office 2008, some of which nearly made me cry and curl up in foetal position – I never knew how deep the crisis actually went. Did you know there are now three completely different ribbons? One from Office (not usable for other programmers), another one written in C++ (not for .Net), and a new one for Windows Seven (not for .Net either). Right.
Microsoft has had good opportunities to do something about this, but they have been systematically squandered through a combination of ineptitude, mismanagement, and slavish adherence to backwards compatibility. The disillusionment I feel is incredible. I enjoy writing programs, but I don’t enjoy writing for Windows. And while once it made sense to stick with Windows, it just doesn’t any more. There’s now an attractive alternative: Mac OS X.
Stay tuned for part three.
the author indeed has some valid points , I can’t argue with him , but if he’s really looking for UI consistency and code reusability I’d advise him to look at KDE(4) , the level of code sharing and reusability is astonishing , and the look is consistence across all kde apps – except a few of course-.