Microsoft loosing the API war? Oh well...

(Please excuse the raw format of this post, it will get updated if I find something really awful in the next few days).

As no one really wants or have time to answer (or just pretend), I thought, well, let’s dig into this huge post.

First, please, Joel darling, I love your writing style and your blog, but stop making my life that difficult, and put the full length article separately from your blog!

First and foremost, seeing Linux as a huge threat to windows is premature, I completely agree with that. There’s several points to this I’d like to ask.

When you hear Linux taking hold of the server market, and even when you listen to Microsoft fears about linux eating some of the market share they could gain over Unix, I have a very strong feeling: The figures leading to these worldwide paranoia marketing campaigns rely on very big customers (i.e. people running a lot of servers). The figure in the SOHO market, both in terms of shipped units and deployed units, is still largely in favor of Microsoft, and I’m pretty sure Linux will have to wait for quite a long time at the door before it can enter this market.

For the desktop, Linux has progressed tremendously, no question asked about that. But so did Microsoft Windows. Can you replace a windows in a corporate environment (locked down, no administrative rights, no hardware plugging and unplugging everyday, etc) by a similarly locked down linux? Yes, absolutely, and it won’t make a huge difference for the users. The Java Desktop System from Sun is a good example of what can be achieved.

But now think about the other side of the fence, and the development of applications. (I’ll dig into that a bit later on, to follow Joel’s progression in his article). Do you really think that a CRM call center wants to use a web application? Do you think an administrative wants to complete all his reports and do his charting on a web application? Exactly my point. Ease of development is the main issue with a Linux desktop. Is Java bringing anything to the table for that? Well, java sucks at desktop software (did I get the Slashdot kids angry enough just yet?). To be more to the point (before someone else points to a counter example), Java developers sucks at writing desktop applications. Why? They don’t have the desktop software culture, they have the system application culture.

The whole talk about stability, management, configurability and composability of the windows platform was absolutely valid. But now there are solutions to these problems, and pretty good ones with that. Why can’t all these productions happen anyway? Because they look at the current state of things, and try to imagine what will happen in five or ten years (time taken for OS/2 to die nearly completely). If Microsoft just stopped innovating, it would be valid. But what can compete with Avalon and aero on linux today? Which project has been built to deliver something in the same time-frame as longhorn? (only acceptable links are for projects that are not still at version 0.0001 after four years of rewriting of the X server. If you get me something interesting, I will update this post and its associated logic).

All this to say, if Microsoft is still in the lead, it is because they know to adapt. It is also because they can adapt their strategy to what the consumer needs. Does the consumer need compatibility? Absolutely. Which leads me to my next point (and Joel’s).

Joel says there are two camps at Microsoft, the Raymond Chen Camp that favor compatibility bug for bug, and the MSDN Camp that doesn’t want to guarantee anything that is not documented, pushing an API specification as a moral contract with a developer. Which side am I? Most people responded to that in one way or another. My answer would be, both! Why would the two be incompatible?

For backward compatibility, Joel talks about VB6 and VB.net. I worked with both technologies, and can remember very clearly the first pages on the vb web site where object orientation, full multi threading and the new class library were announced, before the NGWS (that became the .net framework and CLR, and which were previously COM3) were announced by Bill Gates. Did Microsoft say at the time that VB.vNext would be incompatible? Never, and they presented it as an evolution of vb6, not as a break. Did the marketing suck? Absolutely, we led vb6 developers to think vb.next was just the next enhanced version, and not a complete change. I would have to agree with Joel when he says that. Should’ve Microsoft provided a better upgrade path to vb6 users? That’s a question I would tend to respond by the following: do you want to shape your community, be its slave, or be in between? With vb.net we are in the “in between”, a lot of vb weirdness are preserved (late binding anyone?), but a lot of things break as well. I think that in this case, the msdn camp didn’t win. The camp that won was the one thinking you had to move over, and recreate something that was not good enough any more, or would’ve taken significant engineering time to preserve for an overall bad result. Why would’ve it be difficult to support vb6 out of the box? VB was very limited, and you often relied (at least I did in the glory days) on a lot of api calls, libraries wraps, and pure simple hacks to turn the data entry language into proper efficient code. Would have it been possible to port that to .net? I highly doubt that any vb hacked multi-threaded application would’ve supported it (one of the ugliest hack of vb6 was the use of winAPI calls to create threads and execution of methods with the AdressOf keyword).

Where I start disagreeing with Joel completely, absolutely, vehemently (can you spell over reacting ?), is when he decry this, IIS6 and WinFX as not an “evolution” but a “break”. Here, I have to ask… What is broken exactly Joel? IIS5 was broken, IIS6 supports a new mode, and a compatibility mode for IIS5. Did they tighten security? Yes. Did they did that and it broke some application? Yes. Would’ve it been reasonable to provide a compatibility hack so that applications can be a danger to the overall system and work out of the box? I don’t think so.

Is WinFX replacing win32? Frankly, doesn’t seem to me like Win32 replaced win16? COM replaced OLE 1? OLE replaced DDE? They are all evolutions of the others, and each time they appear as a new technology, in addition to the old one. An example? Microsoft is building indigo, and still fixing bugs in DCOM. They are fixing DCOM but they still provide fixes for NetDDE (that no one in their right mind would ever use ever ever again). They’re building indigo, and they’re hooking it up with the COM stack to provide a two-way compatibility. They worked on .net and made sure you could use .net from COM and COM from .net.

Did .net 1.1 break a few things from 1.0? Yes, and that’s why you have a way to do side by side versioning on these libraries. But did win32 break a few behaviors from win16? Yes it did, and no it didn’t matter.

Question to you joel. I made my company buy your software, fogBugz (if you have a Cubiks company in your records, that’s because of me and only me, and next time am in the us I expect a dinner for that!). Anyway. If you want to add a new functionality, like workflow management of a bug, with validation by managers, and integration with the branching of source control software, are you going to implement that in the current fogBugz software? As a consumer of your product, I would love that (nothing to pay for it) but I really don’t expect that to happen. My guess is that you’ll ship that in the next version. Will you break what has been done for previous versions? Nope. But you will make sure to add stuff. That’s where I completely disagree with your analysis. What is important here is that the new apis are added on top of the current apis. They are not replacing the previous api, nor are they breaking the previous api. And that’s, once again, exactly why NetDDE still works even though DCOM have been there for years and Indigo is on the pipeline.

Joel continues by saying that “The old Microsoft, the Microsoft of Raymond Chen, might have implemented things like Avalon, the new graphics system, as a series of DLLs that can run on any version of Windows and which could be bundled with applications that need them.”. There are several reasons why he should know that’s not true. First, Microsoft like any commercial company needs to generate new revenues, upgrades revenues. I really hope for the sake of your company that you’re not going to freeze fogbugz at its current version and offer all the new functionality for free to all of your users. That would be immediate bankruptcy. Second reason is the scale of the change. Microsoft will include http.sys (the http kernel driver used by win2003) in windows^xp SP2 for free. That’s right, this new server side technology, you’ll get it on the desktop for absolutely free, nothing, peanuts. Not a sausage. Indigo will be available on win^XP, win2k3 and Longhorn for free. Nothing. Peanuts. Not even one sausage. Now if you look at aero, you’re talking about a new display infrastructure, a new driver model, a fully new subsystem, completely replacing the previous one, while being completely backward compatible with GDI. If you ship an update to an OS that replaces 100% of its graphics file system, you can’t support windows in the same way as you used to, because it will soon become two different versions of windows.

Joel goes on by argumenting against WinFS as a search technology. I would just follow Robert’s point number (7), WinFS is first and foremost a technology for storing data, that relates to other data, adding meta-data to provide “intelligent” management, not just text search. Text search already works just fine on windows, thanks to the Indexing Server and the IFilter interfaces. Here, we’re talking more of other kind of data, not only text. How can I relate a picture with the people on it, and ask my operating system “show me pictures of my boyfriend from last year”? If you try to text index it, you reach a wall you won’t be able to overcome. WinFS is not there only for text, we already know how to work with text. As you say, it was not hot anymore I wasn’t born yet.

I would agree with Joel saying that memory management and easy of use of Visual Basic have been upgrading developers productivity tremendously. Who wouldn’t?

But then, he says “And yet, people aren't really using .NET much.”. Do you think that’s because of .net itself? Let me tell you a story. I bet my carreer three years ago on .net. That’s right, for the first c# beta, I said, I will be in .net and do only .net from now on. The market has been very hard for the first two years. Where is it now? Companies start seeing .net as something to use because of its productivity enhancements, but especially because it’s old enough and no one stood up and screamed “We were ruined because we chose .net”. It takes time for a new technology to build confidence in the manager paying the check for a new development project. You do sign checks and you still didn’t sign anything for .net, you should know. .net starts seeing a huge progress in the corporate environment, and it’s gradually replacing most of the Java developments (same trend in the financial services industry for that matter).

The point of .net was to provide a common execution environment, and cross language interoperability. The .net framework was mainly written to provide c# and vb.net the same api. Why? Because the vb api was always limited, there was never enough resources to put in there all the things the vb crowd wanted. Microsoft thought that if you could combine a big api, you could reduce development cost while increasing functionality. Yes they did reinvent the wheel. But so did they when they created OLE/COM, or when they created win32 even though they had win16. It’s just the same story over and over again.

Avalon is a new API for graphics. True enough. It is still backward compatible with gdi though. If you write a winforms application now, you’ll be able to write them in the future. If you write them now, they will still run on longhorn. But frankly, can we really push GDI any further? No, and that’s frankly for the best. Once again, I will say, there is absolutely nothing new. GDI+ was implemented on the win2k OS, and never retrofitted back in windows98 and Me. Ctctrl3d.dll or whatever the name of the common 3d controls under windows95 was not ported back to windows 3. And yet, a user interface for windows 3 is still working today. An API doesn’t disappear. The MSDOS subsystem is still in the operating system, protecting your investment. Yes you will have to learn again, a new technology, and that cost money and is frightening. But that’s also what makes this industry moving (like any other one for that matter), and what lets you ship new versions of your software. Your company, Joel, is the best counter example to your argument. You decided not to port to .net for cost reason. And you can still ship your software. And it works. And will in the foreseeable future. Yet you’re alarmed that you’re being let down. Where are the extensions to the vb4 runtime? There was none, it was added to the vb5 runtime. Same thing. Again. And again. And again. Oh, and we still have the sky above us. And I still got a job, and so does your company!

As for Microsoft wanting you to stop upgrading fogBugz, which we bought, even though we knew about Team System, in common with vault, that I made my company buy too… I will leave it to Eric to explain why Microsoft probably doesn’t care much about fogbugz.

When you say that “no developer with a day job has time to keep up with all the new development tools coming out of redmond”, are you suggesting most of my blog roll is actually fake professional people? A lot of people find the time to know in advance what they are going to do. If you want to succeed, you must aim high. If you aim high, you need to be on top. If you need to be on top, you always find the time to know beforehand where your industry, where what makes your day job possible is going. That’s why I have both longhorn and Whidbey installed. And my day job is a real day job. That’s what makes the difference between my salary and the one from my “enterprise developers” pals which are still feeling very sentimentally about vb6 and how cool it was.

And then the discussion slip to supposed “lock in”. There, I don’t understand. How would the win32 api be more open than the winFX api? How would the first one be less of a lock in than the second one? If you write code correctly against .net, you’re actually more open than when writing against win32, as technologies like mono let you run natively on linux, unix, freebsd, solaris, ibm mainframes, macosx… So where is the lock in exactly?

WinFX is only for longhorn, and that may be the lock-in: The fact that something new is only available in the new platform because it’s such a change that backporting it to old platforms would cost the same thing as providing a new version, which present both support and marketing advantages (Are you running Windows FX or WindowsXP? Instead of “Are you running WindowsXP or WindowsXP+Avalon+SP3?). That is not lock in, that is a new api. Each version of windows, historically has introduced new APIs, Windows98 SE introduced new APIs compared to Windows98. Did some software rely on that? Yes. Could they just not use it and keep on doing Windows95 compatible applications? Yes yes and yes. You have choice, and these technologies continue to be supported. If you have a bug in one of the win32 apis, and fill a ticket with Microsoft and have a support contract (like any serious developer team should have), then they will go down there and investigate, and provide you with a solution or a fix for that api. It may even get fixed in the next service pack. Is Win32 getting anywhere? No, no no no no… Not even imaginable. What you may discover though is that, even on Longhorn, the win32 api has been extended. See this post for a short example.

And there, I just don’t get it. Joel switch to an over focusing on web applications. Yes, GMail is sweet. So is Oddpost. I know of a few other web sites which are just cool as well. But nothing, nothing can replace an efficient rich client application. Do you think I would read 500 feeds from a web application? No, I’m using newsgator and outlook. Would I manage the 100 mails I receive a day from a web application? Not in your wildest deams. Would I do development, picture management, video editing and sorting (you know, just normal family divx videos, lots of them), from a web application? No, never ever. The web sucks, it is slow, forces me into waiting in between two pages. The only good thing about the web is the “liveness” of the data and the rich formatting. Guess what, Microsoft is providing Indigo for the first one and Avalon for the second! The web is nice to read web sites, I guess. I’m still not sure the browser paradigm will keep on living on for years though. People are bored of the “click, wait, see white screen, load page, click again”.

Then, I don’t understand anymore. Joel informs us that it’s over, the web have won. My experience might be slightly different, but I see lots of windows applications being written. I don’t see CRM call centers being web based in the near future. There is space for both technologies, one that REACH users whatever their computer or browser is, and one that is RICH and empowers users to work faster and better. Don’t tell me you manage everything from a web site? Why the hell would you have a computer then? Why didn’t web tablets succeed back in the late 90s… Why did Be die?

(ok, I really needed to play drama queen and sound really nervous in there, Joel does say “I love my rich client applications and would go nuts if I had to use web versions of the applications I use daily”, but I can’t really start a big argument if I agree with him , or if he agrees with me, can I?)

Development positions… Yes, low level people are paid more because there are very few of them. Who knows what happens if you marshal a MBR object across appDomains? Not many people. How the remoting sinks work? Not many either. Do those that knows get paid better? Yeap (except for me obviously lol). That’s just a simple matter of a minority of developers interested in how it works rather than what does it let me do. This was true in the COM days. It was even true in the VB6 days.

Do most people refuse to move back from their web development position? I don’t think they refuse. They are waiting for the right technology that will let them have the same level of freedom than they have on the web. That’s why Microsoft says, all in all, that the very rich client is back. It’s cool, easy to use, and so rich that I don’t have to bother with a web site anymore, unless I want to reach. It will take years to do the conversion, but if the technology is cool enough, it will get users moving, which in turn will get devs moving, etc… As always, enterprise applications will be the last to move, in 10 to 15 years!

Could HTML have won? It would have with a richer model than the pull one, if standards for manipulating the dom and its events appeared back when the browser war was hot, and if the w3c didn’t turn into that huge unable to achieve monster that, these days, only shines when standardizing or clarifying what was done by others (shame to say that, considering how much I supported the w3c all these years).

HTML didn’t win. It’s one of the less bad technologies available, but everybody working on it feels frustrated. Microsoft is betting on providing enough candies for you not to get frustrated anymore. And in my opinion, it is going to work. Would I bet my career on it now? No. .net is just the right migration path. Future will tell (and hopefully prove Microsoft and me right).

So, Joel… Where did you invite me for dinner already?