Slashdot Mirror

The thing is, the changes required in Linux world to be compatible with new versions of key libraries are generally minor, well-documented, reasonable, and relatively quick to implement. In Windows world, that isn't the case, because Windows development is a mess. That is mostly Microsoft's fault. There isn't any good way out of this situation for them now, but they could have seen this coming a decade ago, and they chose to ignore it in the interests of making more profits earlier. Now, having made their bed, they are forced to lie in it.

Speaking as a Win32 and a Linux developer, this is generally not true. Usually the stupid problems that apps make are extremely minor; its just as easy to misuse Win32 as it is to misuse GTK+. The difference is that in the OSS world, the apps that one depends on are usually open source, whereas in the Windows world, the equivalent apps are closed source.

In some ways, its worse in the OSS world. When Microsoft creates an API, you can be effectively guaranteed that it will live forever if you don't misuse the API. And if your application is popular enough, you can get away with abusing the Win32 API (sometimes in extremely gross ways), because Raymond Chen is watching out for you. If I create a Linux app, can I be guaranteed that it will always run on every subsequent version of Red Hat without modification? Its arguable that isn't important for either Red Hat or the OSS community. But the lesson that Microsoft has learned says otherwise.

The thing is, the changes required in Linux world to be compatible with new versions of key libraries are generally minor, well-documented, reasonable, and relatively quick to implement. In Windows world, that isn't the case, because Windows development is a mess. That is mostly Microsoft's fault. There isn't any good way out of this situation for them now, but they could have seen this coming a decade ago, and they chose to ignore it in the interests of making more profits earlier. Now, having made their bed, they are forced to lie in it.

Speaking as a Win32 and a Linux developer, this is generally not true. Usually the stupid problems that apps make are extremely minor; its just as easy to misuse Win32 as it is to misuse GTK+. The difference is that in the OSS world, the apps that one depends on are usually open source, whereas in the Windows world, the equivalent apps are closed source.

In some ways, its worse in the OSS world. When Microsoft creates an API, you can be effectively guaranteed that it will live forever if you don't misuse the API. And if your application is popular enough, you can get away with abusing the Win32 API (sometimes in extremely gross ways), because Raymond Chen is watching out for you. If I create a Linux app, can I be guaranteed that it will always run on every subsequent version of Red Hat without modification? Its arguable that isn't important for either Red Hat or the OSS community. But the lesson that Microsoft has learned says otherwise.

• When Programs Grovel Into Undocumented Structures

• Why not just block the apps that rely on undocumented behavior?

• When Programs Grovel Into Undocumented Structures

• Why not just block the apps that rely on undocumented behavior?

• When Programs Grovel Into Undocumented Structures

• Why not just block the apps that rely on undocumented behavior?

As far as Outlook killers are concerned, Mozilla has been an Outlook killer for a very long time. Even with something as lame as courier Mozilla can easily work over 12G+ IMAP mail folders. Outlook (prior to 2003) caused massive corruption crashes and loss on anything above 2G (after the local cache exceeded 1G).

When people talk about "Outlook killers" they're not thinking about e-mail -- Outlook is universally recognized to be a crappy e-mail client (even by Microsoft's own developers). What they're thinking of instead is the groupware component -- shared calendars, meeting scheduling, task tracking, and so on.

As you note, there are tons of FOSS projects out there that convincingly work better as e-mail clients, but there has never been anything that comes close to it as a groupware client, and that functionality is what ties lots of businesses to Exchange/Outlook.

Unkillable processes usually mean you have badly written driver loaded that won't allow IRPs to be cancelled -

http://blogs.msdn.com/oldnewthing/archive/2004/07/ 23/192531.aspx

Get rid of any non Microsoft drivers, and the machine will usually work much better.

While perhaps producing some rather amusing results, this is a unfortunate but unavoidable consequence of Notepad having to support a variety of encodings of text files.

It's not really news though, and I doubt Hugh Thompson deserves any credit, Raymond Chen explained why things behave like this back in 2004.

Don't take my word for it read this account from a MACBU guy who worked on Word 6.0. It sucked.

http://blogs.msdn.com/rick_schaut/archive/2004/02/ 26/80193.aspx

Including this about Word 6.0 for Mac

"Starting from the Win Word 2.0 code base presented a couple of technical problems for those of us on the Mac side. The first was that it was written to the Windows APIs. Solving this problem isn't simply a matter of writing a layer that emulates the Windows APIs on the Mac."

The API's my friend - were Windows ones.

I say lies? I need education you say? I think not.

OMFG Pwned! Emphatically even.

And yes I do all my 300 page technical proposals in TextEdit too. Everyone does. I'm surprised they sell any Mac version of Office at all with TextEdit around. In fact I find stickies does most documents just fine without the bloatware of Textedit required.

That was our YouTube. And we liked it.

It looks like Microsoft has tried to make their tags very compact for some reason, perhaps in a mistaken effort to reduce file size. That's foolish since any XML-based format is going to result in large file sizes unless compressed, and if you're compressing anyway, more verbose and hence more self-explanatory tag names don't cost anything[*]. Personally, I find the OpenDoc version to be much clearer. I also think it's much better to apply style attributes to text spans, rather than to define tags that implement specific stylistic effects (bold, italic, etc.).

Brian Jones, a program manager on Office, has a post on this: Does tag size matter?. He echoes your statement in that it doesn't make much of a difference in document size due to compression, but claims that there's a large difference in parsing and compression/decompression time:

With the latest SpreadsheetML design, we've seen that the XML parsing alone (not including our parsing numbers, refs, formulas) can often range from 10-40% of the entire file load. That's just the time it takes to read each tag and each attribute.

Given that, I think it's sensible to reduce element and attribute names in order to produce better load/save performance.

You mean like these legacy tags that only OpenOffice can implement? (yeah, I know it's a Microsoft site, but the only other reference I was able to find was this /. post).

According to Microsoft, the only way those legacy tags will ever be found is if they came from a document that was created by an old version of Office. So it should be really easy to verify if current versions of office ever produce those "legacy" tags.

Bob was a flop, and one I commonly mock. However I promise you, that the concept will be revisited and better marketed the second time around. Honestly, I imagine that Second Life will become, or inspire the next generation of Bob, allowing us all to make virtual spaces, which in turn will link to applications and activities within this virtual world.

The concept of Bob was definitely a flop, but the technology behind it was well ahead of its time (well, for PCs, anyway). The UI was rendered completely using resolution-independent vectors which, while NeXT was doing this for years before Bob, is really something that has only become truly practical in the latest generation of operating systems (OS X and Vista) that can offload the cost to advanced GPUs.

Also, as much as people hate Clippy (and I'm happy the Office Assistant is finally, truly dead with Office 12), Microsoft got a lot of mileage out of that portion of Bob. It also introduced the concept of different users to a market sector that was still all about single-user computing (yes, the Bob profiles were superficial and ran on top of the single-user Win3.x, but at the time I would suspect the average home user had never heard of or used NT or a multi-user *nix). Given the configurability of spaces in Bob, I suspect today's Myspace crowd would've loved it :).

If you've never tried Bob, it runs quite well in Virtual PC (I'm sure you can easily find a copy of Bob and Win3.x or Win95 out there on the interwebs ...). Apparently it's also still fully functional on XP. You should try it, if only to see first-hand why it sucked so much.

And here's a video interview of the guys who admit to be responsible.

The guy will be missed at Microsoft, that's for sure... I hope all that brand new kernel transaction stuff already works perfectly in Vista.

Jim Gray - A talk with THE SQL Guru and Architect
http://channel9.msdn.com/ShowPost.aspx?PostID=4989 1

Jim Gray - Part II of talking about Database Design
http://channel9.msdn.com/ShowPost.aspx?PostID=5042 8

Conversation with scientist, engineer and database legend Jim Gray
http://channel9.msdn.com/ShowPost.aspx?PostID=1681 81

The guy will be missed at Microsoft, that's for sure... I hope all that brand new kernel transaction stuff already works perfectly in Vista.

Jim Gray - A talk with THE SQL Guru and Architect
http://channel9.msdn.com/ShowPost.aspx?PostID=4989 1

Jim Gray - Part II of talking about Database Design
http://channel9.msdn.com/ShowPost.aspx?PostID=5042 8

Conversation with scientist, engineer and database legend Jim Gray
http://channel9.msdn.com/ShowPost.aspx?PostID=1681 81

The guy will be missed at Microsoft, that's for sure... I hope all that brand new kernel transaction stuff already works perfectly in Vista.

Jim Gray - A talk with THE SQL Guru and Architect
http://channel9.msdn.com/ShowPost.aspx?PostID=4989 1

Jim Gray - Part II of talking about Database Design
http://channel9.msdn.com/ShowPost.aspx?PostID=5042 8

Conversation with scientist, engineer and database legend Jim Gray
http://channel9.msdn.com/ShowPost.aspx?PostID=1681 81

Actually I think that programmers are more likely to go off the deep end over the trivial. Perhaps it has something to do with the obsessiveness that's generally more prevalent in geek communities. I point you to what is one of the lamest provocations for a death threat: breaking the XCOPY command http://blogs.msdn.com/oldnewthing/archive/2004/06/ 03/147583.aspx.

God, when will people stop reciting this absolute rubbish as if it were true?

Lotus 1-2-3 was one of the main reasons people were buying MS-DOS based computers. Lotus was _the_ killer app for the PC back in the day. A more accurate quote would rather be: 'DOS aint done until Lotus 1-2-3 runs 100%'. Microsoft developers worked closely with Lotus developers to get incompatibilities and bugs fixed.

Please read this link: http://www.proudlyserving.com/archives/2005/08/dos _aint_done_t.html

And for a more detailed explaination of the AARD code, you can read these links:

http://blogs.msdn.com/larryosterman/archive/2004/0 8/12/213681.aspx
http://blogs.msdn.com/larryosterman/archive/2004/0 8/13/214338.aspx

God, when will people stop reciting this absolute rubbish as if it were true?

Lotus 1-2-3 was one of the main reasons people were buying MS-DOS based computers. Lotus was _the_ killer app for the PC back in the day. A more accurate quote would rather be: 'DOS aint done until Lotus 1-2-3 runs 100%'. Microsoft developers worked closely with Lotus developers to get incompatibilities and bugs fixed.

Please read this link: http://www.proudlyserving.com/archives/2005/08/dos _aint_done_t.html

And for a more detailed explaination of the AARD code, you can read these links:

http://blogs.msdn.com/larryosterman/archive/2004/0 8/12/213681.aspx
http://blogs.msdn.com/larryosterman/archive/2004/0 8/13/214338.aspx

Perhaps they had forgotten that the original purpose of Ctrl-Alt-Del was to trigger soft reboots on the IBM PCs and that the combination was selected precisely because it was IMPOSSIBLE to press all three keys with one hand and thereby trigger the reboot accidentally.

Incorrect, XP can only manage 3 GiB of RAM. You can install 4 GiB, but you'll have one unused.

What do you mean by 'going through the dymanic linker'? No offense, but that sounds like technobabble. Calls into a DLL just need an extra level of indirection - they are a CALL [func] rather than a CALL func, but there's no 'dynamic linker' involved.

But from the page I quoted
http://msdn2.microsoft.com/en-us/library/ms683614. aspx
"This function is implemented as an inline function using a compiler intrinsic where possible. For more information, see the section on Compiler Intrinsics in the Visual Studio documentation."

And it turns out the compiler does indeed knows how to turn this into a LOCK INC instruction
http://msdn2.microsoft.com/en-us/library/2ddez55b( VS.71).aspx

So even the normal call [func] rather than call func overhead you'd get from a DLL call doesn't apply in this case, it's ends up being as good as you could do with inline assembly.

The default Vista configuration works great and is quite reasonable for the average non-government, non-corporate user. It makes quite reasonable tradeoffs between usability and security. XP and earlier versions of Windows definitely had some things enabled that shouldn't have been. Vista is much better about that.

The default Vista configuration does not work so great in a corporate environment. One size does NOT fit all. Because one size does not fit all, Microsoft decided to make the default work well for the user who installs Vista in isolation (home, home office, or non-domain business user). If you install into a domain, the defaults might not work so well, but you're likely to have domain group policies to fix the defaults automatically.

Microsoft has distributed some guidelines for how Vista should be set up in various situations, along with group policy templates and some tools to help administrators automatically reconfigure all machines on the domain to comply with the policy. So far, administrators seem to be happy with this arrangement.

Here is some relevant Microsoft-sponsored Kool-Aid (beware - if you watch it, you might be brainwashed!): http://channel9.msdn.com/Showpost.aspx?postid=2831 91

How about open sourcing the core product too?
We've been asked this for years. That's not going to happen. The main reason is that there is too much intellectual property in the VFP core codebase.

Hilf is the "dirty little secret" man?

All you have to do is examine that video critically. False premises. Characterization. Posturing. Strawmen. False dichotomies. Flattery. It goes on and on and on.

It's a "dirty little secret", according to him, that a lot of F/OSS runs on more Window machines than Linux machines.

It's a "dirty little secret", according to him, that a lot of F/OSS projects are abandoned playthings.

It's a "dirty little secret", according to him, that the testing effort that goes into those abandoned playthings doesn't match what goes into Microsoft Windows.

On, and on, and on.

Think about those assertions. Strip the characterization. Consider the assertions. Now look at the characterization again.

Anyone who objects to the /. estimation of Microsoft's character should examine that video critically. Before watching it, maybe spend some time with "On Sophistical Refutations". I can't make myself watch it again. I can feel my revulsion, physically.

This has actually been discussed to some extent for years. One method is to only allow domains to be registered or displayed in a single language character set, such that a domain name can use latin characters or greek characters, but not both. This can be enforced at registration or when displayed in the browser (the browser can highlight improper URLs). This does not prevent attacks where the entire spelling of the domain is available in an alternate character set. One solution is for the browser to somehow tell the user what language a URL is written in.

Here is a detailed description of how IE handles this, and also a w3c page discussing general techniques and different browsers. An interesting note is the possible use of the fraction slash to add fake urls to a domain name. Of course, at the end of the day, standard phishing protection applies to domains which slip through the net.

Most people do not understand that the fast track process is only a way of accelerating the process, it is not a mechanism of rubber stamping the standard, there are still six months of work ahead before the actual voting can begin.

Details about how this work can be found in Brian Jones' blog:

http://blogs.msdn.com/brian_jones/archive/2007/01/ 29/explanation-of-the-iso-fast-track-process.aspx

Miguel.

The "M$ wag" where you posted your brilliant "bubba" flamebait? Which the guy actually took the time to answer in good faith? Is that it? Feels good insulting people on the internets, doesn't it? Calling them names behind their backs? For someone who complains so much about how "insulting" people who don't agree with you are, you sure know how to "dish it out" like a big tough dude. Way to go.

Plz also note the number of features *removed* from Groove 3.x! E.g., I heavily used the 'take Sharepoint sites offline' feature to take documentation with me while working offline but it has vanished from the product. http://blogs.msdn.com/marco/archive/2005/12/02/499 513.aspx will give you more information.

I personally contacted our Microsoft representative and explained him very carefully why I think he sucks/they suck. Taking over Groove and consequently destroying it while integrating it with Office 2007 made me switch to OpenOffice and Groove 3.x. I won't switch back.

Hopefully someone will release a Groove 3.x keygen within the next few days.

In a phrase, the niche is professional coders, rather than hack-a-day cowboys.

Assertions, whether invariants, preconditions or postconditions, can be viewed as extensions to the type system [1]. Since they are expressions of a boolean type and don't modify state (at least, no sane ones would mutate state), they're very easily analysed.

Combine that with a runtime like .NET or the JVM. Compilers and analysers can use such contracts to perform extra typechecking of e.g. arguments to methods, where the methods have preconditions. "Runtime cost" doesn't exist if the runtime has support, especially where verification also exists. Consider the old conundrum: do you check your parameters, or do you expect your caller to check the arguments before they're passed? What if the parameters being wrong leads to a subtle error that manifests later rather than a dramatic failure? With properly stated contracts, these checks can be inserted at the lowest level and automatically propagated higher statically by the compiler or dynamically by the runtime as necessary.

The niche that DbC is supposed to fill is formalising what is already recognised good practice - stating your assumptions while writing your code. If you have much experience as a programmer, you'll know that it's useful to use assert, ASSERT, or some other feature of your environment at choice places where you make certain assumptions that you think can't be broken. And if you've read The Pragmatic Programmer, you'll know why you'll want to leave those assertions in the final release.

Most popular languages, such as C#, Java, C++ etc., capture very little programmer intent in their type systems. There's a lot more potential there - preconditions and postconditions can e.g. state that a variable will be in a certain range dependent on the values of other variables, and then automatically detect range mismatches with e.g. loop invariants. Basically, assertions are really useful extensions to the type system.

[1] For example, consider that a 'requires x != null' constraint and a notional non-nullable reference type from C# or Java, analogous to 'MyType!' in C-w (C Omega):
http://blogs.msdn.com/cyrusn/archive/2004/06/03/14 7778.aspx

Before slamming the format, please read more about it. Regardless of what you think about Microsoft, I think it has great potential. Some highlights:

• High dynamic range
• Embedded ICC color profile
• Lossy and lossless compression
• Ability to decode part of the image without decoding the whole thing (see below)
• Ability to crop, downsample (i.e. thumbnails), and rotate without decoding the whole image
• Very efficient encoding and decoding, useful not only on the desktop, but also specifically designed for fast encoding and decoding on devices like digital cameras
• High quality and small file size. (Around half the file size as JPEG (or) twice the quality. Claimed to be similar to JPEG 2000 without the additional performance and memory impact.)
• TIFF-like container
• The licence for the format *is* supposedly compatible with the GPL; only the source code for the reference implementation is not.

Also, take a look at http://labs.live.com/photosynth and http://blogs.msdn.com/billcrow. To quote one thing from his blog:

Because this is a compressed domain operation, the server never had to decode or re-encode the compressed data to create this low resolution "thumbnail" of the larger, high resolution image. The only work involved was to copy a portion of the compressed data and wrap it up in a container to make a new HD Photo file. This very small HD Photo file is sent across the network connection, and then decoded by the HD Photo codec on the client to provide the low resolution view required for the particular display.

When zooming in to the fine details of a high resolution image, the HD Photo codec is able to very quickly extract an arbitrary rectangular region by accessing only the image tiles that overlap that region. Like the mipmaps described above, this is accomplished by simply extracting a small portion of the compressed data and building a new (and very small) HD Photo file to be sent across the network. The client receives and decodes this small file, combining it with the other segments required to display the required view.

IMHO this seems like a well-balanced format that has most of the advantages of a cornucopia of different formats (JPEG, JPEG 2000, RAW, TIFF) without the corresponding disadvantages. If it's not successful, I at least hope something equivalent is!

For more information on 'HD Photo' (damn I hate that name), check the blog at:
http://blogs.msdn.com/billcrow/

Hasn't been updated in a good while, but contains plenty of nice information. The various bitdepth storages alone make it an 'interesting' format if nothing else - though I'm sticking with EXR.. just a shame that doesn't offer lossy compression much yet - but then.. that's not its' purpose.

From the WGA Blog

• Source ID (which product is requesting an update) - necessary to get the right patches
• Event Code - Not sure what sort of events this is tracking, curious, but not necessarily evil
• Version - I assume this means version of the updater, but could mean version of the base software, either way see #1
• Hash of the event - good security check
• Custom Data - completely unexplained, this is what worries me the most in the list
• Return Code - ok from a usability standpoint (most websites track when users leave, so I put this in the same class as that)
• Part of a domain? - no reason for this to be sent, as far as I can see
• Partial binary product key - piracy reasons? Can't think of any other good reason for this
• WPA hash - also unexplained, but probably related to the above
• OS version - see #1
• User locale ID (langauge) - reasonable if they are presenting nationalized dialogs, removes a prompt from the user
• System locale ID (computer default language) - don't see much of a reason for this except as a backup for the first, odd
• Diagnostic code - reasonable for debugging
• Client Id - i.e. GUID - why do they get this if they aren't using it for user tracking
• HD volume serial - no reason for this, except user identification
• Computer security hash - see above

"In the Privacy Statement of Windows Update Microsoft grants itself fairly far-reaching rights... By way of justifying Microsoft's approach, alexkoc writes that the EULA, likewise presented by the WGA installer, also covered the relaying of such information."

So I guess it might be a bit sneaky, but it has all been covered by WGA disclosures.

An example of the XML returned when a user cancels an installation is available here, "just to allay any fears that Microsoft is using any personal information".

So ya, I don't think this is a huge deal, nor particularly unexpected.

By learning at what point in the install process some users decide to say "Fuck this, I didn't sign up for this!", we can put more effort into the right places in the installation wizard. Remember our goal with the wizard is to obfuscate and misdirect so customers will either not know how we're spying on them, or for those who figure it out, at least they won't be able to sue us over it. We heard from customers that they wanted to know what else were doing behind their backs so we created the install wizard to provide us with plausible deniability. Knowing this kind of information about the install wizard installations is critical for us to continue to propagate the viral meme of WGA and other notions, like software as a service, and ultimately the notion of an operating system as a subscription-based service, like we're doing with the Windows Vista self-destruct sequence. If we are not hitting that mark, we can use this method to slowly increase the amount of DRM we've crammed up your ass until you look like the Goatse Guy, and if we do it slowly enough, you'll not only pay us, you'll thank us for the privilege!.

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

There is plenty of good information on motivation, etc. here: http://blogs.msdn.com/brian_jones/default.aspx

A great summary of arguments can be in this post: http://blogs.msdn.com/brian_jones/archive/2006/09/ 21/interoperability-of-the-office-open-xml-formats .aspx

Reguarding your particular question, that post states:

"If you look at my blog, I probably spend less than 5% of my time discussing ODF. The only reason I talk about it is that people have asked me why we didn't use it as our default format. A simple "it wouldn't work" answer obviously isn't good enough, so I had to show specific examples to help explain my view."

In this post: http://blogs.msdn.com/brian_jones/archive/2006/07/ 27/679703.aspx
Brian lists a whole bunch of examples of why it "wouldn't work" with references to previous posts with more details:

"
The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.
"

This will do squat for putting any nails in anything.

Microsoft wanted this. Infact, Microsoft helped Novel do this: http://www.novell.com/ctoblog/?p=43
And the Microsoft Open XML developers were more than helpful to advertise this: http://blogs.msdn.com/brian_jones/archive/2007/03/ 02/openoffice-support-for-the-openxml-formats.aspx

This is a GOOD THING for everyone. OpenOffice.org users get interopability with MS Office. MS Office meets many government required interopability and open XML format requirements. Win-win.

Let's keep the absurd commentary out of the summary and in the modded down comments, please?

If we ever were really in a war, it's now over, and both sides are winners.

In fact, some methods run on clusters already. It costs extra licenses, though.

You left out large parts of section 4, btw.

Here they are:
(4) Controlled by an open industry organization with a well-defined inclusive process for evolution of the standard
        (b) Beginning on or after January 1, 2008, state agencies shall start to become equipped to accept all documents in an open, XML-based file format for office applications, and shall not adopt a file format used by only one entity.
        (c) The department shall develop guidelines for state agencies to follow in determining whether existing electronic documents need to be converted to an open, XML-based file format. The department shall consider all of the following:
                (1) The cost of converting electronic documents.
                (2) The need for the documents to be publicly accessible.
                (3) The expected storage life of the documents.

Does this mean that CA can no longer publish in PDF? That's not XML based, as far as I know.

What does that do to the CA courts, which currently publish exclusively in PDF format (afaik - every decision I've ever read was published in PDF).

I'd also love to know the results of 4.c.1. I suspect that it's significant (especially given this comment on a Microsoft blog).

I believe it is. I remember there was a hack http://weblogs.asp.net/dfindley/archive/2006/06/20 /Set-hardware-clock-to-UTC-on-Windows-_2800_or-how -to-make-the-clock-work-on-a-Mac-Book-Pro_2900_.as px to use UTC, but it didn't work quite right http://blogs.msdn.com/oldnewthing/archive/2004/09/ 02/224672.aspx. (Sorry about the long links, couldn't figure out how to do it properly.)

http://msdn.com/xna