What is the best option for hardware to run Windows on arm64? Does it run on a RK3399 SoC board like the Pine64 Pro?

@carlosedp All of the Windows 10 on Arm laptops that I am aware of to date are Qualcomm Snapdragon based. My daily driver laptop is a Lenovo Yoga C630, and there's a relatively new Microsoft Surface Pro X with a faster chip.

It looks like some work to get the boot sequence for rk3399 boards compatible with Windows lives at https://github.com/andreiw/rk3399-edk2 by @andreiw - with liberal warnings of things that still don't work.

It can also run on KVM, I actually do my ARM64 dev on a KVM VM on RK3399.

I would love to see an ARM64 version of go for Windows 10 so I can run it natively on the Surface Pro X:

Is what I'm currently seeing so it won't even run in emulation on this device or so it would seem.

#25084 same deal.

mitchellh/gox#140
platform.go and a few hax... latter.
https://github.com/golang/winstrap
ahh poohh but did not get an arm64 windows-arm build of gox... how nice.
winstrap-master_windows_arm.zip

might help...

I would love to see an ARM64 version of go for Windows 10 so I can run it natively on the Surface Pro X:

Is what I'm currently seeing so it won't even run in emulation on this device or so it would seem.

Did you use the 32- or 64- bit download? The 32-bit x86 version should run in emulation.

my windows wants is any golang honeypots and RPI3/4 makes for good decoys/bait...
/topSec SBC's are less expensive to utilize emulation meh..

@clarkezone fwiw, the 32-bit x86 version of Go's installer seems to work, at least from my limited testing (I'm not a Go user, I just wanted to build a Go app)

Reposting @anaisbetts's comment from elsewhere:

So, one thing to know about ARM64 on Windows is, it actually fully emulates x86 (not amd64, 32-bit apps oddly enough) for user-space apps - they Just Work (most of the time! kinda!)

So, with a bit of sleight-of-hand packaging, you can make an "ARM64" release that still mostly has x86 binaries

(I'm not sure what the performance cost of that is, though.)

One reason why windows/arm isn't sufficient is that several important APIs -- such as all of setupapi.dll, for example -- are unavailable in wow mode, which means we need actual arm64 binaries.

It's quite possible to get windows running on arm64 in qemu, by the way.

I'd love to see this as well, wanting to build some tools for my surface pro x

@jstarks Any word on this?

We (the OS team at Microsoft) would love to see this, too, and we would be open to contributing the code for the port. Unfortunately, we're not in a position to commit to long-term maintenance of the code or associated builder right now, so we are hesitant to send out any patches.

If Google or the Golang community would be interested in taking on the ongoing maintenance cost, we would be happy to collaborate on the development.

@jstarks Just like we (Alex, me, Google employees) are already helping to maintain the other 3 Windows ports (386, amd64, arm), I don't see any reason why we couldn't do the same for arm64. I've got Windows running in QEMU/arm64 now for Wintun development, and that works well.

@jstarks Just like we (Alex, me, Google employees) are already helping to maintain the other 3 Windows ports (386, amd64, arm), I don't see any reason why we couldn't do the same for arm64.

windows/arm is actually a counterexample. Its builder disappeared and it bit rot. We're not not even sure it works anymore. There have been reports it doesn't.

In any case, @jstarks, the builders are the main issue, more than maintenance. If we have reliable & plentiful builders, the Go team & community can help keep it working. But absent builders it'll just rot.

How does Microsoft test? Does windows/arm{,64} run on Azure perhaps?

windows/arm is actually a counterexample. Its builder disappeared and it bit rot. We're not not even sure it works anymore. There have been reports it doesn't.

The arm port works. @rozmansi got WireGuard/Wintun ported to it. Unfortunately, WOW has its limitations and we really need arm64 to access the APIs that we need (setupapi.dll, for example).

How does Microsoft test? Does windows/arm{,64} run on Azure perhaps?

I'd too be interested to learn if Microsoft has some nice solutions for this.

But in case not, @rozmansi and I can probably help getting the QEMU setup via TCG running smoothly in gcloud like the current set of builders. Or if we actually need additional performance, we could look if ec2's arm64 VMs support nested KVM, or grab a ThunderX machine from Scaleway and run KVM over there.

The arm port works.

On which branch? Go 1.14 only or even master? (And the fact that we even have to ask is a ridiculous situation to be in.)

The arm port works.

On which branch? Go 1.14 only or even master? (And the fact that we even have to ask is a ridiculous situation to be in.)

Haven't looked at git master in sometime. Could give it a whirl I suppose.

But in case not, @rozmansi and I can probably help getting the QEMU setup via TCG running smoothly in gcloud like the current set of builders.

Go is moving towards having all its arm & arm64 builders on Amazon. EC2 has nice ARM instance types nowadays.

If you can get windows/arm and windows/arm64 booting in qemu[/kvm] there, that'd be great. Then it's just a question of Windows licensing, which perhaps @jstarks et al could help with.

This sounds promising. I'll check on what options are available and if there are licensing implications.

@rozmansi's overall setup works pretty well for me. EC2 doesn't pass down the vmx bit, but TCG really is fast enough for testing things.

I submitted a stack of CLs to add cgo support to windows/arm64 on Friday evening, ending at b8fed48. With those, I believe the windows/arm64 support for Go 1.17 is completed.

Closing this issue.

Change https://golang.org/cl/314430 mentions this issue: dashboard: add compile-only TryBot coverage for windows/arm64 port

I submitted a stack of CLs to add cgo support to windows/arm64 on Friday evening, ending at b8fed48. With those, I believe the windows/arm64 support for Go 1.17 is completed.

Closing this issue.

That's terrific. Thanks for working on that. I'll make a note to test that out in the coming weeks.

Any plans on doing the same for windows/arm? Then there'd be fully deployable capacity across all Windows platforms.

Change https://golang.org/cl/344069 mentions this issue: internal/dl: change GOARCH=arm64 pretty string from ARMv8 to ARM64

Change https://golang.org/cl/344070 mentions this issue: internal/dl: highlight Windows ARM64 installer

Hi,

I have been working with MSYS2 on getting packages there built for Windows on ARM64 (using clang's mingw-w64 target like llvm-mingw does). I am curious if it would be possible to 'bootstrap' an ARM64 package of Go there (and/or if I can contribute to making that work, though I have 0 experience with Go).

Also, I am very interested in what options/licensing you figured out for Windows ARM64. We are currently using a QC710 to build, but I have been trying to figure out some sort of cloud hosting situation...

I am curious if it would be possible to 'bootstrap' an ARM64 package of Go there (and/or if I can contribute to making that work, though I have 0 experience with Go).

Amazingly, it Just Worked. I'm used to having to fight packages much more to get them to build 😀

git clone @ github.com/mh-cbon/go-msi

go mod init github.com/mh-cbon/go-msi && go mod tidy && gox -osarch="windows/arm64"

can build on stock win11 ... go-msi_windows_arm64.exe is produced.

point being might be able to msi/msix an installer as well ..