Fog Creek Software
Discussion Board

API wars and .net

I guess it was all inevitable.

Ok, lets assume that Raymond Chen is in charge, and we still have the good old "Microsoft Systems Journal" instead of "MSDN Magazine".

Windows API is centered around the concept of DLL's, and backward compatibility & DLL hell were getting simply slightly out of hand.

Every few years there is a new minor/major release of windows. Any serious product would require a setup team to sort compatibility problems out.

(Combinations of Internet explorer major+minor version/Java runtime version/OS version/Service pack/Major software packages installed (Office)/
SDK addon combinations and availability (examples like MSI version,MSXML,Uniscribe)/Win32 api changes among versions/Periodically added COM feature).

Been there, done that.

In the end you see the setup team grow, as the number of windows versions/possible installation combination increases. Supporting a serious application would be like writing Win95, no windows team, whatever its size could have buffered away all the possible combinations.

In the end it would very difficult to produce/support a software package - and that would really be
detrimental to Microsoft (Availability of software is the big plus, as Joel has noted).

So i argue that increasing fragmentation of the Windows platform would have inevitably resulted into a 'clean break' attempt.

I guess the rational of the 'clean break' attempt is to create the semblence of code compatibility (logic stuff compiles?) instead of binary compatibility.

Michael Moser
Thursday, June 17, 2004

I have had Joel's prediction tossed in my lap a few years back by an enterprising college student at the university where I worked.  He argued that a scripting language, HTML (and its variants), and a locally run web server (responding on is all you really needed these days to write a bunch of useful applications.

I thought he was full of it, but his laundry list of reasons (similar to Joel's) was quite convincing.

It wasn't until I started using a copy of Radio from Userland (not to argue that this the end all be all) that I got his point.  Radio uses a mini-web server and its own scripting language to handle the heavy lifting of the application.  The UI is almost completely web-based.  Being local, latency issues are addressed, but being a server... interesting features like remote accessiblity without exposing the desktop are also possible.  With web services, you can also push interesting interactions between applications forward quite easily.  Things like homegrown and commercial add-ons like email and chat gateways not only become possible, but are compelling.

Sure, this all can be implemented with a rich client, but then you run into the whole API/DLL mess. 

While not as universal as Java (or C#, if the CLI gets ported everywhere), this method seems, in my mind, to make portability and maintenance easier as well.

Thursday, June 17, 2004

Speaking of Radio, I'm not sure I understand the point of writing a desktop application with a web scripting language, when the same features could most likely be done much more efficiently using compiled languages. CityDesk and Cute Site Builder come to mind :-)

Thursday, June 17, 2004

"I'm not sure I understand the point of writing a desktop application with a web scripting language"

I'm not sure I understand the point of writing an application using complied languages when it would be much more efficient to use a browser and scripting...

Tom H
Thursday, June 17, 2004

Incidently, I can't stand web apps, which is way I don't quite see the point of writing a _desktop_ application like Radio with such tools.

Thursday, June 17, 2004

Oh dear god...could you imagine if every application was written that way?  Just think, you could only ever run *one* app at a time, if everything wanted Port 80 ;-)  Otherwise you'd be running around configuring all your apps to use different ports, and worrying about which ones windows needed, and remote security exploits, and blah blah blah.

Putting any kind of server in the hands of a standard user on a desktop machine is asking for trouble.

Thursday, June 17, 2004

Why would any of them be on port 80? They would use built-in web servers on special ports, just like Radio does.

Brad Wilson (
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home