ARM-Based Windows 10 Portable PCs?

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
I can’t be the only one who is excited about the full OS experience on portables that finally have really great battery life, right? I wonder if Microsoft will release an ARM edition of the Surface—like, RT, but actually good?

This is full Windows 10 for PCs, not some stripped down version. It’s Windows 10 Home and Pro, on ARM. And Windows 10 Enterprise, with all the functionality that businesses expect, including domain join. This is Windows RT done right. Even better, Windows 10 on ARM will supply a long-rumored feature: The ability to run 32-bit Win32/x86 desktop applications—Apple iTunes, Adobe Photoshop, Google Chrome, whatever—directly on the system, unchanged. Two major technological changes have made this miracle possible. First, Qualcomm’s System on a Chip (Soc) designs have improved so dramatically in the past four years that their performance rivals that of mainstream Intel Core chipsets for PCs. And even better, Microsoft has developed an emulation technology that allows Win32 applications to launch and run unmodified on ARM-based PCs.
 
Times, they are a changing!

Hope this becomes reality. If amd cant fight Intel then we need someone who can.

Need proof of stagnation in the pc industry? Compare an i5 2400 to an i5 6400. How is it we got that little increase in 4 years? Because there is no reason to push.
 
Not this again. The idea is interesting, but you do understand that performance isn't free, right? Brief bursts of work that give phones relatively long battery life is not the same kind of workload that actually using a PC all day with WiFi or wireless data enabled has. The TDP of higher performing ARM SoCs is roughly in the same range as Intel's Y models, but the ARM SoCs lag in performance. ARM doesn't have magic pixie dust. You want performance, you pay for higher performance through higher power requirements just like on x86.

But for the broader picture, how did OS/2's "better Windows than Windows" work out? :p How did Blackberry's Android app compatibility work out? How about Transmeta? This still requires that consumers adopt ARM-based Windows tablets, when the vibrant software ecosystem on semi-open platforms is on Android, plus it has to compete against Apple's iPad models. Microsoft's insanity loop.

This is a great tactic to get Intel to lower SoC prices to make Y processor models more price competitive, but otherwise is a pointless move heading towards a failure repeat. Why? Because the ARM build of Windows 10 is fine for built in apps, but then loses because the Windows app store sucks, and running "full Windows" applications through emulation is far less power efficient than running native. The class of peripherals that run on ARM Windows 10 is very restricted compared to x86. And who do you cry to when your favorite Windows application doesn't emulate well? Just buy an x86 tablet if you want to run Windows applications.

It will take a Y-class processor and humongous iPad-class battery to get iPad-class battery life. Does anyone want to pay flagship iPad prices to get a limited ARM Windows 10 tablet? Those are the real questions.
 
Last edited:
This is why Intel is shitting themselves and giving us scraps while they try to move forward on the mobile front.
 
But for the broader picture, how did OS/2's "better Windows than Windows" work out?

I always felt like OS/2 would have done better if MS hadn't effectively convinced everyone that Chicago (Win 95) was just around the corner. As I recall, 95 was originally supposed to be out in 94 (instead of late summer 95). It's not that MS didn't know either, because I had a friend beta testing and he said in the first half of 94 "there's no it'll be ready."

ON the other hand, I also seem to recall that OS/2 was not as easy to set up and that Windows in OS/2 seemed slower, But I can't remember if there was a nother version of OS/2 before 95 came out. I had Warp.
 
I always felt like OS/2 would have done better if MS hadn't effectively convinced everyone that Chicago (Win 95) was just around the corner. As I recall, 95 was originally supposed to be out in 94 (instead of late summer 95). It's not that MS didn't know either, because I had a friend beta testing and he said in the first half of 94 "there's no it'll be ready."
That wasn't the problem. Anyone who had a MSDN subscription or worked for a large computer company (I did :p) had been getting regular builds of Chicago, and IIRC development was tracked pretty accurately in news coverage at the time (magazines and industry trades). No, it didn't spring up unexpectedly and unannounced. It went through a long development period with early builds and betas. I still have some of the early and beta build CDs from my own MSDN subscription in a folder somewhere.

The reason OS/2's Windows compatibility went nowhere was because it was limited to Windows 3.0/3.1 compatibility, negotiated when MS and IBM split ways. Later, IBM utilized an existing Windows 95 installation for Windows compatibility. The mistake IBM made was touting Windows compatibility, so few developers made native applications for OS/2 since it could just run the Windows 3.x version and Windows 3.x/95 users could also run the Windows 3.x version. Funny how that mistake seems to repeat itself so often. MS hyping x86 emulation for Windows 10 on ARM would fall into the same trap. :D
 
But for the broader picture, how did OS/2's "better Windows than Windows" work out? :p How did Blackberry's Android app compatibility work out?

It worked out great for BlackBerry android Support in the end. They just switched to android! Lol. :)
 
Last comment was how fast MS Word functions. Will I be able to type faster? The game porrtion was a rotating still shot. I would like to have seen some action happening. Other than the competition and running win10 on small devices can't be bad. On a personal note running the same OS on all my devices isn''t bad. Works for apple. Never hear apple people complain.
 
That wasn't the problem. Anyone who had a MSDN subscription or worked for a large computer company (I did :p) had been getting regular builds of Chicago, and IIRC development was tracked pretty accurately in news coverage at the time (magazines and industry trades). No, it didn't spring up unexpectedly and unannounced. It went through a long development period with early builds and betas. I still have some of the early and beta build CDs from my own MSDN subscription in a folder somewhere.

The reason OS/2's Windows compatibility went nowhere was because it was limited to Windows 3.0/3.1 compatibility, negotiated when MS and IBM split ways. Later, IBM utilized an existing Windows 95 installation for Windows compatibility. The mistake IBM made was touting Windows compatibility, so few developers made native applications for OS/2 since it could just run the Windows 3.x version and Windows 3.x/95 users could also run the Windows 3.x version. Funny how that mistake seems to repeat itself so often. MS hyping x86 emulation for Windows 10 on ARM would fall into the same trap. :D
Actually, I was mistaken. It was originally planed for a late '93 release, not 95. At the time, as i recall, a lot of people essentially felt like it was irrelevant, since Chicago was coming out in a few months. Of course a few months turned into 2 years.

As far as native development for OS/2, I have no direct knowledge, but if I was a developer at that time, I wouldn't have bothered, given that it had no market share. As I recall, it's main selling point was it was more stable (and perhaps each 3.x app ran in it's own memory space...I don't remember anymore.

Explain how x86 emulation on ARM is a trap for MS?
 
  • Like
Reactions: DPI
like this
The beginning of the end of x86.

Yes it will matter to people that they can run emulated software at first.

However whatever issues there is with loosing performance they will likely rapidly disappear as more and more software vendors simply release ARM versions for windows. It will start with stuff like Chrome which google will have zero issue compiling a WinArm version of seeing as they already have it running on ARM under Linux/Android. Like wise for MS own software... if they go so far as creating a ARM powered surface they WILL recompile Word ect.

The true end will be when companies like Adobe compile things like Photoshop. More and more commercial software is delivered digitally and providing people with ARM compiled versions won't be an issue. All that is needed is the stepping stone x86 translator for the first few years. Apple went through the same thing in reverse when they switched to X86 from Power. The osx translation was only important until the herd was on the new system and the software guys caught up.

4-5 years out X86 is going to be for High end workstations and servers. If Intel hasn't already by then they will release their own ARM design... with a bunch of Intel Media/Physics extensions. At that point X86 will die completely as once we get there its only a matter of time before Intel and AMD ARM server chips take over... and performance on the highest end ARM chips will pass the x86 designs. I can't imagine AMD or Intel spending billions continuing to push x86 development if 95% of the devices sold run ARM cores.
 
Last edited:
Actually, I was mistaken. It was originally planed for a late '93 release, not 95.
The "Windows 93" OS had a far more limited scope, and was abandoned in favor of what became Windows 95. That did cause a delay, but it's not like "Windows 93" was late by 2 years. Windows 95 was a far different OS than Windows 93 would have been. In place of Windows 93, MS released 2 things: Windows for Workgroups 3.11 and the Win32s subsystem for Windows 3.1 to prep software developers for the 32-bit transition in Windows 95.

If you are actually interested in what the early Windows 93 concept went through to become Windows 95, here are screenshots of early Chicago builds after the Windows 3.x interface was abandoned. Windows 93 would have used the Windows 3.1 interface, and afaict builds of that were never released outside of MS, underscoring that it was abandoned early in development in favor of something else. http://toastytech.com/guis/indexwindows.html

I'm not sure why you believe people thought Chicago release was imminent, or how that would have hurt OS/2. For the former, that's not how software development works. The early builds were available on higher level MSDN subscriptions, MS held developer conferences covered by the press, and it wasn't a secret what stage Chicago/Windows 95 was in during development. For the latter, even when Windows 95 was released, most people still ran Windows 3.x applications since most Windows applications were still Windows 3.x applications. OS/2 would have been in the same situation of running Windows 3.x applications.

Just to beat the dead horse into the ground, here are the list of articles from back issues of Microsoft Systems Journal: https://www.microsoft.com/msj/backissues86.aspx You'll find the announcement and previews of all released Windows versions in that time period. There is no Windows 93, because it was a concept that was abandoned. However, Chicago/Windows 95 is clearly visible. :D

I would suggest re-reading my earlier posts above to understand that adding a compatibility mode discourages native development, illustrated by a couple of examples. To add another, even MS recognized that problem and killed Project Astoria and Android Bridge in Windows 10. Why? Because MS wanted to encourage native Windows 10 applications and progress would be slowed if Android apps ran on Windows 10. The same applies to a weird ARM version of Windows 10, since x86 applications run on it with x86 emulation.
 
The "Windows 93" OS had a far more limited scope, and was abandoned in favor of what became Windows 95. That did cause a delay, but it's not like "Windows 93" was late by 2 years. Windows 95 was a far different OS than Windows 93 would have been. In place of Windows 93, MS released 2 things: Windows for Workgroups 3.11 and the Win32s subsystem for Windows 3.1 to prep software developers for the 32-bit transition in Windows 95.

If you are actually interested in what the early Windows 93 concept went through to become Windows 95, here are screenshots of early Chicago builds after the Windows 3.x interface was abandoned. Windows 93 would have used the Windows 3.1 interface, and afaict builds of that were never released outside of MS, underscoring that it was abandoned early in development in favor of something else. http://toastytech.com/guis/indexwindows.html

I'm not sure why you believe people thought Chicago release was imminent, or how that would have hurt OS/2. For the former, that's not how software development works. The early builds were available on higher level MSDN subscriptions, MS held developer conferences covered by the press, and it wasn't a secret what stage Chicago/Windows 95 was in during development. For the latter, even when Windows 95 was released, most people still ran Windows 3.x applications since most Windows applications were still Windows 3.x applications. OS/2 would have been in the same situation of running Windows 3.x applications.

Just to beat the dead horse into the ground, here are the list of articles from back issues of Microsoft Systems Journal: https://www.microsoft.com/msj/backissues86.aspx You'll find the announcement and previews of all released Windows versions in that time period. There is no Windows 93, because it was a concept that was abandoned. However, Chicago/Windows 95 is clearly visible. :D

I would suggest re-reading my earlier posts above to understand that adding a compatibility mode discourages native development, illustrated by a couple of examples. To add another, even MS recognized that problem and killed Project Astoria and Android Bridge in Windows 10. Why? Because MS wanted to encourage native Windows 10 applications and progress would be slowed if Android apps ran on Windows 10. The same applies to a weird ARM version of Windows 10, since x86 applications run on it with x86 emulation.
I used Norton Desktop in Win3.11 I never heard of it again after Win 95 came out and have always wondered if MS bought it from Norton. It sure looked like the new Win 95 desktop and worked similar.
 
I used Norton Desktop in Win3.11 I never heard of it again after Win 95 came out and have always wondered if MS bought it from Norton. It sure looked like the new Win 95 desktop and worked similar.
I never liked Windows shells, so I didn't use those, but I don't see any resemblance between Norton Desktop and the Windows 95 interface. https://winworldpc.com/product/norton-desktop/30-for-windows

Windows 95's "desktop" concept was more likely influenced by Macintosh system software and DEC's GEM.
 
How smoothly did the conversion of MacOS and the Mac ecosystem to x86 go?

Windows will be orders of magnitude more difficult due to the myriad hardware out there.
 
How smoothly did the conversion of MacOS and the Mac ecosystem to x86 go?

Windows will be orders of magnitude more difficult due to the myriad hardware out there.

Don't really think drivers are the issue. That is on MS... drivers for hardware shouldn't really care if MS has implemented code to allow things written for x86 to run. That is sort of the point.

Honestly the osx transition was pretty smooth. The only issue was older MacOS software tended to run slower through translation... point is. It all still ran fine. After a couple years it didn't matter anymore software and hardware vendors simply recompiled their software. The translation was only really needed for a year or two at most. For a lot of software that people use everyday right now... those companies already have versions compiled for Linux/Android/Apple on ARM. So I doubt it will be an issue. If MS is serious and starts making surface ARM and lots of these devices start moving, I would be willing to bet 90% of most peoples everyday software and current hardware won't be using the translation stuff anyway.
 
The "Windows 93" OS had a far more limited scope, and was abandoned in favor of what became Windows 95. That did cause a delay, but it's not like "Windows 93" was late by 2 years. Windows 95 was a far different OS than Windows 93 would have been. In place of Windows 93, MS released 2 things: Windows for Workgroups 3.11 and the Win32s subsystem for Windows 3.1 to prep software developers for the 32-bit transition in Windows 95.

If you are actually interested in what the early Windows 93 concept went through to become Windows 95, here are screenshots of early Chicago builds after the Windows 3.x interface was abandoned. Windows 93 would have used the Windows 3.1 interface, and afaict builds of that were never released outside of MS, underscoring that it was abandoned early in development in favor of something else. http://toastytech.com/guis/indexwindows.html

I'm not sure why you believe people thought Chicago release was imminent, or how that would have hurt OS/2. For the former, that's not how software development works. The early builds were available on higher level MSDN subscriptions, MS held developer conferences covered by the press, and it wasn't a secret what stage Chicago/Windows 95 was in during development. For the latter, even when Windows 95 was released, most people still ran Windows 3.x applications since most Windows applications were still Windows 3.x applications. OS/2 would have been in the same situation of running Windows 3.x applications.

Just to beat the dead horse into the ground, here are the list of articles from back issues of Microsoft Systems Journal: https://www.microsoft.com/msj/backissues86.aspx You'll find the announcement and previews of all released Windows versions in that time period. There is no Windows 93, because it was a concept that was abandoned. However, Chicago/Windows 95 is clearly visible. :D

I would suggest re-reading my earlier posts above to understand that adding a compatibility mode discourages native development, illustrated by a couple of examples. To add another, even MS recognized that problem and killed Project Astoria and Android Bridge in Windows 10. Why? Because MS wanted to encourage native Windows 10 applications and progress would be slowed if Android apps ran on Windows 10. The same applies to a weird ARM version of Windows 10, since x86 applications run on it with x86 emulation.
I remember reading it in PC Magazine and/or PC World and I was buying RAM from a friend who was beta testing Chicago and I asked him about it and he said it'd never make the December release. Now if 93 was called Chicago and it was labeled as such, then I guess he could have been a really early tester, but I doubt it. I say beta testing, because it was definitely Chicago and it was definitely in the Summer.

I'll add that I'm not claiming they gave a ship date and missed it. They simply kept saying it's coming around <insert month or quarter> and then it'd get pushed. And that's why I've always felt they were just trying to keep people from trying something else.
 
  • Like
Reactions: Uncle
like this
This is why Intel is shitting themselves and giving us scraps while they try to move forward on the mobile front.

I don't see why they should be worried. You can buy a windows 10 tablet at Microcenter for $60. Full x86 compatibility.

The whole SurfaceRT thing was because everyone thought ARM was the future. Shortly after Intel released low power x86 CPU's (bay trail?) and the idea of ARM went away.

I don't see a need for ARM based general purpose computing anymore.

EDIT: I did own a Surface RT and thought it was great quality.
 
I've personally been waiting for someone to release an ARM processor with an integrated decoder of x86 instructions. As you all (should) know, all modern x86 processors (beginning with Pentium Pro) are not actually x86 CISC based, they are RISC core processors with an x86 decoder built into the chip. It's obviously not the same RISC as with ARM, the micro-ops are different and heavily optimized to execute x86 CISC instructions more efficiently. However this could be done with an ARM processor which would basically get rid of the need for software based emulation as happened with Windows for Itanium and now ARM. Sure it makes sense for the OS to use internal ARM instructions for its own code and then emulate the x86 applications that haven't been compiled for ARM, this is more efficient for the programs that use ARM assembly. But what I want is full hardware-based compatibility for x86 code. Running x86 assembly this way should yield much better performance than with current software based emulators.

This approach would also provide the flexibility of running an x86 OS natively, that's something I personally require. I am not moving to anything other than the current x86 compatible chips with RISC core until the emulated x86 instructions (hardware or software) on ARM (or any other architecture) provide a significant enough performance increase to make a difference for me. Right now emulating x86 on ARM using software is really slow, performance per dollar wise. And there are no ARM binaries for the software I use and it's very likely there will never be such. I'll likely always keep x86 compatible chips around anyway, but if ARM or anything else can emulate my x86 binaries with better performance I can use those. They could add a x86 decoder into the chip and allow you to switch between ARM and x86 either via BIOS or even better allow to run both concurrently as with x86 and x86-64.

Well that went a little further than this topic, but as for what I think about the move by M$ to include an ARM software based emulator in Windows, that's something they should have done the moment they released the first version for ARM. I don't know what they were thinking when they did not do that with the release of Windows RT. So I'm not surprised, however it's not good enough for me as I explained.
 
Last edited:
I think the video might be exaggerating a bit... Video playback is GPU based, many Adobe filters are also GPU accelerated, and most of the software (Edge, Start menu, World of Tanks) are Universal Apps, which are probably ARM binaries. Regardless, Windows running in ARM, and having the option to run legacy x86 software is fantastic.
 
NVIDIA tried to do that.

Until Intel told them not to.

Well VIA was also going to release Isiah II which was supposed to have x86 and ARM compatibility. I don't know what happened with that, I have not heard of anything since 2014, and as far as I know their x86 license expired a few years ago as well. In any case it probably would have been pretty damn slow and meant for embedded designs. They did file this patent though: https://www.google.com/patents/US20120260067

So it would obviously have to come from a company with an x86 license (Intel/AMD/IBM/VIA). Since Intel is very careful not to license that to anyone these days, the most likely company who could do such a thing would be AMD. And with AMD, it's rumored Jim Keller while he was still with them gave more focus to Zen instead of ARM development (both were developed by the same engineering team, not the best strategy), which by itself is definitely a correct decision. I should clarify, I'm not really interested in ARM if it can not provide better performance with x86 instructions than current x86 compatible chips from Intel and AMD.

But in the case that PC's/laptops with ARM chips and Windows suddenly become popular, I think Intel has a very strong interest in developing x86-compatible ARM processors themselves. They have an ARM license as well, and they are going to be fabbing chips for Qualcomm. But AMD has already made an ARM processor, based on Cortex A57, I don't know why they didn't add hardware based x86 translation, they have the license needed, unlike Nvidia.

We could even see a revival of IBM processors if they decided to make an ARM CPU. That seems unlikely.
 
I can’t be the only one who is excited about the full OS experience on portables that finally have really great battery life, right? I wonder if Microsoft will release an ARM edition of the Surface—like, RT, but actually good?

The only bad thing about WoA was the lack of apps and missing x86 compatibility. Both seem to be covered now.
 
Back
Top