Windows 10 on ARM.

As I said, they provide the Rust compiler for the Visual C++ 2017 toolchain (direct download page).

 

But there is no "aarch64-*-windows-msvc" toolchain in there.
Rust seems to have no support for ARM + Windows yet.
I guess you could cross-compile the C++ parts of Firefox from x64 to ARM64 using VS2017, but can the Windows/x64 Rust compiler cross-compile to ARM64?

 

They already have 1) standard library and build toolchain for the Windows platform 2) ARMv7/ARMv8 architecture targets for the compiler. So the package can be built the next moment Mozilla decides to release Firefox for Windows ARM64.

 

But the moment Mozilla decides to release Firefox for Windows ARM64 is also the moment when you don't need to build it yourself anymore.
I guess Mozilla will release Firefox for Windows ARM64 only after the "aarch64-unknown-windows-msvc" toolchain is available, but who knows.

 

Rust is sponsored by the Mozilla Foundation so they are both the largest user and code contributor.

 

https://www.neowin.net/news/qualcom...ct-battery-life-on-arm-pcs-more-than-on-intel

x64 emulation on Windows 10 ARM?

 

x64 emulation is not surprising, but ultra-mobile Windows ARM64 is intended for 'apps', not productivity applications - so don't expect workstation-class performance from either Intel emulation or native ARM code.

If 64-core ARM64-only Qualcom Centriq gets some traction on the server market, desktop 8-16 core variants may appear some day; I still doubt anyone besides the open-source crowd could be bothered to publish Win32 applications for the ARM64 platform, and UWP productivity applications simply do not exist, except for a few HoloLens/Mixed Reality apps...

 

https://www.ultrabookreview.com/19015-asus-novago-impressions/
https://www.anandtech.com/show/12327/the-asus-novago-two-minutes-with-snapdragon-835-and-windows

 

Well, unfortunately these early reports proved incorrect - Windows 10 version 1709 for ARM64 only supports x86 emulation and native ARM64 for Win32, UWP, and .NET applications, but x64 is not supported in any form.

AFAIK 32-bit ARM is only supported for mobile/phone UWP/.NET apps - and suffers from multiple interoperability issues.


It looks like the confusion resulted from a vaguely worded Microsoft PR which promised official support for compiling native ARM64 apps, though compiler tools and SDK has been in developer preview for a couple of years...
https://www.thurrott.com/windows/wi...ws-on-arm-getting-support-for-64-bit-arm-apps

 

Two new ARM64 notebooks have been announced: Samsung Galaxy Book 2, Lenovo Yoga C630. These are based on Snapdragon 850, though performance improvement over current Snapdragon 835 models are modest (and the current models are quite slow with x86 emulation).

Might as well wait for Snapdragon 8150 (previously 855), or Snapdragon 8180 / SDM1000, which should be a proper 15W laptop chip.

 

What is the raison détre for these things? As a normal Windows laptop they are always going to be an impossible sell in my opinion unless ARM performance starts to eclipse Intel in the continuous 10+W range, which I doubt happening any time soon except if Apple gets in the race.

If Microsoft wants to use them as more highly QA'd and cloud centric Microsoft alternatives to Chromebook they can't just keep marketing it as Windows laptops, they need to position it differently ... although it's dangerous to admit what a mess Windows computing is.

 

Well we can't fault QC for trying to compete with honest attempts.

I'm personally drawn by the promise of extended battery life. But I'm more interested in the surface-like 2 in 1s rather than laptops

 

The original slogan was "always connected PC" - i.e. phone-like battery life resulting from a 5 W mobile ARM processor and a built-in LTE modem as primary data link. Obviously that could only work with quite simple UWP apps compiled for native ARM64 platform, as running x86 UWP apps (and Win32 'desktop' applications) under emulation would be quite demanding for the ultra low-power processor.

And since the few remaining Windows developers have been basically ignoring WinRT/UWP, despite decade-long efforts by Microsoft to lure .NET/WPF developers and availability of cross-platform .NET tools like Xamarin, ARM/ARM64 native UWP applications can still be counted by one hand.


As for desktop Win32 apps, so far there is one single ARM64 desktop application I know of, the VLC Media Player alpha 4.0. My D3D12CheckFeatureSupport text console app has an ARM64 build too, and no-one is downloading it.

Even if Win32 developers would care to convert their x86-specific source code to ARM64, processing performance would be a far cry from 15-35 W mobile CPUs from AMD or Intel, not to mention desktop processors. And the base runtime (kernel32.dll) simply was not designed for ultra-lower-power hardware, as it lacks automatic suspend-and-resume which is vital for efficient power management on every existing mobile platform.​

 

How about the suspend resume windows already did (before the latest updates that may delete your data, the new update no longer suspend stuff

You can check which we're suspended using resmon.exe

 

It's not automatic - Win32 processes were never designed to handle forced suspend/resume (beyond OS task scheduling and virtual memory management). Rather on the contrary, running multiple "preemptive multitasking" GUI applications was the key advertising point for 32-bit Windows.

Basically the OS trusts the applications to do the right thing, with little practical means to prevent abuse of CPU time and virtual memory. Background GUI programs are supposed to remain in the running state until terminated by user, though a process could wait on some thread or a system message in a kind of an active sleep mode. Should a program stop responding to system messages, it is expected to be force-terminated by user - resulting in a potential loss of information if the user did not save the data to a file - and restarted from scratch.


While you can manually suspend Win32 processes/threads with Resource Monitor or Process Explorer, in practice this would only work with simple single-threaded applications. Today's programs are often multithreaded, and interprocess synchronisation is quite tricky to properly implement - when an unanticipated race condition occurs, this may result in a deadlock. Try suspending one copy of MicrosoftEdgeCP.exe or Chrome.exe and you would immediately get the entire browser's UI or HTML rendering engine locked, with no guarantee that resuming would bring it to life again.


On the other hand, WinRT/UWP apps like Edge, Cortana/Search, Settings, Photos, Calc etc. are designed for a single-tasked mobile environment where all background apps are first suspended then terminated outright, so the apps are required to handle suspend/resume messages from the OS by saving/restoring current application state and user data in permanent memory - see Windows 10 universal Windows platform (UWP) app lifecycle.