Arm64 Apps For Windows

[Argenta Sugden]

TeamViewercrashes often on my Surface Pro X which runs Windows 10 on ARM (arm64). This device can run 32-bit apps through emulation when no native arm64 is available, which is the case for TeamViewer. So TeamViewer runs in 32-bit on this device.

When a crash occurs (e.g. when remotely controlling a customer's device), a log is visible in the Windows Event Viewer.

Would be great if TeamViewer was available natively on Windows on ARM though, instead of running as an emulated 32-bit application. CPU usage is quite high currently, and the battery life would definitely benefit from a native ARM version.

I'm planing to purchase a Microsoft surface pro x device, but I'm hesitated because as you've mentioned most of the windows applications runs on the Surface uses the 32-emulator, the most important application I need is teamviewer & without confirming it runs on the Surface without any problems there is no point of purchasing it except wasting my money.

I gotta say that the 32-bit version of TeamViewer has been working fine on my Pro X - I had issues with hardware acceleration in the beginning, but those have been resolved in the meantime (I believe through a display driver update on Microsoft's side).

Tried the 64-bit version two weeks ago on Windows 11 (which supports 64-bit emulation) but it crashed when I tried to connect to another computer. The 64-bit emulation in Windows 11 is slightly buggy still, so I expect that to improve over time.

I think it's just a matter of time for TeamViewer to come up with a native ARM64 version of Windows. As a developer I know that a lot of toolchains/dependencies have been updated to support ARM64 lately (which I've been contributing to myself as well), so it should become easier and easier for TeamViewer to port things to ARM64 ??

I have recently installed Ubuntu ARM on my M1 MacBook Air on a virtual machine (using Parallels), and unlike Windows ARM and macOS ARM, Ubuntu ARM does not seem to include a translation layer for x86 apps, which makes the system almost unusable as a lot of Linux software does not support ARM yet.

I cannot believe there is no translation layer on Linux ARM yet, considering it is an open source OS which often makes developing those kind of things easier and faster than on other operating systems.

Here is how to install Box64, so that you will be able to run amd64 binaries in arm64 (note that you won't be able to install amd64 .deb files this way. .deb files are not designed like that. However, you may still be able to extract the binary from a .deb file and run it.). These instructions are based on this guide.

You seem to be misinformed. Since most of the software in the repositories are Free and Open source, they have already been compiled, and readily available for ARM. According to , the arm64 repository for Debian Sid has 62542 packages, whereas the amd64 repository has 63568 packages (as of 18th Nov, 2021). People usually use box64 to emulate proprietary software created for Windows.

This is a problem because it appears to mean that it is not possible to use Flash Programmer 2 or Sensor Controller Studio on recent Apple hardware. These two utilities appear to only be available on Windows OS but without the device drivers they cannot be used.

There are no plans for supporting CCS running on a Windows Arm host at this time. CCS runs on M1(Arm) based macs thanks to the Rosetta layer that Apple provides. Eventually, we will need to provide an M1 native application but today the only M1 native code is in the installer, Rosetta handles the rest.

Unfortunately, a large volume of effort that would be required to change the Sensor Controller Studio source code (based on Visual Studio) so that it could support MacOS machines. Such development efforts have never been prioritized and the general recommendation is that MacOS developers use a Windows or Linux VM.

Whilst not supported - and I can see why not, Sensor Controller Studio 2.9.0.208 does run well on Windows11arm64 under Parallels. It allows projects to be created, edited and the Code Generator seems to work just fine. The only missing piece is Task Testing which cannot connect to the target without the arm64 native xds110 device driver.

Obviously, I'd be very happy if a macOS version of SensorControllerStudio were to appear. This would make for a very nice development suite. ...but maybe recompiling the device driver might be a simple short term fix?

Thanks for your reply. Yes, I can see why this would not have made it up the priority stack when MacOS was running on x86 and a Windows or Linux VM was a freely available way of working. Developing on Windows10 as a VM in Parallels has been my go to solution for some time now.

What is new now is that there is no way, as far as I can tell, to develop Sensor Controller code on an M1 MacBook. Whilst the MacBook can execute x86 code through Rosetta, it cannot run an x86 VM because the VMHost vendors are only offering arm64 VM support. This appears to be a reasonable choice for them because there are fully supported arm64 versions of both Windows11 and Linux available

Funnily enough though Window11arm64 does run CCS, the Simplelink build chain that I'm using and SensorControllerStudio. I think this is because the OS includes automatic emulation of x86 application code. Certainly I can compile binaries with this setup. What Windows11arm64 does not do is support x86 device drivers, and this is where using a VM on M1 MacBook comes unstuck - you cannot connect to the hardware to debug or test SensorController code.

So you are able to run CCS on Windows 11 Arm64? I am surprised that works. If you are able to build your projects that means that Microsoft has some sort of emulation layer as our compilers on windows are all built for x86/64. I assume you get some sort of error message when you attempt to start a debug session?

So far I've only attempted builds on arm64 Win11, no debug sessions. Without the driver there didn't seem much point. The build results are binary identical to those produced with CCS on OSX on M1 silicon. I too was a bit surprised by this, but reading into arm64 Win11, there are a bunch of settings related to x86 emulation in Windows11arm64. I assume from this that the OS is performing on-the-fly emulation where it needs to for application code. Certainly CCS builds done like this are a bit slower than done in CCS OSX which uses Rosetta for translation rather than emulation.

Noticed that TI created the xds110.c file for OpenOCD, where that OpenOCD source file appears to run in user space and use libusb to communicate with the XDS110 rather than requiring a specific driver.

The immediate issue is actually with SensorControllerStudio and the other utilities that TI are unlikely to port to OSX. Whilst these are happy running in emulation under the arm Windows11, the device driver that they need cannot.

For our "driver" we are actually just using a standard driver that is already present. We install configuration data (inf) in a signed package. The installer uses an old Windows driver framework. That last part is likely what is failing. Sorry that does not help much. We would need to rebuild the installer using a newer windows driver framework.

this makes it possible to modify the .INF files supplied with CCS for the XDS110 to add sections to specify an install under arm64. The install does depend on a couple of coinstaller DLLs but Win11 seems happy to execute these under emulation.

So far I've tested this with SensorController Studio and a LaunchPad, and launching a debug session in CCS11.

One word of caution though, Windows11 doesn't automatically install the device drivers for the XDS110 DFU firmware upgrade process and so the upgrade can fail half way through. This can lead to a need to de-brick the Launchpad.

If you could send me a private message with the files that would be great. It may be something simple that we could integrate in a future release even if we don't officially support the combination. To send a private message you can click on my name.

Learn more about running Windows on PCs powered by Arm processors. Find guidance on how to build Windows apps for Arm64 devices or iteratively update your existing Windows app to take advantage of Arm64 native capabilities.

I am just guessing, since I am not an employee of Docker Inc, but I know that Docker Inc and Microsoft worked together to make Windows containers possible, so there must be a reason why they could not make Docker Desktop available for Windows with ARM CPU.

Hi, Arm lent us a Windows 10 machine a while back and I did a little testing. Docker runs fine on Arm64 WSL2 if you install it yourself (via ), which is great, once you have updated to a Windows version that supports WSL2.

Building Docker Desktop has a bunch of issues around software we use and available toolchains, and as you say lack of emulation for 32 bit x86. This situation should get better over time as the Windows arm64 ecosystem gets better and we update some dependencies. If other people are interested please let us know.

I don't have a Surface Pro X, therefore I'm not sure. On [1], Microsoft mentions that the Surface Pro X is running Windows 10 Home, with a link to the FAQ [2]. On the FAQ page, it says that 32-bit (x86) apps are supported.

I don't see why you'd want to target a specific platform here. When I'm building KeePass, 'Any CPU' is selected as target platform. So, I'd expect it to run as an ARM64 app, if an appropriate runtime/framework is installed.

KeePass 2.x is written in C#; no platform-specific components are required (the 'KeePassLibCxx.dll' libraries are necessary only for importing KDB files created by KeePass 1.x). As 'Any CPU' is already selected as platform target, I don't see what changes could be made in KeePass (code, project properties or configuration) to improve its compatibility with ARM(64).

3a8082e126