Slashdot Mirror

• '.. Their next job is to sell me the new version. And the features that 99.999% of the customers NEED is the backwards compatibility. ...'

There's no entry for gullible in my dictionary. And my refrigerator wasn't running. Thank you young man. You've just saved me a good deal of spoilage.

Microsoft has been seeing increased resistance from developers over stuff like Avalon.

"No, I _don't_ want to throw away my WinForms stuff to develop for Avalon, which may be easier and more powerful to use, but will restrict my target market to those running Longhorn," is the general vibe.

By making Avalon available for Windows XP (presumably as some sort of runtime), Microsoft makes developing against Avalon a more realistic proposition.

As for all the users in here asking "why the hell would I want Avalon?" - some application developer will choose to use Avalon, and if you want that application, you'll want Avalon.

I doubt they do. I remember reading an article loosely related to this awhile back; someone here had linked to it. The article was a Joel on Software piece about how Microsoft lost the API war, and it talked about, among other things, how web applications were a bane to Microsoft because they could be run without windows. As he put it: "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."

Collaborative PowerPoints? Um... Ok. Isn't that what source code control systems are for, even for binaries? Pure vaporware, baby.

...But it's already a reality. For example, I have been working on a project for BMW that is just that: a freak hybrid between Powerpoint and CVS. It's implemented in Flash on the client side, and backed up with a Linux machine running Apache, PHP and PostgreSQL.

Images and documents are stored on a central webserver. All administrative interaction is mediated through the flash application. The editing environment is the playback environment. All relevant historical assets and information are immediately available. And, one of the design requirements was that the whole thing needed to run on Macs, so I don't see anything from Microsoft edging it out anytime soon. The project is like a poster child for Joel Spolsky's recent "How Microsoft Lost The API War" article.

As quite a few people have started realising, the web is the platform of the future. There will always be room for locally run 3d graphics apps/games, but the web just makes sense for business apps.

Joel on Software has a good article here.

Since the win32 API is meaning less and less, now is open sources chance to win the API wars :) I'd love to see a mozilla based explorer.exe replacement. Easily customised, easy to lock down for sysadmins, open source, cross platform. It would make migrating from windows to linux be painless, as the interface would be the same. You could transition incrementally. If you still need office, run windows for a while with the replacement shell. Then, as people get comfortable with the new environment, move them to wine or open office.

I can think of heaps of reasons to switch to a shell i've got full control of. Security being a major one. XUL apps too; you could quickly whip up an app in XUL + javascript which would do all your database transactions. What companies don't have a database of some sort?

Joel Spolsky (of Joel On Software) published his views on software pricing a little while ago too. Worth a look to see how someone else thinks about the topic.

is the fact that MS has made soft errors in their operating system as the article seems to indicate?

I thought it might have been the cost of the effort to polishing their releases (I seem to remember heaps of language releases on MSDN) so I guess it's not for lack of unicode support for language.

But cost of checking might not be worth it. Something 80%-90% accurate (chew me out if you can show examples to disprove this ratio) seems to be ok for MS.

here's an obilgatory JOS article on unicode that lots of MS developers would be aware of ...Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

is the fact that MS has made soft errors in their operating system as the article seems to indicate?

I thought it might have been the cost of the effort to polishing their releases (I seem to remember heaps of language releases on MSDN) so I guess it's not for lack of unicode support for language.

But cost of checking might not be worth it. Something 80%-90% accurate (chew me out if you can show examples to disprove this ratio) seems to be ok for MS.

here's an obilgatory JOS article on unicode that lots of MS developers would be aware of ...Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

SimCity for Windows 3.x had a bug in its handling of memory that caused it to crash on Windows 95. Microsoft had to add code to test if SimCity was running and handle it appropriately; if they had not done so, the crash would not have been Microsoft's fault-- the bug wasn't.

MS has been moving away from their mantra of absolute reverse compatability. That's said, since that's one thing at which the used to be very good. Still, if SP2 uncovered a bug in someone else's software, that's not SP2's fault; you have to know whose bug it was.

SimCity for Windows 3.x had a bug in its handling of memory that caused it to crash on Windows 95. Microsoft had to add code to test if SimCity was running and handle it appropriately; if they had not done so, the crash would not have been Microsoft's fault-- the bug wasn't.

MS has been moving away from their mantra of absolute reverse compatability. That's said, since that's one thing at which the used to be very good. Still, if SP2 uncovered a bug in someone else's software, that's not SP2's fault; you have to know whose bug it was.

You're attacking a strawman.

Sometimes I want to know, as I'm writing my code, exactly what low-level operations will occur when that code gets run. My code, not the libraries I'm calling. Java doesn't even let me do that.

It's a pretty rare "sometimes", though -- I don't do so much low-level work these days. As far as the why of the matter, I think someone wrote a paper about leaky abstractions that explains it pretty well.

It's not a straw man because the original post said it differently. The key word present now that was not originally present: sometimes. You even admit that it's very rare that one would want to know what low-level operations are involved when executing code, and that's very damaging to your original claim that certain people need to avoid back boxes altogether. In actuality, such people would skip Java, Python, and C and opt for assembly code.

The thing is, one could take that "my code" comment to the extreme and say that it is no longer "my code" when it is run through a compiler that might optimize it, or, to take it even further, it is no longer "my code" when it is not written in zeros and ones. You're dealing with abstraction wherever you turn, so let's not pretend that intepreters are so different from compilers.

That "leaky abstractions" paper you're referring to was very weak. It was written by Joel (of "Joel on software") and it was just about the worst material of his that I'd ever read. He even went so far as to claim that the performance of an abstraction can make it leaky, which rendered the definition of "leaky abstraction" pointless, because the implementation of an abstraction would have to run in no time at all to avoid being leaky. No implementations run in no time at all, so every abstraction is leaky, so the definition of "leaky" is worthless because it adds no new meaning to the term abstraction. It was a paper that appeals to programmers who simply don't like abstractions and want to stick to lower-level languages and in-house libraries.

He writes the kind of insightful programmer's stuff, a la Joel on Software.

You'd like to think so, but as of yet there's no way for the kernel to pop up a XWindows Dialog Box saying "There is no disk in /dev/fd0".

I should damn well hope not. It will be a user-space application that is responsible for doing whatever you want to do with the floppy, what's wrong with that application notifying the user?

As far as scenarios where the kernel actually needs to communicate with a GUI, you are wrong, there is a way, it's called D-Bus.

Plus the usual KDE/Gnome issues about network filesystems in the File Open/Save dialogs, sound servers, clipboard issues, file types etc.

Obviously I can't disagree with you here because you are so vague you aren't making any point at all, just trying to spread a vague sense of uneasiness.

Linux Desktop stuff is still in the leaky abstraction phase.

Stop being so clueless. The essay that coined the phrase "leaky abstraction" notes that "All non-trivial abstractions, to some degree, are leaky." In fact, the whole point of establishing that phrase was to point this fact out.

And no, IE7 won't be a Transformer.

Microsoft does not sell IE. They gain no direct profit from people's use of it, so you have to wonder what their motive is here. Let's assume that "good" and "evil" are subjective and emotive words that have no relevance to this discussion, ok?

If you read Joel Spolsky's API war article, some perspective may be gained. Microsoft wishes only to discourage Web developers from moving away from the IE platform. If developers move away, Microsoft no longer has control over web development, and can no longer keep new technologies on the fringe.

This is bad news for a company with plans to move to network applications. If a platform for network applications exists outside of Microsoft's control, it will be much harder to profit from. Thus, Microsoft's interest is served here by retaining that 90%+ browser market share, to prevent the adoption of new technologies not under MS control.

Because the internet navigators are the api of the future, if you make the navigator, you control the future of programming in the in computing... There is no new program with a web interface out there, is better that dealing with each of the api's in all the platforms out there... http://www.joelonsoftware.com/articles/APIWar.html

"IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon. Yes, vastly superior to Win32, I admit it. But not an upgrade: a break with the past."

MS fights as hell to keep the status quo. They stopped development of the IE, because they do not want computer to be web. They want computer to be MS Windows.

You may read http://www.joelonsoftware.com/articles/APIWar.html

But it could be seen even before. Even before the www, I recall that we dreamed about computer environment where you could move across the world, but just to aproach nearest terminal, log in, and there you are, your desktop, files and everything is there. We used to have Novell/Win3.11 network in our comp lab in university. OK, it was not across the world, but it worked fine. You could log whenever you wanted, and everything was there - PC's acted just like terminals, from your perspective. Next version, with NT network, never worked OK. Some programs could not be installed only on server (to be honest nonMS ones)... so the idea went away. Diskless stations had to be replaced with stations with HDDs...(actually, even in Novel/3.11 they were not diskless, but disks contained no real data). If you needed Corel, you had to pick exactly that station with Corel installed.

Then www appeared, but they never liked the idea. If they allow IE to act like complete PC - meaning that you can do text processing in it (for example) - they would replace OS with browser. They would replace their golden hen (desktop OS) with something they cannot control so tightly, and with something that other coulc probably copy. Why would they change current state of affairs? Thick client is what made them rich, and they will try to follow that model as much as they can. They don't like gmail, ebay and everything else ferature rich but web-based - since it is excactly the path what they do not like to happen.

User interface design is one of my pet-peeves about computers these days (be it Mac OS, Windows, or Linxu--I use all three regularly). Every where I look I see bad design that doesn't need to exist. And it annoys the crap out of me that people won't put forth the extra effort to get it right. So here's a little rant on the subject.

As a computer science graduate student, I recently took a course entitled "human-computer interface." This course (at Eastern Washington University) was not really about how to make a GUI "look good" but how to make an interface (from something as simple as the knobs for the burners on your stove to a modern web browser) actually usable. One of the things I learned is that no matter how good programmers like myself think they are, they really don't know much about designing interfaces. There's an intense amount of work involved with it, and a lot of it is outside the fields most programmers typically work in (in particular, there's quite a bit of psychology involved).

There's a lot more to the human-computer interface than just how the interface appears visually. You also have to consider things like the mappings between intended actions and actual results, how easy it is for a user to determine how to perform an action, how easy it is for a user to determine the state of the system, how easy it is for a user to determine the results of their actions, and so much more.

One of the things I see all the time is interfaces that are designed for programmers and other techie types. Just because I know how to write my own Linux kernel modules doesn't mean the typical user of Program X does, so don't make the program require that knowledge unless absolutely necessary. Design for the lowest common denominator, not the greatest. If you make a program easy to use for the average user, then it will be easier for everyone to use, even yourself. (Remember: think of the average computer user (or person in general) and remember that half of the population base is dumber than that average person .)

There are two books I think most people should check out for more information on design and :

The Design of Everyday Things, Donald A. Norman, ISBN: 0-465-06710-7. Goes into much detail on design in general and why it is important, the process of good design, and offers great advice for improving designs and the design process.

User Interface Design for Programmers, Joel Spolsky, ISBN: 1-893115-94-1. Practical user interface design advice for programmers, for those too lazy to read Norman's book and learn more on your own (shame on those of you who would only read this book!). Also check out his blog "Joel on Software" at http://www.joelonsoftware.com/.

Finally, I'd just like to say that regardless of what most Slashdotters think of Apple, they tend to get the interface on their products right because they realize the importance of good design and are willing to spend the extra money, effort, and time to get it right. And this is a large part of the reason their products consistently win design awards and sell very well despite their market share. Look at the iPod for example, and compare it to any of the other hard drive-based MP3 players out there. Are any of them as easy to use? Don't think so. Are any of them as pleasing to look at? Again, didn't think so. Does it have the richest feature set out there (I'm looking at you, Ogg Vorbis supporters)? No, but it's still the largest in market share by a large margin. Because it's easy to use and you don't feel like beating it to a small pile of broken circuit boards at the end of the day because it was too frustrating to use. (No, Apple is not perfect and they do design bad interfaces and products, but they seem to be head and shoulders above most everyone else in their industry.)

Oh, and let me

I learned programming in C++ (using vi, too), and I did not like the word-y blocks VB uses either at first. But I've since grown to like it. Here's why:

You know what kind of control statment you're ending: If/End If, Do/Next. With {} you have to keep track of that yourself.

As much as I like the power of C++, they did some truly stupid things when they designed the language. How could they not put a native string type in there? Now there's a million string class implmentations (including the STL's, which isn't always compatible with other stuff) and no consistency.

Since I'm a consultant, I don't get to dictate the language for clients. But I'm not sure I would want to use a .NET language if I HAD the choice because of an article I read on Joel on Software. It appears from what Joel says that the .NET platform isn't going to be around for very long, while the VB6 platform is extremely tried, tested, and it works.

I'll easily admit that VB's OO features are far weaker than C++'s, but the ease of developing UI's,the error handling, and the IDE (particularly the debugger) are absolutely spectacular. If there's a language that's got similar capabilities for *nix, I'd love to know about it. That's Linux's strength and weakness of course - that there's no universal UI and no universal API associated with the OS (kernel) itself.

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.

I completely agree. A console, first and foremost is a platform. Therefore, it has to appeal to developers, not just consumers. Microsoft was able to buy a lot of developers the first time around. They have taken huge losses as a result. But, the way things stand now, the X-Box is in good shape. Games that are released on all three consoles tend to look and play the best on the X-Box. Microsoft is also the first with a truly successful online gaming service. As long as the market remains: PS2, X-Box, Gamecube. I believe the X-Box will slowly chip away at the other two console's marketshare. People will eventually buy an X-Box along with their currently existing PS2 or Gamecube. If a game comes out on all three, which most do, people will pick up the X-Box version.

However, the X-Box 2 is going to flop in a major way if it can't play X-Box games. There will not be enough games on the X-Box 2 to please the market. They are literally throwing away their whole entire investment in creating the X-Box platform by developing an incompatible X-Box 2. If that isn't bad enough, the money they spent on the X-Box will now compete with their new X-Box 2 for developers.

The X-Box 2 needs to compliment the X-Box. It needs to do everything the X-Box did only better so the two platforms don't compete for developers and consumers. There is a couple things they could do graphically to silently improve existing X-Box titles (better texture-filtering/using npatches). But compatiblity is king. There is no way the X-Box 2 will be able to stand on it's own against the juggernaut that is the playstation game library.

If they have licensing problems with nVidia, so be it. Pay what you have to make it work and mark it up to a learning experience. Then make sure it doesn't happen again.

However, I doubt it will happen. Microsoft's leads are way too willing to throw away their hard won place in the market. Ballmer is a bean-counter without the vision to stop them. Instead, he'll just do his little monkey dance about how good the X-Box 2 is going to be. It is really sad, because the X-Box was a really good console. And Microsoft could continue to do cool things with the line. Too bad they are going to piss it away.

For those needing evidence, I state that I will not buy a X-Box 2 if it is not X-Box compatible. I am in the X-Box's core demographic. I will buy a PS3 if it is compatible with PS2/PS1 games. I don't feel I'm alone. Microsoft is going to lose developers, and they are going to lose consumers like me, and that is why they are going to lose the next-generation console wars.

Both are excellent reading for those interested in the art (science?) of good UI/usability design.

The whole book is good, you should read it from the start.

I found it a good read here

PHP is dead. Long live PHP!

Now that I have that out of my system. Does anyone know if PHP5 Unicode is any better than PHP4?

Admittedly I've done about 10 total minutes of PHP coding in my entire life, but I do follow it as closely as possible when I'm not thinking about Perl. I always got the impression the Unicode working in PHP4 was a little lacking compared to the latter versions of Perl.

For example: PHP does have limited unicode support and Joel on Software.

Our desktops still are essentially the same as the 1984 Macintosh. PDAs still haven't caught up with the Newton. Computers are still dumb.

Computer technology is evolving. Quickly.

Biological evolution took billions of years to get to today. Have you ever read up on Carl Sagan's Cosmic Calendar? If you were to compress the known history of the universe into a single calendar year, all of written human history would comprise the last 15 seconds on December 31!

Whether you're talking about technology or biology, you can't evolve anything too quickly, or you throw out all the accumulated wisdom in the current design. That's why birth defects and substantial changes in genetics are rare - evolve too quickly and the mortality rate climbs towards insolvency.

The QWERTY keyboard is with us, perhaps for centuries to come, even though there are "better" alternatives. But these "better" alternatives cost alot more TODAY to develop and implement than continuing with the QWERTY. So if you "know how to type", you're using a QWERTY.

To change to another keyboard, you have to throw out all the accumulated wisdom associated with QWERTY keyboards - all the trained office workers, all the existing equipment in place right now, the typing tutor software, the toys, cell phones, PDAs, etc.

And why? The QWERTY is "good enough", so we invest our resources elsewhere.

Here's another example: Joel on Software - Things You Should Never Do. In this work, Joel claims that re-writing your nest egg software is the kiss of death for a software company, for the simple fact that in even a cruddy, poorly cobbled software, there's often many man-years of embedded wisdom in there - bugs fixed, design issues resolved, special cases handled, etc.

You simply can't rebuild anything significant from scratch without tremendous cost. That's why our very sophisticated human cerebral brains are built upon the much simpler mammalian brain, which is in turn built upon the very simple lizard brain inside our heads. It's very literally three concentric sections of brain, with the lizard brain in the middle, the mamallian brain wrapped around that, and the cerebral cortex packed on around the outside!

The biological cost of rebuilding our brains to factor out the now much-antiquated lizard brain functions is simply too high to be viable, so it's never happened, and the lizard brain is simply "infrastructure" for higher development.

Look at the history of cities. You'll see the exact same pattern there... Example? Los Angeles has spent 75 years developing around the automobile, and their recent construction of subways have been extremely expensive (300 MILLION DOLLARS PER MILE) and the residual effects of the subway on local business has driven many to bankruptcy.

It's been very costly, very slow, and cost overruns are the norm.

So, when I hear somebody talk about making major changes to existing infrastructure, it's hard for me NOT to dismiss them, no matter their credentials. You simply *don't* change critical infrastructure of any kind without serious review and contemplation, and even then, you have to assume that it'd be 10x as costly and painful as you can imagine.

clicky clicky

MS took backwards compatibility for developers very seriously. You could take a program written for the Windows 3.0 and recompile it for Windows XP and it would just work (most of the time). With Win32, it was binary compatible, too. Similarly, a VB 1.0 program would work in VB 6. MS took this very seriously, and it is a big reason why there has never been a shortage of programs (or developers) for MS platforms.

With the .NET platform and VB .NET (and even more so with Longhorn and Avalon), MS is trying to migrate developers to a completely new platform with no backwards compatibility. This is, of course, to address very real shortcomings with the old Windows platform compared with Java and web-applications. But it's a huge break with the past, the first such risky move since the original move from DOS to Windows.

Joel Spolsky covers this in more depth on his weblog: How Microsoft Lost the API War.

First, Read this article.

The point of the article is that Microsoft has abandon its longstanding practice of supporting backwards compatability. .Net renders com programming obsolete. (Sure, you can mix the two, but try hiring a developer who knows the ins and outs of class factory instanciation. There aren't many.) And before everything could fully convert to .net, we get Avalon, which partially obsoletes .net.

It appears Microsoft is trying to protect their desktop monopoly with further developer lock-in. Mono is trying to prevent this, but eventually, for this strategy to work, Microsoft is going to have to have some portion of their system lock-in developers.

Joel makes the point that much of the cutting edge of application development is taking place not on desktop systems, but web enabled servers. Gmail is a perfect example, but I'm sure we can all think of some others. More and more, hot new software is not being sold as shrink-wrapped products with a Windows approved logo, but being deployed as a web service with some other revenue model (sales or ads, usually).

And, of course, gmail runs just as well on a mac, linux or windows box.

But html cannot be used for everything. I/O sucks, forms are very limited in data validation, transactions are stateless, etc. What I see this as addressing is the beginning of a new, expanded API from which Microsoft's biggest competitors can continue to draw developer mindshare away from Win32 applications.

This is in reaction to Microsoft's continued revision of their API set to make development easier. Consider that .net's managed code makes Win32 programming much easier and secure - no buffer overruns, no memory leaks, etc. All this with speeds close enough to Win32 and C as not to really matter.

This is a preemptive move on the part of the web developers. If a new, open standard can be developed that allows most business applications to move to an intranet model, they can continue the brain drain from Windows. This will lead to more and more killer apps appearing on systems other than Windows. Killer apps that run on any system. This is what Microsoft fears.

Of course, this has all been tried before. Netscape once planned to crush Microsoft in exactly this format. This was the heart of why the first browser war was fought. Netscape failed because they were offering one vendor's lock-in for another.

The second browser war is being fought for exactly the same reason. This time, Netscape's side has added a new twist to their main weapon - open source. If they abandon lock-in, they may be able to strip off enough mindshare to stagnate Microsoft. If so, then the operating system is no longer an asset. If the ability to use the newest, hottest software on the planet is not the correct operating system, but a standars compatable browser, Microsoft looses.

That, more than desktop widgets, is what is happening here.

Neat. Thanks for the link. I got interested in ObjC when I first installed windowmaker a couple of years ago. I think the message syntax (method invocation) looked too alien for me at the time but now after trying to learn a couple of more languages I can get past that now. Functional languages are really interesting to use too. OCaml's use of cutting edge programming concepts: type inference; pattern-matching; robust types (allowing functions to return multiple values via tuples) makes for one of the most concise natively-compiled languages I've ever seen.

But in regards to your second thought, I wasn't trying to imply that C++ was the end all be all language (...oh good lord no). Just that for TrollTech, at time when they started, it was the right tool for the job. Just as the MOC is the right tool for the job to implement a very slick object communication mechanism. I just becomes very hard to watch other programmers pine for a "elegant" replacement where all of the faculties are provided by the language with an ideal API meanwhile forgetting that any complex system, such as a GUI toolkit, is going to develop quirks and work-arounds over time.

This is why TrollTech should be commended because they are making highly stable tools (moc turns out to be very easy to get along with) that work around the limitations of the language without being too intrusive to the language (think MFC message maps, glib, and GTK upcast macros here) and they have always strived for source, and even binary, compatability when reworking large portions of their API because they realize the value of just extending a tried and true codebase (something Joel Spolsky enlightened all of us to with this peice).

Good times.

This problem was compounded by an artificial limiter on backwards compatablility. Namely, the fact that most buisnesses replaced their desktop computers every two to four years. Bundling deals meant those new computers came with the new shrinkwrapped products. Curiously, many of these newer products defaulted to file formats that older versions couldn't read.

As more machines were replaced, the business began to get in the uncomfortable position of supporting two formats, the old an the new. When it reached the breaking point, an order would be given to convert.

However, while computers continue to get faster at about the same pace as always, software has fallen behind. Developers may crave more horsepower, but just what is it about word processing that demands a 2 GHz processor? Couple this with the number of machines replaced to prepare for y2k and you have the current weak desktop computer market.

Without new hardware coming in the doors regularly, older machines, and their software packages, are suddenly lasting longer. This makes it much harder for Microsoft to force upgrades to a new version.

If I read the situation correctly, Microsoft is toying with a simultaneous conversion to the service model with a forced upgrade due to new APIs. After all, if Windows 2K doesn't suppor the latest .foo framework that you must have to run Microsoft Bar(tm), you'll just have to upgrade, won't you?

I think you may have that backwards. Moving off windows is too big a step for most people to make at once. On the other hand moving to firefox is a step towards moving off windows. Why? Because it is cross platform, it means one less app that is unfamiliar if people move to a new OS.

Firfox is bad news for Microsoft. There are no two ways about it.

I'm interested to see what Microsoft is going to do. There are under pressure from a lot of directions at the moment:
1. Browser wars have restarted. What is interesting about this is they have restarted with so little warning.
2. Security. MS is trying to address this with XP SP2, but this is still a huge issue for MS.
3. Longhorn. This is a huge issue for a number of reasons, first off the delay in shipping it. Secondly the fact that it is a rewrite, new API, *lots* of new code == lots of new problems. Thirdly due to performance considerations (this may be less of an issue). The interesting thing about Longhorn is that there are parallels (Netscape)

The next 6 months or so are going to be very interesting. If MS isn't careful they could lose signifigant market share, which I for one won't be crying about.

And so they produce garbage like IE zones controlling ActiveX security and weak patches to ADO.Streams for years now.

i love Joel on Software but i think he is missing the obvious solution:
M$ will go for a clean break with the past with Avalon/Longhorn, and provide backwards compatibility the same way Classic works on OS X. the old programs never know they run on top of a completely new OS. at least that's what they should be doing. they did, after all, buy Virtual PC.

that solution would cleanly reconcile the preservationists (who want to be backwards compatible with 1983 DOS) and the modernists with .NET and Avalon.

I used to agree with you, then I read "How Microsoft Lost the API War". The thing that really struck me was that fundamentals components of .NET will be abandonned with Avalon . This is why I now think that open source .net is a masterstroke. MS is basically asking/forcing their developer base to adopt a now open sourced, platform neutral enviornment. In a few years, they're going to break the whole model and say that to play, you have to retrain and recode major portions of your work. At that point, it becomes more cost effective to stick with mature solutions that work, not play catchup to the latest and greatest. "Look, Shinny Things" is not a better business strategy than compatibility and reuse.

Now if they started a new team like they have with .NET and get an outsider to lead it, then I'd believe it.

Now if they started a new team like they have with .NET and get an outsider to lead it, then I'd believe it.

We have not announced pricing and licensing and will not do so until next calendar year

Damnit...sorry about the lack of hyperlinks

http://www.joelonsoftware.com/articles/APIWar.html

http://members.microsoft.com/partner/competency/is vcomp/empower/default.aspx

This offer is for companies only however...so my original reply is probably not valid as I doubt you could register one company twice in this program.

"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."

http://www.joelonsoftware.com/articles/APIWar.html

And I guess in part this also agrees with what you said since by having proprietary items they are trying to ensure items work on Windows only.

FYI: The Longhorn API will support the old win32 API.

I'm certainly (no longer) an expert on things Microsoft, but there was this article on Slashdot linking to this article by someone who at least has a name I recognize. I don't believe everything I read on the Intarweb, and it's a long read, but the guy seems to be saying that Longhorn will break backwards compatability and says it at length. Got anything more authoritative?

Of course you could have linked his article talking about the office design

I think Joel's setup was pretty much perfect.

If you could create your perfect office how would it work?

I'm a fan of Joel Spolsky's writings (see Joel on Software), so I was fascinated to read about the office space he has designed at his company, Fog Creek Software.

I like what he's built here because the emphasis is not just on catering to developers, but providing an atmosphere where great coding can thrive.

After reading through this article about the fall of the Win32 API, I think Google may be doing something a bit more clever than simply 'giving back'.

The article discusses how the plethora of APIs Microsoft is shipping and uncertainty of just when the APIs will be on real hardware have caused new development to move to the web (for example, building a new email client). It also mentions there are several drawbacks to web programming, but the author expects them to be overcome soon, further sapping the appeal of the Win32 API.

Perhaps this is exactly Google's strategy. How better to further enhance the desireability of web programming versus desktop programming than by demonstraiting in source how to perform some really compelling features? How many developers will take these techniques and use them at the heart of new killer apps; apps that run on any web browser rather than locked to a specific API?

Google may be giving a small bit away, but the potential gains in mindshare among developers may be much, much greater than the loss of this already paid for source code. Further, if the code in question relies on a particular technology, protocol or standard they are well versed in, they have succeeded in enticing developers to play in their sandbox.

Quite clever, really.

Joel Spolsky recently wrote an *excellent* article on this very topic called How Microsoft Lost the API War. Like almost everything he writes, it's well worth a read.

One of his major points is how MS is breaking with it's past, from when backwards compatibility was a /big/ thing. He cites VB.NET and Longhorn as two examples, but it looks like Microsoft just gave him another big one.

-Bill

Well, one thing that keeps people (developers..) with windows is the API. If they hadn't seen any windows code, then MS would lose their advantage. See this.

Oh, and for rewriting it from scratch, see this.

Well, one thing that keeps people (developers..) with windows is the API. If they hadn't seen any windows code, then MS would lose their advantage. See this.

Oh, and for rewriting it from scratch, see this.

And you can open an Office 97 document in Office XP, dumbass.