So then place the blame squarely on the "responsible" Google engineer for putting your systems at risk! This bug has existed in Windows XP for NINE YEARS and presumably was never exploited in all that time, but now, all of a sudden some guy decides that it's vitally important to announce to the world, just a few days after submitting the bug report, that HEY EVERYONE, THERE IS AN EXPLOIT, AND HERE IS HOW YOU USE IT.

Had he kept his mouth shut, your systems would be safer.

Excuse me, but.... huh?

I'm going to assume you haven't actually researched this (i.e. "I went to the source and got the full story for myself" research and not just "I read a Slashdot comment once and got angry" research) and are just running at the mouth because you're angry, not because you're right.

Which you aren't.

Here, let me introduce you to a guy. His name is Tinic Uro, and he's one of the people who actually programs Flash. He's an engineer like us, not a marketing droid (or worse, an executive).

Here are three blog entries you should fully familiarise yourself with before making any further comment on what Adobe is doing in terms of improving Flash on OS X.

Flash 10.1 and Core Animation:
http://blog.kaourantin.net/?p=81
(TL;DR: yes, Flash 10.1 uses Core Animation to accelerate overall Flash graphics performance -- not video specifically -- but you need OS X Snow Leopard and a super-new version of Safari)

Flash 10.1 and timing:
http://blog.kaourantin.net/?p=82
i>(TL;DR: They rebuilt the timer model in Flash 10.1 to use significantly less memory, however Safari on OS X is less flexible than other browsers when it comes to firing timer events, thus making video playback less smooth)

H.264 hardware acceleration in OS X:
http://blog.kaourantin.net/?p=89
(TL;DR: Adobe has released a post-10.1 beta version of Flash that supports full and proper video H.264 acceleration on Mac OS X, with the caveat that you have to have 10.6.3 and certain current graphics chips)

The real story is this:

Apple has been well behind Microsoft Windows when it comes to providing third parties with APIs to do hardware acceleration, and to do high-performing timer operations that are necessary to run browser plugins smoothly. I know the Slashdotterie will get all worked up over that assertion, but speaking as someone who's actually written browser plugin code, you'll just have to trust me on this. IE has always had the best timer support, which is one reason why video- or timeline-heavy plugins have always performed better than other platforms. As of OS X 10.6.3 and Safari 5, Apple has pretty much caught up.

- Despite the headline-grabbing statements from Steve Jobs and other executive-types, there are actual hard-working developers at Apple and Adobe who actually collaborated to define a good API for high-performance video access for browser plugins. If Apple wasn't so deliriously secretive, you'd hear a lot more about it. Trouble is.... the only people who are allowed to blog at Apple are people who'll make the company look good and forward-thinking -- like the Webkit team.

The problem with performance isn't 100% Adobe's fault. It can't be. Adobe's engineers aren't stupid -- if there had been an easy solution to good plugin video performance on the Mac all this time, they would've fixed it years ago. Why spend several years intentionally using a bad approach?

Lastly.... despite what the article summary says here on Slashdot, overall Flash performance is quite a bit better in 10.1, especially on OS X. Do your own benchmarking; you'll see for yourself. It's still not as good as it should be, but it's a massive step forward. They know HTML5 is coming... they know they have to make Flash as good as or better than HTML5 or they'll be toast by 2020. They know all this.

Download the free Windows SDK 7.1, and you can compile 64-bit native Windows binaries all day.

This isn't correct. MS Bob was released in 1995; Bill and Melinda met in 1987. She'd just joined Microsoft and was a programmer -- and by all accounts, a pretty good one at that. Plus, she's pretty hot, and she was 23 that year. Wouldn't you scoop up a girl like that, especially back then when women were still really rare in the field?

The Microsoft Windows equivalent of Grand Central Dispatch is called User-Mode Scheduling, and is included with Windows 7 and Windows Server 2008 R2.

http://msdn.microsoft.com/en-us/library/dd627187(VS.85).aspx

Microsoft has also released application libraries on top of UMS to make it easier to use in certain languages. C++, for example, has the Concurrency Runtime. More on that here:

http://msdn.microsoft.com/en-us/library/dd504870(VS.100).aspx

GDC and UMS both let an application developer accomplish pretty much the same thing: move all into a single process with enough pre-assigned threads to cover all the cores on a system, and then work is queued up and performed on those threads. The benefit of here is that GCD and UMS applications don't have to context-switch into and out of the kernel a bazillion times in order to do a set of parallelizable tasks.

GDR and UMS+CCR both whittle down the developer's code-writing commitment to a few lines. It's pretty amazing stuff.

BUT....

Neither of these technologies really addresses the underlying system-wide problem: adding more CPU cores to a system doesn't increase performance on a linear scale like increasing the speed of the CPU. Every time you add a core, more and more time gets spent doing resource management instead of actual work. OS kernels invariably have locks on important resources (memory tables, for example), and while these things don't matter at all on a 2 or 4 core system, they're going to be a huge bottleneck on a 200-core system. No general-purpose operating system on the market today... not Windows, not OS X, not even Linux... can provide a liner or near-linear performance improvement as the number of cores increase beyond 16 or so. Not as long as there is any kind of shared resource between those cores.

By the way.... Dave Probert, who is the Microsoft engineer the Slashdot article is discussing, explained UMS in this Channel 9 video over a year ago:

http://channel9.msdn.com/shows/Going+Deep/Dave-Probert-Inside-Windows-7-User-Mode-Scheduler-UMS/

Uhhhh, no....

Firefox 3.5 has significantly updated rendering and Javascript engines. HTML5 tags are supported, native Theora and Vorbis decoding is included, ICC profiles, SVG transformations, CSS media support, etc.etc. It's worthy of the version number bump.

Meanwhile, IE 6 SP1 and SP2 were primarily security improvements and UI changes... there are no rendering engine changes.

You can think of IE6 service packs as being similar to Firefox 3.0.x and 3.5.x point releases, where they'll do various bits of work to make the browser more stable and more secure, but not really fundamentally mess with how it interprets pages.

NetApplications tracks browser versions so we can see what rendering engines are available to us as developers. That's why they count FF 3.0 and 3.5 separately, and they why count all releases of IE6 as the same.

Oh come on. You're a professional (right?), you should know better than to say this kind of crap. You know what your problem is? You think NAT is a security mechanism -- it's not. Just because we have spent the last ten-plus years having the Firewall also perform network address translation, doesn't mean the two roles have anything to do with eachother -- they don't. NAT is a workaround for the problem of limited IP address spaces; it says so right in the freakin' abstract of the original NAT RFC (1631), which was published in 1994! Don't assign it responsibilities it wasn't designed to have!

IPv6 can (and should) be firewalled just as IPv4 can (and should). It's always a good idea to have a device between your Internet connection(s) and your in-house systems that makes decisions about whether or not packets going to & from certain IP addresses+ports should be allowed through. But, seriously, who cares if the source or destination address is IPv4 or IPv6?

But that's not what they're doing! There is no remote code execution vulnerability on Windows 2000, XP, or Server 2003. Only Vista and Server 2008 are susceptible to remote code execution. This is a Denial of Service vulnerability on NT 5.x systems, and you have to have the firewall disabled (and, indeed, no stateful hardware firewall at all) in order to be vulnerable.

The details are here:

http://www.microsoft.com/technet/security/bulletin/ms09-048.mspx

It's fine to criticise Microsoft for not releasing a patch for XP, but let's at least get the facts about the vulnerability straight, first, yeah?

Ed Bott did a bunch of research on what the Windows 7 three application limit really means:

http://blogs.zdnet.com/Bott/?p=844

In short, he says that:
- Windows Explorer, Command Prompt, Task Manager, Control Panel applets, other Windows system tools don't count
- Many applications that run as system services and present themselves through the notification area (aka system tray) don't count (anti-virus, firewall, little utilities, etc) ...
- The version he tested doesn't exempt installers, but Microsoft said that they should be
- Internet Explorer is NOT exempt, but there is no limit on the number of tabs you can open
- If you don't like the three-app limit, there is a built-in way in Windows to upgrade to a higher edition that doesn't have the limitation. You don't have to reinstall Windows or lose your data or anything; it's just an online purchase and a change of product key, and the upgraded features are unlocked with a reboot

So it's not like you're screwed if your computer came with Starter and you need more. But if you don't need more, hey, you just saved some money....

shims just sound like a lame hack. using a shim means you've given up on elegance and respectability

Shims allow Microsoft to fix bugs in Windows without affecting applications. Changing how any API call works, even to fix something that is clearly wrong, can cause major problems, because there could very well be applications out there that rely on the broken behaviour.

I'll give you a practical example. In Windows 7, they fixed the CreateFileEx() API call, which is used to create and open files. Pretty much every application out there uses this API, so changing how it works would be about as dangerous as changing how a core CLI utility on Unix like "sed" or "grep" works and then rolling out the change to production systems around the world.

The bug in Vista (but has existed in Windows for quite some time) is that if you were you request exclusive read access on a file that you do not have full access to, Windows would silently change your lock on that file to "shared read" access. Which is, of course, not what you asked for. There are plenty of other cases in CreateFileEx() where the API call will fail if you ask it to do something your user account doesn't have permission to do. They fixed this in Windows 7, but this is obviously a case where fixing a bug in Windows will cause many applications to crash or not function properly.

In order to provide this bug fix, and therefore make Windows better, they've added in a new (optional) application compatibility manifest that new applications can use that says, "hey, I want the Windows 7 behaviour!", and this CreateFileEx() fix -- as well as a number of other bug fixes -- will be in place for your application. Microsoft is saying that they will also maintain that defined compatibility level through future versions of Windows, too, i.e. on Windows 8, you'll get the Windows 7 API behaviour.

Sure beats having to keep up with KDE's world-breaking changes every few years, don't you think?

There really is no other good way of going about this. An "elegant and respectable" solution would probably involve every software company, ever, fixing every bug in their software, ever, that prevents their application from being compatible with Windows 7. What do you suppose the chances of that happening are? You might as well be a seven-year-old girl asking for a live unicorn for your birthday... you just might have better luck! A lot of software that needs to run on Windows is in-house jobbies written years ago by people who'd just learned the difference between "If" and "While" BASIC statements. It would likely cost a lot of money to scour the whole code-base and fix it... and that's if they even still have the code and can find someone to do the work! (What if the contractor ran off with it and is holding it for random? I've got a friend who's dealing with that very issue right now!!)

Microsoft's solution to this problem is to give IT people the ability to analyze the software they have to run and to apply shims to make it work. Microsoft will even help companies with this, often for no cost at all.

Elegance is nice, but it can be prohibitively expensive. Shims are for the real world.