W7 was pretty good when it was freshly installed on a quad 9550. Now that I've been using it for a few months I'm noticing it has the same issues as all the others: bloat. If you have nothing other than the OS installed, it's pretty fast. Throw 60,000 files through software installs, picture collections, music, videos, documents, etc. and lets see how slow it gets.

Speaking as an ex OS/2 user : you're talking nonsense.

Right from NT 3.1, 16 bit Windows apps were either run collectively in a virtual DOS machine, or in a separate virtual DOS machine session. A badly behaved 16 bit app could lock up any apps within its virtual DOS machine, but not other virtual DOS machines or any other NT subsystem (Win32, Posix and 16 bit OS/2 at the time)

On 64 bit versions of Windows there is no Windows 3.1 or indeed 16 bit compatibility.

This (poorly written) article is talking about coping with buggy apps to prevent them crashing.

Compatibility is generally one of the top priorities of Windows, and is a key reason Vista had issues (aside from bugs). Vista started enforcing coding standards that should have been followed for years and things started to break.

If a system does briefly 'freeze' there are many possible reasons, and scheduling is not necessarily one of them. Alternatives include poor drivers, single threaded code and blocking waiting on resource. Being unable to interact with the system with a KVM does not mean it has frozen.

OS/2 is almost dead. It was old and smelly in 1999 when I stopped using it, and it's not much better now (although at least it runs fairly up to date open source apps).

Even if OS/2 hadn't died, it would have required a huge overhaul. Its lack of multiuser design, the synchronous input queue and archaic (if fairly efficient for some purposes) kernel would have caused real problems in future years.

If IBM had spent its resource on a portable OS/2 x86 instead of squandering it on OS/2 PPC/Workplace OS, OS/2 might have had a chance. Sadly its death was always assured in hindsight.

You say: "Windows NT (2K, XP, Vista, 7) do not use cooperative multi-tasking, their are fully preemptive"

That's what I keep reading, yet I can SEE (XP) foreground tasks sometimes freeze for seconds at a time under even light load. But you're definitely not *entirely* accurate because "somewhere" in even 7 is support for Win31 processes that you effectively state by omission from your list ARE using the "cooperative" scheme. Along with that are surely some primitive heap management and memory reclaim routines, and if the basic problem goes back 20
years, then those are likely what are exploited.

Perhaps the freezes just show that the M$ scheduler is lousy. Fact is that M$ is new to pre-emptive multi-tasking. Up to the 2K version, what they had was a "cooperative" GUI shell atop single-tasking DOS. (Well, there's NT prior to that, but it's a snake pit that they try to forget.) Anyway, M$ sold a primitive system to the unsuspecting general public for at least seven
years while the alternatives that I named did it right.

I understand kludges, and the reason for kludges, and to some degree sympathize with even M$ programmers for having to cope with the history, BUT writing an OS isn't really as difficult as M$ makes it appear.

By the way, OS/2 could be called NT 2.3 and has delivered XP level performance since 1993. To large extent, OS/2 is the
foundation of 2000 and later, but M$ left out much.

Hi Kids! Still don't know what DirectX is or where it came from? Don't forget to pick up this month's (or next, or last years, or 2000's) copy of CPU Magazine. Alex St. John has written effectively nothing else for the past decade or more in his useless monthly column. Well, except for the odd Post-Script driver article. (I'm yawning even as I write this comment)

Come on, Alex. At least read your own morose tagline and see that it's probably time to move on from heralding yourself as "President and CEO of a technology company devoted to delivering CD-ROM quality entertainment content over the Web". Wow, CD-Rom is the future, and the future looks bright. Well, CD-Rom and PostScript. 72 points to the inch Zzzzzzz...... you're a gnat's eyelash away from being buried even deeper in this rag (a position currently held by "The Cutting Edge's" Barry Brenesal. Who, I shit you not, offered a spotlight on DESQview in the November 2009 issue) Ahhhh progress.

You sound sure of everything you say.... one simple question though.

Name me one movie using computer animated effects/characters/objects/... that uses DirectX for rendering?

I just want one movie, only one please.

Didn't avatar look soooooo real, wow they must have used DirectX for that because opensource OpenGL is sucky as Brian Burke has said.

@Stuart Halliday: you don't know what hacker means (probably coz of the media using the term with bad conotations)

# S: (n) hacker (a programmer for whom computing is its own reward; may enjoy the challenge of breaking into other computers but does no harm) "true hackers subscribe to a code of ethics and look down upon crackers"

With Linux, you simply select a PAE kernel upon installation and your heap doesn't get executed any more. Problem solved. (Windows can use PAE, too, but the crappy Windows drivers don't like it.)

Apparently, memory heaps aren't the only thing that become corrupted. Facts get corrupted as well, especially in the hands of an idiot like Ed Berridge (author of this Inquirer article). The original BetaNews article doesn't make Russinovich out to be the lone Mr. Fixit that Berridge portrays in this article. The BetaNews writer (Fulton) even posted an update at the end of his article chastising some of the reporters who purportedly summarized his article. The second bullet point of that update could well have been written in direct response to this Inquirer article:

i "Russinovich did not build these new features, such as Unified Background Process Manager, alone. There is a large company called Microsoft which is his employer, and which has hired a battalion of developers." /i

Gosh, that's not quite the impression I got from this Inquirer article.

Mandate 64-bit processors with NX flag and you'll fix most of your problem.

Heap corruption is not something Windows-specific, although Windows' heap corruption is, obviously. Not every Windows programmer uses MS's own programs, and this kind of error cannot be detected at compile time (most of the time anyway) since it pops up at runtime. It IS the program's fault, and ultimately the programmer's fault.

Every Windows programmers use Microsoft's own programs. Why these tools still allow such basic security threats is a mystery. Don't blame the programs, blame the tools used.

How can a Computer programmer like Mark who has direct access to the OS source code be called a Hacker?

Or is the Inq. just trying to spice the technical article up?

you install linux(ubunty if your a beginner) and see that its even faster... and doesnt BSOD whenever you take a CD out and doesn't misterously get spyware infections.

Or then you can buy a mac...

bad comparisson - 98 guy's horse and buggy will whip your Windows 7 machine even if you gave it 10 seconds headstart.

I have at least one win98 machine and use it whenever I can as it MUCH faster than any energy chomping modern beast. Most everyday things dont need processing power.

Admittedly i've doctored win98 a lot using 98lite and 982me but hey ....

How nice for you! Buy the way, may I borrow your horse and buggy next Sunday? I have a tea dance to attend.

I'll just keep running win-98 until there's actually something I even moderately need to do that can't be done on it (and BTW, running win-98 on 3-year-old hardware will all drivers ain't bad).

"is that Windows doesn't exactly have full control of processes, because somewhere still in it is the "cooperative" multi-tasking scheme (that they borrowed from Apple), instead of real pre-emptive time-slice multi-tasking as in Unix, Linux, and OS/2."

Windows NT (2K, XP, Vista, 7) do not use cooperative multi-tasking, their are fully preemptive. If you do not even know that you should not be commenting on OS design, really. The rest of your post is equally clueless along with the other metaphor junkie clueless windows bashers in this thread. This is to stop programs from crashing, not the OS...sigh.

"Looking at some of the data Russinovich discovered that 15 per cent of all user-mode crashes are caused by heap corruption [...]"

...should actually read:
"Looking at some of the data Russinovich discovered that 15 per cent of all user-mode crashes are caused by 3rd party programs made by shitty programmers that are completely clueless on how to manage memory [...]"

It's a cold hard fact. Remember kids, if you free a block of memory, make sure no pointer can point at it.

Sorry but Windows is used by the majority of people and all of the gripes you guys have don't make much difference. Most software works with Windows and not BSD or Linux. Linux devs prefer to not be everything to everybody. Microsoft is still around because they have built upon success. Sure it started by monopoly but the current state of computing is that apps not the OSes monopoly decide what OS you use. If someone needs Windows they need Windows.

DirectX is the API everyone uses because MS made it easier than everything else. End of story. Now it has more features implemented than OpenGL also. Has anyone tried to make hardware accelerated 3d games work on Linux. It is a ridiculous mess.

Linux has tons of work to do to even hope of competing with a Finished product like Windows7. Almost 100% of the devices available have complete fully functional drivers for Windows. Alot have drivers for Linux but tons have missing features like line/mic in on different audio devices.

Microsoft actually listened to someone criticising their OS and then did something about it?! ...Are you sure this isnt a hoax!? Wow, something must have changed at Redmond.

So they cut all the pointless processes, OK 'bout time, they shouldnt be running at all if they are not being used, its been a mess for ages. Also this must reduce start up burden. Dont start me on background tasks and fragmentation and the other pools of treacle which slow down my games machine.

I agree with Jasons friend the API is a major obstacle to free and fair competition among OS.

Your friends were probably talking about OpenGL. If gamers were not tied to DirectX or if DirectX was open source so that other operating systems could use it then there would be less of a need for Windows for many users. At one time OpenGL and DirectX competed but Microsoft won by throwing money at developers and it won (and apparently OpenGL was difficult to program for at the time). Id software still allows you to use OpenGL in their games because their tech lead (Carmack) has dignity. Hopefully some day virtualization will reach a point where we can just run Winblows inside of Linux so that we can game and use Linux for everything else.

Someone I trust said that if game-writers would standardize their API, there would be almost no reason for average users to use Windows at all.

From the way I remember him explaining it, it basically means that you write your code so that a translation tool has an easier time figuring out what is says so that it can "explain" it to the underlying operating system. So PRINT would need to mean print, and not delete or do a backflip, no matter where it can from.

This is just another kludge to keep a badly designed OS limping along, on crutches with an oxygen bottle. Also it sounds like these improved services will be using a lot more CPU overhead. Fast is an adjective that doesn't describe windows.

I also like what Lars said about patching a rotten ship, but its more like patching a ship made from bamboo and mosquito netting.

Patching holes in a rotten ship.

is that Windows doesn't exactly have full control of processes, because somewhere still in it is the "cooperative" multi-tasking scheme (that they borrowed from Apple), instead of real pre-emptive time-slice multi-tasking as in Unix, Linux, and OS/2.

Cnet article meanders on about a new model for polling attached devices (example, a Blacktooth). I don't see how the new scheme saves any processor time over having its own driver. But in any case, note that it's a *NEW* model, not yet implemented.

Anyway, the new scheme allegedly catches heap corruption in progress, but then seems to check whether it's an "honest" mistake rather than simply shutting down the process and reclaiming all resources. Guess we'll eventually see how well that works. Probably just another short-term "fix" that works only because it's *NEW* and its own flaws haven't yet been found.