Slashdot Mirror

Wow...so, did Vista and 7 get Unix style folders?!?! No more C: drive and the like?? Cool, I'll have to check that out!

Both yes and no.

You have been able to use slashes in file paths since DOS 1.0. All Win32 APIs that take filenames understand them. All GUI applications do, too (try navigating to e.g. C:/Users in Explorer and see what happens).

Command-line tools do as well, but the problem there is that leading "/" is also treated as an indicator to start a command-line option, and furthermore, as an option separator. So if you write dir /foo/bar, this will be parsed as argv[1]="/foo", argv[2]="/bar" to begin with, and then those will be treated as options (unrecognized, so you'll get an error) rather than paths. If you put quotes around it, however - e.g. dir "/foo/bar" - this will be properly interpreted as a path.

(As a side note, you can thank IBM for this whole mess; when DOS has got directories, it was supposed to use "/" for paths and "-" for options, as God and K&R intended.)

PowerShell disposes with all this, and uses "-" only for options, so it will never misinterpret a Unix-style path. Of course, it also understands "/" as a path separator (though will still show "\" for NTFS and registry in paths that it itself outputs). It also understands "~" as a shortcut for home directory, and expands variables with "$...", not DOS-style "%...%".

Disk letters are still there, but can be largely ignored if desired. You'll still need one for your root, but everything else can be mounted in directories underneath it, including any removable drives, USB sticks etc. At this point, you can also start omitting it in all paths you input, and always start them with "\" (or "/"), since the current drive will always be the only one in the system.

Not to be disagreeable but patches have already disabled one part of the software. That's how we became aware of this risk.

Was the disabled part of your software written strictly against specification, and not relying on any undocumented assumptions, or uncovered implementation details?

If it does, then there wasn't ever any guarantee that it will work. This furthermore applies to all development technologies, not just VB6. A .NET application directly accessing internal CLR structures, for example, will likely break on a major version update, and there is no recourse for this.

Now it's true that there are also breaking changes for code that used to be perfectly valid. But, again, this is true of all development technologies. There were quite a few valid Win32 apps written in VC++ that got broken on Vista, for example (though the majority of those broken were written improperly in the first place). Even .NET applications can and are affected. For example, this change broke things for quite a few people out there.

All that said, the track record of breaking API/contract changes on Windows is of the best for all development platforms of that size out there. It happens, but it doesn't happen anywhere as often as, say, if you target some modern Linux UI framework, and it never is of the same magnitude (e.g. no release of Windows, pretty much since 1.0, forced people to rewrite their code mostly from scratch to make it work; compare to Gtk 1.x -> 2.x, or Qt 2.x -> 3.x -> 4.x).

So far as I know, only Java is possibly comparable in that department, and even then there are conflicting reports on how true this is in practice rather than on paper. Since I don't develop software in Java full-time, I do not have enough experience to judge either way; Java language design not dealing with brittle base class problem satisfactorily might be part of the problem, but I don't know how often that is hit in practice.

There are reasons the progress bar dialogs don't show all the work being done. Reporting takes time. Would you rather have more information over having it complete quicker?

The issue there was that Microsoft app writers (like Microsoft Office) were able to use private APIs and nobody else was.

Except that according to people like Raymond Chen, the Office folks were just crappily reverse engineering those private APIs and doing things they weren't supposed to be doing by having done so.

From a a comment in this article posted by him:

The functions were exported only by ordinal. There was no documentation, there was no LIB file to link against, the function wasn't named; you had to reverse-engineer the LIB file and link with it. Surely that must've been a clue that what you were doing was the slightest bit dodgy. Office probably found those undocumented functions the same way you did. In the Windows division, we treat Microsoft applications the same as any other company's applications. In fact, earlier versions of the programs now known collectively as Office were such problems that -- I hope the Office folks' feelings aren't hurt by this -- we made up insulting names for them just to keep our sanity. The only one that comes to mind right now is "PowerPig". (I must point out that in the intervening years, the Office folks have done a fabulous job of getting their act together.)

Microsoft has the same problem. If you read The Old New Thing, you'll get a lot of stories over time about things that people start doing in Windows/DOS that weren't documented, that were private APIs, etc. But they had to keep them working because otherwise some really important program would break. Microsoft generally seems to try to keep that stuff working.

Apple is exercising control that Microsoft didn't have over Windows. Since Apple controls distribution, they can prevent people from doing these things, and save themselves hassle later.

Just because someone discovers that a specific microwave can also open their garage door doesn't mean that all new versions of that microwave should have to do that forever.

Apple (and Microsoft) never said "If you do this, it will work." Usually they say "DON'T do stuff unless we say it's OK, 'cause it will break."

Apple just has a chance to force the issue.

I think the number one reason for not going to HTML5 is MSIE. Microsoft has no intention of creating a fully standards compliant browser. If they did that, they would likely also need to make their web based applications standards compliant and that would end their lock-in for Windows on the desktop and server where web applications are concerned.

This simply hasn't been the case since IE7. IE8 is fully CSS2.1-compliant, which removes most of the pain of dealing with IE already. IE9 adds many CSS3 features and also has a far more compatible JavaScript implementation. Microsoft's explicit goal for IE9 is that developers should be able to use the same markup as much as possible. IE8 was an enormous improvement, and the IE9 previews look like they'll also be far better. The only problem is IE users who don't upgrade.

Plus, you can get a version of Visual Studio from Microsoft for free that will do everything you want. Plus, you definitely won't regret having VS as a debugging environment.

Have you seen this? Three months of zombie windows and counting:

http://blogs.msdn.com/b/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx

There's an interesting discussion at http://blogs.msdn.com/oldnewthing/archive/2007/12/24/6849530.aspx about the role DOS played in Win9x. It's sort of an interesting mix of bits.

From the horse's mouth. Read the first few paragraphs under 16-Bit Applications. The article is about Windows 95, but has a brief description of Windows 3.x cooperative multitasking.

Also, the terminology is well-known and long-standard in computer science. Of course, if you don't work (or have no degree) in the field, we shouldn't expect you to be aware of it. Hmmm, this paragraph could seem condescending - it's not intended that way at all.

- T

Well, good thing you werent condescending, because I don't think you can get more "from the horse's mouth" on this question than Microsofts Raymond Chen, which writes:

"Enhanced mode Windows allowed you to run multiple MS-DOS prompts that were pre-emptively multi-tasked"

http://blogs.msdn.com/oldnewthing/archive/2010/05/17/10013609.aspx

But in enhanced mode, Windows did use Virtual 8086 mode, and those instances could be pre-empted. That's the only way multitasked DOS boxes can work correctly anyway.

http://blogs.msdn.com/oldnewthing/archive/2010/05/17/10013609.aspx

No, it was the same on the real 3.x calculator, making it targets of jokes:
http://blogs.msdn.com/oldnewthing/archive/2004/05/25/141253.aspx

Unless you want to compile native 64-bit binaries. In that case, Visual Studio Express Edition won't be sufficient.

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

About your AD comment, it's been brought up, but AD isn't the be-all-end-all of security.

From:
http://blogs.msdn.com/developingfordynamicsgp/archive/2009/12/09/do-we-really-want-windows-authentication-for-microsoft-dynamics-gp.aspx

"One major drawback to switching authentication modes is audit trails. AX and SL have made the move from SQL auth to Windows Auth. In doing so, they destroyed the audit trail at the database level. All DB updates are made by one user making it a massive challenge to determine who made a change to financial data. Many of the AX and SL companies we work with get dinged for this in each audit."

Ok, What the FUCK. I was going to say this wasn't even a story and that the poster had no clue on .NET, then I read THIS:

http://blogs.msdn.com/developingfordynamicsgp/archive/2008/10/02/why-does-microsoft-dynamics-gp-encrypt-passwords.aspx

THIS is your argument? What version it is? All your talking about is application security.

Look, the poster isn't the greatest .NET programmer out there (Plenty of built in stuff for encryption in .NET), but come on. A two byte substitution cipher? All you have to do is put down a packet analyzer, have the application "retrieve" the system password and there you go. Its just kept in the freaking tables and I doubt businesses use ssl on their lan.

But that's not the biggest pet peve. WHY AREN'T YOU USING AD? You know, the 20+ years of authentication system that just works?

I sound angry because on one hand I like how you can program your own authentication provider in iss and start to warm up to Microsoft, but then I read something like this where you don't even bother to use the BUILT IN string encrypting in .NET.

I think that this article is a little misleading. The encryption that is being discussed here is well known to be weak, and is only used for the system password, it's not used for the integrity of the system at all.

The article links to a blog here, which talks about the encryption of the SQL login passwords, which is a completely different thing, which does not use a simple substitution cipher. A couple different locations that encryption is used are being confused here.

http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx

Right here buddy.

Honestly, what makes you think you can ask others for citations when you obviously didn't even try to provide your own (seeing as it was factually wrong).

Citation: http://blogs.msdn.com/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx

We’ve read some follow up discussion about support for more than the H.264 codec in IE9’s HTML5 video tag.

To be clear, users can install other codecs for use in Windows Media Player and Windows Media Center. For web browsers, developers can continue to offer plug-ins (using NPAPI or ActiveX; they are effectively equivalent in this scenario) so that webpages can play video using these codecs on Windows. For example, webpages will still be able to play VC-1 (Microsoft WMV) files in IE9. A key motivator for improving the codec support in Windows 7 was to reduce the need that end-users might have to download additional codecs. The security risks regarding downloadable codecs and associated malware are documented and significant. By building on H.264 for HTML5 video functionality, we provide a higher level of certainty regarding the security of this aspect of browsing and our web platform.

No, they didn't. They specifically said they would not. The relevant quote is:

http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx
"In its HTML5 support, IE9 will support playback of H.264 video only."

Now they say they'll support H.264, and VP8 if the codec is installed (http://blogs.msdn.com/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx). Since this post happened literally the same day that this became an option, it sounds like this contingency plan had been in place ahead of time.

http://blogs.msdn.com/ieinternals/archive/2009/06/17/CSSHistoryProbing.aspx is an article on the subject.

Essentially the vulnerability is a feature of the spec. Even without JavaScript or cookies, the CSS specification allows a web developer to specify that a particular icon/cursor/background-image should be shown for visited links. The exposure is that the client only downloads resources when they are needed to preserve bandwidth, and the server knows what has been requested from it, so I could put in then put somewhere in my css #google:visted { background: url("userwenttogoogle.png"); }

The problem is the only way to protect against the vulnerability is to remove features which are part of the spec (potentially breaking legitimate and standard compliant web pages), to download all resources (wasting lots of bandwidth), or putting the user in control (probably more annoying than useful as most users won't understand the dialog)

Live Workspace is an old thing, and is not the same as Office Web Apps / SkyDrive.

Now, I haven't found any place that'd list system requirements (and specifically browser/OS) for Office as exposed on SkyDrive, but it is reasonable to assume that they will be the same as for Office Web Apps in SharePoint 2010 - after all, it's supposed to be the same code. And for those, Firefox on Linux is explicitly supported. No Opera on the list, though - a pity.

The only flaw in your plan, is that you can still buy Microsoft Windows 1.1 from Microsoft. You just can't get support for it.

No, you can't buy it, period. That's actually the third stage of support lifecycle for most MS products, of which most people aren't even aware:

1. General support.
2. Extended support.
3. No support, but still available (this is only for products for which there's sufficient demand, so far as I know).
4. Not available. No, really. Please dig out the body of the programmer who wrote your original app 30 years ago, and make him rewrite the code to work on something that's still supported.

For example, Windows 3.11 went from #3 to #4 in 2008.

make GUI's, access db's, parse XML, talk to other machines, etc. Which C, C++, and C# (LINQ excepting) don't have built-in to the language

LINQ in C# cannot do any of the things that you've listed, either. After all, it's just syntactic sugar for method calls, with no inherent semantical meaning - and the latter is defined entirely by the libraries. In fact, this can be rather creatively abused.

When Microsoft started the trend of removing menu bars with Vista and Office 2007 I believe their aim was not to improve the user experience but to lock users into their applications

No, their aim was to solve the problem that menu bar discoverability doesn't scale, to the point where the top 10 feature requests for Office were features that were already in Office.

See:

http://blogs.msdn.com/jensenh/archive/tags/Why+the+New+UI_3F00_/default.aspx

You can definitely create new documents in Office Web Apps preview in SkyDrive. Indeed, I just tried that a moment ago - there's a "New" button on the toolbar while browsing folders, which expands to the list of document types. Here is even a blog post from the team explaining this and showing a screenshot.

I do wonder where that FUD comes from - there seems to be a proliferation of posts in this discussion claiming that this functionality is missing, so, apparently, people are getting it from somewhere?

F# Seadragon ( http://www.seadragon.com/ ) StreamInsight ( http://blogs.msdn.com/streaminsight/archive/2009/08/20/streaminsight-goes-public.aspx ) Surface ClearType

Also, UAC is indeed a boundary at the lowest level, hence the requirement to bloody reboot when you change it (can you tell I hate rebooting).

Nonsense. If the user is an administrator, UAC is not a security boundary. See here:

Security Boundary: this is a special term to Microsoft. It means that if someone discloses a way to violate a Microsoft-defined security boundary, that Microsoft will release a security patch as soon as possible, so that the method to violate the boundary no longer works against patched systems.

Administrator running in Admin Approval Mode (AAM): this is kind of a hybrid between An Administrator and a Standard User. You get a split token, which means you have the credentials of both a Standard User and an Administrator, and the right one is applied depending on what is going on.
...

Administrator in AAM: this is definitely not a security boundary. With the Administrator token available in the user’s space, it is too easy for malware to attack something in this very broad attack surface and gain elevation without the user’s approval. Microsoft could not patch this barrier without substantially breaking application compatibility. ..

Both Apple and Microsoft, two of the more influential forces in the decision, are stakeholders in MPEG LA [mpegla.com].

And it is unlikely that either of them makes any money from MPEG-LA - Microsoft's IE manager says that "Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264". I'd expect that Apple, which owns just one patent in the H.264 pool, is in a similar position.

Add the fact that they both probably feels slightly anxious over the seemingly immortal Open Source guys, that just refuses to keel over, but invades market after market.

A good theory, but not quite so well borne out by facts, at least for Apple. They've managed to do quite well getting iPhone marketshare, despite competition from Android, and look to continue being wildly profitable in that area. And, also, they support a lot of open source projects - they own and maintain CUPS, they're major backers of llvm-clang (which, god willing, will eventually supplant gcc entirely), and you can download the source code for the BSD-derived components of OS X (including the patches they've made, despite not having to do so) as well as their kernel.

Open source and patent-free aren't the same thing. Theora is untested in terms of patent infringement, and the assertions of its developers aren't adequate guarantee that people implementing it won't be hit with lawsuits related to it. That and the fact that has no major corporate backers or IP holders willing to litigate on its behalf, makes it a unnecessary risk for businesses. Note, too, that there is are several open source H.264 implementations, including the excellent, GPL x264 encoding library.

I think the decision was made completely without regard to technology

And this is where you're only partially right. Yes, I believe non-technical factors were important in the apparent success of H.264 over theora, but that's not the only reason - there's extensive existing support on mobile devices for H.264 decoding, it's frankly much better quality at lower bitrates than theora, and the default container format isn't the horrible shitty mess that is OGG.

Yes, Microsoft is implementing the WOFF standard, along with all the other browsers.

Of course not.

They posted it in many places, for example:

http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx

It's too easy to bash Microsoft to have to sink to this.

I don't see anywhere on the blog article linked mentioning .Net is Open Source. In fact I did a browser "find" and the first reference to Open Source is a reply in the comments section.

Scott Gu mentions that the source code is available, which it is, and has been ever since.

Also even if Scott had mention that, how would that qualify as much fanfare. Not a peep from Micrsoft PR.

Finally, since that reference release 2 years ago. Microsoft has released the entire .Net Micro as Open Source, help out Mono in development, and promised not to sue open source implementations. Not quite Open Source, but great strides for a company that was so afraid of the process a few years back.

KDawson gives MS bashing a bad name. ( I think that's going to be my new sig)

IE9 will continue to support other codecs via plugin.

Of course, developers can rely on the [codec] of the underlying operating system, like Windows 7, without paying any additional royalty.

http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx

to rephrase this: we like H.264 because it forces Mozilla to break compatibility with Linux or with HTML5, so using H.264 harms either Linux or Firefox

there you have it AGAIN - all the "we support FOSS" blah blah was just empty lies... behind the smile they were planning to stab "their friends" in the back. surprised?

Because Microsoft made a deal with MPEG-LA, that's why. MPEG-LA makes money off patent licensing.

The profit in licensing is elsewhere.

In professional production and distribution. In hardware.

Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264. Much of what Microsoft pays in royalties is so that people who buy Windows (on a new PC from an OEM or as a packaged product) can just play H.264 video or DVD movies. Microsoft receives back from MPEG-LA less than half the amount for the patent rights that it contributes because there are many other companies that provide the licensed functionality in content and products that sell in high volume. Follow Up on HTML5 Video in IE9

Don't believe it?

Then try counting the number of industrial giants like Mitsubishi and Toshiba on this list: AVC/H.264 Licensees

IE is becoming less and less relevant every day. For one it's loosing marketshare on the desktop, but also very importantly is the fact that mobile devices are quickly becoming the preferred medium that people use to interact with the web.

How many of those mobile devices support H.264 video in hardware?

How many have a video camera?

Pretty much all of them.

Microsoft's support for H.264 is in the OS not the browser and is accessible to anyone.

Third-party applications that simply make calls to the H.264 code in Windows (and which do not incorporate any H.264 code directly) are covered by Microsoft's license of H.264. Follow Up on HTML5 Video in IE9

The OS could be Win 7, Win 7 Mobile, or Win 7 Embedded for your STB.

4 upgrades and a seamless migration across architectures. I'd call that pretty amazing.

Big whoop, I did that with Classic, too. Newb. (The architecture was 68k to PPC, but same process.)

Hmm. I was more under the impression that marketing did the research, discovered how they could start up the ancillary certification and training revenue, and implemented the ribbon.

That's pretty insulting to the people who worked hard to create the feature. I'm sure you're so brainwashed that it's impossible to acknowledge anybody at Microsoft actually working to improve their products, but try reading this blog and see if it can soak through your skull: http://blogs.msdn.com/jensenh/

rewrote the GUI (Cocoa),

Rewrote, but without making a single significant change to it (usability-wise), and while removing features in the previous version. This is not something to laud, this is laziness.

I guess you also missed the shot across Adobe's bow?

That's mobile, aka hardware. I've made it perfectly clear twice now that I'm not talking about hardware.

MS has gotten fatter and slower (I'm not buying the switch to lazy loading from Vista to W7 as making it "faster", that was a major bug fix)

Have you even used Vista? It's not a tenth as bad as Slashdotters claim. The only real performance difference between Vista and Win7 is that Vista would aggressively fill its file/DLL cache at boot, and aggressively indexed drives and Win7 does both lazily.

If you actually, seriously, and honestly *believe* the shit that Slashdot shovels relating to Vista, then I think you're beyond hope. There's no point debating with a person whose mind is set in stone.

We'll also not delve into Apple's other software offerings because there's just no state of the art in Keynote,

I won't go into details about products I haven't tried. I will say that until Keynote gets collaboration and version control features, it's simply not in the same market as PowerPoint... either Apple believes that every company giving presentations is a one-man shop, or they badly mis-estimate how people use presentation software. Keynote may be better in some areas, but it's missing extremely basic and extremely important features.

If they were pretty much the same, I and millions of others wouldn't be switching. There would be no reason to and the learning curve, however short, wouldn't be worth it.

Oh please. You're switching because you want to be trendy, not because you care about the quality of the software. You've obviously never used Vista or Windows 7, but you certainly feel qualified to comment on it regardless. You obviously didn't fairly compare the alternatives.

I would actually go as far as to say you're the exact kind of poseur the starter of this thread was talking about.

Anyway, "it's good because its popular" doesn't work for McDonalds, and it doesn't work for Apple. Not in my eyes.

It's so hard to even write these replies, because I already know that you're so brainwashed, you'd never, ever, give anything from Microsoft the benefit of the doubt-- you'd never actually try using any of their products, and you'd certainly never, ever, ever say, "I haven't used that, so I can't comment on it." You can't argue with zealots. I think next time I won't even bother trying.

Hey Bill Gates is trying his hardest to show everyone he is trying to change. Why else would he spend so much money to make cows that don't fart and helping to spread awareness for malaria?

Folks here on Earth are working on it:

http://blogs.msdn.com/stevecla01/archive/2009/07/19/bill-gates-is-making-cows-that-don-t-fart.aspx

http://gizmodo.com/349723/scientists-discover-how-to-neutralize-cow-farts-your-farts-next-god-willing

It's a good cause . . . with no visible methane on our planet, those aliens won't be able to find us, and eat us. And our cows.

And then you could add in some a GUI platform to let you present information in graphical windows say, and call it Windows Presentation Foundation.

• The OASIS Open Document Technical Committee continues to expand the capabilities of ODF. The ODF 1.1 has been released and 1.2 is in draft form already. These represent significant ongoing work based on elements either flawed or missing in the 1.0 specification.
• The PAS management guide (JTC1N5746) states a desire to avoid divergence of the JTC1 spec from any future versions. Therefore the management guide requests that the originator of the specification work closely with JTC1 on revising or amending a PAS submission. Given that ODF 1.1 was not submitted to JTC1, should we interpret this to mean that it is not mature enough and that they are waiting for 1.2? What should be inferred about the maturity of the 1.0 specification?

Here you go. Straight from the horse's mouth. And that's the first one I found with my very first Google search. If I could have done this a week ago within 5 seconds, you are not going to tell me that you didn't get this particular point from Microsoft. I knew your point sounded familiar when you brought it up.

And as for you admitting that you were wrong, you know what? I can't find it in this subthread. So how about you provide me with a quote? Because all I see is lots of shouting trying to sidetrack away the conversation from the fact that you said:

there has been no attempt to submit [ODF] 1.1

which is Just Plain Wrong(tm)

Mart

They *are* using OS supplied codecs, they're just choosing to limit the options available to reduce the security footprint. Firefox could do exactly the same thing.

Uh huh. And why doesn't Chrome? And what of the 60% of Windows users with no H.264 support in the OS? And what of other desktop platforms and mobile platforms?

Your approach is a poor solution which limits cross platform deployment, which limits Firefox source distribution, which promotes closed formats, all of which limits competition and innovation with artificial barriers to entry for new developers and is ultimately bad for the web.

Meanwhile, the MS statement was about image codecs. The OP was speculating they would do the same for video codecs, without any actual evidence to back that claim.

Okaaay.. so you're suggesting that video codecs are somehow more secure that image codecs? I'd like to see that proof. It'd be spectacular. In any case, read here:

http://blogs.msdn.com/ie/archive/2010/03/16/html5-hardware-accelerated-first-ie9-platform-preview-available-for-developers.aspx#9979730

Microsoft doesn't even support WMV videos in IE9.

Mozilla can use AVC/H.264. They just need to do it via the OS, like I think IE and Safari will do, and Opera already does. H.264 is already directly supported on Windows 7 and Mac OSX. Linux users need to do their tricks, like with MP3.

They only way they can do as you suggest is by severely compromising Firefox. This has been answered exhaustively many times. See Mike Shaver's blog post about it. To quote:

People have raised questions about using existing support for H.264 (or other formats) that may already be installed on the user’s computer. There are issues there related to principle (fragmentation of format under the guise of standardized HTML), to effectiveness (about 60% of our users are on Windows XP, which provides no H.264 codec), to security (exposure of arbitrary codecs to hostile content), and to user experience (mapping the full and growing capabilities of to the system APIs provided); I’ll post next week about those in more detail, if others don’t beat me to it.

Security is not to be underestimated. It's worth noting that IE9 will not support all media formats supported on the host operating system, purely to limit the attack vector surface area available. See this comment by Microsoft's Frank Olivier on the IE blog. He's talking about image formats but the same applies to video formats:

We've not heard many requests for additional image types - to limit the attack surface in a web browser, it is a good idea to not expose more decoders.

See also Chris Blizzard's blog post about the decision to only support open video in Firefox. And most importantly of all, don't worry about. Open video is the way forward for video on the web. Theora is here now, VP8 may be joining it next month, and Dirac may join both in the future.

You'd have a point about the assembly, except that Adobe's software already runs on Windows, on x86. If they have x86 assembly for the Windows version and PowerPC assembly, they can run it on OS X on x86.

Your third point is actually a good counterexample. The Win32 API contains a lot of things that are very endian-sensitive and even sensitive to the size of long. Lots of structures are expected to be dumped directly to disk, with 32-bit little-endian longs. Most Win32 API code would not work on a big endian CPU, while OS X moved from a big endian to a little endian architecture. Most Win32 code would also not work on an ILP64 or LP64 platform, which is why Win64 is about the only LLP64 platform in the world. For a longer explanation, see Raymond Chen.

There is no Office 13 - But Why? – a video produced by Microsft on MSDN Channel 9 – explains why there is no Office 13.

From TFA page:
http://blogs.msdn.com/ie/archive/2010/04/07/a-closer-look-at-internet-explorer-9-hardware-acceleration-through-flying-images.aspx
Result: 95 errors / 2 warnings

They do, but it's not Windows:
http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx

You are correct, and here is the relevant link:
http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx

Before the 360 development hardware was complete, there was some form of Windows running on PowerMac G5s serving as the development environment for studios, but that was a stop gap.

It doesn't run Windows:
http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx

The interesting thing about Itanium is that you could write code which would work ok on pretty much any processor but fault on an Itanium. Then you need someone like Raymond Chen to work out why

http://blogs.msdn.com/oldnewthing/archive/2004/01/19/60162.aspx

Windows server 2008 R2 dropped 32-bit x86 support, actually.

Actually they didn't, they made it an optional feature that is not installed by default.