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."
Repeating my comment on OSNews... (Score:5, Insightful)
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.
Hard to be a Mac user? (Score:5, Insightful)
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.
Re:Repeating my comment on OSNews... (Score:2, Insightful)
No, that's exactly the same as Microsoft's. Find me a deprecated *and removed* MS API call, I dare you.
Good idea (Score:5, Insightful)
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:Why it has to die (Score:5, Insightful)
doesn't compare to much to "We'll give you the source code"
Microsoft Developer Network [microsoft.com] 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.
Increased Irrelevancy, however. (Score:4, Insightful)
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.
Re:Prophecy (Score:4, Insightful)
Seriously, an open standard will keep them _alive_, but it won't keep them _ahead_. They have to innovate and stay incompatible, so that people won't want to use competing products.
Kids (Score:3, Insightful)
Re:Repeating my comment on OSNews... (Score:5, Insightful)
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...
That's so much BS (Score:1, Insightful)
I think that Joel has a good theory as to the reason: Microsoft has a critical mass of people whereby the internal voices overwhelm the external voices and they have decided to clean things up, and modernize and improve them. That means breaking old stuff, in order to remove the icky and clunky bits.
In the long run (Joel theorizes), that kills Microsoft's huge advantage over Linux, Apple, and everyone else: backwards compatibility. If Microsoft wants to retain their advantage, they have to push their advantage: write once, run on any Windows system that comes out in the future, and many that came out in the past.
As a (former) die hard web developer (Score:5, Insightful)
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
Re:Repeating my comment on OSNews... (Score:3, Insightful)
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.
Re:Good idea (Score:2, Insightful)
MS would do OK if they were to give away the stuff necessary to run Longhorn apps on older versions of Windows.
The problem is that when Longhorn is out, you will *still* need to wait for several years before you can actually write apps that use it.
MS *could* have provided Longhorn-API functionality for older versions of Windows, but that really ruins any incentive to move up to Longhorn, so their hands are tied.
*sigh* The problem is that Linux needs to figure out how to make a good desktop environment. Given how piss-poor people who *try* to create a good desktop environment do, I've not got much hope there.
ideological loss, but still winning in the market (Score:3, Insightful)
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").
I disagree .NET will fail due to Longhorn/Avalon (Score:3, Insightful)
I believe that the long wait for Longhorn/Avalon to be released will cause more people to pick up
Developers will see the benefits of the
When Longhorn/Avalon finally gets released, the adoption I expect will be slow. We just spent all this money becoming proficient with
I just can't see how
Re:Prophecy (Score:5, Insightful)
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.
Re:Why it has to die (Score:2, Insightful)
API's are a black box: you pass them values, they return some.
All you need to know is what to feed them and what to expect in return.
PS - I've developed software for both GNU\Linux platform as well as microsoft platform(s) and I'll take linux ANY DAY OF THE WEEK!
Re:Prophecy (Score:3, Insightful)
I think you're bang on the money regarding Microsoft and open standards.
My prophecy is that Microsoft have their eye on the next web battle over standards - XAML vs. XUL [mozdev.org] vs. Flex. [macromedia.com]
Re:Hard to be a Mac user? (Score:2, Insightful)
True thus far
No Trojans
Want to rethink that MacOS X Trojan [intego.com]
indefinite uptime
Not a valid metric
great applications
In the eyes of the beholder
Win32 API will live forever (Score:5, Insightful)
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.
Re:Uhh... what? (Score:3, Insightful)
Re:Why it has to die (Score:5, Insightful)
Comprehensive up to a point. In fact, not comprehensive at all. People have sold books [amazon.com], 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.
Re:Repeating my comment on OSNews... (Score:2, Insightful)
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.
Web interfaces are not that good because the monopolistic owner of the most popular browser decided years ago that the Web was a competitor to their proprietary APIs. Therefore they've thrown no resources at advancing or evolving it. This sucks the wind out of the whole Web industry because nobody is going to serve data that requires an alternate browser.
Re:Repeating my comment on OSNews... (Score:3, Insightful)
Need network access? The BSD socket API gives it to you. Servers, clients, peer to peer? Not a problem.
So you want graphics? The X Window System has been around since 1985 and the protocol is still the same. Your old clients will still work with today's servers. Toolkits for making the programming easier have been around for a long time, too.
Anything you need to do can be done on UNIX (and POSIX) systems using APIs that have been stable since the 1980s, possibly earlier. win32 didn't even exist then.
Sure, if you want the latest technologies (Java, GNOME 2, Qt 4), you will have to put up with the fact that they are not backwards compatible. However, the old APIs are available, too, if you need them, and you can write any application using those.
Re:This is how Microsoft fixes bugs (Score:4, Insightful)
Perhaps I need clarification of your point?
Re:Why it has to die (Score:0, Insightful)
They did a fairly commendable job of balancing power vs. ease of use, as well. A bit too much towards the power side, tho.
Besides, I would -much- rather have a really well documented set of APIs, than 30mb of pure c source code and no good API docs (X-Windows), anyday.
The only thing not well documented are the NT kernel APIs. The driver development documentation is very sparse, there are many exported functions from ntdll/ntoskrnl that don't even have explanations for them. But this hardly matters to 99% of programmers.
Re:Why it has to die (Score:0, Insightful)
Oh, come on. People have sold more ridiculous books than that.
You have a public API you don't change. You implement this in system libraries. These libraries need to talk to the kernel directly. They do this through a private API. Everything on the private API is exposed through the public API, so it's of no interest to anyone. Except weenie authors and people who buy their books.
What's next - mangu publishes: "Linux: Direct kernel calls for all the l33t kids!" ?
Think he's living in the past a little on this one (Score:3, Insightful)
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
Re:Hard to be a Mac user? (Score:1, Insightful)
Re:Why it has to die (Score:5, Insightful)
Re:Half Wrong. (Score:1, Insightful)
Key quotation regarding IE... (Score:5, Insightful)
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
Re:Repeating my comment on OSNews... (Score:4, Insightful)
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]
Re:Good idea (Score:5, Insightful)
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.
This is why WINE is the most important (Score:3, Insightful)
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.
Re:This was not an unusual case (Score:4, Insightful)
...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)
Re:Prophecy (Score:3, Insightful)
Microsoft will back a huge open standard? This is the silliest thing I've read in a long time, you're either shilling or smoking something strange ..
Re:Hard to be a Mac user? (Score:5, Insightful)
Like he said, *you* have everything *you* need, but the plethora of quite diverse and intensive applications that everyone *else* needs isn't there. Sorry, he's still right.
1. People seem to mix up the fact that just because a particular Windows application isn't available on Mac, that Mac users do without. As a rule, it's not the case.
2. What applications do the vast majority of Windows users use? Office, IE, and Outlook. Right? They are all available on Mac though there's little reason to use IE and Outlook. The one exception is Access. Is this a show stopper in the corporate and business world? Sometimes. In the home market? Rarely.
3. To the typical user -- geeks included -- the availability of more software on Windows just means there's more software they could use but don't. This is not a minor point; there's only so much software that any one person will want to use. I'd be curious to see if Windows users use more, less, or the same amount of software as Mac users.
4. While quality is often in the eye of the beholder, I for one still think that Windows software tends to be crappier than Mac software. Unfortunately, that crappiness seems to be spreading. Suffice it to say there are more ways to produce crappy software than good software and since Windows has so much more software available for it ...
It's not hard being a Mac user, certainly no harder than being a Windows users since the vast majority of users have a hard time using computers at all.
Try this perspective: as a longtime Mac user, I have a hard time using Windows because I can't find much high quality software that runs on Windows --even after several years. Stands to reason, doesn't it? Considering that all the major apps -- Word, Excel, Photoshop, Illustrator, etc. -- were born on the Mac platform, you'd think developers would look to the Mac sometimes for how to do things right.
Re:Why it has to die (Score:3, Insightful)
doesn't compare to much to "We'll give you the source code"
I disagree. Source code does not equal documentation, and if you have to trawl through source code to find the API, that's wasteful and time consuming (and just plain difficult). What source code does give though is the opportunity to trace down problems where the API isn't working as documented (or intended). That's a plus - but it's not necessarily a big plus.
Re:Why it has to die (Score:4, Insightful)
Wasn't the lack of documentation for some APIs part of the U.S. antitrust trial?
IIRC, there were some APIs that weren't even documented INTERNAL TO MICROSOFT. Something about not having to document APIs for third party developers if the API wasn't documented for Microsoft use...
Re:Why it has to die (Score:5, Insightful)
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.
Re:Why it has to die (Score:3, Insightful)
You are joking, right?
Web as a the savior (Score:3, Insightful)
Re:Good idea (Score:5, Insightful)
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.
Oldschool (Score:4, Insightful)
Re:As a (former) die hard web developer (Score:2, Insightful)
This pipe dream has been repeated over and over and over for years. Okay, so we have Gecko, Java, JavaScript, etc. etc. -- all the attempts so far at "rich clients" more or less suck, because nothing yet ever invented made programming significantly easier than before. So, instead of relatively simple and understandable things like POSIX and even X Windows, we now have 1000 layered buzzwords from SOAP to XML to JavaScript to whatever where no programmer on earth can hope to understand them well enough to really get real work done and test it on all the relevant platforms and find that it actually works on all those platforms...because it is all still based on POSIX/X Windows/MS Windows/Mac OS in the end. Full circle--we have gotten nowhere. "Web enabled" has taken the fun out of software development.
The best websites to this day are still damn simple. E.g, Google, Slashdot on "light" mode, etc. The most annoying are those whose developers had a JavaScript orgy and passed out before the QA meeting.
Re:Repeating my comment on OSNews... (Score:3, Insightful)
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
I can also trim my lawn with hand-clippers, but a lawn mower would be much more efficient.
It is not easy, stable, etc. to make a complex but usable web interface. They all end up cutting corners, relyig on browser-specific functionality, plugins, etc.
What I want to see is something like XUL or XAML turned into a standard and then having a XAML or XUL browser instead of a web browser, with a simple HTML-rendering component built into it.
Reading a news article is a very HTML thing to do. Perusing and replying to threaded discussions is an exmaple of something that would probably be experienced better through an actual UI instead of an HTML-ized version. How about your Yahoo Mail or GMail accounts? They woudl also benefit from a UI-markup-language producing a more traditional client-side UI.
The question is, how long owuld it take a UI-browser to become as ubiquitous as the web-browser?
HTML's lack of features? No. (Score:4, Insightful)
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.
Re:I do agree, and not with you. (Score:5, Insightful)
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.
Re:Why it has to die (Score:4, Insightful)
Re:Repeating my comment on OSNews... (Score:3, Insightful)
Yes, obviously, but a simple experiment on my machine shows one very good reason this isn't happening. I have maybe a dozen windows open, and several have as many as 10 tabs showing closely-related pages.
I keep javascript and other scripting turned off for a very good reason. If I turn it on and refresh any of these windows, that browser's cpu usage rapidly goes to nearly 100%. Why? Simple answer: advertising.
Most of the actual web content makes little use of scripting. No point, usually, because I'm mostly displaying static docs. But the advertisers want my attention, and to get that, they use changing pictures. A changing widget requires cpu time. It doesn't take very many "active" ads to saturate the cpu.
But I'm trying to get work done, and I need my cpu. My only defense is to turn off scripting. And set the image processing to only do a single pass through a changing image. This isn't totally successful. The mozilla here is running at about 10% of the cpu when idle, even though I've turned off all the "active" things that I know about.
When someone comes up with a scripting technique that doesn't allow web pages to soak up my cpu, maybe I'll consider leaving it turned on. Maybe.
Of course, there are also security concerns. Anyone who leaves scripting turned on in IE is a fool (or is working on a "crash and burn" machine and doesn't care). Java and Javascript are materially safer from a security viewpoint, but they still have some serious risks. I have a demo page with a bit of Javascript that downloads an image to your machine without ever showing it to you. Depending on my mood, it may be a porn image, and anyone watching your Net usage will see that you downloaded porn. Depending on where you are, you could lose your job and/or land in jail as a result of downloading my web page with Javascript turned on.
But the cpu usage is the real story here. As far as I can tell, nobody is working on solving it. Unless I can trust the Web to not soak up all my cpu, I won't seriously consider allowing any cpu-using Web gimmicks to run.
Re:Why it has to die (Score:5, Insightful)
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.
Re:Why it has to die (Score:5, Insightful)
I respect Joel, but.. (Score:5, Insightful)
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,
Speciousness nit-pick (Score:3, Insightful)
Quoting AR: (for the furious: byte *buffer = malloc(1024); isn't legal c++)
not to "/sigh" but... /sigh
... in the sense that you will get a warning, I supposed it's not...
byte *buffer = static_cast<byte *>malloc(1024); is both "legal c++" and warning free.
byte *buffer = new byte[1024]; is, of course, "better", but the old format (which demanded a (byte*) before the malloc to shut the same warning up anyway) is "just as valid" as the new.
(All of the above assumes that you have "typedef unsigned char byte;" or some such as, since "byte" was never a C or C++ intrinsic...)
Most of your compatability argument is trash anyway. It is (arguably) "impossible" to maintain backwards compatability when moving from more-to-less type safety etc, but when moving from less-to-more it is a matter of dilligence in the construction of the tool set and execution environment. If some of that dilligence can be done in hardware, all the better (see the Sparc garbage collection shared object library that you could LD_PRELOAD with any C program to make it self healing) but reguardless, one could produce a C compiler and envrionment that was completely type-safe and "morphic"(tm) by catching all the unsafe language features (pointer, malloc, reference, etc) and passing them through a scrubber library and generating safe code.
More simply put, one could produce a C "compiler" that really made Java/Python/Perl/etc out of the program and then ran that.
So all this "can" and "cannot" and "must" is Specious. The only thing you cannot ever do is give Java true multiple inheritance... 8-) [I jest, of course, more or less.]
The fundamental problem is that things that "just grow into place" but are never "designed" tend to age poorly. They have to be replaced eventually and Microsoft, by edict, "does not re-write code." You see, *IF* they had the stones (and mayhaps they do, in Longhorn), they would write a "real" Windows API that didn't carry all the baggage around, and then they would replace WIN32 with another, identical WIN32 that called into the new API instead of the old. See, the current WIN32 API looks back in all ways, and is often required to have several different implementations of essentially the same functionality in order to get around the lack-of-design mistakes of the past. If they were to take everything they ave learned and make a good (and open) API that ecnompassed all the "functional domains" that have come before, then the old libraries could be re-cast as sub-set adapters insted of super-set side-cars. (e.g. if the small data goes through new big holes, instead of trying to pass big data through old small holes in an "apparently conformant" way, you gain the liberty to make things work.)
It's all in the "founding assumptions." DOS was assumed to be for tiny systems with no growth potential, and we are still hauling that assumption around. *nix was assumed to be for "big systems" and was cut back variously to make the various smaller variants (invariably 8-). Even so *nix still had some growing to do (look up the saga of time_t sometime.)
So if Microsoft would stop looking back from it's core, and instead were to look far forward from its core and only have a small adjunct group looking back to do some "compatability layers" then much could be made right with the world. (This is, BTW, why WINE can fit essentially all of Windows into a Linux process.)
Presuming that the "display surface" offered by the web is "interesting" has always been (IMHO) a symptom of all-flash-no-sizzle. So I agree that "the web" isn't some great healer or panacia. HTTP a transaction-based "fetch" environment, so anything that doesn't look transaction based won't be part of "the web" but will need to be something totally else "attached to" the web via something (hopefully) more sophisticated than "a browser." (Which is where Java, and Flash and god knows what all else came from; the de
Re:I disagree .NET will fail due to Longhorn/Avalo (Score:3, Insightful)
The same framework, same languages, same development tools just a load more apis for the newer Longhorn features. The base libraries are the same, concepts and idioms, event models, the works.
If people spend the time now to become proficient with
If you structure your application well such as using the MVC pattern you can swap in a new UI that uses Avalon rather than WinForms without having to alter your core business logic at all.
hoist by their own petard (Score:5, Insightful)
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
Reason #78,048,234 to dump Windows (Score:4, Insightful)
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.
Make it linear (Score:3, Insightful)
That's only if every new version has to support every old version. In practice, that is rarely a necessity; as long as you provide an upgrade path, it doesn't much matter if you only support the last version or two directly.
For example, contrary to the article's claim about VB.Net vs. VB6, I think Microsoft's first spectacular compatibility failure in recent times was when they changed the file format between Office 95 and Office 98. After a bazillion users complained that they couldn't work with their old data post-upgrade, Microsoft (eventually) released the missing functionality to do the conversion.
Of course, it would have been better to incorporate that from the start, but failing that, tools to convert between successive major versions usually suffice.
Re:I do agree, and not with you. (Score:4, Insightful)
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.
Re:Backwards compatibility is possible. Forever (Score:3, Insightful)
Is Wine done yet? (Yeah yeah, "Wine Is Not An Emulator"; today it is.) How long would it take you to finish Wine, plus
(Answering an obvious misunderstanding: You can't get out by saying "I'll just use Wine", because emulators are taking longer and longer to develop, especially for moving targets like Win32. Again, that solves a technical problem, but only in an idealized world where you have infinite time to wait for someone else to do your work with no repurcussions.... and if you have to do the work yourself you gain nothing.)
Re:Repeating my comment on OSNews... (Score:3, Insightful)
Of course, this might have had something to do with the fact that we were forced to support Netscape 4.7, even in the age of Mozilla.
I was wondering about that as well! (Score:3, Insightful)
Web API for Longhorn clients ONLY (Score:3, Insightful)
For Microsoft's strategy to succeed, it has to get developers to produce compelling apps that require the new operating system. Microsoft had trouble getting developers to develop for Windows back when DOS was king, and had to prime the market with its own Windows applications. But after Word for Windows and Excel dazzled users, other application developers had to follow and recreate their DOS products in Windows.
But Joel thinks the new API will not improve web apps so much that users and developers will need to flock to it. It'll be interesting to see what applications Microsoft comes up with to show off the new API and attract upgraders and developers to the new platform.
Re:Repeating my comment on OSNews... (Score:5, Insightful)
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.
Re:Why it has to die (Score:4, Insightful)
Sun's pretty good, too...before
(use three slashes instead of two and you enter XML documentation mode which is slightly more intuitive than javadocs). I can add a new method to our data layer and not have to announce what it does to the rest of the team...which saves some email time.
Oh, and I like Apple's development docs, because they're always in nice detailed PDF files full of errata, examples, war stories, and explanations of Why It Is Like This.
Re:Prophecy (Score:3, Insightful)
Re:Win32 API will live forever (Score:3, Insightful)
Let me get this straight - you think that with the next release of Windows, MS are going to completely break compatibility with almost every single Windows application in existence?
It'll never happen. Over time, and the next few releases, they will almost certainly push very hard to get people away from the Win32 API and onto
Re:Good idea (Score:3, Insightful)
Really? On my Linux box, I have a DOS emulator running. Just for kicks, in that DOS emulator is a ZX Spectrum (USA name: Timex Sinclair) emulator running, which perfectly runs the game 'Jet Set Willy'.
Now that you could call backward compatibility over 25 years, and it's working great.
So you have a new API? Well, looks like you'll need a called-on-demand conversion layer for the old API.
Sucks, yes.
But a *lot* of people are using Windows, and a huge amount of them have *not* updated. A lot of offices are using NT. A lot of users are still on 98. Why change? All the software runs on it, all the games run on it, all the new hardware works with it - why should they switch?
So if you now come and say: "Everybody, everybody must update! You need new Hardware, new Software, new OS... you'll be spending a loooot of bucks!", I don't think that you'll be overrun by enthusiastic customers.
Why are people not switching to the Mac? Because their software doesn't run on it. Now it doesn't run on the new Windows, either? Well, they might just switch, even if the hardware is more expensive.
Switching anyway? Well, you don't have to buy new hardware, and there's a lot of software which looks nearly like what you're already used to - on Linux. Why not switch there instead?
You can hold a market in your iron grip if they all need compatibility with you. Drop that and you loose.
Pales in comparison (Score:5, Insightful)
Re:I respect Joel, but.. (Score:3, Insightful)
Microsoft Mail to 5,000,000 Developers: Umm, we fixed this bug in win32.dll, just check your code and recompile. Once the 1,000,000,000 Windows-Users have their windows Update fired up, you guys can distribute your patches!
yeah, sure, why can't they do that?
Seriously, this affects ALL kinds of widespread APIs, open or closed source. Once you have reached a critical mass of people using an API, you'll never ever get rid of it.
Hell, Unix is decades old and we still have creat() and umount().
Microsoft needs change, otherwise it will die. (Score:3, Insightful)
Having worked extensively with Windows, I can safely say that WIN32 sucks...not from a quantity side (you can do everything with it), but from quality side: everything is a horrible mess and the simplest thing to do becomes a really hard task with WIN32. Therefore, I considered it natural to slowly be phased out, either driven out by market forces (that can't stand the cost of developing for bare Win32) or real innovation.
Software and hardware companies should also understand that there is an upper limit to the computer market. This limit is defined by how much needs are covered. This limit has been reached in the last few years: modern operating systems and applications cover almost every need. There is just no need for newer operating systems, for Office enhancements etc. People are at last satisfied with what they have, and there is no need to change.
I really doubt Microsoft will change anything with Avalon. No matter how impressive the new interface is, I really doubt hundrends of small, intermediate and big companies will ruch to change hardware in order to run Avalon. It's not like 10 years ago, when networking and windowing were considered new and cool technology by average Joe. Now everybody can have a decent GUI, either with Linux or an older version of Windows (Windows 2000, for example).
Re:I do agree, and not with you. (Score:4, Insightful)
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.
Re:This was not an unusual case (Score:3, Insightful)
Bottom line is that it wasn't one coder. This was multiple people in multiple departments in many different capacities where none of them did the right thing. Was it a directive from the board, a group of executives, or the dominant culture at Microsoft? Who knows. Frankly, who cares? It was certainly deliberate.
Re:Bizzare, yes. Undocumented, no. (Score:2, Insightful)
The main problem I've had is finding the funtion I want. If I want to do X, I think of tons of likely function names and keywords to search on, and rarely find what I'm looking for in a timely manner. Usually, I'll go through 3 steps to do what I want, and months later find some obscure code on the web that uses the function I wanted, which ends up having a name completely unaligned with my logic.
Re:Hard to be a Mac user? (Score:3, Insightful)
A program that silently installs and does things to a user's computer that they don't want, without the user's knowledge, when the user is just trying to play some music sounds like a trojans to me...