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."
Joel's a great writer and has shed tons of insight into software development, interface design, software business practices, etc. Hell he even managed to make an article on redoing your office a good read. Much props to him, holla!
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.
3 stories about Microsoft or someone related to MS?
Come on editors, there has to be better material!
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).
I have a project sitting on my plate right now, an upgrade to an old Access database that needs to read a flat file stored in a zip. The original version uses pkunzip 2.0 (!) and is being upgraded for XP. But since they haven't documented Zipfldr.dll yet, I'm limited by department rules to using Winzip9 and the Command Line add-on instead...which requires additional licensing.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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 dont follow this guy's articles/rants much, but he is basically regurgitating everything everyone has been talking about and cramming down everyone else's throats for a long time.
.NET and didnt provide a straight forward migration to .NET from VB6.0 and other crap that they built. They expected that since all their developers loved them to death, it would have been easy to just port them from the antiquated VB6.0/5.0 to VB.NET. The industry/developers didnt move fast enough for them, which is where Microsoft suffered.
(1) Microsoft Loves developers who code on MS technologies - Sure, thats why they reel them in with swags. They lost a ton to Java, and they alienated another bunch when they moved to
(2)Compatibility - This was bound to happen, one day. With the rest of the world/industry/developers willing to sacrifice backward compatibility for the sake for something new/better, MS also realized that in order for them to move forward and keep pace, they have to do the same. Sure, they will have to piss some people off, but heck, they assumed the advantages would far outweigh the negatives. Wrong! But I am glad that Microsoft decided to shake free from the outdated Windows API model and embrace the new, and thereby have the balls to sacrifice some backward compatibility. You cant keep everyone happy for the rest of their lives. Some tradeoffs need to happen. You cant survive otherwise.
So what is this guy talking about other than whats already blatantly obvious to the rest of the world?
Rapid Nirvana
Greatest editorial I think I have read in about 5 years.
http://jayceecorder.blogspot.com
The Microsoft API's are well documented (*very* well documented), and the tools that Microsoft and others provide to use them are first rate. Contrast that with Linux, which still has no developer tools of that quality. Even though they are often icky and clunky, they are no worse (and often better) than what Linux and X and GNOME provide. The documentation for them is sure a thousand times better, and the developer community is larger and more experienced.
I think that Joel has a good theory as to the reason: Microsoft has a critical mass of people whereby the internal voices overwhelm the external voices and they have decided to clean things up, and modernize and improve them. That means breaking old stuff, in order to remove the icky and clunky bits.
In the long run (Joel theorizes), that kills Microsoft's huge advantage over Linux, Apple, and everyone else: backwards compatibility. If Microsoft wants to retain their advantage, they have to push their advantage: write once, run on any Windows system that comes out in the future, and many that came out in the past.
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.
The Windows team added special case code to run allow SimCity to run! That's an incredible effort.
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
That's a big guess. Currently, the words Microsoft, open standard, and internet shouldn't be used in the same sentence. Nearly everything Microsoft has ever done has been backed by the idea that they must do anything and everything possible to maintain a stranglehold on the market. Remember, before anything else, Microsoft is a business, and the name of the game is profit. If it comes down to maintaining an open standard, or increasing their profit margins, it will be an easy guess which one they choose.
Source code is not the same as quality documentation. The MSDN CDs and site provide great documentation for developers. It's much easier than sifting through the virtually non-existent API documentation when trying to develop apps for GTK or QT.
MS is already pushing XML-RPC. They would love the web to turn into a network of XML-RPC applications with a rich desktop interface, rather than a bunch of server-local copies of stuff with a dumb client.
Quote from the article ...
I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. 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.
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.
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
And/Or some of the other interesting OSS API's ...
Your list will get bigger, though you might have to shuffle a few things around.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
I frequently look into (non Sun) APIs when I'm working in Java. If the documentation is unclear then what better way than to just have a look?
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. "
> comprehensive documentation
> about the Microsoft APIs
I don't know... some seem to be better than others. The MAPI docs aren't so hot, especially if you want to do something with Extended MAPI. Granted, simple MAPI was documented very well... but try hooking some of the events and dealing with long IDs and all that... whew.
The best resource I found was an out-of-print book. Looks like Les has made it available on CD now, which is nice... a few years ago I had to buy a used copy off Amazon for $70 or so.
The Army reading list
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.
And Gandhi didn't have a job at all! What a sucker that guy was!
...
Oh, wait
He says...
Microsoft's crown strategic jewel, the Windows API, is lost. The cornerstone of Microsoft's monopoly power and incredibly profitable Windows and Office franchises
Not exactly. How about the fact that that every computer maker makes Bill'$ O$ the standard.
If the GOV would do their job and stop this COLLUSION and force people to buy Bill'$ O$ at Compusa for $100 bucks then there would be REAL tangible change for the better.
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
"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."
Microsoft made their API easy to use + free. That's how they're dominating the market! Ready pitchforks!!"
"Derp de derp."
Did you not get the memo yet that there are more web based applications written every year than anything else?
I fully agreed with most of his article, right up until the end. He kept mentioning how breaking compatibility over and over again will cause .NET, Longhorn, Avalon, etc., to not be adopted (or if it is, not for many many years). Because of this, developers will be confused what to do. He then offers this alternative. As he said
.NET, but the major hold back is all of our Windows 98 customers. I don't want to force them to install the .NET runtime for win98, have their machine crash, and have them blame me. I just want to write an application, and know it will still work 5 or 10 years down the road, regardless of if our customers are still running the old win 98, or the new Longhorn. The author suggests the web, but Java sounds like a better alternative to me.
Which means, suddenly, Microsoft's API doesn't matter so much. Web applications don't require Windows....and so we should make html the new API.
Web applications? Sure...but how about Java?
I would assume that when Longhorn is released with all its new changes, that Sun will still find a way to make Java applications run on it. If that's the case, why make such a fuss about Web applications when you could also develop in Java, and then not worry about what changes Microsoft makes?
As a VB 6.0 developer, I'd love to jump to
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
His critique of C++ is actually a critique of the Windows API. You can have all the advantages of memory management in C++, and even some more (managing other resources than memory by automatic variables). Modern C++ code does rarely contain "delete" statements.
I don't think so. Instead, Microsoft is trying to propagate developing of browser-based application that only run on windows.
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
Joel mainly pits the MSDN crowd vs. the Chen crowd as a struggle over 'which API is better'. The Chen crowd seems less interested about which API is better(although they are probably very interested), and more interested in protecting coders from themselves.
.NET is automating protecting coders from themselves, which is exactly what the Chen crowd wants anyway.
Joel's comparisons of MSDN and Chen camps is also divided by auto-managed vs. coder-managed memory. With newer versions of MS products, there is much less of a need for the Chen camp, because their main focus is fixing coder errors to keep apis stable with newer versions. Something that isn't important when programmers can't accidentally bog up a chunk of memory.
I would hazard a guess that memory managed code is what is the demise of the Chen crowd because
Alas this is all theoretical to me, since I'm a java guy. I guess that places me in the MSDN camp. But this is all theoretical anyway because MS is doomed to bankruptcy by the end of next week.
So by these standards, all Gates needs to do is make a nice need skin for Windows that makes it look like OS X and he can take over the world! Oh and change the name of Outlook to Entourage.
http://jayceecorder.blogspot.com
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.
So by these standards, all Gates needs to do is make a nice need skin for Windows that makes it look like OS X and he can take over the world! Oh and change the name of Outlook to Entourage.
Actually if they would have the Mac BU design the interface for pretty mcuh everything (it's not the skin, it's the way the apps behave) then I would actually not mind using Microsoft apps - even on the PC!
I don't know why you bring up taking over the world as they have already done so - no need to do anythign else there. Mission accomplished.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
as soon as your keys leave the keyboard
;)
It would be kinda hard to type on a keyboard with no keys...
>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.
Dude, why *would* I want to debug the systems' calls.
I just want it to *work*, and 99,9% of the time, it works.
It's a sick developer that tries to debug libraries that he didn't write. {unless there is some extreme (read: usually rare edge case) cases - in which case you managed to prove that you didn't do anything wrong in your code, in which case, you might have an edge. But usually, just sending a bug report and finding a work-around would do.
--
Two witches watched two watches.
Which witch watched which watch?
The main new platform that doesn't run Windows is the smart phone. They are still large and expensive, and there is still a lack of standardization. But think about the potential market; everyone who carries a phone and would like to perform some basic computing tasks (email, IM, maps/directions, contacts, etc). Right now M$ has only a small fraction of that market.
There are a variety of new form factors that may take off as well. Car-based PCs, tablets, HTPCs, etc. M$ has their fingers in all of these markets, but they don't have killer apps so they are not clear winners. There are lots of non-M$ app opportunities for developers that are willing to look beyond the PC form factor.
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.
i really dont know whether you have programmed in Python. i've been programming in python since V1.5. never had a problem with it breaking my code. Though the APIs have changeed quite a few times, the newer APIs were always backward compatible. Well, for me, transistion from apache V1 to V2 was smooth. i dont know why you complain about not able to recomplile. Maybe you should try to recompile all the modules and see for yourself.
The governments plan to slap Bill'y$ company on the hands was such a joke.
Take this garbage O$ off our damn computers and make people do a real choice ! Either the $100 billy o$ or something else. Anything but force it on us and make developers dependant on it.
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
Oh come on, and nobody has written books about Linux's internals?
BTW, that book is 12 years old, and predates the MSDN.
If you need web hosting, you could do worse than here
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 ..
This isn't news...this is simply the latest in series of advertisements thinly disguised as "editorials." So tell us, Roblimo, how much of a kickback have you gotten from Joel for the last 5 ads of Spolsky's posted on /.?
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.
My manager (on this project) is a young guy, younger than me, just promoted to the position. Thus he's eager to follow protocol. Luckily, I will not be under him for much longer, my next contract I only have one manager.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
The other interesting implication of this is that it protects Wine. MS can't simply break the Win32 API, so Wine has a fixed target.
--------
mobile porn
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.
> This old argument about Mac having no apps is very old, very tired,
> and very tiresome.
The guy is talking about the enterprise space, not some git sitting in his underroos surfing the web and using AIM.
And yes there are a buttload of line of business apps that don't run on Mac. If your business has a dependency on just one or two you probably can't migrate off of Windows unless you can find a way to bring them along. Windows emulators running on a Mac aren't anymore practical than VMWare on Linux. They can save you if you have one or two that you don't use often but still need but probably won't cut it for an app a large percentage of the userbase uses regularly.
Small ones like Timeclocks, contact managers, accounting, inventory control. Big ones like all encompasing industry specific apps that employees spend most of their day in. Things like teachers spending a bug chunk of their day in one of a couple of apps specific for schools, each district buys into one of them and everyone must run it. If it doesn't run on Mac then that district doesn't tend to have ANY macs. Same for most other professions. Nowadays cops don't use Word to write their reports, they have all encompasing apps specially designed for law enforcment and they run on Windows.
Democrat delenda est
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.
Open source developers are lead by example, the biggest being the kernel developers. They don't seem to mind breaking compatability across version releases, even minor releases. While this might be good for design/code purity, it's no good for people who happen to be using API's that break.
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...
What were you trying to do in QT that you were not able to do on NT?
autopr0n is like, down and stuff.
This sounds like it could throw off any hopes of Linux getting more market share. I know the author is framing it as a bad thing for Microsoft...but at least part of the reason people think about moving to Linux is that Windows is so rickety. I've always suspected that this is because of the need to be compatible back to DOS 1.0, and I think this pretty well proves it:
[SimCity] used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. 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. (emphasis added)
Now, I'm sure there were fairly talented people working on this....but if, as the author goes on to state, this was not an unusual practice at Microsoft, I'm frankly amazed they even got Windows to stay up for a few minutes at a time. It certainly explains the bizarre and inexplicable behavior and crashes Windows is known for.
Of course, fixing Windows wouldn't help Microsoft's reputation for hardball tactics or for overpriced licenses, but it does make it that much harder to suggest that people try an alternative.
Daniel
Hurry up and jump on the individualist bandwagon!
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.
Not once does Spolsky mention code access security. From what I have observed, Microsoft's efforts seem to be directed towards downloaded modules that run on the CLR. Rich client / web deployment. Of course the obvious problem is security. ActiveX fails in this regard since it is all or nothing; the CAS model offers much more resolution. Good for the developer and the user in theory.
The trick is to make it easy for a typical user to understand how to configure their machine to do what it should do, and nothing else.
Interesting how so many people make claims about Microsoft, yet don't seem to be very familiar with some of their key technologies. It would have been a much more interesting article if Spolsky had addressed CAS as well.
Imagine how much harder physics would be if electrons had feelings! -Feynman, maybe
Seriously..
I just wrote a LAMP application.. It worked but the interface wasn't pretty.
Part of the problem is that everyone has a browser to run application and the only consistancy across ie and netsc..Mozilla is html. Java was almost there but MS killed it in the browser.
Everyone has a webrowser.
I always thought a standard application runner program with plug-in (components) would do well. Eclipse plug in arcitectue should show the way. Jedit as well..
He's talking about the binary extension API which yes they break frequently and yes this causes tremendous pain to people distributing Python apps with binary extension modules.
> 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.
I seem to recall their final solution (hmm, interesting choice of words) was much more subtle. ... if you use non-Ford petrol in my nice Ford, I'll sometimes lock up the engine .. but illegal? Probably not unless you are a monopoly - and they weren't at that time, just aiming to be. And their aim was pretty accurate.
Windows checked to see it was running on DR-DOS and then SOMETIMES made stuff go wrong. (Memory allocation maybe?).
So people like me (I was a PC retailer at the time) ended up saying "Don't use DR-DOS. It's cheaper and mostly works really well, but doesn't seem to work quite right with Windows". This was true, but for the wrong reasons!
The question is - was this legal? It was certainly immoral
"Cats like plain crisps"
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!
Mod parent up. Not insightful, but obvious. At least it should be to all of you. *sigh*
Yes, ".pif" files actually have a purpose other than as a means of transmitting viruses.
BS.
Win32 is an easy, powerful API and MSDN is by far the best documentation I've seen on any API. I've worked on large projects including kernel-level stuff. MSDN has never led me wrong. Any outdated functions in it are clearly marked as being obsolete with a link to it's replacement.
I've never needed the API to have debug symbols. If something is wrong, fix the struct you sent to it and continue. BFD.
Visual Studio and probably the Platform SDK come with those debug system files you speak of.
-]Phreak Out[-
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
Microsoft would reduce prices because there would be legit alternatives to the pricey os.
Markets do work when theres real competition.
Software makers would then make software for the competition.
Microsoft MADE web applications stand still when they stopped developing IE. IE hasn't changed much since version 4. They added some new stuff to IE5 so that OWA would be better.
If Microsoft hadn't fucked the web browser up, web apps would probably be a lot better by now.
It's really too bad, because I agree that HTML and it's buddies aren't powerful enough to replace a lot of applications out there.
- It's not the Macs I hate. It's Digg users. -
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.
Joel's just whining because he knows he's going to have to port CityDesk and his other products to .NET soon, because customers are probably already asking about it. He's screwed by the same vendor lock-in that all other 3rd-party MS developers get blown away with. By the time his company is done with the port, MS will have thrown 3 times as many people at developing a "good enough" competing product that will ship ready for Longhorn, and Fog Creek will be just another assimilated victim.
Is it also possible that Joel's entire career and his company are centered on the last generation of MS technology, and they are about to become dinosaurs because they haven't kept up? It's very telling that he knows how expensive and rare Windows C++ programmers have become.
As for the free advertising, he's trying to convince those customers that have become trapped on the Microsoft upgrade treadmill (and are paying excessive subscription fees for the privilege) that everything is fine and dandy with the current Windows technology, and they should feel perfectly comfortable staying on 98 or NT as long as they keep buying FogCreek software and don't switch products before CityDesk is ready for Longhorn. A Longhorn Joel desperately hopes doesn't come charging through the door before his team can finish their rewrites.
Making the auto analogy is WEAK. The auto makers are actually trying to monopolize their electronic system controls but the government is telling them to stop it. Anyways ,what if there were only one type of car sold ?
Wouldn't all the parts manufacturers make parts only for that car? (little analogy there)
And i can choose what kind of tires i want on my new car. The dealer doesn't give a damn because he's not influence by fear or money like what goes on in software.
Chew on that fool.
Hahahahahahaha! :)
Hold on... HAHAHAHAHAHA!
If only that were true! If only that were true...
When getting into any serious programming task, even something small, ie. < 1k lines of code, I always end up looking through the source of some part of the API I'm using.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
There was no Market competition. Because markets are based on price and Microcrap is giving their OS practically for free when you buy an os. It's a CARTEL. The OEMs' are in on it too. Wake up man ! All the good software is made for Billy O$ because their is no real competition because they buy their way on your computer. It's ILLEGAL distortion of market. It's a bit like other countries subsidizing goods to gain entry and then raise prices later. Trick of the trade.
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. -
I haven't worked with the Win32 API for four years, but when I did I remember having to discover by trial and error such oddments as a disagreement between the function to draw an ellipse and the function to create a region to detect clicks in an ellipse as to whether the bounding box of the ellipse (specified as x, y, width, height) included the column x+width and the row y+height or not. That kind of thing should be documented, but wasn't.
Debuging into system librarys ? Librarys should be blackboxes, and you should be able to trust them.
It's a shame the MSDN sample code doesn't all work. I have distinct memories of trying not to pull my hair out while I attempted to debug the sample code for scrollpanes.
What?
No. Seriously. What the bloody hell are you talking about?
Are you saying that not using web-based applications magically makes machine compromises go away?
Unless you were distributing it directly from your application, that spyware will happily pop its ads up right in front of your shiny new "Visual C++" application.
Perhaps you should blame your admins, or your operating system vendor - but not your programming tools.
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"
Interested in helping me patent this new-fangled technology I'm working on? I call it an "emulator." It lets you "emulate" your old operating systems with their APIs and dependent applications on new operating systems with different APIs.
I think it's really going to take off.
That solution will nail all of these problems. For those folks that want to run a bit faster there's another idea of mine called the "Compatibility Subsystem."
1. Tell everyone the Win API is dead.
2. Insert advert at bottom of article.
3. ????
4. Loss!
Microsoft does not like open standards based development, e.g. the Internet and related standards, because it do not allow them to lock in users to their proprietary platforms.
Looks to me, this sentence works just fine.
Attack its weak point for massive damage!
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.
And as I said, there are still people running NT4, which obviously does not support .Net at all.
LOAD "SIG",8,1
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
compile debug code into any and every library...? Good one - you had me going there for a moment!
While in theory that may sound like a good thing, if you ever find yourself delving into the depths of the OS libraries you either either have too much free time on your hands, or you're about to create a support nightmare for someone else in the organization. Either way, not a good thing.
Jan
You've never read the QT documentation then have you?
It really is very, very good.
Though it's not Linux/Unix documentation, it is the documentation that was being compared....
Advanced users are users too!
Mozilla is susceptible to this(the ad/spyware that affects Window's TCP/IP stack or however to re-route connections).
What? My head asplode!
Can you explain this further? I've heard of apps affecting tcp/ip but this has nothing to do with mozilla unless you know something I don't.
MSDN isn't a very good site for docs.
Many listings are outdated, some are blatantly wrong. It's also not well structured, and not everything is there.
It's also very hard to understand how things actually work from the API docs, I remember reading the window handler API docs to find some things out (2 weeks ago, was trying to implement a bugfix for wine) and I had to go look the API up elsewhere.
For anything big or more complex (or if you just don't remember things too well) MSDN isn't very good.
How many developer's read through linux API's? 0.000000001% ... of linux users! Whats that, like 6 guys?
Your estimation that there are 60 million linux developers strikes me as a tad generous.
Joel focuses on only one reason for M$
dominance: backwards software compatibility.
There is another, IMHO: hardware compatibility.
When I buy a new piece of h/w, it is much
more likely to work wll out-of-the-box
with Windows than, dare I say, with Linux.
There is a number of reasons for this: (a) M$
has a huge testing organization which few
companies of open src efforts can afford, yet,
(b) since M$ alreasy has a huge installed base
OEMs are more inclined to support it by default,
(c) M$ might pull it off and coax OEMs to support
a future version of Windows, even if it is radically different. The changes in the drivers
might not be that significant.
So this is all a question of how one views
Windows: is it a bag of APIs or just a collection
of device drivers?
There are plenty of APIs under Linux too...
When you write a perfectly good driver for one version of the OS, which calls various API functions which return the right results and work fine, but then you use it on the next version and it returns a crashed machine because you now have to initialize a particular structure before you use it, it's kind of hard to track down that it's the USB code that is dead when the machine crashes registering the network interface. Not nearly so bad if you can read the API source code to see what is going on, and have a complete set of working device driver examples to cross-check against.
(this happened mainly because I didn't know there was a do-nothing-but-be-there-in-case-we-need-to initializer call in 2.4 kernels that actually did something in 2.6)
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... "
ok then, the simple addition of a session key parameter is all you need. It's really not that hard, and with SSL protecting it from being sniffed it's more than sufficient for the needs of most applications.
Advanced users are users too!
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.
I learnt my multithreading theory using Java 1.1 (by chance at university, but that's not the only place to learn). So far ALL of that knowledge has been perfectly applicable to any language I've written in (C, C++, even VB6, which supposedly doesn't have multithreading).
Yielding is basic thread behaviour and not related to any specific API or OS. If you don't know why you need to specfically yield, then you shouldn't be writing multithreaded applications. Just from your explanation, I can raise issues in basic design. You show a clear lack of understanding on how to accomplish the task. It's scary. It's unfortunate that switching OS "fixed" your problem, since you didn't understand what caused the problem in the first place.
MSDN is not there to teach you how to program properly. It's there so you know how to use the API's that MS supplies. No amount of documentation will allay a dearth of programming skills. In fact, the flexibility and high backwards-compatibility of the windows API is partly to blame for programmers like the parent giving windows a bad name. Bad programming practice gets propagated and continued because it's gotten away with.
/rant
click-clack, front and back. I'm not moving this car otherwise.
I'm curious. What app is there on Windows (and not on Macs) that really needs emulating? My impression was that people ran Windows emulators on Macs for the same reason they do on Linux -- for the gee-whiz, look I'm emulating another system -- not to do anything serious.
Because grig API's will win, hands-down.
It doesn't matter if your computer "can do HTML". Grid API's don't need HTML to function. Grid API's do actual work. That's what us programmers need computers to do. That there is a nifty gosh cool neat-o GUI involved is irrelevant.
Grid API's and X-Windows are the "API's" of the future. Who cares what O/S you use to run them?
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.
now. start talking about simcity :)
#
#\ @ ? Colonize Mars
#
See Flex. ... a familiar, standards-based programming framework and powerful set of components for creating a rich, responsive presentation tier ... Presentation and demo, sample apps, white papers. This could be the future of interactive web-based apps.
Of course, you can make exactly the same argument against switching to .NET in the first place. When you've got VB6, VC++ and MFC, Java, Perl and CPAN, and several other established technologies in the marketplace, each with a large developer base who already know their tools well, you need a compelling advantage to justify retraining all those people and rewriting all that code to use .NET instead. Given the obvious disadvantages of doing so -- it costs time and money, it's not a proven technology, it ties you into Microsoft products, etc. -- why would anyone bother, unless they needed a particular feature only available in .NET (which almost no-one does)?
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.)
First, MSDN is by far the best documentation source I have ever encountered. Not only is depth of information huge, the interface is easy to use and the community that is willing to answer your questions so large but the information is also provided in such a way that finding an answer or a code sample is easy.
Second, I don't ever want to deal with the code of an API or a Library. To me it has to be a black box that I can trust (or at least place blame on) because its not my job to debug the API. Third. Complie debug code into every library? What?
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).
Where would like me to start on your absolute weak pathetic reply ? hmm.
First of all my friend we spell 'tires' this way.
To a degree, depending on the tyres and the dealer. You probably won't find many that will sell you a car *without* tyres, however.
I am not going to waste too much time on you since you got just about everything wrong but i thought your response to the big auto companies trying to stop people from taking their cars to less expensive was pretty funny. Are you GM stockholder ?
You also get the gist of the post all wrong. I am trying to illuminute that choice is there for auto parts if you want it. We are not LOCKED into buying black model t's . We have choice. We can buy any type of tire for our cars because we aren't locked into one product. What do you think the stock price of Goodyear would be if all cars in this country had to use their 'tires'(not tyres).
I could go on and on but your a lost cause.
Yeah , the government is robbing us blind and Microsoft's a saint.
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.
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?
:) And I can imagine as my programming-skills increase, so will the percentage of the times source-digging turns out usefull. Been on Linux since '99, and I'll never switch back.. That has a lot more to do with other things than the ability for me _personally_ to view the source though..
I would rate myself as a _TOTAL_ newbie in C-programming. Just learning some of it by myself when I find time for it and get bored. But when I do program, I choose Linux/QT/C++ for the job, and even though I'm so fresh in C programming that I don't know half as much about classes, pointers and STL, as you probably do after a week if you take a C++-course, I've several times dug into the sourcecode GPL'ed software-libs I'm using hoping to sort out a "problem" i wonder about. 90% of the time it doesn't help me one bit, as the code is usually to advanced for me to understand, but the 10% of the times it actually sort out a problem for me, I get real happy
I have to agree. I find the MSDN documentation very helpful. Most of my knowledge of Windows-specific code was learned from the MSDN docs. I think they did a realy good job on the docs.
. . . but when people run GUI applications with buttons and scrollbars [in the future], it will be using the Windows API.
Ummm...that stinks. You ever use the Windows API?
I didn't do it! Unless I was supposed to do it. . . (hmm. .
it requires a huge kernel on each machine...
.. except having to whip out the electron microscope to read a header file can sometimes be a pain.
Well MAYBE you should be running OSX. It has a microkernel you know. MUCH smaller.
I like it
Funtage Factor: Purple
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?
Poor people who cannot afford to upgrade their old system.
// and TRS-80 Systems.
Non-Profit organizations who haven't had an upgrade budget since 1990. Many still run Netware 3.X and DOS 5.0 and Windows 3.1 on 386 systems.
Many schools who kept getting their budgets cut, and never have any money to upgrade their old systems. DOS/Windows systems sit next to Apple
Third world countries who get the hand-me-downs of organizations who upgraded and never found out what to do with those 286 and 386 and 486 systems, so they got shipped to third world countries via charities. Some systems jury-rigged to run on a car battery in the poorer areas.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
No, see, the thing is that this page works fine in several browsers, just specifically not in Firefox. God only knows why. I'm too lazy to try to get our gigantic HR/IT complex to fix it.
Web apps are no better, even when written to standards; sooner or later the standard will change and the web app will break. This is true even if its an open standard - things change, things break. This is universal truth.
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
Good lord yeah. Having full debug for all your interfaces is great. After having it for so long working in DOS(because in DOS you basically had to write your own I/O code anyway), I've been having some real problems adapting to the blackbox of windows libs!
It's been a long time.
People keep using Windows, and computer manufactures keep selling computer installed with Windows, because most apps run exclusively on Windows.
However, if software development becomes mostly web-based, it won't matter what OS the end-user runs, as he or she be able to run most apps on anything.
Therefore, there will be no reason to run Windows.
Now feel free to resort to your plentiful supply of Ad Hominem attacks!
If someone says he and his monkey have nothing to hide, they almost certainly do.
yeah, he is. He even bolded the key phrase to clue you in to the fact that he was joking, I guess that wasn't enough for you. Oh well, bold AND italics next time
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
Hmm, gotta agree with the parent on this one. Every time I've been unfortunate enough to need in-depth info MS stuff, their Technet has provided nothing but frustrating half-answers and overly complicated examples. Not that all open technology docs are better, but with MS's money they should be able to do better..
It would seem that Sleep(0) is a replacement for yield; it lets the next thread with the same priority run; if there are none then the original thread keeps on running. Note that this isn't mentioned by the Yield documentation.
However, my favorite example of bad documentation is InternetGetConnectedState versus InternetGetConnectedStateEx. You would never guess, from the identical nature of the very brief descriptions, that one works well, and the other also works well but in more situations, and in fact that the first one sometimes returns the wrong data.
Want a sig like mine? Join ACM's SigSig today!
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
Check out his posting history.
LOAD "SIG",8,1
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.
Slashdot _does_ compile wrong in firefox. All the time on the front page the table containing the newest news overlaps the table on the left with all the pretty links. About it compiling right in IE, I don't know.
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?
Technet is pretty ordinary, but MSDN is awesome.
Not Meta-modding due to apathy.
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 +
I still think the Linux kernel is more important. There are other browsers, they don't take that long to develop, look at KHTML.
And anyway, you actualy can push aps that look totaly native to moz using XUL. But the problem is, hardly anyone will be able to use them.
Standards are good, and the w3c is moving things forward.
autopr0n is like, down and stuff.
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.
First of all, why didn't you use your soundcard's buffer? Normally, you'd ask the soundcard to record, and poll the data every once in a while. If you needed a higher sampling frequency or something, well... you're not really using the hardware the way it's supposed to be used, and you can hardly blame the documentation for that. Buy some real data acquisition hardware.
And basically, the problem you described has nothing to do with the API. You probably would have had the same problems if you yielded or not. Yielding would not have prevented the low level file IO drivers from disabling interrupts for whatever reason. What yielding would have done was keep your program from locking up the computer. I'm not sure that you can give a process "real time" priority on Linux the same way you can in windows, but if you could it would also cause the machine to lock up just the same, if you're lacking a yield.
Again, this was a problem with the OS core, and possibly even the physical hardware (was this program run on the same machine), not the API, and definitely not the documentation.
autopr0n is like, down and stuff.
And it didn't work. Win16 had 21 timers. 20 were available for applications, the 21st was the system timer.
GetTimer gave you one of the 20, when they were used up, you ran out.
The Excel guys found out about GetSystemTimer and assumed it did something special since it gave them one more timer.
Of course it really didn't, it just made a bunch of things inside windows (like memory management) stop working.
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.
It may have been part of the trial, I don't remember. But if it was, it was a stupid part of it. API "helper" sites have delved so deep into the poking of Windows code that some of them know what's going on better than Microsoft coders themselves. A lot of whiz kids program on the Windows platform, didn't you know, and these guys love to hack as much as any Lunix user. They post their results and tools for exploiting them to websites and newsgroups...the AllApi network was what I used back when I was learning VB; it was tight.
.NET, for example, there are a lot of methods marked as "unbrowsable," so they don't show up in the API docs nor in the code complete window. In my experience, calling these methods generally leads to trouble or just doesn't work. So, aside from a few that relate to scroll wheel activity, I stay away from them. After all, I hope someday to move our projects to MONO and the fewer obscure methods and P/Invoke calls I make, the better.
There are tons of "hidden" and undocumented parts of the API, but generally they are hidden or undocumented for a reason. Some are deprecated. Some don't really work universally or have obscure side effects. Some are just so inscruitable and dangerous you should know what you're doing before you poke at them. In
If I remember, the claim was that these hidden methods made programs run faster. That's not entirely true...they may have sped up certain operations, but at the expense of reliability. Microsoft doesn't have to worry about reliability in these methods, because if something doesn't work they can just have the team in charge of that method secure their shit. That's a bit harder for the rest of us...so it's best we steer clear. I suppose it's cheating not to let us use nitros in our engines, but I'd rather keep my head gasket attached to the block, you know?
Hey freaks: now you're ju
Why not? If that 50Mb of crap allows me to program easier I'm for it. In fact we distribute our Java app with in a single Linux installer CD. OS+Java Runtime+app and there's still a lot of free space on the CD. .Net does to Windows system these days but I assume that is pretty much uninstallable.
I don't usually distribute perl scripts to windows users because they usually don't have perl, so I see your point, but for today standars 50Mb isn't a lot.
BTW, Java install in its own directory so you can have many versions in the same machine, I don't know what
"I think this line is mostly filler"
-Mike
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
First, I don't really believe that the thick-client is truly dead. Yeah, there's so many advantages to running apps via a browser (the automatic client upgrade perhaps being the most important), but there will also be an inherent requirement for thick-client apps. Games being the biggest example of this. And games will always require an OS specific API to interact with (yes, there's OpenGL, but what about sound etc etc?). For this reason, I doubt highly that the existing APIs will stop being supported.
Second point - if people with COM and C++ knowledge are getting $130000 dollars, then I am well and truly in the wrong job!
I beg to differ... The MSDN library is the best collection of programming references, examples and source that I've ever had the privilege to work with. Programming heaven = dual (or more) monitors, UltraMon, MSDN collection open in 2ndary monitor and VS.NET in main monitor. Unless I'm trying to troubleshoot obscure bugs or work with 3rd party components, I never need anything but MSDN help open. I leave it set in Index mode, filter set to .NET Framework, and if I'm working in a portion of the framework I don't know very well all I have to do is type the name of the Type or Class that I'm working with. Voila, everything I ever wanted to know about that class, complete with examples for the language I'm working in. Not only is the index easy to use, but the actual documentation is very thorough and cross-referenced very well. If I'm looking at the general info page for a DataSet, the first occurrance of the word DataTable is hyperlinked directly to the DataTable docs. In short, its just easy. I have ZERO complaints about VS.NET's help system.
I am a leaf on the wind. Watch how I soar.
Look, I've written somewhat complex projects in both Open Source and Windows. I'll take Windows any day of the week. Any time I have looked at the source of of a program, it was because either the program didn't work, or wasn't well documented. In short, because the program was half assed. I have never pined for the ability to read the source of the SQL Server JDBC driver, because I have never called a method and had it return true when it obviously didn't do anything. I suspect even if that did happen, I would not open the source to find that the entire method had been commented out by somebody who had started to refactor it, and then gave up.
Testing, documenting and repairing JDBC drivers is not what I do. I write client-server apps. I don't know a whole lot about driver configurations or socket communications, because I am more concerned with the structure of the data moving down the pipe than the structure of the pipe itself. You may want to view datapaths end to end and put debug code in the middle of a perfectly fine API call, but I'd rather concentrate on something I cared about and leave fixing the API to somebody who got paid to do eactly that.
And it's not like I'm not a connsumate do it yourselfer. I rebuild cars in my spare time. The reason I have so much spare time is that I don't have to fix the framework I'm writing on...
Hey freaks: now you're ju
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. A robust SVG implementation plus a good widget set for it should be at the top of OSS development priorities somewhere just behind a free Java.
Google confirms: Ruby is the world's most beloved programm
They need to simplify it. I'm not learning that many different technologies just to complete a "normal sized program".
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
These people are running NT4 because they have legacy applications that they need running. They tested these apps on NT4, don't want to retest on newer OS, or don't have source code, or don't have anybody who can comprehend that source code.
These people are not interested in any new application on NT4, whether .NET or not.
MSDOS: 20+ years without remote hole in the default install
I keep around a copy of Borland C++ 5.0 partly just because of the .HLP files documenting various APIs. When trying to learn about an unfamiliar API, a website (with waits between pages) just isn't as efficient as a fat-client-ish help browser. Windows help was good; 'man'+'less' is excellent, except that it doesn't store any sort of hierarchy. However, a tree-view can actually make it harder to grok a system; sooner or later I have to read something more-or-less from beginning to end to understand it.
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
If one case of bad press can kill of a company, it was never very strong to begin with. For example, Lotus' Notes, despite numerous compatibility problems across various versions of Windows, managed to stay afloat and thrive. Maybe Caldera should look into their own business model than blame competitors.
Go somewhere random
And one should not forget that Cocoa is based on the OPENStep (or however it is capitalized) API. The same one that GNUStep utilizes, minus some of Apple's new APIs. Basically, one can use the GNUStep documentation to program on Cocoa, although one might need to tweak it a bit to work on OS X.
Dude, why *would* I want to debug the systems' calls.
Perhaps for the times you follow the API docs to the letter and your app is *still* crashing unexpectedly.
Just knowing where the bug seems to be ("Hey, this code in blahlib.c looks a little suspect, maybe it's not my app that's the problem after all") is a real boon. It's more than that: it's The Way It Should Be.
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
'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
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.
Excellent point. It is an example of holding your developers to a higher standard and them then matching it. Of course, you need excellent documentation so developers know how to write safe code. MSDN libraries are often vague. This leads to making assumptions about the black boxes.
Explains the limitations quite nicely.
Xix.
"Everything is adjustable, provided you have the right tools"
Ah wait. You must be one of those old-skool programmers who has never encountered preemptive multitasking / threading before. Well, I cannot blame you - it has only been around since 1995 (Windows) or 1985 (AmigaOS) or 1975 (UNIX)...
If you find yourself calling yield() all the time, _please_ visit a programming refresher course. It is the 21st century now, and Windows has actually implemented some modern programming techniques. Your "programming by numbers" you probably picked up in the sixties no longer has any relevance.
Yes, just read Joels Sim City anecdote for examples of hidden modes in windows.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
We need an OSS clone of Flex functionality. It is insanely great.
Agreed - I've attended one promotional meeting, expecting to be cynical, and I was practically a convert within an hour. XUL looks like it could be that clone - or at least a competent competitor - but I'm still concerned that without one clear direction certain large companies will muscle in. Heck, I can see even Macromedia losing this one. Prove me wrong, World, prove me wrong!
This is where the serious fun begins.
APIs are supposed to be a black box. But in the real world, if you're involved in a large and complex project, it can really help if you actually know what's going on inside.
For example, I was heavily involved in writing a replacement GINA for a retail cash register project. We actually had a US$40K support contract with Microsoft in case we ran into problems when writing our GINA. (The GINA is the bit loaded by Winlogon.exe which asks for your user id/password and manages how authentication gets done to Windows NT and anything else you need to authenticate with). At the time, the GINA documentation was diabolical. We did run into problems - and called Microsoft. They couldn't answer us either, because it seems like the guy who wrote this stuff had left and MS didn't have any better information than us.
We ended up doing a significant reverse-engineering job on the MSGINA to find out what we were supposed to be setting and how to set it. If we had the source code, we could have done it in a fifth of the time and wouldn't have needed an expensive (and useless) support contract.
As for the rest of the Win32 API - it is quite well documented in the MSDN online (but for stdlib/stdio functions, I find the OpenBSD manpages more useful and informative, even if I'm using stdio/stdlib on Windows). The documentation may be perfectly adequate, but the API itself feels congealed rather than designed, and that's without even getting into the GUI side of things.
Oolite: Elite-like game. For Mac, Linux and Windows
How do you mean added documentation of methods with code completion? Do you mean in a similar way to eclipse (when you're browsing the list of methods it shows you a snippet from the javadoc?)
> 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.
This is not bad documenting. This is bad design. Notice the difference. Even though interfaces are mess they are still documented well.
MSDN API docs:
- Are up-to-date
- Are consistent
- Have working search capability (even offline if you a local MSDN copy)
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.
Microsoft have been moving away heavily from the windows API in recent time and have been pushing .NET heavily, because essentially .NET is the replacement for the windows API but on a bigger scale. .NET is (possibly) going to be used by every single program that runs under every single version of windows. MS want it to be used for Client apps, web apps, mobile phone apps, server apps, scripts, hardware.. EVERYTHING.
.NET is the windows API, just now it's the "everything MS" API. By using .Net, you are using microsoft, and hence windows. No java for the masses(or unix for that matter)
.NET or start abusing the patent system to muscle Mono out. .NET is the weakest link in the MS lockin, as now Mono may allow windows apps to work flawlessly on Unix. But .Net is the keystone in the new MS API lockin. I hardly see how MS WON'T try to crush Mono!
Essentially
Question is what effect will mono have on all this.
I'm a pessimistic type so I'll say that if mono ever becomes a threat to the MS lock in, then MS will radically alter
This is kind of a pity, because, to be honest, I'm sick of memory leaks.
May the Maths Be with you!
My exception safety is -fno-exceptions.
If I paid for a 3rd party lib, I'd be justified in insisting I can treat it like a black box and I should be able to trust it.
I don't think Cocoa can be called a new API. Cocoa is OpenStep (with a few extensions) which was developed many years ago by NeXT and Sun, based on the NeXTStep APIs.
It has a form of garbage collection
Not entirely. Cocoa uses reference counting which is simpler and faster than true garbage collection, but requires objects to be manually released. To make this easier for programmers, it includes an autorelease pool class. If an object is sent an autorelease message then it is destroyed when the autorelease pool is destroyed. This allows you to return objects from functions with an effective reference count of 0, which can then have their reference count increased by the receiving function, if they need to keep it (or not if they don't). To make things even easier, the AppKit message loop creates an autorelease pool at the start of the event loop and the destroys it at the end.
While this may sound a lot like garbage collection, it has one very important difference:
It is deterministic
In a Cocoa app, you know exactly when memory is going to be freed (it's either when you free it explicitly, or at the end of the event loop for autoreleased objects). Your program will never be interrupted for the garbage collector to run.
I am TheRaven on Soylent News
interact with the server _without_ reloading the page
I wrote a very short Java Applet back in 1998 to take a request from JavaScript and put the result into a field on a FORM. It was written using Java1.1 so MSIE could understand it. It allowed JavaScript to:
1. Create URL that will return information.
2. Ask Java Applet to get information.
3. Parse information.
4. Redraw page.
(We also had a CORBA version that let JavaScript handle Domino objects. It could retrieve data and even update records on the server without refreshing the webpage.)
The good part is that we had a standard method for JavaScript to talk to the server. Just tell the Applet the URL and the name of the field to put the data, then look at the data. It was easy to write the server side programs that returned the information. (Too easy. We found ourselves returning JavaScript to call with eval() rather than returning the generically-formatted information that could be reused by other applications.)
The difficult part was forcing the browser to notice sections of the page changed. Changing a graphic was easy. Changing options for a pull-down was easy. Changing options for radio-buttons and checkboxes was difficult. Changing "static" text on the page was almost impossible.
We used it for its strengths. Choose a department from one pull-down. A second pull-down would allow choice of the employees in that department, and would be updated without a full page refresh.
The entire point of this technology was to save bandwidth and a little time. We could update the employee list without updating the entire page. A few years later, we realized that bandwidth was inexpensive and the complexity of the technology cost more than just refreshing the page all the time. We redirected the effort into writing programs that would write concise HTML to keep the bandwidth usage low.
The only reason that any of this is necessary is that MS embraced the browser and halted all progress. They deliberately skipped the "extend" phase. Today we develop for Mozilla (using very old HTML standards), test against MSIE5.5 and MSIE6.0, and then fix all the stuff MS broke.
I spend my life entertaining my brain.
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).
Flash is OK for simple apps...for more complex things Java is still a better alternative. Java Web Start and other similar things make web deployment of full-fledged desktop apps easy.
Java is getting to be very good...sadly it's taken about five years longer than originally advertised. However, better late than never! :-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Yah. Indeed, MS documentation is quite good. I vaguely remember the online documentation not being as good some 3 or 4 years ago, but maybe I was just lookin' at the wrong places. I dunno.
:)
It should be noted, however, that there ARE non-working examples in the documentation. I may not be much of a programmer, but I have managed to stumble upon a couple of examples with bugs.
Not everything can be perfect. But programming heaven should be bug-free, wouldn't you say?
I am a speak english. Do you not? - Saroto
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
I'm seeing these probs with .9 as well - for some reason the "Games" section seems particularly vulnerable.
Que voy a hacerle yo
Si me gusta el whisky sin soda
Dude, try Cocoa with XCode. Wow...
Shame on Google.
Linux... the only OS I know that makes me type "man mount"
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
I called Cocoa new because it is relatively new. Yes, most of the API is carried over from NextStep and all of its incarnations but there is a lot of new functionality in the Cocoa API. It's a young and still developing API basically.
Reference counting is a form of garbage collection. It's just a more simplistic approach to garbage collection than some of the other methods. There are some advantages, which you have mentioned, to reference counting and there are some disadvantages to it also, such as objects with cyclical references not getting freed. Overall reference counting does work well and it is fairly unobtrusive so it's a positive addition to Cocoa.
Sapere aude!
Face it, NT is not a real-time OS
Neither is any desktop OS. Nonetheless, in my experience it has had far better multimedia performance than, say, Linux, which was hardly suitable at all until quite recently.
and so there is no guarantee that random drivers won't hang the system for arbitrary periods of time.
If they do, they are crap drivers, or drivers catering unsuccessfully to crap hardware. Any OS is at the mercy of this kind of crap.
Doesn't Win32 have some sort of async I/O or select()?
Yes, and yes. Look up "overlapped io" and "completion ports".
I agree wholeheartedly. We *should* be able to trust third party libraries... We *should* have rocket-cars, and jet-packs, and take vacations on the moon, too, but they never gave us that. As well as bug-free libraries.
Maybe we should do a project for an automatic code verifier (not validator, verifier), which proves code symbolic-mathematically to be bug-free. Then we could run the system libraries through it and finally declare them to work exactly as they should, no? Of course, who guarantees that the verifier doesn't have a bug? Do we run the verifier through itself? What if the bug makes it think it doesn't have any bugs when it does? It's madness, I tell you.
So, as a guy who rides a bike...
What is the one case where a manual car is better than an automatic?
Que voy a hacerle yo
Si me gusta el whisky sin soda
You can get KDE for Solaris, but you have to be comfortable with compiling it from source, or trust someone else's packages.
*** Where are we going? And what's with this handbasket?
You've put very little substance into your claim. How is he "bigoted"? It's not like he's always saying "Microsoft rulez, *nix users suck". His experiences at Microsoft undoubtedly taught him a lot, and why shouldn't he leverage that experience?
/. but you don't HAVE to become part of the rabble.
You seem like a smart person who would otherwise be worth listening to. Why not go inform yourself about Joel before spouting stuff like this? If you're going to oppose his position on various issues, then at least do it intelligently. This may be
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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
You're nuts. The API docs suck big time. Having come from Java backwards into MSVC++ and MSDN, I can say unqualifiedly that I wish I could use Java on every project. Time after time after time, I have a problem, I wade into the mess that is MSDN, only to turn up thousands of irrelevant documents. Occasionally, you get lucky and find just what you want, but mostly you're stuck doing keyword searches, hope against hope that someone has had the same problem you're having and solved it. God forbid you want to work with something that has a generic name, such as open or read. You'll get stuff from VB, SQL, IIS. The search engine is so weak-- if it had exclude capability, AND/OR logic, etc, it might be slightly improved. But the real issue is that the documentation has grown up over years in layers, rather than being based on a consistent design that is rigidly adhered to. The sooner I can get my group over onto Posix, the happier I'll be.
Hmmm, seems to me your troll score is 3 for 3. Good thing you posted anonymously.
1) Is your comment related at all to the text, or are you just ranting in general?
2) He's not exaggerating, and you're off topic, fueling yet another rant.
3) No, actually, the best websites are where the tools of the Web are used in a way consistent with their original intent.
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.
Did I even *imply* that Slolaris beats Linux? Pull-eeze!
If you're *generous* towards Solaris, you'll say it's about on par with Linux... but I'm not that generous.
Hell, I even once worked for Sun, and I'm going to just say it- for just about any job that you'd use Solaris for, I'd use Linux instead- and save a boatload of cash doing so. Outside of ( as you point out ) a few server administration packages and specialized Sparc-only apps, I'm not sure why you'd buy a Sun these days, there are definitely better, cheaper *nix options ( ok, mainly Linux, *BSD and OS X ), and clearly lots of folks think the same way I do on this, or Sun wouldn't be hurting so badly.
That's fine if you're dealing with well documented code, but suppose you're using a 3rd party library which doesn't have very good API documentation. In practice being able to look inside the code lets you work out *how* you're meant to use the interface.
I would consider it a failure on my part if someone had to look inside my code to write client code for it, but that doesn't mean I'm not going to look inside someone else's if it's poorly documented.
Developers, Developers, Developers, Developers
Why do I get an image of a ranting sweaty Balmer in my head when I read this?
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.
It's the new MacOS X stuff that makes Carbon so much easier than Classic, particularly with respect to user-interface handling.
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.
You haven't tried to do any serious filesystem manipulation in Classic or Carbon, have you? Royal pain in the arse, between the need to juggle FSSpecs, FSRefs, file paths, and other ways of referring to files, and the very weak concept of a directory hierarchy that MacOS has.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
I'd be interested in seeing which examples you're speaking of... I personally haven't run into any that don't work.
I am a leaf on the wind. Watch how I soar.
Stop it. Seriously, Flash is not the answer. The web is supposed to be browser, server, OS, & platform independant. It is, it really is. Honest. If we want to talk about a better way of doing things, don't suggest Flash as the answer.
Using flash screws many people - those who are vision impaired, those who are browsing from a CLI, those who attempting to interface programatically with your site, those with low-bandwidth connections, and (here's a big one) those using mobile devices, such as PDA's and cell phones.
Furthermore, Flash is a proprietary format. It is not open & it is not in the best interest of the web. Flash is the fat cousin of IE-only hacks. In other words, you're not helping the situation. Push for open standards and standards-compliant browsers. You're no better than Microsoft hacking their old broken API's to death if you use Flash.
Seriously, why in the world would you want to build a site in Flash? If using XHTML, CSS, etc. will not give you a rich enough interface, then write the damn thing in Java.
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.
Flash is an open standard. Adobe makes a flash creating product and the open source ming makes flash too. That being said they both suck compared to macromedia's flash authoring.
Furthermore, it's better than XHTML and any rich content ideas the W3C has proposed. It's years ahead and here now. I'm all for collaborative development but it's quite frankly failed as far as rich content and the W3 go. Flash is here, now, openly documented and free to implement.
Flash is accessible too, I'm still learning it, but I see tons of accessibility features built in.
Do you know anything about flash? It seems that you know nothing about it.
Photos.
Mozilla DOES NOT need thier own scripting. That's for the W3C to decide. If we end up with Moz-only sites, then how does that improve our situation??? Hell, I love Mozilla, won't shut the hell up about it, use both the big suite and Firebird/Thunderbird, and even I don't want to see that happen.
I don't care for Safari or Konqueror, but I respect my friends who do enough not to want to lock them out. Not coding to standards and people adding application-specific CRAP to websites is what got us in the mess in the first place.
Webmail is a bad example, actually, because its an example of an application where webapps work adequately for most purposes. However, I've never seen a good web word processor, much less webCAD, and I never expect to.
Users will use what they are given, which is why they don't know the difference between 98 and XP, why they use webmail, and why they don't care about elegance. MS is smart enough to realize this, which is why they've been doing their best to avoid breaking compatibility, even at the expense of higher complexity and lower stability. A user will put up with an occasional crash, but break Word and he'll hate you forever.
That said, I still use pine for my email.
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
Flash is a fucking animation engine. They bolted on accessibility. Great. What's my problem, you ask? Look at the Flash Accessibility FAQ:
Hey, Windows users can have accessibility! Awesome! Fuck you very much Macromedia.
The fact is that Flash is a plugin. Plugins are meant to supplement a site, not replace it. If your site depends on using a plugin - any plugin - you are building your house on sand & locking people out.
This all goes to the larger point. A solution not built on standards that are well written, extensible, and open to all is no solution at all. You want to brag about how your site runs on all browsers at platforms? Don't say it's because you're using Flash, because it will be a lie.
Not to metion we still have yet to talk about low bandwidth, small devices, those who aren't browsing graphically.
The "Inside Macintosh" books (q.v. by area) have to be some of the best API documentation ever written. It's too bad Apple couldn't keep up that level of quality.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
You're right, and I tried to say that in the first place but you managed to say it a lot better.
Then we got sidetracked.
- It's not the Macs I hate. It's Digg users. -
If Apple tried to use their monopoly control of the platform in the ways that Microsoft does, people would talk about breaking them up too. Apple has usually played well with companies that produce add-ons (software or hardware) and they're generally liked.
"Check out his posting history."
My posting history should say "he makes smart ass remarks" more heavily than "he is in love with every single thing Microsoft does".
"Derp de derp."
How many developer's read through linux API's? 0.000000001% ... of linux users! Whats that, like 6 guys?
It is handy to be able to step into libc (with symbols) when debugging. Probably most Linux developers DON'T examine the whole API, but if it doesn't seem to be working as documented, at least there's an option to look at that particular function.
Just having libraries that aren't stgripped can be quite useful.
That's one of the advantages of it. As a matter of fact, it's replacing Win32 in Longhorn.
They're pretty much the same. Cocoa is the new API.
Try Cocoa sometime. People wonder how they developed things without it.
...is between being "a major player", and owning the game.
OS X is a pseudo-BSD system...remember?
I know people who run KDE and some ported Linux apps under OS X. OS X has the market of Apple apps available to it as well as an entire UNIX application base.
...just code web apps, or apps based on Open Source, and *know* they will work in the future?
Yep, 'cause those old gnome 1.0apps and legacy KDE apps all compile just great without me having to bloat my system with obsoleted libraries.
Oh wait. A lot of them don't. Hmmm.
People said the Windows API was hard, and while a C Windows API program may take up a couple of pages, it is not hard to go through it line by line and explain what every last function call and function argument is supposed to do. With COM and ActiveX, I have essentially given up on that for the reason you just outlined.
On the other hand, I believe Borland has "wizards" that make COM/ActiveX development tolerable while I don't know how anyone uses VS C++ to do any of this. Both C++ Builder and Delphi use this tool call the Type Library Editor for maintaining the IDL and automatically keeping a wrapper class in synch with that IDL. Yes, the Type Library Editor is buggy and quirky and using it to specify interfaces compared to real coding is like having sex by remote control.
But there is one thing the Type Library Editor can do that I have yet to figure out with, say, VS C++ and the ATL wizards: the Microsoft tools lets me add stuff, but it doesn't seem to let me remove stuff. The only way it seems to remove stuff is to edit sources, and instead of 2 files (.h and .cpp) there seem to be about 5 different files (.h, .cpp, idl, rc, and something else for good measure), and I have never been able to remove a method from an interface without corrupting everything beyond starting over again.
Having gotten over the learning curve, the Type Library Editor allows me to not only produce COM and ActiveX controls, it allows me to edit and tinker with their interfaces. Interfaces are supposed to be immutable, but being able to modify interfaces during development is important to me.
With that level of tool support, I am inclined to hang on to COM/ActiveX development instead of migrating to .NET. All kinds of software from VB 6 to Matlab to even .NET can host ActiveX components -- when is Matlab going to host a .NET component? When is IE going to host a client-side .NET component? By sticking with COM/ActiveX, I have a much broader set of consumers of software components.
Oh, you can use .NET/C# to develop COM/ActiveX components -- haven't tried it.
ASP documentation isn't as organized as you see it. Once you do that the function specficitacion or the teory of the objetcs, just lacks about it. Also: PHP is as fast as do a php.net/whatdoyouwant ant thats it :)
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
ASP documentation isn't as organized as you see it. Once you do that the function specficitacion or the teory of the objetcs, just lacks about it. Also: PHP is as fast as do a php.net/whatdoyouwant ant thats it :)
Um, OK. That doesn't make a lot of sense to me. I think you're trying to say the ASP documentation isn't very good and that PHP is really fast?
Fine, you're welcome to that opinion. I use ASP.NET myself. The ASP.NET docs are fine and it's properly compiled rather than interpreted so I have no problems with the performance.
Microsoft dropped legacy support in Longhorn, no more running DOS and Windows code. You'll have to buy all new programs or use an emulator. I've seen the beta, and this is the case. This is the only way Microsoft can provide a way to avoid getting infected with the current viruses and spyware and adware.
Also with it no longer being Windows, they will claim it has nothing to do with the DOJ case against them.
New OS, New API, New GUI, new everything. 100% controlled by MS.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
RTFA and see if Longhorn has legacy support. Unless they added it in since that article was written, I doubt it.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
If application X can crash the Operating System, isn't something fundamentally wrong with the OS? Does the MS Distorion Field prevent them from seeing this?
.NET anyone?
.NET was designed from within the Distortion Field, so all you ISV's out there - be ready to re-write your code yet again in 10 years.
Design flaws beget ugly patches, ugly patches beget uglier patches, and eventually, you'll have to rip it all up and start over...
Of course,
- spin
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse