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

Comments

Why it has to die

[Ckwop]

I have a little different opinion to the article. 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" - .NET is the halfway house..

It's open and documented such that developers feel comfortable using it and feel like they're getting a powerful suite. It's closed enough such that Microsoft can maintain an effective monopoly on the framework
because projects like Mono will always be playing catch-up to some extent.

One thing that Microsoft hope doesn't happen is Mono becoming the defacto standard and not the MS framework.
That patent warchest of theirs is probably set aside for that particularly eventuality.

Simon.

Re:Why it has to die

[Anonymous Coward]

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!

Re:Why it has to die

[Anonymous Coward]

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.

Re:Why it has to die

[Tranzig]

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.

Re:Why it has to die

[Carnildo]

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.

Re:Why it has to die

[Anonymous Coward]

compared to what exactly?

they are impossible to read.

Examples:

+ finding documentation on ASP vs finding documentation on PHP

+ finding documentation on VB.NET vs finding documentation on python

Re:Why it has to die

[jon3k]

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!

Re:Why it has to die

[tolan-b]

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?

Re:Why it has to die

[tcopeland]

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

Re:Why it has to die

[mcgroarty]

When I was developing for Windows platform, I never needed any documentation other than MSDN.

Then you only worked on small projects, or you had a lot of tolerance for wrong and outdated documentation.

I wonder how many Linux developers looked at the sources of the APIs they use. I have never did such a thing.

That's because you couldn't.

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

[mangu]

Microsoft Developer Network has comprehensive documentation about the Microsoft APIs.

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.

Re:Why it has to die

[Nasarius]

When I was developing for Windows platform, I never needed any documentation other than MSDN.

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.
And I have to say I refuse to use .Net for the same reason I won't use Java for anything serious: it requires you to install a huge VM on each machine.

Re:Why it has to die

[Anonymous Coward]

Microsoft doesn't even tell you about some APIs.. Like the API which automatically resizes columns in ListView controls to fit the cotents, Why?!

But they do cover most APIs and it's not really essential to know these undocumented ones, so I'm not too bothered really.

Re:Why it has to die

[Malc]

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

Re:Why it has to die

[RupW]

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.

Re:Why it has to die

[Anonymous Coward]

What?? The Microsoft APIs have about 50 times the documentation, of, say, the X-Windows APIs. And are infinitely cleaner and easier to use.
They did a fairly commendable job of balancing power vs. ease of use, as well. A bit too much towards the power side, tho.
Besides, I would -much- rather have a really well documented set of APIs, than 30mb of pure c source code and no good API docs (X-Windows), anyday.
The only thing not well documented are the NT kernel APIs. The driver development documentation is very sparse, there are many exported functions from ntdll/ntoskrnl that don't even have explanations for them. But this hardly matters to 99% of programmers.

Re:Why it has to die

[NanoGator]

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

Re:Why it has to die

[Anonymous Coward]

Comprehensive up to a point. In fact, not comprehensive at all. People have sold books, profitting from Microsoft's incomplete documentation.

Oh, come on. People have sold more ridiculous books than that.

You have a public API you don't change. You implement this in system libraries. These libraries need to talk to the kernel directly. They do this through a private API. Everything on the private API is exposed through the public API, so it's of no interest to anyone. Except weenie authors and people who buy their books.

What's next - mangu publishes: "Linux: Direct kernel calls for all the l33t kids!" ?

Re:Why it has to die

[Anonymous Coward]

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. ... and Rubini's "Linux Device Drivers".

You were writing a device driver? Then that's where you went wrong. The documentation for that isn't in the MSDN, it's bundled with the DDK.

You weren't trying to write a device driver without the DDK, were you?

Re:Why it has to die

[ameoba]

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.

Re:Why it has to die

[Anonymous Coward]

So what about GetSystemTimer that wasn't documented yet used by Office?

Re:Why it has to die

[Anonymous Coward]

The reason for the death of the API is probably GNU/Linux.

Not at all. The Win32 API was designed in a different era, for client machines that didn't have to worry too much about security, and with compatibility with 16-bit Windows a big issue. Even without competition, it was destined to be replaced at some point.

Unix' API grew up in a world much like that of today, so it didn't need to evolve as much. Even so, I'd say it's more an issue of "it hasn't been updated" rather than "it didn't need to be updated." How would you go about changing the Unix API if you found an area where it was rough around the edges?

(and don't poke fun at Microsoft's docs or somebody'll whip out BSD man pages.)

Re:Why it has to die

[Anonymous Coward]

I have never did such a thing.

spoken like a true microsoft developer...

Re:Why it has to die

[Anonymous Coward]

You've obviously never worked with win32.

Uh, no, I've worked with it for years.

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.

Huh? Those calls are pretty much a one-to-one mapping to opendir, readdir, stat, etc. which you'd have to use on POSIX.

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

Again, huh? The raw windows messaging model is simple enough and, if anything, works better compiled as 32-bit. MFC, at its core, is a simple object-oriented framework on top of the native windows message system. There's nothing hard or broken about it.

Re:Why it has to die

[Anonymous Coward]

So what about GetSystemTimer that wasn't documented yet used by Office?

I hadn't heard of that. Neither, as it happens, has google - there are like six hits for it. I don't believe you.

If you meant GetSystemTime then that is documented. But it doesn't gain you anything over time.h's gmtime().

Re:Why it has to die

[Ayende Rahien]

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

Re:Why it has to die

[callipygian-showsyst]

.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

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.

Re:Why it has to die

[man_of_mr_e]

Oh come on, and nobody has written books about Linux's internals?

BTW, that book is 12 years old, and predates the MSDN.

Re:Why it has to die

[TheRealSlimShady]

A closed set of poorly documented APIS
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.

Re:Why it has to die

[Anonymous Coward]

I think you just proved his point.

Re:Why it has to die

[frdmfghtr]

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

Re:Why it has to die

[IamTheRealMike]

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.

Re:Why it has to die

[Nasarius]

Microsoft made their API easy to use

You are joking, right?

Re:Why it has to die

[postmanpat78]

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

Re:Why it has to die

[docwhat]

> 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!

Re:Why it has to die

[ed1park]

Mod parent up. Not insightful, but obvious. At least it should be to all of you. *sigh*

Re:Why it has to die

[PhrostyMcByte]

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.

Re:Why it has to die

[Trepalium]

Because it was for a really old version of excel (for Windows 3.x). GetSystemTimer was a win16 API call, along with SetSystemTimer, KillSystemTimer and a handful of other APIs. This was covered in the book, "Undocumented Windows", and is where the 'common knowledge' about Microsoft using undocumented APIs in Office came from. I won't comment on whether Microsoft has become better at it or not, but I will say that Microsoft Office is often the bringer of new APIs to Windows even today.

Re:Why it has to die

[TrancePhreak]

Visual Studio and probably the Platform SDK come with those debug system files you speak of.

Re:Why it has to die

[Ender Ryan]

API's are a black box: you pass them values, they return some.

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.

Re:Why it has to die

[Anonymous Coward]

Your an idiot. Get off your high horse and realize that Linux/Unix documentation is no better. In fact, is a piece of shit written for nerds and dickheads to saviour in complexity, rather than get the job done.

Re:Why it has to die

[Bluelive]

Debuging into system librarys ? Librarys should be blackboxes, and you should be able to trust them.

Re:Why it has to die

[pjt33]

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.

Re:Why it has to die

[Graff]

Of those APIs, Win32 was the easiest to use and had the best documentation. Carbon came in second, with Classic a very distant third.

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.

Re:Why it has to die

[aled]

Yeah, that's why I don't use any OS for anything serious: it requires a huge kernel on each machine...

Re:Why it has to die

[Anonymous Brave Guy]

compared to what exactly?

they are impossible to read.

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.

Re:Why it has to die

[mangu]

The documentation for that isn't in the MSDN, it's bundled with the DDK.

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.

Re:Why it has to die

[fader]

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.

Re:Why it has to die

[Why2K]

Having to look at the source code is bad for at least two reasons:

1. It's an excuse for providing poor documentation
   
2. Peeking at the source code is a great way to make your application dependant on details of the implementation rather than the interface

Re:Why it has to die

[Nasarius]

*sigh* When you're selling software to businesses, you CANNOT expect them to install 50+MB of .Net crap in addition to your software on each and every computer. .Net is NOT installed by default, even on XP.

And as I said, there are still people running NT4, which obviously does not support .Net at all.

Re:Why it has to die

[mabinogi]

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

Re:Why it has to die

[teval]

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.

Re:Why it has to die

[Feztaa]

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.

Re:Why it has to die

[WhiteDeath]

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)

Re:Why it has to die

[Janek Kozicki]

now. start talking about simcity :)

Re:Why it has to die

[LPrime]

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?

Re:Why it has to die

[vvizard]

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?

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 :) 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..

Re:Why it has to die

[Mortlath]

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.

Re:Why it has to die

[Anonymous Coward]

Shame on you for replying to a troll.

Re:Why it has to die

[naden]

it requires a huge kernel on each machine...

Well MAYBE you should be running OSX. It has a microkernel you know. MUCH smaller.

I like it .. except having to whip out the electron microscope to read a header file can sometimes be a pain.

Re:Why it has to die

[Sj0]

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!

Re:Why it has to die

[Anonymous Coward]

Uh, dude, you just described a black box. Duh.

Re:Why it has to die

[MntlChaos]

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

Re:Why it has to die

[FuzzyBad-Mofo]

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

Re:Why it has to die

[rsclient]

A (fairly recent) MSDN has this, and only this, to say about Yield (at least in the index):

Not necessary and has no effect. The message loop handles synchronization. Not necessary and has no effect. The message loop handles synchronization.
Threads that create processes can use WaitForInputIdle to wait until the new process has finished its initialization.

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.

Re:Why it has to die

[Nasarius]

Check out his posting history.

Re:Why it has to die

[TeraCo]

Sure, but you're talking about technet, not MSDN.

Technet is pretty ordinary, but MSDN is awesome.

Re:Why it has to die

[j-pimp]

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.

Re:Why it has to die

[Anonymous Coward]

IIRC, the main party complaining about the lack of API docs was Novell -- who have to hook their directory service into Windows at a pretty low level. This sort of thing wouldn't impact the average application developer.

Re:Why it has to die

[LO0G]

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.

Re:Why it has to die

[Anonymous Coward]

> Debuging into system librarys ? Librarys should be blackboxes, and you should be able to trust them.

When they're written by God's Angels, and are therefore perfect, then you'll be correct.

But, so long as they continue to be written by us mere mortals, there will be the need to occaisionally debug a system library in order to have the app under development work correctly.

Re:Why it has to die

[dasmegabyte]

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.

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

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?

Re:Why it has to die

[aled]

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.
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 .Net does to Windows system these days but I assume that is pretty much uninstallable.

Re:Why it has to die

[dasmegabyte]

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.

Sun's pretty good, too...before .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
(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.

Re:Why it has to die

[Digital11]

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.

Re:Why it has to die

[dasmegabyte]

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

Re:Why it has to die

[mentin]

there are still people running NT4, which obviously does not support .Net at all.

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.

Re:Why it has to die

[reanjr]

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. ;)

Re:Why it has to die

[Anonytroll]

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.

Re:Why it has to die

[stor]

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

Re:Why it has to die

[Photo_Nut]

'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

Re:Why it has to die

[Alioth]

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.

Re:Why it has to die

[AndyS]

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?)

Re:Why it has to die

[Snaapy]

> 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)

Re:Why it has to die

[Anonymous Coward]

OK, no offence but it's pretty clear that you don't understand why an API exists in the first place.

It is *supposed* to hide the details of the implementation!

Re:Why it has to die

[NickRuisi]

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.

Re:Why it has to die

[TheRaven64]

Now the new entry into all of this is Cocoa. Cocoa is the new API that Apple is using for Mac OS X.

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.

Re:Why it has to die

[Dayflowers]

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? :)

Re:Why it has to die

[dasmegabyte]

Like I said, it's nothing Javadocs can't do, I find the XML-like reference a bit more intuitive, but what's great is the granularity of this context. If I have this:

///<summary>
/// Foo
///</summary>
///<param name="charlie">bar</param>
///<return&g t ;A reference to Foobar</return>
public Object AppendFoo(Object bar)
...

the code complete tooltip shows the summary field (foo) when you highlight the method's name, the param description (bar) when you open the parenthesis to start writing the call, and it displays the value returned "A reference to Foobar" when you mouseover the object call itself. Thus, you have all the contextual information pertaining to the method right in front of you AS you are coding without a huge scroll to read through. 95% of the time, this contextual information is enough for me to figure out how a new object works without having to go to the docs at all.

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.

Re:Why it has to die

[FireBreathingDog]

Dude, try Cocoa with XCode. Wow...

Re:Why it has to die

[Jorkapp]

• "Linux: Direct kernel calls for all the l33t kids!"

Linux... the only OS I know that makes me type "man mount"

Re:Why it has to die

[Graff]

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.

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.

Cocoa uses reference counting which is simpler and faster than true garbage collection

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.

Re:Why it has to die

[wtrmute]

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.

Re:Why it has to die

[Anonymous Coward]

There are six billion Linux users? That's like, the entire population of the earth!

I know /. likes to make Linux sound more widely used than it is, but I've never seen it taken this far.

Re:Why it has to die

[Anonymous Coward]

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.

Re:Why it has to die

[tolan-b]

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.

Re:Why it has to die

[Anonymous Coward]

thats a matter of openion. I developed for Mac clasic, Windows and Java, and now learnign OSX. I always found the Mac OS classic dveloper documentation more than adaquate... to me, this was going thru Inside Macintosh series, reading header files, and the use of THINK Reference. Never found the use of the Win help documentation useful to me, as I had to go to another app, and slow me down browsing thru a lot of half guessed crap.

Re:Why it has to die

[Carnildo]

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.

Re:Why it has to die

[Digital11]

I'd be interested in seeing which examples you're speaking of... I personally haven't run into any that don't work.

Re:Why it has to die

[bar-agent]

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.

Re:Why it has to die

[Anonymous Coward]

Of course it really didn't, it just made a bunch of things inside windows (like memory management) stop working.

Are you trying to imply that memory management worked in Windows 3.1?

Re:Why it has to die

[NanoGator]

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

Re:Why it has to die

[sjames]

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.

Re:Why it has to die

[cuerty]

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 :)

Re:Why it has to die

[RupW]

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.

Prophecy

[cbrocious]

My prophecy is that HTML and HTTP will be completely deprecated within the next 4 years, and will be replaced by an open standard, probably backed heavily by Microsoft, allowing more power and flexibility to developers. Something like that may being me back to web-development...

Re:Prophecy

[RAMMS EIN]

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.

Re:Prophecy

[Izago909]

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.

Re:Prophecy

[mcgroarty]

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.

Re:Prophecy

[tedhiltonhead]

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.

Re:Prophecy

[I confirm I'm not a]

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.

Re:Prophecy

[dustmite]

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

Re:Prophecy

[gewalker]

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.

Re:Prophecy

[ltmon]

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.

Re:Prophecy

[Tarantolato]

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.

Re:Prophecy

[Tarantolato]

We need an OSS clone of Flex functionality. It is insanely great.

Re:Prophecy

[I confirm I'm not a]

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!

Re:Prophecy

[Glock27]

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.

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! :-)

.NET & C#

[artlu]

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

Re:.NET & C#

[filtur]

Hurray for smalltalk. It's alive and kicking in some parts of the world. I was 'forced' to use it for an algorithms class. I didn't really care for it when I started, but in time it grew on me. I learned a lot more than just copying C algorithms from books

Re:.NET & C#

[javaxman]

I don't miss SmallTalk.

I program in Objective-C, using Cocoa libs under Mac OS X. ;-)

< ducks, fearing SmallTalk programmers with flamethrowers >

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:.NET & C#

[artlu]

Speaking of mac os x and java and small talk and sun... If sun would decide to use AQUA as it's desktop I think we would see a lot of rebirth in Solaris..

Now im upto $0.04.

GroupShares.com - An Interactive and Free Stock Market Community

Re:.NET & C#

[javaxman]

If sun would decide to use AQUA as it's desktop I think we would see a lot of rebirth in Solaris..

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

Re:.NET & C#

[harrkev]

I am typing on a Sun Blade 150 right now. I am not much of a programmer (more of a hardware person), but I would LOVE to be using KDE right now rather than CDE.

CDE is good competition for Windows 3.11, but anything more advanced blows this UI out of the water.

Just my free opinion, and worth every penny that you paid for it.

Repeating my comment on OSNews...

[RAMMS EIN]

I have 2 comments:

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 .NET doesn't go there; the GUI interface is very much tied to Windows.

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.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

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.

No, that's exactly the same as Microsoft's. Find me a deprecated *and removed* MS API call, I dare you.

Re:Repeating my comment on OSNews...

[mangu]

All these stop just short of integrating well with the web and the client platform. Why?

Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:

1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

3) Privacy and encryption are an add-on, not built in.

4) No widgets other than those in the browser.

The solution for all these problems have been to create plug-ins, applets, javascript, flash, etc. Since these aren't part of the standard, they are all different and incompatible among them. There isn't any standard beyond http and html. Or, rather, there are too many standards, one for each vendor...

Re:Repeating my comment on OSNews...

[Zocalo]

1. Web clients vs. rich user interfaces

Have a look around for screen shots of SAP running via a web interface. While it can be a little clunky in places, when properly implemented it can be every bit as rich as .NET/GTK/Qt based applications. It's doable, but the hardware requirements for the backend can be horrendous if you have a lot of users - in my case a pair of Sun E12Ks with 32 CPUs and a boatload of RAM and HDDs in each.

Re:Repeating my comment on OSNews...

[RAMMS EIN]

Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:

1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

3) Privacy and encryption are an add-on, not built in.

4) No widgets other than those in the browser.

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?!?

Re:Repeating my comment on OSNews...

[Anonymous Coward]

Try Java Web Start. Example.

Re:Repeating my comment on OSNews...

[Aphrika]

"Why has nobody managed (or tried) to take the last step?"

Your answer lies in your question. People do take the last step, using the range of technologies that you've mentioned. While Flash is mainly used for eye candy, I've seen it used for some nice realtime graphing and Gantt charts, Java still makes its way onto web pages from time to time, especially in web applications. In part, the reason that all web page interfaces aren't much good is because people have the choice, and most settle for good old HTML, with its limited form elements and markup.

There will always be a limit to what the browser will be able to do though. Part of that comes from the page's stateless approach, which ironically is a browsers main advantage over a traditional client-server system. IMO, the browser needs a revisit and a serious overhaul, otherwise its duties will be replaced by a family of other applications such as RSS readers and application equivalents (I believe Macromedia recently released a framework for Flash aplications, but I forget what it was called).

Re:Repeating my comment on OSNews...

[smallpaul]

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 .NET doesn't go there; the GUI interface is very much tied to Windows.

Web interfaces are not that good because the monopolistic owner of the most popular browser decided years ago that the Web was a competitor to their proprietary APIs. Therefore they've thrown no resources at advancing or evolving it. This sucks the wind out of the whole Web industry because nobody is going to serve data that requires an alternate browser.

Re:Repeating my comment on OSNews...

[RAMMS EIN]

Compilers, converters, text editors, filters? It can all be done with UNIX APIs from the 1970s.

Need network access? The BSD socket API gives it to you. Servers, clients, peer to peer? Not a problem.

So you want graphics? The X Window System has been around since 1985 and the protocol is still the same. Your old clients will still work with today's servers. Toolkits for making the programming easier have been around for a long time, too.

Anything you need to do can be done on UNIX (and POSIX) systems using APIs that have been stable since the 1980s, possibly earlier. win32 didn't even exist then.

Sure, if you want the latest technologies (Java, GNOME 2, Qt 4), you will have to put up with the fact that they are not backwards compatible. However, the old APIs are available, too, if you need them, and you can write any application using those.

Re:Repeating my comment on OSNews...

[grotgrot]

Why has nobody managed (or tried) to take the last step?

The first problem is that anyone trying to do a web app has to support Internet Explorer if they want to reach a reasonable number of users. Macromedia is trying to do the rich web client thing with flex. I basically compiles the UI to Flash but still communicates with the server. There is a good demo and presentation on that site. However be prepared to fall off your chair laughing when you find out how much it costs.

Contrary to Microsoft's, UNIX and POSIX APIs have been very stable

That isn't exactly true. Posix only has about a 1000 apis. It doesn't cover things like a GUI, rich access control and security, printing (not job submission but actual page composition), databases. There have been random UNIX centric APIs that have covered all those such as Xlib, XT, Motif, Gtk, Qt, KDE, Kerberos, DCE etc. However they too have evolved over time just like Microsoft APIs have.

I will certainly agree that UNIX centric APIs are usually (but not always) better designed.

Re:Repeating my comment on OSNews...

[RAMMS EIN]

Which just illustrates my point:

1. It's an almost 5 MB download, meaning it takes a long time to start.

2. Once started, it's noticeably sluggish.

3. The widgets are non-native and completely out of tune on my desktop.

Not to offend the developers, who have probably spent a lot of time making this into a good application. The problem is in Java. It just doesn't cut it.

Re:Repeating my comment on OSNews...

[Pieroxy]

I once posted a message to some mailing list requesting support for sockets in JavaScript

Security settings should force you to communicate only with your originating server and port. Hence a Socket is way "too free" for that.

And if the user is using a proxy, then what? How can you access your original server? You have to go through the Proxy.

No, a real way would be to have access to an object a bit like java.net.HttpURLConnection. Such an object would be trivial to write, with two features in mind:
1. It should use the browser's connections settings (proxies, etc...) and caching capabilities.
2. It should enforce that the URLs accessed are issued from the same server/port as the script requesting it.

Socket is way too low level.

Re:Repeating my comment on OSNews...

[Dub Kat]

Regarding why web clients haven't taken over...because MS doesn't want them to naturally. If web apps had good interfaces (approaching rich clients), and worked in any web browser, there'd be no need for Windows and IE.

MS has control over rich web interfaces being available because of this: the *vast* majority of browsers are IE. So if MS doesn't allow rich web interfaces in IE, web developers won't attempt to make a web app that can't be used by the majority of users.

I think it's possible to get close to rich web apps using JavaScript, DHTML, and other technologies, but it's very painful for web developers to get it to work correctly across Firefox, IE, Safari, etc. For an example, see oddpost.com webmail. It's very rich, but only works in IE 5.5+.

$60/month Debian Linux Server

Re:Repeating my comment on OSNews...

[TheGavster]

You'll note that the common word between the expansion of HTTP and HTML is 'text'. That's what the idea behind the web is, text. Current extenstion can give you pretty text. Sometimes, you can even get somewhat interactive text. Its no excuse for a real application, one that is designed to stand alone or at worst use a highly optimized VM that you yourself never have to see. You don't want to say 'I need to use app x, so I'll fire up the browser', you say 'I'll fire up app x'. For the lay user, there's no line between the app and the OS, because they look and operate as a whole. Web applications break this, by simply being enhancement upon enhancement laid upon simple text. Java applets are an exception, but they are pretty much a hole in the text where a real program is allowed to show through.

Re:Repeating my comment on OSNews...

[FigWig]

You can use the Javascript/ActiveX XMLHTTP object to dynamically read data. I have done it in both IE and Mozilla, though some trickery is needed. Overall it's probably not worth the trouble to use though. If you just want to reload certain portions of a web page you can always use IFrames.

Re:Repeating my comment on OSNews...

[mcrbids]

All these stop just short of integrating well with the web and the client platform. Why?

Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:

1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

3) Privacy and encryption are an add-on, not built in.

4) No widgets other than those in the browser.

The solution for all these problems have been to create plug-ins, applets, javascript, flash, etc. Since these aren't part of the standard, they are all different and incompatible among them. There isn't any standard beyond http and html. Or, rather, there are too many standards, one for each vendor...


So it's very clear, then, that there's a definite need that's not yet met. I checked out Mozilla's XUL and it doesn't do it, either.

Something that's not *quite* web-based, and not *quite* rich-client. Java and javascript both came kinda close. Javascript is a lousy excuse for a language, and Java has its own problems.

If I could get PHP or Perl into a browser, run the program on the browser, and then kick back to the web server a-la web, with session management, I'd have the bomb.

What I've done instead is to write client-side stuff in PHP-GTK, force the customer to install software, and then communicate with the server at the times its needed. Ugly, but it works.

Oh, and it works on Linux, Windows, and Mac OSX.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

OK, but there's nothing there to hold over Windows. Winsock is basically the BSD socket API. Windows GDI still works. Win32 APIs have been stable since inception. So what's your point?

Re:Repeating my comment on OSNews...

[Ian Peon]

1. Web clients vs. rich user interfaces

If you haven't already, take a look at XUL. Mozilla's interface is created with this, and other people are doing some very interesting things with it. (second link only works in Mozilla or other Gecko browser)

Re:Repeating my comment on OSNews...

[RAMMS EIN]

Actually, HTML (substitute XML/s-expressions if you like) is a nice way to describe interfaces (nicer than any C API I've seen), and, combined with a scripting or programming language *could* provide a rich user interface. The problem is that the only standard scripting language is JavaScript, and it stops just short of providing the needed functionality (apart from being horrendously slow in current implementations).

Re:Repeating my comment on OSNews...

[ebassi]

You would be lucky if a GNOME app for GNOME 2.0 even compiles for 2.6. It will most certainly not run if it's already compiled.

I call for BS on this one. Now, if you'd have said "GNOME app for GNOME 1.4", then you'd have been right; but, you know: API breaking does happen, from time to time, especially when an API overpasses the point of being sucky enough to be unextensible.

On the other hand, a GNOME 2.0 app will run, without the need for recompilation, under GNOME 2.6. Flawlessy. In fact, I'm using apps written, tested and compiled with libraries released for GNOME 2.0 under GNOME 2.6.

Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.

Re:Repeating my comment on OSNews...

[Pieroxy]

With that, you could interact with the server _without_ reloading the page

BTW, you know there are numerous tricks to do this very thing, right? Such as hidden frames, hidden iframes, dynamic script generation (foo.innerHTML="http://my.server/my/script.js?foo= bar"), etc...

Re:Repeating my comment on OSNews...

[bergeron76]

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?

Mozilla has.

Re:Repeating my comment on OSNews...

[msoftsucks]

Yes it's rich because its using ActiveX. That's why it only works in IE 5.5+.

Re:Repeating my comment on OSNews...

[Trinition]

While it can be a little clunky in places, when properly implemented it can be every bit as rich as .NET/GTK/Qt based applications

I can also trim my lawn with hand-clippers, but a lawn mower would be much more efficient.

It is not easy, stable, etc. to make a complex but usable web interface. They all end up cutting corners, relyig on browser-specific functionality, plugins, etc.

What I want to see is something like XUL or XAML turned into a standard and then having a XAML or XUL browser instead of a web browser, with a simple HTML-rendering component built into it.

Reading a news article is a very HTML thing to do. Perusing and replying to threaded discussions is an exmaple of something that would probably be experienced better through an actual UI instead of an HTML-ized version. How about your Yahoo Mail or GMail accounts? They woudl also benefit from a UI-markup-language producing a more traditional client-side UI.

The question is, how long owuld it take a UI-browser to become as ubiquitous as the web-browser?

Re:Repeating my comment on OSNews...

[aero6dof]

Yes, obviously, but then, _how come_ there are no standard protocols that fix this? Many people perceive the need.

Certainly it exists. Its called X Windows.

Re:Repeating my comment on OSNews...

[Bluelive]

I guess java could do it, but there are enough big problems. The jvm version installed is often to old, and updating costs too much bandwidth. Rmi is arguably too difficult. Swing is still missing a common guibuilder. Swing is hard to remote via rmi. Programming for a distributed enviroment isnt a skill most people have. Latency might be too high for naive GUI forwarding solutions. Bandwidth might be too low for sending whole documents or emailarchives. Security gets more difficult to get right for more richer applications. (just wait for the apps that expect the client side to not get decompiled and have special requests crafted) Ofcourse most is true for any such application.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

Contrary to Microsoft's, UNIX and POSIX APIs have been very stable.

The Linux APIs are only stable for developing a 1980s style text-only application (or daemon) that uses text files and obscure keyboard shortcuts as its user interface.

For applications that an average end user would want to use, the Linux APIs are a horrid mess of change compared to anything from Redmond. Have you tried running Netscape Navigator 4 for Linux (compiled in 2002) on a Fedora Core two box? It doesn't work. Have you tried running a version of Wine compiled and released in 2002 on same FC2 box? Again, it doesn't work. And, oh, have you tried updating an old Loki game on a FC2 box--that doesn't work either, even though the loki_patch tool which broke in FC2 was staticlly compiled.

The fact of the matter is that Microsoft runs rungs around Linux when it comes to binary backwards compatibility. Linux (well, at least FC2) is developed with a mindset of "if it isn't open source, it doesn't need to run on our platform".

(Te be fair to Linux, an old binary of FVWM1 compiled for RH6.1 works flawlessly in FC2. As does the actual Loki game I play).

Re:Repeating my comment on OSNews...

[Anonymous Coward]

> nobody is going to serve data that requires an alternate browser.

That's a BS assumption for internal/vertical applications. If a company can tweak it's existing ASP/PHP/JSP stuff and get a better UI on the cheap, they'll certainly look at switching browsers.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

Yeah, and Linux has had how many threading APIs?

Next time read the whole textbook and not just the intro page.

Re:Repeating my comment on OSNews...

[jc42]

... it's possible to get close to rich web apps using JavaScript, DHTML, ...

Yes, obviously, but a simple experiment on my machine shows one very good reason this isn't happening. I have maybe a dozen windows open, and several have as many as 10 tabs showing closely-related pages.

I keep javascript and other scripting turned off for a very good reason. If I turn it on and refresh any of these windows, that browser's cpu usage rapidly goes to nearly 100%. Why? Simple answer: advertising.

Most of the actual web content makes little use of scripting. No point, usually, because I'm mostly displaying static docs. But the advertisers want my attention, and to get that, they use changing pictures. A changing widget requires cpu time. It doesn't take very many "active" ads to saturate the cpu.

But I'm trying to get work done, and I need my cpu. My only defense is to turn off scripting. And set the image processing to only do a single pass through a changing image. This isn't totally successful. The mozilla here is running at about 10% of the cpu when idle, even though I've turned off all the "active" things that I know about.

When someone comes up with a scripting technique that doesn't allow web pages to soak up my cpu, maybe I'll consider leaving it turned on. Maybe.

Of course, there are also security concerns. Anyone who leaves scripting turned on in IE is a fool (or is working on a "crash and burn" machine and doesn't care). Java and Javascript are materially safer from a security viewpoint, but they still have some serious risks. I have a demo page with a bit of Javascript that downloads an image to your machine without ever showing it to you. Depending on my mood, it may be a porn image, and anyone watching your Net usage will see that you downloaded porn. Depending on where you are, you could lose your job and/or land in jail as a result of downloading my web page with Javascript turned on.

But the cpu usage is the real story here. As far as I can tell, nobody is working on solving it. Unless I can trust the Web to not soak up all my cpu, I won't seriously consider allowing any cpu-using Web gimmicks to run.

Re:Repeating my comment on OSNews...

[pfdietz]

'X Windows'? Is that anything like the X Window System?

Re:Repeating my comment on OSNews...

[AdamPiotrZochowski]

the biggest problem with web is that you have to code for:

1) lowest common denominator
and forget things like javascript/flash, or
use them only as a bonus addon, not a requirement
(ie: flash for a logo, not a menu)
(ie: javascript to verify a form before submission
( but still duplicate code on the server side to
( repeat the form verification

2) have tons of work arounds for different implementations
Every browsers has own quirks. So you try to find
ways to fix problems. NS4.x is the worst of them all,
does not handle nested DIVs, has a limit on the javascript
source code it can process, crashes, forgets to render
elements, its a mess. Now NS4 is a recent browser, dont
forget to also try to support the lynx/links/w3 browsers.

3) alienate users
the webservers I am handling for now have 98% IE users,
its reasonable to deny access for people who use
alternatives.

as per your ideas as a sollution:

1) flash is a JOKE, dont touch it ever!!

2) python? how? on the server side? and how would it differ
from perl/php/asp/jsp ?

3) JavaScript with Extensions, beautifull, NS4 has different
layering system than IE/Mozilla. Not to mention that IE
has its own. And then there is the 'standard' DOM, that
every browser supports partially...
I fear of the extensions you propose? and how do you hope
to make browser makers support them.
I mean, in IE you can use vbscript instead of jscript,
and with 98% market saturation no-one sane is doing that!

4) XUL, I have though about XUL and XAML,... Gnome/mono/Mozilla
people think this will be great. but then, please
review the point above!! its an extension that only one
browser supports, and its unlikely all browsers ever will
(or I await the links/w3 support for XUL)

5) compile C on the fly... How big is C compiler?? What
libraries are for C to be used?? Do we allow inline
assembly?? What about pointers? security? this is tryly
insane idea!!

So why has no one tried?

1. http was not designed for this
http is just a transfer protocol, we could as well keep
hosting webpages over gopher or ftp for all that is
necessary..
2. html was not designed for this
M stands for MARKUP, providing hints how to display Text
(guess what does T stand for in html). This is an
extension to ascii files. We define what part of the
ascii file is a quote (with QUOTE tag) or what is
a paragraph (p) or what needs to have emphasis (with EM)
The addition of such tags as bold (B) or italics (I)
already bastardized HTML !!!
3. javascript / css / dom / dhtml / cookies / https
these are all kludges and hacks on top of hacks to get
html do something that it was not designed. Not to
mention that HTML itself in the middle of its life
changed its purpose from being an open ps/pdf replacement
that makes sence to an idea of full fledged application
system... UGH!!!

to answer: many tried, many failed, and we keep adding hack
on top of hacks.. small hacks, i hopes that one by one they
will get somehow supported and popular around the web.

enjoy

--
/apz, Support bacteria -- it's the only culture some people have!

Re:Repeating my comment on OSNews...

[ispeters]

It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation, the Mozilla documentation, the Microsoft documentation or this tutorial called Using the XML HTTP Request Object

The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)

The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.

Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.

Ian

Re:Repeating my comment on OSNews...

[autopr0n]

1) No sessions. No good way to store state. Cookies, etc are ugly kludges.

APIs can abstract this away. Give the user a single session ID, that references a complex server-side object.

2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.

Ever heard of POST? But what kind of applications need that much data transferred from the user? If you're doing a program where all the work is done on the server, you're golden. On the other hand, not being able to take advantage of the client side processing is pretty retarded.

3) Privacy and encryption are an add-on, not built in.

SSL is fine, and well supported.

4) No widgets other than those in the browser.

You can easily roll your own with DHTML, and use DHTML/JS libraries of other widges.

The real problem is that most of the extended features aren't well supported.

Re:Repeating my comment on OSNews...

[costas]

AFAIK, the issue is the DOM/JS integration for individual browsers --essentially you need a standard way to talk back to the server from within the DOM of a page instance, which doesn't exist. Now, there is an excellent JS library that does exactly that, abstracting away the browser-specific hacks (works on IE, Gecko, KHTML and Opera at least). For a demo, go to my site in my .sig: that's how the automatic ratings work, w/o re-loading the page.

Re:Repeating my comment on OSNews...

[TheGavster]

Great for interface layout, pretty lousy for the part of the software that actually does work. I think that an XML-based dialog layout system might not be all bad, but simply as a way of communicating the layout to a real language, a la the dialog designers in VS.Net.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

It's probably not a bad thing. Maybe one-size-fits-all works, maybe it doesn't. I think we're approaching a period where we're going to have a million little micro-applications, like back in the early days of the Internet when you needed a separate tool for FTP, e-mail, Web, gopher, IRC, etc.

Now you can get that all rolled up into a single tool (although even now, outside of, say, Mozilla, the level of integration is pretty low--and even Mozilla is moving back in the other direction, via Firefox/Thunderbird).

The problem with mega-apps is that they don't adapt to revolutionary change very well. If the browser as a platform is insufficient, it's going to be hard for an outsider with a few weird ideas to tinker with it. These little apps like RSS readers are too new; it'll take time to mainstream them (although it's already starting to happen).

Re:Repeating my comment on OSNews...

[Anonymous Brave Guy]

WHERE ARE THE GOOD WEB HOSTED APPS?!?

Maybe the same place as the worthwhile contexts where web hosting actually adds value? That is, there are a few specialist ones, but mostly they don't exist.

Re:Repeating my comment on OSNews...

[N1KO]

There are online anti-virus programs (using ActiveX).

Bittorrent is written in Python and it's fairly popular. I don't understand why anyone would want that kind of application running inside a web browser if it works well enough as it is.

Downloading a small program only takes a few seconds and running things automatically isn't a very good idea anyway.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

For example there's this conferencing application from (www.sonexis.com)--click on the "See the Power..." button to view a (Flash 6, alas) demo of it.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

Wow. Moderators are on crack again. Should've been modded '-1, Pedantic'.

Re:Repeating my comment on OSNews...

[Jonboy X]

Well, see, the downside of this approach is that you have to spend your time writing frikkin' JAVASCRIPT!!! Having done my fair share of JS at my last job, it's always been my experience that writing and maintaining a Javascript app any more than about 500 lines (not to mention working around Javasctipt/DOM implementation bugs on various platforms) make me want to kill.

Of course, this might have had something to do with the fact that we were forced to support Netscape 4.7, even in the age of Mozilla.

Re:Repeating my comment on OSNews...

[boots@work]

I kind of agree, but I think you are stretching the definition of API a bit too far. From a certain point of view, anything you need can be written on a Turing machine, and they're even older than Unix.

Suppose I want to display nicely rendered multilingual text. Not such an outrageous requirement, I think. But only in the last few years have there been any reasonable Unix APIs to do so. Working unicode support throughout the toolkit and in window managers is only a few years old.

I think the core issue is that Linux doesn't have the "fire and motion" imperative that Microsoft does. Developers do break interfaces from time to time, but they generally only do it when there is a technical imperative, not just because they want to force upgrades.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.

Unix versioning is based on sym links. Given that it doesn't look like sym links came into play until somewhere around SVR 3.2 which seems to have come from 4.2BSD (I base the "come from" on a diagram on page 5 of The Design & Implementation of the 4.3BSD Unix OS), and Linux didn't get them until .95.

Now, I don't know what your definition of "since day 1" is but if it's 14 years (First Edition released in 1969, 4.2BSD released in 1983) then you're absolutely correct.

I'd also point you to the fact that Unix didn't have passwords on day one. They were added later. So much for security can't be added on, it's gotta be designed in. Not that you claimed that they did but it's an example of where Unix came from.

You see when Unix was designed it was a stripped down Multics. Multics was too big, too bulky, too much operating system with too many features. But if you look at the features of Multics we all have them on our desktops (and Unix systems). So Unix barely had anything from day 1. You wouldn't want to use day 1 unix today. Oh, maybe you'd find some level of nostalgia in it - it'd be like whipping out a Pong console - but you wouldn't ever make it your desktop, let alone attempt to install multiple versions of software on it.

Re:Repeating my comment on OSNews...

[ispeters]

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

if(isIE) {
// do this
} else if(isMozilla) {
//do this
} else {
// blow up
}

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

Re:Repeating my comment on OSNews...

[Spy Hunter]

This article is great, Joel is a genious, and it's all because of the one paragraph in the article where he answers your question #1.

Joel has explained the reason Internet Explorer's development hit a wall a year or two ago. All you people asking why Internet Explorer's standards compliance hasn't gotten any better, why it hasn't gotten tabbed browsing, etc, now you have your answer. It's a very good reason (for Microsoft), and it's obvious in retrospect, but I sure didn't think of it until I read these few sentences:

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.

Microsoft can't afford to make IE any better, because if was improved one or two generations more, the kinds of web applications that would become possible would make Windows irrelevant as a platform. Everyone would be developing for the web instead of Win32 or .NET or Avalon or whatever. Internet Explorer development has come to a screeching halt except for things which are absolutely necessary to avoid losing its #1 browser position (because for Microsoft the only thing worse than an improved IE is an improved Mozilla!). This is the reason why.

Re:Repeating my comment on OSNews...

[zhiwenchong]

Take a look at this:

BEEP, the Application Protocol Framework
http://www.beepcore.org/beepcore/about_qanda.jsp

Re:Repeating my comment on OSNews...

[Trepalium]

Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.

I wish that were true. I really, really wish that were true. Too many people do not understand the correct way to determine the version numbers on their libraries, and instead fix them to whatever release of the package is. Ask the people who packaged KDE for Debian why this is a good idea, and I'll bet you'll get an earfull.

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:Repeating my comment on OSNews...

[Anonymous Coward]

Funny... the page doesn't seem to work at all like the description, and things that are supposed to happen just don't.

Not much of an endorsement for Javascript, really.

Re:Repeating my comment on OSNews...

[LoocSiMit]

1. Web clients vs. rich user interfaces

I have long wondered why web interfaces aren't much good.

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:Repeating my comment on OSNews...

[Anonymous Coward]

Ho-lee shit...

Is there any plan to make a XUL plugin for IE?

Re:Repeating my comment on OSNews...

[Trepalium]

One? linuxthreads is a subset of POSIX threads, and is part of glibc now. There's three different implementations of threads on Linux, the original linuxthreads(1:1), ngpt(M:N), and nptl(1:1). They might be implemented in different libraries, but they're just one API -- POSIX. Of course, maybe you mean Apache's APR, wxWidget, and the other platform abstraction libraries?

Re:Repeating my comment on OSNews...

[RAMMS EIN]

``BTW, you know there are numerous tricks to do this very thing, right?''

Yes, and they are all high latency and waste bandwidth. With sockets, you determine the protocol that gets used, so you can write an IRC client that runs in a web browser, for example.

Re:Repeating my comment on OSNews...

[RAMMS EIN]

``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.''

IIRC, this is exactly how socket access works in Java applets (unless the applet is signed and given more permissions). There is no theoretical limitation that prevents you from making sockets work like you describe. This curbs the security argument.

In the past, people have suggested that I create a Java socket from JavaScript (I think it's called LiveConnect). However, this would still require Java, and when I tried it, it completely trashed Mozilla.

Re:Repeating my comment on OSNews...

[killjoe]

"Yes, obviously, but then, _how come_ there are no standard protocols that fix this?"

There is. It's called CORBA. It's great, it's language independent, OS independed, allows for propogation of events from server to client and vice versa, there are lots of open source servers and every language in the world supports it.

How come nobody uses it? It's "Too Hard" (TM). Which means your typical php, asp, python or perl hacker never took the time to learn it.

Re:Repeating my comment on OSNews...

[bheer]

>It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object.

Worth noting that Gmail (at least on IE) uses this a *lot*. And that's how it largely achieves it's speed and usability (I use Outlook at work and can attest that Gmail's implementation of autocomplete is actually *better* than Outlook's.)

Re:Repeating my comment on OSNews...

[RAMMS EIN]

Wow, thanks, that's a good start. However, it still loses against real socket IO: HTTP requests add a lot of latency and waste a lot of bandwidth if all you want to do is send a small message. What I had in mind at the time I suggested the extension to JavaScript was writing an IRC client. Imagine adding half a KB of HTTP headers to every little message you send. :-(

Bitterness follows. I am really disappointed with the state of browsers. All they really do is parsing simple textual formats, and then rendering the specified widgets according to some hardcoded and some customizeable rules. Then, they can execute a scripting language that interacts with the parse tree. For this you need a 10 MB program? Hell, even a simple browser like lynx (which mostly just strips the markup and passes on the text to the display) is hundreds of kilobytes. Why? And then they still don't provide the simple feature of letting the scripts access the network functionality that the browser itself uses. One simple feature that would make them a fully workable platform. But no, they give you the kitchen sink instead.

I am going to write my own browser, see if I can keep it small and simple, then add in support for network access in some scripting language. Then maybe I'll have some respect for the major browsers.

Re:Repeating my comment on OSNews...

[Pieroxy]

I basically described the behavior of "java.net.HttpURLConnection". So no, it is not how "exactly how socket access works in Java applets", as you put it. It actually has nothing to do with it.

This class is HTTP-based, meaning it cannot do anything else than HTTP protocol. It does use the browser internet settings, so even if the user doesn;t have an internet access but just access to a proxy, it still works.

people have suggested that I create a Java socket from JavaScript
That works only if the user has a direct access to the internet. No proxies, etc...

Re:Repeating my comment on OSNews...

[phreakv6]

If using a rich interface is the idea... why not use macromedia flash... well for communication like you were talking about... sockets... flash remoting could do the trick... the security etc is handled in the remoting API,it allows connection only to the server from which the flash movie was hosted and also it uses the browsers connection settings in case there is a proxy in-between... of course the remoting communication is with xml over http..

Re:Repeating my comment on OSNews...

[ProKras]

Hmmm...I'd like to see someone at Valve try to port Half-Life 2 to run as a web app.

Hope the user's got a fast connection.

Re:Repeating my comment on OSNews...

[drolli]

Java will in near future nearly kill any other language regarding thin clients - in fact it did. Most mobile phones here are delivered with some kind of java; It runs on windriver vxworks os (most uses embedded RT os); It runs on Mainframes, Smartcards and other funny devices. The really bad frst version of the AWT and all the compatibility Problems from Java 1.0 to 1.2 and quick changes are clearly a minus, but since 2 years these settled. The Problem about distributed applications is in most cases, to my experience, not the programming but the conception/semantics behind. To believe that porting an non-distributed system to a distributed one can be done by programmers alone is futile. Most of the time even semantical changes in the function are appropriate - since actions which did not cause any considerable cost before (e.g. accessing an database!) cost something (e.g. a limited centralized cpu, a limited centralized network interface, a limited amount of data transferred with high priority, a limted amount of total data transferred and so on).

Re:Repeating my comment on OSNews...

[julesh]

Until it was adopted by enough sites that it was necessary to have one.

Of course, few people would want to be early adopters, because the potential market would be small.

It is an idea I've considered before. I don't think the world's ready for it yet.

Re:Repeating my comment on OSNews...

[jsebrech]

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?

Because the only ones who could, the W3C, have abandoned HTML. They want you to move to XHTML(2), XFORMS and SVG. Therefore they are no longer in the business of extending regular HTML.

David Baron in his blog commented about the disinterest of the W3C with regards to supporting the existing API set.

HTML does not have the necessary elements to do rich ui's well. There is no widespread client-side web technology that does have what it takes (flash and java come close, but have single-supplier, standardisation, integration and accessibility issues). Like you point out, with just a few HTML extensions the web could become dramatically more useful for rich UI's, but the W3C has shown zero interest in doing that.

And then ofcourse there is the problem of 90 percent of the client space running a browser which has not seen development this millenium. But with HTA's you could conceivably figure out some kind of extension that does work in IE too. If there was some kind of unified push to make regular HTML and the existing web technology "good enough", it could succeed.

Re:Repeating my comment on OSNews...

[Arrawa]

Well, I work with a web interface everyday (Tridion CMS) and I it is just plain slow. It uses MSIE and it looks great, has many features, but the rendering is slow and if the connection is not that good, MSIE hangs. You need a really fast computer with loads of internal memory to get it going.

Mozilla is undoubtely faster, but still...

Re:Repeating my comment on OSNews...

[julesh]

I think your problem is unusual, for a few reasons:

1. 120 web pages open at once is a lot more than most people would even consider. I rarely see people with more than 10. I have one colleague who often opens as many as 30; he doesn't complain about CPU usage, although he does frequently complain about Mozilla's memory usage when he does that.

2. Most people still use IE. IE does seem to use less resources when idle than Mozilla.

3. Very few people would _notice_ 10% cpu usage. You must be executing some demanding apps for that to be a problem.

Re:Repeating my comment on OSNews...

[RAMMS EIN]

``Microsoft can't afford to make IE any better, because if was improved one or two generations more, the kinds of web applications that would become possible would make Windows irrelevant as a platform.''

Some of the replies I have received in this thread show that XUL-capable browsers have already achieved a fearsome ability to present rich user interfaces. This means that MSIE not only lacks the usability features that other browsers provide, but also the base that some developers use for their applications. If Mozilla and web developers push hard enough, they might cause a revolution that forces users to upgrade to better browsers, and MSIE into compliance with XUL, rather than the rest of the world into compliance with Microsoft's XAML.

Re:Repeating my comment on OSNews...

[rmayes100]

Not to mention if some popular apps start shipping and/or requiring Mozilla more people will have it installed on their machines and may choose to use it over IE.

Re:Repeating my comment on OSNews...

[heck]

> Yes, obviously, but then, _how come_ there are no standard protocols that fix this?

Because the target "platform" has been IE. Management knows everyone has IE, so developers are told "it must work in IE!" There ARE ways to do some of the things you talk about if you let a semi-decent Web hacker loose (trusted Java applets talking to a servlet; an ActiveX Object; etc.) - but the fact is most people are used to Web interfaces that work in IE (and the limitations of those interfaces); most people do NOT want to download something that smells like a 'fat client' layer (even if it is using an open standard and downloads from the server blah blah blah); and management does NOT want to support something that smells (to them) like a fat client.

Joel touched on the secondary problem in his article. The IE developers have been locked away for years and IE has changed not a whit for all practical purposes. Netscape imploded; plus Netscape decided to rewrite everything from scratch (hard to add new features when you are recreating all of the original features) Opera has zero foothold in the US. Mozilla/Firefox is finally stable and it does have some nice features; and (back to the grandparent post) as Joel mentioned in one of his articles - now that Firefox IS stable it will be interesting to see what happens with DHTML.

But we still have the problem that management feels that everyone everywhere has IE and IE is not changing. As others (including Joel) have noted, it is not in MicroSoft's interests to have IE change. Think about it - if you develop a good way to implement Web client where everything - your Word processor, your email, your spreadsheet - runs from the server on open standards, why would most people need Windows or need to develop client apps for Windows?

Re:Repeating my comment on OSNews...

[Suidae]

I wonder if the IE team is still there, keeping IE updated with all the new technology, just in case.

Heck, they might even have a version that properly supports PNG images.

Re:Repeating my comment on OSNews...

[ttsalo]

Anything you need to do can be done on UNIX (and POSIX) systems using APIs that have been stable since the 1980s, possibly earlier.

Oh yeah? Try to do:

• PTY allocation
• Bookkeeping for user login/logout
• Accepting user's login (password itself, password aging, expiration, etc etc)

so that it works on every system and tell me again about the "UNIX API"... We're talking major #ifdef hell here. The PTY allocation is the cleanest here, it just requires eight-branched #ifdefs. The two others are much worse.

--

Re:Repeating my comment on OSNews...

[cortana]

I call for BS on this one. Now, if you'd have said "GNOME app for GNOME 1.4", then you'd have been right; but, you know: API breaking does happen, from time to time, especially when an API overpasses the point of being sucky enough to be unextensible.

Of course, you wouldn't compile a Gnome 1.4 app against the API for Gnome 2; you'd compile, and run, it against the old Gnome 1.4 libraries. And since we have had versioned libraries for years, you can continue to run, say, Gnucash right alongside newer Gnome 2.6 apps.

It really annoys me when MICROS~1 come up with some bullshit bandaid for creaky old Windows like "Side by side instalations of multiple versions of the same DLL", and all the Windows sycophants claim it's the second goddamn coming of Christ, when it's been working over in Unix land for decades. Argh.

Re:Repeating my comment on OSNews...

[Anonymous Coward]

I like the idea, but you've got to come up with some other (nick) name. "UI browser" is even more confusing than "XUL browser"... What it the thing that you are browsing, really? From the user's point of view?

Remember, eventually this has to be sold to the PHBs if it is to succeed... So an easy to understand name is good. "Web browser" happens to achieve perfection there.

You've given the under-the-hood a lot of thought, so I'll gladly leave the name inventing to you, after this small remark :-)

Re:Repeating my comment on OSNews...

[Anonymous Coward]

I'd just like to add that personally I enjoy watching 100% CPU usage. Makes me feel I'm really getting value for my money from that tortured CPU :-P

If it was 10% all the time, I'd feel silly for having spent far too much on the CPU...

Re:Repeating my comment on OSNews...

[chris_mahan]

And why is it too hard?

Because distributed applications that marshall remote objects are "too hard" to get right.

Re:Repeating my comment on OSNews...

[rnd()]

Check out the Microsoft Web Service Behavior. With this, you can interact with a Soap web service from client side script. Gmail uses this, I believe.

Re:Repeating my comment on OSNews...

[Trinition]

I propose a "Rich Browser" in honor of the rich client metaphor I'd like to see resurrected where the client contains meaningful state and has a complex (in a useful way) interface. You can do this with HTML and friends, but it is much more difficult because they weren't built for that.

Re:Repeating my comment on OSNews...

[WNight]

Wow, that's really nice looking for being cross-platform.

Re:Repeating my comment on OSNews...

[alienw]

OK, then try making a 3D first-person shooter, with 3D-accelerated video, multichannel 3D surround audio, various input options, and so on. You will probably have to implement half the stuff yourself. The thing is, X11 and KDE or GNOME is a much more important part of a modern desktop system than the underlying UNIX API. Hell, WinNT is POSIX compliant, but it's not like you can run Linux apps on it directly.

Hard to be a Mac user?

[Anonymous Coward]

Remember, people buy computers for the applications that they run, and there's so much more great desktop software available for Windows than Mac that it's very hard to be a Mac user.

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.

Re:Hard to be a Mac user?

[Anonymous Coward]

Hear, hear.

I challenge Windows users to name one common (non-gaming) application that exists for Windows but doesn't have an equivalent on the Mac. I can't really imagine what it could be. We have Office, iPhoto, iTunes, and Safari, and between those 4 (Word processing, digital photos, MP3s, the web) 90% of computer time is taken care of.

Now, I'll admit that gaming on the Mac is shit, but hey, that's why I own a Gamecube.

Re:Hard to be a Mac user?

[Oligonicella]

Like he said, *you* have everything *you* need, but the plethora of quite diverse and intensive applications that everyone *else* needs isn't there. Sorry, he's still right. My wife has a Mac, I don't.

Re:Hard to be a Mac user?

[kensai]

No Viruses
True thus far

No Trojans
Want to rethink that MacOS X Trojan

indefinite uptime
Not a valid metric

great applications
In the eyes of the beholder

Re:Hard to be a Mac user?

[jwcorder]

Name one great game that came out in the past six months that works on your Mac? You have ten seconds. Ok a minute. It won't matter, there aren't any.

Re:Hard to be a Mac user?

[JamieF]

You know that trojan wasn't actually found in the wild, right? They took a proof-of-concept that someone had created and announced that their virus app could detect it.

Perhaps parent^2 should have said "no trojans in the wild"...?

It is a pretty sad argument, though. There's always that one kick-ass application that only runs on Win32, such as Visual SourceSafe or Outlook or IE 6.0 or Access or MSN Messenger. Pity the poor Mac users who can't experience all that the Windows platform has to offer.

Re:Hard to be a Mac user?

[Mongoose Disciple]

Believe it or not, I'm not trying to troll you here. Honest.

I'm not some kind of super-Mac-hater. OS X is pretty slick, and if on some future day all the software that I would want to use is written for the Mac without my having to endure Windows-emulation headaches I see my Mac-friends having, I would probably switch.

That said, saying there aren't viruses or trojans for Mac is kind of like saying your Amiga doesn't pick up viruses from the intarweb these days. Who would bother to write one?

Security by obscurity doesn't work, true. But security by "Who the fuck cares" does.

Re:Hard to be a Mac user?

[rjung2k]

That's a silly argument, since you're assuming "great game" is a Windows game first and foremost. It makes as much (little) sense as saying, "Name one great Mac game that came out in the past six months that works on your Windows PC?"

Re:Hard to be a Mac user?

[jwcorder]

No, not assuming a great game is a Windows game. But you could. Because I would almost guarantee that one thing you will never hear at EA is "Hey Shithead, how are you coming on that Award winning game that only works on OS X?"

Or you will never see a Venture Capitalist meeting start out by saying..."ok, we have this great idea for a game, but here's the catch, it only works on MACs. PCs can go to hell...and we are gonna make tons of money..."

Re:Hard to be a Mac user?

[javaxman]

Joel here also mistakenly buys the argument that Mac users are only 2.3% of the population. Not so. Mac users who bought a machine *this year* are 2.3% or so. But Mac users keep and use their machines for a _lot_ longer- they're actually more like 10% of users.

It seems there may be a few applications for Mac OS X as well. More importantly, Objective-C and Cocoa are easy enough that more OS X programs are being made every day. Developers indeed. If the Linux community could get some standardizationg together and throw some effort behind GNUStep... sigh... that would be nice, too, but Apple's more likely to release OS X for Intel ( i.e. don't hold your breath ). GNUStep is getting closer, though...

If it weren't for guys like Joel with their "if it's not Microsoft it's just weird" attitude and willingness to spread MS FUD, users would have a lot more options, and more developers would be able to make a better living slinging more code for more platforms, rather than being forced to eat Microsoft's swill.

Re:Hard to be a Mac user?

[jwcorder]

"But Mac users keep and use their machines for a _lot_ longer- they're actually more like 10% of users"Alot longer then what? Oh I forgot, my windows machine self destructs after 3 years. I just can't take all this MAC washing. The world according to a MAC user:

1. My MAC is better then your Windows XX machine.

2. MS apps run better on my MAC then your Windows XX machine.

3. The silicon that makes up my MAC is high value, so it will last so much longer the the silicon in those Windows parts.

4. My MAC is faster then your Windows XX machine

5. Because I use a MAC, my penis grew 4 inches and I can screw for hours and I couldn't do that before.

I have to leave this thread now. Getting....a...migraine.

Re:Hard to be a Mac user?

[filmsmith]

Don't leave just yet. It's Mac. Short for Macintosh. Not MAC, short for Media Access Control.

And my penis actually grew 5.2 inches.

fs

Re:Hard to be a Mac user?

[CaptDeuce]

Like he said, *you* have everything *you* need, but the plethora of quite diverse and intensive applications that everyone *else* needs isn't there. Sorry, he's still right.

1. People seem to mix up the fact that just because a particular Windows application isn't available on Mac, that Mac users do without. As a rule, it's not the case.

2. What applications do the vast majority of Windows users use? Office, IE, and Outlook. Right? They are all available on Mac though there's little reason to use IE and Outlook. The one exception is Access. Is this a show stopper in the corporate and business world? Sometimes. In the home market? Rarely.

3. To the typical user -- geeks included -- the availability of more software on Windows just means there's more software they could use but don't. This is not a minor point; there's only so much software that any one person will want to use. I'd be curious to see if Windows users use more, less, or the same amount of software as Mac users.

4. While quality is often in the eye of the beholder, I for one still think that Windows software tends to be crappier than Mac software. Unfortunately, that crappiness seems to be spreading. Suffice it to say there are more ways to produce crappy software than good software and since Windows has so much more software available for it ...

It's not hard being a Mac user, certainly no harder than being a Windows users since the vast majority of users have a hard time using computers at all.

Try this perspective: as a longtime Mac user, I have a hard time using Windows because I can't find much high quality software that runs on Windows --even after several years. Stands to reason, doesn't it? Considering that all the major apps -- Word, Excel, Photoshop, Illustrator, etc. -- were born on the Mac platform, you'd think developers would look to the Mac sometimes for how to do things right.

Re:Hard to be a Mac user?

[Anonymous Coward]

UT2k4?

Re:Hard to be a Mac user?

[TheHornedOne]

He said 'user' not 'wanker that sits in front of a 15" monitor pretending to blow up trolls'

Re:Hard to be a Mac user?

[man_of_mr_e]

You're making a serious statistical error there.

You're forgetting that even though Mac users may keep their machines for a while, so do Windows users. Further, an aging Mac LC isn't going to be very useable with today's or even yesterday's applications.

Re:Hard to be a Mac user?

[javaxman]

Now, let's be serious for a second. Did I say any of 1-5?

No. I said Macintosh users keep their hardware on average much longer than PC users keep their hardware, so the relative yearly *sales* percentages of Macintosh hardware vs. PC hardware doesn't reflect the number of Macintosh users vs. PC users.

Did I lie?

No.

How old is your PC, anyway? No, not your oldest PC, your most recently purchased one. You run XP on that?

How much have you spent on PC harware in the past 2 years? Really? Interesting...

Actually, if your PC is more than a couple of years old, my Macintosh is faster than your PC ( I've recently upgraded at work, replacing my 4-year-old G4 ), not that it matters much... the software is better, that's what's important.

Ok, I'm done being serious in my feeding of a windows fanboy troll, so I'll say :

I wouldn't want my penis to grow any, I'd hurt my wife... ;-)... what, you can't go 4 hours? My gal married me because I kept her up *all* night and left her walking funny the next day...

Oh, wait. I'm still being serious. oh well...

Re:Hard to be a Mac user?

[javaxman]

No, there's no stats error there. Mac users keep their machines _longer_ than Windows users.

The 200Mhz PII which I use as a doorstop doesn't count.

I'm not talking about Mac LC's, I'm talking about 333Mhz G3 machines which run OS X just fine. Try running Windows XP on a PII of any clock speed. I dare you.

And people think Macintosh users are the fanatics... weird...

Re:Hard to be a Mac user?

[Jeremy Erwin]

Yes, if you want to experience the full panoply of Microsoft apps, you will have to install Windows. Funny, that.

(MSN Messenger has a mac client, though.)

Re:Hard to be a Mac user?

[Hawthorne01]

But security by "Who the fuck cares" does.

You realize, of course, that you contradicted yourself, right?

So the quality of code inside an OS has *nothing* to do with security?

Right.

Move along, folks, nothing to see here.

Re:Hard to be a Mac user?

[Hatta]

No Viruses, No Trojans, a system that stays up pretty much indefinitely, and great, great applications

Yeah, but I hear the user experience changes drastically after 9 months.

Re:Hard to be a Mac user?

[EddWo]

Well what about the one that pretended to be a preview of Word 2004. It might have only been a simple shell script but it is still a trojan, it did exist in the wild and it did cause damage to a few idiot's computers (wiping their home folder). What about it makes it "not a trojan"?

macosxhints
slashdot

Re:Hard to be a Mac user?

[Anonymous Coward]

> I'm talking about 333Mhz G3 machines which run OS X just fine

They may run OS X just fine (except for the fact that Apple shipped them with 32MB RAM), but the vast majority of old Macs DON'T run OS X, and the owners DON'T buy new software. Therefore, Apple's installed base of ancient machines is largely irrelevant to the discussion of new APIs.

Re:Hard to be a Mac user?

[Anonymous Coward]

I never understood the "old Mac installed base" argument as a bragging point. It seems to indicate that Apple's latest gear isn't compelling enough to get Mac users into the store.

Also, the longer those people hold onto their crusty iMacs, the more likely it is that they'll be sucked into the Windows world.

Re:Hard to be a Mac user?

[scotch]

Good for the consumer, or good for the vendor, who you rooting for?

Re:Hard to be a Mac user?

[gewalker]

Sorry, but the killer app is the one written to support the business. If my business is automobile auctions, its the vertical market or custom application written to support -- selling cars at auction.

I can swap word-processor, spreadsheets, email clients, web-browsers, etc. to Mac or Linux, but I must have my auction application which is tied to Windows.

Lots of business have pretty deep ties into the generic Windows apps, that make it tough to move to anything else too.

BTW, if your line of business app runs on Mac, you're not switching, and if it runs on Sun, but not Linux, you're not switching either. No, what Joel was saying is the most people writing to .Net are using ASP.Net, meaning that the client is not locked in -- which is true if you are not IE dependent, which is somewhat difficult to avoid if you don't plan for it

Re:Hard to be a Mac user?

[man_of_mr_e]

XP runs fine on PII's, and i have several of them doing just that. They need more memory, but that's cheap.

There are literally 10's of millions of people out there still using Windows 98 on P1's and early PII's.

Also, i'd disagree that 333Mhz G3's run OS X "just fine". I've used earlier versions of OS X on imac's of that era and found it to be sluggishly hostile.

Re:Hard to be a Mac user?

[Anonymous Coward]

Both.

Is it good that I'm using a 333Mhz G3 Powerbook from 1998? No - the thing can barely keep up with my typing. I'd like to upgrade, but not to what Apple's currently selling.

Re:Hard to be a Mac user?

[Kiryat Malachi]

Put sufficient memory on it and OS X runs just fine on a 400 MHz G3 (which is what I happen to run OS X on). Having 512 MB of memory makes a huge difference; OS X is memory hungry as all hell.

I would consider it just barely usable at 256 MB, and totally unusable at 128. The lack of memory on old systems is more likely to be causing that sluggishness than the processor.

Re:Hard to be a Mac user?

[dmaxwell]

Try running Windows XP on a PII of any clock speed. I dare you.

Our school district has a number of 400Mhz PIIs that we added 256MB sticks of SDRAM to so that we could transistion them to XP from 98SE. For light use of Office and web surfing they work just fine. You wouldn't want to edit video on these machines but they are perfectly usable in most HS and MS classrooms.

Re:Hard to be a Mac user?

[flynt]

No, there's no stats error there. Mac users keep their machines _longer_ than Windows users.

In God I trust; all others must bring data.

Re:Hard to be a Mac user?

[man_of_mr_e]

Even worse, the old systems ran only at 66Mhz. Besides, 400Mhz G3's are only a few years old, compared to a PII which is about 8 years old.

Re:Hard to be a Mac user?

[FrYGuY101]

According to Google, 3% of the machines accesssing it's servers are Mac. 91% are Windows (Link goes to Google's Zeitgeist).

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:Hard to be a Mac user?

[Anonymous Coward]

While I am an AC, I don't know why this wasn't modded as Funny. Because it is extremely so.

Re:Hard to be a Mac user?

[Anonymous Coward]

I just today upgraded a G3/333MHz iBook with 320MB RAM to Panther. Speed for browsing and e-mail is quite close to my G4/533 with 1.2GB RAM -- certainly closer than I expected.

I've worked in IT for >20 yrs, used DOS and Windows at work and home for >15. About 5 yrs ago, I switched to Macs at home. What a pleasure! It was as if I had been on a 20-mile hike, and finally got the rock out of my boot. At last! Every step isn't painful!

Re:Hard to be a Mac user?

[Kiryat Malachi]

400 MHz G3s are roughly 5.5 years old, having been introduced in January of 99. The PII is roughly 7 years old (released May 97).

Re:Hard to be a Mac user?

[kannibal_klown]

Well, depending on what you define a "great" game (as there's so much sh!t out there now), I'd say Unreal 2004.

I'm a recent convert, but no zealot. I use my Wintel desktop for the occassional game or if I need to work on a Visual C++ app for work.

But I use my Powerbook for everything else, including Java development.

Games aren't top priority anymore for me. Sure, I'm addicted to "Thief III," but buyond that there's very little that appeals to me.

Re:Hard to be a Mac user?

[Chester K]

But Mac users keep and use their machines for a _lot_ longer- they're actually more like 10% of users.

Bullshit. Google has possibly the most unbiased OS survey (who doesn't use Google?!), and even they say that only 3% of the market is Mac.

Re:Hard to be a Mac user?

[Anonymous Coward]

Mac users keep their machines _longer_ than Windows users.

Probably because it's so much cheaper to upgrade a windows box to the latest, than a Mac. Not to mention that Windows is a LOT more backwards compatible than Mac OSs are... you don't have to re-buy all your software when you upgrade your hardware.

Re:Hard to be a Mac user?

[Doubting Thomas]

You need to work on your deadpan delivery, man. I was halfway through a retort about how you need to get out and try more software before I realised that this was sarcasm.

Re:Hard to be a Mac user?

[1u3hr]

Name one great game that came out in the past six months that works on your Mac?

If you want games, get a console. Other than an occasional Solitaire session, I don't play games on my computer. My daughter plays lots of Flash games though.

Re:Hard to be a Mac user?

[mandalayx]

Did you read the article *immediately prior* to this one?

He praises Firefox 0.9 and says MSIE sucks.

He may be pro-MS, but to call him a zealot spreading FUD seems premature.

Re:Hard to be a Mac user?

[JamesKPolk]

That may be true, but I would argue that no smart businessman uses for his business software he cannot control.

If you can't take your software with you as you adapt to a changing environment, then you're going to be in big trouble sooner or later.

Re:Hard to be a Mac user?

[SEE]

Even if the 2004 numbers come in at double last year's, there will have been fewer than 41 million Macs sold, worldwide, 1994-2004, by the Apple 10-K SEC filings.

Combined 2001-2003 non-server PC sales are 423 million (Gatner Group numbers). Ten percent of 423 million is 42 million, or more than all the Power Macs that will have ever been sold by the end of this year.

So, if the number of PCs in service is less than 90% of the last 36 months' sales, and the number of Macs in service is somewhere around 100% of all PowerPC Macs ever sold, Macs might make up 10% of the installed base.

How many 4400s have you seen in service lately, and how much new software has been bought for them?

Re:Hard to be a Mac user?

[stefanb]

This old argument about Mac having no apps is very old, very tired, and very tiresome.

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:Hard to be a Mac user?

[Anonymous Coward]

FU

Re:Hard to be a Mac user?

[Anonymous Coward]

I'd almost believe you weren't a troll if you were griping about desktops, but laptops?

You can get a refurbished one (still with full warranty and the option to buy AppleCare) from Apple for $1049. And that is not a good deal how? Oh wait, it is a good deal. Silly troll, go troll somewhere else.

Re:Hard to be a Mac user?

[Anonymous Coward]

No it isn't.

Based on the topic covered in the overall article, the section should have been called "Why Sun and Apple Can't Sell Computers (Yet)"

Both have browsers, so both should do better in the future by Joels logic.

Re:Hard to be a Mac user?

[Anonymous Coward]

http://www.winhistory.de/more/386/xpmini_eng.htm

Re:Hard to be a Mac user?

[Mongoose Disciple]

So the quality of code inside an OS has *nothing* to do with security?

No, I'm not saying that at all. However, to a large degree, any statements about the quality of the code from a security standpoint are, by necessity, speculative.

Saying that OS X is immune to viruses and trojans is like saying my umbrella is great if I never take it out of my house and into a rainstorm. It might very well be, but because it's never seeing rain, we don't know for sure.

See also: the episode of the Simpsons with the rock that keeps tigers away.

Re:Hard to be a Mac user?

[kannibal_klown]

Depending how far you go back, PIIIisn't that old.

Sure, it came out like 8 years ago, but it was the standard for a while. They were still churning those things out like 5 years ago.

And if I'm not mistaken, that's about when the G3 400 came out.

I'm a recent Mac convert (not a zealot), but I have to agree that x86 scales a little better. An older PC can run XP (provided it has enough RAM) better than an old Mac can run OS X. Then again, I think OS X is a better operating system than XP (though XP never game me any problems).

However, I don't have any experience with Linux on my Mac yet, so I can't comment on that.

Re:Hard to be a Mac user?

[Lodragandraoidh]

I have 4 machines (not counting my kids and my wife's) - only one of which is a windows machine. All the rest are running Slackware Linux.

What does that lone Windows box do? It is just a glorified entertainment system - playing games that I can not run on Linux - or if they do run on another OS - I can't afford (i.e. a MAC), playing music and movies - most of which I could make work under Linux if I cared to spend the time. With the advent of perfectly usable open source business and creativity applications makes owning a windows box less of an imperative - in fact it could probably be replaced with a MAC - if I had the money.

On the other hand, my linux boxen are where the rubber meets the road. One is my workstation - thin client mostly - though I do some Python development on it for stand alone applications. One machine is my server; runs Zope - which I use as my development framework; 99% of my development efforts in my network are on this box - and all of the workstations on my network immediately benefit from thos efforts. The last machine is a firewall for my network.

Thats it. Joel is spot on, with this paradigm shift Microsoft is betting the farm on distributed applications, while the rest of the world is going toward web based applications. The nail in the coffin will be when browser developers build extensions into the browser to allow fast graphics programs that leverage underlying hardware in near real time, as well as abilities to control aspects of the browser - while allowing the user to override the application choices. Once that bottleneck is broken, the browser will become the interface of choice for most development.

Re:Hard to be a Mac user?

[Anonymous Coward]

So now it's... what... 5.3 inches?

Sorry. Had to be said.

Re:Hard to be a Mac user?

[bar-agent]

C'mon, you know you can't trust those stats, what with browsers disguising themselves as each other all the time.

Re:Hard to be a Mac user?

[MentosPimp]

Not to mention some people can be a Mac user
and still access web pages from other platforms more often.

I have to use win2000 at work.
I have a WinXP gaming rig.
I have a rig with a Win 2000 install
And a Linux install
And I have an iBook,

Despite being a 'Mac User' stats like the grandparent would say that I 'use' it less than 5% fo the time. Which is false. The majority of my browsing is on Windows and IE at work.
So, you cant really count browswers or browser hits as equal to 'users'

Re:Hard to be a Mac user?

[Anonymous Coward]

I just love it when Windows users deride Macs as toys and yet the first argument to buy a Wintel is usually: GAME

Re:Hard to be a Mac user?

[Anonymous Coward]

You are ignoring a significant subset of {hackers, crackers, virus writers} that take hacking an un-hacked system as a challenge. Sure, the script kiddies who have no real skill probably won't be able to do so and therefore probably won't care. However, there are smart virus writers who think that being the first virus writer on Mac OS X will raise their stature amongst other virus writers. The fact that noone is successful is a huge plus for OS X security model.

As for emulations, there are usually equivalent OS X softwares (not necessarily a port of a program). When people says there are tens of thousands Windows softwares, usually they forget to mention that there are hundreds of text editors, which you need only one or two. You didn't elaborate why your friends used emulation, but sometimes the reason is not the unavailability of OS X equivalent, but rather, they don't want to spend money to re-buy software titles, or they get locked in a proprietary format, or they don't know how to find an equivalent software. A lack of software is usually an overblown issue, especially for non-business users and gamers.

Re:Hard to be a Mac user?

[FrYGuY101]

What about Windows users who, at work, have an Apple? I know more than a few who have that situation.

Like I said. It's AS CLOSE AS YOU CAN GET. Not perfect. Though I highly doubt there's a 7% difference like the great-great-grandparent claims...

Re:Hard to be a Mac user?

[Anonymous Coward]

Anyone in to FPS can tell you that there isn't a FPS in the world that plays better on a console the on a PC. Even Halo for the PC kills Halo for the Xbox. So you don't do anything other then surf the web, check email, and use Photoshop, then keep you Mac. I however, won't use it unless it has Windows on it. Peace.....

Re:Hard to be a Mac user?

[MentosPimp]

I highly doubt the difference is 7% also.

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.

Re:Hard to be a Mac user?

[JamieF]

>What about it makes it "not a trojan"?

Who said it (the MP3 trojan referenced by the parent post) wasn't a trojan? I said: "You know that trojan wasn't actually found in the wild, right?" That would be your clue that I think it is in fact a trojan.

Now, this other trojan is different. Clearly it too is a trojan. The distinction is that the one you mentioned (fake Word prevew) apparently was found in the wild, which makes it a real threat, as opposed to something that an AV company made up so that they could declare victory against it. (Actually I wasn't aware of that one; if I had been I would have pointed that out as a more viable argument against "no trojans" than the not-found-in-the-wild MP3 trojan.)

Re:Hard to be a Mac user?

[devilspgd]

Except for the one on the newly released Beastie Boys CD, right?

A program that silently installs and does things to a user's computer that they don't want, without the user's knowledge, when the user is just trying to play some music sounds like a trojans to me...

Re:Hard to be a Mac user?

[DeadScreenSky]

Name one great game that came out in the past six months that works on your Mac?

Maybe I am just being a whiny bitch and/or ignorant, but has one great game came out for even the PC in the last six months? Not really defending the Mac, just lamenting the state of computer gaming...

(I am sure some people would suggest some Brand New Rapid Mouse Pointing Action Adventure Game, but FPS games aren't really my thing anymore. Blah.)

Good idea

[Mnemia]

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.

Re:Good idea

[Carnildo]

The problem is that Microsoft broke it once for .NET, a second time for Longhorn, and is making no guarentees they won't break it again.

Apple, on the other hand, only broke the API once, with the transition from Classic to Cocoa (the MacOSX API), and even then, they did their best to maintain compatibility, with Carbon.

Re:Good idea

[cmowire]

Not quite.

MS would do OK if they were to give away the stuff necessary to run Longhorn apps on older versions of Windows.

The problem is that when Longhorn is out, you will *still* need to wait for several years before you can actually write apps that use it.

MS *could* have provided Longhorn-API functionality for older versions of Windows, but that really ruins any incentive to move up to Longhorn, so their hands are tied.

*sigh* The problem is that Linux needs to figure out how to make a good desktop environment. Given how piss-poor people who *try* to create a good desktop environment do, I've not got much hope there.

Re:Good idea

[Anonymous Coward]

Did you notice that they quietly bought Connectix, and with it Virtual PC, a few years ago?

I think the future is quite obvious.

Their new operating systems won't be backwards compatible, but will instead be able to run a backwards-compatible operating system inside a lightning-fast emulator for legacy applications.

The best of both worlds. We'll be using fancy 64-bit processors running an OS with a fancy, stable .NET-like API, while all our legacy applications will continue to run, on nice little isolated virtual processors.

Re:Good idea

[BeerCat]

Apple, on the other hand, only broke the API once, with the transition from Classic to Cocoa (the MacOSX API), and even then, they did their best to maintain compatibility, with Carbon.

Mostly true, but the original Carbon API (IIRC) chopped around a quarter of the cruft that had built up between System 1 and OS 8. There are some apps that don't work well with Carbon (Excel 5, but not Word 6, for example), presumably because they used some of the deprecated API calls.

So in effect, they chipped away at the API by making Carbon, and then made a new one for Cocoa.

Re:Good idea

[IrresponsibleUseOfFr]

The fact that Microsoft is breaking backwards compatibility is the exact reason that Joel says they lost the API war.

Developers, more than anything else want a stable platform to develop for. Microsoft's top priority in the past was to provide a stable platform (stable in the sense that all old-code worked on the new platform). Developers are users too. I would be really pissed off if I upgraded some app and it wasn't able to work with my old data. Why is there a different expectation when I code for an API? Why should I have to rewrite my code because the vendor discovered some better way of doing it? I probably went to a lot of trouble to get that code working in the first place. Make sure it performs well, possibly works around a couple bugs that took me hours or days to figure out, and now the vendor comes along and breaks it and I have to learn some new way of doing it and deal with new, yet undiscovered bugs. fsck that. If it was an app, I would ditch it. If it was a platform and had a choice, I'd ditch that too.

What platform are people turning to? Joel's answer is the web because HTML/browser represents a very stable platform. I won't reiterate his arguments here. But, I do feel that he has a point. He is a smart guy, and I could see it come to pass. That doesn't necessarily mean it will. Smart people have been wrong before :)

With Joel's world view, how Linux will make inroads on the corporate desktop is simply by having a good web-browser and being free. Features on the client will become irrelevant.

All I can say is prediction is hard, especially when you are trying to predict the future.

Re:Good idea

[IamTheRealMike]

That's not really accurate - as Joels article pointed out Apple have a much worse track record of backwards compat than Microsoft do. Apples Java team in particular need to be smacked about a bit - they're broken compatability with updates which they then pulled from the update service, leaving some users trapped in an incompatible limbo with no way for developers to get their system into the same state as their users.

Painful. Not to mention all the apps that stop working whenever major upgrades to OSX are released. I know most of them are eyecandy hacks, but even so, such things exist for Windows (eg WindowBlinds) and rather than break their apps Microsoft hired the guys who did it!

Re:Good idea

[Jerf]

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.

I agree with this, and I agree with Joel as well.

Maintaining reverse compatibility is the right thing to do today. It's the right thing to do tommorow. It's the right thing to do next week.

But it is not free, and the costs grow exponentially with each iteration. Eventually, "exponentially" will beat anyone... even Microsoft.

They've actually trapped themselves extra badly because each successful iteration ingrained the expectation from their customers that much more that the next iteration too would be backwards compatible. The hole just gets deeper every time.

I've had this discussion with other developers before, who insisted the users need backwards compatibility. My counterargument was just this, a day will come, sooner than you think, where you won't be able to provide it. Personally, I think we need to level with the users sooner, rather then later: We can't provide it indefinately, so let's at least hold the option open of breaking compatibility. (I'm not saying to break it for no reason, just that you will have to, the logic of modern programming demands it, so be ready.)

As usual, if you sensibly prepare for it in advance it's easier than if you are suddenly shocked by it.

Re:Good idea

[Anonymous Coward]

Excel 5/Word 6 are not "Carbon", they are "Classic" applications, that run in a MacOS 9 VM. Like many other old Mac programs they don't work because Apple made small changes in the API between System 7 and MacOS 9.

Apple's back-compat has been pretty good, but not nearly as good as Windows, where any old major app WILL run.

Re:Good idea

[DissidentHere]

Isn't this what .NET will allow them do? MS introduces a layer of abstraction that allows the same code to run on old and new MS OS, 32 and 64 bit, and MS can say 'Look at how flexible we are' (Oh, I write this on a Mac, but develop for MS and *Nix)

I think MS has enough $ to push .NET, wait a few years and offer a certain level of platform independance. The didn't get rich by being stupid, they've got a 5-10 year plan and they know that there are _many_ business that are still using Win98 or NT 4.0 that don't plan to upgrade in the near future. They see an opportunity to run Office 2008 and Exchange 2008 on P1s running Nt 4.0 (bloat issues aside for now).

I'd like to see Linux take over on the desktop, but let's face it, we need to increase the profit motive and get more marketing and organization. Joe Blow is not going to take anything but Windows until he's told to and it is easy to get all the same 'stuff' for less (the cheaper part is obvious to us).

Re:Good idea

[Javagator]

Developers, more than anything else want a stable platform to develop for

As a developer I have to disagree. Managers may want a stable environment because they don't want to re-write their existing applications. In his article, Joel says porting to .Net "will not benefit a single customer and therefore will not gain us one additional sale". As a developer, I want to know how much more productive will I be in .Net. The answer is, a lot. I've developed in C++/X-Window/Motif, VC++/COM, VB6, and (just for fun) C#. COM is the most confusing and awkward mix of macros, templates, libraries, and obscure "wizard" generated code that I can imagine. Even the X-Window environment was much more productive. Moving to C# would probably double my output and make my job a lot more fun.

Re:Good idea

[RetiredMidn]

as Joels article pointed out Apple have a much worse track record of backwards compat than Microsoft do

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:Good idea

[mindstrm]

Maintaining perfect backward compatability leads to bloat.

Those eyecandy apps you talk about, which use private interfaces that apple makes very clear will NOT necessarily be supported or even acknowledged in future versions or updates... most mac users don't install those.. and they are *eyecandy*... they don't have a whole lot to do with functionality, and do have a lot to do with inconsistency and bloat.

Most mac users do not install eyecandy.

I'm not sure what situation you mean with java.. can you elaborate?

Re:Good idea

[Red Pointy Tail]

Yeah, but now that you've invested your time on .NET and are very productive, are you willing to throw out for WinFX, Avalon, XAML, which is apparently as compatible to .NET as VB6 is to VB.NET. Almost everyone agrees that .NET is good, so why can't they just extend it for Longhorn instead of ripping it all out? I don't see major overhauls like this happening to Java libraries.

Re:Good idea

[Anonymous Coward]

Hmm. You see, IBM has done a pretty good job of this backwards compatibility thing for System/360 over the last four decades. If one really "can't provide it [backwards compatibility] indefinately [sic]", one really must wonder how it is one can run forty-year-old unchanged binaries on a modern z/Architecture machine.

Re:Good idea

[KlausBreuer]

>I've had this discussion with other developers before, who insisted the users need backwards compatibility. My counterargument was just this, a day will come, sooner than you think, where you won't be able to provide it.

Really? On my Linux box, I have a DOS emulator running. Just for kicks, in that DOS emulator is a ZX Spectrum (USA name: Timex Sinclair) emulator running, which perfectly runs the game 'Jet Set Willy'.

Now that you could call backward compatibility over 25 years, and it's working great.

So you have a new API? Well, looks like you'll need a called-on-demand conversion layer for the old API.
Sucks, yes.
But a *lot* of people are using Windows, and a huge amount of them have *not* updated. A lot of offices are using NT. A lot of users are still on 98. Why change? All the software runs on it, all the games run on it, all the new hardware works with it - why should they switch?

So if you now come and say: "Everybody, everybody must update! You need new Hardware, new Software, new OS... you'll be spending a loooot of bucks!", I don't think that you'll be overrun by enthusiastic customers.

Why are people not switching to the Mac? Because their software doesn't run on it. Now it doesn't run on the new Windows, either? Well, they might just switch, even if the hardware is more expensive.

Switching anyway? Well, you don't have to buy new hardware, and there's a lot of software which looks nearly like what you're already used to - on Linux. Why not switch there instead?

You can hold a market in your iron grip if they all need compatibility with you. Drop that and you loose.

Re:Good idea

[trueshot]

Joel's answer is the web because HTML/browser represents a very stable platform.

This article makes me wonder. I am have huge numbers of my clients being infected with terrible spyware. So bad, I can't clear them up. Adaware plus Spybot plus TrendMicro Housecall used to do the trick. Now, they don't even make a dent. We are exclusively a webbased application with an enormously complex user interface. (more than 800k in Javascript for a single page). Is Microsoft purposely marginalizing the "safeness" of the web browser?

Re:Good idea

[PantsWearer]

Is Microsoft purposely marginalizing the "safeness" of the web browser?

That's an interesting question. In truth, I doubt that it's purposeful on their part. It's more of a negligence issue than anything else.

If I were you, I'd start targeting Mozilla-derived browsers and try to get my clients to switch over.

Re:Good idea

[Anonymous Coward]

Yes, there is no other alternative for Microsoft. They are in catch22 situation.
Because most of the code is insecure by DESIGN.

And don't be suprised if Microsoft starts selling open source software products in future.
Because selling closed source software products is unethical, if not illegal as on date.

Marc was wrong

[Anonymous Coward]

So is Joel.

The browser is a terrible interface.

Anything that cannot store state is a security risk waiting to happen.

Re:Marc was wrong

[jon3k]

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.

Re:Marc was wrong

[3) profit!!!]

as soon as your keys leave the keyboard

It would be kinda hard to type on a keyboard with no keys... ;)

Re:Marc was wrong

[Anonymous Coward]

Based on IP address as well as some other odds and ends

Gee. That works well when there are multiple people using the same IP (e.g. a firewall). Not. ;)

Re:Marc was wrong

[mabinogi]

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.

Re:Marc was wrong

[Anonymous Coward]

You might know a thing or two, but not much beyond that. Stardard session tracking is fine if all you need is to know the forward progress through a site, but if you have forms and want the user to be able to use the back button, that all goes out the window. Half the browsers out there won't reload pages when a user goes back, even if meta no-cache tags are used. Then the state of the form variables is undefined - depending on browser their either in their original value or the value they were set to when the user left the page. And there's many other corner-cases that can cause your webapp to fall into states you thought were impossible.

It's not impossible to deal with, but it's very kludgy with different solutions for different platforms, whether the user has javascript enabled, or if you can't handle storing all the users' session data server-side. Also, the question of what the user expects the behavior to be is even harder to answer then the technical questions.

In a nutshell, session tracking sucks on the web because the webbrowser will let the user do things without telling the server what's happening.

Increased Irrelevancy, however.

[metatruk]

Quoth the article:

Although there is some truth to the fact that Linux is a huge threat to Microsoft, predictions of the Redmond company's demise are, to say the least, premature. Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute. So don't be so quick to write them off.

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.

Re:Increased Irrelevancy, however.

[Anonymous Coward]

if IBM is irrelevant, why does it receive so much attention on Slashdot?

Re:Increased Irrelevancy, however.

[xanthan]

IBM is far from irrelevant. Global Services is a $40B business unit with the ability to make and break technologies on a whim -- and they don't just pick/bias IBM built technologies either. They pick what's right for the job and the customer its going to.

The IBM technology arm continues to innovate a lot of core technologies. They aren't big and visible to the general public, but they do affect how the world spins. You aren't the world's 17th largest company and become "irrelevant."

Re:Increased Irrelevancy, however.

[JamieF]

>they will become increasingly irrelevant like IBM has.

Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.

Re:Increased Irrelevancy, however.

[man_ls]

IBM is quite possibly as far from irrelevant as you can get.

They could go toe to toe with Microsoft, probably even beat them, in any kind of a war. They've been around 3 times as long, have that much more cash, and have the weight of name to throw around with that cash.

When IBM Global Services says something is good, it is good to every corporate manager and director in the country, with few exceptions. That's why they are such a powerful ally for the Linux cause: when IBM Global Services says Linux is ready to be used on the corporate desktop, it IS READY.

Re:Increased Irrelevancy, however.

[metatruk]

Oh, I believe IBM is doing some important things, and is not irrelevant. However, IBM is *more* irrelevant now than they were 20 years ago, when they were the *only* choice for a lot of products. IBM competes with everyone now, in all of their industries.

Contrast that with how MS is. They compete with very few companies, because their basic mode of operation is anti-competitive.

MS is relevant even if you don't even use or purchase their products. They control almost everything.

I can mostly ignore IBM.

Re:Increased Irrelevancy, however.

[ndykman]

Heck, even ask MS how "irrelevant" IBM is.

It'll be interesting to see just how much influence IBM will have over Linux, and what directions they'll push it in. And yes, I think IBM can influence Linux. When you've got programmers (paid, no less), you can make stuff happen. In the kernel, in the surrounding tools, etc.

Re:Increased Irrelevancy, however.

[usrid0]

Why don't you compare stock prices between IBM and M$.

Re:Increased Irrelevancy, however.

[fijimf]

Why don't you compare stock prices between IBM and M$.

You should actually.

Look at return over the past 5 years. Not just price -- don't forget about IBM's (and more recently MSFT's) dividends. I think you might be surprised.

Re:Increased Irrelevancy, however.

[Big Jason]

IBM == I've Been Masturbated

Re:Increased Irrelevancy, however.

[Anonymous Coward]

Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.

Or go work for IBM and see from the inside how quickly they're trying to make themselves irrelevant.

I think the GP was talking about IBM being irrelevant to the "desktop" market, to which I heartily agree. Yet as you point out, for backoffice applications IBM still has a very strong position. I personally LOVE DB2, and WebSphere is pleasant enough (but has some frightening unfinished corners inside the code -- do some random decompiles to see for yourself).

Let's leak some information about IBM's internal structure. (This isn't secret to IBM's longtime customers or competitors BTW.) IBM's *best* software comes out of Server Group, not Software Group. Server Group is *old* (mainframes), and has lots of down-to-earth managers that have been around the industry for a while. Software Group OTOH has essentially never created a cool application on its own: it buys something and then rebrands it (Lotus, Rational, WebSphere). Software Group's management culture is very different than Server Group's, slimy-er if you will, more like fresh MBA graduates and less like an experienced engineering group. DB2, while branded Software Group, was originally Server Group and follows that management style.

I just came out of a team (Tivoli) that had Band 8 developers ($95,000 salary range in the flyover states) that (I shit you not) were just starting to figure out how to use a ResourceBundle. They didn't know that in production environments you have to support other languages, or that WSAD and WebSphere are very different and require separate testing. None of them even knew how to install the code they were working on onto a Unix-y system, even though it was mandated that it had to run on five platforms. (Guess which platform they did their development on?) That level of inexperience -- akin to high-school hobbyist code -- shouldn't be compensated at that level, but Software Group management doesn't have the engineering emphasis in their culture to weed that crap out.

So yeah, I kind of support the GP's position: IBM is still going very strong on momentum, but the only serious "invention" I saw going on was basically out of the research and mainframe groups. IBM won't ever go away, but they aren't really leaders anymore.

This was not an unusual case

[craXORjack]

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.

But a much more interesting example is when they checked to see if DR DOS was running and flashed a FUD-filled error message to the user. Mmmmm... FUD

Re:This was not an unusual case

[Anonymous Coward]

Remember, "It's not done till Lotus won't run!"

Re:This was not an unusual case

[TheRealSlimShady]

But a much more interesting example is when they checked to see if DR DOS was running and flashed a FUD-filled error message to the user.

...in a beta version of the operating system. It never showed that message in a released version of the OS. While it might have been FUD, it was also true - Windows wasn't supported on DR DOS and Microsoft couldn't guarantee that it would run correctly. (Yeah, yeah, I know that the code was still **in** the released version, not active)

Re:This was not an unusual case

[Radical Rad]

Nope not just a beta version. It was in at least one OEM version because I saw hundreds (at least, maybe thousands) of machines loaded with it as part of our custom configuration process at the value added reseller where I worked in the early to mid nineties. I was working in Quality Assurance at the time and did not want to allow the machines to be shipped this way but was ordered to by management who said they cleared it with the sales rep for that account.

Here is a link concerning the situation in case any readers are not familiar: Caldera: MS Cheated in DOS War

Re:This was not an unusual case

[TheRealSlimShady]

Even that article states that it was in a beta. You are the first person I've ever read about that claims to have seen it in a live version of Windows. You were right to be worried about QA - you were shipping beta software.

Re:This was not an unusual case

[Radical Rad]

Well maybe it was a beta version rather than OEM. Ten years is a long time to remember every detail, but I assure you that we shipped it and lots of it.

Re:This was not an unusual case

[Anonymous Coward]

I thought it was "DOS ain't done 'til Lotus won't run".

Re:This was not an unusual case

[ttfkam]

It was a public beta. Testers saw this message a lot and contacted Digital Research about it. Digital Research requested a copy of the Windows beta. Microsoft refused. After the public release, DR-DOS was patched in a week, but the PR damage had already been done. Even long after the error message went away, pundits were still harping on about potential compatibility problems even though no actual problems showed up. Only that artificial error message, purposely cryptic, needlessly worrisome, and produced by Microsoft to illegally kill off a competitor.

Re:This was not an unusual case

[Anonymous Coward]

For me, the question is was this the work of _MICROSOFT_ (as in, did the order come from the board of directors) or was it the work of an individual coder (or maybe a small team of coders?) - Maybe even inserted in the beta code as a joke.... I guess we will never know. But To assume that the order came from board level may not be correct.

After all, as a coder, Ive done some funky stuff that i would probably be sacked for if the board ever found out...

Re:This was not an unusual case

[ttfkam]

Granted, an individual coder could have written the code. However, the code QA team would have had to avoid testing with the other popular DOS at the time to have missed it. The integration team would have had to avoid DR DOS as well in their testing. The production group would have had to ignore reports that came in from the field that there was a problem with DR DOS. The beta distribution group then refused to send a copy of the beta to Digital Research so that they could "fix" DR DOS.

Bottom line is that it wasn't one coder. This was multiple people in multiple departments in many different capacities where none of them did the right thing. Was it a directive from the board, a group of executives, or the dominant culture at Microsoft? Who knows. Frankly, who cares? It was certainly deliberate.

3 stories in a row ?

[Garabito]

3 stories about Microsoft or someone related to MS?

Come on editors, there has to be better material!

Re:3 stories in a row ?

[Anonymous Coward]

It's 2 stories, you Insensitive Cl.... ah f*k it. too old. nope wait, instinct comes back. CLOD!

Re:3 stories in a row ?

[Anonymous Coward]

ah, the trifecta...

Who is "joel", and why should I care what he says?

[Anonymous Coward]

Title says it all.

Kids

[Anonymous Coward]

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

Re:Kids

[jb.hl.com]

Linux isn't really that much easier to download than Windows, if you Look in the right places :)

Re:Kids

[lucas teh geek]

Wow! man you are a l33t h4x0r

moron

Re:Kids

[Clansman]

Actually, you don't need to download Windows, it's usually already installed.

I wish they'd document some of the improvements

[Marxist Hacker 42]

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.

Re:I wish they'd document some of the improvements

[Ayende Rahien]

Dude, what prevents you from taking any one of the dozens of Zip implementations out there?
There are several packages that are open source Zlib comes to mind, frex/

Re:I wish they'd document some of the improvements

[Marxist Hacker 42]

Working for government means I have to work within "ODOT Approved Software List". As far as ZIP is concerned, that limits me to either the built-in XP ZIP library, or WinZip. Anything OSS would have to go through a lengthy approval process that would exceed the number of hours I have left on my contract. Part of the trade off of working for a buracracy- but heck, it's more steady than private industry right now.

Re:I wish they'd document some of the improvements

[arkanes]

Think they would care that zlib is the back end for the WinXP zip library? (Note that WinXP had to be patched for the zlib exploit a year or so ago)

Re:I wish they'd document some of the improvements

[Ayende Rahien]

> Think they would care that zlib is the back end for the WinXP zip library?

Shouldn't they? If so, why not?
Why should *you* care? The code is there, it's compatible with WinXp, the license is nice. USE it.

>(Note that WinXP had to be patched for the zlib exploit a year or so ago)

Just like any other user of Zlib?

Re:I wish they'd document some of the improvements

[arkanes]

Did you read the parent? It's because theres an approved list of software. If zlib is the back end for an item thats on the approved list, maybe he can use it without going through the entire red tape process?

Re:I wish they'd document some of the improvements

[Marxist Hacker 42]

They didn't even approve XP until October 2003- and I'm sure their analysis didn't go that deep. It's amazing how much security we have in this state agency- and it is State, not Federal. Of course, ODOT is the biggest department Oregon has, especially since consolidation means that it absorbed the DMV a couple of years back. But still- security and protocol is downright paranoid around here.

Re:I wish they'd document some of the improvements

[Marxist Hacker 42]

Possibly- but I kind of doubt it. At this point though, ODOT already has 5000 licenses for Winzip 9- more than the computers to run it on- so they won't miss a couple. That, and I've only got a week left on my contract- it would take me that much time to learn zlib and get it working properly with VBA. Where if the XP version of Zlib (zipfldr.dll) was DOCUMENTED, it would be a snap and I wouldn't have to install the Command Line Add On on the end user's machine (this is a SINGLE customer).

Re:I wish they'd document some of the improvements

[Marxist Hacker 42]

Zlib isn't listed separately on my software list- which it would have to be for this use. Where if the XP version of Zlib was DOCUMENTED, I wouldn't have any red tape at all, and nothing extra to install on the end user's machine.

Re:I wish they'd document some of the improvements

[reanjr]

Companies like MS (and really any big API company, OSS excluded) do not document functions so that they can change the interface later. Oftentimes, if it is something as simple as the zip thing, they do not find the benefits to outweigh the risks of a later change breaking compatibility.

I would imagine one could figure out how the dll works by dumping some info from it and playing around (or doing a google search). This allows the vast majority of developers (I know, it probably does not help YOU) to use the undocumented feature without MS taking flak for changing it later on.

Using APIs is like using a scripting language. Great time-saver if the feature is implemented and a huge pain in the bum when it's not. You could always implement the zip functionality yourself ;)

Re:I wish they'd document some of the improvements

[EddWo]

Sound like in this case it is not deliberate.

"For example, the code that lets the explorer access Zip files is licensed from another vendor and we're not allowed to disclose how that works."

Larry Osterman

Re:I wish they'd document some of the improvements

[Marxist Hacker 42]

It doesn't help me more because I'm not allowed to do it as I don't know how to do it- if this was offsite for private industry I'd do it in a second- but actually, if I was working for private industry, I'd just go ahead, licence ZLIB, convert it to a COM object, and include it with the application install. Neither of these are options working for a paranoid state government agency.

I don't agree

[Ayende Rahien]

Yes, there is a lot of investment in old Win32 code.
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 .NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute, considerring that they *don't break backward compatability*.

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 .Net, and *that* is not something that MS could afford doing.

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

Re:I don't agree

[Anonymous Coward]

Huh? Firefox renders perfectly for me. I used to use opera, switching to IE when a site didn't render. Now I just use firefox, I haven't fired up IE in months.

Re:I don't agree

[Anonymous Coward]

The so-called breaking changes (he mentions .NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute

Moot! Mute means silent and unable to speak for oneself...

On second thought, I agree. Avalon, XAML, and all the rest of the quackery really can't speak for themselves. As XAPIs, they'd go nowhere without Microsoft's "Department of Marketting and FUD for Competitors" behind them.

*smirk*

Don't you wish you'd used the right word?

Re:I don't agree

[Ayende Rahien]

No, they would go a *long* way, because the *tools* for building those applications would support them.
And if I can make a snazzy new UI easily, I *would*.
So you would see a lot of fun apps just for longhorn, maybe with some backports for WinXP/2K.

The *serious* applications would remain neutral, but all the developer's toys (which are the funnest {yes, I know it's not a word} toys around) would be for Longhorn.

Re:I don't agree

[mabinogi]

> VB.Net is a new language, VB6 has reached its end, you might want to compare it to the transition from C to C++

Ok, I'll do exactly that.
When looking to move on from C to an object oriented language, I considered C++, but it's weird inconsistancies and "not quite C"ness put me off, and I instead decided that if I was going to have to learn a new language, and a new way of doing things, I might as well make the jump all the way to Java. I've never regretted that decision. Though this is not quite the same thing as VB6 and VB.NET. The most recent version of all C++ compilers still supports C, so C has not been abandoned, my decision to switch was based on a desire to learn a different development model, not a forced change due to the discontinuation of the product like the VB6 and VB.NET transition is for most people.

That's always the risk when you make it difficult to upgrade. They think "Well, if I have to go through this much effort to stick with company X anyway, why don't I see whether or not company Y has something better to offer, as the transition won't be any more painful"

Re:I don't agree

[Anonymous Coward]

By all accounts - Longhorn *will* keep the reknown MS' backward compatability.

You are completely correct. Longhorn will have both WinFX and Win32 APIs.

Joel Might Be Wrong

[xp]

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

Re:Joel Might Be Wrong

[Anonymous Coward]

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.

You mean with the same underlying problems.

Re:Joel Might Be Wrong

[kfg]

Joel confuses binary compatibility with API compatibility.

Anybody who has tried to explain to someone why WINE is not an emulator has probably had to confront this confusion face to face.

I recently got lectured that WINE would always have emulation overhead by a guy who was sitting there writting Win32 binaries . . . on his Linux box.

He still didn't get it when I asked him if he weren't concered about the emulation overhead when he ran those Linux binaries under Windows.

Some people have troubles with the abstraction layer between the physical machine and the logical machine.

KFG

Re:Joel Might Be Wrong

[Anonymous Coward]

You're missing the point - the problem is that Longhorn apps will not have backwards compatability (binary or otherwise), not about having older apps be compatible with running on Longhorn.

With MS's current plan, if you develop an application using Longhorn technologies such as Avalon, it will only run on Longhorn, you can't run it on older versions of Windows such as WinXP.

Re:Joel Might Be Wrong

[tolan-b]

mod parent up!

*burns karma*

Re:Joel Might Be Wrong

[xp]

With MS's current plan, if you develop an application using Longhorn technologies such as Avalon, it will only run on Longhorn, you can't run it on older versions of Windows such as WinXP.

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

Re:Joel Might Be Wrong

[JamieF]

OK, I'll bite. How is binary compatibility different from API compatibility? I suspect that this may differ from language to language and from static to dynamic linking...?

Are you talking about the difference between a new OS that supports older binaries with binary interfaces but which no longer provides an SDK to use the deprecated API? If so then I guess binary compatibility would be a subset of API compatibility - in C, binary compatibility would just mean that the linker would need to be able to do its thing, but API compatibility would mean that header files would also be needed.

I say that this may be a language-dependent issue because there are languages and binary formats for which the compile-time interfaces are in the same file as the runtime implementation. In these cases, the third layer (above the implementation and declared interface) is human-readable documentation, and just withholding that would be all you could do to try to get people to stop using the old API. But if they had documentation from another source (yard sale, eBay, etc.) they could still compile against the implementation files since those have the required interface info embedded in them. I'm thinking in particular of .NET assemblies and Java classes but there are probably plenty of other examples out there.

Re:Joel Might Be Wrong

[Anonymous Coward]

> But that is always the case.

It's not always the case. Most of the technologies that Microsoft has delivered in the past, like ATL or MFC that was mentioned earlier, run on many different versions of windows.

That is very useful for developers who use that technology to create their applications, because the developers can still sell those applications to users on a variety of different Windows versions, not just people who have a single version of Windows.

This is changing a lot with the Longhorn technologies. Unlike an application that uses ATL or MFC, a Longhorn Avalon app will not run on WinXP/Win2k/ME/98.

> What matters is that you can run DOS programs on Longhorn.

This is not what matters to application developers these days. How many DOS developers do you know?

Re:Joel Might Be Wrong

[ed1park]

Correction: It's a cleverly disguised ad for his commercial web app software.

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.

Re:Joel Might Be Wrong

[teval]

He doesn't really,

Look deeper into the Windows docs, you'll see a lot of the structures have different versions (before and after a certain revision), lots of useless archaic API which never get updated (converted to call the new API)

Even more recent things like DirectX suffer from this (well.. recent compared to the win16/32 mess)

Re:Joel Might Be Wrong

[kfg]

OK, I'll bite. How is binary compatibility different from API compatibility?

Strictly speaking binary compatability is a machine issue. Will this set of machine instructions run on this particular machine. Note that in the SimCity bug there was no flaw in the program logic and no conflict with an API. Physical memory barfed on what the machine instructions told it to do. The only reason it didn't barf under DOS was because DOS wasn't asking the machine to do much of anything, whereas Windows does.

When you write a program as a single executable and compile it you then have two things, a binary which is an actual "thing" which interacts with the physical machine, and the logic of the program, which is a pure mathmatical abstraction. The binary and the machine don't know about that abstraction, they just know to put this here, move that there, increment that, etc.

An API is the next level of abstraction up. While there are exceptions it is software that talks to other software, not the machine, and while it may be implimented in binary form (which must, obviously, run on the machine) it is the logical structure of the communications between the software that is actually the API, not the binaries themselves. Just as your code logic is distinct from the compiled binary.

So you can type "make me a window" instead of the actual code to draw a window, and the code of the API sends a signal to the OS to run the window drawing code, which is in the OS itself, not compiled into your own code.

So API compatability means sending the right signals at the right time. The binary may run fine, and yet the program may fail due to API incompatibility.

You type "make me a window," which sends a "39 Hike!" to the OS, but it wants a "1" to draw a window. "39 Hike!" tells the OS to send all your personal data to Bill. Everything runs flawlessly, but the result is not what you intended. Binary compatible. API incompatible.

Are you talking about the difference between a new OS that supports older binaries with binary interfaces but which no longer provides an SDK to use the deprecated API? If so then I guess binary compatibility would be a subset of API compatibility - in C, binary compatibility would just mean that the linker would need to be able to do its thing, but API compatibility would mean that header files would also be needed.

. . .if they had documentation from another source (yard sale, eBay, etc.) they could still compile against the implementation files since those have the required interface info embedded in them.

In the case of Linux and WINE I'm talking about an OS that is distinct from the Windows OS and which does not share its APIs. Things are simplified by the fact that they both share a hardware architechture, Intel, and that's why no real emulation is necessary. They both work to the same machine instruction set. For that matter they're both written in the same language, C (at least 98 is).

Now, if you want to run Windows programs under Linux you can do it the eBay way. Buy a license for Windows. Then you can run Windows itself under Linux in a virtual machine, the VMware way. This isn't actually emulation. It's running two OSs simultaneously. Ok, so it eats up system overhead like an emulator, so from the end user point of view it may amount to the same thing performance wise, but it still isn't actually emulation. It's identity. An Intel OS running on Intel hardware.

But let's you don't want to support that overhead, or say that you're running Linux in the first place because you don't want a Windows license ( crazy, I know, but just suppose), but you're compeled to run MS Office anyway, or you want to run a Windows only game. The essential thing standing between you and doing that is the Windows API.

You send the main executable to the cpu, which starts to run it, which sends out a signal to. . .Windows -- and the whole thing barfs instantly. You're AP

Re:Joel Might Be Wrong

[Rick the Red]

With MS's current plan, if you develop an application using Longhorn technologies such as Avalon, it will only run on Longhorn, you can't run it on older versions of Windows such as WinXP.

As Joel points out, in 1990 this wasn't a problem, as the new PC sales were always more than the current installed base. Windows apps won't run on DOS? So what? There's now 20 times more Windows PCs than DOS PCs. Wait, make that 200 times. No, now it's 2000 times. Hold it, what's DOS?

Joel's put on all this is that times have changed and Longhorn may take years to simply match the XP installed base. Microsoft disagrees, and I believe they're counting on DRM to drive Longhorn sales. DRM has the potential to literally force everyone to buy a new, Government-approved (if not mandated) PC with Longhorn. DRM will be used to fight spam ("I won't read it if I can't verify the origin"). DRM will be used to deliver music and movies ("I won't play it if it's not legal"). DRM will be used to verify on-line payment ("I won't sell it to you if you can't prove this is really your credit card"). DRM -- and thus Longhorn on a new PC -- will be required to do any of those things, if Microsoft gets their way. Apple will be lucky if they can get in on the act without becoming another PC clone maker. Linux, *BSD, and the other open/free operating systems will never gain the desktop, and will be lucky to not be DMCA'd out of North America.

I personally don't think it will happen the way Microsoft, Intel, and Disney hope it will, but there's a significant chance that DRM will be legally mandated for so many things that even if you never listen to music or watch movies on your computer you'll still cave and join the club. The only silver lining I can see in the worst-case scenario is that if you're willing to pay a premium to your ISP to deliver all the spam they won't be able to block for you because you won't use the otherwise-mandated spam-block DRM email system, then maybe before too long there will be so few of you geezer geeks using pine and elm and thunderbird that it won't be worth sending spam anymore. But, as I said, I'm optimistic that we won't see the worst-case scenario. But what we see will be bad, and at best Longhorn will be the only Microsoft OS with DRM, so if you want DRM (and they're gonna make Joe Sixpack want it, believe me) you'll buy a new Intell-inside-Dell-DRM-PC-with-Longhorn (and a whole new Office package while we're at it). Either that, or you'll buy an Apple and all new application softwear. To prevent that, Microsoft will do all it can to make sure all your existing apps run just fine on Longhorn -- they just won't be able to take advantage of the DRM features. So they won't be useful and/or legal for some tasks (like email, on-line shopping, etc.).

Even in a not-at-all-worst-case scenario, sooner or later Joel will have to migrate his stuff to the new APIs because his current apps won't open his customer's DRM-protected files.

Visual C++ now free

[aking137]

Wow - I never knew before reading this article that Microsoft's Visual C++ Compiler is now free. (Free as in 'beer' of course.)

Re:Visual C++ now free

[Anonymous Coward]

Wow - I never knew before reading this article that Microsoft's Visual C++ Compiler is now free.

Yeah, they released it a few months ago. It's got a few limitations - mostly you only get static libs to link to - but it's still great.

Re:Visual C++ now free

[Anonymous Coward]

I use it myself. If you download the .Net Platform SDK you get a C# compiler aswell (cl.exe)

Also the Microsoft Visual C++ 2003 Toolkit has a C++ compiler (cl.exe) and a resource builder (res.exe)

of course you need the Windows SDK (I think theres a compiler included aswell, not really sure)

Re:Visual C++ now free

[reanjr]

I'm pretty sure it's been available for a lot longer than that. The toolkit is what is new. Not the compiler being free. I KNOW the csc and vbc compilers have been free since before VS.NET 2K3

Re:Visual C++ now free

[RupW]

I'm pretty sure it's been available for a lot longer than that. The toolkit is what is new. Not the compiler being free. I KNOW the csc and vbc compilers have been free since before VS.NET 2K3

Well, yeah, but they're the C# and VB.NET compilers. They're bundled in the .NET *runtime* - to display an ASP.NET page, for example, it gets converted into an equivalent C# source and compiled.

The new thing is a free optimising C++ compiler for x86. There've been rumours before that you could find it in the platform SDK or the DDK or something but I've used both over the years and I've never seen the x86 compiler for free before.

Re:Visual C++ now free

[Anonymous Coward]

The free cl.exe used to be a watered-down, non-optimizing compiler. The new download is the *same* compiler as the one in VS.NET 2003, i.e., the optimizing one.

So whats new?

[cOdEgUru]

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.

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

(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?

Re:So whats new?

[Anonymous Coward]

while hardware is different than software... but aren't even cutting edge x86 processors today still fully compatible with 16 bit code, the same way AMD's 64 bit chips run 32bit code

Man that was great

[jwcorder]

"(I know, I know, at this point the 2.3% of the world that uses Macintoshes are warming up their email programs to send me a scathing letter about how much they love their Macs. Once again, I'm speaking in large trends and generalizing, so don't waste your time. I know you love your Mac. I know it runs everything you need. I love you, you're a Pepper, but you're only 2.3% of the world, so this article isn't about you.)"

Greatest editorial I think I have read in about 5 years.

Re:Man that was great

[Anonymous Coward]

That would be that you were looking for.

I'm a Windows .NET developer who owns a Mac, as do at least 10% of my colleagues. Just 'cos we're Windows developers doesn't mean that we're fscking stupid.

um

[DRWHOISME]

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.

That's so much BS

[Anonymous Coward]

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.

Re:That's so much BS

[Javagator]

Contrast that with Linux, which still has no developer tools of that quality

Are you kidding? What about emacs?

Amazing..Special case code to run SimCity

[sashang]

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.

Re:Amazing..Special case code to run SimCity

[confused one]

They apparently did this for tons of apps. Search your system Registry for AppCompatibility

Re:Amazing..Special case code to run SimCity

[IamTheRealMike]

This sort of thing is rife in Windows. They have special code to repair the stack for programs that define WndProc with the wrong calling convention - indeed, using the wrong calling convention is such a common mistake that all kinds of code has embedded assembly to repair it: even relatively modern stuff like the shell and DirectX!

As a (former) die hard web developer

[Omega1045]

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.

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

Re:As a (former) die hard web developer

[ari_j]

"MS will patent SOAP and sue anyone who uses it without license" :P XML-RPC is a very open offshoot of early development on SOAP, and its simplicity means it's easier to implement, from what I've seen. Go try it out - there are extremely easy to use libraries available for C++, PHP, Ruby, and probably others.

Or, of course, you could use S-expressions to accomplish the same thing but with the breath-freshening power of Lisp.

Re:As a (former) die hard web developer

[Anonymous Coward]

XML-RPC accomplishes the exact same thing as SOAP...and is quite similar...and has been around a lot longer.

Re:As a (former) die hard web developer

[Anonymous Coward]

... so don't reply telling me some tinfoil hat story on how MS will patent SOAP...

Jesus! MS patenting SOAP? I mean, how are we supposed to do our washing now?

(Sorry, coudn't resist...)

Re:As a (former) die hard web developer

[Anonymous Coward]

rich clients to interop across platforms

This pipe dream has been repeated over and over and over for years. Okay, so we have Gecko, Java, JavaScript, etc. etc. -- all the attempts so far at "rich clients" more or less suck, because nothing yet ever invented made programming significantly easier than before. So, instead of relatively simple and understandable things like POSIX and even X Windows, we now have 1000 layered buzzwords from SOAP to XML to JavaScript to whatever where no programmer on earth can hope to understand them well enough to really get real work done and test it on all the relevant platforms and find that it actually works on all those platforms...because it is all still based on POSIX/X Windows/MS Windows/Mac OS in the end. Full circle--we have gotten nowhere. "Web enabled" has taken the fun out of software development.

The best websites to this day are still damn simple. E.g, Google, Slashdot on "light" mode, etc. The most annoying are those whose developers had a JavaScript orgy and passed out before the QA meeting.

Re:As a (former) die hard web developer

[aero6dof]

Jesus! MS patenting SOAP? I mean, how are we supposed to do our washing now?

Like lack of SOAP matters to a geek like you? :)

(Sorry couldn't resist either :)

Re:As a (former) die hard web developer

[leandrod]

> instead of relatively simple and understandable things like POSIX and even X Windows, we now have 1000 layered buzzwords from SOAP to XML to JavaScript to whatever where no programmer on earth can hope to understand them well enough

On the spot, AC.

What I wished was that we went back to POSIX -- well, not quite, actually some garbage-collected functional stuff running on POSIX -- and the X Window System.

And I think that could come to pass. With GNU/Linux spreading, Mac OS X holding its share and getting X servers (both Apple's gratis and Fink's free ones), and Cygwin/X getting easier and easier to install, we could soon have X servers everywhere, so that we could run applications from POSIX servers whenever HTTP didn't suffice.

A trend may be starting with public Telecenters and other LTSP or otherwise host-and-terminals GNU/Linux implementations.

Then we could go back to improving the host (GNU Hurd, functional programming, relational databases) and the terminals (Cairo, I/O) and stop worrying about the API du jour.

Re:As a (former) die hard web developer

[EddWo]

Hence Indigo to wrap up all that hard to understand SOAP stuff, and XAML to make rich clients as easy to author as web sites, and WinFS to tie users to the platform forever by locking in all their data with relationships and InfoAgent rules.

Re:As a (former) die hard web developer

[ianezz]

we could soon have X servers everywhere, so that we could run applications from POSIX servers whenever HTTP didn't suffice.

Uhm, X protocol is quite "chatty". NoMachine MX literally does miracles to circumvent network latency problems, still I think this makes X protocol merely usable on WANs and MANs (i.e. the Internet), not "a good choice".

OTOH, X protocol is just fine on LANs.

Re:As a (former) die hard web developer

[RoLi]

I can see technologies like SOAP enabling rich clients to interop across platforms

As somebody who has actually worked with SOAP and has worked for at least 2 weeks to implement something a tiny shellscript calling scp and then ssh could have done faster and better, I don't.

SOAP is only used when you have a clueless management that insists on using the newest and latest from Microsoft.

scp/ssh can replace SOAP right away, and the X protocol can fill anything else.

And people say....

[jwcorder]

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

And people say the evil giant doesn't try to fix it's software. They fixed SimCity DAMN IT!

Re:And people say....

[RealAlaskan]

>>the Windows developers, ... added special code that checked if SimCity was running, ... ran the memory allocator in a special mode ...

>And people say the evil giant doesn't try to fix it's software. They fixed SimCity ...

SimCity isn't the Evil Giant's software. Whatever they may do to other people's programs (break DR DOS, fix SimCity ...), this doesn't suggest that they fix their own software!

Re:And people say....

[jwcorder]

Excuse me....but I don't think they would add special code to SimCity to see if SimCity was running. So if they added special code to Windows, wouldn't that be fixing their software?...hmmm.....think I might be on to something here.

Re:And people say....

[mlk]

I would argue that they are breaking there software a little to make SimCity work.

A good use of resources IMO :D

About this "Joel" guy

[Anonymous Coward]

Situada en el Real del Windows 2000/XP Arrabal en el barrio judio, Joel daba paso al recinto islámico de la epoca.
Aunque no se puede datar su fecha de origen, se tienen noticias de la misma a partir del siglo, API se reconstruye sobre el siglo y esta influenciada por el estilo mudejar, Microsoft aspecto que destaca notablemente en la actual y bien conservada en Windows XP.

The Browser Is the Future of App Development

[Anonymous Coward]

Just like it was the future of app development 10 years ago, right?

Re:The Browser Is the Future of App Development

[jon3k]

Did you not get the memo yet that there are more web based applications written every year than anything else?

SourceCode != QualityDocumentation

[moronikos]

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.

Re:SourceCode != QualityDocumentation

[leonscape]

Non-existant API Docs for Qt are located at http://doc.trolltech.com/3.2/index.html
KDE's are at http://developer.kde.org/documentation/library/cvs -api/
Thats every function call to program in KDE and Qt all completeley cross-refrenced, with examples.

Re:SourceCode != QualityDocumentation

[AlXtreme]

www.gtk.org/api

It really doesn't get much more easier than that. But my hunch is that you've yet to code a single line of C + GTK+.

Yes, I'm a troll, bring it on.

Re:SourceCode != QualityDocumentation

[Anonymous Coward]

And absolutely no information on dependencies, idioms, or general usage. Those API docs are pretty damned useless unless you know exactly what you're looking for. For example, how does one send an email message? Where are the docs? I don't think you'll find them in the first or second place you might look...

Re:SourceCode != QualityDocumentation

[leonscape]

You did see the Qt page right? As for KDE Just go to the parent site http://developer.kde.org/ We where after all dicussing API's the other documentation is there.

As for e-mailing
http://developer.kde.org/documentation/library/cvs -api/kdecore/html/classKApplication.html#a22

One function call.

Re:SourceCode != QualityDocumentation

[Anonymous Coward]

Non-existant API Docs for Qt are located at http://doc.trolltech.com/3.2/index.html

"Non-existant API docs?" Sweet! BTW, you can download Duke Nukem Forever here: http://www.3drealms.com/downloads/dukenukemforever

Re:Who is "joel", and why should I care what he sa

[Anonymous Coward]

Joel is an ex-microsoft programmer who left and then founded his own software company. Which is profitable. Thats more than 99.99% of people here on /. have ever done.

He also writes a blog which occasioanly makes good points because he still maintains contacts from all those years working at MS.

This is how Microsoft fixes bugs

[vivek7006]

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.

Re:This is how Microsoft fixes bugs

[aka-ed]

Is this supposed to be a criticism of MS? They didn't "fix a bug" here, they built-in forgiveness for a third party's bug. If they hadn't, Maxis, end-users, and MS would have suffered.

Perhaps I need clarification of your point?

Re:This is how Microsoft fixes bugs

[Just Some Guy]

Is this supposed to be a criticism of MS?

It is from me. If they hadn't fixed it, then other developers would've gotten the message that either you play by the rules, or you get hosed when the accidental feature you've been relying on goes away. Now they know that if they can only get enough market share, then Microsoft will bend those features around their local compatibility problems.

Put another way, if a Unix app bombs due to poor coding practices, do you blame that version of Unix for not "supporting" that application, and do you expect the OS vendor to make an application-specific patch to make it work again? No way! It's one thing if an application reveals a flaw in the OS that needs to be fixed, but this is an entirely different animal.

Re:This is how Microsoft fixes bugs

[aka-ed]

A compatability tweak is hardly a "bending of the features" of the new OS, those features remain fully intact when an app that has no need of the tweak is run. The absence of the tweak would not enhance the performance of Windows, except to the extent of lightening the registry by a single line.

Do you feel that Linux is a viable candidate for the consumer desktop? Would you argue that Linux can be as "user friendly" as Windows?

Unless your answers to these 2 questions are no and no, I would recommend you think a bit more about the end-user, and less about the extent to which compatability tweaks like this one fail to punish those you think should be punished.

Re:This is how Microsoft fixes bugs

[Just Some Guy]

The idea of special-case code is abhorrent to software engineers. It's ugly, fragile, and a maintenance nightmare.

Do you feel that Linux is a viable candidate for the consumer desktop? Would you argue that Linux can be as "user friendly" as Windows?

Yes and yes. I think it's far more user friendly than a Windows desktop. When I have to use a Windows system, I'm completely lost. The shortcuts don't work right, copy-and-paste is wrong, and nothing's where I expect it to be. Wait - did that sound strange to you? Now you know how I feel every time I hear Windows users that Unix desktops are difficult.

The average consumer writes letters, browses the web, and reads email. Unix has excellent applications for all of those tasks. Whenever I hear that Unix isn't ready for the desktop, what I'm usually really hearing is someone complaining that a particular task that very few users would ever try on Windows is more difficult on Unix.

And where did you get this weird idea about "punishment"? There's no malice in ignoring hackish code that ignores a published API or explicit coding standard. You're reading too much into the situation.

Re:This is how Microsoft fixes bugs

[aka-ed]

What are the real benefits -- apart from satisfying abstract programming ideals -- of leaving out the one line of configuration settings (it's not code, it's a tweak) for compatability with a product that was designed for a different operating system?

Failing to include the line creates hassles for both the OS publisher and the games publisher. But most importantly, it creates inconvenience and frustration for the user.

If there's no benefit to omitting the single line of config data, omitting it is purely a punitive measure; "developers would've gotten the message that either you play by the rules, or you get hosed," in your own words.

Do you also believe Sony made an error in making PS1 games playable on PS2?

Re:This is how Microsoft fixes bugs

[Just Some Guy]

What are the real benefits -- apart from satisfying abstract programming ideals -- of leaving out the one line of configuration settings (it's not code, it's a tweak) for compatability with a product that was designed for a different operating system?

First, it was designed for a particular operating system, it was designed for a particular API. If the new OS supports the same API as the old one to the point that all documented interfaces still work in accordance with the documentation, then any breakage is the fault of the developers and not the OS vendor. Second, the problem is that by extending the API beyond its documented limits, you're effectively creating a whole new API to code against. What happens when a new developer unwittingly triggers a compatibility patch and figures hey, it works, so let's use it. If their trigger condition is similar (but not identical) to the one being trapped for the first application, then future OS releases now have to handle the original API, the original set of patches, and a new set of patches to handle the differences between the old patched API and the new OS. Down this path lies insanity.

Failing to include the line creates hassles for both the OS publisher

It does for Microsoft, because they've created a tradition of bending their system to support broken applications. Now everyone has been trained to blame Microsoft for any compatibility issues they find, instead of the people who wrote the broken code in the first place.

Do you also believe Sony made an error in making PS1 games playable on PS2?

Now you're inventing strawmen and I'm ending the discussion.

Re:This is how Microsoft fixes bugs

[aka-ed]

It's not a strawman; your unilateral decision that I have broken some rule of yours, and so now you will unilaterally close discussion is as inflexible as your initial post in this thread, and equally unreasoning.

Backward compatability is the issue here, and if including a tweak in Windows allows a popular game to work, how the hell is that different in basis from Sony deciding to support games from a previous console? A LOT more trade-offs were involved in that decision, as you should know quite well.

"Backward compatability" is sometimes about considering the experience of the user more than programming ideals. It's about the reality of markets. Stuff that Linux developers need to deal with, not run away from.

Translation

[XanC]

Come on, Babelfish, enlighten us!

Situada en el Real del Windows 2000/XP Arrabal en el barrio judio, Joel daba paso al recinto islámico de la epoca. Aunque no se puede datar su fecha de origen, se tienen noticias de la misma a partir del siglo, API se reconstruye sobre el siglo y esta influenciada por el estilo mudejar, Microsoft aspecto que destaca notablemente en la actual y bien conservada en Windows XP.

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.

ideological loss, but still winning in the market

[MMHere]

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 disagree .NET will fail due to Longhorn/Avalon

[cjmnews]

I think that Joel is wrong here.

I believe that the long wait for Longhorn/Avalon to be released will cause more people to pick up .NET as an alternative to the old API development.

Developers will see the benefits of the .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.

When Longhorn/Avalon finally gets released, the adoption I expect will be slow. We just spent all this money becoming proficient with .NET. Why change to the new system now? Unless you need the new features, .NET should cover most needs of application and web developers.

I just can't see how .NET will go away so soon after it's introduction.

What about flash.

[metalhed77]

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

Re:What about flash.

[Anonymous Coward]

Been doing just this but XML parsing in Flash is too slow, this gets even worse with SOAP. Flash remoting however is really promising. Check out http://www.openamf.org/ if you plan on using Java at the server-side.

Re:Who is "joel", and why should I care what he sa

[Anonymous Coward]

Joel is some guy who makes bug tracking software. Oh, he also preaches to the world about how to make good design decision in software development. Bwaahahhahahahahahahhhahahaha.

Uhh... what?

[Hatfieldje]

From the article:

The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.

You would think that after progrmaming for as long as he claims (13 years) he would understand tht HTML is not an API, but a Markup Language (HyperText even). And I wish people would stop trying to make HTML sing. I just want it to mark the text up. That's what it's for.

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:Uhh... what?

[Anonymous Coward]

How could you not understand that he meant that HTML and other web-based technologies have replaced teh API?

Re:Uhh... what?

[Anonymous Coward]

I can't believe you wrote teh

Re:Uhh... what?

[Anonymous Coward]

first, you didnt get what he was trying to say about HTML being the new API. read it again.

second, dont compare linux to windows about new API changes because linux has itty bitty tiny marketshare compared to windows. there were lots of great reasons mentioned in the article why it hurts them and yet you completely missed them.

Try POSIX next.

[torpor]

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.

Re:Try POSIX next.

[Carnildo]

I've used wxWindows (now wxWidgets). For the parts that aren't buggy, it's slightly better than Win32 in ease of use, and somewhere worse than any of the others in terms of documentation.

Re:Try POSIX next.

[torpor]

I've used wxWidgets for 7 projects, and I can't say I've ever had problems with bugs that I couldn't just fix myself, and contribute back to the main source tree.

Try that with MFC ...

As for the docs, you must need a lot of hand-holding if you think the wxWidgets docs are incomplete. I'd sure like to know what you found lacking ...

Re:Try POSIX next.

[Carnildo]

They might be better now, but when I was using it a few years back, wxDateTime and related classes were essentially undocumented, particularly with respect to the handling of time zones. I also remember a number of sections of documentation that basically said "To be completed".

Re:Try POSIX next.

[torpor]

so ... yeah ... give it another shot now. you might see that the F/OSS model, applied over a year or two, produces results you won't get from MFC.

note, also, that i've intentionally avoided getting into a debate with you over the so-called 'documentation' for some of the other API's mentioned ...

Re:Try POSIX next.

[Carnildo]

My experience with the F/OSS model is that it can produce incredible improvements in code over a few years, but documentation tends to lag far behind.

I'll check it out anyway.

Re:Try POSIX next.

[torpor]

For me, source == documentation.

Interesting comments, but where were...

[Black Jack Hyde]

Crow and Tom Servo?

We can only hope...

[cmacb]

From the article:

"... they could reinvent themselves as a shaved-ice company at the last minute. "

Win32 API will live forever

[Orion Blastar]

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.

Re:Win32 API will live forever

[molarmass192]

Well, you can run WINE in a chroot jail. Also, most of the Linux filesystems offer very granualar control over directory and file attributes so you can lock down configs and binaries int the wine home very tightly. Myself, I think that this is probably a task best left to packagers rather than the WINE devs. Keep WINE as lean as possible and let the OS handle the securing it. In fact, this is how my crossover office is setup for viewing those nasty WebEx presentations.

Re:Win32 API will live forever

[Anonymous Coward]

"Already there are still people using DOS and Windows 3.X and refuse to upgrade."

Who? Hermits hiding out in plywood shacks in the remote woods of Montana writing anti-technology manifestos and mailing bombs?

Re:Win32 API will live forever

[reanjr]

*EPLOSIVE LAUGHTER*

Oh wait, you were serious about that granular control thing, weren't you?

On a more serious note, Windows supports a very granular permission system. It's only a matter of setting permissions. If you're not going to do that on Windows, why would you on WINE?

I think that other options would definitely have to be looked at for WINE. Interestingly enough, as WINE becomes better and better, it will become more and more insecure. Right now, there's still alot of Windows apps that don't work right. Same thing would probably go for virii, etc. As WINE runs more apps, it will run more worms, etc.

In summary: Sandboxing would be good. :)

Re:Win32 API will live forever

[Chester K]

Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release.

The problem is WINE is not "undocumented Win32 API calls". CrossOver Office can run MS Office just fine, and if there's any Windows application that would be using "undocumented Win32 API calls", it'd be Office. The fact is that there aren't any useful undocumented API functions. What's not documented is undocumented for a reason and is not used, even by Microsoft apps.

The problem with WINE is that the Win32 API is so mind-bogglingly huge because it covers just about everything you'd ever want to use an OS to do, that the WINE developers haven't been able to implement the whole thing. They go for the "most bang for the buck" APIs.

Re:Win32 API will live forever

[Tim C]

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.

Let me get this straight - you think that with the next release of Windows, MS are going to completely break compatibility with almost every single Windows application in existence?

It'll never happen. Over time, and the next few releases, they will almost certainly push very hard to get people away from the Win32 API and onto .NET, but it's going to be a *very* long time before they can drop support for Win32 apps.

Re:Win32 API will live forever

[dr_turgeon]

The bets are on as to how soon those Longhorn viruses and worms come out after Longhorn is released.

Rest assured that Microsoft® is already hard at work on ensuring release day compatibility with all popular viral and spyware code. Thank you for your interest in Microsoft!

Re:Win32 API will live forever

[IamTheRealMike]

Actually there are lots of useful undocumented APIs. Check out the unnamed shell32 exports or NTDLL

Re:Who is "joel", and why should I care what he sa

[jon3k]

And Gandhi didn't have a job at all! What a sucker that guy was!

Oh, wait ...

Half Wrong.

[DRWHOISME]

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.

Re:Half Wrong.

[Anonymous Coward]

Why dont you start your own computer maker company and make big bucks selling pre-installed gentoo or whatever the flavor of the day is?

Re:Half Wrong.

[drsmithy]

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.

Do you think cars should have to be sold without tyres as well ?

Re:Half Wrong.

[TheRealSlimShady]

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.

Cool, then everyone could pay more for Windows rather than less. You know that they only pay around $30-$40 for the OS when it comes bundled right?

Re:Half Wrong.

[Anonymous Coward]

God you're retarded.

So is it COLLUSION that Dell gets hard drives cheaper than I can?
That Gateway doesn't have to run to Best Buy to buy RAM for their systems.

It's the nature of OEMs.

Re:Half Wrong.

[whiteSanjuro]

the market has made this the standard os because a) average person has no use for a computer w/o os and b) the fact that ms office is the dominant software package for general purpose home and office use. office is what makes ms all the money, windows is but a fraction of their profits compared to office.

Re:Half Wrong.

[Anonymous Coward]

Then that is at least $30-40 my employer could save. Like many corporations we pay for Windows and depending on the model an Office suite when we buy the computer from Dell. Then we are required to pay for both these again when we slick them down and reload with images we have created containing the applications our employees use.

Re:Half Wrong.

[DRWHOISME]

I only talk to big grownups.

Now go home and tell your mommy to change your diaper.

bye ......bye.

Joel, you should lay down the law with your kids

[Anonymous Coward]

But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument.

Only if your a wuss.

If .net is any good and if M$ puts their marketing muscle behind it, it will flourish.

Gracious plug at the end....

[jwcorder]

"The company I started, Fog Creek Software, makes a terrific product called FogBUGZ for software project management and bug tracking. It's web based, affordable, and runs on your own server, and it's now available for Windows, Unix, or Mac OS X servers. Check it out now -- there's a free online trial!"

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!

Re:Gracious plug at the end....

[Oligonicella]

Drink more Ovaltine? It's a damn commercial!

Re:Gracious plug at the end....

[Anonymous Coward]

Gracious or gratuitous?

MOD PARENT UP, GRAND PARENT DOWN

[Anonymous Coward]

Mod parent up, grand parent down. Seriously, how did that plain wrong information get +4?

Java?

[helix400]

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

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

Re:Java?

[evought]

The same goes for a number of other layering technologies, including Qt, Tk on top of Python or Ruby, etc. Together with Java, they start to shield developers from these types of changes. People used to use these toolkits (mostly) to develop multi-platform apps (Windows/Mac/Unix). Now the trend may slide more to shielding people from changes within the Windows "platform".

If I write a Java or C++/Qt or Python/Tk app, when MS changes the API, it becomes largely Sun's or TrollTech's or the Tk Project's job to tweak the insulating layer to run on the new system. With a well-written toolkit, this is often surprisingly quick since they start before the new platform is released. It takes time to start optimizing the toolkit for the new platform, but the base toolkits tend to be available rapidly and, therefore, existing apps written to them can get a foothold rapidly.

There are a few things to watch out for. One is, of course, that you don't want your toolkit to go away or become unsupported. Open Source is a little safer in this respect because someone can pick it back up again, even you if it is important enough. The other is that even with a really good abstraction layer, different platforms are different, especially in the way they respond to bugs or marginally unsafe code in your product. Java programmers often get bitten by the threading model- it is surprising how little is (and can be) guaranteed by Java's threading model across platforms.

Another very nice advantage of the abstraction layer approach is that you can often choose your development platform according to how well it runs your development environment rather than how well it runs your apps. For instance, develop on Mac or Linux, use VM technology for quick tests, the actual target platform for integration tests, your development hardware for unit tests. Very few carpenters choose their tools by polling their customers. In the same way, it is important for the developer to not be restricted by what end users have on their desks.

Now, the end result of all this, is that once you start using this approach to protecting yourself from changes in MS APIs, you are an awful lot closer to deploying for another OS entirely. MS's strong-arm tactics become less effective. That is what will eventually bite them.

Think he's living in the past a little on this one

[SuperKendall]

There are many points in the article to me that seem a little bit from the past:

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 .Net 1.0 to 1.1 that break things, and looking forward Windows.forms is already depricated!

Rose Glasses

[Saeed al-Sahaf]

"The reason for the death of the API is probably GNU/Linux"

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:Rose Glasses

[matrix0f8h]

Linux is not sweeping the world like a storm...

Love hurts.

Re:Rose Glasses

[GbrDead]

so many people are using .NET

Nope, they aren't so many. Even Joel (pro-MS, IMHO) said it. .NET's popularity is nowhere near the popularity of Java when the latter was 3 years old, although .NET is hyped as much better than current Java and Sun didn't have a large developer base back then.
I haven't seen usable applications based on .NET. The only one I have heard that might be usable, is Bulgaria's e-governemnt site. The decision to use .NET is clearly non-technical - the fact that Microsoft bribes Bulgarian politicians (on the expense of us, taxpayers) is a public secret.
Bribing politicians instead of gaining developers' attention? Nope, doesn't sound like .NET could become popular even in the future.

Re:Rose Glasses

[iamacat]

Write once, run anywhere is a fantasy that just does not provide any real world solutions to real world problems

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 .NET and Mono.

C++; browser-based application

[Meijer]

Often I've written the same code, once in C++ calling the Windows API and once in Visual Basic, and C++ always took three or four times as much work. Why? Memory management. The easiest way to see why is to look at the documentation for any Windows API function that needs to return a string.

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.

The big meme at Microsoft these days is: "Microsoft is betting the company on the rich client."

I don't think so. Instead, Microsoft is trying to propagate developing of browser-based application that only run on windows.

Wow

[Anonymous Coward]

You can copy.... AND paste! Who showed you how? Say.. you wouldn't be interseted in some herbal viagra would you? Cause I've got a deal with a nigerian bank that could make you millions while speeding up your unoptimised internet connection!

It's about the APPs silly. . .

[JSBiff]

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.

Re:It's about the APPs silly. . .

[jwsd]

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.

Your logic is flawed. There is no benefit for Microsoft to stop innovating in IE. Anti-Microsoft zealots always portray Microsoft as a monolithic entity tightly controlled by an evil command center. But if you ever worked in big corporations, you will know that they are invariably composed of rival groups competing for budgets and resources. If the IE group stops innovating, their budget will be cut and the group management won't let that happen without a big fight. And the only way to justify the survival of their group is to demonstrate all those new features that users want. Acutually, the bigger the innovation, the better. Because that entails large investment in the group and a lot of new hirings. Every old timer gets a chance to move up one level in the corporate ladder.

Re:It's about the APPs silly. . .

[EddWo]

Well it does seem to have happened that way. The major developers from the Internet Explorer team moved into the Avalon team soon after Windows XP shipped. Avalon plans to do everything DHTML + Chrome + DirectShow3D did plus flash/svg plus xforms/xul plus pdf etc all in one unified display model and tightly linked into the windows graphics pipeline. It needed all their best graphics, layout, animation etc. developers working on that full time.
Hence the announcement of no new versions of IE except for with future versions of Windows. There has been some recent work on it with the popup blocker + extensions manager and security tweaks for XP SP2, but no major work on the rendering engine.
It seems likely that IEs web standards support will continue to stagnate even after Longhorn is released, there will be no SVG or xsl-fo etc. the best we can hope for is that they fix transparent pngs and css2.1, anything more complicated and interactive will need to be written as a web-installable .net application that uses web services to communicate with the server.

Key quotation regarding IE...

[GPLDAN]

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.

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

Re:Key quotation regarding IE...

[mpcooke3]

I agree about the developers and I fear developers will move to windows development in droves once Avalon/Indigo is released because at last someone will have created a proper Web API. I hate microsoft but I can't deny that a proper web API is long, long overdue.

Will mozilla gain critical usage level before Avalon/longhorn?

And even if Mozilla by some miracle got more than 5% market share would it even matter?

No one is going to want to develop old style web application using the typcial DHTML/HTTP/Cookie/ServerSideSession hacks of today when there is a proper API for developing Rich GUI web apps using Avalon/Indigo in windows.

I am afraid that the Mozilla of today is similar in some respects to the DR-DOS v's MS-DOS war. Micorosft doesn't care because they are already developing the next generation toolset Windows3.1. The equivalent today being Avalon/Indigo.

Mozilla/Gnome are obviously aware this is happening after the Amazon Avalon demo but what are they going to do about it? They don't have the market share for it to be worth creating a competitor next gen technology so they may be left trying to emulate Avalon/Indigo support in Mozilla, but this next Gen toolset is largely not standards based and is owned and driven by microsoft (AFAIK).

Sorry to sound depressing but microsoft is both still winning the current HTML broswer war AND putting all it's resources into the next generation web technology which once released will probably leave projects like mozilla and Opera in a similar situation to DR-DOS, u know, nice and all that but it won't run any of your windows apps so what's the point?

Re:Key quotation regarding IE...

[sploxx]

That's how you win, you take Microsoft's strongest weapon away - the masses of developers.

I already hear ballmer screaming: "Developers, developers, developers. Developers, developers, developers..." :)

Re:Key quotation regarding IE...

[mewphobia]

I can see ms battling in at least 2 ways;

1. patents.
MS has funds that OSS do not.

2. xbox/drm
If MS gets their own DRM box in everyone's house, they control the platform!

Things OSS need to do:

* I really wish the mozilla project would focus on making their XUL offering a bit more substantial. It would be awesome if you could make a program in XUL that could minimise to the system tray! making a messenger/irc/chat program would be easy as! it already supports server push via multipart/x-mixed-replace in newer versions (>1.7).

* Firefox/mozilla are moving targets for developers! Plugins break between releases! It's okay to add features, but maybe the versioning system should be modifyed to not break things until the next major version. And possibly the next major version shouldn't be released until there is a seamless migration strategy.

Re:Key quotation regarding IE...

[Brandybuck]

Maybe I've been living in a cave for the last decade, and maybe my intelligence has been permanently damaged because I use C, but would someone please explain to me why everyone is getting erections over Mozilla as a platform? Why the circle jerk?

Mozilla may be crossplatform and allows distributed applications, but so does Java, and in the more than a decade it's been around, it still hasn't destroyed Microsoft like it promised. Why can Mozilla success where Java hasn't? And why must I use Mozilla when Java is going to give me the exact same benefits plus a hundred more?

Memory Management killed the Richard Chen camp

[Robotron2084]

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.

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 .NET is automating protecting coders from themselves, which is exactly what the Chen crowd wants anyway.

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.

Re:Think he's living in the past a little on this

[jwcorder]

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.

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.

Slam M$ + Praise Linux = Karma Whore

[GunFodder]

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.

Garbage Collection

[Peaker]

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.

STOLEN FROM OSNEWS.COM

[Anonymous Coward]

slashdot fucking sucks fuck you all

I too work for the US government...

[Anonymous Coward]

Your manager needs lessons from mine. We're also at a government agency, but in our group: software development is a bit different from yours. This difference is despite being under the same purchasing rules.

Our manager (a lifer) upholds our departmental motto "It is far easier to get forgiveness than permission." He'd opine "Create a dependency, we'll spread it, and by the time anyone notices we need approval for some little piece; that piece will be more expensive to replace than to approve. You'll be surprised how fast that approval goes by then."

In seven years he's not been incorrect.

So, I guess the unapproved software conundrum really sums from the addends of how much backbone your manager has, how irreplaceable he is, and how close to late retirement he is? With a gutsy, irreplaceable, older and respected manager behind you; tools are easy to include. Just make certain he's really behind you.

Oh, and just as a sidenote: a demo of a cranky, nearly failed app using available tools contrasted with a sexy app linked against the proper tools can help convince your managers manager to go your way. Never let your manager walk in without proper ammunition.

Re:I too work for the US government...

[Marxist Hacker 42]

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.

You kind of have it...

[SuperKendall]

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.

Windows as bad as Opensource ?

[Anonymous Coward]

Python breaks its API on every version upgrade. Rendering binary modules incompatible (although COM or XPCOM would solve that problem).

Apache 2.0 broke countless binary modules, and no - you can't just recompile it.

Until opensource developers treat API's in binary modules are sacrosanct, it means that users keep having to reinvent the wheel, or refix broken parts.

Re:Windows as bad as Opensource ?

[vvenka1]

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.

Re:Windows as bad as Opensource ?

[TheRealSlimShady]

Until opensource developers treat API's in binary modules are sacrosanct, it means that users keep having to reinvent the wheel, or refix broken parts.

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.

Re:Windows as bad as Opensource ?

[IamTheRealMike]

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.

What Joel didn't say...

[IndigoSkies]

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.

Re:What Joel didn't say...

[zaphod_bee4]

People often misidentify websites as the Killer App of the future. Actually Thin Client's are more that type of thing. A server serves an application to a client. The browser may be the client platform or it may be some other new development. The Point, is that once the protocol for serving the application is public it can be implemented on any client platform. That's why HTML is available pretty well everywhere. I don't think HTML (as it is now) is going to be the protocol used but I do think something will fill that need. I just hope there is enough of a unified standard available that we don't have to have a ton of client platforms for all the applications. Some stuff is going to stay "rich client". 3D-apps for instance. But even those will probably evolve to use those same protocols to communicate with a server for collaborative work. A sort of medium client application model.

MOD PARENT UP

[Anonymous Coward]

You have to love the OSS circlejerk that these threads always devolve into. Thanks for at least attempting to cut the bullshit.

Well...

[RAMMS EIN]

``This old argument about Mac having no apps is very old, very tired, and very tiresome.''

Well, to be fair about OS X:

1. Windows apps don't run on it.
2. Classic apps don't run on it.
3. Quite a few apps developed for the GNU system don't run on it.

That is, unless you emulate/virtualize the system those apps do run on. Also, there are plenty of apps for any purpose that do work under OS X. I am just pointing out that migrating to OS X can hurt, as you will likely have to abandon some of your favorite apps.

Re:Well...

[Anonymous Coward]

You obviously know nothing, why even bother posting? Talk to your mom if you want attention.

everything doesn't run Windows

[GunFodder]

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.

Re:everything doesn't run Windows

[Nasarius]

You forgot one giant market: Internet servers. The vast majority of web servers are running Apache.

Re:everything doesn't run Windows

[Anonymous Coward]

For the most part, "Internet Servers" are doing nothing -- serving placeholder sites, or some static HTML. Only a small percentage even serves trival PHP/ASP/ColdFusion.

One thing MS points out is that for SSL sites (ecommerce applications, mostly), they are doing very well.

This is why WINE is the most important

[ceswiedler]

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.

Re:This is why WINE is the most important

[AlXtreme]

Microsoft doesn't care about WINE. Windows Emulation will never get the compatibility Win32 users need, and it doesn't even matter, as the 'HTML API' is the only thing that users will care about in 5 years. RTFA.

Oh wait, this is /., never mind...

Re:This is why WINE is the most important

[dmaxwell]

The UNIX api was never controlled by one company. Even AT&T never had the level of control that MS does on WIN32 and .NET. MS can ALWAYS make their APIs a fast moving target to stymie the Wines, ReactOSes, and Monos of the world. That said, Wine does seem to be useful if you want to target a particular Windows app and run it elsewhere. It msy also have value if you need to make some Windows API source code cross platform.

Re:This is why WINE is the most important

[Anonymous Coward]

Right. But Linux DE's are still crap, and that's what matters to most people. See OS X vs Linux for that. This whole "next year is the year of the Linux desktop!!" thing is getting very old, especially when developers of things like Gnome are such asshats as to disregard criticism with a "Don't like it? Patch it!" attitude. Criticism is good, see Mozilla then & now (Seamonkey vs. FF). These folks are the reason Linux won't gain a hold on a teenager's PC, + the crappy name.

Re:This is why WINE is the most important

[Trillan]

Actually, I think the grandparent is right.

What the article says is that people will not care about the Windows API, but the web will become the API going forward.

The API of the majority of applications now is still Win32. Implement that, even five years from now, and you'll get a huge boost in number of applications that run on a system. So in five years, this hypothetical system will support Win32 (and thus be compatible with most Windows applications) and the web (and thus be commpatible with current applications).

I don't know that I agree with him about web applications, but certainly if Microsoft fails to move the world to Avalon, Win32 will be an important API to implement.

Thats why

[DRWHOISME]

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.

One problem with his prophecy

[Anonymous Coward]

If you can run win32 apps on linux, I would bet you will be able to run them on longhorn. seriously.

Paid ads

[pongo000]

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 /.?

Embrace and extend!

[mariox19]

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:Embrace and extend!

[the_duke_of_hazzard]

This is utter nonsense. While MS have a lot of control over how HTML is used, the "Internet at large" is far from controlled by them, so they have little power to change it. The idea of MS stampeding over all other platforms and browsers when they can't even get half the webservers in the world to run on their code/platform is absurd.

I also disagree that MS developers are substandard or thoughtless. They are developing code for systems where the goalposts are always shifting and adherence to open standards simply doesn't carry much weight.

Microsoft aren't stupid enough to try and overthrow an infrastructure that works far better than anything they've come up with, mainly because the designers of the internet were academic engineers with lots of time and little commercial pressure.

Re:Embrace and extend!

[mariox19]

Microsoft's tools are a Trojan horse (in the original sense of the term). Certainly, there are many above-standard, thoughtful developers for the Windows platform. What I'm talking about are the Web applications -- meant for the public -- that use proprietary Javascript hooks and other IE "features" which more or less break on anything but Windows-IE. It's the developers of these applications using the "features" built into Microsoft's tools, operating system, and browser that undermine non-Microsoft platforms.

The public -- including the schools and companies that purchase these applications -- is sent the subtle message that "you really need Windows and IE; other platforms can't seem to handle it." In their minds it's the other platforms with the problem.

Wait until AXML and the other new wave of "goodies" from Redmond come out. That's when the "fun" will really begin.

MS has lost control of their own API

[SteamyMobile]

One thing which is interesting is that Microsoft's API has taken on a life and existence of its own. MS is a slave to Win32, not the other way around. This implies that if Longhorn doesn't support the Win32 API, it will be competing against all the other things that also don't support Win32, such as Linux. History has shown that Microsoft's ownership of the Win32 API doesn't lead to ownership of other markets (cf the Xbox).

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

Flash is where it's at.

[endquotedotcom]

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

Re:Me on Joel

[Anonymous Coward]

I hear that guy has a sweet ass. It'd be nice to be "Me on Joel," that sexy phaggot...

Clue time

[jmorris42]

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

Bizzare, yes. Undocumented, no.

[autopr0n]

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.

Re:Think he's living in the past a little on this

[Anonymous Coward]

FFS if you are going to try and use HTML to make quotes stand out, can you learn to close your tags.

Can you be more spesific?

[autopr0n]

What were you trying to do in QT that you were not able to do on NT?

Re:Can you be more spesific?

[mangu]

What were you trying to do in QT that you were not able to do on NT?

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:Can you be more spesific?

[Anonymous Coward]

<snip>

IOW, he couldn't find his bug so he blamed the documentation. Now that's original :-)

Interestingly, he is obviously the only person ever to attempt this sort of code -- without him here to report the truth, we would never have known about this PROBLEM in MSDN!

Uh-oh

[Daniel]

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

Web as a the savior

[The Ape With No Name]

Here's the two word problem: stateless protocol. HTTP was not meant to do what we are trying to do with it.

Re:Web as a the savior

[jc42]

Here's the two word problem: stateless protocol.

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.

Re:Web as a the savior

[humankind]

Technically speaking the guy is right. The web is basically a stateless protocol. There are a number of hacks, but GET/POST variables are THE most kludgiest of them all. If some morons hadn't freaked out users unnecessarily over the whole cookie issue, it wouldn't be as much of a problem. The people who whine about cookies and security should have all been rounded up and dropped into a big hole so their fearmongering would not have created the ridiculous panic that it did awhile back.

Re:Web as a the savior

[10101001 10101001]

Have you ever used X? It's a stateful protocol. Ever used vnc? It's a stateless protocol? Ever heard of Xvnc which provides a stateless protocol to an X server? It seems silly to me to assume that you can't use a stateless interface to alter a stateful one. After all, all web apps are about is providing a stateless interface to a stateful "rich" app.

Re:Web as a the savior

[Watcher]

Keeping state like that is all well and good-as long as you're doing sanity checks on what is returned in the POST. If you aren't, you've just opened yourself up to a whole world of abuse. One of the biggest problems with the web is you can't trust the user at all. At any point he could turn out to be some schmuck trying to crack into your server/crash the app/steal money/whatever. Its tough enough to trust anyone with a client/server application design, but really trusting anyone with a web application is a mess.

I'm none too fond of web development because all of the really powerful things you can do easily on the desktop has been removed from the browsers because of abuse. That won't change anytime soon, at least until we can sandbox every application out there.

CAS

[Strudelkugel]

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.

Browsers on every maching

[acomj]

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

Oldschool

[autopr0n]

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

Re: DR DOS

[SimonInOz]

I seem to recall their final solution (hmm, interesting choice of words) was much more subtle.
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 ... 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.

GNU\Linux

[200_success]

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!

What's with the backslash in GNU\Linux? You look suspicious to me, Microsoft boy.

Why the browser will NOT be the future of app dev

[bahwi]

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!

That's what .pif files are for

[Animats]

Yes, ".pif" files actually have a purpose other than as a means of transmitting viruses.

Misunderstanding WinFS

[leandrod]

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.

Re:Misunderstanding WinFS

[_Knots]

That doesn't sound terribly spectacular...

Set the sticky bit and a+rwx on / and munge your file ownerships (or POSIX ACLs) to your heart's content. Bam! No more heirarchy. Add / to your path, add / to your lib dir, add / to your man dir. It'd work.

Oh, different users should have different views? Er, uh, ok, so then we have /home/foo and /home/bar. No more need to worry about namespace collision. Add that to your environment paths.

Things in multiple places? Sounds like hard (or symbolic) links to me. (man ln) Nothing revolutionary.

Can you see why lack of heirarchy is a bad idea? You get namespace collisions, a disorganized mess, and no clear idea of what's what. The moment you introduce anything vaguely clever, like different views per user, you've just added the old heirarchy under a new name.

Not saying that the file system is the best thing since sliced bread, but it really is good at what it does. Databases are good at what they do, which, curiously, isn't generally managing files.

My $.02.

Re:Misunderstanding WinFS

[leandrod]

> Set the sticky bit and a+rwx on / and munge your file ownerships (or POSIX ACLs) to your heart's content. Bam! No more heirarchy.

How come? ACLs and hierarchisation are orthogonal.

> Add / to your path, add / to your lib dir, add / to your man dir. It'd work.

And would be a mess. Unique naming anyone?

> different users should have different views? Er, uh, ok, so then we have /home/foo and /home/bar. No more need to worry about namespace collision. Add that to your environment paths.

And then get hierarchy back.

> Things in multiple places? Sounds like hard (or symbolic) links to me. (man ln) Nothing revolutionary.

Links still need something to be primarily somewhere in the hierarchy.

> The moment you introduce anything vaguely clever, like different views per user, you've just added the old heirarchy under a new name.

No, that's where the relational model for database management, or at least SQL, enter. You can do very interesting things with it, be it under the covers or at the interface.

> Databases are good at what they do, which, curiously, isn't generally managing files.

OS/400 does quite well. And a relational system would be even better.

Re:Misunderstanding WinFS

[ynohoo]

SQL: Standard Query Language for querying relational databases. "SQL database" is a meaningless phrase.

Re:Misunderstanding WinFS

[leandrod]

> SQL: Standard Query Language

Structured Query Language.

> for querying relational databases

SQL is not relational. It violates several principles of the relational model. The ISO SQL standards don't even mention the relational word since at last ISO SQL:1999.

> "SQL database" is a meaningless phrase.

It ain't. An SQL database is a database created and manipulated with ISO SQL. An SQL DBMS is a DBMS creating and manipulating SQL databases. You can even speak of SQL data, meaning data structured with SQL.

Re:Misunderstanding WinFS

[ynohoo]

Thanks for the corrections! Although basing the structure of the database on the nature of the queries sound like it could rapidly turn into a nightmare - unless you still have a DBA saying "no, you cant do that" : )

Re:Misunderstanding WinFS

[leandrod]

> Thanks for the corrections!

You're welcome.

> basing the structure of the database on the nature of the queries sound like it could rapidly turn into a nightmare

You could argue ISO SQL itself is a nightmare, but fact is Oracle SQL or Transact SQL are even worse, MySQL a disaster and mostly everything else a complete disaster, specifically if it has something to to with XML or OO. The only good stuff around are the relational systems: Tutorial D (toys only up to now), Alphora Dataphor (MS.Net), Duro and Opus (only libraries)...

But fact is that the only goal of structuring data is, not only querying, but manipulating it - SQL is actually misnomed. If you can't manipulate, it is not useful, it is not even data but only random bits. And SQL specifically lacks much power that the relational model provides.

Also, SQL includes DDL. So you do use it to structure the database. Bad as it is, doing it in something like ERDs is even worse and still has too be translated to SQL or something the like.

wrong !

[DRWHOISME]

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.

Why not create it Open source..

[Anonymous Coward]

Tha would be a really good innovation not coming from MS :)

App breaking

[Anonymous Coward]

OK, the first app break was going from DOS to Windows (say 3.0 or 3.1). You could say the DOS doesn't count and Windows was MS's first OS, but a lot of sophisticated software was written for DOS -- games, GUI word processors (you had GUI's in the DOS days only you had to do everything in the app -- in fact WordPerfect put a lot of work into their DOS GUI and were slow to develop for Windows which in part gave Word a leg up).

The second break was Windows 95. Yeah, yeah, about how much 16-bit API made into into Windows 95, and yeah, yeah, Windows 3 programs ran under Windows 95. But it was a big break for users (the shutting the computer down by selecting Start, the cascading Start button menus -- a lot of users, i.e. my dad, were pretty comfortable with Windows 3.1. And it was a big break for developers -- the changed WinProc, the flat memory model. As both a user and a developer I stuck with DOS and skipped Windows until Windows 95 came along.

Now Windows 95 was a big, big rollout. Yes it was late, but once it happened, Microsoft made a big push, both with developers and with users. You didn't have to port apps over to Windows 95, but there was a lot of encouragement and hints dropped from Microsoft to get everyone on board.

.NET is the third break in my enumeration of things, and the interesting thing is how Microsoft has had this ever so slow multi-year rollout. The only real break is that you can't get VB 6 anymore -- VS.NET otherwise supports MFC and ATL C++ programming as usual. Heck, Windows still doesn't ship with the runtime; you have to download it. So now they are planning a fourth break before break number three has even caught on. This sure as heck means the third break won't attract much interest.

Re:They don't cut it because of IE.

[cbreaker]

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.

HTML's lack of features? No.

[Mufasa3245]

1. Create a fast drawing program
2. Build a real-time spell checker with wavy red underlines
3. Warn users that they are going to lose their work if they hit the close box of the browser
4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server
5. Create a fast keyboard-driven interface that doesn't require the mouse
6. Let people continue working when they are not connected to the Internet

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.

Re:HTML's lack of features? No.

[CrazyLegs]

I think the point being made is that it's really a pain-in-the-ass to build and manage Web function with these kinds of features. Sure, it IS technically feasilble through a variety of means to do this stuff (Javascript would be the LAST choice for me). But how much effort and complexity is worth the results? It really depends on the audience you're writing for, I think. In a corp IT shop (my background), it just makes sense to go the rich client route for doing any function that requires high responsiveness, richer interface, etc. We can do this because we (a) own all the clients and sys mgmt process and (b) it's easier to develop/maintain these types of apps vs. Web-based function.

grain of truth

[Anonymous Coward]

whether you agree with Joel or not, there is a grain of truth in the article. The landscape of development has changed over the last 8 years. OS level API definitely aren't as important as they used to be. Whether they will regain the same level of dominance is questionable and no one can really say with confidence which way it will go.

The only thing you can count on is change.

his skin

[cratermoon]

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.

Re:his skin

[Anonymous Coward]

> because customers are probably already asking about it

Well, I think his point is that customers are only asking about it because Microsoft is baiting them to - it doesn't really buy him anything to port.

This is the exact same thing that he (and JWZ) bitched about with Netscape on Unix -- they threw away perfectly good Motif code for the sole reason that Motif wasn't cool anymore.

Re:his skin

[cratermoon]

> customers are only asking about it because Microsoft is baiting them to - it doesn't really buy him anything to port.

Well that's exactly it. The article is a long hagiography on how great Joel says it is that the windows team has done everything possible to make it so old software continues to work, and hey, Windows is pretty darn good as it is, so please please, says Joel, don't make me port to .NET and lose 12 man-years and get wiped out by Microsoft anyway when they ship MSDesk for .NET.

Wrong.

[DRWHOISME]

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.

Re:Wrong.

[drsmithy]

Making the auto analogy is WEAK.

It doesn't have to be an auto analogy. Pick any product that has complementary parts sourced from different sellers. Bikes and tyres. Computers and CPUs. Mobile phones and phone plans.

The auto makers are actually trying to monopolize their electronic system controls but the government is telling them to stop it.

Thus probably making the vehicles more expensive and adding another layer of complexity for the consumers. Good old government !

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)

Probably, but there isn't only one type of car sold. (little analogy there)

And i can choose what kind of tires i want on my new car.

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.

The dealer doesn't give a damn because he's not influence by fear or money like what goes on in software.

The dealer is most certainly influenced by money. If he isn't, he won't stay in business for long.

Similarly in software, the only "fear" is fear of losing money, but losing competitive edge. It all boils down to money. If there's money to be made selling PCs without OSes, rest assured someone will (and does) do it.

Chew on that fool.

I think you should spell that "fewl". It would suit the rest of your post better.

Re:Me on Joel

[Anonymous Coward]

The guy writes a bug database application and thinks he's Gods gift to application development.

Someone give the guy a hook - he gets too much notoriety being a "know it all".

wrong.

[DRWHOISME]

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.

Re:I do agree, and not with you.

[cbreaker]

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.

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

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.

Re:Bizzare, yes. Undocumented, no.

[pjt33]

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.

Re:Why the browser will NOT be the future of app d

[Anonymous Coward]

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.

Backwards compatibility is possible. Forever

[jhoger]

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

Re:Backwards compatibility is possible. Forever

[Jerf]

You missed the point entirely. I never said it was technically impossible, I said it's not free. It costs, and those costs rise, they never fall.

Is Wine done yet? (Yeah yeah, "Wine Is Not An Emulator"; today it is.) How long would it take you to finish Wine, plus .NET support, plus Avalon support... ... and here's the real point: While you were doing all that, did your competitors eat your lunch? (Even Open Source competes for developers.) Yes, yes they did.

(Answering an obvious misunderstanding: You can't get out by saying "I'll just use Wine", because emulators are taking longer and longer to develop, especially for moving targets like Win32. Again, that solves a technical problem, but only in an idealized world where you have infinite time to wait for someone else to do your work with no repurcussions.... and if you have to do the work yourself you gain nothing.)

Re:Backwards compatibility is possible. Forever

[jhoger]

Hrm...

QEMU is more what I mean by emulator.

Want to run Windows 95 applications? Run them under Windows 95 in QEMU, or VmWare, or maybe VirtualPC.

Given the project's momentum, within 1 year QEMU will be as good as VmWare in OS compatibility. It will be Free in all possible ways.

Crossover Office version of WINE works very well. With the abandonment of Win32 the API will be anything but a moving target.

I'm just saying that you can have as much backward compatibility as you like pretty much for free. Just quarantine those old apps off into their little sandbox subsystem.

What you don't want to do is keep growing the old API till its horrifyingly crufty and creaking under its own weight as Win32 is.

Re:Backwards compatibility is possible. Forever

[meadowsp]

We use Charon VAX emulator to run 20odd year old software. Works a treat.

Uhuh..

[Deleriux]

1. Tell everyone the Win API is dead.
2. Insert advert at bottom of article.
3. ????
4. Loss!

Re: DR DOS

[Anonymous Coward]

DR-DOS's memory manager was incompatible with Windows, and a patch appeared from DR after several months.

Cross-platform .NET finds its calling

[roesti]

For me, [the Java vs .NET debate] is pointless unless .NET somehow becomes cross-platform, at which point I expect Bill Gates to burst into flames.

As good a reason as any for Mono to exist, really...

Re:FP

[Anonymous Coward]

With Floating Point? Thy register runneth over...

Security implications of kludged patches?

[xixax]

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.

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:Security implications of kludged patches?

[Anonymous Coward]

The "fix" is probably just to delay frees... So that you have a side list (possibly just of 1, maybe a short queue), and when a request to free comes in you free the last allocation requested to be freed. There's probably not much to exploit here (or in other similar fixes). You can imagine once you implement this for one application if another has the same problem it's easy enough to turn it on for that app as well. Given that all apps have bugs, and the number of apps that exist for Windows, I could imagine a fix like this could get used alot (and not be just some "languid backwaters").

Finally let me point out that if you can choose the name of the executable on the OS you already almost undoubtably have full control as that user. So you own the system. Why are you trying to mess with the memory allocator when you can just rmdir /s /q %userprofile% if not rmdir /s /q C:\?

I respect Joel, but..

[NullProg]

From a cross-platform C/C++ programmer who is probably not as good as Joel, a couple of issues.

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

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,

Re:I respect Joel, but..

[Yahnz]

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

umm.... because their customer list if a few orders of magnitude bigger than yours, and their customers' customers aren't as understanding?

Re:I respect Joel, but..

[mx.2000]

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?

Microsoft Mail to 5,000,000 Developers: Umm, we fixed this bug in win32.dll, just check your code and recompile. Once the 1,000,000,000 Windows-Users have their windows Update fired up, you guys can distribute your patches!

yeah, sure, why can't they do that?

Seriously, this affects ALL kinds of widespread APIs, open or closed source. Once you have reached a critical mass of people using an API, you'll never ever get rid of it.

Hell, Unix is decades old and we still have creat() and umount().

Speciousness nit-pick

[IBitOBear]

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

Re:Speciousness nit-pick

[sql*kitten]

Sparc garbage collection shared object library that you could LD_PRELOAD with any C program to make it self healing

Sounds interesting, got a URL for it?

Re:Speciousness nit-pick

[IBitOBear]

Nope, Sorry.

It was an alternate memory management library thing that came with Sun's "Workbench" their (expensive) C/C++ SPARC compiler suite. The .so bound-over malloc()/new with a configurable/debugable implementaiton of same (you know the bit, landing and buffer zones etc) and it also bound-over free()/delete with a no-op [delete would do destruction but not then free the memory].

The library then leveraged some special memory fragment usage-tracking hardware in the SPARC chip. Periodically it walked the application stacks and static areas, treating every aligned pointers-worth of memory like a pointer. If the value as intrpereted lay within an allocated block of memory the block was likewise scaned (etc, recursively). Memory was freed when it could no longer be reached from any reachable reference.

Essnetially programs could not leak memory, and pointers could not be stale. (Unless, of course, you worked to sabatoge the system.)

I used a Workbench(tm) compiler for about two years before I, one day on a whim, started reading through all the directories and obscura that was installed with the package.

Anyway, I "repaired" several comercial applications that were known to leak memory and/or core-dump [in particular the IDEAS(tm) and Gateway(tm) elements of NetExpert(tm); the worst comercial software package ever written priced over $150,000(USD)] simply by doing the LD_PRELOAD.

I beleive a similar "mark-sweep" garbage collector is now built into gcc if you know how to use it.

But the shared library thing (especially with the tunable-by-environment-variables safety/debugging features) was a lifesaver for bringing some very terrible comercial software into rational useability.

Re:Speciousness nit-pick

[sql*kitten]

It was an alternate memory management library thing that came with Sun's "Workbench" their (expensive) C/C++ SPARC compiler suite.

Interesting, I have SPARCworks or SunPro or Forte (whatever it's called this week :-) ) but I'd never heard of this. I will investigate. Thanks for the tip!

That's insane...

[Yahnz]

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

Re:That's insane...

[Anonymous Coward]

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

Or, you have a buggy OS library on your hands (at least the part you're currently working with) and you need to figure out what's wrong so you can make a small testcase for the OS maintainers. Maybe even patch your copy so you can work around the bug until the OS maintenance release comes out that fixes it.

And no, this hardly comes out of "free time". It's expensive to be debugging someone else's libraries instead of working on the main job.

Re:Why the browser will NOT be the future of app d

[matrix0f8h]

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.

know what's really funny?

[Anonymous Coward]

That article is probably responsible for keeping me developing on Windows. I didn't know about the C++ compiler, optimizing and all, being free. I didn't know about the insanely cheap MSDN Universal. Then Raymond Chen's blog is icing on the cake ...

i bet you can find allot of bugs using chen's page

[Anonymous Coward]

what do you think?

Device drivers and testing

[Anonymous Coward]

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?

Re:I disagree .NET will fail due to Longhorn/Avalo

[EddWo]

Except that Longhorn/Avalon/WinFS is built with .Net, so all that training carries right over.
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 .Net now and move their existing applications onto it, it only makes it all the easier to jump onto Longhorn.
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. .Net is not going to go away, it's going to be at the core of the whole Windows platfom.

You ARE dumb. Stop programming now.

[Roman_(ajvvs)]

I'm giving up mods for this, but I'm compelled to bite... I feel sorry for the person having to maintain your code.

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

Re:You ARE dumb. Stop programming now.

[Anonymous Coward]

That was anecdotal and unnecessarily harsh. You should have kept your mod points.

Re:You ARE dumb. Stop programming now.

[DerWulf]

Never use Thread.yield() to fix multithreading issues. If your problems go away after you pop in some yields,chances are its pure luck and as portable as the empire state building. Use sleep(), wait(), notify() instead. Look it up yourself, I know you can.

Windows Emulation

[Jonathan]

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.

Re:Windows Emulation

[Anonymous Coward]

How can someone with a 4 digit ID be so ignorant? There's about 10 million apps availible on Windows not available on Mac, ranging from general purpuse tools like MS Project to an uncountable number of vertical market and internal applicaitons.

Oh, sure Steve tells you that you "don't need them". But what if you actually do need them?

Re:Why the browser will NOT be the future of app d

[sipy]

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?

hoist by their own petard

[scrytch]

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.

So if I'm interpreting accurately, Microsoft just pulled off a successful vaporware strike ... on their own platform

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+, .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.

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 .. in fact, one major REASON it's moving to a new set of API's is to avoid the commodity the Win32API is becoming!

Re:hoist by their own petard

[Chester K]

MS is hardly doomed .. in fact, one major REASON it's moving to a new set of API's is to avoid the commodity the Win32API is becoming!

The main reason Microsoft is pushing away from the Win32 API is not because it's a commodity (even WINE still doesn't have it right). The reason is that the Win32 API has years upon years of bad design and accumulated cruft, and is difficult to secure. Microsoft, while building their market share, had to cater to everybody -- even at the expense of design coherence. (For example: "Yes, Win95 can run Quake!" was a necessity even though it required massive design faults to make it happen.)

Now that Microsoft is in a solid position of owning the desktop market, they've successfully transitioned over to a stable, robust kernel design; now they can start ditching Win32 and start sheperding developers to a completely different, well-designed API. See the .NET Framework for phase one of the plan, which ditches the legacy dependancy on unverifable languages like C. Phase two is WinFX/Avalon, which ditches the legacy dependancy on the Windows UI fundamentals.

Re:hoist by their own petard

[multi io]

It makes no sense to completely ditch any C-based API layer in favor of .NET, when you can as well implement the .NET CLR on top of a (still available and documented) C-based API (as is the case in the current implementation). There are languages that come with their own, specialised runtime with distinct advantages. Highly dynamic languages like Smalltalk or Ruby come to mind, as well as languages like Ada or SPARK, where the compiler does all the checks and correctness proofs, so it's perfectly valid to compile everything down to low-level, unchecked machine code in the end. Using the CLR as the common base for everything would cost an order of magnitude of performance and would question the status of Windows as an all-purpose operating system.

Leaving the .NET framework as the only documented interface to the operating system has no benefits except lower maintenance costs for Microsoft -- but the have enough money, haven't they?

Re:hoist by their own petard

[Anonymous Coward]

multi io wrote: Highly dynamic languages like Smalltalk or Ruby come to mind, as well as languages like Ada or SPARK, where the compiler does all the checks and correctness proofs, so it's perfectly valid to compile everything down to low-level, unchecked machine code in the end

Sorry, but a secure runtime can never trust that the intermediate bytecode is correct. Any language whose "complier" produces an intermediate step that is then interpreted into native machine code can be hijacked by a sufficiently clever and/or persistant developer. Please refer to Jasmin (a "Java assembler") for my proof-by-example. If a Java VM implementation ignores the security rules (sandboxing and bytecode validataion), a malicious developer could use Jasmin to write an exploit.

Never forget: security is a process, not a simple goal. Production systems which face a network must have professional paranoids designing, reviewing, and maintaining their security infrastructure.

Re:hoist by their own petard

[multi io]

Sorry, but a secure runtime can never trust that the intermediate bytecode is correct.

I didn't claim otherwise. It can't trust that intermediate bytecode is correct, it can prove it (for certain definitions of "correct"). That is, it can prove that the code complies to certain rules (no stack overflows/underflows, compliance to statically declared type information etc.), or that the code does not call specific (potentially insecure) low-level APIs (Perl's or Ruby's "tainted modes" also do this to a point, as well as Java's security architecture).

My point was that it would be unwise to provide the CLR/.NET framework as the only interface to the operating system, because there are cases where you use languages like Perl or Ruby that come with their own runtimes, including sandboxing features. As far as I know, you could download and execute untrusted Ruby scripts from the web and run them in an interpreter on your local machine, as long as you make sure Ruby's "taint mode" was activated before (Perl's taint mode is insufficient for running untrusted code).

Please refer to Jasmin (a "Java assembler") for my proof-by-example.

Oh, you're the Jasmin developer?

If a Java VM implementation ignores the security rules

Yeah well, there are always some things you have to depend on, and most of the time, a non-faulty JVM is one of them :-)

Re:hoist by their own petard

[Chester K]

There are languages that come with their own, specialised runtime with distinct advantages. Highly dynamic languages like Smalltalk or Ruby come to mind

The CLR does a pretty good job with dynamic languages, despite what the poor results from the programmers at ActiveState have said after their halfhearted attempts to get Perl running under it. IronPython (A Python compiler and runtime for .NET) is turning out to be faster than the original C Python implementation.

MSIL is just as suited to running a dynamic language as regular assembly is.

as well as languages like Ada or SPARK, where the compiler does all the checks and correctness proofs, so it's perfectly valid to compile everything down to low-level, unchecked machine code in the end

That's what the Microsoft.NET CLR does. MSIL was intended from the start to be able to JIT as efficiently as possible, so it was designed to be type-checked and provably safe, so the JIT can output optimal native code -- in most cases, it'll emit exactly the same code that a native C compiler would have output for the same routine. Microsoft's implementation never interprets the MSIL bytecode for execution. The Mono implementation only does if you use the debugging "mint" tool, or if you're unfortunate enough to be running on a platform they haven't created a JIT for yet.

This is a striking contrast to Java, whose bytecode was JITted only as an afterthought. The CLR can run Java code, but it can't optimize it that well due to the unavoidable overhead that the Java design enforces.

Using the CLR as the common base for everything would cost an order of magnitude of performance

You seriously owe it to yourself to look into C# if you think it's "an order of magnitude" slower than native code. You'll be very pleasantly surprised by its high performance. You might even have a hard time telling it apart from native code (Windows.Forms notwithstanding).

Reason #78,048,234 to dump Windows

[humankind]

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.

Re:Reason #78,048,234 to dump Windows

[bheer]

Backward binary compatibility has a price. So does not providing backward binary compatibility. Real software vendors (IBM, Sun, etc) have known this for decades. Unlike, say, wannabes like Redhat, which took the high road and said binaries for Redhat N.x won't run on N+1.x.

Of course, with open source, you may have the option to recompile, but not if you're running something that's closed-source, like DB/2 for Linux.

Anyhow, the lesson from the last 20 years is that the software market (including those who pay for open-source, such as Citibank) values backward binary compatibility. With their 3.x RHEL line, Redhat has shown that they too have gotten this message. Microsoft's approach to backward compatibility might seem kludgy, but this is probably one of the best things they've done.

There's probably a zillion special little mods to the OS to make select, Microsoft-approved legacy apps run properly.

The only index MS would use is: is it popular? if so, it would be supported. Take a look at AppCompat sometime - lots of stuff from Lotus and Corel are on that list.

Btw, the parent has got to be one of most clueless posts I've ever read on Slashdot. That it got to +3 Insightful is just sad.

Re:Reason #78,048,234 to dump Windows

[Anonymous Coward]

RH N.x binaries run on N+1.x but you need compat. libs installed, which will only be done automatically if you _upgrade_ to N+1 and are therefore likely to be using N.x binaries somewhere. I've got apps that were compiled last century running on this RH9 box.

RH N+1.x binaries won't run on N.x but why would you downgrade? This happens too often to contemplate with Windows anyhow, and due to late binding it can mean that all of your $100k application works on old versions, except for say the Save and Export features. Ouch!

Make it linear

[Anonymous Brave Guy]

Maintaining reverse compatibility is the right thing to do today. It's the right thing to do tommorow. It's the right thing to do next week.

But it is not free, and the costs grow exponentially with each iteration.

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.

This guy has to be the dumbest dumbfuck in history

[JessLeah]

The Windows API lost? Is that why Windows is still "dominating" (read: monopolizing) the desktop computer world, and a huge percentage of the server world? I hate Windows, but this guy is a lunatic if he thinks the Windows API "lost" anything. Bill Gates probably laughs his billion-dollar tuckus off when he hears idiotic Pollyanna optimism like this. NEWS FLASH: The Win32 monopoly is stronger than ever. Linux is still a niche-market thing (outside the server and embedded worlds), end-users won't touch it, fear it, and probably hate it. Dumbass.

.Net just sucks

[Anonymous Coward]

.Not is just like VB it just plain sucks.

NET & C#-Smalltalk.

[Anonymous Coward]

Go to the smalltalk groups. There's a lot of things happenning in smalltalk (including jobs). The bad thing about smalltalk, has little to do with the language, and more to do with history, and marketing.

Flex

[hackrobat]

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.

Re: DR DOS

[craXORjack]

Probably not unless you are a monopoly - and they weren't at that time, just aiming to be. And their aim was pretty accurate.

If you had followed the MS antitrust trial you should have learned that a company can hold a monopoly with as little as 30-40% of marketshare depending on the industry and other circumstances. MS had greater than 90% share of the IBM PC OS market right from the beginning when IBM began bundling it with their personal computers. So MS was unquestionably a monopoly from that point forward at least in the market for IBM and IBM compatibles. (Yes I am ignoring Apple here but they never stood a chance against IBM) Just because a federal judge had not yet ruled that MS holds a monopoly did not mean they didn't have one. The ruling just meant that MS needed to quit wasting the courts time by denying something so obvious.

But by your own argument...

[Anonymous Brave Guy]

When Longhorn/Avalon finally gets released, the adoption I expect will be slow. We just spent all this money becoming proficient with .NET. Why change to the new system now? Unless you need the new features, .NET should cover most needs of application and web developers.

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)?

Re:I do agree, and not with you.

[Kiryat Malachi]

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.

Productivity boost by managed memory is overblown

[yeremein]

... Visual Basic is significantly more productive. Often I've written the same code, once in C++ calling the Windows API and once in Visual Basic, and C++ always took three or four times as much work. Why? Memory management.

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

wrong again

[DRWHOISME]

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.

Re:wrong again

[drsmithy]

Where would like me to start on your absolute weak pathetic reply ? hmm.

I'd suggest the beginning. You might also find it more challenging to actually reply next time, instead of talking about replying.

First of all my friend we spell 'tires' this way.

How interesting. Where I come from we spell it correctly.

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 ?

No.

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.

So, just like the computing world, you mean ?

What do you think the stock price of Goodyear would be if all cars in this country had to use their 'tires'(not tyres).

In a country where that was true, I doubt there'd be much of a stockmarket at all.

I could go on and on but your a lost cause.

Actually, I'd say you're a lost cause, with spelling like that.

Yeah , the government is robbing us blind and Microsoft's a saint.

The government is robbing us. Microsoft, however, are not Saints.

Re:This guy has to be the dumbest dumbfuck in hist

[Anonymous Coward]

Heh! Mod parent up, plz!

ASP.NET is brilliant?

[cnoocy]

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.

Re:ASP.NET is brilliant?

[reanjr]

I've been using .NET since before VS.NET was released and I've been absolutely amazed at how much ASP.NET is taking off on the Internet.

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:ASP.NET is brilliant?

[DukeyToo]

I use ASP.NET regularly; it is my web development tool of choice.

I find ASP.NET a little bit of a contradiction really...In so many ways it seems designed like VB6, i.e. simplified so much that it hurts sometimes. In other ways, it uses code inheritance for web pages, user-controls and web-controls, which are all wonderful things.

I'm hoping ASP.NET 2.0 will be better, but I already consider ASP.NET to be better than plain old ASP (no experience in PHP, so I can't comment on that).

Re:ASP.NET is brilliant?

[spruce]

I've never used PHP, but I've read some code understand it's bascially similar to ASP (yes, many differences.) It's bare bones, top down programming. Since developing in ASP.NET I've cringed every time I have to go back to ASP.

Web controls are great. If the ones MS provide don't do it for you, there's a myriad of third party tools available. The code-behind paradigm is great. Debugging in ASP.NET is straight from the heavens. You should check out DotNetNuke, it's an open source .NET alternaive to PHPNuke.

There's just way to many things to praise about ASP.NET compared to ASP, but to answer your question, yes, .NET has been a vast improvement for me.

P.S - upon rereading your post you probably know lots of these things, but I just wanted to say that there are those of us who are converted:)

Oh no....

[Sir Brialliance]

. . . 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 was wondering about that as well!

[SuperKendall]

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!

Re:I do agree, and not with you.

[cbreaker]

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 was going just fine until...;

[Anonymous Coward]

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?

Some examples

[Orion Blastar]

Poor people who cannot afford to upgrade their old system.

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 // and TRS-80 Systems.

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.

Re:Some examples

[Anonymous Coward]

Don't forget that they have to walk uphill both ways to use the computers. Bare foot. In ten feet of snow.

Re:I do agree, and not with you.

[Kiryat Malachi]

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.

Re: Note about dev tools

[Anonymous Coward]

There are lots of free dev tools available for windows.. (The following Is from The Forger's Win32 API Tutorials, A great site for beginners)

Free Visual C++ Command Line Tools

Getting Them

Microsoft has quietly released it's command line compiler and linker tools as part of the .NET Framework
SDK. The Framework SDK comes with everything you need to for .NET development (C# compiler etc...) including
the command line compiler cl.exe which, while it's intended for use with the .NET framework,
is the same compiler that comes with Visual C++ Standard.

.NET Framework SDK (Requires Windows XP or 2000)

Since this is the .NET SDK, it doesn't come with the headers and libraries required for Win32 API development,
as these are part of the Platform SDK. Lo and behold, the Platform SDK is free as well. You only need the Core SDK,
but feel free to download the other components as you desire.

Platform SDK

As a bonus, if you download the Platform SDK documentation (which I highly recommend) you will have a complete local
and up to date Win32 reference which is MUCH easier to use than MSDN online.

An explaination...

[Anita Coney]

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!

Good/Bad competition

[SnprBoB86]

Random MS vs Linux or whatever point:

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 .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 ;-)

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.

Joel doesn't have REAL support for his views

[Anonymous Coward]

Joel doesn't have REAL support for his views. He makes claims like "this is the way it will happen" and so on. Let me clue you in. Way back in 1991 there was Cairo. It was to be the next NT. It was to have what was originally planned for Longhorn, now Heartburn (as if), namely an object-based file system, among other grandiose things. Never (ever) happened. Cairo "became" Windows 2000 (only because it was the thing after NT, so not by fact, only by time/position). Anyway, long story short, get back in 2008 and see how it's all wrong all over again.

I don't think HTML is the future

[dfj225]

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!

Re:I don't think HTML is the future

[DukeyToo]

A little-known fact (it must be little-known, because no-one else mentioned it) is that .NET actually supports running untrusted, or partially trusted rich clients over the internet, using their browser as a launch platform.

The enabling .NET technologies for this are code access security (CAS), and isolated storage. CAS allows local machines to limit local permissions to the running application, based on a combination of factors including the location that the code is running from (e.g. over the Internet). Isolated storage allows an application to have a small file-system sandbox that it can use for its own purposes.

In .NET 1.0, Microsoft has not pushed this technology much, because they only had the groundwork done. Come .NET 2.0, and they will be pushing it more. Expect full rich clients that can be automatically downloaded, and installed on your Windows box, without worrying about whether the application has a virus or will interfere with other apps, etc, (because CAS prevents the app from doing anything that accesses the filesystem, the local network or whatever).

Web API for Longhorn clients ONLY

[PizzaFace]

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.

Re:Web API for Longhorn clients ONLY

[mpcooke3]

But Joel thinks the new API will not improve web apps so much that users and developers will need to flock to it.

That is clearly wrong IMO, I develop web application using DHTML/cookies/webpages etc,
A proper Web API will allow some companies to write proper applications delivered over the web. Imagine trying to compete against those companies by writing one of todays crappy webpage based pseudo-apps. Developers won't have much choice.

Also microsoft always have the option of upgrading IE/windows in Win2k to include more of the .NET framework if they feel that they don't have enough of a stranglehold to pull off the HTML->XAML move.

Re:Web API for Longhorn clients ONLY

[0123456]

"A proper Web API will allow some companies to write proper applications delivered over the web"

And that would make my granny or girlfriend upgrade to Longhorn because, exactly?

"Also microsoft always have the option of upgrading IE/windows in Win2k to include more of the .NET framework"

Why would they want to encourage people to continue running W2k rather than Longhorn?

Re:Web API for Longhorn clients ONLY

[mpcooke3]

"And that would make my granny or girlfriend upgrade to Longhorn because, exactly?"

Same reason as the win3.1 to win32 upgrade. Because lots of application only run on new computers.

"Why would they want to encourage people to continue running W2k rather than Longhorn?"

They would only do this if they weren't already obtaining critical mass with Avalon on Longhorn.

Mind you given eventually everyone upgrades their computer and there is no competition for Avalon they don't really need to speed up the roll out.

Re:Web API for Longhorn clients ONLY

[mpcooke3]

People upgraded from win 3.1 to 95 if they wanted to run the better/newer applications that were only available on 95.

People that want to access better/newer application only available to Avalon will upgrade to Longhorn.

Regardless of whether this happens in 1 year or over 5 years, what other possibility is there?

A next gen web API is inevitable as it benefits users, businesses and developers. So the real question is whose will become the adhoc standard, the open source API or the Windows one?

Oh no, wait, I forgot! There is no alternative to the windows one, well i guess that one might win!

Re:I do agree, and not with you.

[mt v2.7]

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.

Let me get this straight...

[Hard_Code]

Ok, let me get this straight:

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 .NET and a whole bunch of other replacement APIs

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

Re:Let me get this straight...

[leomekenkamp]

There is a little problem with your role-playing game: there is no TCP; these are actually divided into 3 groups. I like to call those groups '0: incompatible and ignorant', '1: compatible, but what slower' and '2:incompatible, but faster' (speed here stands for execution speed).

Group 0 is IMHO the worst, the SimCity example falls under group 0: using memory after it has been deallocated is pretty sloppy programming. That it worked under DOS is no excuse, it is simply wrong. Microsoft should IMHO have put _no effort_ whatsoever in 'fixing' windows to run simcity. Instead they should have pointed out where simcity went wrong, and offered to help the sc authors to fix their bug. Fixing it for them is bad, since then you are rewarding bad programming habits ("Oh, we can do whatever we want, MS will fix it if it does not work.").

Group 2 will become very very small once every member of that group realises that that 1% extra performance will lead to no performance at all in a next version of an OS.

Group 1 will have no problems whatsoever.

No take these 3 groups and place a number after each TCP: I come to 1, 1, 1, 0|2.

I will mock their API's.

[fwarren]

Drop the MCF stuff and try coding a toolbar by following the Microsoft docs.

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:I will mock their API's.

[TomGroves]

Agreed that developing for PocketPC is tricky in that so much of the documentation is for the CE platform, of which PocketPC is only a subset.

Re: DR DOS

[Anonymous Coward]

MS had greater than 90% share of the IBM PC OS market right from the beginning when IBM began bundling it with their personal computers.

That's like saying Coke has 100% of the McDonald's beverage mark. How narrowly do you want to draw the market? At the time of the launch there was this comapny called Apple who had shipped the Apple I, Apple II, Applie IIplus & the Apple III. So there was certainly strong competition there. Not to mention CP/M, whatever the hell Commodore ran or Tandy's ran, etc...

Pfft, the "IBM PC OS" market! Back to Apple, with a definition like that you can say Apple has a pure OS monopoly on the "Apple PC OS" market. When are we going to break them up? I mean, 100% of the market! It's unholy! They're going to destroy the free market! Everyone run for lives! AHHHHHHHHHH!!!!!!!!

I dunno

[autopr0n]

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.

Joel is weak.

[Anonymous Coward]

And personally I still haven't had time to learn .NET very deeply, and we haven't ported Fog Creek's two applications from classic ASP and Visual Basic 6.0 to .NET because there's no return on investment for us. None.

I had to stop reading at this sentence... He programs in VB! Only pathetic wanna-bes program in VB. Yuck! Get a real language. Weak as water.

Okay, that's what I thought.

[autopr0n]

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.

Re:Okay, that's what I thought.

[markov_chain]

Face it, NT is not a real-time OS and so there is no guarantee that random drivers won't hang the system for arbitrary periods of time. IDE drivers in particular used to be a nuisance even on earlier Linux kernels until the preemptive and low-latency patches, as anyone attempting real-time disk-recording or sound filtering could tell you.

As far as being dumb for not yielding etc., I have to admit that I would have preferred using a non-thread based solution to this problem. Doesn't Win32 have some sort of async I/O or select()? Event-based programs are IMHO more elegant and hide fewer scheduling decisions from the programmer.

Hey now

[autopr0n]

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.

Re:Hey now

[Mycroft_VIII]

I wrote more lines in ONE class in my first semester. at least 3 of the class asssignments were bigger than 50 lines.
I would seriously question how 'good' your school (or at least the cs dept) was considering at the time I was in a community coll.
I did get the department head to waive a bunch of intro courses, but none were actuall degree courses, just intro courses and pre-req's for the degree courses.

Mycorft

Re:Hey now

[Anonymous Coward]

Man/Woman(choose as appropriate) - Either you just troll and keep your sig or write informative comments but remove the sig. Its quite inappropriate seeing your advt sig and reading the informative comment at the same time while at work.

[ I am aware - sigs can be disabled ]

The worst thing...

[mscalora]

One of the worst things about the Win32 API is the zillions of #define macros for every function that takes a string parameter, as in:

#ifdef UNICODE
#define GetMessage GetMessageW
#else
#define GetMessage GetMessageA
#endif // !UNICODE

If you have a method called GetMessage in one of your clases very wierd things start happening sooner or later.

-Mike

Two Things...

[keefey]

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!

XUL

[harikiri]

I gave up on learning XUL when I read in the XUL introductory tutorial that:

In order to complete a normal sized program, you would eventually have to be fluent in XML, JavaScript, CSS, RDF, DTD, DOM, XPCOM, XPConnect, JSLib, and other technologies.

They need to simplify it. I'm not learning that many different technologies just to complete a "normal sized program".

MSDN docs vs. manpages

[lamber45]

perdoc is, in my experience, the best reference for an API. I would never say it's worse than any part of MSDN. Then again, the Win32 stuff on MSDN is often an edited version of what was there for Windows 3.0 (1990 or before), while the manpages for core commands and functions on UNIX are typically repackaged or rewritten versions of documentation from the AT&T codebase (1982? 1975?). Some documentation is very similar, or even the same, in manpages and MSDN; for instance, most of the OpenGL functions, when looked up in MSDN or the manpages on Solaris, are described word-for-word the same.

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.

GAMES

[Anonymous Coward]

do you have them?

Maybe not a must, but there's a reason behind it

[Roman_(ajvvs)]

With Java, you won't know whether or when the OS is going to yield your thread or not. Synchronization and things like yield() make things a bit more deterministic. Any Java API can document its threading issues in classes almost transparently. With Windows you don't always know it either. To compensate, the .NET API documentation states which functions are threadsafe under what conditions.

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.

And the very next sentence...

[ttfkam]

However, you will only need a working knowledge of the first three (i.e., XML, JavaScript, and Style Sheets) in order to start this tutorial. The remaining languages and technologies will be introduced as we encounter them in the process of building XulNote.

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.

Another way to look at it

[bheer]

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.

Re:Another way to look at it

[ttfkam]

First of all, it wasn't Caldera, it was Digital Research. Caldera simply bought the assets later. Second, it was malicious and intentional anti-competitive behavior by Microsoft. Have you read the court filings? Obviously not, or you would have understood the scope of what was done.

As far as "one case of bad press," one case of bad press about silicon breast implants brought Westinghouse (a huge company) to its knees on very questionable scientific grounds. In the Westinghouse case, it was fear, hysteria, and scapegoating. In the case of Microsoft and Digital Research, it was intentional corporate sabotage. It was perfectly reasonable to blame Microsoft, and competition had nothing to do with it. If competition was the issue, DR DOS would have wiped the floor with MS DOS in the marketplace. The same with Novell DOS.

As a (former) die hard [complainer]

[Anonymous Coward]

"This pipe dream has been repeated over and over and over for years. Okay, so we have Gecko, Java, JavaScript, etc. etc. -- all the attempts so far at "rich clients" more or less suck, because nothing yet ever invented made programming significantly easier than before."

Might that be because computers (and computing) aren't the same as they was 20 years ago? Your complaint is among the same level as a shade tree mechanic complaining that cars have gotten more complicated.

"So, instead of relatively simple and understandable things like POSIX and even X Windows, we now have 1000 layered buzzwords from SOAP to XML to JavaScript to whatever where no programmer on earth can hope to understand them well enough to really get real work done and test it on all the relevant platforms and find that it actually works on all those platforms...because it is all still based on POSIX/X Windows/MS Windows/Mac OS in the end. Full circle--we have gotten nowhere. "Web enabled" has taken the fun out of software development."

Well aside from the fact that you're exagerating the situation. The funny thing is that all the other places American IT jobs are going to, aren't having a problem understanding all those "buzzwords". Just pampered "we want everything to be easy" Americans.

"The best websites to this day are still damn simple. E.g, Google, Slashdot on "light" mode, etc. The most annoying are those whose developers had a JavaScript orgy and passed out before the QA meeting."

The best websites are were the webmaster gave a damn. Technology is a tool, nothing more.

Re:As a (former) die hard [complainer]

[Bozdune]

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.

MOD PARENT UP!!!

[calica]

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.

Re:MOD PARENT UP!!!

[bar-agent]

It is an example of holding your developers to a higher standard and them then matching it.

With the shared memory and other problems of the OS, you were basically forced to a higher standard. If you took too long to do something, the computer was basically frozen. If you didn't clean up your memory, the entire computer crashed and you had to reboot.

I notice a decline in programmers' level of responsibility now that we have a protected memory system. "Oh, the OS'll clean it up, not to worry."

I fear for the future.

mod parent up

[xixax]

Explains the limitations quite nicely.

Xix.

"Informative" my ass

[johannesg]

I suggest you stop your condescending whining and try learning something about programming. Why in the world would anyone want to yield() at _any_ time?

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.

Re:"Informative" my ass

[Roman_(ajvvs)]

If you find yourself calling yield() all the time

I agree that context switching should not be overused. Sticking yields all over the place won't do much for deterministic behaviour or performance. Anyone researching the topic in literature will find this out. It is however still important to understand why a thread should yield and be able to have a thread intentionally wait. It might not be the yield() command specifically, but it will be a thread-related command. join(), sleep(), block(), lock() are all conceptually equivalent to yield() with minor variations in their conditions. This has nothing to do with whether or not the OS supports preemptive multitasking or not.

Your "programming by numbers" you probably picked up in the sixties no longer has any relevance.

I'll ignore the "twinkle in my father's eye" aspect and just wonder why you think threading is no longer relevant in programming today? I'm sure ignorance is bliss, but I for one would like to understand how my program will run before it does so.

Re:"Informative" my ass

[johannesg]

Sticking yields all over the place won't do much for deterministic behaviour or performance

If you care about deterministic behaviour you should not use threads in the first place. But that's besides the point: you were arguing that because he wasn't calling yield() his software was not working. That's an attitude that went out of fashion with Windows 3.1. You are ignorant about modern operating systems, and apparently unwiling to learn.

It might not be the yield() command specifically, ...

You wrote "If you don't know why you need to specfically yield...". The answer is simple: you DON'T need to specifically yield. I would have forgiven you for this, except that you then went on to also say "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." which was a TOTALLY undeserved attack. It is YOU who does not understand basic programming theory.

I don't know where that list of functions came from, but at least join() is fundamentally different from yield() (hint: one of them ENDS a thread, and the other SUSPENDS it temporarily. If you do not know the difference, think of it as the difference between dying and going to sleep).

...just wonder why you think threading is no longer relevant...

Oh dear, that's not what I said at all is it? I said calling yield() all over the place is no longer relevant. But thanks for the strawman attack - it just shows the weakness of your argument. Now crawl back under the rock you came from before you make an even bigger fool of yourself.

I have said it before, and I will say it again:

[Alex Belits]

Joel Spolsky is a bigoted windbag.

Solaris desktop better than linux?????

[mountain_penguin]

I take it you don't use solaris. I do it sucks big time packages break in odd ways compiling things from source is a pain and suns version of desktops such as gnome are way way behind the curve forcing us to use blastwaves packages which have there own oddness (mime types don't work in nautilus!)
Man I wash sunray server software would work on linux and then we could have up to date less buggy desktop it would be fantastic

Re:Solaris desktop better than linux?????

[javaxman]

Dude,

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.

Re:Bizzare, yes. Undocumented, no.

[ThaReetLad]

Yes, just read Joels Sim City anecdote for examples of hidden modes in windows.

Tautology

[Anonymous Coward]

I love a good tautology...

Second paragraph:
Although there is some truth to the fact that Linux is a huge threat to Microsoft

A tautology is something that is tautological.

J2EE, portlets, .NET etc.

[Deternal]

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.

The API is dead! .NET lives again!

[ObsessiveMathsFreak]

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.

Essentially .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)

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

This is kind of a pity, because, to be honest, I'm sick of memory leaks.

Pales in comparison

[21mhz]

Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale.

Haven't seen Sun's Java documentation, have you? It's a whole another culture. Kicks MSDN's ass any day.

Re:Pales in comparison

[Anonymous Coward]

No, MSDN is definitely better than Sun's documentation for the Java platform.

JavaScript talks to servers (using a Java Applet)

[solprovider]

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.

Microsoft needs change, otherwise it will die.

[master_p]

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

Re:Microsoft needs change, otherwise it will die.

[ynohoo]

While I agree that the Win32 API has gathered alot of cruft, I do agree with Joel that Microsoft are shooting themselve in the foot by trying to drop it.

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.

Firefox/ Slashdot

[Mr Syd]

I'm seeing these probs with .9 as well - for some reason the "Games" section seems particularly vulnerable.

You have zeroed in on the right points

[fnj]

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

Manual / Automatic

[Mr Syd]

So, as a guy who rides a bike...

What is the one case where a manual car is better than an automatic?

Yeah, I agree

[Anonymous Coward]

The more I read his article, the more convinced I became that:

[Using language I learned on HBO]

(a) Joel is a Prick
(b) He's got his head stuck up Ballmer's ass
(c) I wouldn't waste my piss on him if his head was on fire, and
(d) Hey Joel, you lie down with dogs, you get up with fleas!

I concur wholeheartedly with your last sentence, javaxman.

Sincerely,
Joseppi Blauinski

KDE for Solaris

[why-is-it]

I would LOVE to be using KDE right now rather than CDE.

You can get KDE for Solaris, but you have to be comfortable with compiling it from source, or trust someone else's packages.

Re:KDE for Solaris

[harrkev]

Hard to do when my comany does not let me have admin access. I use what I am given (grumble grumble).

Huh?

[Da VinMan]

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?

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 /. but you don't HAVE to become part of the rabble.

Re:Huh?

[Alex Belits]

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?

He writes huge amount of umm... text, about things that either don't matter, or he has very little idea about, what is an example of the same kind of arrogance that his former friends at Microsoft exhibit. His opinions are mostly based on some vague idea of "how things should be done" or on some random interpretation of the decisions, made by Microsoft. He puts no effort into analysis, and doesn't look at anything but Microsoft -- if Joel mentions anyone/anything else, it's only if Microsoft wages some kind of ideological war with it, and only then Joel notices, and writes something about it, entirely from the angle of how does it affect Microsoft. Joel may not always defend Microsoft, but he always speaks from the Microsoftie position, and based on Microsoft ideology.

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 /. but you don't HAVE to become part of the rabble.

I have "informed myself about Joel" by reading his writings, and all I could find there was tiresome regurgitation of Microsoft ideology. Admitting the fact that Microsoft software design is shitty from Microsoft's own position does not make him smart.

Re:I don't agree--To fix Slashdot under Firefox...

[Synistar]

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

Re:I do agree, and not with you.

[Anonymous Coward]

I think you guys are missing the point slightly.
Joel isn't saying one platform or another is better than the other for developing, his laying out how it looks to the developing industry, and how MS are shooting themselves in their own foot.
Sure the standards might change for the web at some stage in the future, but its not on the books now. Thats the key part. What he's saying is that with MS bringing out new APIs and breaking the old ones, and with new APIs coming out just around the corner, whats the point in doing the development on an API that won't be around in 2~3 years time. You can be fairly safe in saying the 'net standards aren't likely to change in 2 - 3 years time.
I think this article reads as a rallying cry to Microsoft. Get your act together. Give us an API you can guarantee wont be thrown out the window within a short period of time. THEN and only then will people develop for it, and take the time to learn the necessary skills.

Re:I do agree, and not with you.

[Geoff-with-a-G]

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.

crazy Balmer in my mind

[supergwiz]

Developers, Developers, Developers, Developers
Why do I get an image of a ranting sweaty Balmer in my head when I read this?

And Another way to look at it

[Anonymous Coward]

You're a total fucking idiot.

NO! NO! NO!

[kikta]

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.

Re:Bizzare, yes. Undocumented, no.

[ACPosterChild]

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.

WRONG! WRONG! WRONG!

[metalhed77]

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.

W3C *not* Mozilla

[kikta]

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.

Re:I do agree, and not with you.

[Kiryat Malachi]

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.

*sigh*

[kikta]

Fine, you have the format for Flash, I don't know (and don't care) if Macromedia has released the format into the public domain or not.

Flash is a fucking animation engine. They bolted on accessibility. Great. What's my problem, you ask? Look at the Flash Accessibility FAQ:

What has been done to make Macromedia Flash more accessible?
Support for Microsoft Active Accessibility (MSAA) allows users of assistive technologies such as screen readers to access the contents of a Macromedia Flash movie.

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.

Re:*sigh*

[metalhed77]

Well we're kind of stuck between a rock and a hard place then aren't we?

On the one hand we have the W3C is has been fine for the non-rich content web and is quite accessible, and on the other we have flash that is accessible only to most and has the rich content.

That being said, thanks for bringin this to my attention, I had no idea flash's accessibility was so bad. However, I'm still going to use it because handling images will be one of the central purposes of my app and, well if you're using a screen reader you probably have no use for it anyway.

Re: DR DOS

[Anonymous Coward]

You obviously didn't live through the period or were way too young to know anything about it.

Re:I do agree, and not with you.

[cbreaker]

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.

Re: DR DOS

[WNight]

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.

.NET doesn't have a Win32 underpinning

[bonch]

That's one of the advantages of it. As a matter of fact, it's replacing Win32 in Longhorn.

Carbon IS MacOS Classic

[bonch]

They're pretty much the same. Cocoa is the new API.

Try Cocoa sometime. People wonder how they developed things without it.

The difference

[Julian Morrison]

...is between being "a major player", and owning the game.

What about *nix ported applications?

[bonch]

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.

Re:I do agree, and not with you.

[geminidomino]

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

Developing COM using Borland Tools

[Latent Heat]

"COM is the most confusing and awkward mix of macros, templates, libraries, and obscure "wizard" generated code that I can imagine."

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.

Uh yeah, Longhorn did you RTFA?

[Orion Blastar]

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.

More on Longhorn

[Orion Blastar]

RTFA and see if Longhorn has legacy support. Unless they added it in since that article was written, I doubt it.

Software Engineering Distortion Field

[Spinlock_1977]

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?

Design flaws beget ugly patches, ugly patches beget uglier patches, and eventually, you'll have to rip it all up and start over... .NET anyone?

Of course, .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.

- spin