Windows on ARM64 will support Win32 apps through emulation, but native apps can be compiled for ARM64 too

1. Can this version of Visual Studio releases binary for two architectures for instance, ARM64 and X64 combined?
   This would probably create fat binaries but there would only be one source code to maintain.

2. I can run Classic Windows programs just fine on my old XP PC. No need to spend money for upgrades.

3. I’ll never understand Microsoft. Always taking the scenic route.

4. This has been done before successfully. When Apple moved from PowerPC to X86, they included an emulator (Rosetta) within OSX so that PowerPC apps could still run (If I recall correctly it was 80% of the speed).
   With time, apps were recompiled for X86 and eventually, Apple removed the emulator. The same thing could happen here.
   We might be witnessing the end of X86 domination on the Desktop or just another failed project for Microsoft. Time will tell.

5. Continuum + recompiled apps for ARM64 could lead to Windows on ARM being decent? Well Microsoft, you have my interest again.

6. Windows Continuum runs on ARM64. Announcing desktop support is no surprise. Qualcomm is doing whatever it can to get good press. I really don’t find any of these companies innovative or relevant to the future of computing.

7. No 64 bit windows apps support is useless. I will stick with my GPD win that run 64bit apps… Let’s wait for CES 2017 on January and I hope intel will make something new in mobile cpu sector ….

   1. No 64-bit apps for now since ARM is targeted to mobile-first people who adores longer battery life than pro Apps.

      1. Those who adore battery life should stop dreaming about architecture emulation

8. *yawn* there was a ton of apps recompiled for 32 bit ARM, back when you could jailbreak the first Surface RT. They couldn’t be installed without an exploit (the jailbreak) and it’ll be the same here. UWP or Win32.

   1. Well, supposedly, recent news say MS is going to allow developers to target the desktop on ARM devices and also provide x86 emulation for desktop apps that haven’t been recompiled for ARM.

      1. The emulation thing I believe but I will wait for clear, unequivocal word from Microsoft before I believe they will allow Aarch64 apps willy-nilly. Seems to me they would block those to further push UWP.

         1. We’ve already seen them allow Win32 on Windows Store (as well as other non-UWP routes, the various “bridges”).

            And there’s the news about the x86 emulation itself – are they going to block that too, to push UWP?

            1. Did you even read my comment? Of course they won’t block Win32 emulation, what a ridiculous straw man assertion.

            2. Nope, there’s a reason why they have avoided emulation for years…

               It’s a big hit on performance, which is one of the reasons all previous attempts have failed even when it was just emulating a desktop web browser…

               It’s a big drain on battery life, which on ARM would be a problem because battery life is a premium on most ARM devices and a big hit would significantly impact the perceived value of the device…

               Emulation is also not 100% effective and can vary between devices, especially as ARM has a very high hardware fragmentation issue… Though, this can be limited by optimizing only for hardware that W10 Mobile would be found on but is a issue for future proofing apps to ensure they always work…

               There’s also the hit on RAM as part of the RAM needs to be set aside to run the emulation, on top of the RAM the apps and OS use and not all ARM devices are going to have lots of RAM, least of all by desktop PC standards…

               While making apps run natively is the preferable route, as it gives max performance, allows the app to be optimized for both the form factor and power efficiency, and doesn’t have to run into issues like permissions, security, etc.

               It’s also kind of the point of UWP to be able to run on any hardware… Apps ported to UWP would automatically be able to run on either ARM or x86…

               While a compatibility layer is nothing new and would allow at least some software to be able to run on ARM with minimal modifications as yet another alternate solution they could go with…

               So, unless it’s very high end ARM hardware it’s actually more likely they’d drop the emulator to ensure the apps work on the widest range of devices and to help insure user experience is good enough… after all, in the end it’s not a question of whether it can run something but whether the user experience using the apps is good enough as otherwise it could just ruin the whole user experience and force the customer to move to a different platform…

            3. Oh, and as for your “bridges” shit, how’s that working out for your Android apps?

            4. You do know that was because of conflict of interest issues and they had to choose between support for porting iOS apps or Android as both would entail too much legal and support issues with dealing with competitor companies that would want to limit any such ports… It’s one of the reasons it’s so hard to get a dual booting Andoird/Windows device because these companies interests are in conflict…

               While porting iOS apps offered the most financial incentive…

               Prior to its cancellation, the Beta testers reported they were able to get the Play store working… So it was viable, it was just too much trouble to push it through and MS could make more money off porting iOS apps…

               This would of course not be a case for a Windows app running on ARM as long as its still running on a Windows OS… There’s no conflict of interest with another company and thus no reason to cancel it like they did the Android bridge support… While it can help benefit their own W10 Mobile platform by expanding what it can offer…

   2. Ton? Hahahahahaha…. Try Photoshop on Windows RT Then!

      1. I was referring to mostly open source apps, of which Photoshop is not. Although Adobe could have recompiled it for the RT jailbreak community if they wanted to. Besides, the lack of one commercial app doesn’t negate my point…that we had ARM compiled apps on Windows before but with no way to install them without an exploit.

   3. This isn’t really the same as that

9. Intel tried bringing Android to x86 processors, with the help of a few billion dollars of course, but failed. With TSMC and Samsung catching up on Intel’s manufacturing technology, x86 can not hope to have ARM’s efficiency, so it’s only remaining advantage is performance.

   Now ARM is attacking Intel’s castle with the help of Microsoft, and they have good chances of success. Performance is more than enough today, probably the emulation wouldn’t be killing performance in simple tasks like browsing, and things will probably improve in the future.

   And then there is that canceled, or maybe I should say postponed, socket from AMD, where you would be able to install both ARM and x86 processors. That’s the future if this emulator works.

10. Again as I keep asking on multiple tech sites – HOW does this make the feature unique to Windows on ARM? If programs can be recompiled for ARM then why can they not also be run on Android??

    1. Because hardware (x86, ARM, PPC, 68000,…) is one thing, and Operating System (Windows, macOS, Linux,…) is another.

       1. What in the OS is the limiting factor? You’ve not answered the question.

          1. You can’t install a Windows application on a Macintosh. It won’t run.
             You can’t install an iOS application on an Android device. It won’t run.

             It’s like those kindergarten toys; the square wooden blocks don’t fit into the round holes.

             The compatibility layers/emulation would be like a case that fits around a square block (Win32 .exe) to make it round (UWP), so that it would go into the circle hole (Windows 10 Mobile). However, it won’t go in as smoothly as the actually round blocks (performance hit). And even though you have the round case (emulation) on the square blocks (Win32 .exe), it won’t fit into a triangle block (AndroidOS).

             That’s the simplified answer.

             1. So the limiting factors is APIs?

             2. yes. Basically applications dont understand hardware. It is the OS with the help of drivers understand the hardware.

                Applications interact with OS and the way they interact with OS is different for each OS(conceptually it may be same but practically it is different). These interactions are like the way in which the application is recognised by OS, the way in which apps/drivers get loaded when you click on them, the way in which apps gets to know the environment by using the OS services and the way in which apps uses OS to get its functionality done. If windows apps are compiled for ARM, it means it can work with Windows OS on ARM(Not any OS on ARM).

                if you write code that doesn’t have any dependancy with OS and compile it for ARM then it can run on ARM hardware but for that you don’t need a OS or rather if OS is running then it is not going to load your program as it doesn’t know how to load your program. you may have to write a loader(something like dll, dynamic load) that interacts with OS and give control to your program when it needs to.

    2. How would you run ‘Windows’ softwares in ‘Android’? They are two different platform with different way of running stuff, it doesn’t matter what kind of chips they are using.

       The only way Android could run a windows software via compatibility layer like WINE and CrossOver.

    3. Only part of the code relies on direct machine code of a certain architecture. Most of it relies on APIs, that are provided by the OS. If you have the APIs and you can emulate that small portion that do rely on x86 specific instructions, you have yourself a working emulator! ARM is a reduced instruction set architecture, while x86 has a CPU instruction for everything (like, add two registers together, then jump to the position in the cx register, all in one instruction), so all they have to do is to take all the special instructions and break them down to small snippets of code that does the same thing in an ARM environment. They also have to consider that some basic instructions might work differently (like a failed division might have errorflags in different registers), and have to replicate non-existing registers, but if you have the horsepower, it’s pretty straightforward. But it will be slow. A tiny piece of code, like PUTTy will run no problem, but don’t expect Adobe Photoshop to run in any meaningful speed on this.

       1. I don’t feel like you’ve answered the question whatsoever. I didn’t ask for an analysis of the potential performance, rather if the APIs were made available on Android then what would stop it from running any X86 program the same way this will work for Windows?

          1. The APIs are pretty much the operating system itself, or at least most of it. If Android gets a full Win32 API support, then it gets most of Windows itself. Windows is not the “start” button or the desktop, rather the ability to run Win32 applications: the APIs. OS/2 was an operating system with Win16 (and later Win32) support: it literally contained a full copy of Windows within itself for that. Windows XP mode in Windows 7: a full windows XP virtual machine.
             WINE on linux… well, I’m not quite sure what to call that. It’s more or less a Win32 kernel replacement and DLL loader, so rather than recreating the APIs, they provide an environment to run the real stuff, but on the linux kernel, acting as a compatibility layer.

             So, to answer your question, yes, if Android were to get a full Win32 API support AND a way to emulate x86 code on ARM, it would be able to run Windows apps (with very little modification). But this is true to any system, OSX or iOS, QNX or FreBSD, anything would be able to do this too.

             Just to understand what kind of a work this would be: the first thing an app would do would be to call an API to create a window for itself. A concept that’s entirely missing from Android.

             Check our React OS, those guys are working to do just that for the last 20 years or so (not on ARM thou, only recreating the APIs on x86/64).

             1. What kind of APIs are we talking about here? .NET?

             2. No, the Win32 API. Dotnet is optional, or you can install it alongside your application as long as the basic Win32 APIs work, so you can install anything.

                Also, I hope you do realize this is all theoretical. For example some applications need a working registry. Linux or android has nothing alike. And while you might be able to run a binary, it’s possible you can’t install it, because it relies on the Windows installer service, which is again a separate thing. Putty or 7zip are very lightweight programs, they don’t require much to run. You don’t install them, just drop it somewhere and fire away. Things, like Photoshop or games need much much more besides the sheer ability to execute their code.

          2. He answered the question spot-on. APIs are what is responsible for keeping the majority of software from being easily ported to ARM. Most x86 windows software relies on DirectX, .NET, and other proprietary APIs and libraries to function. The components of code that are independent of these this is typically very small.

             1. So the answer is “the APIs that Windows use are proprietary” – he did not say this. If he did then you wouldn’t have to say it. I understand if this is the case.

             2. It’s not that they are secret, they are well documented on what they do, but the proprietary part is how they do it, and they interlope all together. The API itself from a programmer’s standpoint is just a dictionary, it says what function does what and what answer you’ll get to your query. You can’t even copyright an API in itself, because the whole point of it is that other people use it, and understand it (you can’t copyright the method to ask for a croissant in french). Theoretically you could replicate it. ReactOS does just that. But it’s such an enormous work (30 years of development of thousands of programmers), that even a tech giant, like Google would have to work years and years on it to create anything meaningful without any help from Microsoft (or existing projects).

    4. Re-compiling a x86 Windows .exe file to run on ARM Android OS requires so much work.
       So much work, that…
       …its just better to write the program from scratch with all the efficiency improvements and usability/user interface improvements for Android.

       However, if its the choice between emulating millions of programs to be compatible on the destination platform… that’s much better than re-writing all of it from the ground up.

       Of course, that’s just a general statement though.
       It’s totally possible the emulation will kill the performance. Or battery life. Or both.
       And could make the thing totally useless for the programs you want and need.
       So it could make the endeavour a lost cause.

       I actually think that’s the future.
       Letting go of the past, and setting up for a better future. That’s only achieved with people moving away from OS X and Windows.

       And using the new development tools to create the Apps that can run on multiple systems and multiple architectures (ARM, x86, RISC, PowerPC, Cell). There’s HTML and Java, Qt, Swift and Universal Windows Platform programs.

       1. I’m still not getting any answer as to why X86 emulation on Windows on ARM will be limited to Windows only.

          1. Because when Windows32 executables are run in an ARM emulation, it runs through several compatibility layers. Things get complicated fast.

             Technically it is not impossible to run the same programs on a different OS, for instance, Android. However, the end API’s on Windows 10 Mobile are vastly different to the end API’s on Android. So it won’t run.

             You would have to port over the Win32-ARM emulator itself to Android. And even in that case, you’ll have to use some low-level access, so it won’t work as a platform. It will only work for a particular set of API and kernel. So if you port the emulator to the Galaxy S6, it should work with all the S6 variants, Note 5, Note 7, and Galaxy S7 variants. However, there’s a strong possibility it won’t run on something like a Nexus 6P or Xiaomi Mi 5.

             You could be talented (and lucky) and manage to port it over to a Vanilla Android System and hope it works for your Samsung phone, even though it runs perfect on your Nexus.

             However, that’s all beside the point.
             The API’s and the compatibility layers belong to Microsoft. And they would never open source it, or even license it. It’s their bread and butter. They will double-down on it to give Windows 10 Mobile (and Contiuum and UWP) ecosystem an advantage over Apple and Google.

             1. ok I get it if it is the APIs. What if Android developed equal alternatives to be used instead?

             2. Android is a internationally collaborated project to create mobile operating system.
                I believe you meant “what if Google developed an equal alternative for Android”.

                Well, it would be impractical and impossible.
                Impractical because:
                …. those x86-Windows32 executables will run really slow on an Exynos 7420 or slower. That makes it frustrating. It won’t be optimised for touch user interface. Makes it doubly-frustrating. And to be able to build such a compatibility would mean it only works on SOME android devices and excludes some executables from working (constant crashing). Triple-frustrating. And to top it all off…. it would take a lot effort to create such a thing, and even harder for Google who are good at developing HTML/Java applications and not Windows-applications.

                Impossible because:
                …. Microsoft will sue and block Google from even distributing that software. There is less than a 1% chance they would reconsider their stance on this.

                It’s better for Google to create a NEW ecosystem that uses a modern platform.
                And take control of that ecosystem. Windows is Microsoft’s ecosystem, and a close guarded one at that. So just forget about the whole hypothetical thing.

    5. Recompiling for a different CPU is (usually) really easy if the compiler supports it.

       Porting to a different operating system is a huge amount of work (unless you’re already using a cross-platform language and libraries).

       In fact, never mind Android, this is significant news even for Windows: the older Windows RT required developers port their applications to WinRT (or what’s now UWP), which is a significant amount of work. Now it looks like supporting ARM will be much easier for Win32 applications.

       1. So you are saying the only thing stopping a program written for X86 windows would be language and libraries – my question is why are these limited to Windows.

    6. Because Android isn’t Windows.

       A program needs to be written for an OS and compiled for that OS and CPU combination. Windows programs compiled in this way will run on 64-bit ARM devices running Windows. They won’t directly work on any other OS.

       Now, there is something called WINE, which pretends to be Windows, but translates things so they work on another OS. That’s usually decently fast, but there’s compatibility issues, because Windows is extremely complex, and WINE’s developers don’t know everything there is to know about Windows. But, once WINE supports ARM64, you could run ARM64 Windows applications inside of WINE on another device.

       Similarly, you can emulate a CPU, and that’s how x86 Windows applications can run on an ARM Windows device. That’s fairly simple – how x86 processors work is very well known – but slow.

       And, you can even do both at the same time – I’ve seen where QEMU is combined with WINE, to run x86 Windows applications on another kind of CPU and a non-Windows OS. But, you’ll take both a performance and a compatibility hit.

    7. For more information, ask your nearest Computer Science teacher, google, or books!

Comments are closed.