This week, however, Microsoft finally published a more complete list of the limitations of Windows 10 on ARM. And that word – limitations – is interesting. This isn’t how Windows 10 on ARM differs from Windows 10 on x86-based systems. It’s how it’s more limited.
None of these things really sound all that surprising to me, but you can bet these limitations – which seem technical in nature, not political – will lead to outcries among some people who buy ARM-based Windows 10 machines.
“Your app uses an OpenGL version later than 1.1 or requires hardware-accelerated OpenGL..” – it’s not political? OpenGL 1.1 – really?
and nothing about Vulkan, but I think they want programmers to use windows-only APIs.
They are not stupid and know that OpenGL 1.1 from 1992 lacks mipmapping/multitexturing and is literally useless, because software from those year will not likely compile in modern compiler, targeted for ARM. They would put Mesa, which supports modern OpenGL revisions, but they put this crap intentionally to complicate development environemnt setup(you have to carefully set to not link against system opengl) to confuse new developers and force them to learn DirectX(instead of OpenGL).
It is technical. Nobody is interested in writing drivers for OpenGL. Maybe you will?
The one purely political limitation, is the SAME ERROR MS is making AGAIN – the lack of ARM Win32 desktop. This is the real showstopper, since a lot of apps need to be converted to UWP, and it could not be possible at all:
UWP apps can request additional capabilities to get a few more rights with permission from the user, but have limited access to the system and user data. For example, you cannot read most of the filesystem, only your installed location, an isolated application data folder, and an isolated temporary file folder.
This will limit the adoption of native apps, making the whole idea not worthy.
MS is aiming to launch doomed on arrival product again, at least for me, as early adopter.
But maybe I’m too nervous about this, and MS is clearly interested in deprecation of old APIs. Time will tell.
Anyway I don’t understand why they are so surprised with a lack of Hyper-V? It is x86 virtualization that requires extemely slow full system emulation. On WoA x86 is emulated in user-level mode.
Edited 2018-02-20 00:08 UTC
This is wrong. The ARM Win32 SDK is coming. Win32 apps will be native on ARM
Ok, that’s fine.
I don’t see that as political. Windows only supports OpenGL 1.1. This hasn’t changed in 20 years.
ATI, Intel, and NVidia support modern versions of OpenGL on their own. Microsoft does not.
There is nothing stopping somebody from releasing modern OpenGL support in Windows, or stopping anybody from using it.
There’s nothing stopping developers all over the world from ignoring some 3rd party effort to bring modern versions of OpenGL to Windows. That’s exactly what would happen.
Edited 2018-02-20 09:03 UTC
That’s not at all what I’m talking about.
I’m saying, nothing stopping Imagination Technologies or NVidia from supporting OpenGL.
You know, the exact same situation it is for Windows on x86.
Actually no, OpenGL is only allowed for desktop apps.
UWP only allows for DirectX, and Microsoft has provided patches to allow Angle to be used on UWP.
OpenGL only matters on the desktop thanks to Apple needing to cater to UNIX devs to take the company out of the red zone.
Now with their bank account filled up, even they are starting to ignore OpenGL, focusing on Metal instead.
So it remains to be seen how much OpenGL or Vulkan, will matter in lets say 10 years from now, specially with all major studios using middleware.
Which doesn’t contradict anything I said.
OpenGL is provided not by Microsoft, but by GPU vendors. This is the case on x86 desktops, this will be the same on ARM laptops.
UWP isn’t mandatory on ARM laptops, either. The Win32 ARM SDK is a thing that exists
Windows on ARM is all about UWP and desktop bridge on Windows Store.
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm
https://channel9.msdn.com/Events/Ch9Live/Windows-Community-Standup/K…
Desktop bridge applications are considered just a stepping stone to port applications into the UWP, as they are not sanboxed as UWP apps are, given that they need to execute with full trust.
https://blogs.msdn.microsoft.com/appconsult/2016/10/13/desktop-bridg…
Edited 2018-02-20 21:28 UTC
…..and? There’s no indication that Win32 will only be allowed for desktop bridge UWP apps.
By all appearances, this is a fully-featured (minus Hyper-V), legit version of Windows.
I guess you didn’t bothered to watch the Channel 9 sessions.
Note that I see this as positive, sandbox all the way.
Edited 2018-02-21 10:31 UTC
Oh, cool then. I tend to skip videos, since I’d much rather read an article (Which takes much less time)
Why does MS bother at all with 1.1, is it useful for anything?
(and will Qualcomm support newer OpenGL on those ARM chips?)
No, not really useful for anything.
But, Microsoft once supported it as an API, which means they’ll support it until the heat death of the universe.
It’s completely false to say that OpenGL 1.1 is useless.
OpenGL 1.1 is still quite useful for prototyping, where shaders, multitexturing, mipmapping, manually managing colors and projections, and creating your own matrices from scratch is just noise.
There are also many 2D applications that use “OpenGL 2” which can actually use OpenGL 1.1
The appellate court issued an emergency stay of incarceration, so at least someone on the legal ladder has some common sense and compassion. I get why the judge in the criminal case was conflicted; there was trademark infringement regarding the labeling of the discs, but IMO Lundgren’s intent was clear. He wanted to give users an option of a physical restore disc where the OEMs no longer offered one for download or the user had no other way of obtaining one, and he wanted to make a few bucks on the side. He felt (and I agree) that the license was not violated because the license was tied to the hardware, not to a restore disc.
Given that the same restore disc could be used for any of the same brand/model PC, but the license key was already in possession of the user and was tied to the user’s machine only, combined with his clear intent, the judge should have dismissed the case.
Then again, I’m basing all of that on the one article, so I probably don’t have all the facts in the case. Still, I’m glad he has an appeal in motion, and it will be interesting to see where this goes. Given Microsoft’s current “Windows as a Service” pivot, I’m surprised they are throwing so much muscle at this case. Some guy distributing restore discs for outdated and unsupported OS versions, if anything, speaks to the resilience of their OS. The users who would have benefited from Mr. Lundgren’s efforts will now see Microsoft as the “big bad guy” who never really changed his bullish ways.
Oops…I have no idea how I posted this in the wrong discussion. Sorry!
Who is this for? Is there people out there asking “Why can’t I run Windows 10 on ARM?” At this stage the only real reason to use Windows is for legacy software, and ARM will have none of that.
Granted, maybe that’s just my opinion, but I see this as another Windows Phone, trying to edge into the cheap educational computer space. I think the thing they don’t understand is that the reason Linux is so popular on things like the Pi is because of it’s open source nature and being able to tweak every little thing.
It is ok for console-only or bare-metal, but full-blown Linux GUI system runs like shit on PI.
Edited 2018-02-20 05:26 UTC
Are you trying to say Windows will run like a charm on Pi?
I heard someone managed to run Windows ARM on RPi. It was limited to 1 core, really slow and crashed after some time.
RPi can handle Linux lightweight GUIs quite well considering it’s limited resources.
I wonder what they were doing there, the only supported version on the Pi is Windows IoT, and it surely does better than Android Things, for example.
In any case, it is designed for IoT deployments, not to be used as a desktop.
Actually I tried to live on R-Pi2 exclusively for some weeks, so I know it quite well
There is no excuse in limited resources. There are tasks that is not suitable for given hardware.
AROS would perform great on R-PI.
Edited 2018-02-20 18:51 UTC
Says who? Almost all the distributions I’ve seen for the Pi have GUIs. They’re for tinkerers and even run emulation quite well (I’ve ran Playstation 1 games on my RetroPi.)
Yes, KDE and Gnome run like crap on them, but they also more or less require some nice 3D acceleration. Try XFCE and a few other lightweight ones, they work fine.
Maybe if you are using something like Raspbian, which is extremely poorly thought out for embedded systems, or if you are running Unity, Gnome, Plasma, etc, which can struggle to perform well on desktop machines.
I use fluxbox and icewm on my first-gen rPi just fine. I’ve also used LXDE without any issues.
This is not going to be a cheap tinkering box. They have Windows IOT for that market, which is quite rightfully ignored by that market
There’s a fairly decent amount of amd64 stuff out there now, though no where near as much as there should be for Windows. So the question is then, if these are going to be beefier ARM processors, are they actually any cheaper than AMD/Intel? So I have to ask again, what market is there for these?
You quoted everything, but then only focus on price again. How did you miss the “At the same time there should be huge battery improvements and always-on connectivity should be included.”
The market that Microsoft is aiming for is “regular people” that need/want to run some Win32 programs (Office, Chrome) that they have always used while at the same time wanting a thinner/lighter/always-on/always-connected/long-battery life laptop. They will spend 400-600 Euro on that laptop just like they did on their previous one. They won’t get a major speed-increase and they won’t be able to run high-end games but they don’t have to wait for their machines to boot, won’t have to worry about bringing a charger to school/work, don’t have to plugin ethernet cables or even use WiFi.
The above is the idea and it sounds like a good idea to me. Question remains if people will buy it or will just use their phone/tablet for consumption and old-fashioned laptops for “work/hobby”
avgalen,
Assuming it is the user’s intention to run x86 apps, I would tend to agree with leech…it’s a hard sell. The x86 on ARM performance has been benchmarked and it is so bad that my slowest dual core computer from 10 years ago matches the ARM’s 8 core benchmark score and blows past the single core scores.
https://www.theregister.co.uk/2017/11/14/window_on_arm_benchmarks/
https://www.slashgear.com/asus-windows-10-on-arm-device-benchmarks-a…
I’ll concede it’s not entirely microsoft’s fault that x86 software market is so difficult to replace and it’s not their fault that software emulation kills performance either. Regardless, the fact is that for x86 workloads this new offering is a major downgrade. I even have to question whether the battery performance will suffer too for workloads under x86 emulation.
Hypothetically if this were like apple jumping all in with a new architecture, then sure I get it, the CPU emulation layer would be a temporary stepping stone to better pastures, after which users would be running natively again. However microsoft is not commiting the way apple did, and so it seems unlikely that major software vendors will commit either. And to the extent that users want to keep using their existing software, windows on ARM is likely going to remain worse for reasons that have nothing at all to do with ARM’s merit as an architecture.
I actually have wanted an ARM laptop for the longest time, but for linux rather than windows because with linux we can always run natively, which obviously makes a huge difference.
Edited 2018-02-21 15:31 UTC
Yes, this is one of the biggest benefits that Open Source has. If a new architecture comes to the market you can “just recompile” and everything runs natively. That is also why the change from x86 to amd64 went by almost unnoticed on Linux while it took ages on Windows. For newer programs that are still maintained this isn’t a problem though. Windows itself and most of its core programs will run natively on ARM and so will most of the Store-Apps. So if you are interested in seeing the performanceloss of the emulation benchmarked you could just run the ARM version of the benchmark compared to the x86 version.
avgalen,
Indeed, we have debated how well this emulation would stack up, so it will prove interesting when more numbers come out.
No, that is simply not true anymore. Most of the commercially supported software is still available in 32 bit because those systems are still in use and even sold. However most of that software is also available in 64 bit versions. The big exception is “Office plugins/extensions” which are based on 16 bit functionality (yes, really) that is available in the 32 bit versions of Office but not on the 64bit versions, hence the recommendation to “run Office in 32 bit unless you require 64bit and don’t depend on old plugins/extensions”.
Visual Studio is the other exception (https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-…)
If I look at all the software we run in our company the only software that is only available in 32bit is some labelwriter program that could easily be replaced if we needed to.
It is precisely those kind of labelwriter programs that x86 emulation is meant for.
Performance is not the thing that I worry about for Windows on ARM. I worry about people that try to run AMD64 programs that won’t work and will confuse those users because “that computer can run some programs but not others”.
avgalen,
Hmm…I believe most users, like me, will find a majority of their 3rd party software is still 32bit. This may not be the most accurate way to find out, but my “program files x86” directory contains 129 items versus only 70 for “program files”. A better way would be to scan the binaries. I believe I reinstalled my computer from scratch in 2016. This would make for an interesting census
Edited 2018-02-22 16:28 UTC
Here is how I tested: Just start up your “20 most used programs”, fire up Task Manager, go to the details tab, enable the platform column and sort by that to see how few 32 bit is running. And like I said, most of those 32 bit programs do have 64 bit versions available. The ones that only have 32 bit versions available are either ancient and unsupported or just wouldn’t benefit from 64bit and would run “good enough” on ARM-x86-emulation for sure.
avgalen,
I know what you are saying, but my personal experience contradicts it and I assure you I always opt for the 64bit version when available. Clearly we need a larger sample size.
Edited 2018-02-23 01:59 UTC
You inspired me.
1. Get sdir (http://www.malsmith.net/sdir)
2. Cd /d “C:\Program Files”
3. Sdir -r -pn -dar -fear=amd64 *.exe
4. Sdir -r -pn -dar -fear=i386 *.exe
5. Cd /d “C:\Program Files (x86)”
6. Sdir -r -pn -dar -fear=amd64 *.exe
7. Sdir -r -pn -dar -fear=i386 *.exe
Those sdir lines translate to “recurse, no pause, display CPU architecture, and exclude those matching the specified architecture.” The result on my machine was a total mess:
\Program Files:
– 184 i386
– 119 amd64
\Program Files (x86):
– 660 i386
– 239 amd64
So I think the conclusion is that the split between these directories has been…ineffective…at categorizing where installers put binaries. Oh, and 29% of the executables in the two are amd64 on my box.
(To think when the first amd64 XP build was released, I got my hands on one and ported all my code to it in April 2005, only to realize there was no point. Talk about jumping the gun.)
malxau,
Indeed, and yet it’s funny how close we were percentage-wise: your 29% to my 35%, haha.
Because in most cases there are hardly any benefits to moving to AMD64. Not so with move to ARM.
zima,
That interesting I guess time will tell if developers will provide native ARM ports.
I have some commercial win32 software contract work experience, and so far there’s been absolutely zero demand for 64bit through my clients, I don’t know that ARM will be any different for them. However I don’t think my experience is necessarily representative, so I am curious about the experiences of others.
My experience is that almost all new development work * is either done in virtual machines like .NET/Java (or similar like Swift/Dalvik) that are basically hardware/OS independent because they don’t touch those lower levels.
* or done in a scripting language (Python/PHP/JavaScript) that also doesn’t care about the hardware/OS it runs on
* or done in languages that could run on other platforms whenever a customer would ask for it (C/C++)
…it is very rare nowadays to work on a program that needs to scale-up to 64bit in order to meet performance requirements. Scaling out to run the same (small) program for hundreds of users at the same time is much more common thanks to websites/apps.
It is either because of marketing (now in a 64bit packaging) or because it has to co-operate with another 64bit program/library that we get a request for 64bit.
“As long as it runs on the intended platform and does what the users want” is all that matters.
(Games/3D/Video are noticable exceptions that are basically 64bit only now, but our company doesn’t work on that normally)
Why would you say that?
If anyone ever doubted that Microsoft, as a whole, do not learn from past mistakes, look no further than this latest attempt to put Windows on ARM. It’s the Surface RT again. I think someone at Microsoft ought to get a dictionary and look up the definition of insanity.
At least someone is on the same page with me here!
How? How is this SurfaceRT again?
Surface RT: Runs only Metro apps, at a time when there are very few if any, and no side loading
Windows 10 ARM: Runs Win32 (x86), Win32 (ARM), and UWP apps when there are tons more available. Plus, sideloading to your heart’s content, and full on Entperise manage
How is this anything like it?
Edited 2018-02-20 19:05 UTC
They see Windows, they see ARM, they write their complaints and feel good?
In addition to all the good points about Application support I would like to add:
RT ran on a much less powerful ARM-CPU
RT ran on Windows 8 which was almost Vista-level rough while Windows 10 is much more refined.
This version of Windows on ARM is explicitely NOT revolutionizing anything and it isn’t breaking any frontiers. It is specifically made to be “the best compromise between all factors of computing that matter to normal people” (yes, I made that up, feel free to quote me)