Windows 11 On Arm64

[Mirtha Hinrichs]

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 was able to make this work end to end with STM32CubeProgrammer and IAR on Windows 11 ARM64 (running in Parallels on an Apple M1). To make that work, I have removed all references to the certificate signatures (CAT files) from INF files.

To install, you need to temporarily disable driver checks: -to-fix-the-third-party-inf-doesnt-contain-digital-signature-information/ (use the temporary solution 3 - Reset while holding Shift). After rebooting with driver signature checks, go to Device Manager, find the STLink device and manually specify the folder where you've unzipped the file attached below.

I made the modifications and because the inf changed Windows fails to install the driver (tampering). Because the driver is signed and the signature changed, I don't know of a simple way to disable the check. This means there is no viable workaround for now for all Windows ARM64 users.

The changes I've made cannot work (for security reasons as the driver package is signed). The changes are following driver documentation from Microsoft here: -us/windows-hardware/drivers/install/inf-controlflags-section

I have attached only the INF files from the STLink driver. These have been changed from NTamd64 to NTarm64. The correct fix is to add another arm64 section (i.e. wherever amd64 is used, add something similar for arm64).

Hi,

I have extensively searched for an answer to this but cannot find a single reference to it so, LibreOffice for windows arm64. Does it exist, is it on a roadmap? Are there any obvious impediments to me compiling it myself?

If I took it on I would definitely be looking to cross compile X86 to Arm64. Even for basic web app development VS chugs on my surface pro x, it would be an exercise in frustration to emulate all those tools in 32bit.

Now I switched to a new Macbook Pro with Apple M1 cpu which has an ARM64 architecture. So I'm now on Windows 11 ARM version. Cisco is the only VPN client (and those on virtual desktops) which is working in this constellation. I tried the 32 and 64 bit versions of the current windows FortiClients, none is working.

When I searched for "FortiClient" in the Microsoft Store, I found that App and I installed it. After the Installing process there is a white App with only a notice with some information, when you opened it in the Windows Start Menu. The Header is called: "FortiClient v1.0.1041".

To Configure the App, I open the Settings and searched for 'VPN Settings'. There I click on 'Add VPN' and add the Name, url:port, the Name and the Passphrase. We have no certificate in my Company. After that I select in VPN Provider the FortiClient. I enabled the "Remember my sign-in info".

How to use Microsoft Store to install most recently version? The avaliable one is 2016.

Using directly from FortClient site does not work, installation run perfectly without erros, but when try to connect take a few second and finish, not complete VPN connection.

Something rare, constantly Windows is trying to install network interface without succes, i happend for you too?

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

I need the windows 10 ARM preview, but I can't find it. I contacted Microsoft support, and they told me that they don't have this version anymore, but that I can ask on this forum if someone has a backup or something. Can anyone help me?

Hi, that's Windows 11, I need Windows 10. I'm asking if someone has the file, or where I can download it. Here Download Windows Insider Preview ARM64 (microsoft.com) they have only Windows 11 ARM, and I don't need it :)

The use case would be development with Swift for Windows on a Windows 11 VM on Macs with Apple Silicon. We already use Visual Studio for ARM on it and it is very usable. While my main work is on macOS, we also have the need to compile for Windows.

Although Swift on Windows currently only supports x64 I have been successfully building my Swift projects on Windows ARM since Windows 10 ARM and now Window 11 ARM using Parallels Desktop on macOS with M1 (not counting also Linux ARM...). The resulting x64 code runs well on Windows ARM (thanks to the Windows x64 emulation layer) and therefore meets our current customer needs, but I would also like to be able to generate for Windows arm64 natively soon.

Yes, ARM64 is an important target to support. However, there are plenty of things that are still missing on the x64 side as well. ARM64 support is getting better, and while we do not have official builds available yet, it is getting reasonably possible. I have been running a native ARM64 toolchain on Windows for a while. There are some more issues to be ironed out with the toolchain, and we still need to iron out how to provide official builds for them.

In his latest message on this thread Saleem Abdulrasool mentions that

"There are some more issues to be ironed out with the toolchain, and we still need to iron out how to provide official builds for them."

No, there aren't known major issues, most of those have been addressed. There is one crash that we are seeing which we haven't fully isolated and thus do not necessarily have an understanding of the shape of the issue. On the other hand, that is a large code base with C++ Interop .

There are no concrete plans. We are looking at getting build.ps1 support for cross-compiling the toolchain. This will require subsequent setup on the CI that @mishal_shah would be better suited to help with ascertaining the resourcing for.

Add cross-compiling support for the windows toolchain by hjyamauchi Pull Request #71584 apple/swift GitHub is the PR that @hjyamauchi and I worked on recently to add the support for the cross-compilation so that we can get this functionality enabled for official releases as well.

Now that ARM64 installers for Swift-main are available on the homepage, I was wondering what version of Python is required to set up debugging in Visual Studio Code. Python 3.9 binaries for Windows on ARM were never officially released. Is there a trusted source for Python 3.9 ARM64 or do we need a different version?

There are binaries available on nuget for python 3.9 on ARM64 - NuGet Gallery pythonarm64 3.9.10. We are trying to track the same version of python across x64 and ARM64 as well as across macOS and Windows, and hopefully we will be able to use releases off of python.org whenever the next python bump occurs.

Great, thanks again. After extracting Python from the NuGet package and setting PYTHONHOME (didn't work for me without that environment variable), I can debug Swift code in Visual Studio Code without any problem.

Note: configure now enables DCO build by default on FreeBSD and Linux. On Linux this brings in a new default dependency for libnl-genl (for Linux distributions that are too old to have a suitable version of the library, use "configure --disable-dco")

Note that OpenVPN 2.5.x is in "Old Stable Support" status (see SupportedVersions). This usually means that we do not provide updated Windows Installers anymore, even for security fixes. Since this release fixes several issues specific to the Windows platform we decided to provide installers anyway. This does not change the support status of 2.5.x branch. We might not provide security updates for issues found in the future. We recommend that everyone switch to the 2.6.x versions of installers as soon as possible.

3a8082e126