Comment by mitchty | Hacker News Reader

Comment by mitchty | Hacker News Reader

Parent Full thread

Well for one, Apple transitioned from ppc->intel REALLY well with Mach-o binaries and Rosetta.

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)

You keep saying "without using a vm/jit" like it's something Apple did, but in reality, Rosetta is a JIT and not every Mac OS X binary for PPC was a Universal one (which, incidentally, caused a few problems when Rosetta's translation wasn't up to par, either).

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.

This is true that Rosetta is a JIT, but my point was more that the Mach-O binary format allows for multiple architecture binaries, therefore somewhat obviating the need for a jit.

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.

From CES2011

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.

I was thinking more along the lines of C/C++ WIN32 api and things like 64bit calling conventions etc... that might not remain quite the same on ARM.

There is no such issue. You dont seem to understand what you are talking about. Look up ABI. They couldnt possibly port software as big as the OS itself and MS Office / Oracle DB to Itanium without having stable C/C++ and Win32 ABI/API.

Ok fine I'm a retard.

Yeah everybody knows there's no way a C API from Microsoft could ever be a leaky abstraction. Lol.

Or that there's no way the win64 calling conventions weren't influenced by win32.

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.

Right, being mainly an extension the x64 is hugely influenced by x86. The 64-bit Win32 ABI is obviously influenced too, to the point that on x64, 32-bit process is largely just a native 64-bit process with 32-bit modules loaded.

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.

Reply on news.ycombinator.com