Windows 10 on ARM.

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.
 
DmitryKo said:
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.
Click to expand...
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.
 
https://www.neowin.net/news/qualcom...ct-battery-life-on-arm-pcs-more-than-on-intel
Initially, there were reports that Windows on ARM wouldn't run 64-bit Win32 apps, but when I spoke with Dell regarding why it wasn't doing anything with ARM, I was told that 32-bit apps are the problem.

The answer is that that's all been worked out. If it runs on an Intel chip, it should run on a Qualcomm chip as well. If you're worried about first-gen kinks though, you can always just wait for Snapdragon 845 PCs, which are coming later this year.
Click to expand...
x64 emulation on Windows 10 ARM?
 
Last edited:
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
In gaming, Qualcomm stated that with the modern APIs, the Adreno GPU is natively compiled and doesn’t need translation. As a result, due to the way that Adreno works, for some titles it ends up being more computationally efficient over other solutions and causes less work on the CPU, allowing for more of the power budget on the GPU and an overall better frame rate. Obviously we want to get a hold of the device and test the claim, but if offers an interesting prospect.
Click to expand...
 
Arnold Beckenbauer said:
x64 emulation on Windows 10 ARM?
Click to expand...

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
 
Last edited:
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.​
 
DmitryKo said:
as it lacks automatic suspend-and-resume which is vital for efficient power management on every existing mobile platform.
Click to expand...

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
 
orangpelupa said:
How about the suspend resume windows already did
You can check which were suspended using resmon.exe
Click to expand...

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.
 
Last edited:
OK, so this sounds interesting.

https://www.windowscentral.com/qualcom-snapdragon-8cx

A Qualcomm SOC specifically built for use with Windows 10.

Depending on the price, I'd be interested in it as a future replacement for my HTPC/Server (still running on an i3 2100 with Radeon 5450) here. Supports 4k HDR 120 FPS decode of video and can drive 2x 4K displays (I only need 1 for HTPC use, but 2 is nice. :p).

Regards,
SB
 
To the surprise of absolutely no one, the custom SQ1 with 4x A76 cores at 3GHz emulates win32 applications with terrible performance. Trying to emulate x64 with the same hardware is just begging to go even worse IMO.

Though I guess Microsoft will just keep throwing money at it because being hostage to Intel isn't a nice position to be in.
 
You must log in or register to reply here.

Similar threads

D
3DMark for Windows 8 to unify test suite between ARM and x86 solutions
2 3
Replies
53
Views
18K
Deleted member 13524
D
E
Windows tablets
47 48 49
Replies
967
Views
184K
BRiT
BRiT
J
  • Locked
New news on PS4 and PS3 from Sony
Replies
4
Views
14K
Shifty Geezer
Shifty Geezer
E
Piracy not reason consoles won
5 6 7
Replies
138
Views
21K
assen
A
F
Is the X86 architecture a good option for Next-Gen handhelds? (Microsoft Xboy?)
2
Replies
31
Views
8K
corysama
C
Back
Top