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."
It is amazing how .NET and C# are finally starting to migrate over into commercial use. There were ideas in the early 90s by those of us who were smalltalk developers that we wanted to see back then. It isnt until now that C# is finally integrating some of those features for development use.
:(
Damn, I miss Smalltalk
GroupShares.com
-------
artlu.net
I have 2 comments:
.NET doesn't go there; the GUI interface is very much tied to Windows.
1. Web clients vs. rich user interfaces
I have long wondered why web interfaces aren't much good. The technologies are there; Java applets, Flash, Python could do it, JavaScript could with a few extensions, XUL, heck, even C, compiled on the fly. All these stop just short of integrating well with the web and the client platform. Why? Why has nobody managed (or tried) to take the last step? Even
2. API changes
Contrary to Microsoft's, UNIX and POSIX APIs have been very stable. There have been extensions, but the bulk of what used to work still works. This makes the case for switching over to standard technologies, now that Microsoft is pushing you to switch anyway.
Please correct me if I got my facts wrong.
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.
No it isn't, it's easy to be a Mac (OS X) user. No Viruses, No Trojans, a sytem that stays up pretty much indefinitely, and great, great applications that do everythinbg I need and much more besides that I probably don't really need, if I'm honest. This old argument about Mac having no apps is very old, very tired, and very tiresome. Please stop.
Honestly, I think breaking API compatibility is the only way for MS to actually fix the problems with Windows. A lot of the problem seems to be the large amount of old code and cruft that has been left in the name of backwards compatibility.
It's certainly a big risk to the Microsoft monopoly, but it's a necessary step for them. Now would be a good time for Linux to make a big move for the desktop.
The reason for the death of the API is probably GNU/Linux. A closed set of poorly documented APIS
doesn't compare to much to "We'll give you the source code"
Microsoft Developer Network has comprehensive documentation about the Microsoft APIs. When I was developing for Windows platform, I never needed any documentation other than MSDN. And if you want source code, you can download the SDKs for free. Though it contains only sample codes, I wonder how many Linux developers looked at the sources of the APIs they use. I have never did such a thing.
MS may have a long way to fall, but they will become increasingly irrelevant like IBM has.
As far as I am concerned, they don't need to go out of business to have fallen. They just need to lose most of the influence and power they have gained through their illegal and unethical business practices.
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.
Microsoft supporting an open standard? Pass me some of what you are smoking, please!
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.
Please correct me if I got my facts wrong.
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).
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
Wow - I never knew before reading this article that Microsoft's Visual C++ Compiler is now free. (Free as in 'beer' of course.)
I used to preach the "web is everything" argument from every soap box I could. I don't think HTTP and HTML will cut it for the types of interactive programs we will see in the future. Heck, in many cases they don't cut it now.
.NET for about 2.5 years now I can go into my office and find any number of contradictory statements about the .NET APIs, statements published my MS! I think this is hurting them quite a bit.
I can see technologies like SOAP enabling rich clients to interop across platforms (ok MS haters, SOAP is a mult-vendor thing so don't reply telling me some tinfoil hat story on how MS will patent SOAP and sue anyone who uses it without license). I am willing to bet some other protocols similar to SOAP, or perhaps riding on top of SOAP, will come along to allow richer communication across networks. HTML just isn't going to do it.
While I totally agree that open standards and open source make the best APIs, MS failed way before even that line. Take SMB for example. Their systems, by design or mistake, don't even follow their own standard! I am betting it is a little of both. Their APIs are this way as well. What is really hurts MS in this particular area is poor documentation and poor implimentation of their own APIs. Having worked with
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
And people say the evil giant doesn't try to fix it's software. They fixed SimCity DAMN IT!
http://jayceecorder.blogspot.com
Located in Real of Windows 2000/XP the Suburb in the district judio, Joel took step to the Islamic enclosure of epoca. Although its date cannot be dated from origin, have the news of the same one as of the century, API reconstructs on the century and this influenced of the sort to mudejar, Microsoft aspect that emphasizes remarkably in the present one and conserved well in Windows XP.
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").
I think that Joel is wrong here.
.NET as an alternative to the old API development.
.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.
.NET. Why change to the new system now? Unless you need the new features, .NET should cover most needs of application and web developers.
.NET will go away so soon after it's introduction.
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
You can lose something that is loose, so tighten the loose item so you don't lose it.
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).
Photos.
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...
Umm... HTML and HTTP *are* open standards that are backed heavily by Microsoft that give power and flexibility to developers. :)
If you were using something other than HTML and HTTP, you wouldn't be doing Web development; you'd be doing some other kind of development.
Macromedia Flash applications backed by SOAP look very interesting for apps requiring more GUI-like, real-time interaction. This is basically what Java applets were intended for.
Who cares if the API's are open? How many developer's read through linux API's? 0.000000001% ... of linux users! Whats that, like 6 guys?
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!
I also fail to see how he feels (apparently along with others) that the API is MS's cash cow. There have been people building libraries (like the ones his beloved VB use) to abstract the OS-API layer, like QT, or Java (which built its own VM, but still abstracted the OS out in most cases). IIRC the 2.6 kernel changed a lot of things in linux, even broke some apps, but did not spell the downfall of linux (granted, they did not change the entire API and are stil POSIX compliant, I think). Why then would a new API hurt MS? If Longhorn catches on (assuming it's ever released), then people will program for it, just like they do for XP/2000.
Now that I've stopped making sense even to myself, I end this rant.
for maximum effect, the preceding post should be read monotone and at a steady cadence
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 vs. Flex.
This is where the serious fun begins.
Crow and Tom Servo?
From the article:
"... they could reinvent themselves as a shaved-ice company at the last minute. "
Already there are still people using DOS and Windows 3.X and refuse to upgrade. There will be people using 32 bit Windows for a long time as well.
Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release. When that happens, Microsoft will have abandoned the Windows 32 bit platform for Longhorn. Then Linux + WINE will be very valuable for people with new machines who can only run Longhorn or Linux.
My only request is that WINE and other programs than run softare using the Win32 APIs, create a sandbox to prevent viruses and worms from spreading.
The bets are on as to how soon those Longhorn viruses and worms come out after Longhorn is released.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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.
Comprehensive up to a point. In fact, not comprehensive at all. People have sold books, profitting from Microsoft's incomplete documentation. I think the grandparent post is somewhat exagerated in saying that it was Linux that made Microsoft put aside the API. However, in my particular case, it was the incomplete API documentation that made me stop using NT and start programming in Qt in Linux. I tried and tried, and there was no way I could make a data acquisition program I was writing to work well under NT 4. I did exactly what the MSDN documentation said. Then, in desperation, I tried to learn Qt. 20 minutes after starting to read the Qt documentation I had my first non-trivial working Qt program. That was in 1998, and I never wrote a MS-Windows program ever since. I have migrated with little effort my MFC programs to Qt/KDE. I only need three sources of documentation: qt3-assistant, Johnson & Troan's "Linux Application Development", and Rubini's "Linux Device Drivers". Plus the thousands of sites in the web where I can find source code for Linux, of course. A complete documentation is good, but nothing can replace a good set of examples.
I spent about three years writing web based, sql backended applications, so I like to tell myself I know a thing or two about it.
I love this argument about state tracking. Every single server side scripting language posesses some kind of session tracking functionality. Based on IP address as well as some other odds and ends (depending on implementation). No cookies, no mess, and totally invisible to the user.
Saying thats not a valid form of state tracking would be like me telling you that because your unix terminal doesn't lock itself as soon as your keys leave the keyboard, its just a security risk waiting to happen.
You haven't done anything very unusual then. I'm writing software that has to support NT4. Try searching for NetSetupComponentInstall. It's a valid API function, but all you'll find are a couple references on Google Groups. .Net for the same reason I won't use Java for anything serious: it requires you to install a huge VM on each machine.
And I have to say I refuse to use
LOAD "SIG",8,1
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
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.
I've used wxWindows (now wxWidgets). For the parts that aren't buggy, it's slightly better than Win32 in ease of use, and somewhere worse than any of the others in terms of documentation.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
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!
http://jayceecorder.blogspot.com
Perhaps I need clarification of your point?
I survived the Dick Cheney Presidency 7 to 9 AM 7-21-07
There are many points in the article to me that seem a little bit from the past:
.Net 1.0 to 1.1 that break things, and looking forward Windows.forms is already depricated!
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
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You've obviously never worked with win32. We're talking a half-dozen library calls and about the same number of strange handle types & structures to do something simple like get a directory listing & then look at the dates on files. MFC and .NET may be more usable but they still have an underpinning on an API that was designed to be backwards compatable with 16 bit windows and the 16 bit Windows API was an outgrowth of the structure of a large assembly program rather than being designed with any sort of usability in mind.
my sig's at the bottom of the page.
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
And Joel says that in his article. And he's *right.* I can't tell you how many places I've worked where there was at least *one* application, that was critical to the core business function of the company, that was a windows program. These people had no choice to migrate away from windows. They *could* put a mac *and* and wintel box on each desk, but they weren't actually going to do that, when the wintel box did everything they wanted in one computer.
Joel's point - and the reason Microsoft killed netscape, is that as more and more applications (especially business database apps - which constitute most of the lock-in special apps I was talking about earlier) more to being web-based, it becomes less and less necessary to run Windows.
Microsofts's strategy with Internet Explorer, in the end, turns out to have been brilliant (maybe more brilliant than they originally intended). . . Make IE *good enough* to work for most 'current generation' websites, push it out for free to everyone in order to marginalize the competition to the point where no further innovation can happen in web-browsers without Microsoft also adding that functionality to IE, then STOP DEVELOPING IE so that NO innovation happens AT ALL.
Then, once people get frustrated with the limitations of html (which could have been alleviated with on-going development of the standards), announce that you are release a new technology that will give 'rich client' interfaces over the network.
So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it's certainly good enough for developers, who have voted to develop almost every significant new application as a web application.
.NET towards building a open web application, and making that application portable. You start stealing from the edges of Window developers. You start picking away at the hordes. That's how you win, you take Microsoft's strongest weapon away - the masses of developers. Where the devs go, users will follow.
Which means, suddenly, Microsoft's API doesn't matter so much. Web applications don't require Windows.
It's not that Microsoft didn't notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There's no way Microsoft is going to allow DHTML to get any better than it already is: it's just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: "Microsoft is betting the company on the rich client." You'll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that "Avalon, and Longhorn in general, is Microsoft's stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We're investing on the desktop, we think it's a good place to be, and we hope we're going to start a wave of excitement..."
The trouble is: it's too late.
So, when Slashdot goes on and on about how great Mozilla is (and it is good, I'm not saying it isn't - I really like FireFox 0.9) and laments how Microsoft hasn't done a damn thing with IE since 2001, and how you need the Google toolbar and this and that - remember that quote.
Microsoft wants to slow DOWN the rate of advancement in the browser. If you buy that, and buy Joel's premise on that, you now should conclude something VERY VERY IMPORTANT.
Mozilla for Windows may be the SINGLE MOST IMPORTANT OSS project there is. In many ways, it is just as important as developments in Gnome and the linux kernel, disk systems, network protocols, what have you. It's advancements in being able to push rich applications is vital. It's replacement for Active Scripting needs to be secure. Every step it makes pushes another developer that may have gone to use the Windows API or
There are less Linux desktops out there than ones running MacOS. Most non-fanboys don't think Linux is going to storm the desktop for years to come. How are open desktop APIs going to impact the deployability of apps unless they have a majority of the installed base?
I have been working on business apps for years now and I agree completely with the author. We deliver HTML based interfaces because it is so much easier to ensure the client runs on different hardware platforms. Desktop APIs come and go, but HTML is still going strong. The slickest rich client UI in the world is no good if it won't run.
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.
I thought I knew where Joel was going with the article, but was surprised when he didn't get there. I expected him to explain MS's loss of the Win32 API as the high-level .NET APIs (and VM) making the low-level Win32 API irrelevant.
And once everyone was developing against the new, high-level APIs of .NET, and MS no longer "needed" to support Win32 apps, that would open the door for others on other platforms to develop .NET compatible VMs for those, NON-MS systems.
And it's at that point that MS has totally lost control. Their former OS lock will have become irrelevant, and even the apps created by die-hard MS loyalists, for deployment only on MS, would suddenly be able to run on anything. (more or less not unlike Java)
I'm disinclined to agree with Joel about the future belonging to browsers. Sure, they'll still be very important and there will be many more web-based apps out there. But for rich client apps (which will surely still exist) they will not be locked to MS or any other os, as long as high-level, memory-managing VMs have become the norm.
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.
Do you think cars should have to be sold without tyres as well ?
There's absolutely NO "16-bit windows" support in .NET!
And, since it's written for a virtual machine environment you can't possibly claim it has its roots in old Win16 baggage.
I program professionally on both Mac and Windows and I'd have to say that the Windows .NET API is MUCH easier to deal with than all the "baggage" I have to deal with on Apple's platform! (Like using QuickTime for images, Carbon/Cocoa/NextStep/Objective C, etc.)
MFC has not been actively supported from Microsoft for years. I'd say MFC was their biggest failure. Few people used it for real applications, and MS didn't use it internally for much.
Best Buy can have you arrested
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 ..
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.
Just as they tried to do with Java, Javascript, and to some degree HTML, Microsoft will do the same with the Internet at large. With the installed base they have, they rule. Write your Web applications to conform to standards; but if they don't conform to Internet Explorer's quirks, you're in trouble. The average user will think something is wrong with you.
Look at some of the Web sites or Web applications out there that are developed with Microsoft's tools. What I mean is, look at them with a browser other than IE, or a platform other than Windows. I think we've all seen where the substandard, Microsoft-Kool-Aid-drinking developer has thoughtlessly developed with Microsoft's tools, leaving the application broken for non-Windows/non-IE platforms. Hell, I'm sure such developers don't even test them on anything else but Windows-IE. In there minds, Windows and Internet Explorer is "everybody."
Microsoft absolutely counts on this behavior and how it makes anything but the Windows-IE combination look bad. They'll be sure to give the world more of the same with any "solutions" they concoct in the the future.
Microsoft's next generation of development tools and languages may run on the 'Net, and profess to work with any browser or platform; the practical truth of the matter will be different, however. The will again corral a herd of substandard developers within their API's and development tools, and send them stampeding over the World Wide Web to trample all other platforms and browswers.
quiquid id est, timeo puellas et oscula dantes.
Qualifier: I'm not a programmer by trade
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...
Government's idea of a balanced budget: take money from the right pocket to balance...oh who am I kidding?
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.)
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.
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.
You are joking, right?
LOAD "SIG",8,1
WOW! That makes 6,000,000,000 (6 billion) Linux developers. With that many developers I would say the Win32 API is already dead.
Unless some of those 6 billion developers got bored and decided to implement Win32 on Linux. Now there's an interesting idea...
Here's the two word problem: stateless protocol. HTTP was not meant to do what we are trying to do with it.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
> 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)
I don't know much about Carbon, but Win32 and MacOS classic are both very old apis. You really ought to try something new like wxWindows, QT, or whatever. The Java API, which I'm very familiar with is light-years ahead of Win32 for doing 'computer' tasks like networking, file access, or cryptography. but Swing has it's own quirks, especially when you're trying to make your layouts 'pretty', but it's still much easier to use then Win32
autopr0n is like, down and stuff.
What's with the backslash in GNU\Linux? You look suspicious to me, Microsoft boy.
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!
While on general lines I agree with the article, he clearly misunderstands WinFS -- the effect might still be the same, as either MS itself is misunderstanding WinFS, or at least selling it badly.
WinFS, or files on a SQL -- not relational -- database is not about organising for search, but about not having to organise, yet being able to.
With current hierarchical filesystems, we are forced to organise files hierarchically, and that's very often cumbersome. So search functions have to dig into each document and kinda Google it, building a full-text index, and that takes lots of resources and is difficult to do. Not even Apple does it good enough, at least it didn't in my then-Mac OS 9 366MHz iBook.
With an SQL database as the filesystem, even if SQL is so inferior to the relational potential, we get rid of the necessity but not of the possibility of hierarchies: we can still put some or all of our files in hierarchies, but now the specific nodes in the hierarchies where the file is are just some more attributes, so any file can be at several places at several hierarchies, or at none at all. Searching too becomes more efficient, but the real benefit is alternatives to organisation, and therefore the possibility of richer queries and easier remembering.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Anyone else see this list? I scoffed at most of it instantly. Sure, the author apoligizes for a few of them but very poorly and with no explanation.
The author says that some of these can be solved by JavaScipt. No; all of them can be easily solved with Javascript. And if you don't like Javascript, try using ActiveX, DHTML/CSS, Java, Flash, ColdFusion, or any of the other many options out there.
It is true that these solutions take a little more work, but everyone knows that. The author admitted that much.
My question is this: If the author doesn't even say this list is accurate, why did he even put it in the article?
If he must make a point about the web versus Microsoft, make it about the fact that Microsoft refuses to update their web browser even though everyone knows that it was not even standard compliant when it was last released so very long ago. There are much better browsers that are still under constant development including Opera, Panther, and Mozilla to name some excellent examples.
Mufasa http://www.firetiger.net/
The only thing you can count on is change.
A program that reads data from a sound card mic input, does some processing on this data, and writes the result to disk. Again. And again, in a loop. In NT I couldn't find any way to do this without losing some data. I found that the write to disk operation seemed to disable hardware interrupts for as long as 100 milliseconds at a time, and I would lose input buffers. If I set the priority of my input routine to "real time", then the entire machine (mouse, keyboard, etc) would stop responding. Someone told me I'm really dumb, because I didn't put a "yield" in my read input loop, but the "comprehensive" documentation in MSDN didn't quite cover that point. Since the same algorithm that didn't work in MFC/NT4 worked perfectly in Qt/Linux, only adapted to the different API, I realized that I didn't need the MSDN documentation at all...
Some of your points are valid, but it doesn't matter WHY Microsoft is changing around API's, it's the fact that they are changing at all.
.NET stuff, when you could just code web apps, or apps based on Open Source, and *know* they will work in the future? And the other point is that companies aren't going to jump on the new platforms because they won't be released for several years and won't be mainstream for several years past that, if at all, with competition brewing.
Sure, backwards compatibility with Win32. But not full backwards compatibility, it's more like a subsystem.
The point is, why re-code all your applications for the new longhorn stuff, why re-code all your applications for all the
It's an interesting time, and I won't bet on either side of the coin. We'll just have to wait and see what happens.
ps. Mozilla and Firefox run Slashdot and 99.8% of web sites out there perfectly for me.
- It's not the Macs I hate. It's Digg users. -
Debuging into system librarys ? Librarys should be blackboxes, and you should be able to trust them.
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!
Yeah, that's why I don't use any OS for anything serious: it requires a huge kernel on each machine...
"I think this line is mostly filler"
1. Tell everyone the Win API is dead.
2. Insert advert at bottom of article.
3. ????
4. Loss!
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"
You're claiming that MSDN is impossible to read? I've been a programmer working in Windows development for years, using Win32 APIs, MFC, and various other bits and pieces. Say what you like about the interfaces themselves, Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale. Compared to typical *nix man pages or trying to sort out perldoc, it's paradise, and why the top-level poster thought giving the source code was at all equivalent to giving good documentation I have no idea.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Well, I could say I rest my case, the MSDN does *NOT* have a "comprehensive" documentation, does it, if I have to look somewhere else. But OK, the DDK is also in the Microsoft site, so let's not get too tecnhical on this point.
No, I wasn't writing a device driver. I have done that once, for an ISA card I designed, so I know how to write a VxD for Windows. My problem was in using a device, namely a sound card. I had a program, written in C++ using MFC, that had two threads: one for reading data from a sound card, doing some processing and writing results to disk, and another thread for showing the results on the screen. There was no way, and I couldn't find any answers on MSDN, on how to run both threads with high enough priority to not lose any data. I did that in Linux without much problem, using two processes, instead of threads. I know Linux is not a "hard" real-time OS, but my program works without any problem. I have discussed this program in some forums, and people have told me how I was supposed to put "yield" instructions in the input loop. To me, that sounds like what the system task scheduler is supposed to do. An ordinary user like me isn't meant to mess with the task scheduler. In Linux my program works perfectly using what's presented in Chapter 9 in Johnson&Troan. In NT I'm supposed to do something more, something that neither the documentation which comes with Visual C++ or the documentation in MSDN tells me how. Perhaps there is somewhere in the depths of MSDN something on the right way to use Yield. But, since I was unable to find this documentation, and Linux works perfectly without any Yield, I chose to program in Linux.
Librarys should be blackboxes, and you should be able to trust them.
*wipes away a tear*
Thanks... I needed that. If I had modpoints, you'd have +1 Funny right now.
- fader
From a cross-platform C/C++ programmer who is probably not as good as Joel, a couple of issues.
.net. It still calls down to the Win32 layer. Why would I not still call the Win32 API directly? Apps still work under 9x and Ntx based systems. I really don't see MS scrapping kernel32 or user32 in the near future.
1) It's not ANSI VB or ANSI Win32. If you settle on a programming environment controlled by one vendor, then they can change the language specifications at will. I wrote my System/UI specific wrapper functions over a decade ago. Why didn't Joel?
2) Joel compares C/C++ memory management to automatic vs manual transmissions. I would associate memory management in C/C++ to doctors who know once they make an incision, they have to close it back up when done. Either you know the procedure (or launguage) or you don't. The article seems to want to apologize for all the Comp Sci grads who don't have a clue when it concerns system level programming (I found one in my office this week).
3) VB is a layer on top of Win32. So is MFC. From the object dumps I've run on MSIL applications, so is
4) The Win32 API is feature rich. Give credit where it is due. The Win32 API evolved from the OS/2 API developed in the late 80's in conjuction with IBM.
5) The reason Raymond Chen had to make the effort to be backwards compatible was that some published API calls were always different than the implementation (say API bug). Remember the DOS bug/feature that allowed TSR's? Remember when DDE turned into netDDE which turned into COM? This brain-dead logic has carried MS through until modern day XP. As an API/Library developer for my companies products, I've had to tell third parties I made a bad design decision (2) and you need to re-compile with the new library/API header. All of them appreciate and understand my mistake. Why can't Microsoft do this?
Great article, just some food for thought from a old time beer drinking hippie programmer. Gotta go, playing network freecraft with my ten year old.
Enjoy,
It's just the normal noises in here.
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
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Except that Longhorn/Avalon/WinFS is built with .Net, so all that training carries right over. .Net now and move their existing applications onto it, it only makes it all the easier to jump onto Longhorn. .Net is not going to go away, it's going to be at the core of the whole Windows platfom.
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.
"Taligent is still pure vapor. Maybe they'll be the last who jumps up on Openstep... "
And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn.
... on their own platform
.NET and some technologies that NEVER took off, I can still use DDE for my IPC needs. And even MS's own apps like IE still do.
.. in fact, one major REASON it's moving to a new set of API's is to avoid the commodity the Win32API is becoming!
So if I'm interpreting accurately, Microsoft just pulled off a successful vaporware strike
The rest of Joel's rant is just way off track. Microsoft has ALWAYS pushed a new incompatible tech, while keeping old ones around. I mean hey even after I got COM, OLE2, COM+,
People predicted MS was going to put itself out of business when it came out with NT, because well hey while you're learning a new API, you might just switch to Solaris (now on x86!) or that exciting OS/2 thing... Microsoft succeeded for two reasons: it kept trying ("third time is the charm" really applies to MS) and its competitors kept screwing up. I don't actually see that changing significantly.
MS is hardly doomed
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Because WEB APPS AREN'T ANY BETTER.
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.
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
You missed the point entirely. I never said it was technically impossible, I said it's not free. It costs, and those costs rise, they never fall.
.NET support, plus Avalon support... ... and here's the real point: While you were doing all that, did your competitors eat your lunch? (Even Open Source competes for developers.) Yes, yes they did.
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.)
I have experience writing for both platforms, and I prefer C++, despite VB's garbage collection. VB certainly makes it easier to do some things, but that's mainly because it offers an abstraction for all the Win32/COM red tape (dig through the MSDN to find which of the eleven or so Close...(), Delete...(), Free...() functions you need for this thing, and Release() all those COM pointers in every conceivable exit point).
C++ itself provides the means to relieve the programmer of much of this menial work, though. Microsoft doesn't take advantage of C++'s capabilities, but that's probably because C++ hadn't evolved enough when much of the Win32 code base was written.
In my recent work, which has all been C++ on Win32, I almost never have to manually delete anything. The Boost Smart Pointer Library has been tremendously useful, both for internal program logic and for taming the Win32 memory management nightmare. The reference-counting boost::shared_ptr template class and its relatives can be used to automatically free memory allocated with new when the last pointer is destroyed. What's more, you can specify a templatized deleter, so that a shared_ptr can manage COM objects, GDI objects, file handles, memory allocated in any of the dozen or so Windows APIs (GlobalAlloc(), VirtualAlloc(), HeapAlloc(), ThrashDiskAndThenCrashAlloc(), etc.)
It's possible to augment the API in such a way as to boost productivity without breaking backward compatibility. The .NET framework is a huge misstep, in my opinion, because it needlessly throws away a decade's worth of existing code. We were going to use it in a recent product, but we decided to go with MFC instead, because it couldn't link with our existing C++ code (well, it could, but huge marshalling bugs that have gone unfixed for years made it completely unusable).
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.
Hrm...
QEMU is more what I mean by emulator.
Want to run Windows 95 applications? Run them under Windows 95 in QEMU, or VmWare, or maybe VirtualPC.
Given the project's momentum, within 1 year QEMU will be as good as VmWare in OS compatibility. It will be Free in all possible ways.
Crossover Office version of WINE works very well. With the abandonment of Win32 the API will be anything but a moving target.
I'm just saying that you can have as much backward compatibility as you like pretty much for free. Just quarantine those old apps off into their little sandbox subsystem.
What you don't want to do is keep growing the old API till its horrifyingly crufty and creaking under its own weight as Win32 is.
I used to be a detractor of Flash. But over time I have seen some pretty good use of flash, not just annoying gratuitis graphics - and you can build a pretty powerful (and really, well, flashy) interface from it. You can get what Microsoft wants to deliver in two years today, on just abount any browser on the planet!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I agree - Microsoft likes to break standards, and they sure made a mess of the web browser.
Because, that IS what you're saying. People apparently wrote some web pages specifically for Internet Explorer, and they don't work correctly with browsers based on standards.
That's what standards are good for, and it's what Open Source software tends to follow a LOT closer then pay-per-view Microsoft software. And I can't exactly single Microsoft out completely; plenty of closed source companies do the same, but then again most don't have a monopoly.
- It's not the Macs I hate. It's Digg users. -
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?
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 have developed an application before using Flash in the front end and JBoss in the backend (OpenAMF makes up the glue in between, but there is also Macromedia's Flash Remoting). It's a very interesting way of developing a rich interface delivered via web, but it has it's limitations.
The first is the development effort in the front end. We had to create all our Flash widgets nearly from scratch because those that were included were not flexible enough. This was a fairly large job. An open library of flexible, easy to use widgets for Flash would make this less of an impact.
The second was the reaction speed of the UI, although this was considerably helped by the introduction of Flash 7 -- much smoother, plus the Flash programmers liked the addition of ActionScript 2.
The third was common to all web apps - the inability to "push" event from the server, relying always on user input to update the state of the gui.
Anyhow, all in all this is a legitimate use for Flash (besides advertising and annoying website navigation) which can be quite effective in differentiating a webb-app from the background noise.
To me, I think that web services or applications delivered through a web browser could play a large part in the future, they will not be the only (or the best, IMHO) choice unless there are major changes to how we approach these technologies. The author of the article talks about the major problems holding back (mainly poor GUIs in terms of design and responsiveness) and I think that this problem won't be easily solved without some new technologies that are not based on HTML. Once we get past HTML, I think better web apps will be possible.
Until then I will continue to see this dilema: what advantage does using a "web app" version of my software give me? Certainly, I can't imagine using some of my favorite sofware (Photoshop, iTunes, VS) as web apps. I think that as things work now, it would be possible to make web apps like Word, Excel, and definetly Outlook possible, but why? and what do I gain? When I type in Word, I don't want to wait 30 seconds for spell check to complete. When its late at night and I am writing a paper and it just so happens that the latest and greatest virus hits and my connection keeps bottoming out because of all the traffic, I don't want my word processing software to stop working. To me, using the common "desktop" software in a web interface would just be more of a pain. And I can't imagine what something like Photoshop would be like if developed using this type of technology. I think that software like Photoshop will always have to be developed as rich client or "desktop" software. The only other feasable solution that I see, is if one was to use some sort of Adobe portal where you log in, the latest version of their software is stored locally on your computer, and is run in some time of intrepreter much in the same way that Java or JavaScript works now.
Of course this is what I think when looking at technology as it stands now. I do think that in the future someone may create a new protocol for the internet that allows for a truely "web app" driven lifestyle, where you boot your computer, Mozilla (or whatever browser is popular by then) loads displaying something that could look like a standard desktop, execpt all of the icons really link to web apps that stream off of a server and are never actually installed locally. This could be a feasable future, but it is definetly not going to happen with HTTP and HTML, at least I hope not!
SIGFAULT
Right that a Web API would fill a need. But Joel says the Web API will only be on Longhorn clients, not available on older versions of Windows. Joel says Microsoft is betting that the new apps on that API will be so compelling that customers will have a reason to upgrade Windows, and Joel thinks Microsoft will lose that bet.
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.
Ok, let me get this straight:
.NET and a whole bunch of other replacement APIs
.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).
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
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
It's 10 PM. Do you know if you're un-American?
I have. The original documentation was written back in the days of Win 95. They updated the code for C++. And they left a mistake in there. The toolbar data structure has a 2 byte unused field in it that is NOT DOCUMENTED by Micorosoft. They have updated the information at least 3 times in the last 8 years. And it is still wrong.
Try loading a bitmap from a file on Windows CE. Look at Microsoft's documentation. Read their book on develpment. Then write and compile the program. It compiles fine. Then run it, and poof, it crashes. Turns out they did not implement the function in CE. There is 1 fscking article that can be googled out of the MS newsgroups on it.
I will soon be porting an app to Palm. And I am SO looking forward to woking with documentation that is better than Microsofts.
The only thing that saves them. Is when their documentation is wrong, their header and include files save your butt.
---------
vi +
Huh? Those calls are pretty much a one-to-one mapping to opendir, readdir, stat, etc. which you'd have to use on POSIX. I wound hardly call FindFirstFile() and FindNextFile() one to one mappings of whats in dirent.h. The memory allocation functions are one to one mappings minus the multiple memory pool support. And while in many cases their is a 1 to 1 mapping of functions, Microsofts handling of strings through calling the function with a 0 byte array is non posix like.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
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.
Right. That's one of the reasons I prefer working with Microsoft products where I can (basically whenever the OS is guaranteed to be Windows) -- Microsoft's docs are really, really good and the community is very friendly towards stupid questions. Frequently I'll find open source projects that don't even tell you how to compile the latest version correctly, let alone tell you the syntax of everything or the proper order of initialization.
.NET, Javadocs were the shit. But Microsoft takes it a step beyond and integrated documentation of methods with their code completion system as well as with the inline documentation of methods in C# comments
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.
Hey freaks: now you're ju
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.
I wouldn't have the OS assume complete responsbility for switching, (especially in the case of time-sensitive tasks), as it can be important to make switching as deterministic as possible. With better thread handlers (like there is in linux) it can be less of a pain to manage, but that doesn't mean it shouldn't be be managed at all. It all comes back to understanding what you're doing.
click-clack, front and back. I'm not moving this car otherwise.
In other words, in order to get started, you need to understand data organization, basic logic, and basic layout. Anyone who has made a web page with DHTML has these prerequisites, and that's a lot of "anyones." Hell, using even basic DHTML will have taught you DOM.
The rest of the tech is covered in the tutorial itself. All of it is using the concept of Separation of Concerns. Where do you put the structure of your documents? XML (XUL). How do handle events and call object methods? JavaScript. How do you make it look pretty? CSS. How do you set labels and do internationalization? RDF. How do you make objects that can be called in any language without making explicit language bindings? XPCOM. Etc. Want to change the look without breaking the event handlers? Edit the CSS. That's SoC. In this case, people could call it MVC (Model/View/Controller) as well.
- I don't need to go outside, my CRT tan'll do me just fine.
We need an OSS clone of Flex functionality. It is insanely great.
Google confirms: Ruby is the world's most beloved programm
'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.'
"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."
Openness of an API isn't as important as documentation of how to use it. Being able to look into the details of how an API is implemented breaks the contract, and enables you to depend on the specific implementation details to not change instead of being responsible and coding to the contract. That's the reason that you have a separation of implementation from interface. Often times, having the implementation details of some API makes it worse. How many times has Microsoft itself been burned by employees between Office and Windows collaborating too deeply, and as a result having to support some undocumented feature that should never have been there in the first place, or Office shipping Windows updates and Windows shipping Office updates. You don't want to make that same mistake.
Microsoft gives out the Windows headers and documentation. Those form a contract that enables an application developer to write to the APIs, and then test with (in some cases several different) implementations of those APIs. If your application isn't tested, say on Windows XP and Windows 95, then there are a few million people who might not be able to use it.
However, if your application depends on some line of code in Linux's APIs, and there is a change to that code, you won't discover it until your application breaks.
Microsoft Windows has a market where people develop commercial applications. If you want to make Linux be a mainstream desktop OS, one of the barriers you have to overcome is mainstream application developers (of ALL types). If all the great games run on Windows XP and Longhorn with Microsoft XNA (DirectX 10 and Media Player 10), then how many Linux geeks will still have a PC running Windows for their games (even pirated). If you're a teenager with a PC, do you want to run the NERD OS, or would you rather play Halo at a LAN Party?
If you want the lion's share of the software market available on Linux, you're going to have to convince games houses, application writers, system integrators, and other developers that there's a paycheck coming to them for producing content on Linux. Until at least 25% of the PC games at my local EB Games store say Linux on them, Linux won't have the desktop.
In simpler words: people who expect to not pay for their OS expect not to pay for their software. You can't sell me Linux if my games don't run on it. You can't sell my mom Linux if she can't buy a printer that works with it. You can't sell my dad Linux if his Digital Camera's software says Mac or Windows. You can't even give it away to this kind of person. They don't want it.
My parents started a small company that now (primarily) sells large clusters of Linux based servers (they've been selling hardware and software for my entire life -- and I'm 25). They run Windows on their desktops. The engineering tools they use (hardware engineering) run on Windows. The software engineers at the company run Linux.
You can't sell me Linux when it is being given away on the streets, but you can give it away with your hardware. You can sell me Linux as an embedded OS inside my LinkSys box (as long as there's a nice Windows XP logo certification on the side...), or ma
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.
My exception safety is -fno-exceptions.
If Microsoft does not keep spitting out "new technologies" (or rather new implementations of others' ideas) then how are they gonna survive in the market ? those 10,000 programmers and 20,000 testers need to be fed somehow (and I don't want to talk about the grand egos of Bill and Co).
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).
You can also add comments to individual enumerated values in an enum. Want to know what SYSTYPES.XCORSYS really means, or what its scalar value is? Put it in the docs.
Hey freaks: now you're ju
fix Slashdot's horrible, invalid HTML output. It is has been discussed to death before but the Slashcode devels have not put any effort into fixing it.
Take a look at these articles for more info on how this can be fixed.
Note: That last link is about a Slashcode user who has already tackled some of the major issues with fixing Slash to output valid XHTML and CSS
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.
The documentation I've seen is fairly hit and miss. It's obvious that one person/group wrote parts of it and another did other parts. Some function calls have good descriptions and examples listed, while others really suck.
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.