Slashdot Mirror


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

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.

121 comments

  1. To do list by Anonymous Coward · · Score: 0

    Sounds more like a list of things they need to fix unless they want Windows RT part 2.

    All this will do is encourage use of Win32 over Win64 and the limited UWP.

    1. Re:To do list by MightyMartian · · Score: 1, Insightful

      I imagine the inability of third party cloud storage apps is a "flaw" that won't be fixed any time soon. Sorry Dropbox and google Drive, you're out.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:To do list by ChunderDownunder · · Score: 1

      I wouldn't say there are any particular unexpected showstoppers in that list.

      Hyper-V would need to be replace the underlying hypervisor to support ARM guests. It's not an emulator (?) so would never support running x86 VMs in any case.
      OpenGL will only use whatever level MS and Qualcomm have bothered to support in their driver. Given it's an Android smartphone chipset, Open GL ES and Vulkan are likely better supported.
      x86-64 would be a nice to have but the idea is to get developers releasing arm64 binaries, not rely on emulation indefinitely.

    3. Re:To do list by Daltorak · · Score: 5, Insightful

      I imagine the inability of third party cloud storage apps is a "flaw" that won't be fixed any time soon. Sorry Dropbox and google Drive, you're out.

      No, no, no. It's a technical limitation of emulation, not some kind of insidious plan to block out competition.

      Windows 10 on ARM supports shell extensions just fine -- the vendors have to recompile their applications is all. Nothing Mac OS developers didn't go through during the PPC -> Intel transition twelve years ago.

      Literally anyone who's written shell extensions for Windows Explorer before will already understand the problem: shell extensions are loaded into the same process as Windows Explorer itself. Loading x86 code into a process that's running native ARM code just isn't going to work.... lots of issues that are pretty much impossible to work around, like calling conventions, endianness, memory layout, ASLR implementation.... all sorts of fun things. How would you even get an x86 emulator to pick and choose when to kick in? Based on memory ranges of loaded DLLs? No way -- you don't want that kind of voodoo horseshit going on in your apps, especially Windows Explorer, whose extensibility model is already pretty rickety as it is.

    4. Re:To do list by Anonymous Coward · · Score: 0

      Are you sure? They've explicitly mentioned that classes of apps won't work at all, not that they'd need a recompile.

    5. Re:To do list by R3d+M3rcury · · Score: 1

      Nothing Mac OS developers didn't go through during the PPC -> Intel transition twelve years ago. [...] How would you even get an x86 emulator to pick and choose when to kick in?

      Actually, Apple dealt with this years ago during the 68K/PPC transition. Yes, you could load 68K code into a running PPC application and have it emulate it (mostly because nobody wanted to touch the File Manager which was hand-optimized 68K assembler, as I understand it).

      Though the answer to the question was you told it what the code was pointing at (i.e., 68K or PPC).

    6. Re:To do list by Anonymous Coward · · Score: 0

      Literally anyone who's written shell extensions for Windows Explorer before will already understand the problem: shell extensions are loaded into the same process as Windows Explorer itself. Loading x86 code into a process that's running native ARM code just isn't going to work.... lots of issues that are pretty much impossible to work around, like calling conventions, endianness, memory layout, ASLR implementation.... all sorts of fun things

      Yea, obviously you have the x86 emulator in the Windows Explorer space and the shell extensions are then ran through it. Would it be a mess? Of course. Is it doable? Of course. Something similar: StarCraft: Remastered : Emulating a buffer overflow for fun and profit. Lots of HLE do similar stuff. I fully understand that MS would not want to deal with that mess and just require a recompilation, but that's not the same thing as not doable.

      Of course I think Windows 10 on ARM is just a clusterfuck period. The whole x86 emulator thing is not going to do much except placate people who do a very minimal amount of x86 stuff. Put another way, I see the same subset of people who tolerate WINE under Linux. Sure the compatibility will be a lot better, but the performance will be relatively horrible.

    7. Re:To do list by _merlin · · Score: 2

      Mixed Mode Manager was beautiful in a perverse way. The killer was that classic MacOS was tied to the 68k interrupt model - right up to MacOS 9 they were still dispatching interrupts through the 68k emulator. In early versions of System 7 for PowerPC you couldn't run native PowerPC code at interrupt time at all - anything that could be called from an interrupt handler had to run in the 68k emulator (this limitation was solved relatively quickly).

      You had this structure called a Universal Procedure Pointer (UPP). On the PowerPC side it contained the address of the code and a description of the argument and return types. This allowed you to call 68k or PowerPC code from PowerPC code. For 68k code to call PowerPC code, there would be a prologue consisting of an _MixedMode A-line trap followed by the argument description. Mixed Mode Manager would detect the trap, break out of the emulator, and translate the stack frame.

      You could probably translate COM between x86 and ARM. Microsoft already did this once when they supported 16-bit COM components in 32-bit applications and vice versa. The stack frames had to be translated for the differing calling conventions and pointer types. They probably don't want to though - the roll-out of x86_64 has encouraged people to write more portable code.

    8. Re:To do list by Anonymous Coward · · Score: 0

      Right, but to be fair, the number of Windows apps is so great it launches Apple's side of the scale so far into space that it's not even in our universe anymore.

    9. Re:To do list by gravewax · · Score: 4, Funny

      Are you sure? They've explicitly mentioned that classes of apps won't work at all, not that they'd need a recompile.

      That is just the usual Slashdot shithole editors. selectively quoting, even the article clearly states they just need a recompile.

    10. Re:To do list by Anonymous Coward · · Score: 0

      Surely the list of applications which do not run in WinArm is continuously evolving to include any kind of applications where Microsoft has its own business. This is a artificial limitation implemented specifically by dictation from business department. Of course they plan also to prevent installation of any application which does not come from Windows store.

    11. Re:To do list by Anonymous Coward · · Score: 0

      Now if only there were a legitimate reason to use Spyware 10 at all. Too bad for Microshaft that there isn't.

    12. Re:To do list by TheRaven64 · · Score: 1

      Loading x86 code into a process that's running native ARM code just isn't going to work

      I would be shocked if they weren't doing this, because that's how modern high-performance application emulators work: you compile all of the system libraries as native code and insert shims for communicating between them. ARM and x86 are both little endian, so that difficulty goes away. I'd be surprised if struct layouts were different between Windows/ARM and Windows/x86. Calling conventions need translating when you go to and from emulation, but that's trivial.

      That said, I expect that most of the things like the shell are AArch64 binaries, which makes this kind of thing a lot harder.

      --
      I am TheRaven on Soylent News
    13. Re:To do list by TheRaven64 · · Score: 1

      x86-64 would be a nice to have but the idea is to get developers releasing arm64 binaries, not rely on emulation indefinitely.

      I suspect that they're hoping, given the slow adoption of Win64, that anything that's been released as a Win64 app is under active development and so easy to get working on ARM. The emulator is intended for legacy things where no one has the source code (or, at least, the people that do have no incentive to support an ARM build).

      --
      I am TheRaven on Soylent News
    14. Re:To do list by Anonymous Coward · · Score: 0

      ARM and x86 are both little endian, so that difficulty goes away.

      Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.

      According to Overview of ARM ABI Conventions:

      Although the SETEND instruction in the ARM instruction set architecture (ISA) allows even user-mode code to change the current endianness, doing so is discouraged because it's dangerous for an application. If an exception is generated in big-endian mode, the behavior is unpredictable and may lead to an application fault in user mode, or a bugcheck in kernel mode.

      So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.

    15. Re:To do list by TheRaven64 · · Score: 2

      Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.

      That's there for a specific customer who wants to keep networking code originally written for big-endian MIPS and never ported to a little-endian machine in existence and other people are strongly discouraged from using it. As I recall, you can disable SETEND in EL0 (so you trap and can detect that the user has done it and switch back on interrupt if they have). This isn't an issue for emulated x86 code, because it will be running in little-endian mode on a machine that is intended to run in little-endian mode. I thought that AArch64 had removed SETEND, but I could be mistaken.

      So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.

      You'd have to persuade the JIT to generate a SETEND instruction, which sounds difficult.

      --
      I am TheRaven on Soylent News
    16. Re:To do list by kelemvor4 · · Score: 1

      Are you sure? They've explicitly mentioned that classes of apps won't work at all, not that they'd need a recompile.

      That is just the usual Slashdot shithole editors. selectively quoting, even the article clearly states they just need a recompile.

      ...or just one in particular... msmash. I guess even slashdot has an agenda these days. You can't escape it in the news.

    17. Re:To do list by cjjjer · · Score: 1

      I guess even slashdot has an agenda these days.

      I guess slashdot is an agenda after all.

      FTFY

    18. Re:To do list by pr0fessor · · Score: 1

      We are also talking about light weight convertibles or laptops with long battery life and cellular. When it comes to gaming and virtual machines I'm not surprised it has limited support some of which is hardware dependent.

    19. Re:To do list by Anonymous Coward · · Score: 0

      If it's implemented in UWP, it's not subject to the x86-on-ARM limitations.

      These limitations they're warning about are really only for the x86 emulation layer.
      - It's 32-bit only.
      - Anything that loads as a module into native ARM code (like exporer.exe or the kernel itself) must also be native ARM code. Hence, shell extensions, IME, cloud storage pseudo-volumes, drivers, etc.
      - Hyper-V isn't ported yet.
      - DirectX is ported, but legacy support for DX8 and earlier isn't going to be ported. (DX9 was released with Windows XP, nearly 2 decades ago.)

      This doesn't really change how new development is done for the platform. It only changes what old software is supported and what old software needs to be replaced with a UWP-ified version (or even just a Win32-on-ARM port).

  2. Yawn by Anonymous Coward · · Score: 1

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

    1. Re:Yawn by Anonymous Coward · · Score: 2, Funny

      crippled version of Windows

      Seems redundant.

    2. Re:Yawn by rogoshen1 · · Score: 1

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

    3. Re:Yawn by Anonymous Coward · · Score: 0

      I prefer the Willamette in my toaster. Much better heat generation.

    4. Re:Yawn by Excelcia · · Score: 1, Troll

      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 most part sane and no one wants to let them into any other market. No one willingly gives Microsoft money for anything else, because they have repeatedly demonstrated they simply cannot be trusted.

      So, seriously, why would anyone even know of or care about Windows for ARM?

    5. Re:Yawn by xvan · · Score: 1

      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;.

    6. Re: Yawn by GabeGhearing · · Score: 1

      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.

  3. Pointless by Anonymous Coward · · Score: 1

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

  4. Impossible! by Anonymous Coward · · Score: 3, Insightful

    The ARM port can't run x86 drivers?

    Say it isn't so!

    That Slashdot has completely hit rock bottom...

    1. Re:Impossible! by bloodhawk · · Score: 1

      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

    2. Re:Impossible! by K.+S.+Kyosuke · · Score: 2

      Isn't one of the limitations the forced secure boot crap? (And I'm pretty sure there's more screwy stuff in there. With MS, there always is...)

      --
      Ezekiel 23:20
    3. Re:Impossible! by Anonymous Coward · · Score: 0

      Joe Average doesn't know about drivers and such. All Joe knows is "It's Windows" and his scanner, USB dongle, 3D printer, etc. are Windows compatible. LMAO watching MS try, yet again, to get Windows to run on anything but a x86 without causing more problems than they solve.

    4. Re:Impossible! by Anonymous Coward · · Score: 0

      that is hardly a limitation that 99.99% of people give a shit about.

    5. Re:Impossible! by Anonymous Coward · · Score: 0

      There is no technical reason, why thou could not just emulate the drivers too. In practice this limitation prevents one from running any game with copy protection.

    6. Re:Impossible! by novakyu · · Score: 1

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

    7. Re:Impossible! by K.+S.+Kyosuke · · Score: 1

      I'm pretty sure there's still about 1% of dektop Linux/Un*x users (or somewhat more), so you're implying that over 99% of them don't care. I'd like to think they do.

      --
      Ezekiel 23:20
    8. Re:Impossible! by Hal_Porter · · Score: 4, Informative

      There is no technical reason, why thou could not just emulate the drivers too.

      Suppose you've got some x86 code in running on an ARM in kernel mode. It will expect everything it sees to have the x86 structure alignment. E.g. if it does an mov eax, [ebx+n] and that is translated into LD R0, [R1,#n] then you'd best hope that the structure R1 points to has the exact same thing at offset n in ARM windows that it does on x86 windows.

      There are going to be some weird corner cases where that won't be the case, and then you've got kernel mode corruption. Actually if the ARM is running a 64 bit kernel and the driver is x86, that's guaranteed to be the case and you need to thunk all the structures. However I think even if you have x64 code being emulated on ARM64 there are going to weird corner cases where the layout of a kernel mode structure is going to be different.

      Another issue is alignment. x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not. In user mode that's no problem - you get an alignment fault, the kernel fixes it up and you go on you way, with a performance hit.

      However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock. The page fault handler needs to acquire a whole bunch of spinlocks when it fetches a page and allowing to run at a raised IRQL risks a deadlock and a frozen system. So an NT based OS will BSOD with IRQL_NOT_THAN_LESS_OR_EQUAL in this case - what that means is that IRQL is not <= PASSIVE_MODE.

      But suppose you have some x86 kernel mode code at a raised IRQL doing an unaligned pointer access. The emulator runs it and it faults. And in NT that fault is instant death. Sure you could hack the kernel so that it first tries to do an alignment fixup. However you've introduced a load of complexity to a design that was pitiless and pure initially - if kernel mode code causes a page fault at raised IRQL then it dies instantly and the solution is for users to track down the company, for the company to track down the developer and for the developer to fix his shitty code.

      Actually another option would be for the emulator to check for misalignment and handle it in by avoiding the fault. This would probably work, but there's an overhead you'd need to pay on every pointer access, even the aligned ones, where you'd need to check the low order bits to make sure enough of them were zero to make it aligned before you dereferenced it.

      In practice this limitation prevents one from running any game with copy protection.

      Copy protection drivers are a bit like anti virus software anyway. What they're doing is grovelling around in undocumented structures and doing rootkit type shenanigans. And the idea that you're going to try to run a copy protection meant for x86 or x64 on a completely different processor architecture is a fool's errand first place. The whole point of them is to try to work out if there's something a bit hinky going on. Nothing is more hinky than running kernel mode code on the wrong CPU architecture with a bunch of hacks that tries to hide the differences and doesn't completely manage it.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    9. Re: Impossible! by Anonymous Coward · · Score: 0

      Many wont give a shit until their os is hosed and then they need to run a boot utility to fix their computer/retreive data only to find microsofts asshole secure boot is hindering the fixit job.

    10. Re:Impossible! by TheRaven64 · · Score: 1

      It will expect everything it sees to have the x86 structure alignment

      The structure alignment rules for anything that's not a packed structure are likely to be the same for both. You may have some issues with stack frame layouts, but that's a separate issue.

      x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not

      That isn't true for any ARM core released in the last 10 years, possibly the last 15 years.

      However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock

      That's far more important: you don't want to be trapping out to an emulator in an interrupt context. You also probably don't want to stick the emulator in the kernel in the first place, because that's a nice big attack surface for malware to play with.

      --
      I am TheRaven on Soylent News
    11. Re:Impossible! by Hal_Porter · · Score: 1

      Hmm, I see what you mean about unaligned pointers and ARM. Support was added in ARMv6 and it's still there in ARMv8 AArch64 mode

      AArch64
      https://www.realworldtech.com/...

      ARMv6
      http://infocenter.arm.com/help...

      Frankly if I were Microsoft and someone suggested adding support for non native kernel mode code I'd say "What an excellent idea. Why not suggest it to Dave Cutler, right now!". And then that would be last you'd see of them.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    12. Re:Impossible! by Anonymous Coward · · Score: 0

      Ive been using secure boot with linux for a couple of years now with no problems.

    13. Re:Impossible! by K.+S.+Kyosuke · · Score: 1

      On an ARM device?

      --
      Ezekiel 23:20
    14. Re:Impossible! by Shirley+Marquez · · Score: 1

      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.

    15. Re:Impossible! by Hal_Porter · · Score: 1

      The structure alignment rules for anything that's not a packed structure are likely to be the same for both

      I found this for Android - long long is aligned to 8 bytes on ARM but 4 bytes on x86

      https://software.intel.com/en-...

      Microsoft compilers have an option to align. It seems like /Zp8 is the default

      https://msdn.microsoft.com/en-...

      What that means is that anything up to 8 bytes will be naturally aligned

      And if you look here it confirms it

      https://msdn.microsoft.com/en-...

      I still think there'd be some corner case where the layout in memory of a structure would be different. Bitfields for example, though Windows usually doesn't use those because of portability concerns. Or SIMD data.

      Another issue is that x86 and x64 are strongly ordered and ARM is not. You have to add in explicit barriers to for ARM to work the same. ARM I&D caches are not coherent too - self modifying code works on x86 because writes to the D cache automagically end up in the I cache. That's not true in ARM. x86 goes to great lengths in hardware so that code now sees the same machine that code back in the 386 days did and one which is very different from both a moder x86/x64 chip and any Risc chip. Modern x86/x64 chips have extra hardware to maintain the illusion and Riscs like ARM do not.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  5. No Hyper-V? by Weaselmancer · · Score: 1

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

    --
    Weaselmancer
    rediculous.
    1. Re:No Hyper-V? by Anonymous Coward · · Score: 0

      This is not as big of a problem as you think. Just do the following:

      ARM Windows -> Vmware -> Linux -> VirtualBox -> Windows Server -> Hyper-V -> Pirated copy of x64 Windows 7, because Microsoft "upgraded" your license to Windows 10.

      Problem solved!

    2. Re:No Hyper-V? by Anonymous Coward · · Score: 0

      You could run Linux/KVM on the hardware and run this software inside a Windows ARM virtual machine.

      If it's not a locked down crippleware device, that is.

    3. Re:No Hyper-V? by Anonymous Coward · · Score: 0

      You know it already runs win32 x86 software right?

    4. Re:No Hyper-V? by Weaselmancer · · Score: 1

      thats_the_joke.jpg

      --
      Weaselmancer
      rediculous.
  6. That's nice by Anonymous Coward · · Score: 1

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

  7. Seems fair enough. by swamp_ig · · Score: 1

    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.

    1. Re:Seems fair enough. by 93+Escort+Wagon · · Score: 1

      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.

      --
      #DeleteChrome
  8. 64 Bit Support is Unlikely by nateman1352 · · Score: 3, Interesting

    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 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.

    1. Re:64 Bit Support is Unlikely by Anonymous Coward · · Score: 0

      You can't patent or copyright an ISA. Most of their patents would cover hardware implementations of various features.

      For eg, Bochs can emulate a full x86-64 environment and hasn't been sued yet. Some dynamic recompiler techniques MS wants to use may be patented but there's nothing stopping them from creating something usable.

    2. Re:64 Bit Support is Unlikely by Anonymous Coward · · Score: 1

      uh what? you most definitely can patent an ISA. The only reason that Intel was able to implement AMD64 is they already had a cross-license in place.

    3. Re:64 Bit Support is Unlikely by MobyDisk · · Score: 1

      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.

    4. Re:64 Bit Support is Unlikely by Anonymous Coward · · Score: 0

      Technically, but they still had to be executed on intel/amd platforms.

    5. Re:64 Bit Support is Unlikely by _merlin · · Score: 1

      Bochs x86_64 emulation works on an IBM POWER host.

    6. Re:64 Bit Support is Unlikely by Kjella · · Score: 1

      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 sued by Intel about some SSE patents but drag it out in courts a few years without suffering an injunction then settle for a one-time payout and continue shipping now patent free x86-64 processors. It's a bit of a dirty trick but big companies with deep pockets can afford to do that. Intel will play dirty too when they can, so very little sympathy from me.

      --
      Live today, because you never know what tomorrow brings
    7. Re:64 Bit Support is Unlikely by Hal_Porter · · Score: 1

      You can't patent or copyright an ISA. Most of their patents would cover hardware implementations of various features.

      Intel claim patents on SIMD instruction sets and say that those preclude anyone who doesn't have a license executing those instructions even in emulator

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

      Intel carefully protects its x86 innovations, and we do not widely license others to use them. Over the past 30 years, Intel has vigilantly enforced its intellectual property rights against infringement by third-party microprocessors. One of the earliest examples, was Intel's enforcement of its seminal "Crawford '338 Patent." In the early days of our microprocessor business, Intel needed to enforce its patent rights against various companies including United Microelectronics Corporation, Advanced Micro Devices, Cyrix Corporation, Chips and Technologies, Via Technologies, and, most recently, Transmeta Corporation. Enforcement actions have been unnecessary in recent years because other companies have respected Intel's intellectual property rights.

      However, there have been reports that some companies may try to emulate Intel's proprietary x86 ISA without Intel's authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation ("code morphing") techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta's x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.

      Only time will tell if new attempts to emulate Intel's x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel's microprocessors, which have been specifically optimized to implement Intel's x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel's intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.

      The graph above shows that SSE and later is still covered by extant patents. SSE is actually part of the x64 architecture - you need to execute SSE instructions to have floating point, and floating point is not optional. The x64 ABI actually requires SSE. I.e. to emulate x64 instructions you need a licence for the SSE patents.

      This probably also means that if an emulator supports SSE instructions in x86 mode Intel will sue too.

      Of course they might be bluffing about suing and will come to an arrangement with Microsoft and Qualcomm or the hardware vendors of Windows on ARM devices to license the patents. Or maybe they're not but they'd lose in court.

      Their blog post is clearly designed to make Microsoft, Qualcomm and the vendors think that a lawsuit is possible though.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    8. Re:64 Bit Support is Unlikely by Hal_Porter · · Score: 1

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

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

      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 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 extension to x86 but it is almost covered by patents from both Intel and AMD.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    9. Re:64 Bit Support is Unlikely by 91degrees · · Score: 1

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

    10. Re:64 Bit Support is Unlikely by Hal_Porter · · Score: 1

      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.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    11. Re:64 Bit Support is Unlikely by TheRaven64 · · Score: 1

      It depends a bit on what those patents cover. You can't patent the idea of a 128-bit vector, so it must be on details of specific instructions. ARM has had a 128-bit vector unit for quite a long time and a lot of SSE instructions map trivially to NEON equivalents. If those instructions are the ones that are covered by the patents, then ARM will already have a cross-licensing agreement in place to cover them.

      --
      I am TheRaven on Soylent News
    12. Re:64 Bit Support is Unlikely by TheRaven64 · · Score: 1

      Nope. Microsoft bought Connectix for their VirtualPC for Windows product, which became Microsoft VirtualPC and then was merged into their other virtualisation platforms, but Connectix was better known for VirtualPC for Mac (which had one release after Microsoft bought them and was then killed, largely because IBM's PowerPC 970 didn't include the instructions that made byte swapping cheap): an x86 emulator that ran on PowerPC. It was pretty good for the time and ran a useable GUI on a 1.25GHz PowerPC. It did a bunch of work to detect uses of condition codes and skip generating them if they're not used, which is one of the pain points when emulating x86.

      --
      I am TheRaven on Soylent News
    13. Re:64 Bit Support is Unlikely by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
    14. Re:64 Bit Support is Unlikely by Hal_Porter · · Score: 1

      Yeah. Lexra got screwed

      http://probell.com/lexra/

      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'.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    15. Re:64 Bit Support is Unlikely by Hal_Porter · · Score: 2

      If you were Acer and you had a prototype Windows on ARM device and you knew the performance was going to suck would you risk being party to a lawsuit where Intel sued Qualcomm and Microsoft for violating one of their 400 patents that was analogous to the one MIPS sued Lexra over?

      Or would you think "Yeah, I think we'll pass on Windows on ARM".

      I think that's what Intel is going for.

      Or maybe they want to make sure that Microsoft agree not to emulate any instructions recent enough to be patented. I.e. the 486 instruction set and probably MMX is OK, x64 and SSE or later is not. That would mean you could only run x86 binaries and not x64 ones. And things like Photoshop are going to really suck.

      Intel don't need to win a lawsuit for it to have an effect. All they need is to hint a blog that one might be coming and they can scare off hardware vendors from launching devices and Microsoft from adding SSE support to their emulator.

      Amusingly the MIPS vs Lexra lawsuit means that even if you don't implement instructions that would violate a patent and do an illegal instruction trap, you can still be sued because hypothetically someone could write a trap handler which emulated them. That's some real 'through the looking glass' lawyering right there.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    16. Re:64 Bit Support is Unlikely by MobyDisk · · Score: 1

      A+ for the history lesson!

  9. ARM64 drivers but can't support 64 bit application by Ayano · · Score: 0

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

    --
    I don't read AC
  10. Get a life by Anonymous Coward · · Score: 0

    you trust a nasty company to support early versions of their products?

    nobody trusted comtributions from SCO.

    Software today is distinguished from free and pre-payed: communists outlaw ownership of software, moe become the next wave of capitalists.

    It took how many jelly beans for Microsoft Corp & friends to accelerate software life expectacy to fail OpenGL? ARM is the next target to cripple.

    1. Re:Get a life by Anonymous Coward · · Score: 0

      Get back on your meds.

  11. I don't think any of this is a surprise by holophrastic · · Score: 2

    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.

    1. Re:I don't think any of this is a surprise by Anonymous Coward · · Score: 0

      It's probably not '64 bit apps', but "64bit x86 code" that isn't supported because transpiling that to ARM is harder.
      But native ARM 64 bit binaries probably work fine.

      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.

      Actually, the 'journalist" is an "idiot". Read the actual documentation .

      Shell extensions. Apps that try to hook Windows components or load their DLLs into Windows processes will need to recompile those DLLs to match the architecture of the system; i.e. ARM64. Typically, these are used by input method editors (IMEs), assistive technologies, and shell extension apps (e.g. to show cloud storage icons in Explorer or a right click Context menu).

      Long story short; Explorer.exe is recompiled as native ARM64. Thus any DLL that is loaded into explorer.exe has to also be ARM64. I think that's a pretty damn reasonable technical limitation. (And, most importantly, Microsoft are stating shell extensions are supported; they merely need to be ARM64 native.) The journalist is completely and utterly wrong and could not be more wrong if they tried. They're so wrong, that I would argue they're defaming Microsoft.

      What ISN'T supported is "injecting x86 dlls into ARM native processes".

      (Interesting comments there -- looks like the x86 world is "Windows on Windows", exactly how the x86-32 world exists as "Windows on Windows" within x64 windows. Same limit there, I think you can't load 32 bit DLLs into 64 bit processes today. That might be why x64 machine code isn't supported because there already is that 'bubble' for 32 bit x86 WoW tested, but not a second WoW for 64 bit. And presumably they simply aren't going near ARM32.

      What is ACTUALLY a surprise is the OpenGL limitation - which is far more 'microsoft being anti-competitive' than literally everything else this reporter thinks.

    2. Re:I don't think any of this is a surprise by AmiMoJo · · Score: 1

      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 on ARM to be much good, if you couldn't tell. Probably just another Windows 8 RT. Doesn't run anything, no-one wants it, quietly dies in a corner.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:I don't think any of this is a surprise by Shirley+Marquez · · Score: 1

      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.

  12. Windows on ARM wasn't meant to be parallel to x86 by Solandri · · Score: 4, Insightful
    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.

  13. Re:ARM64 drivers but can't support 64 bit applicat by Anonymous Coward · · Score: 0

    It support ARM64 just fine... it's x64 that it doesn't support....

  14. Re:Windows on ARM wasn't meant to be parallel to x by Anonymous Coward · · Score: 0

    FYI: Windows CE ran on ARM processors in the late 90s, back about half a decade before PC performance plateaued and sales gradually began to fall.

  15. Just use Linux by Gravis+Zero · · Score: 0

    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.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:Just use Linux by Anonymous Coward · · Score: 0

      WINE still needs x86

    2. Re:Just use Linux by Anonymous Coward · · Score: 0

      https://wiki.winehq.org/ARM
      I don't think you can grab any Windows x86 program and just run it - it mentions QEMU so it's going to be slow if it works at all

    3. Re: Just use Linux by Anonymous Coward · · Score: 0

      Wine+Qemu is exactly what Microsoft is doing. Itâ(TM)s WAY faster than just emulating. Only the appâ(TM)s instructions need emulation, the calls into the system are native.

    4. Re: Just use Linux by Anonymous Coward · · Score: 0

      I thought they worked with Qualcomm to have hardware emulation on their ARM chips. Doesn't that mean they don't need QEmu?

  16. No by theweatherelectric · · Score: 5, Insightful

    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.

    It cannot use x86 drivers.

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

    1. Re:No by Anonymous Coward · · Score: 0

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

      They note this because a lot of things are 'drivers' in Windows that aren't in any other OS. Things like cloud storage managers, etc. Not just traditional hardware drivers.

    2. Re:No by Anonymous Coward · · Score: 0

      Things like cloud storage managers, etc. Not just traditional hardware drivers.

      Anything that pretends to be hardware needs a driver interface. Is that really odd to you? Whether it's a fictional hard drive that's actually a user space on some NSA server, a fictional BlueRay drive that's actually reading a file, or a fictional keyboard to relay instructions from a kludged-in Playstation controller, it acts like hardware so it's treated like hardware.

    3. Re:No by Anonymous Coward · · Score: 0

      > No one thought that.

      You should see the article on 'Windows 10 IOT of Raspberry Pi'. Many stated they would be running a full desktop and all their games on a $35 computer.

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

      Because they are stupid and also think that Bill Gates is God.

  17. Re:Windows on ARM wasn't meant to be parallel to x by Anonymous Coward · · Score: 0

    Microsoft taught everyone about commoditizing their suppliers. Intel was just the biggest and last lesson.

  18. Re:Windows on ARM wasn't meant to be parallel to x by Anonymous Coward · · Score: 0

    This is about Windows 10 on ARM64

  19. Thanks by Anonymous Coward · · Score: 0

    I'll pass.

  20. Not surprising really by Hal_Porter · · Score: 3, Insightful

    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).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/...

    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...

    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.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    1. Re:Not surprising really by Bert64 · · Score: 1

      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 overhead you had reasonable performance for the time. The difference today, is that arm is significantly slower than x86 even when running native code and the emulation will harm that further.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    2. Re: Not surprising really by Hal_Porter · · Score: 2

      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.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    3. Re:Not surprising really by Dog-Cow · · Score: 1

      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.

    4. Re:Not surprising really by Dog-Cow · · Score: 1

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

    5. Re:Not surprising really by Hal_Porter · · Score: 1

      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/...

      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.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  21. So basically Windows RT by Anonymous Coward · · Score: 1

    Been there, dumped that...

  22. Class Action Lawsuit! by Anonymous Coward · · Score: 0

    Glad to see that whomever over there in MS who knew how to play the game retired.

  23. Patenting interfaces by aberglas · · Score: 1

    Wasn't there a big court case recently when Oracle tried to sue Google over the Java API.

    That was copyright. Patents expire after 20 years, so the 64bit issues should be coming to a head real soon. (It is from time of filing, not time of release in a product.)

  24. Re:That shit-fest is hard to port by gravewax · · Score: 2

    The windows Kernel is actually their strongest feature, it is a well designed kernel. What sucks is the shit stacked on top of the Kernel.

  25. Limited Kudos. by jimtheowl · · Score: 2

    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-...

  26. Now all they need to do is rename it by jools33 · · Score: 1

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

  27. x86 apps by Anonymous Coward · · Score: 0

    Will Virtual PC 2007 run on the ARM setup?

  28. Not really by Casandro · · Score: 1

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

    1. Re:Not really by Z80a · · Score: 1

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

    2. Re: Not really by GabeGhearing · · Score: 1

      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.

  29. Damn kids by Anonymous Coward · · Score: 0

    Windows NT on alpha, mips, power pc.

    ARM is just another hal, right? With a bunch of lame emulation in some cases.

  30. What about the EULA? by Anonymous Coward · · Score: 0

    Will it still provide a week of reading for ordinary people and two terms of classwork for legal students?

  31. Re:That shit-fest is hard to port by Anonymous Coward · · Score: 0

    You owe me a new keyboard. I just spat my coffee into it.

  32. Re:That shit-fest is hard to port by TheRaven64 · · Score: 1

    Huh? The Windows NT kernel was originally brought up on the Intel i860 (RISC processor) and then ported to x86, to make sure that it was portable and didn't include any x86isms outside of the HAL. They've been maintaining ports to other architectures internally since then to ensure that it keeps this property.

    If you read Tanenbaum's Modern Operating Systems, you'll see a good comparison of the NT kernel to a couple of UNIX systems and it comes off pretty well in the comparison.

    --
    I am TheRaven on Soylent News
  33. Re:Windows on ARM wasn't meant to be parallel to x by Anonymous Coward · · Score: 0

    nice theory, but it falls flat on two counts:

    microsoft isn't getting fifty bucks from major oems like hp or dell for a windows license...

    and arm-based units will fall under that netbook|low end hardware category that has previously qualified for ridiculously-cheap licenses when built to certain hardware limits.

    this is about market share, not profits from windows licenses. microsoft is losing the growing low-end market to android and chromebooks, losing the academic market to those and apple, and is even losing 'enterprise' sales as well as mobile workers are turning more and more to their phones (which aren't running windows anything) instead of a traditional notebook pc.

    windows 10's revenue stream is from ads, app preloading and 'store' commissions, and marketshare is needed for that... marketshare at any cost.. remember, they 'gave away' windows 10 for two years.

  34. AKA, it will be another dud by Anonymous Coward · · Score: 0

    Its going to be so restrictive that most Windows users like with 10S will simply pass only worse with a ARM you simply cannot install another full version of Windows 10. There will be no upgrade path. These devices will be pretty pathetic and limited in use, sort of like a Chromebook with Windows. I'll pass.

  35. This is what happens... by Anonymous Coward · · Score: 0

    ...when you decide to use a cell phone architecture instead of a real full powered computer design.

    1. Re:This is what happens... by xvan · · Score: 1

      ARM is a more efficient architecture on for applications.
      Even if you consider single core applications peak computing power, the benchmarks show that AMD64 isn't more than 20% faster than ARM64.

      The real issue are, as always, preexisting closed software ecosystems. An ARM linux box is perfectly viable.

  36. What's the point? by cmaurand · · Score: 1

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

  37. WIndows 10 ha.. by Anonymous Coward · · Score: 0

    sofa king ghey

  38. Re:That shit-fest is hard to port by Anonymous Coward · · Score: 0

    probably a good thing that you can't use a computer if you find that shocking. Anyone with low level OS developer knowledge will tell you the same thing. NT Kernel is actually a very good design and implementation.