[Mythbusters]

Right and those office like apps are toys. Not a real productivity application. There were touch screen phones before iPhone and search engines before Google. I am not saying Office running on ARM is in the same league but there is no denying the first class engineering there.

[stephencanon]

Office XP was a "toy"? Office 2003? The SoC in the Surface is as capable (and in many ways more capable) than the commodity computers of that era.

At what point exactly do you believe office stopped being a toy?

[Mythbusters]

Aren't we talking about the architecture here? Surface and the software on it is ARM architecture. Something that Office never ran on before. These are significantly different architectures and just because the graphics or processing capabilities are same does not mean it will run right?

Besides the version that was tested with was a beta. The final version of office runs smoothly on the device. So what is your point? RTFA!

[stephencanon]

Correct. The architecture is different, and software written for x86 will not "just run" on ARM.

However, porting a userland application to a new architecture of roughly equal capability is not a major engineering accomplishment. There is significant work to be done in the compiler, in the OS kernel and libraries, and I don't mean to detract from that at all. Well-written application code (especially code for productivity apps that generally doesn't make heavy use of processor-specific features like vector ISAs) should require minimal change.

My point is simply that office should not tax the capabilities of the SoC at all, and that getting it to run isn't a major feat of engineering in itself; no limits are being pushed here. I'm not saying that Microsoft hasn't done a good job, or that Office sucks on the Surface. I'm just trying to have some perspective.

[objclxt]

I'm prepared to give Microsoft the benefit of the doubt here, and suggest that Office is a bit more complex than your average user-land application. I suspect a lot of the code is either quite old or low-level, to a much larger degree than a typical app. It's not just Microsoft - think about how long it took Apple to migrate iTunes from Carbon to Cocoa, or Adobe to get 64 bit PhotoShop on the Mac.

[stephencanon]

The limiting factor in both Carbon -> Cocoa and 64-bit Photoshop was porting to a completely different API layer, which turns out to be vastly more invasive than changing architectures. Even for very complex userland programs, changing architectures typically doesn't require changes to more than a tiny fraction of the codebase (unless one is porting to something truly exotic, but ARM and x86 are really quite similar from that perspective). You end up spending a few months chasing down bizarre bugs, but the actual scope of the changes is always fairly small.

[MBCook]

I would agree that Office is probably a beast to port due to its long history and large code base, but that still doest explain why it should be considered an achievement for Office to run at all on ARM. ARMs are in the same ballpark as x86, clock for clock. It's not like its a 50x performance difference.

Mythbuster's argument just isn't making sense to me.

[Mythbusters]

It's not the difference in performance but having to compile against a different architecture altogether. These two are architecturally different and porting an old legacy app like office cross platform must not be an easy feat. I don't see examples of old apps easily being ported over across platforms.