And in fact, for large classes of interesting applications, installer and installed size is overwhelmingly data, not code. Games are going to be 95%+ data (check out how small the actual app is sometimes; often less than 1% the size of the data files). Microsoft Office has far, far more space allocated to fonts, clip art, all those multilingual spelling dictionaries, and templates than the actual *.exe files.

And even the self-contained .exe files in the above examples will also include a ton of bitmapped images for the GUI and such. Sure, command-line apps are going to have a lot more code, but even they will have the help text, tables, and other stuff that could be stored once in a platform-independent internal data structure.

Having behavior driven largely by data, not good is a good thing, of course. Data is a whole lot easier to debug than code, and bugs in data are generally much less catastrophic assuming the code itself does good validation.

This test was only using a single socket system. Perf differences from XP are going to be greater on a NUMA multisocket systems like Barcelona or Nehalem. XP predates NUMA on the PC architecture, while Vista and Win 7 got a lot of tuning for it.

This can be a big help for video encoding and other highly multithreaded tasks.

With a sample size of 16, "one third" ISN'T statistically different from 50/50.

There's no news here. The HE AAC codec (called AAC+ in the Coding Technologies implementation, and now called Dolby Pulse after Dolby's acquisition) is a highly advanced spectral band replication codec, and can be pretty darn transparent down to around 48 Kbps. That there was about a 2:1 preference for the high bitrate Ogg in a highly nonscientific small sample size test like this is a yawner. http://en.wikipedia.org/wiki/HE_AAC

DirectShow is alive and well on Vista and Windows 7. There is a new media API called MediaFoundation, which is used by default in WMP for Win 7. It's quite different and improved in many ways over DirectShow, but can interoperate with existing DirectShow decoders.

Well, the members of the MPEG-LA patent pools hold pretty much all the known-critical patents for video compression, so that's actually a pretty good real-world protection.

I made a few samples using the latest versions of x264, VC-1, and Theora, testing both offline VBR and real-time CBR encoding.

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Theora%5E_1.1

Theora is defintely improved, but I see a lot of basis pattern throughout these samples. Theora would be well-served by a postprocessing filter. Theora's 1-pass CBR encoding definitely needs a LOT of tuning before it'd be viable for real-world content; I don't think we'll see it used effectively for live encoding this version.

Coming from the digital video world, I'm entirely opposed to standardizing on using GB instead of GiB in any context. Because lots of other industries, like telecommunications and digital media, have long used the correct ^10 numbers. Come to think of it, Apple was the last company to use KB/sec for compression bitrates, and even they dropped it as of QuickTime 6 back in 2003.

When you get provisioned bandwith, you're getting ^10 numbers. And when you compress video, you're using ^10 values (so, 20 Mbps is really 20,000,000 bits per second, not 20,971,520)

It's a big pain to have to always convert between the real values and the erroneous ^2 values when figuring out how much video we can put on a disc/drive.

It will be a horrible thing to have GB mean different things in different contexts and to have to know when to do or not do the conversions.

You won't get a FormatLikeWord95 tag if you're not using Word 95, of course :).

It's important for lots of users that they can maintain functional compatibility and bidirectional conversion with older Office documents, so that was a core design goal of the .???x formats.

You may not need that yourself, but a lot of people do, and the new formats give them that in a much more interoperable, searchable, and efficient XML-with-.zip structure.

It seems like 90% of the compliants about the new formats don't even acknowledge the design goal, which makes any discussion of how good it is pretty irrelevant.

A clean-room new office file format would have had much worse interoperability and hence much less adoption, for only aesthetic gains at best.

If OpenOffice doesn't have Normal/Draft, it's dead to me. I don't want to see page breaks when I'm still writing the darn text! That's bugged me about other tools for getting on 20 years now.

That killed Pages 1.0 for me as well.

Well, yes, of course you'd use PDF if you want to get the exact fonts and layout on the other end. .docx is a content creation format. It can work somewhat for that scenario, but it's not its whole reason for existence.

But nor are you going to write an article in Acrobat. Note that the Office apps now have an excellent "Save as PDF" mode that's much faster than Distiller.