Joel on Win32; API complexity and the Army of Muppets (a rant)

Joel has written a nice little piece on the demise of the Win32 API. Some of it I agree with; such as for many developers the fact that .Net is just the latest example of Microsoft indulging in a Fire and Motion exercise, yet for other developers it's vitally important; the trick, as ever, is working out which camp you fall into... But some of it, I don't.

I really don't understand the problem with API complexity (but perhaps that's because I don't really understand the problem with API complexity...). Sure some aspects of the Win32 API are complex and hard to fathom but you only have to work it out once and then you're done. You write some code that makes it easier to use and put that code in a library and use that in future. By doing this you get to understand the problem to a level that's lower than you'd probably choose to, but at least you do understand it.

If you only need part of the API (such as just needing the SChannel aspects of SSPI) then you write wrappers that let you do that easily and ignore the bits (like Kerberos auth) that you don't much care for. If you then need to use another part of that API you can either extend your wrappers or write new, focussed, classes for the new bits you need. If you find that your wrappers are at too high a level for a particular problem you can revisit them, refresh your understanding and then decide at how to craft the abstraction that you need for this version of the problem...

The key point is that you take this hit just the once, generally. From then on you have code that you've adjusted to how your mind deals with that particular problem; you have tests and whatever level of docs you feel comfortable with... If you need to go deeper you can, you don't have someone else's abstraction as the only way to do things...

OK, so the guy's in VB-land or .Net-city don't ever need to do this (except when they do because they need something that the people who wrote their runtime didn't expect them to need and they have to delve into the raw API to achieve it...). Personally, I'd rather be used to doing this stuff, and know that I'm capable of doing it rather than work at someone else's level of abstraction and then suddenly find that they don't cut the mustard and realise that it's hard to get up to speed on the lower level stuff just so that I can work out how to get the last 5% of functionality that I need to finish my app by tomorrow...

It's the same with memory management, it's not that hard, but you do need to think about it. It's nice to work in a language that does that thinking for you but you have to be aware of the times when, perhaps, it's not appropriate or possible; I agree that in 'Enterprise-development-land' those times are less often... The problem is that many "developers" don't seem to think much at all, so they're bound to get tied up with memory management; but, in general I'd prefer for them to remain tied trying to understand pointers rather than allowing them to skip all that and get on with writing really poor business systems ;)

It's not as though you write C++ production code like those MSDN samples and do everything the hard way using bare API calls and have to copy the same 4 or 5 lines time and time again every time you want to access GetFileVersionInfo()... Oh, you do? Well that's your problem then, not the complexity of the API, just that you're failing to add any value with the code that you're writing...

I think this is just a rant now, still, never mind... I'm starting to believe that, at 37, I must now be old and cranky because to be quite honest with you; if you're not writing code in such a way that you define concepts and abstractions in such a way that the actual main line business logic code that you write is clear and easy to understand then you're just not doing it right. You're not adding value. You're making things worse. You are part of the problem. You're building shit on top of shit and nobody will thank you for it. You should give up and go become a landscape gardener or something... Told you I was old and cranky... ;)


Joel is wrong, because he is assuming that DHTML is going to save him, as a developer. Joel is right on some of his observations, such as .net didn't take its toll because not enough people have it. But on the server market, .net is pretty important. And that's where it matters, because java doesn't make sense on the client either. Internally though, .net is an excellent solution from A to Z.

What I see in Joel's comments is that, he has this software fog something which is web based, and he wants to be able to develop it as much as possible without relying too much on Microsoft, but the problem is that DHTML is not the answer. HTML is document centric and designed for Zeldman type of guys who only want to worry about graphic design. DHTML is simply an attempt to make web applications feel like desktop applications and yet they don't feel that way, on top of that using DHTML is the worst way to develop software. It involves javascript, DOM, and browser bugs and limitations. The only reasonable expectation you can have is that, whatever you come up with will run only in IE and Mozilla, and you should forget the rest of the browsers including Safari. Furthermore only you will know the framework you come up with.

This are the main problems, so somebody has to come up with really nice way of using web to develop apps. XUL from Mozilla/Netscape/AOL, Flash from Macromedia, Applets from Sun, .Net from Microsoft and so on doesn't cut it out. .Net is the best but again it is limited, the Flash is promising but it is not open and free enough.

I agree that on the server, and in 'the enterprise' .Net is important but, at present, on the desktop .Net apps are, IMHO, slow and fat. I expect this will get better (in Longhorn? ;) ) and I expect that it's possibly due to developers who aren't completely up to speed with what they can and should do with .Net. I suppose by the time we have a 100% managed MS Office .Net it will all be hunky dory... ;)

Agree re DHTML not being the right choice and the fact that there currently is no right (and easy and safe) choice for what Joel wants to do...

I really think that the demise of the Win32 API is grossly exagerated; but then I guess I've always been one of those people who is firmly in the Raymond Chen camp; I understand the need for the complexity and the fact that what they're doing is hard and the envrioment in which they're doing it is complex...

I think part of the argument is, lots of developers are going to have to do a complete rewrite of code at some point Real Soon Now. If the choice is between "rewrite now for WinForms, rewrite in 2 years for Longhorn, rewrite 2 years after that for Win.Next," and "rewrite now for an HTML interface usable now, in 2006, and in 2008, and be done with it," it's pretty obvious which choice is a capital-letter Win. Assuming, of course, that your interface can be made to work using HTML.

Without subscribing to the usual anti-MS paranoia, improving HTML based guis wouldn't exactly have been in MS's interest. The whole UI initiative with XAML may or may not prove to be another lock-in when the only thing that can render it correctly is an MS OS. It is probably a good thing however as HTML wasn't exactly well thought out in first place - let's not forget it was all thought up for display particle physics results not replacing windows, buttons, lists, interactivity.

If anyone could produce a nice gui using code that is rendered by any application on any OS, there goes the desktop monopoly. Or maybe I'm just cynical. I'm just surprised MS didn't insert a mswin:// protocol into all IE versions and deploy a pre-XAML XAML 5 years ago when they reached 80% browser share.

Whilst the average individual might write the odd document or two, the bulk of Office purchases are by big corporates for large amounts of money, which is where MS's profits mostly come from. These companies are tied to Win2k, or worse NT 4.0, and the migration path is pretty painful from NT4 to Win2k, let alone WinXP and Longhorn. Hence those OSes are going to be around for quite a while, and to quote 'the death of Win32 has been largely exaggerated'.

One thing people forget is that there is multiple things going on in the Win32 API. There are the low-level Culter-esque APIs (ie WaitForMultipleObjects() ), and higher level UI operations (CreateWindow() CreateFont(), etc) that go back to the pre-NT days.

The thought that there wouldn't be a native interface to the OS to me is insane. There are plenty of people that think the Win32 API is too high level.

From a developers point of view I like .NET on the server. It is quick and easy to put together complex programs which interact with C++ code. That is something that could never be said about java.

From a sysadmin point of view, I hate that it pretty much locks me into Windows with out going through contortions to get it to work with Mono...

Leave a comment