Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Windows Hardware

Microsoft Finally Documents the Limitations of Windows 10 on ARM (thurrott.com) 121

Posted by msmash from the closer-look dept.
For over a year we've been treated to the fantasy that Windows 10 on ARM was the same as Windows 10 on x86. But it's a bit more nuanced than that. Paul Thurrott: 64-bit apps will not work. Yes, Windows 10 on ARM can run Windows desktop applications. But it can only run 32-bit (x86) desktop applications, not 64-bit (x64) applications. (The documentation doesn't note this, but support for x64 apps is planned for a future release.)
Certain classes of apps will not run. Utilities that modify the Windows user interface -- like shell extensions, input method editors (IMEs), assistive technologies, and cloud storage apps -- will not work in Windows 10 on ARM.
It cannot use x86 drivers. While Windows 10 on ARM can run x86 Windows applications, it cannot utilize x86 drivers. Instead, it will require native ARM64 drivers instead. This means that hardware support will be much more limited than is the case with mainstream Windows 10 versions. In other words, it will likely work much like Windows 10 S does today.
No Hyper-V.
Older games and graphics apps may not work. Windows 10 on ARM supports DirectX 9, DirectX 10, DirectX 11, and DirectX 12, but apps/games that target older versions will not work. Apps that require hardware-accelerated OpenGL will also not work.
This discussion has been archived. No new comments can be posted.

Microsoft Finally Documents the Limitations of Windows 10 on ARM More

Microsoft Finally Documents the Limitations of Windows 10 on ARM

Comments Filter:

  • Yawn (Score:1)

    by Anonymous Coward

    'Sounds like a crippled version of Windows (probably some S-like version) on a chip best employed in toasters.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      crippled version of Windows

      Seems redundant.

    • this list is referring to ARM, not the Pentium 4 sir.

    • Re: (Score:1, Troll)

      by Excelcia ( 906188 )

      No idea why this was modded into obscurity, because it's right on the money. Who cares about Windows on ARM? Ok, maybe ARM isn't exactly something I'd only relegate to my toaster, but I can't think of a single ARM device I'd want Windows on. We have successfully stuck Microsoft in its own little chroot jail - it has a niche as a necessary evil for the desktop (and by that I mean laptop desktop), but everything else Microsoft has tried to do has failed miserably for the reason that consumers are for the mo

      • Re: (Score:2)

        by xvan ( 2935999 )
        An ARM chromebook is viable. The same niche could be competed by Microsoft.

        The issue is the public expectations. The same people that blame linux for not running their <token program>, will blame windows for the same thing.
        Somehow, people don't expect their mobile phones be able to do the same as their PCs. The apple phenomenon is seems to suggest that people really don't need their <token programgt;.
        • I donâ(TM)t see how Win10 on ARM fits into a market. MS canâ(TM)t be expecting real photoshop users on this emulation thingy... It canâ(TM)t be cheaper than Chromebooks... itâ(TM)s not gonna be easier to manage/support than a Chromebook. When this ships it will be fun to do a head to head comparison on a Chromebook with Wine and whatever MS ships and see how many windows apps work on each.

  • Pointless (Score:1)

    by Anonymous Coward

    A complicated, overly-limited mess. Another win for Redmond!

    • If those are the only limitations, 99,999% of all legacy Windows software will work on ARM.

      • Re: (Score:2)

        by Z80a ( 971949 )

        The lack of Open GL hurts quite a bit, depending on what you will do.

      • What apps do people actually need/use that they are not already using a web browser for: - specialty printing/scanning software. - VPN software - expensive software with security dongles. - Accessibility software(Braille outputs, screen readers) Most real-world cases I can think of where people are going to want to use a Windows app are likely to not work.

  • Impossible! (Score:3, Insightful)

    by Anonymous Coward on Monday February 19, 2018 @06:08PM (#56154764)

    The ARM port can't run x86 drivers?

    Say it isn't so!

    That Slashdot has completely hit rock bottom...

    • yeah that particular item belongs in the "no shit Sherlock" bucket. The only real negative on the list was the lack of 64 bit apps, but that appears to be in the works. Apart from that it is actually pretty good situation for a completely different hardware architecture, especially if they fix the 64 bit app support

    • Re: (Score:2)

      by novakyu ( 636495 )

      Next bombshell will be PowerPC distribution of Debian is not binary-compatible with x86 distribution.

    • If you're going to publish the complete list of limitations, you publish the complete list. Whether or not they are obvious to a technical reader.

  • Well darn. I was hoping to run VirtualBox on it so it could run Windows programs.

  • That's nice (Score:1)

    by Anonymous Coward

    But when can I get an ARM-based desktop anyway? I already have a toaster.

  • Looks like they've put their work in really.

    Lack of x64 is an issue, but I do wonder how you'd have any chance of running drivers for a whole different processor in any meaningful way. Even multiple quite old versions of DirectX.

    • With MS Office, at least, I believe it’s Microsoft’s guidance even on x86 to use the 32-bit version unless you have a specific need for 64-bit. So it’s not like there’s a functional difference in that use case.

  • 64 Bit Support is Unlikely (Score:4, Interesting)

    by nateman1352 ( 971364 ) on Monday February 19, 2018 @06:23PM (#56154822)
    I would be surprised if X64 support ever sees the light of day. I'm sure both Intel and AMD have many patents that make implementation of X64 emulators impossible without running afowl and infringing. AMD might be willing to license to MSFT but given Intel's post [intel.com], Intel is definitely not and is ready to sue. They are lucky that the 386 and older are not patented, that the only reason 32 bit support is possible. The patents start at MMX.

    • Re: (Score:2)

      by MobyDisk ( 75490 )

      Microsoft already has several of their own x86 emulators. There was the old Microsoft Virtual PC app, then the server edition after that, plus their Azure stuff.

    • Re: (Score:2)

      by Kjella ( 173770 )

      They are lucky that the 386 and older are not patented, that the only reason 32 bit support is possible. The patents start at MMX.

      I think they would be expired. "In the United States, for utility patents filed on or after June 8, 1995, the term of the patent is 20 years from the earliest filing date of the application on which the patent was granted" and from I can tell MMX was 1997. The x86-64 specification was published in August 2000 and makes use of SSE2 instructions. So there's at most 2.5 years left of any patents, it's approaching that time where Microsoft can secure the bulk of that IP from AMD, launch a product, probably get

      • Intel have a handy graph of when each SIMD instruction set was patented here

        https://newsroom.intel.com/edi... [intel.com]

        MMX is 1996
        SSE is 1999
        SSE2 is 2001
        SSE3 is 2004

        and so on

        The original x64 specification made support for SSE and SSE2 [wikipedia.org] mandatory, but of course some applications might require later versions.

        It's pretty clear that Intel are saying that if you write an emulator to run patented SIMD instructions on non Intel hardware and don't have a patent license, they may sue.

        x64 is a nice pragmatically designed extens

        • I wonder what the patent covers though. JIT compilation may well avoid this; and it would result in faster code.

          • It's not 'a patent'. The Intel graph shows loads of patents on each instruction set - 1600 over 13 instruction set extensions or about 123 average for each one.

            They claim around 400 patents for MMX, SSE and SSE2, though most of these are for SSE and SSE2.

            And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.

            • And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.

              There is some awful case law from a MIPS lawsuit that lends some weight to this. MIPS patented a pair of instructions to do unaligned loads and stores more efficiently than doing a shift-and-mask. A competitor created a MIPS-compatible CPU that trapped on these instructions and emulated them in software. MIPS claimed that this violated their patent and, in a shocking lack of judgement, the court agreed with them.

              • Yeah. Lexra got screwed

                http://probell.com/lexra/ [probell.com]

                Though you can not patent an instruction set, you can patent machines and methods that are necessary to implement a particular unusual instruction that is part of the instruction set. That legally blocks competitors from creating a fully compatible clone of your processor. There are four instructions in the MIPS-I instruction set that were protected by one US patent, 4,814,976. These instructions, lwl, lwr, swl, and swr are known as the unaligned load and store instructions. These instructions are useful in systems in which memory is scarce. In such systems, it is often useful to pack 16-bit or 32-bit data values in to memory in such a way that they are aligned to arbitrary byte boundaries, and not necessarily to natural 16-bit half-word or 32-bit word boundaries. Accessing such unaligned variables requires at least two bus clock cycles, whereas accesses to aligned data can be performed in a single cycle. Most assembly programmers and compilers for modern systems align data to their natural address boundaries in order to gain the system bus performance benefit of aligned loads and stores, and so they never use the lwl, lwr, swl, and swr instructions.

                Prudent high tech companies study their competitors' patent portfolios, and Lexra was no exception. Lexra was well aware of the patent on unaligned loads and stores that was owned by MIPS Computers Systems, then by Silicon Graphics, and later by MIPS Technologies. To avoid infringing, Lexra chose not to implement unaligned loads and stores in its processor design.

                When MIPS filed its S-1 IPO prospectus form in 1998 it sued Lexra for copyright infringement. The suit was settled after a few months with Lexra agreeing not to use MIPS trademarks without attribution and to state in its documentation and in its public statements that it implemented "the MIPS-I instruction set except for unaligned loads and stores". MIPS Technologies agreed to the settlement, apparently acknowledging that Lexra did not execute unaligned loads and stores.

                If a Lexra processor encountered an unaligned load or store instruction in a program then it did the same thing that it would do for any other invalid opcode, it took a reserved instruction exception. In the second lawsuit between MIPS Technologies and Lexra, filed November 1999, MIPS Technologies claimed that because exception handler software could be written to emulate the function of unaligned load and store hardware, using many other instructions, Lexra's processors infringed the patent. Upon learning of this broad interpretation of the patent, Lexra requested that the US Patent and Trademark office (USPTO) reexamine whether the patent was novel when granted. Almost every microprocessor ever designed can emulate the functionality of unaligned loads and stores in software. MIPS Technologies did not invent that. By any reasonable interpretation of the MIPS Technologies' patent, Lexra did not infringe. In mid-2001 Lexra received a preliminary ruling from the USPTO that key claims in the unaligned load and store patent were invalid because of prior art in an IBM CISC patent. However, MIPS Technologies appealed the USPTO ruling and, in the mean time, won a favorably broad interpretation of the language of the patent from a judge. That forced Lexra into a settlement that included dropping the reexamination request before MIPS Technologies might have lost its appeal.

                It was never determined that processors that execute the MIPS-I instruction set, but treat unaligned loads and stores as reserved instructions, infringed the '976 patent. The patent expired on December 23, 2006 at which point it became legal for anybody to implement the complete MIPS-I instruction set, including unaligned loads and stores.

                Extremetech mused on the case and came up with the tech industry analyst equivalent of 'it's a game of two halves mate. It could go either way'.

                https://www.extremetech.com/co... [extremetech.com]

                The short answer is, we don't know. The long answer is, it'll depend on exactly what kind of patents Intel has on its own SIMD extensions. If it holds patents that specifies how to emulate SSE/SSE2, rather than just the instruction sets themselves, Microsoft and Qualcomm could well be found to violate them. Then again, this also wouldn't be the first time Intel slammed down its foot in a tough-talk display that ultimately came to naught. When AMD announced it would spin off GlobalFoundries, Intel initially argued that the deal might run afoul of its own agreements with AMD regarding the use of that company's x86 license. In the end, nothing came of those claims, and GF was spun off while continuing to manufacture x86 chips for AMD.

                On the other hand they don't need to win in court to win in business, rather in the way that football hooligans don't need their team to win on the pitch to beat seven shades of shit out of the opposing fans in the terraces, or in a sidestreet on the way back to the train station.

                But look at things from Intel's perspective: Its tactics in the early 1990s and mid-2000s substantially limited AMD's addressable market share. It may have paid a whopping $1.4 billion fine to the EU to settle antitrust claims, but that's peanuts compared with the threat Athlon 64 might have represented to Prescott and Smithfield. And Intel isn't wrong when it talks about the myriad other companies that used to hold x86 licenses (or tried to emulate the ISA), but withered on the vine after their attempts to compete with Santa Clara failed.

                The problem is this: System OEMs like Dell, HP, and Asus aren't in the business of taking chances. When your net margin on hardware is in the 2-4 percent range, you can't afford bravery. Imagine a hypothetical future in which HP shipped a Qualcomm Snapdragon 835 that could run x86 code via emulation, only to be named as a party to a hypothetical lawsuit in which Intel sues Qualcomm and Microsoft for their emulation system. Unless one of its two partners agrees to indemnify it, there's no way HP would risk a serious lawsuit over the topic.

                Asus, Dell, Acer - all of these companies are likely to see the situation similarly. The specter of these kinds of lawsuits has always loomed large over the computer industry. I wouldn't blame them for Transmeta's problems; Transmeta's code-morphing approach and Efficeon architecture were initially innovative, but performance wasn't strong and Intel quickly moved to address its own power weaknesses through the Pentium M and the development of technologies like SpeedStep.

                On the other hand, Intel's threats of lawsuits over VIA Technologies' lack of a P4 bus license were the direct cause of the collapse of VIA's P4 motherboard market share. VIA's DDR P4 chipset was a fast and affordable option when the P4 was stuck between either SDR RAM (which badly crippled the CPU) and extremely expensive RDRAM. Intel wouldn't launch its own DDR chipset for the P4 for more than a year after VIA launched its own. But lawsuit threats and licensing disagreements ensured VIA's addressable market was minimal.

  • Now that's an interesting predicament, what kind of shenanigans is going on under the hood there MS..

  • I don't think any of this is a surprise (Score:3)

    by holophrastic ( 221104 ) on Monday February 19, 2018 @06:43PM (#56154888)

    So, with different hardware, anything that relies on non-ARM hardware drivers can't. Seems logical.

    Also, since it's windows10, and not windows7, older graphics requires aren't there.

    Again, seems logical. I'm guessing that the windows user interface has been re-built, and probably lacks a whole lot of backwards compatibility. Given that ARM devices are likely performance restricted by comparison, it's no surprise to me that there's little or no access to any ARM-specialized user interfaces (i.e. all of them). Not really disappointing, but a limitation for sure.

    64-bit apps is obviously a momentary restriction -- it won't last long. That's simply proof that the project began before wide-spread 64-bit ARM adoption. It'll follow suit in short order.

    HyperV, I'm sure, is similarly a few generations ahead of the windows ARM project. I'd bet that adoption of windows on ARM will dictate whether or not HyperV gets brought in at all. And reasonably so.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      I've been evaluating Windows 10 IoT Core, their current Windows-on-ARM offering that is replacing Windows CE. It's total crap, like Windows CE before it.

      Microsoft can't make good operating systems for ARM and non-desktop platforms. I don't know why, they just can't. You download the test Win 10 IoT image for Raspberry Pi and it doesn't have a soft keyboard installed, or any demo apps, or any way to actually evaluate it without huge effort. Microsoft are just terrible at this.

      So I'm not expecting Windows 10

    • The first generation of Windows on ARM computers, the connected computers with cellular modems built in, won't have enough RAM for HyperV to be very useful. Nor does anybody expect people to use them in ways where it would be useful, given their performance limitations. If the concept gets enough market traction to get continued at all, HyperV will be added in time for use on systems that can actually take advantage of it.

  • Windows on ARM wasn't meant to be parallel to x86 (Score:5, Insightful)

    by Solandri ( 704621 ) on Monday February 19, 2018 @06:47PM (#56154902)
    You have to bear in mind what was going on when Windows on ARM came out. The PC market was shrinking, while the mobile market was exploding (both phones and tablets). Intel processors still concentrated mostly on performance, not low power consumption. So everything on mobile used ARM processors. As a result, nobody knew if mobile was just a fad, or if Intel was doomed as ARM ate into its share of the processor market.

    Windows on ARM was Microsoft's hedge against the latter scenario. If Intel imploded, it wouldn't take their Windows franchise with it. The possibility of losing their biggest software platform to ARM also put enormous pressure on Intel to reduce the power consumption of the CPUs. Which they did, and as a result current Intel quad core laptops have just a 15W TDP and can run circles around ARM devices.

    Microsoft never intended to sell Windows for x86 and Windows for ARM beside each other. It was an either/or hedge based on performance per Watt, and x86 won out. The only reason it's resurfacing again is because laptop prices have been dropping. You can get a decent baseline model for less than $500 now, which used to be a good sale price for an about-to-be-discontinued model a few years ago. As the price drops, something has to give. Most of the hardware has already been pared down to razor-thin margins. The only two remaining pieces of fat left in modern laptop prices are:
    • the Intel processor (frequently $50-$100 of the price, vs about $5-$20 for ARM processors with the same silicon surface area)
    • the OS (about $50 of the price)

    Microsoft isn't gonna give up the OS slice of that pie, so they're gonna wave around Windows on ARM in a threatening manner to see if they can pressure Intel into giving up some of their slice of the pie.

  • If these are the limitations you are willing to accept then you might as well just use Linux with WINE. It'll run more applications than this garbage.

  • No (Score:5, Insightful)

    by theweatherelectric ( 2007596 ) on Monday February 19, 2018 @08:23PM (#56155228)

    For over a year we've been treated to the fantasy that Windows 10 on ARM was the same as Windows 10 on x86.

    No one thought that. Microsoft has been very clear from the outset what Windows 10 on ARM offers.

    64-bit apps will not work.

    Incorrect. 64-bit ARM applications will work, of course. And Microsoft has always said the initial target for x86 emulation was 32-bit applications. That was announced in 2016 [anandtech.com].

    It cannot use x86 drivers.

    Of course it can't. Why would anyone think it would?

  • Not surprising really (Score:4, Insightful)

    by Hal_Porter ( 817932 ) on Monday February 19, 2018 @09:58PM (#56155474)

    Back in the days NT run on Risc it was able to run x86 code, but only 16 bit x86 code. That's because the emulator was in the Windows On Windows (WOW) layer. Back then WOW was a way to run 16 bit code on a 32 bit OS. On an x86 chip it run the node natively. On Risc it used an emulator, which Microsoft had licensed from Insignia Solutions.

    So on a MIPS R4000 machine you ended up with this

    1) You could run Win16 and Dos x86 applications because those run in the WOW layer or in NTVDM, the NT virtual Dos machine
    2) You couldn't run Win32 x86 binaries, you needed native MIPS ones
    3) You couldn't run x86 drivers, you needed native MIPS ones

    The R4000 was 64 bit capable but NT never run in 64 bit mode on it. Though it did on Alpha for while until that was discontinued. 64 bit mode lives on now for x64, ARM64 and maybe Itanium if you ask MS very nicely.

    Now move forward to 64 bit Windows 10. The kernel is 64 bit code. WOW is used to run 32 bit binaries. On x64 it runs 32 bit code x86 code natively. On ARM it uses an emulator. So an ARM64 machine you end up with this

    1) You can run Win32 applications because those run in the WOW layer. There's no NTVDM or support for 16 bit code in 64 bit Windows because that would need WOWOW - Windows on Windows on Windows.
    2) You can't run Win64 x64 binaries, you need native ARM64 ones
    3) You can't run 32 bit drivers, you need native ARM64 ones

    Ironically given how wonderfully quirky ARM32's instruction set was and how Steve Furber reckoned that 'MIPS was clean but the cleanness lead to poor code density which hurt them they competed with us in the embedded world', (I'm paraphrasing a bit, the interview is here [youtube.com]).ARM64 is much more similar to MIPS than it is to ARM32. I.e. no conditional execution, load/store multiple, no free shift with every instruction and no Thumb mode with two byte instructions. RIP Sophie Wilson's wonderfully devious instruction set. Still I can see why they did it - something stripped down like MIPS or ARM64 must be a lot easier to implement as out of order superscalar design than ARM32.

    So the situation with WIndows on ARM is better than Windows RT on 32 bit ARM of course - that had no x86 emulator and actually blocked Win32 ARM binaries from running unless they were signed by Microsoft. This was part of Microsoft's evil plan to move people from Win32 to Windows Store applications.

    What I think will be more of an issue for Windows 10 ARM is performance. A Snapdragon 835 is comparable to an Atom natively but emulation will add some overhead - some benchmarks imply a lot.

    E.g. a Snapdragon 835 running x86 code gets a mere 818 single core score on Geekbench

    https://www.windowslatest.com/... [windowslatest.com]

    That's about half the native performance which around comparable with an Atom. I.e. great for phone but terrible compared to an i5.

    https://www.slashgear.com/asus... [slashgear.com]

    Intel have threatened Microsoft and Qualcomm with a lawsuit if they convert SIMD instructions from SSE or AVX to NEON. So you could run 32 bit Photoshop but the emulator can't support any SIMD instruction set. And you're running on a chip which is more like an Atom than an i5/i7. That's going to suck. You can't run x64 binaries, even though most software is x64 now.

    It'll run something like 7zip or Firefox OK, and those will probably have a native ARM64 binaries too, but if you try to run the x86 version of Photoshop on it the experience will be dreadful.

    Outside of Microsoft everyone ignored the non x86 platforms for NT. There's a fair chance that apart from open source stuff people will ignore Windows on ARM too. It's hard to see Adobe spending much engineering time getting Photoshop to run well on Windows on ARM.

    • Re: (Score:2)

      by Bert64 ( 520050 )

      The only 64bit versions of windows for alpha were development versions that were never released publicly (although it would be interesting if they did release them, just for historical curiosity).

      Although alpha was a 64bit chip, it used backwards compatibility flags in the compiler to get it to appear as a 32bit cpu for nt.

      It could however run 32bit x86 code through emulation... The emulation wasn't all that fast, but alphas were much faster than x86 cpus available at the time so even after the emulation ov

      • NT on Alpha could run 32 bit x86 code because Dec wrote a very clever emulator called FX!32.

        That hooked into NT's process spawning when you tried to run a non native binary and run the code via Dec's FX!32. However it also did profiling. Once it knew which parts of the x86 binary were executed most frequently it would JIT them to native Alpha code.

        At one point the platform which could execute x86 code was an Alpha running it via FX!32's JIT.

      • Re: (Score:2)

        by Dog-Cow ( 21281 )

        You are wrong. I used the Alpha version at my university's computer lab in the mid-90s.

        • The 32 bit port of NT for Alpha was released but the 64 bit one was internal only - they used Alphas until they got Itaniums

          https://technet.microsoft.com/... [microsoft.com]

          A colleague of mine rescued an Alpha AXP machine from a dusty closet. Upon booting up the system, he discovered that it was running a 64-bit version of Windows from early 2000. How is that possible?"

          I happened to have one of these machines in my office then. In its prime, this machine was a force to be reckoned with. It was about the size of a small refrigerator and generated about as much noise as a vacuum cleaner. It contained four-count 'em, four!-Alpha AXP processors, each running at a mind-boggling 400 MHz. It had one gigabyte of RAM and thirteen gigabytes of hard drive space, striped over a dozen fast SCSI drives. This may sound puny today, but back in the 1990s, these Alpha AXP machines were the envy of the block and made you the popular kid at the lunch table.

          In 1999, when Compaq announced it would no longer support Windows on the Alpha AXP, a lot of Alpha AXP systems were suddenly left sitting around Microsoft with no official duties. Some of these machines, however, were pressed into a variety of unofficial duties. I used my Alpha AXP system to index the entire Windows source code. You can imagine how convenient it can be for a programmer to be able to identify all callers of a function in just a few seconds or to locate the source code for a function or dialog box that shows up in a debug trace.

          But even for the simple task of indexing the Windows source code, the Alpha AXP was soon overshadowed by x86-class machines. These were cheaper and faster, they offered more hard disk space, and they had more memory. So for this reason, my machine soon joined its forgotten brethren. It was assumed that the end of support for the Alpha AXP was the end of these machines, but then they were given an opportunity to go out in a blaze of glory, breathing their last breaths in service of the next generation.

          The 64-bit Windows project was already well under way, and of the 64-bit processors under consideration, only the Alpha AXP was actually available in physical form. The Intel Itanium was still under development and ran only in a simulator, and the AMD64 architecture hadn't even been invented yet. As a result, 64-bit Windows was initially developed on the Alpha AXP.

          When Compaq announced that they would no longer support Windows on the Alpha AXP, all these Alpha AXP machines that previously had been used for 32-bit Windows 2000 development and testing got repurposed and began serving a secret life as test machines for a 64-bit operating system that will never ship in that form. The Alpha AXP was merely a proof-of-concept platform.

          The Alpha AXP machines served that role well, giving the 64-bit Windows team real hardware to work with instead of having to run the operating system on an Itanium simulator. (You can imagine how slow that was.) Sure, the Alpha AXP wasn't the final target hardware, but it was a big help. And when physical Itanium CPUs began showing up, the niche filled by the Alpha AXPs vanished, and they were once again retired into dusty closets.

    • Re: (Score:2)

      by Dog-Cow ( 21281 )

      I used the Alpha port of NT, including FX!32 emulation for x86, at my university's lab. It was never popular, but it was available outside of MS.

  • Limited Kudos. (Score:3)

    by jimtheowl ( 4200185 ) on Tuesday February 20, 2018 @01:19AM (#56155882)
    There is next to no chance that I will ever use this, but for those who would, it looks like useful information. You may want to skip to the actual information as the quoted article is as thin as it gets.

    https://docs.microsoft.com/en-... [microsoft.com]

  • Now all they need to do is rename it - how about Windows RT?

  • Pretty obvious to me that that Windows 10 on ARM is not ready.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close