Slashdot Mirror
Joel On Microsoft's API Mistakes
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
I have 2 comments:
.NET doesn't go there; the GUI interface is very much tied to Windows.
1. Web clients vs. rich user interfaces
I have long wondered why web interfaces aren't much good. The technologies are there; Java applets, Flash, Python could do it, JavaScript could with a few extensions, XUL, heck, even C, compiled on the fly. All these stop just short of integrating well with the web and the client platform. Why? Why has nobody managed (or tried) to take the last step? Even
2. API changes
Contrary to Microsoft's, UNIX and POSIX APIs have been very stable. There have been extensions, but the bulk of what used to work still works. This makes the case for switching over to standard technologies, now that Microsoft is pushing you to switch anyway.
Please correct me if I got my facts wrong.
No it isn't, it's easy to be a Mac (OS X) user. No Viruses, No Trojans, a sytem that stays up pretty much indefinitely, and great, great applications that do everythinbg I need and much more besides that I probably don't really need, if I'm honest. This old argument about Mac having no apps is very old, very tired, and very tiresome. Please stop.
Honestly, I think breaking API compatibility is the only way for MS to actually fix the problems with Windows. A lot of the problem seems to be the large amount of old code and cruft that has been left in the name of backwards compatibility.
It's certainly a big risk to the Microsoft monopoly, but it's a necessary step for them. Now would be a good time for Linux to make a big move for the desktop.
The reason for the death of the API is probably GNU/Linux. A closed set of poorly documented APIS
doesn't compare to much to "We'll give you the source code"
Microsoft Developer Network has comprehensive documentation about the Microsoft APIs. When I was developing for Windows platform, I never needed any documentation other than MSDN. And if you want source code, you can download the SDKs for free. Though it contains only sample codes, I wonder how many Linux developers looked at the sources of the APIs they use. I have never did such a thing.
MS may have a long way to fall, but they will become increasingly irrelevant like IBM has.
As far as I am concerned, they don't need to go out of business to have fallen. They just need to lose most of the influence and power they have gained through their illegal and unethical business practices.
I used to preach the "web is everything" argument from every soap box I could. I don't think HTTP and HTML will cut it for the types of interactive programs we will see in the future. Heck, in many cases they don't cut it now.
.NET for about 2.5 years now I can go into my office and find any number of contradictory statements about the .NET APIs, statements published my MS! I think this is hurting them quite a bit.
I can see technologies like SOAP enabling rich clients to interop across platforms (ok MS haters, SOAP is a mult-vendor thing so don't reply telling me some tinfoil hat story on how MS will patent SOAP and sue anyone who uses it without license). I am willing to bet some other protocols similar to SOAP, or perhaps riding on top of SOAP, will come along to allow richer communication across networks. HTML just isn't going to do it.
While I totally agree that open standards and open source make the best APIs, MS failed way before even that line. Take SMB for example. Their systems, by design or mistake, don't even follow their own standard! I am betting it is a little of both. Their APIs are this way as well. What is really hurts MS in this particular area is poor documentation and poor implimentation of their own APIs. Having worked with
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
Umm... HTML and HTTP *are* open standards that are backed heavily by Microsoft that give power and flexibility to developers. :)
If you were using something other than HTML and HTTP, you wouldn't be doing Web development; you'd be doing some other kind of development.
Macromedia Flash applications backed by SOAP look very interesting for apps requiring more GUI-like, real-time interaction. This is basically what Java applets were intended for.
Already there are still people using DOS and Windows 3.X and refuse to upgrade. There will be people using 32 bit Windows for a long time as well.
Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release. When that happens, Microsoft will have abandoned the Windows 32 bit platform for Longhorn. Then Linux + WINE will be very valuable for people with new machines who can only run Longhorn or Linux.
My only request is that WINE and other programs than run softare using the Win32 APIs, create a sandbox to prevent viruses and worms from spreading.
The bets are on as to how soon those Longhorn viruses and worms come out after Longhorn is released.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Comprehensive up to a point. In fact, not comprehensive at all. People have sold books, profitting from Microsoft's incomplete documentation. I think the grandparent post is somewhat exagerated in saying that it was Linux that made Microsoft put aside the API. However, in my particular case, it was the incomplete API documentation that made me stop using NT and start programming in Qt in Linux. I tried and tried, and there was no way I could make a data acquisition program I was writing to work well under NT 4. I did exactly what the MSDN documentation said. Then, in desperation, I tried to learn Qt. 20 minutes after starting to read the Qt documentation I had my first non-trivial working Qt program. That was in 1998, and I never wrote a MS-Windows program ever since. I have migrated with little effort my MFC programs to Qt/KDE. I only need three sources of documentation: qt3-assistant, Johnson & Troan's "Linux Application Development", and Rubini's "Linux Device Drivers". Plus the thousands of sites in the web where I can find source code for Linux, of course. A complete documentation is good, but nothing can replace a good set of examples.
You've obviously never worked with win32. We're talking a half-dozen library calls and about the same number of strange handle types & structures to do something simple like get a directory listing & then look at the dates on files. MFC and .NET may be more usable but they still have an underpinning on an API that was designed to be backwards compatable with 16 bit windows and the 16 bit Windows API was an outgrowth of the structure of a large assembly program rather than being designed with any sort of usability in mind.
my sig's at the bottom of the page.
So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it's certainly good enough for developers, who have voted to develop almost every significant new application as a web application.
.NET towards building a open web application, and making that application portable. You start stealing from the edges of Window developers. You start picking away at the hordes. That's how you win, you take Microsoft's strongest weapon away - the masses of developers. Where the devs go, users will follow.
Which means, suddenly, Microsoft's API doesn't matter so much. Web applications don't require Windows.
It's not that Microsoft didn't notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There's no way Microsoft is going to allow DHTML to get any better than it already is: it's just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: "Microsoft is betting the company on the rich client." You'll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that "Avalon, and Longhorn in general, is Microsoft's stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We're investing on the desktop, we think it's a good place to be, and we hope we're going to start a wave of excitement..."
The trouble is: it's too late.
So, when Slashdot goes on and on about how great Mozilla is (and it is good, I'm not saying it isn't - I really like FireFox 0.9) and laments how Microsoft hasn't done a damn thing with IE since 2001, and how you need the Google toolbar and this and that - remember that quote.
Microsoft wants to slow DOWN the rate of advancement in the browser. If you buy that, and buy Joel's premise on that, you now should conclude something VERY VERY IMPORTANT.
Mozilla for Windows may be the SINGLE MOST IMPORTANT OSS project there is. In many ways, it is just as important as developments in Gnome and the linux kernel, disk systems, network protocols, what have you. It's advancements in being able to push rich applications is vital. It's replacement for Active Scripting needs to be secure. Every step it makes pushes another developer that may have gone to use the Windows API or
OK, no offence but it's pretty clear that you've not done a huge amount of programming, at least, not with APIs of any size.
No API of any complexity at all is a "black box" - they are often backed by millions of lines of code, and that code, just like application code, will contain bugs and odd behaviours. The documentation will be incomplete - very few people can spec out a complex API to the degree needed to truly understand it, even when you have documentation coming out of your ears like with MSDN.
Even assuming the API is perfection itself, it'll always be lacking SOME feature you want. Openness of an API is a very important thing indeed.
Anyone else see this list? I scoffed at most of it instantly. Sure, the author apoligizes for a few of them but very poorly and with no explanation.
The author says that some of these can be solved by JavaScipt. No; all of them can be easily solved with Javascript. And if you don't like Javascript, try using ActiveX, DHTML/CSS, Java, Flash, ColdFusion, or any of the other many options out there.
It is true that these solutions take a little more work, but everyone knows that. The author admitted that much.
My question is this: If the author doesn't even say this list is accurate, why did he even put it in the article?
If he must make a point about the web versus Microsoft, make it about the fact that Microsoft refuses to update their web browser even though everyone knows that it was not even standard compliant when it was last released so very long ago. There are much better browsers that are still under constant development including Opera, Panther, and Mozilla to name some excellent examples.
Mufasa http://www.firetiger.net/
Some of your points are valid, but it doesn't matter WHY Microsoft is changing around API's, it's the fact that they are changing at all.
.NET stuff, when you could just code web apps, or apps based on Open Source, and *know* they will work in the future? And the other point is that companies aren't going to jump on the new platforms because they won't be released for several years and won't be mainstream for several years past that, if at all, with competition brewing.
Sure, backwards compatibility with Win32. But not full backwards compatibility, it's more like a subsystem.
The point is, why re-code all your applications for the new longhorn stuff, why re-code all your applications for all the
It's an interesting time, and I won't bet on either side of the coin. We'll just have to wait and see what happens.
ps. Mozilla and Firefox run Slashdot and 99.8% of web sites out there perfectly for me.
- It's not the Macs I hate. It's Digg users. -
You're claiming that MSDN is impossible to read? I've been a programmer working in Windows development for years, using Win32 APIs, MFC, and various other bits and pieces. Say what you like about the interfaces themselves, Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale. Compared to typical *nix man pages or trying to sort out perldoc, it's paradise, and why the top-level poster thought giving the source code was at all equivalent to giving good documentation I have no idea.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
From a cross-platform C/C++ programmer who is probably not as good as Joel, a couple of issues.
.net. It still calls down to the Win32 layer. Why would I not still call the Win32 API directly? Apps still work under 9x and Ntx based systems. I really don't see MS scrapping kernel32 or user32 in the near future.
1) It's not ANSI VB or ANSI Win32. If you settle on a programming environment controlled by one vendor, then they can change the language specifications at will. I wrote my System/UI specific wrapper functions over a decade ago. Why didn't Joel?
2) Joel compares C/C++ memory management to automatic vs manual transmissions. I would associate memory management in C/C++ to doctors who know once they make an incision, they have to close it back up when done. Either you know the procedure (or launguage) or you don't. The article seems to want to apologize for all the Comp Sci grads who don't have a clue when it concerns system level programming (I found one in my office this week).
3) VB is a layer on top of Win32. So is MFC. From the object dumps I've run on MSIL applications, so is
4) The Win32 API is feature rich. Give credit where it is due. The Win32 API evolved from the OS/2 API developed in the late 80's in conjuction with IBM.
5) The reason Raymond Chen had to make the effort to be backwards compatible was that some published API calls were always different than the implementation (say API bug). Remember the DOS bug/feature that allowed TSR's? Remember when DDE turned into netDDE which turned into COM? This brain-dead logic has carried MS through until modern day XP. As an API/Library developer for my companies products, I've had to tell third parties I made a bad design decision (2) and you need to re-compile with the new library/API header. All of them appreciate and understand my mistake. Why can't Microsoft do this?
Great article, just some food for thought from a old time beer drinking hippie programmer. Gotta go, playing network freecraft with my ten year old.
Enjoy,
It's just the normal noises in here.
And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn.
... on their own platform
.NET and some technologies that NEVER took off, I can still use DDE for my IPC needs. And even MS's own apps like IE still do.
.. in fact, one major REASON it's moving to a new set of API's is to avoid the commodity the Win32API is becoming!
So if I'm interpreting accurately, Microsoft just pulled off a successful vaporware strike
The rest of Joel's rant is just way off track. Microsoft has ALWAYS pushed a new incompatible tech, while keeping old ones around. I mean hey even after I got COM, OLE2, COM+,
People predicted MS was going to put itself out of business when it came out with NT, because well hey while you're learning a new API, you might just switch to Solaris (now on x86!) or that exciting OS/2 thing... Microsoft succeeded for two reasons: it kept trying ("third time is the charm" really applies to MS) and its competitors kept screwing up. I don't actually see that changing significantly.
MS is hardly doomed
I've finally had it: until slashdot gets article moderation, I am not coming back.
My exception safety is -fno-exceptions.