Although ARM-based PCs are now available, apps that utilize native 64-bit architectures on Microsoft’s Windows 10 on ARM have been relegated to legacy support for 32-bit apps. Microsoft introduced the proper frameworks for 64-bit apps at its recent BUILD conference, allowing developers to port their apps and begin native app integration. After a small wait, apps are starting to appear; VLC – the swiss army knife of multimedia players – is one of the first to launch a dedicated ARM64 app.
I’m obviously not going to cover every single major Windows application that gets ported from x86 over to ARM, but I do find there’s something fascinating about seeing the first few applications getting the ARM treatment. It makes me think of the very early days of Windows NT, when it was available for not only x86, but also for Alpha, MIPS, PowerPC, Clipper, and SPARC (although those last two were never actually released).
I wonder if they would be willing to release these unreleased ports (sparc, alpha 64bit etc) for historical and research purposes? They can’t have any commercial value, but would be very interesting to play around with.
Same goes for other niche or unreleased systems like Solaris/PPC – i actually have it, and a machine to run it on, but i can’t find a copy of the compiler (mainline gcc never supported it, one guy ported a specific version but i cannot contact him or find binaries and obviously can’t compile the src).
VLC is already on non-x86/x86-64 architectures on other platforms. So it was a relatively easy port; probably just a recompile and test verification.
Most Windows applications, however, are only designed for x86/x86-64 and wont’ be easily ported by merely a recompile; they’ve probably got a lot of various uses that mean hard work for porting (bitmasks, pointers, etc – especially in the Win32 APIs).
Both x86 and modern ARM are little endian, so I wouldn’t expect much trouble from bit twiddling code. I’d expect the x86 to x86_64 transition to be harder than x86_64 to ARM64, since pointer sizes stay the same.
Edited 2018-06-02 03:59 UTC
Unless you try to use some assembly code, the application should just recompile. Even unaligned access is no problem if it’s not enforced by SCTLR_EL1 during kernel boot, however uanligned atomic access will probably fail – I doubt any structures passed through APIs depend on this behaviour. I suspect using something like qemu-user for windows would just work.
Well, you can port an app, but VLC is just a crashy mess on all platforms, so even you have it on your platform, it doesn’t mean much – you might not be able to play anything.
I haven’t had VLC crash on me ever.
Me neither, and I’ve used it for years on Windows, Linux and BeOS!
Must have been something wrong with your underlying system somewhere.
It has crashed on me when playing DVDs (unencrypted but with complex menus).
I prefer MPC-HC anyway despite most likely not getting any new versions. I paid for the excellent DirectShow filters when I bought my Windows license, I might as well use a player that takes advantage of them…
Edited 2018-06-02 18:08 UTC
That would explain it. I don’t watch things from DVDs anymore, not even the DVDs I own, but even then, none of my DVDs have complex menus.
I don’t watch the DVDs straight, rather I rip them first, then watch the rip. That way I’m not forced to sit through a bunch of unskippable ads and whatnot.
Edited 2018-06-04 02:17 UTC
I find it somewhat interesting that so many people seem to be obsessing over this to such a high degree. I could have told you that VLC was one of the most likely applications to provide a 64-bit ARM version for Windows first. I mean, it’s not like they already had code that was easily portable to almost any architecture, depend almost exclusively on libraries that are just as portable, and already had a working 64-bit ARM version of much of their code (for their Android app).