Slashdot Mirror
Joel On Microsoft's API Mistakes
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
A closed set of poorly documented APIS
Say what you like about MS's evil ethics but *do not* mock their API docs. They're very good.
Wow - I never knew before reading this article that Microsoft's Visual C++ Compiler is now free. (Free as in 'beer' of course.)
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.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Non-existant API Docs for Qt are located at http://doc.trolltech.com/3.2/index.htmls -api/
KDE's are at http://developer.kde.org/documentation/library/cv
Thats every function call to program in KDE and Qt all completeley cross-refrenced, with examples.
If a first you don't succeed, your a programmer...
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 the abstraction layer between the physical machine and the logical machine.
KFG
Examples:
+ finding documentation on ASP vs finding documentation on PHP
In the index, you click "Web Development", "Server Technologies", "Active Server Pages". If that's too hard, you type 'ASP' in the search box in the top left hand corner. OK, the ASP language reference is under the IIS docs but you'll find a link to it from the easy-to-find ASP pages above.
+ finding documentation on VB.NET vs finding documentation on python
OK, I couldn't see this one in the index myself. But I searched for 'VB.NET' in the box on the left and the sixth or seventh link goes to the VB and VC# language docs, complete with reference, which is in the Visual Studio documentation section.
>they will become increasingly irrelevant like IBM has.
Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.
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.
You would be lucky if a GNOME app for GNOME 2.0 even compiles for 2.6. It will most certainly not run if it's already compiled.
I call for BS on this one. Now, if you'd have said "GNOME app for GNOME 1.4", then you'd have been right; but, you know: API breaking does happen, from time to time, especially when an API overpasses the point of being sucky enough to be unextensible.
On the other hand, a GNOME 2.0 app will run, without the need for recompilation, under GNOME 2.6. Flawlessy. In fact, I'm using apps written, tested and compiled with libraries released for GNOME 2.0 under GNOME 2.6.
Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.
You can save space. Or you can save time. Don't ever count on saving both at once. -- First Law of Algorithmic Analisys
A bunch of replies to this thread have mentioned Flash as a potential solution. "Real" developers don't like Flash though, because the IDE sucks. (I use it every day, it does.) Macromedia has an answer for that too, and it's Flex, which doesn't require any specific IDE. (However, they're working on one, and it looks pretty hot so far.)
> Dude, why *would* I want to debug the systems' calls.
I don't think he was saying you want to debug other people's stuff. If you have a full debugging version of all the libraries (your and other peoples) it is *much much* easier to debug problems.
And even though I may not want to debug other people's libraries and such, I have had to. This is how I have found bugs in things like PHP, mod_python and such. They were corner cases to those developers, but they weren't for my applications. I'm thankful I could track those problems down, because my application got back up and running again. Not usually the case when I have proprietary closed libraries.
Ciao!
The Doctor What (KF6VNC)
Actually Classic and Carbon are pretty much one and the same. Carbon is Classic with some of the less-used and less-functional API removed, plus some of the newer Mac OS X-related stuff added in.
Classic has a TON of documentation, the print form of it was mostly the Inside Macintosh series, which had literally dozens of books. The books were separated logically by category (interapplication communication, graphics, human interface, etc) and had extremely detailed documentation on the Classic API as well as tons of examples. Most of that information is still good to use for Carbon, in fact most Classic programs will recompile easily using the Carbon API - just a few minor changes have to be made.
As for ease of use, Carbon and Classic seemed pretty intuitive to me. Certainly no harder to use than the Win32 API and, IMHO, probably easier.
Now the new entry into all of this is Cocoa. Cocoa is the new API that Apple is using for Mac OS X. Cocoa is based on Objective C, a Smalltalk-like language which adds object-oriented ideas to the C language. It does this in a fairly simple manner and doesn't feel as kludgey as the additions which C++ added to C. You can also use both C and C++ code within your Carbon code without too many hang-ups.
The Cocoa API has the poorest documentation of all of these API but it is definitely the most simple to use. It has a form of garbage collection, it has some very nice helper classes, and the method names (they are called messages in Objective C) and class names are very descriptive and intuitive. Of all the API I've discussed Cocoa might be the most difficult API to get information about but once you learn the basics you can really fly in coding with it.
Sapere aude!
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, the Mozilla documentation, the Microsoft documentation or this tutorial called Using the XML HTTP Request Object
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. 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.
Ian
Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.
.95.
Unix versioning is based on sym links. Given that it doesn't look like sym links came into play until somewhere around SVR 3.2 which seems to have come from 4.2BSD (I base the "come from" on a diagram on page 5 of The Design & Implementation of the 4.3BSD Unix OS), and Linux didn't get them until
Now, I don't know what your definition of "since day 1" is but if it's 14 years (First Edition released in 1969, 4.2BSD released in 1983) then you're absolutely correct.
I'd also point you to the fact that Unix didn't have passwords on day one. They were added later. So much for security can't be added on, it's gotta be designed in. Not that you claimed that they did but it's an example of where Unix came from.
You see when Unix was designed it was a stripped down Multics. Multics was too big, too bulky, too much operating system with too many features. But if you look at the features of Multics we all have them on our desktops (and Unix systems). So Unix barely had anything from day 1. You wouldn't want to use day 1 unix today. Oh, maybe you'd find some level of nostalgia in it - it'd be like whipping out a Pong console - but you wouldn't ever make it your desktop, let alone attempt to install multiple versions of software on it.
Someone once wrote on an academic review that I shouldn't look to programming as a future. I was in middle school. Now I'm about to graduate with a CS degree.
It sounds like this guy is a kid playing around, or at least he was when he wrote the program.
Anyway, yield is actually only needed on OSs that do not have preemptive multithreading, which NT does. Yield wouldn't have solved his base problem anyway, just that he could have seen it didn't work when he set the thread to real-time, rather then seeing his machine lock up. (When you set a thread to real time, it's like running it on an OS without preemption, sort of).
In java, the threading behavior is determined by the underlying OS. If it has preemption, your java code works, if it doesn't, it doesn't. Back in the 1.1 days, Macs didn't have preemption (didn't get it until OS X(!)), and since java might want to run there, they you needed to yield.
autopr0n is like, down and stuff.
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.
NO CARRIER