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."
Liberals call everyone Nazis yet they are the closest thing to it.
I've programmed for Win32, MacOS Classic, and MacOS Carbon. Of those APIs, Win32 was the easiest to use and had the best documentation. Carbon came in second, with Classic a very distant third.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Yes, there is a lot of investment in old Win32 code.
.NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute, considerring that they *don't break backward compatability*.
.Net, and *that* is not something that MS could afford doing.
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
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
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.)
--
Two witches watched two watches.
Which witch watched which watch?
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
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?!?
Please correct me if I got my facts wrong.
I program in Objective-C, using Cocoa libs under Mac OS X. ;-)
What's amazing is that Java combined with the hack-y nature of the Win32 APIs finally forced Microsoft to create something that's still not as good as NeXTStep was 15 years ago, and probably isn't ( yet ) as good as Java ( it's just optimized for it's single target platform ).
I'll leave for those who care to debate Java vs .NET. For me, that's a debate that is pointless unless .NET somehow becomes cross-platform, at which point I expect Bill Gates to burst into flames.
Once you get used to building projects where you can view data paths from end to end with no opaque blocks in the middle, and once you get used to being able to compile debug code into any and every library, you'll never want to go back.
Poppycock! When I write code under Linux, I go to man and Google first, not the source. In my experience, the MSDN library is more than a match - it's very good documentation. The problem is the sheer number of APIs under Windows..
Most of my work these days is under Windows, and I will freely admit that on occasion I have used the source that Microsoft provides. That's right, I have the source to MFC, C library, ATL, WTL, etc. It's not due to lack of documentation though. I often debug in to assembly code, but it's normally to get to somewhere else (e.g. step in to the COM libraries to reach my COM code) and the debug symbols that are freely available normally suffice to give me enough context
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.
Write boring code, not shiny code!
This is an Open Source fantasy. It simply isn't true no matter how much you love Linux (and I love Linux a lot). The API is not dead, it only seems that way to the Slashdot crowd who see thing through glasses with a unique prescription. Believe it or not, as of yet, Linux is not sweeping the world like a storm...
"It's open and documented such that developers feel comfortable using it and feel like they're getting a powerful suite."
This is only true for Open Source masochists. Building software that does not require the user to have intimate relationships with the OS to install, this is still a large issue that is more or less ignored by all the elitist "gurus" out there.
"One thing that Microsoft hope doesn't happen is Mono becoming the defacto standard and not the MS framework."
Honestly. This is not a troll. Is *anyone* actually taking this seriously? Mono is more or less a "If Microsoft can do it, OSS can do it better" type of deal. Mono is a tool in search of a problem. Write once, run anywhere is a fantasy that just does not provide any real world solutions to real world problems. The only reason so many people are using .NET is because Microsoft has made it the default environment, not because they have problems that only .NET can solve.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
It seems there may be a few applications 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.
The win32 api, especially from a modern standpoint is just a bizarre creation. Certainly a lot more complex then the stdio, and other Unix libraries. It's grown in strange ways, by using the 'reserved' bits for new things, cramming weird structures in other structures.
but I've always been able to find documentation on every part of it. Microsoft documentation is very good, and has always been.
I'm sure there are a lot of bizzare hacks and special modes that are not documented, but if you base your code off the documented APIs, you'll be fine.
autopr0n is like, down and stuff.
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!
On the spot, AC.
What I wished was that we went back to POSIX -- well, not quite, actually some garbage-collected functional stuff running on POSIX -- and the X Window System.
And I think that could come to pass. With GNU/Linux spreading, Mac OS X holding its share and getting X servers (both Apple's gratis and Fink's free ones), and Cygwin/X getting easier and easier to install, we could soon have X servers everywhere, so that we could run applications from POSIX servers whenever HTTP didn't suffice.
A trend may be starting with public Telecenters and other LTSP or otherwise host-and-terminals GNU/Linux implementations.
Then we could go back to improving the host (GNU Hurd, functional programming, relational databases) and the terminals (Cairo, I/O) and stop worrying about the API du jour.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
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?
Xix.
"Everything is adjustable, provided you have the right tools"
How can he say that ASP.NET is great? As someone using it full-time, I can see how it's very good if you want to rapidly create data-driven sites by using MS dev tools that look pretty much how you designed them in IE. But is you want to have direct control of the HTML of your product, ASP.NET makes it very hard on you.
This sig is not the Zahir. Lucky for you.
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?
Wait; this is completely contrary to my experience. I worked on Lotus 1-2-3 for Mac, which was targeted at Mac OS 6 & 7 (7 was new when we shipped 1-2-3). 1-2-3 was written in C (actually Symantec's C++ subset) with some inline 68K assembly, and did some grotesque trap patching.
That 1-2-3 68K code runs under OS X on a PowerPC G5. Reliably. I still maintain spreadsheets that I update weekly.
As Joel's article pointed out, Microsoft has engaged in some amazing bend-over-backwards hackery to maintain backward compatibility. This echoes a Wall Street Journal article written about Windows NT development where Dave Cutler bragged about the number of programmers tasked with adding code to make certain "high profile" Windows 3.x apps run under NT.
By contrast, Apple, in the early releases of Mac OS, showed enough foresight to tell developers how to keep their code future-proof, and developers who adhered to those protocols (which were not all that restrictive) wrote apps that still run today, under an entirely new OS on an entirely different CPU.
Yeah, supporting Netscape 4.7 would probably make me murderous, too. JavaScript as a language is actually really nice. It's object-oriented, but the type system is very flexible (they're aren't really any classes, per se, they're all "prototypes"), functions are objects, so you can pass them around, and closures are possible, which gives you lots of power. I agree that differences between browser implementations can cause some grief, but we've been able to abstract away most of those differences, so there isn't a single line of code in the entire code base that makes any reference to the browser string. Of course, this means that if you try to use the latest version of Konqueror that I tried, things just blow up, because we assume your browser can handle our app, and that version of Konq can't, but we're developing for a captive audience, and we can almost dictate browser versions, so that's been a bit of a saving grace. One nice thing is that all the developers work on GNU/Linux, so it has to work in Moz for us to be able to develop, but the users all use IE, so it has to work there for us to sell it. This dichotomy (did I use that right?) has dictated that our framework must be cross-browser. If our code was littered with
I think we would have instigated a mass suicide a long time ago, but since we have almost no code like that, and since all such code is hidden in the equivalent of "library code", making new screens, or new functionality is pretty straight forward. I find the productivity to be pretty high, and the library has only been in development since August of 2003. Of course, I'm biased since I was one of the pilot developers, but the opinions of my coworkers seem to at least align with mine, even if they're not quite as enthusiastic.Ian
Random MS vs Linux or whatever point:
.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 ;-)
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
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.
http://brandonbloom.name
I suppose it's just Murphy's law. There's two ways for programmers to interpret the version number on .so objects, so naturally they choose the disasterous way.
I used up all my sick days, so I'm calling in dead.
I don't know about the INTERNAL TO MS thing, but...
;)
There were several internal workings functions that MS didn't document AT ALL. That's not to say that their documentation was poorly done. On the contrary, it was excellent. None of the undocumented functions would cripple a developers ability to write a program they wanted to write. It simply gave MS an edge in developing certain applications, as an added tool.
MS, for the most part, keeps functions undocumented for support reasons. They have service contracts with many large companies and many of their developers (primarily through MSDN subscriptions) have incident support for development. If you followed the API, your app was GUARENTEED (I mean that in pretty much the strongest way possible) to work on EVERY future version of Windows.
If you wanted to do some snazzy things in the meantime, you could use undocumented features, and your app would break next version.
I have a sneaking suspicion that MS keeps functions undocumented until the version of Windows AFTER they use the function in one of their own programs. That way, they have the ability to change any functionality they want, but they make sure all their own apps are forward-compatible by putting their own "hacks" into the API.
This is supposedly anti-competitive. On the contrary, I think it is a very successful way to compete.
It is quite possible to make alot of this stuff work crossplatform via a browser.
A good example is lotus workplace, based on J2EE - you can access, edit, create information. When you need more advanced features you get a 'richer' java interface.
Of course this is not always enough, and then you can use their rich client for the available platforms - most users will however not need this.
Also the latency problem is not very big, since the lotus products work via replication (and thus you are working on a local copy while the server version is locked etc.).
There's a lot of stuff you can do via the web which is normally done via desktop app's. Using Java makes it crossplatform (and thus makes the OS decision irrelevant). This is not to say that desktop app's will disappear, but more to say that the author is right - a lot of stuff will work perfectly fine via the web.
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...
``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.
Please correct me if I got my facts wrong.