I agree that the user experience needs to improve across the Windows 8 platform for this to really matter, but that is mainly in Microsoft's court.
For me, I like having both a Mac and PC on hand. An Ultrabook would be nice if only for the size.
It might be an issue of scale but not portability. Much less software exists for Mac than does for Windows.
Traditionally, MS has been very good at maintaining compatibility through different versions. Maybe they'd make an architecture change easily, but they haven't had to do so yet.
I even know someone who's seen a non-x86/64 Windows system!
Sorry. I concede that there is a major application or three that runs on Itanium. For now. Microsoft is dropping the platform.
As for ARM all I'm saying is we'll wait and see.
Using a vm/jit isn't the only way to handle architecture changes. In addition it doesn't remove the need to handle kernel changes/etc... that the vm itself runs on. Nor does it mean that the vm and all of its underlying assumptions are valid on a new instruction set. It took java a fair amount of time to run fast on multiple architectures, I doubt .NET will fare any better.
When Windows actually manages to (again, it ran on alphas/mips/ppc and something else back in the 4.0 days) run on more than one platform I might partially buy into .NET being "portable" across windows releases and architectures. But I suspect a fair amount of things will have to change or move to new apis. Similar to Microsofts go it alone 64bit model in Windows, another architecture in the fray will force things into spaces they didn't originally expect.
Basically, I don't trust anything coming out of Microsoft until they deliver the goods. Apple has shown they can handle multiple platforms transparently, and without the need of a vm/jit. Which can help out things like battery life with caches/etc...
http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s... http://en.wikipedia.org/wiki/Rosetta_(software)
The technology demonstration included Windows client support across a range of scenarios, such as hardware-accelerated graphics and media playback, hardware-accelerated Web browsing with the latest Microsoft Internet Explorer, USB device support, printing and other features customers have come to expect from their computing experience. Microsoft Office running natively on ARM also was shown as a demonstration of the full depth and breadth of Windows platform capabilities on ARM architecture.
I dont think there is reason to doubt Microsoft on API compatibility which i s what this ultimately boils down to. Windows recently ran on IA64 BTW. .NET helps but Win32 in itself is proven enough to need little more than just a recompile for porting.
But in fact their 64bit abi on x86_64 was in fact derived from their 32bit calling conventions.
http://stackoverflow.com/questions/4429398/why-does-windows6...
Correct me if I'm wrong, but there is an exact case of where 32bit windows on x86 directly influenced 64bit. This is what I'm talking about when I talk about other 64bit platforms may not behave the way Microsoft expects. And this directly influences c/c++ register allocation.
Though I will state, what Microsoft did for its fastcall on 32bit windows and 64bit is rather ingenious in that the same call can work on both platforms.
Most of the time, the differences are hidden by abstractions in the Win32 C API. The calling conventions do a pretty good job of this (especially the 64-bit ones). Still, there is a nontrivial amount of software that does need to use a few (or many) assembly instructions or interact with the CPU in low-level ways. Windows is a relatively friendly OS for applications that rely on non-standard behavior.
You can't "just port" an antivirus package. Certainly many malware samples won't run on ARM either, but many will (like .vbs). It will take time to sort all that out. In the meantime, many companies simply won't deploy Windows without AV.
Also, .NET is "portable" not just across Windows releases, but through the work of Mono large portions of it also work on Linux, and on other architectures via Linux as well -- so presumably, anywhere Mono or Microsoft's official .NET are compiled, .NET will run so long as no weird x86- or binary-specific things (like P/Invoke) are done. There are other problems with Mono, however, but those are for another discussion.
The only use Rosetta served was running cross architecture binaries.
Mono also doesn't run the full .NET stack, e.g. think the Netflix drm components, so I can't quite consider it cross platform. Cross platform windows wise sure, but that isn't saying much.
For example, MS Office and IE are still used primarily in 32-bit mode on 64-bit systems.
Even if everything goes smoothly with the codebase, just setting up another build environment for something like ARM means installing a new compiler version and toolset. Many (or most) dev shops are stuck on 6-10 year old compilers.
You also multiply the QA regression cycle costs by some incremental factor.
There are lots of applications small and large, that to this day, don't even ship a 64-bit build.
Yes, there are some applications that have been ported. Even if you were to come up with a not-short list of them I would submit everything else in the world that has not.
The big different is not technology, it's culture. Apple will happily make all your old software obsolete as long as it doesn't seriously interfere with them selling new hardware. Microsoft has the much harder job: they need businesses to buy OS licenses (that is what they sell) and those businesses have a lot of old crappy expensive software that must continue to run to make the sale.
Wake me up when 50% of the shrinkwrapped Windows-logo compliant and hardware software sitting on store shelves runs on it at native speed.
Fun fact: Windows NT was released for PowerPC.