First, let’s talk about the device.

I’ve written about Windows on ARM64-based devices previously, and used a variety of ARM64-based devices from Microsoft and other OEMs that I borrowed for specific testing, validation, etc. But I never actually owned one. So when I saw the opportunity to buy one cheaply on eBay from the Microsoft Store outlet (an “open box” special), I had to do it. I bought one to add to my collection of devices. You never know when you might need to do some ARM64-based work.

The device I purchased was the Samsung Galaxy Book S, a two-pound laptop running the eight-core Qualcomm Snapdragon 8cx processor, retailing at $999 but can be found for less (e.g. on the Samsung website).

It doesn’t have the latest or fastest ARM64 processor, but if you look at the benchmarks it’s still respectable:

Now, given that the SQ1 is clocked slightly faster than the 8cx, you would expect there to be a difference between those two, and single core vs. multiple core tests may show different relative results, so don’t put too much emphasis on the benchmarks themselves. Just consider that the 8cx-based Galaxy Book S will be close to the Surface Pro X, but will lag behind the latest Intel and AMD processors, as well as Apple’s new M1 ARM64 chip released recently in new devices. (Perhaps check out the Windows Central articles on the 8cx perf, as well as Windows running on the M1. And that’s before emulation takes its toll.

Now, let’s talk more about the OS. Out of the box, Windows 10 on ARM64 will run native ARM64 apps and ARM32 apps (most likely older Windows Phone UWP apps), as well as emulated x86 apps; that emulation is not the quickest and impacts battery life as well. But the bigger problem is that so much software has moved from x86 to x64 — all of that x64 software won’t run, at least not yet. Of course I’ve already upgraded the device to the latest Windows 10 ARM64 Insider build, as that has the beginnings of x64 emulation support. That’s likely to ship in the fall as part of the 21H2 release of Windows 10 (not guaranteed, but that’s the next real opportunity; miss that opportunity and we’ll be waiting a long time).

If you don’t use emulation, there are some native ARM64 apps available. A quick rundown:

• Microsoft Edge (Chromium-based): Native ARM64.
• Microsoft Teams: Native ARM64.
• Microsoft Visual Studio Code: Native ARM64.
• Microsoft Visual Studio: Emulated x86.
• Google Chrome: Emulated x64 (yay, the Insider feature works fine).
• Remote Desktop Connection: Native ARM64.
• Microsoft Office (Excel, Word, Outlook, etc.): Emulated x86 (although Outlook says “x86 (ARM64 optimized)” whatever that means).

Overall, the key apps I use (outside of Office) are already native ARM64 (a different situation from when I first used a Windows ARM64 device). The growing x64 support is good too, as I don’t need to rely on x86 app versions any more (at least once all the kinks are worked out and this is released outside of Insider builds). I could easily see myself using this as a “very portable” laptop (compared to my MacBook Pro 16″ that is a little more bulky) when traveling (if we ever do such a thing), for meetings (ditto), or for casual computing. It’s only got 8GB of RAM (which I could easily get to 5-6GB used), so it’s not likely to be a development machine, but using it to connect to a remote workstation via Remote Desktop Connection works well.

Some notes on key features of the device:

• Fingerprint reader. I really like the fingerprint reader on my MacBook Pro: press the button on the top right of the keyboard to wake the computer and authenticate me. Well, the Galaxy Book S works exactly the same way, using Windows Hello for Business (no infrared camera, but the fingerprint reader is a reasonable substitute).
• Touchscreen. I am firmly in the “laptops should have touchscreens” camp. My MacBook Pro doesn’t have one, yet I still try to touch it all the time. No need to worry about that as the Samsung has a touchscreen. I do wish the 13.3″ screen were larger, but that’s more a comment about the state of my eyesight than about the device itself.
• LTE support. The Galaxy Book S that I have came preconfigured for Verizon’s LTE network, but I should be able to use it with a T-Mobile SIM as well. (The mystery here is that Samsung’s specs just say “LTE Cat.18”, which means nothing to me, so determining the LTE bands that it supports, and comparing those to what T-Mobile can deliver, is a non-trivial exercise. Since T-Mobile has sold the Samsung device, I am assuming it will work.) I just don’t happen to have a spare nano SIM laying around, so I’ll try that at a later date (like maybe when we’re traveling again, when I can justify the extra $20 a month for that data-only SIM).
• Secure Boot. Weirdly, the device shipped with Secure Boot disabled. I don’t know if it came from the factory like that, or if it was the result of being an outlet “open box” special. Overall, the firmware settings on the device feel somewhat antiquated, compared to some of the newer GUI-based UEFI hardware settings features.

But what about PowerShell?

I did a blog post about a year ago that talked about PowerShell on ARM64. The quick summary: There was no ARM64 version of PowerShell.exe on the system, just an x86 (emulated) version. So, that’s what you had to use, and there could easily be side effects from that resulting in script failures. Now that the Insider builds have added x64 emulation, does that change? As a matter of fact, it does:

From that picture, you can see in Task Manager that powershell.exe is marked as an ARM64 (x64 compatible) process (kind of like Outlook was previously, but flipped around). Then look at the environment variables on the left-hand side that show the PROCESSOR_ARCHITECTURE is AMD64. So, PowerShell effectively believes it is x64 (AMD64), but it appears to be more of a “hybrid” process — my suspicion is that there is some transparent “thunking” going on to allow simple interactions between x64 and ARM64 code.

Since the process is x64/ARM64, it sees the “normal” registry locations, e.g. HKLM:\Software\Microsoft is the 64-bit registry info, while the HKLM:\Software\WOW6432Node\Microsoft key has the x86 info in it (and as before, there is also an HKLM:\Software\WOWAA32Node for 32-bit ARM processes). There is no WOW6464 key, i.e. an emulated x64 registry key that maps x64 apps separately from ARM64 apps. Going back to my “hybrid” comment, that makes sense. (I would suggest not trying to run both ARM64 and x64 versions of an app on the same system, unless they can happily share a registry key.)

So that’s a good thing: It means that PowerShell scripts that are dependent on x64 modules, and don’t expect to find redirected registry keys on a 64-bit OS, should “just work” in normal situations. (I’m sure someone will find a way to prove me wrong.) IT pros should appreciate this.

What about VBScript?

If you’re still an “old-school” person running VBScripts using cscript.exe or wscript.exe, you’ll notice that those are (and probably have been even prior to the Insider builds) native ARM64 executables. So if you still have logon scripts or startup scripts around, take that into account. (I didn’t try to do anything significant, like having an ARM64 cscript.exe try to load an x64 COM control, but it might actually work now with the Insider support for x64…)

Overall verdict?

For me, this would always be a secondary device, not a primary driver. Windows 10 on ARM64 is certainly progressing to solve some of the app compat issues, and if you’re just running general productivity apps or browsers, you’d probably be happy with the device.

I do wonder when we’ll see a device that is faster overall. Hopefully Qualcomm will come out with a processor that can match the M1. Otherwise, using Parallels on an M1 Mac to run a Windows 10 ARM64 VM (which you can only do using an Insider build because there’s no way to buy a retail copy of Windows 10 for ARM64) might be faster…