Joel On Microsoft's API Mistakes 690
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
Re:Why it has to die (Score:1, Interesting)
.NET & C# (Score:2, Interesting)
Damn, I miss Smalltalk
GroupShares.com [groupshares.com]
This was not an unusual case (Score:5, Interesting)
Re:Why it has to die (Score:5, Interesting)
I don't agree (Score:5, Interesting)
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.)
Joel Might Be Wrong (Score:4, Interesting)
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 [blogspot.com]
This is how Microsoft fixes bugs (Score:2, Interesting)
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.
Re:Repeating my comment on OSNews... (Score:5, Interesting)
Yes, obviously, but then, _how come_ there are no standard protocols that fix this? Many people perceive the need. Users feel the difference between web apps and native apps (Joel is right, for existing apps, users don't care. Now try writing a usable word processor using HTTP and HTML...).
I once posted a message to some mailing list requesting support for sockets in JavaScript. With that, you could interact with the server _without_ reloading the page, have the server push events to you, rather than periodically poll for them, speak any protocol from a web app, etc. The reply I got was that it wasn't going to happen, citing security issues and bloat. Yeah, that's why Java applets do have socket support, and Java is of course a prime example of elegant, light-weight software. *cough* *cough*
As for lack of standardization; we have CORBA which is very standardized and very universal. If you want something lighter, there is RPC. ZeroInstall provides a nice way to "run" native software off the web. Java has gotten pretty usable. WHERE ARE THE GOOD WEB HOSTED APPS?!?
What about flash. (Score:3, Interesting)
Uhh... what? (Score:2, Interesting)
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.
Re:.NET & C# (Score:5, Interesting)
I program in Objective-C, using Cocoa libs under Mac OS X. ;-)
What's amazing is that Java combined with the hack-y nature of the Win32 APIs finally forced Microsoft to create something that's still not as good as NeXTStep was 15 years ago, and probably isn't ( yet ) as good as Java ( it's just optimized for it's single target platform ).
I'll leave for those who care to debate Java vs .NET. For me, that's a debate that is pointless unless .NET somehow becomes cross-platform, at which point I expect Bill Gates to burst into flames.
Re:Why it has to die (Score:4, Interesting)
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.
Re:Why it has to die (Score:5, Interesting)
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
Re:Repeating my comment on OSNews... (Score:5, Interesting)
Security settings should force you to communicate only with your originating server and port. Hence a Socket is way "too free" for that.
And if the user is using a proxy, then what? How can you access your original server? You have to go through the Proxy.
No, a real way would be to have access to an object a bit like java.net.HttpURLConnection. Such an object would be trivial to write, with two features in mind:
1. It should use the browser's connections settings (proxies, etc...) and caching capabilities.
2. It should enforce that the URLs accessed are issued from the same server/port as the script requesting it.
Socket is way too low level.
Rose Glasses (Score:5, Interesting)
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.
Re:Joel Might Be Wrong (Score:2, Interesting)
But that is always the case. You can't run Windows apps on DOS machines either. What matters is that you can run DOS programs on Longhorn. This way Microsoft won't lose its customers.
As long as Microsoft keeps their users the developers will follow.
----
Your Boss Might Be A Muppet [blogspot.com]
It's about the APPs silly. . . (Score:3, Interesting)
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.
Slam M$ + Praise Linux = Karma Whore (Score:3, Interesting)
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.
Re:Hard to be a Mac user? (Score:5, Interesting)
It seems [apple.com] there may be a few [apple.com] applications [apple.com] for Mac OS X as well. More importantly, Objective-C and Cocoa are easy enough that more OS X programs are being made every day. Developers indeed. If the Linux community could get some standardizationg together and throw some effort behind GNUStep... sigh... that would be nice, too, but Apple's more likely to release OS X for Intel ( i.e. don't hold your breath ). GNUStep is getting closer, though...
If it weren't for guys like Joel with their "if it's not Microsoft it's just weird" attitude and willingness to spread MS FUD, users would have a lot more options, and more developers would be able to make a better living slinging more code for more platforms, rather than being forced to eat Microsoft's swill.
Re:Repeating my comment on OSNews... (Score:3, Interesting)
Re:Half Wrong. (Score:3, Interesting)
Do you think cars should have to be sold without tyres as well ?
Re:.NET & C# (Score:3, Interesting)
That's so high on the list of improbable turns of events, I really did laugh when I read it. Part of Sun's dilema right now is how to convince folks to run Solaris and buy a Sun rather than buy OS X and a G5 PowerMac.
I really doubt McNealy would highlight Apple's competitive advantage *while* paying licening fees ( as if Jobs would license his OS's look-and-feel ! ). Again, we'd see OS X for Intel first.
Linux not really a threat as far as Sun is concerned- their desktop is comprable if not better, and they sell Linux distros anyway if you can't be convinced to buy their hardware... ( gee, do you wonder why Steve doesn't think that'll work for Apple? Oh, that's right, it didn't work for NeXT... )
Embrace and extend! (Score:3, Interesting)
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.
Re:This was not an unusual case (Score:4, Interesting)
Here is a link concerning the situation in case any readers are not familiar: Caldera: MS Cheated in DOS War [wired.com]
Re:This was not an unusual case (Score:3, Interesting)
Bizzare, yes. Undocumented, no. (Score:5, Interesting)
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.
Why the browser will NOT be the future of app dev (Score:5, Interesting)
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!
Re:Joel Might Be Wrong (Score:3, Interesting)
A great read nonetheless. I found the Raymond Chen links and such extremely interesting. I've always wondered about the some of the curious/antiquated parts of the win32 api.
grain of truth (Score:2, Interesting)
The only thing you can count on is change.
Re:Can you be more spesific? (Score:3, Interesting)
A program that reads data from a sound card mic input, does some processing on this data, and writes the result to disk. Again. And again, in a loop. In NT I couldn't find any way to do this without losing some data. I found that the write to disk operation seemed to disable hardware interrupts for as long as 100 milliseconds at a time, and I would lose input buffers. If I set the priority of my input routine to "real time", then the entire machine (mouse, keyboard, etc) would stop responding. Someone told me I'm really dumb, because I didn't put a "yield" in my read input loop, but the "comprehensive" documentation in MSDN didn't quite cover that point. Since the same algorithm that didn't work in MFC/NT4 worked perfectly in Qt/Linux, only adapted to the different API, I realized that I didn't need the MSDN documentation at all...
Re:Why the browser will NOT be the future of app d (Score:1, Interesting)
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.
Re:As a (former) die hard web developer (Score:5, Interesting)
On the spot, AC.
What I wished was that we went back to POSIX -- well, not quite, actually some garbage-collected functional stuff running on POSIX -- and the X Window System.
And I think that could come to pass. With GNU/Linux spreading, Mac OS X holding its share and getting X servers (both Apple's gratis and Fink's free ones), and Cygwin/X getting easier and easier to install, we could soon have X servers everywhere, so that we could run applications from POSIX servers whenever HTTP didn't suffice.
A trend may be starting with public Telecenters [sp.gov.br] and other LTSP or otherwise host-and-terminals GNU/Linux implementations.
Then we could go back to improving the host (GNU Hurd, functional programming, relational databases) and the terminals (Cairo, I/O) and stop worrying about the API du jour.
Security implications of kludged patches? (Score:5, Interesting)
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.
Re:Why it has to die (Score:3, Interesting)
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.
Device drivers and testing (Score:1, Interesting)
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?
Re:Web as a the savior (Score:3, Interesting)
I must be using a different HTML than you are.
<input type=hidden name=foo value=bar>
Works fine, in my experience. It's not the only way to pass around state, but it's the simplest.
I have gotten frustrated by the need to wrap it in a <form>, though. It'd be handy if hidden variables would also get passed back with plain hyperlinks.
But I'd agree that HTML wasn't designed to be the programming language that a lot of people want. It was designed as text markup, after all. Trying to make HTML into a programming language is sorta like trying to make a bicycle carry heavy freight. Saying it's stupid isn't critticising the tool; it's criticising the people who insist on using the wrong tool for the job.
But there's a serious barrier to making web pages into programs. Nobody with a grain of sense will allow programs to be downloaded from random sites and run automatically. Until this changes, things that make HTML into code will simply be turned off by anyone with the slightest understanding of why we have problems with malware and adware.
ASP.NET is brilliant? (Score:3, Interesting)
Re:I do agree, and not with you. (Score:3, Interesting)
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 was going just fine until...; (Score:5, Interesting)
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?
Re:Hard to be a Mac user? (Score:3, Interesting)
Unless you're telling me Mac users also use Google less frequently (Pretty much a standard activity for ANY web-surfing computer these days), I don't buy it. Google's stats are about as close to you can get to which OS is used in what percentage by Web-surfing computers...
Re:Good idea (Score:5, Interesting)
Wait; this is completely contrary to my experience. I worked on Lotus 1-2-3 for Mac, which was targeted at Mac OS 6 & 7 (7 was new when we shipped 1-2-3). 1-2-3 was written in C (actually Symantec's C++ subset) with some inline 68K assembly, and did some grotesque trap patching.
That 1-2-3 68K code runs under OS X on a PowerPC G5. Reliably. I still maintain spreadsheets that I update weekly.
As Joel's article pointed out, Microsoft has engaged in some amazing bend-over-backwards hackery to maintain backward compatibility. This echoes a Wall Street Journal article written about Windows NT development where Dave Cutler bragged about the number of programmers tasked with adding code to make certain "high profile" Windows 3.x apps run under NT.
By contrast, Apple, in the early releases of Mac OS, showed enough foresight to tell developers how to keep their code future-proof, and developers who adhered to those protocols (which were not all that restrictive) wrote apps that still run today, under an entirely new OS on an entirely different CPU.
Re:Repeating my comment on OSNews... (Score:4, Interesting)
Yeah, supporting Netscape 4.7 would probably make me murderous, too. JavaScript as a language is actually really nice. It's object-oriented, but the type system is very flexible (they're aren't really any classes, per se, they're all "prototypes"), functions are objects, so you can pass them around, and closures are possible, which gives you lots of power. I agree that differences between browser implementations can cause some grief, but we've been able to abstract away most of those differences, so there isn't a single line of code in the entire code base that makes any reference to the browser string. Of course, this means that if you try to use the latest version of Konqueror that I tried, things just blow up, because we assume your browser can handle our app, and that version of Konq can't, but we're developing for a captive audience, and we can almost dictate browser versions, so that's been a bit of a saving grace. One nice thing is that all the developers work on GNU/Linux, so it has to work in Moz for us to be able to develop, but the users all use IE, so it has to work there for us to sell it. This dichotomy (did I use that right?) has dictated that our framework must be cross-browser. If our code was littered with
I think we would have instigated a mass suicide a long time ago, but since we have almost no code like that, and since all such code is hidden in the equivalent of "library code", making new screens, or new functionality is pretty straight forward. I find the productivity to be pretty high, and the library has only been in development since August of 2003. Of course, I'm biased since I was one of the pilot developers, but the opinions of my coworkers seem to at least align with mine, even if they're not quite as enthusiastic.Ian
Good/Bad competition (Score:4, Interesting)
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.
Re:Prophecy (Score:2, Interesting)
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.
I don't think HTML is the future (Score:3, Interesting)
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!
I will mock their API's. (Score:3, Interesting)
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.
---------
Re:Repeating my comment on OSNews... (Score:4, Interesting)
I suppose it's just Murphy's law. There's two ways for programmers to interpret the version number on .so objects, so naturally they choose the disasterous way.
Re:ASP.NET is brilliant? (Score:2, Interesting)
I fully expected it to do really well in the Intranet environment due its great productivity in simply getting a site up and running. But the Web Controls that ship and the whole layout paradigm MS has gone with, I find horribly lacking.
I use VB.NET all the time for app development, but I cannot bring myself to go through the HASSLE of using ASP.NET. I'm sticking with PHP for now.
Has anyone had any better results than the parent poster and I? Possibly by writing all of your own Web Controls (I've thought about it, but that seemed to be overkill)?
Re:Repeating my comment on OSNews... (Score:2, Interesting)
The HT in HTTP and HTML stand for Hyper Text you know. The web is a document reading system. It's good at that. You can create customised documents on demand and you can link to other documents. You can customise and link the documents to customise the information you display.
If the website developers have a clue then you can view it (or feel it or hear it) on a wide variety of devices. You can make the information appear as you want it to appear. Once you start adding in buttons and widgets and frames and windows you lose that freedom. Granted, few web developers or those paying them have a clue (nor do many slashdotters - I just searched the source for this page and found lots of italics but absolutely no emphasis - but then I'm guilty of that myself sometimes too), but you can hardly blame the web for that. Blame the developers.
If you want a networked interactive application with a flashy GUI then don't use the web. That's not what it's for. That's not what it was designed for and it's not very good at it.
If you want to make information available to as wide a range of people possible then do use the web. That's what it was designed for and it's very good at it (if you do it right). You can organise the information you find using your client and change the way it is displayed (or you should be able to). You can make your client integrate the information provided with your system however you want, because the information is (or should be) distinct from the presentation.
Most people just want to get information out there, be it a comment on APIs for other geeks to read or the price of the MK17 Whizzbangs they are selling. You should keep the information separate from the presentation. That's what the ML in HTML is - it's Markup Language.
If the kind of interface you want is, for example, to be able to arrange the view of a store's pricelist and stock information with the flexibility you get with, say, a good GUI database frontend then a dedicated Flash, Java etc. app is the wrong solution. They've already come up with the right solution. XML is the right solution. Provide a GUI for convenience, fine, but don't tie the information to the GUI.
Re:This was not an unusual case (Score:3, Interesting)
Re:Why it has to die (Score:3, Interesting)
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.
Re:Why it has to die (Score:2, Interesting)
"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
J2EE, portlets, .NET etc. (Score:3, Interesting)
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.
Re:Hard to be a Mac user? (Score:4, Interesting)
MS Project and Visio. I need those day in, day out, and they're not available. Neither are apps that give me the same functionality. Let alone file format compatibility (yes I know it's MS fault). But the few alternatives I looked at were crashy, had an arcane user interface (neither proper Cocoa nor copied from the originals, just wierd), and simply lacking in functionality. Not that I would think that Project or Visio are the best possible apps in their space; they're just as sucky as most MS apps.
If you use computers professionally, and you need to work with people outside your own organization, then using a Mac is harder. Many problems are soluble, but there are problems to be solved.
But I agree with Joel's outlook: many apps will eventually move to the Web, and as Mozilla and WebKit/KHTML improve, all these troubles will disappear. Who knows, maybe Mac OS X Java support might push Java far enough to make it a viable desktop platform...
Re:Repeating my comment on OSNews... (Score:4, Interesting)
Some of the replies I have received in this thread show that XUL-capable browsers have already achieved a fearsome ability to present rich user interfaces. This means that MSIE not only lacks the usability features that other browsers provide, but also the base that some developers use for their applications. If Mozilla and web developers push hard enough, they might cause a revolution that forces users to upgrade to better browsers, and MSIE into compliance with XUL, rather than the rest of the world into compliance with Microsoft's XAML.
Re:HTML's lack of features? No. (Score:3, Interesting)
Re:Microsoft needs change, otherwise it will die. (Score:3, Interesting)
For instance, I frequently use my 5 year old version of Photoshop, but see no need to upgrade. Nothing Adobe have added since then has tempted me to upgrade - and the price is also a major disincentive. So what is Longhorn going to offer me I don't already have? In fact, they seem to be saying I need to replace all my software, so why upgrade!
Apple already made this mistake with OSX, and had to reimplement OS9 to keep their user base happy. I'm sure Microsoft will end up back-pedalling and reimplementing Win32 into Longhorn.
Re:Rose Glasses (Score:4, Interesting)
Huh? HTML is a fantasy? J2EE servers are a fantasy? How about reusable C++ code? I would say every time a cross-platform technology reaches maturity, people jump on it like crazy. I am not sure what's the current maturity of
Re:Hard to be a Mac user? (Score:2, Interesting)
That being said, I think even Apple zealots would concede that the 97% Windowsfigure is solid for corporate/business desktops. Your friends are an extreme minority.
A more interesting stat would be for Mac-only type sites, like MacNN or MacRumors, and see how many Windows Browsers hit those sites... we might
get an idea of how many Mac people are using Windows to view the web.