Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Microsoft Operating Systems Programming Software IT Technology

Joel On Microsoft's API Mistakes 690

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."
This discussion has been archived. No new comments can be posted.

Joel On Microsoft's API Mistakes

Comments Filter:
  • by RAMMS+EIN ( 578166 ) on Wednesday June 16, 2004 @06:37PM (#9446832) Homepage Journal
    I have 2 comments:

    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 .NET doesn't go there; the GUI interface is very much tied to Windows.

    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.
    • by mangu ( 126918 ) on Wednesday June 16, 2004 @06:49PM (#9446927)
      All these stop just short of integrating well with the web and the client platform. Why?

      Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:

      1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

      2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

      3) Privacy and encryption are an add-on, not built in.

      4) No widgets other than those in the browser.

      The solution for all these problems have been to create plug-ins, applets, javascript, flash, etc. Since these aren't part of the standard, they are all different and incompatible among them. There isn't any standard beyond http and html. Or, rather, there are too many standards, one for each vendor...

      • by RAMMS+EIN ( 578166 ) on Wednesday June 16, 2004 @07:01PM (#9447040) Homepage Journal

        Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:

        1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

        2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

        3) Privacy and encryption are an add-on, not built in.

        4) No widgets other than those in the browser.

        Yes, obviously, but then, _how come_ there are no standard protocols that fix this? Many people perceive the need. Users feel the difference between web apps and native apps (Joel is right, for existing apps, users don't care. Now try writing a usable word processor using HTTP and HTML...).

        I once posted a message to some mailing list requesting support for sockets in JavaScript. With that, you could interact with the server _without_ reloading the page, have the server push events to you, rather than periodically poll for them, speak any protocol from a web app, etc. The reply I got was that it wasn't going to happen, citing security issues and bloat. Yeah, that's why Java applets do have socket support, and Java is of course a prime example of elegant, light-weight software. *cough* *cough*

        As for lack of standardization; we have CORBA which is very standardized and very universal. If you want something lighter, there is RPC. ZeroInstall provides a nice way to "run" native software off the web. Java has gotten pretty usable. WHERE ARE THE GOOD WEB HOSTED APPS?!?
        • by Pieroxy ( 222434 ) on Wednesday June 16, 2004 @07:21PM (#9447213) Homepage
          I once posted a message to some mailing list requesting support for sockets in JavaScript

          Security settings should force you to communicate only with your originating server and port. Hence a Socket is way "too free" for that.

          And if the user is using a proxy, then what? How can you access your original server? You have to go through the Proxy.

          No, a real way would be to have access to an object a bit like java.net.HttpURLConnection. Such an object would be trivial to write, with two features in mind:
          1. It should use the browser's connections settings (proxies, etc...) and caching capabilities.
          2. It should enforce that the URLs accessed are issued from the same server/port as the script requesting it.

          Socket is way too low level.
        • by ispeters ( 621097 ) <ispeters.alumni@uwaterloo@ca> on Wednesday June 16, 2004 @09:38PM (#9448162)

          It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation [xulplanet.com], the Mozilla documentation [elemental.com], the Microsoft documentation [microsoft.com] or this tutorial called Using the XML HTTP Request Object [jibbering.com]

          The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)

          The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.

          Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc [sourceforge.net]. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.


    • 1. Web clients vs. rich user interfaces

      Have a look around for screen shots of SAP running via a web interface. While it can be a little clunky in places, when properly implemented it can be every bit as rich as .NET/GTK/Qt based applications. It's doable, but the hardware requirements for the backend can be horrendous if you have a lot of users - in my case a pair of Sun E12Ks with 32 CPUs and a boatload of RAM and HDDs in each.

    • by Dub Kat ( 183404 ) on Wednesday June 16, 2004 @07:28PM (#9447277) Homepage
      Regarding why web clients haven't taken over...because MS doesn't want them to naturally. If web apps had good interfaces (approaching rich clients), and worked in any web browser, there'd be no need for Windows and IE.

      MS has control over rich web interfaces being available because of this: the *vast* majority of browsers are IE [google.com]. So if MS doesn't allow rich web interfaces in IE, web developers won't attempt to make a web app that can't be used by the majority of users.

      I think it's possible to get close to rich web apps using JavaScript, DHTML, and other technologies, but it's very painful for web developers to get it to work correctly across Firefox, IE, Safari, etc. For an example, see oddpost.com webmail [oddpost.com]. It's very rich, but only works in IE 5.5+.

      $60/month Debian Linux Server [aktiom.net]
    • 1. Web clients vs. rich user interfaces
      If you haven't already, take a look at XUL [xulplanet.com]. Mozilla's interface is created with this, and other people are doing some very interesting [infodraft.com] things with it. (second link only works in Mozilla or other Gecko browser)
    • by Spy Hunter ( 317220 ) on Wednesday June 16, 2004 @11:57PM (#9448969) Journal
      This article is great, Joel is a genious, and it's all because of the one paragraph in the article where he answers your question #1.

      Joel has explained the reason Internet Explorer's development hit a wall a year or two ago. All you people asking why Internet Explorer's standards compliance hasn't gotten any better, why it hasn't gotten tabbed browsing, etc, now you have your answer. It's a very good reason (for Microsoft), and it's obvious in retrospect, but I sure didn't think of it until I read these few sentences:

      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.

      Microsoft can't afford to make IE any better, because if was improved one or two generations more, the kinds of web applications that would become possible would make Windows irrelevant as a platform. Everyone would be developing for the web instead of Win32 or .NET or Avalon or whatever. Internet Explorer development has come to a screeching halt except for things which are absolutely necessary to avoid losing its #1 browser position (because for Microsoft the only thing worse than an improved IE is an improved Mozilla!). This is the reason why.

      • by RAMMS+EIN ( 578166 ) on Thursday June 17, 2004 @07:49AM (#9450776) Homepage Journal
        ``Microsoft can't afford to make IE any better, because if was improved one or two generations more, the kinds of web applications that would become possible would make Windows irrelevant as a platform.''

        Some of the replies I have received in this thread show that XUL-capable browsers have already achieved a fearsome ability to present rich user interfaces. This means that MSIE not only lacks the usability features that other browsers provide, but also the base that some developers use for their applications. If Mozilla and web developers push hard enough, they might cause a revolution that forces users to upgrade to better browsers, and MSIE into compliance with XUL, rather than the rest of the world into compliance with Microsoft's XAML.
  • by Anonymous Coward on Wednesday June 16, 2004 @06:41PM (#9446859)
    Remember, people buy computers for the applications that they run, and there's so much more great desktop software available for Windows than Mac that it's very hard to be a Mac user.

    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.
    • by javaxman ( 705658 ) on Wednesday June 16, 2004 @07:35PM (#9447342) Journal
      Joel here also mistakenly buys the argument that Mac users are only 2.3% of the population. Not so. Mac users who bought a machine *this year* are 2.3% or so. But Mac users keep and use their machines for a _lot_ longer- they're actually more like 10% of users.

      It seems [apple.com] there may be a few [apple.com] applications [apple.com] for Mac OS X as well. More importantly, Objective-C and Cocoa are easy enough that more OS X programs are being made every day. Developers indeed. If the Linux community could get some standardizationg together and throw some effort behind GNUStep... sigh... that would be nice, too, but Apple's more likely to release OS X for Intel ( i.e. don't hold your breath ). GNUStep is getting closer, though...

      If it weren't for guys like Joel with their "if it's not Microsoft it's just weird" attitude and willingness to spread MS FUD, users would have a lot more options, and more developers would be able to make a better living slinging more code for more platforms, rather than being forced to eat Microsoft's swill.

    • by stefanb ( 21140 ) * on Thursday June 17, 2004 @07:05AM (#9450601) Homepage
      This old argument about Mac having no apps is very old, very tired, and very tiresome.

      MS Project and Visio. I need those day in, day out, and they're not available. Neither are apps that give me the same functionality. Let alone file format compatibility (yes I know it's MS fault). But the few alternatives I looked at were crashy, had an arcane user interface (neither proper Cocoa nor copied from the originals, just wierd), and simply lacking in functionality. Not that I would think that Project or Visio are the best possible apps in their space; they're just as sucky as most MS apps.

      If you use computers professionally, and you need to work with people outside your own organization, then using a Mac is harder. Many problems are soluble, but there are problems to be solved.

      But I agree with Joel's outlook: many apps will eventually move to the Web, and as Mozilla and WebKit/KHTML improve, all these troubles will disappear. Who knows, maybe Mac OS X Java support might push Java far enough to make it a viable desktop platform...

  • Good idea (Score:5, Insightful)

    by Mnemia ( 218659 ) on Wednesday June 16, 2004 @06:42PM (#9446869)

    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.

    • Re:Good idea (Score:5, Informative)

      by Carnildo ( 712617 ) on Wednesday June 16, 2004 @06:55PM (#9446990) Homepage Journal
      The problem is that Microsoft broke it once for .NET, a second time for Longhorn, and is making no guarentees they won't break it again.

      Apple, on the other hand, only broke the API once, with the transition from Classic to Cocoa (the MacOSX API), and even then, they did their best to maintain compatibility, with Carbon.
    • Re:Good idea (Score:5, Insightful)

      by IrresponsibleUseOfFr ( 779706 ) on Wednesday June 16, 2004 @07:31PM (#9447301) Homepage Journal

      The fact that Microsoft is breaking backwards compatibility is the exact reason that Joel says they lost the API war.

      Developers, more than anything else want a stable platform to develop for. Microsoft's top priority in the past was to provide a stable platform (stable in the sense that all old-code worked on the new platform). Developers are users too. I would be really pissed off if I upgraded some app and it wasn't able to work with my old data. Why is there a different expectation when I code for an API? Why should I have to rewrite my code because the vendor discovered some better way of doing it? I probably went to a lot of trouble to get that code working in the first place. Make sure it performs well, possibly works around a couple bugs that took me hours or days to figure out, and now the vendor comes along and breaks it and I have to learn some new way of doing it and deal with new, yet undiscovered bugs. fsck that. If it was an app, I would ditch it. If it was a platform and had a choice, I'd ditch that too.

      What platform are people turning to? Joel's answer is the web because HTML/browser represents a very stable platform. I won't reiterate his arguments here. But, I do feel that he has a point. He is a smart guy, and I could see it come to pass. That doesn't necessarily mean it will. Smart people have been wrong before :)

      With Joel's world view, how Linux will make inroads on the corporate desktop is simply by having a good web-browser and being free. Features on the client will become irrelevant.

      All I can say is prediction is hard, especially when you are trying to predict the future.

    • Re:Good idea (Score:5, Insightful)

      by Jerf ( 17166 ) on Wednesday June 16, 2004 @08:28PM (#9447710) Journal
      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.

      I agree with this, and I agree with Joel as well.

      Maintaining reverse compatibility is the right thing to do today. It's the right thing to do tommorow. It's the right thing to do next week.

      But it is not free, and the costs grow exponentially with each iteration. Eventually, "exponentially" will beat anyone... even Microsoft.

      They've actually trapped themselves extra badly because each successful iteration ingrained the expectation from their customers that much more that the next iteration too would be backwards compatible. The hole just gets deeper every time.

      I've had this discussion with other developers before, who insisted the users need backwards compatibility. My counterargument was just this, a day will come, sooner than you think, where you won't be able to provide it. Personally, I think we need to level with the users sooner, rather then later: We can't provide it indefinately, so let's at least hold the option open of breaking compatibility. (I'm not saying to break it for no reason, just that you will have to, the logic of modern programming demands it, so be ready.)

      As usual, if you sensibly prepare for it in advance it's easier than if you are suddenly shocked by it.
  • by metatruk ( 315048 ) on Wednesday June 16, 2004 @06:45PM (#9446891)
    Quoth the article:

    Although there is some truth to the fact that Linux is a huge threat to Microsoft, predictions of the Redmond company's demise are, to say the least, premature. Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute. So don't be so quick to write them off.

    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.
  • by craXORjack ( 726120 ) on Wednesday June 16, 2004 @06:45PM (#9446893)
    They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
    But a much more interesting example is when they checked to see if DR DOS was running and flashed a FUD-filled error message to the user. Mmmmm... FUD
    • by Anonymous Coward on Wednesday June 16, 2004 @06:53PM (#9446968)
      Remember, "It's not done till Lotus won't run!"
    • by TheRealSlimShady ( 253441 ) on Wednesday June 16, 2004 @07:50PM (#9447453)
      But a much more interesting example is when they checked to see if DR DOS was running and flashed a FUD-filled error message to the user.

      ...in a beta version of the operating system. It never showed that message in a released version of the OS. While it might have been FUD, it was also true - Windows wasn't supported on DR DOS and Microsoft couldn't guarantee that it would run correctly. (Yeah, yeah, I know that the code was still **in** the released version, not active)

      • by Radical Rad ( 138892 ) on Wednesday June 16, 2004 @08:08PM (#9447575) Homepage
        Nope not just a beta version. It was in at least one OEM version because I saw hundreds (at least, maybe thousands) of machines loaded with it as part of our custom configuration process at the value added reseller where I worked in the early to mid nineties. I was working in Quality Assurance at the time and did not want to allow the machines to be shipped this way but was ordered to by management who said they cleared it with the sales rep for that account.

        Here is a link concerning the situation in case any readers are not familiar: Caldera: MS Cheated in DOS War [wired.com]

    • by xixax ( 44677 ) on Wednesday June 16, 2004 @09:28PM (#9448089)
      They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

      That bit of the article really got me. How many memory allocators do they need to debug or secure? How many exploits might be found by pretending to be SimCity or other applications and getting branched off to languid backwaters of code that don't get much ttention anymore?


  • Kids (Score:3, Insightful)

    by Anonymous Coward on Wednesday June 16, 2004 @06:48PM (#9446911)
    Since Linux is easier to download than Windows, and dev tools are more accessible to kids in Linux than in Windows, my guess is that in coming decades, free and open are going to be the norm, just because it's what people will grow up with (as far as development).
  • I don't agree (Score:5, Interesting)

    by Ayende Rahien ( 309542 ) on Wednesday June 16, 2004 @06:48PM (#9446919)
    Yes, there is a lot of investment in old Win32 code.
    Yes, there isn't such a big incentive *right now* to write code for Avalon / XAML.
    Yes, MSDN Magazine has the *wrong* attidue (notice the ratio of artciles about yet-unavailable technologies to availiable technologies in it recently?)
    As a matter of fact, personally, I didn't bother with them because I've more pressing concerns at the moments.

    But, the thing is:
    By all accounts - Longhorn *will* keep the reknown MS' backward compatability.
    A> There hbeen nothing on the contrary.
    B> MS has a *really* good track record.

    The so-called breaking changes (he mentions .NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute, considerring that they *don't break backward compatability*.

    The change in VB.NET is indeed a breaking change.
    But, it's not the first time that VB update break existing code (as a matter of fact, I think that is normal for VB, although the changes are usually minimal)

    VB.Net is a new language, VB6 has reached its end, you might want to compare it to the transition from C to C++, you've to break compatability (for the furious: byte *buffer = malloc(1024); isn't legal c++)
    And if you're going to break compatability, why not do it in a way that is still largely the same, but gives you *so much more* freedom & flexibility.

    The other choice would've been to exclude VB from .Net, and *that* is not something that MS could afford doing.

    So, in short, Joel is talking about moving away from old technology (Win32) that he descibe as hard to use and error-prone to a better, OO, managed way of doing things.
    While at the same time *retaining* backward compatability.

    I don't get it.
    Sure, a lot fo code is now not the newest & brightest, but you can say the same about COBOL.

    About MS losing the desktop to Web app, that is bull.
    Personally, I can't *stand* using webmail, the latency there is killing me.
    Any sort of web app is usually a mess to write & maintain correctly - especially cross-platform(for example, Firefox 0.9 can't show *Slashdot* properly - I get all sorts of hovering errors when tables over-write one another. Strangely, IE show it perfectly well. And I usually use Firefox, for the reasons Joel mentioned).

    Yes, MS made a big mistake with not updating IE, but I can see their point.
    If they are going to sell Longhorn, it needs to be more than snappy UI & pretty pictures (especially for the business client).
    It has to have *killer app* - IE 7 & WMP 10 are probably on top of the list at MS.
    I'm certain that we will so much improved applications that require Longhorn (DirectX for Longhorn isn't that much of a long call - by the time that it would be out, 2000 would be an old system, and MS can justify not supporting it on Win2K. Games are the #1 killer app, after all.)
    • by cbreaker ( 561297 ) on Wednesday June 16, 2004 @09:02PM (#9447945) Journal
      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.

      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 .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.

      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.

      • by Kiryat Malachi ( 177258 ) on Wednesday June 16, 2004 @10:29PM (#9448482) Journal

        OK, yeah, your shitty little form might be compatible for ever and ever and ever, but anything of any weight is going to break sooner or later because it will rely on Java, or something else,, and eventually that will break backwards compatibility.

        Some fun examples of broken webapps - my company's internal time-tracking program won't run properly under Firefox, but runs fine under IE. It's a Java applet, and they both run the same Java VM, but Firefox never finishes loading it (at least, that's the apparent behavior - I have more important things to do, so I just use IE once a month when I need to take a vacation day).

        Another fun broken webapp was my old University's online coursetools site, which for quite some time wouldn't load properly in Safari because of an ambiguity in how quotation marks were supposed to be handled.

        Web apps will break sooner or later. Open source apps will break sooner or later.
        • by Geoff-with-a-G ( 762688 ) on Thursday June 17, 2004 @12:53PM (#9453679)
          Because WEB APPS AREN'T ANY BETTER.

          I agree with that, and I hate most web apps, but that doesn't matter. All that matters is what most users do, and most users don't mind web apps. Most of the "ordinary users" I know make frequent reference to "checking my webmail often".

          Most of the comments above this one which don't simply say some variation of "I totally agree with Joel" are talking about how awful the old code is, and how much better the new stuff will be. I agree with this, and as a programmer and network engineer I am strongly drawn towards elegant solutions and new technology, but as a rational human being I have to admit the irrelevance of it all.

          One of the most drastically apparent things for me is the difference between Win 98 and Win XP. Having studied both and used each one for more than two years, I can tell you that XP is at least an order of magnitude better than 98. But many of the users I speak to don't even know the difference! I ask which one they're running, and they don't know. I have to explain to them how to check.

          Users don't care about whether your solution is elegant or advanced, all they care about is "can I get my webmail and use Word?" And if the developers want to move towards web apps because they're easier, then the users aren't gonna stop them. If Microsoft maintains backwards compatibility at the expense of good efficient code, users will thank them for it, not switch software vendors.

  • Joel Might Be Wrong (Score:4, Interesting)

    by xp ( 146294 ) on Wednesday June 16, 2004 @06:49PM (#9446923) Homepage Journal
    Joel confuses binary compatibility with API compatibility.

    Microsoft continues to support backward binary compatibility. My DOS applications still run on WinXP.

    Also, Microsoft has always changed its APIs over time to keep up with the state of the art. This is why we have ATL, MFC, and tons of other libraries for the same underlying problems.

    Conclusion: This is nothing new.

    Notes on Stuff [blogspot.com]
    • by kfg ( 145172 )
      Joel confuses binary compatibility with API compatibility.

      Anybody who has tried to explain to someone why WINE is not an emulator has probably had to confront this confusion face to face.

      I recently got lectured that WINE would always have emulation overhead by a guy who was sitting there writting Win32 binaries . . . on his Linux box.

      He still didn't get it when I asked him if he weren't concered about the emulation overhead when he ran those Linux binaries under Windows.

      Some people have troubles with t
  • Visual C++ now free (Score:5, Informative)

    by aking137 ( 266199 ) on Wednesday June 16, 2004 @06:49PM (#9446924)
    Wow - I never knew before reading this article that Microsoft's Visual C++ Compiler is now free [microsoft.com]. (Free as in 'beer' of course.)
  • by Omega1045 ( 584264 ) on Wednesday June 16, 2004 @06:53PM (#9446962)
    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.

    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 .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.
  • by jwcorder ( 776512 ) on Wednesday June 16, 2004 @06:53PM (#9446965)
    "The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

    And people say the evil giant doesn't try to fix it's software. They fixed SimCity DAMN IT!

  • by MMHere ( 145618 ) on Wednesday June 16, 2004 @07:00PM (#9447029)
    I'll believe it when I see it -- that is when MS's 90%+ monopoly market share declines and there are true other players.

    Until then, MS can mess up all they want (or all you say they do), and still win in the market place. As long as everything runs Windows, everything else has to be compatible with a constantly moving target.

    Moving the the target is also how MS keeps their deathgrip on the share percentages. It's part of their "competitive advantages" (read, "platform lockin").
  • by cjmnews ( 672731 ) <cjmnews@yahoo.com> on Wednesday June 16, 2004 @07:00PM (#9447030) Homepage
    I think that Joel is wrong here.

    I believe that the long wait for Longhorn/Avalon to be released will cause more people to pick up .NET as an alternative to the old API development.

    Developers will see the benefits of the .NET infrastructure (memory management, standardized interfaces, develop in the language of your choice, etc.) over the standard VB/VC++/ASP and begin to use .NET more. They will take classes, and become trained in .NET.

    When Longhorn/Avalon finally gets released, the adoption I expect will be slow. We just spent all this money becoming proficient with .NET. Why change to the new system now? Unless you need the new features, .NET should cover most needs of application and web developers.

    I just can't see how .NET will go away so soon after it's introduction.
  • What about flash. (Score:3, Interesting)

    by metalhed77 ( 250273 ) <andrewvc@@@gmail...com> on Wednesday June 16, 2004 @07:02PM (#9447043) Homepage
    Many of the problems with web UIs he describes can be solved by using flash. I'm actually considering using it for a web based since flash + actionscript being driven off server generated XML is convincingly better than XHTML + XSLT (transformed on the server).
  • by cmacb ( 547347 ) on Wednesday June 16, 2004 @07:05PM (#9447074) Homepage Journal
    From the article:

    "... they could reinvent themselves as a shaved-ice company at the last minute. "
  • by Orion Blastar ( 457579 ) <orionblastar&gmail,com> on Wednesday June 16, 2004 @07:06PM (#9447093) Homepage Journal
    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.
    • by Chester K ( 145560 ) on Thursday June 17, 2004 @01:26AM (#9449321) Homepage
      Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release.

      The problem is WINE is not "undocumented Win32 API calls". CrossOver Office can run MS Office just fine, and if there's any Windows application that would be using "undocumented Win32 API calls", it'd be Office. The fact is that there aren't any useful undocumented API functions. What's not documented is undocumented for a reason and is not used, even by Microsoft apps.

      The problem with WINE is that the Win32 API is so mind-bogglingly huge because it covers just about everything you'd ever want to use an OS to do, that the WINE developers haven't been able to implement the whole thing. They go for the "most bang for the buck" APIs.
  • by jwcorder ( 776512 ) on Wednesday June 16, 2004 @07:16PM (#9447167)
    "The company I started, Fog Creek Software, makes a terrific product called FogBUGZ for software project management and bug tracking. It's web based, affordable, and runs on your own server, and it's now available for Windows, Unix, or Mac OS X servers. Check it out now -- there's a free online trial!"

    Well I have posted twice about this as I read, and now must say that I found the root of the article. It was all a damn ad!

  • by SuperKendall ( 25149 ) * on Wednesday June 16, 2004 @07:20PM (#9447205)
    There are many points in the article to me that seem a little bit from the past:

    1) Mac. Perhaps a few years ago it was "hard to be a Mac user". But it's not hard at all anymore, except for games - and even then it's only troubling, because most game development has shifted to the console. For any other kind of App you can get just about any top-tier program for the Mac, with Mac versions of any remaining holdouts on the way. In fact I would absolutly say that I dislike Office on the PC but do not find Office for the Mac as annoying.

    2) Web apps. Somewhat contrary to the "Everything will be lightweight web apps" message, I think we are seeing the real rise of web apps that make use of the web only as a transmission medium and have much richer interfaces. As an example I would point to iTunes which does not have an interface you can point a browser at, but is a real web app at heart. I think we'll see more programs along those lines.

    Avalon seems like a neat idea but I don't know how useful it will really be to be able to create a form with a floating video in the background with a few lines of XML. To really make it work they'd have to deploy Avalon support to previous versions of IE back to Win98 really - and I'm not sure they are going to do that.

    I do generally agree with Joel's assesment though, that the camp that just cares for new wizzy features and has abaondoned supporting old stuff has won out. Ironically Java has taken the "protect old code" attitude with things like Generics support, whil Microsoft has gone for a somewhat more featureful implementation that might break some older stuff. As he noted there are changes from .Net 1.0 to 1.1 that break things, and looking forward Windows.forms is already depricated!
  • by GPLDAN ( 732269 ) on Wednesday June 16, 2004 @07:25PM (#9447245)
    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.

    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 .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.
  • Garbage Collection (Score:5, Informative)

    by Peaker ( 72084 ) <.gnupeaker. .at. .yahoo.com.> on Wednesday June 16, 2004 @07:33PM (#9447326) Homepage
    is hardly the main productivity boost in people's programming environments. Sure it is a productivity boost, but not the main or even the biggest one.

    The main productivity boost in Python, for example, is its dynamic typing. Its simplicity second, and automatic memory management as a third, perhaps.

    Also, his claim that you don't have to debug memory leaks with Garbage Collection is a common fallacy. Garbage Collection makes it very possible to leak memory, often in more difficult ways to debug, since the developer is typically unaware of what memory is behind held by which objects as usually there is no need to put much thought into the issue.
  • by ceswiedler ( 165311 ) * <chris@swiedler.org> on Wednesday June 16, 2004 @07:47PM (#9447435)
    This is why WINE is the most dangerous OSS project to Microsoft. Microsoft can always make good applications to run on Windows, and maintain an edge over the competition by dedicating lots of money and developers and selling the apps for a net loss. It's worth it to them as long as everyone runs Windows.

    When the Windows API becomes a commodity implementation, the exact thing will happen to Windows which happened to commercial Unix vendors when Linux and BSD reached maturity. It no longer becomes important to run the original (possibly a little better) version, if the free version does well enough.

    Linux doesn't emulate Unix in every little detail--just enough to make it easy to run applications developed for Unix. In doing so, it made the Unix APIs a defacto open standard. WINE will do the same thing for Windows, and that, more than anything else, will be Microsoft's downfall.

    In ten years, Microsoft may be gone as a company; but when people run GUI applications with buttons and scrollbars, it will be using the Windows API.
  • by bahwi ( 43111 ) on Wednesday June 16, 2004 @08:35PM (#9447765)
    The browser will not be the future of application development as long as spyware/adware exists! Yes, even Mozilla is susceptible to this(the ad/spyware that affects Window's TCP/IP stack or however to re-route connections). That is why it won't work for awhile. That is why we're moving an entire PHP site to Visual C#(with PHP backend on the server, for now).

    Just my 2c, but I am sick and tired of hearing "The app is broken" and telling them to run ad-aware and hearing "Ok, it's fixed now. Try not to let it happen again." argh!
  • by Mufasa3245 ( 706965 ) <jojo245@firetige[ ]et ['r.n' in gap]> on Wednesday June 16, 2004 @08:49PM (#9447868) Homepage
    1. Create a fast drawing program
    2. Build a real-time spell checker with wavy red underlines
    3. Warn users that they are going to lose their work if they hit the close box of the browser
    4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server
    5. Create a fast keyboard-driven interface that doesn't require the mouse
    6. Let people continue working when they are not connected to the Internet

    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.

  • by NullProg ( 70833 ) on Wednesday June 16, 2004 @09:37PM (#9448151) Homepage Journal
    From a cross-platform C/C++ programmer who is probably not as good as Joel, a couple of issues.

    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 .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.

    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.

  • by scrytch ( 9198 ) <chuck@myrealbox.com> on Wednesday June 16, 2004 @10:05PM (#9448356)
    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.

    So if I'm interpreting accurately, Microsoft just pulled off a successful vaporware strike ... on their own platform

    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+, .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.

    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 .. in fact, one major REASON it's moving to a new set of API's is to avoid the commodity the Win32API is becoming!
  • by humankind ( 704050 ) on Wednesday June 16, 2004 @10:14PM (#9448403) Journal
    The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

    Great. All our worst fears have been confirmed. The latest version of windows is exactly the hacked-up piece of shit operating system that it acts like that we've all secretly hoped wasn't really the case....

    Who in their right mind would want to develop for a platform like this? Now we know why the OS is so bloated and slow. There's probably a zillion special little mods to the OS to make select, Microsoft-approved legacy apps run properly.
  • by Anonymous Coward on Wednesday June 16, 2004 @11:19PM (#9448751)
    The first big win was making Visual Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.

    Bullcrap! I bought heavily into MS's bull about being able to develop with Word and Excel macros in the Visual Basic scripting language. I wrote several applications for customers that had lotsa finely crafted Word and Excel macros. I bought the first round of Microsoft documents that told me how to do these things. I never bought the second round.

    You know why? Because they changed everything in the shift from Office 6.0 to Office 97! All of a sudden, every API in the Visual Basic scripting language that underlaid Office changed; not just a little, but enough that a whole new shelf of documentation was needed. When I presented my clients with estimates of what was needed to rewrite the macros to make them work under the new Office they quietly asked that I restore Office to the old version. No can do! Microsoft had made that impossible!

    Failing that, my clients insisted that it was my duty to make the macros work with the new version of Office no charge. This would have required rewriting them. Riiiiight! I was gonna do that! In the end, they went back to doing it by hand and I never got another job from them!

    Developers! Developers! Developers! indeed! How many more times do you think I did anything with Microsoft tools?
  • Good/Bad competition (Score:4, Interesting)

    by SnprBoB86 ( 576143 ) on Wednesday June 16, 2004 @11:36PM (#9448844) Homepage
    Random MS vs Linux or whatever point:

    ATI and nVidia are in what I like to call "good competition". I can choose one or the other with minimal negative side effects for either choice. Their products are complete substitutes for each other and that is good. They force each other to be innovative.

    The current (and for the forseeable future) situtation with operating systems isn't so wonderful. Mac, Windows, Linux, and Unix are certainly in "bad competition". I can't switch between them that easily. If I choose the wrong one I've got major problems. Can't run this game on Linux, can't get that application for Mac, constantly fighting spyware on Windows, etc. Their products fill different, but similar needs. Maybe it is just the nature of the product, but it really sucks. Sure the normal rules of competition apply, you need to have better stuff than the compedators. Unfortunatly, operating system vendors can easily lock you into their product. Changing my video card may cause an visual artifact in 1 out of 20 games, but changing my operating system is gonna throw a wrench in everything.

    Platform independant applications exist, but we aren't quite there yet. I think more effort needs to be put into this. Personally, I really like the .NET framework and would love to see it become the standard for cross platform applications. I would also love to see cross platform applications become the standard ;-)

    I think Microsoft sees that they will not be able to hold onto the operating system market forever and I believe they are making a good move (both for themselves and for the industry) by depreciating native Win32 in Longhorn. Hopefully, the bet-the-company mentality will let them force people to accept change.
  • by Hard_Code ( 49548 ) on Thursday June 17, 2004 @12:01AM (#9448998)
    Ok, let me get this straight:

    Technical community and pundits: OMIGOD the windows API is so crappy and kludgy and windows crashes a bazillon times a day and you shot my dog

    Microsoft: no, it's actually YOUR badly written applications

    TCP: OMIGOD it's still your fault

    MS: That's ok we fixed it for you anwyay.

    TCP: OMIGOD why did you waste all that energy on such and old and rotten API! You suck! HUZZAH! I'm throwing salt in your eyes

    MS: Yeah, I know, we finally decided it was time to part with all that baggage and hired smart guys that you seemed to like and invented .NET and a whole bunch of other replacement APIs

    TCP: OMIGOD why did you do this to me!? I thought you loved me!? I'm going to run off with my new lover "teh intarweb" where we will make complicated scientific visualization applications out of javascript and feed starving mouths with semantic web markup alone, and live in a utopian libertarian dream!

    I don't buy it. I think Joel has entered the crank-o-sphere. While XUL shows some tentative promise as an application development platform, current web standards are pretty damn CRAPPY at creating rich interactive GUIs or applications of any complexity. That is why we see so much Flash cropping up.

    I for one think .Net is a GREAT step forward (if not for everybody else, at least for people who previously lived lives subsisting off prior Microsoft C/C++/COM/ActiveX/etc. sludge).

Truth is free, but information costs.