In a post, Stéphane Rodriguez enumerates a series of points on why he asserts that OOXML is defective by design. Naturally, I have to agree with it (or as some MS people would say, I am biased that way), but in fairness to MS, MS is a big organization that has lost it’s focus and continues to think that it can do anything it pleases, no matter how defective.
Stephane has some incorrect ideas when it comes to how WOW64 (32-bit applications on 64-bit windows) works. It does not emulate the code and slowdowns of the pointer marshalling steps needed to call into the kernel are lost in the general noise of a benchmark comparision (they’re small relative to the general overhead of a syscall).
Stephane’s general point about Excel and 64-bit computing is also fairly wrong-headed. If you’re processing enough data that you need more than 1 GB of address space, then Excel is simply not the proper tool for your job. Excel has a certain target problem domain and large scale (multi-GB) data processing is not within it. Of course, someone could write a 64-bit program that could distill data into a form more suitable for excel analysis, and OOXML provides a workable way to even create the necessary excel sheet on some compute node running 64-bit Linux.
But all of the limitations of Excel aside, OOXML is a file format and has nothing to do with 64-bit computing. The performance or non-performance of VBA, Excel, or Office 2007 on 64-bit hardware has little to do with the OOXML format itself.
Re: 64 bit?
Thanks, nksingh (posting from Seattle). I agree that 32 and 64 bit issues are tangential and largely unrelated to ooxml. And, since I don’t use windows and haven’t since 1998, some of the reasons cited by Stéphane might be valid – though I can’t test (nor really care to).
Nonetheless, it still remains, ooxml is really not worth the effort.