Windows RT is BACK!!! (sort of)

[Windows OS]

Microsoft has just released a video showcasing a Windows 10 Enterprise build running on a QUALCOMM SNAPDRAGON processor. That's right. An ARM chip, not x86. Plus, Microsoft also fixed one of the reasons why Windows RT failed. In this video, Microsoft showcased Photoshop CC and Word 2016, two x86 DESKTOP applications running on ARM Windows 10 via emulation (thus confirming the x86 emulation rumers). So, you could count this as the return of Windows RT.

https://www.youtube.com/watch?v=A_GlGglbu1U

[Goldfish64]

Now that is interesting. Would be nice if that is what Windows RT devices got, but I doubt the Tegra 3 and 4 can show that kind of performance.

[ovctvct]

Not sure if anyone noticed, but it says 64 bit, so it's ARM64. Maybe ARM could replace x86 this way...

[The Distractor]

yes, this is ARM64 Enterprise NT.

I didn't think this would actually have a client compile, everything I saw pointed to Server only!

[sparcdr]

Interesting bit about the emulation since Windows on ARM via emulation is reportedly 5x slower than native, as suggested by a site I forgot to keep the URL for being effectively between a 66MHz 486DX/4 and 133MHz Pentium w/ MMX in regards to DOSBox on this architecture. This is pretty typical of emulators which are capable of dynamic recompilation on the same host CPU, whereas cross-emulation of alien architectures such as OS X 10.3 or 10.4 on IBM PowerPC via PearPC on x86 (Arguably hasn't been updated for current technology), OpenVMS or DIGITAL UNIX on Alpha AXP via ES40, Linux 2.6.23 on SPARC V8 via Qemu or ARM 32-bit (V6/V7 NEON) via Google's own Android emulator suffer a more severe penalty of up to 30x slower due to TLB cache misses, cache contention/locking aspects and for the obvious lack of CPU-level assists such as VT-D. Google uses a lot of Qemu technology in its Android emulator, which should be pretty obvious to anyone using their tools. I remember reading Linux KVM has only recently added support for PowerPC acceleration, but again only if the host CPU supports it.

I am often disappointed that it has been so long as of the days such as the like of the SuperFX, but there has been in recent more are efforts in the field of VLSI to simulate architectures with better performance due to simplicity of their designs. Homebrew NES (MOS 6502) is still very much a thing. These sort of efforts would likely become the assists I speak of, albeit a separate module since focus of the ARM cores is/has been thermal dissipation without active cooling and work on the memory controllers, among other more central (and important) themes. I argue that no amount of software, regardless of the complexity is enough to make such a notion workable.

This is still very much a research toy by Microsoft since the more affordable hardware options haven't caught up. No one expects an Rpi1/2 or Banana Pro (Rev 1) to run Windows correctly or well (Rpi2 being the only supported of all) and no amount of stripping down has so far changed that much; possibly with the exception of Windows Server Core which Microsoft Research claims is 93% smaller, and ~86% less vulnerable (As in unaffected by security advisories so far) which has been changing this reality over the last two server releases. Windows 10 IOT is still too bloated in the sense swap is not a panacea and should be avoided at all costs on embedded platforms, but without paging running anything on Windows on ARM seems rather limited anyways. Slackware on ARM for me uses ~40MB for example with 2 TTYs (1 UART, 1 CONS), OpenSSH Cron, and Syslogd and I have done kernel configurations in the past for SPARC32/64, PPC, IA32 and AMD64 so I know it can be better if all the core is thrown out for ulibc, busybox, etc. I get the same results with Gentoo on AXP (AlphaStation XP1000) ~40MB total usage without any swap used and the same core set of services. The last Windows that was this small was 95 and NT 3.51, 16 years ago; when a 1GB disk cost an average of $360 and the common amount of RAM installed by an OEM was 16MB.

Someone (Or a team) had to trace the syscalls and repeat some automated process to aggregate information indicating which modules were being called frequently so they could optimize them in this context; something akin to Superfetch for dynamic translation had to be done to make this at all usable since most ARM systems as a whole lacks "simple" things such as RTC on-chip, "complex MMU", etc. employing software hacks which workaround limitations of the hardware and things that arguably break the technical specifications at the cost of the sanity of each respective engineer.

This is reminiscent of the challenge faced with Apple while Steve Jobs was away when Bluebox and Yellowbox technology had to translate Motorola 68K syscalls to PPC as they slowly and not completely replaced more code with C just before OS X via Rhapsody was mature enough to spell out the final nail in the OS 9 coffin. The differences in chips then were a similar problem due to CISC vs RISC and endianness (X86 being CISC, and ARM being RISC; while MIPS could do both Small and Big in either bytemode if the firmware allowed it). Many chips bourne of the late 70's through 80's including the heavy hitters lacked proper MMU as has been talked about since the first Linux releases circa 1993; whilst FreeBSD (Then NetBSD, etc.) was one of the only that had the lineage which allowed for it to work without a major engineering effort due to such limitations as suggested.

NetBSD continued supporting dozens of architectures including the Amiga and Atari and remains to this day probably the only modern system capable of running on such hardware due to lack of interest, scarcity, and expense of hardware due to said scarcity. The only saving grace for these platforms was that BSD UNIX by way of its original System V roots came paging and at that very moment in time was actually touted as a feature; something we take for granted and most don't realize was necessary due to the cost of disks vs memory being cheaper as still rings true today, but even more prohibitively obvious. Other operating systems ditched supporting architectures without hardware facilities that allowed such a thing hence why Linux required 386 from the beginning, which it supported up until/about 2010 as a target.

NASA and the ESA still use 486 hardware due to micro gravitational artifacts being more of a problem for semiconductors that are less than 1 micron (1000nm) process, or Pentium and onwards (Down to 14nm on GPUs, 12nm CNY CPU). These systems are headless, controlled via serial, have no central bus in the way we may think of it, but are engineered for a specific set of tasks which don't necessitate the need to crunch 115,000 MIPS (Xeon E5) when < 100 will do. For many years ISVs have thrown around the idea to compute everything in the cloud to abstract the complexity of emulation from the device, such as with the Chromebook for example; given its comparable hardware limits. As long as there is more than 1 architecture remaining, the need to emulate will exist, and the situation has gotten better since Intel VT and AMD-V were released a decade ago. The CPUs have gotten smaller and the TDP hasn't gotten worse, but we're running out of shrink to work with as we approach the 5nm barrier where quantum tunneling occurs. (Ie inability to regulate current in a predicable manner)

I envision a future devoid of privacy where all major computation is done centrally; a throw-back to the heyday of Main-frames but a much more dystopian and Orwellian existence indeed. We will have commodity quantum computing by 2030 and it will be at this point such a thing as a laptop will cease to be a real thing. We're done with silicon, the most abundant resource in our solar system, but will still need to make chips, which begs the need for specialized cooling and distribution, which requires central computing again. But hey, by then maybe as global citizens we'll have awesome internet at that price since it'll be essential.

Windows RT never took off as Microsoft had hoped due in part to excessive disk space usage when 32GB and 64GB flash was still prohibitively expensive. Samsung announced 16TB enterprise SSD drives using 3D V-NAND would possibly be released in 2018 for a few grand. 960GB SSDs are available, but the form factors of larger drives of both traditional and digitally magnetic types narrow the choices available for OTG powered devices with a 2.1 ampere limit such as most Pis, with the exception perhaps of the ODROID C4. RAM has and is still a big issue for ARM, but is still much worse for those with some notion Windows would be a good idea, including Microsoft. The hardware needs to catch up and the prices can't remain near zero forever to archive this.

For a fun read check out Jamulator (NES) re static cross-recompilation of 6502 instructions to x86 (binary->source->binary) using LLVM and GO.

Windows IOT on RPI1
ExaGear
Unicorn Engine
State of Wine on ARM, et. al
Lifehacker on Retro OS for Pi
RetroPie

[Windows OS]

Now that is interesting. Would be nice if that is what Windows RT devices got, but I doubt the Tegra 3 and 4 can show that kind of performance.

Yeah. While I'm pretty sure that old RT devices will NOT be officially getting this, I wouldn't be surprised that once people get their hands on this, they would be able to get this running on a Surface 2. But, I expect the performance to the less than optimal.

[The Distractor]

Now that is interesting. Would be nice if that is what Windows RT devices got, but I doubt the Tegra 3 and 4 can show that kind of performance.

I wouldn't be surprised that once people get their hands on this, they would be able to get this running on a Surface 2.

Nope. ARM64 is not ARM32.

[sparcdr]

Nope. ARM64 is not ARM32.

A8 cortex is also still considered a high-end embedded CPU. Even the ODROID XU-4 (Which I mistakenly called a C4 or something) is A7 (32-bit) like the Banana Pro (NEON), Orange Pi Plus2 and RPI2. The Odroid-C2 is ARM64 according to Debian's Arm64Port page, among others.

The RPI3 is 64-bit (A8A? Cortex) but as of yet doesn't officially support Windows IoT. According to wikipedia, the A8 proper is still an ARMv7 derivative and its integer model is 64-bit clean, but it isn't a full subset. The A8A is the 64-bit known now as AARCH64 as stated below. Raspberry Pi The A57 is a common SOC that also employs this capability. The userland is still 32-bit as it seems in any case with most systems with the exception of iOS on Apple's A8 variant, though correct me if I'm wrong.

https://en.wikipedia.org/wiki/ARM_architecture#64.2F32-bit_architecture

Announced in October 2011,[7] ARMv8-A (often called ARMv8 while the ARMv8-R is also available) represents a fundamental change to the ARM architecture. It adds an optional 64-bit architecture (e.g. Cortex-A32 is a 32-bit ARMv8-A CPU[100] while most ARMv8-A CPUs support 64-bit, unlike all ARMv8-R), named "AArch64", and the associated new "A64" instruction set. AArch64 provides user-space compatibility with ARMv7-A ISA, the 32-bit architecture, therein referred to as "AArch32" and the old 32-bit instruction set, now named "A32"

AArch64 features
New instruction set, A64
Has 31 general-purpose 64-bit registers.

https://en.wikipedia.org/wiki/ARM_architecture#64-bit_operating_systems

Mobile device operating systems
iOS supports ARMv8-A in iOS 7 and later on 64-bit Apple SoCs.
Android supports ARMv8-A in Android Lollipop (5.0) and later.

Desktop/server operating systems
Support for ARMv8-A was merged into the Linux kernel version 3.7 in late 2012.[111] ARMv8-A is supported by a number of Linux distributions, such as Debian,[112][113] Fedora,[114] openSUSE.[115] Support for ARMv8-A was merged into FreeBSD in late 2014.[116]
Porting to 32- or 64-bit ARM operating systems[edit]
Windows applications recompiled for ARM and linked with Winelib – from the Wine project can run on 32-bit or 64-bit ARM in Linux (or FreeBSD or other compatible enough operating systems).[117][118] x86 binaries, e.g. when not specially compiled for ARM, have been demonstrated on ARM using QEMU with Wine (on Linux, macOS and more), but do not work at full speed or same capability as with Winelib.

More helpful with taking guesses at what will invariably work besides the announced Snapdragon can be drawn from conclusions made from glancing at https://en.wikipedia.org/wiki/Comparison_of_single-board_computers Note the RPI3 Model B is still stuck in the dark ages with 1GB of RAM. (LPDDR3 I believe, hence the scant amount) Linux images commonly targeting ARM of current is typically configured "3/1GB split", with anonymous memory (paging/swap), highmem (Load high / LAA) enabled, but not PAE which would counteract some of the 32-bit userland limits more as a stop-gap if it weren't for errata.

Windows in 32-bit is much the same on ARM, with the exception that the "512MB hole" that was never corrected in full due to BIOS implementation bugs as Microsoft likes to point only affects the x86 platform. The Windows IoT hardware support subset is much more specific since the RPI2 is the only supported model of all, and this is probably due to Microsoft forgetting how to "play nice" with non-x86 architectures after dropping PowerPC (NT 4.0 SP1), MIPS (NT 4.0 SP3?), Alpha (2000 Beta 3), then finally IA64 (2008 R2) becoming quite complacent in its inner workings. It had to keep it simple to see if it would work, so it chose the most commonly available model to port to, using a lot of its work with RT in the process.

Server essentials / core requires 512mb of ram not including much interface of all, which is a reasonable baseline to assume is the same for the ARM port, making the desktop experience mode which requires 2GB par official system requirements a non-option. The Up-Board is the only mass produced embedded system that offers 4GB of RAM, and it is based on the now discontinued Atom architecture which is x86. Microsoft has made strides with the Surface at the cost of the iPad and iPad Pro due to it using a commodity i5 x86 chip, but I have no doubt Microsoft will provide an ARM option once it feels more confident in providing support for more platforms. That may be the only saving grace at the cost of the bumbled Nokia acquisition since the S60 / Symbian platform last supported the 808 PureView, which used a 1.3GHz ARM11 processor from TI, suggesting Microsoft retained talent and repurposed it elsewhere such as the Windows core division for this inevitable result, albeit delayed a few years.

Microsoft's colourful history with non-x86 architectures is subject of the history books. Under settlement with DIGITAL over OpenVMS intellectual property cross-licensing that came as a result of Cutler's NT under Microsoft's Research Division, Microsoft kept the upper hand by refusing to provide internally developed tooling (Visual Studio) and productivity software (Office) for the Alpha processor. The PowerPC port was cancelled some 2 weeks after it was completed, and never gained traction partly due to differences of PREP and ARC in the midst of the Apple clone wars of the 90's. The MIPS port was never really a thing, despite the agreement with SGI since it was limited to the low-end, though OpenGL was one of the surviving fruits of this deal.

All of these architectures lost because they had no useful software, and that was very much intentional since Microsoft has been accused and under investigation a few times due to bundling deals with OEMs and the "coincidental" fact most used Intel, rather than AMD as made on record when Intel had to pay AMD for abusing its dominant role in this scheme, implicating Microsoft in the process and then leading to the DOJ investigation and paltry 8 million dollar Sherman Antitrust fine decided in 1999/2000; followed by the EU ruling and much larger 0.6B EUR fine against Microsoft in 2007. Let's hope the situation is better fast-forward 20 years under the stewardship of Satya Nadella who has made faithful gestures to the open-source community by employing teams of engineers to provide as such with Hyper-V guest support (Arguably by force, in regards to GPL and drivers), .NET Core and Docker integration (As of 2016) for instance.

RISC has been a mainstay since the SPARC in the Sun-4 had its own modest success due to simplicity in design and a high compute/clockcycle versus traditional CISC models such as VAX/VMS, CDC still in use at the time (1989). "Moore's law" coined in the 60's is and has been slowing to 2 1/2 years instead of every year, though it's amazing a whim would had been so true for 40 years. x86 has only continued to get more complex, adding RISC characteristics over the years to try and squeeze more performance out of the chips, whilst pumping billions to compensate for a bad design and that can't help Intel much longer. Microsoft is still very much a software company, and they have adapted in the past, but something's got to give in terms of price/performance cost to the end-user or sacrifices made in software, the later is something they don't seem capable of doing anymore unless you consider 60 billion lines of code with obscenities written throughout a success. In other news, Facebook claims it has surpassed Windows 7 in terms of KSLOC!

[Bob Pony]

I can kinda predict that Windows RT 10 might happen for Windows RT 8.1 tablets that have an ARM processor (e.g., Surface 1st gen Tablets).

[Wheatley]

I can kinda predict that Windows RT 10 might happen for Windows RT 8.1 tablets that have an ARM processor (e.g., Surface 1st gen Tablets).

Nope. ARM64 is not ARM32.

[Splitwirez]

ARM64 is not ARM32.

Two questions...
a) Is it actually confirmed that there isn't going to be an ARM32 version?
b) ...what does all of this mean for the Windows RT 8.1 Update 3 Start Menu?

[Wheatley]

ARM64 is not ARM32.

Two questions...
a) Is it actually confirmed that there isn't going to be an ARM32 version?
b) ...what does all of this mean for the Windows RT 8.1 Update 3 Start Menu?

a) Likelihood of that happening is basically nonexistent. Microsoft isn't going to bring back dead products when they can focus their efforts on something useful, like ARM64.
b) Nothing.

[jimmsta]

It's likely that Microsoft will ultimately bring to market some new devices that run this variant of Windows, likely intending on Server and small business devices. The days of thin clients are back, and having a strong local OS running on low-cost hardware is something that the business sector is looking for. WYSE-branded thin clients are pricey, and tend to not run independent OS's, instead relying on PXE boot. Introducing a thin client that acts as a physical RDP endpoint would be ideal -- and even more so for hosted client systems. I suspect that the future of Microsoft includes more hosted content and deployment of these thin boxes running ARM processors.

From a business perspective, for instance, Office 365 is far better for the money than a full Open License -- I have 60 users where I work, which would cost roughly $40000 USD for a Microsoft Open Volume License. Instead, we pay something like $9000 per year for Office 365, which includes a lot of hosted functionality. It's obvious to me that Microsoft wants more and more business users to move into this form of computing. Bringing back the old mainframe-style system, albeit over the internet, is the logical progression at this point. Now, the logical progression is to replace the endpoints with lower operating cost machines (ARM-based SOCs), with licensing of an OS. In the end, Microsoft still gets their money for the OS license, the licensing fees go hand-in-hand with the SOC developers, and everyone is happy.

I look forward to a future where all the management of users and systems is centralized. Lower cost of systems/clients is the natural progression. Microsoft may have jumped the gun with the original Windows RT devices, but now that the rest of the technology is in-line with this sort of vision, they might be able to proceed without much of a problem.

[MrFreeman]

I look forward to a future where all the management of users and systems is centralized. Lower cost of systems/clients is the natural progression. Microsoft may have jumped the gun with the original Windows RT devices, but now that the rest of the technology is in-line with this sort of vision, they might be able to proceed without much of a problem.

I personally don't. I like having a computer I can call my own.

[ovctvct]

I look forward to a future where all the management of users and systems is centralized. Lower cost of systems/clients is the natural progression. Microsoft may have jumped the gun with the original Windows RT devices, but now that the rest of the technology is in-line with this sort of vision, they might be able to proceed without much of a problem.

I personally don't. I like having a computer I can call my own.

Well, by lower cost of systems, he probably meant ARM CPUs will be also used in desktops/laptops, as they are much cheaper than those x86 CPUs. I personally have no problem if that happens, in fact I hope it does...

[hounsell]

he probably meant ARM CPUs will be also used in desktops/laptops, as they are much cheaper than those x86 CPUs.

Which is only the case now because you're comparing two very different classes of CPU. ARM Mobile CPUs can get reasonably expensive at the high end, and a high-end desktop ARM CPU would surely be not much different from a high-end desktop x86 CPU in terms of cost to make. Indeed, I'm sure in terms of cost-per-performance, modern AMD64 CPUs are probably likely to best the current high-end ARM chips, except at the extreme high end where there's not even a mass-produced ARM chip that can compare.

x86 SoCs can already be had pretty cheap. Cheap enough that other factors will be a greater determining factor in the overall cost.

[MrFreeman]

I look forward to a future where all the management of users and systems is centralized. Lower cost of systems/clients is the natural progression. Microsoft may have jumped the gun with the original Windows RT devices, but now that the rest of the technology is in-line with this sort of vision, they might be able to proceed without much of a problem.

I personally don't. I like having a computer I can call my own.

Well, by lower cost of systems, he probably meant ARM CPUs will be also used in desktops/laptops, as they are much cheaper than those x86 CPUs. I personally have no problem if that happens, in fact I hope it does...

No, the dude was clearly refering to thin clients

[ZhengXiaoAi]

Well,Windows 10 RT?Will it be available for Surface RT/Surface 2 and more RT devices?

[mrpijey]

Since Microsoft has discontinued these devices they surely won't support them anymore with new OS refresh updates.

[BilinSun]

Oh I'm very sad to hear about that.Do you remember why aero was removed in Windows 8?Now paying regard to poor performance of ARM,MS may never bring aero glass back.

[PlasmaPlane]

The x86 emulation is interesting, I doubt it'll be too fast (or reliable) though... Still beats having nothing to run but Windows Store apps, though. (or a few ARM-compiled apps if you jailbreak)

[kni]

Mix up with https://www.betaarchive.com/forum/viewt ... 62&t=36659 and you've got a perfect architecture salad.

Very interested on how x86 emulation will perform. As a backup method for running legacy apps can be fine.