Sign in / up

back to article Windows slithers on to Arm, legless?

Perhaps more by accident or design, Microsoft managed to lower expectations for Windows on Arm last week – but not set them so low it kills off interest in the platform. In fact, the "redacted" advisory about limitations of Windows confirms what we already know – hairy hacks won't work, nor will various plugins that hook into …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *

Page:

  1. alain williams Silver badge

    Wedded to Intel

    That is part of Microsoft's problem. One CPU/instruction-set has really made things simpler for them and their users. However it is really difficult for them to change; 16 -> 32 -> 64 bit has caused enough problems.

    This is something that Unix has addressed from the start. I remember 30+ years ago porting my programs to at least 3 different instruction-sets before I considered it ready for others to test. So different platforms have always been part of *nix programmer & user expectations, part of the culture.

    Yes: need to think a bit more, but once you have the idea not that hard.

    26 9 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Wedded to Intel

      Windows, at least from NT onward has always supported multiple processor architectures. NT actually targeted the Intel 860 originally.

      18 2 Reply
      1. kryptylomese
        Reply Icon

        Re: Wedded to Intel

        Windows does but not the software that runs on it and that is the problem!

        2 2 Reply
    2. BinkyTheMagicPaperclip Silver badge
      Reply Icon

      Re: Wedded to Intel

      Have you forgotten that Windows NT has historically supported five different platforms (x86, MIPS, Alpha, PowerPC, and Itanium) and had incomplete ports for two (i860, Sparc)?

      The issue is not the cross platform nature - it generally worked well, it's the lack of software. Alpha was most successful, partly because DEC and Microsoft made the effort to keep the platform up to date, and partly because it included x86 emulation.

      This was then repeated with Windows CE, multiplatform, but limited software.

      Porting is likely to be considerably easier than between Unix variants, as the Windows API is standardised, but probably more expensive. This was definitely prior to the years of free compilers from Microsoft, however, and I'm not sure how well gcc/mingw coped with non x86 platforms. Third party compilers would undoubtedly be pricey.

      16 7 Reply
      1. John Smith 19 Gold badge
        Reply Icon
        Unhappy

        "Windows NT has historically supported five different platforms "

        Note those words

        "Windows NT," and "historically"

        How many alleged "from the ground up" re-writes ago was that?

        20 4 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          Re: "Windows NT has historically supported five different platforms "

          > "How many alleged "from the ground up" re-writes ago was that?"

          To be fair almost all those architectures failed in one way or another, MS would look a bit daft maintaining an Alpha port. I think mips is about the only one still operating and that's hardly desktop level.

          6 4 Reply
          1. jabuzz
            Reply Icon

            Re: "Windows NT has historically supported five different platforms "

            > I think mips is about the only one still operating and that's hardly desktop level.

            Don't know I just last year brought a couple of Ubiquiti Edgerouter Infinity's. They have in them a 16 core 1.8GHz 64bit MIPS chip with 16GB of RAM. Allegedly the chip is available in a 2.2GHz variant and has a couple of SATA ports too and a PCIe x4. So a version of that chip which slimmed down the eight 10GbE ports and stuck in a GPU on would be a seriously decent desktop machine. From memory it is on a 22nm process so goodness only knows what it would be like on a 14nm process.

            3 0 Reply
            1. Anonymous Coward
              Reply Icon
              Anonymous Coward

              Re: "Windows NT has historically supported five different platforms "

              >> I think mips is about the only one still operating and that's hardly desktop level.

              >Don't know I just last year brought a couple of Ubiquiti Edgerouter Infinity's.

              I honestly didn't realise MIPS had reached such lofty heights, but that is still a router and an embedded application.

              2 0 Reply
          2. Joe Montana
            Reply Icon

            Re: "Windows NT has historically supported five different platforms "

            MIPS is still competing in the embedded space, although they are way behind ARM, and really missed their chance to get ahead of ARM in the transition to 64bit.

            MIPS had a 64bit variant *long* before ARM, it's been around since the early 90s and has mature compiler support, as well as hardware available easily and cheaply. ARM64 was only announced in 2011, and took a while to get OS and compiler support.

            1 0 Reply
      2. Charlie Clark Silver badge
        Reply Icon

        Re: Wedded to Intel

        The issue is not the cross platform nature - it generally worked well

        All the way until 3.5 when MS moved lots of stuff into the kernel for better performance on x86. This effectively killed off support for other architectures because the microkernel was lost.

        6 3 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          "when MS moved lots of stuff into the kernel"

          That was made to avoid costly ring transitions. As long as it is code that doesn't use any CPU specific feature or instruction, it can be recompiled for any CPU you like just using a different compiler, it really doesn't matter where it does run.

          For the matter even Linux moved a lot of its graphic code into the kernel because you can access graphics hardware only from there - and if you keep on going back and forth from user to kernel your performance will get a big hit - why OS were mapping kernel memory into user space protecting it with a paging bit only?

          And Linux too is not a microkernel architecture, still it runs on many different CPUs....

          8 0 Reply
          1. Charlie Clark Silver badge
            Reply Icon

            Re: "when MS moved lots of stuff into the kernel"

            That was made to avoid costly ring transitions.

            x86-specific like wot I said. The Alpha didn't have the same problems.

            And Linux too is not a microkernel architecture, still it runs on many different CPUs....

            Yes, but the ports are not easy. Compare it with a truely multi-CPU arch such as NetBSD or a microkernel (hint why is Google thinking of dropping the Linux kernel for Fuchsia?)

            4 5 Reply
            1. Anonymous Coward
              Reply Icon
              Anonymous Coward

              "x86-specific like wot I said. The Alpha didn't have the same problems."

              Just, they are the security checks. Look at what happened when Intel decided to ignore some checks during speculative execution for speed...

              Ring transitions in Intel chips are quite complex operations, and the protected mode of Intel chips is quite sophisticated. I don't know enough about Alpha chips because I never programmed one, but in Intel chips it's not just checking and flipping some bits, because descriptors have far more data to check.

              0 0 Reply
      3. Richard Plinston
        Reply Icon

        Re: Wedded to Intel

        > Alpha was most successful, partly because DEC and Microsoft made the effort to keep the platform up to date, and partly because it included x86 emulation.

        ... and partly because DEC settled with Microsoft over Dave Cutler reusing design work he had done at DEC when implementing NT.

        """Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."""

        http://www.itprotoday.com/management-mobility/windows-nt-and-vms-rest-story

        1 0 Reply
      4. Joe Montana
        Reply Icon

        Re: Wedded to Intel

        Chicken and egg... Vendors won't port to a platform with no users, and users won't buy a platform with no software.

        The unix world was always different, you had several large well established vendors each with their own OS and later their own processor architecture (many started off on m68k before developing their own). Developers of software for windows on the other hand have never really had to deal with portability, they typically never considered processors with a different byte order or pointer size.

        Then there is the open source nature of many unix systems, especially today. Not only is most software portable, anyone can recompile it for a different architecture. You don't get the chicken and egg problem, as the vast majority of software is a recompile away once you have a unix-like kernel and gcc ported to the new architecture.

        2 0 Reply
    3. Lysenko
      Reply Icon

      Re: Wedded to Intel

      You seem to be confusing Seattle with Cupertino.

      2 10 Reply
    4. Anonymous Coward
      Reply Icon
      Anonymous Coward

      "However it is really difficult for them to change"

      "16 -> 32 -> 64 bit has caused enough problems"? What problems? There were more problems with applications written without taking into account the far more protected and restrictive NT environment than running them on a 32 bit system. Going from 32 to 64 bit was so simple nobody really noticed it happened, but the availability of far more RAM.

      Backward binary compatibility has always been excellent, unlike some Unix where you can't run applications on a newer system unless your recompile them because binaries won't work. Windows users do expect compatibility at the binary level.

      The only problem came when AMD dropped the Virtual86 mode in 64 bit mode so Windows 64 bit could no longer run 16 bit applications outside a full virtual machine.

      It was an AMD decision, nor Microsoft nor Intel took it.

      If you write everything only in a high-level language and libraries, all you need is a compiler/interpreter, and have been so for decades, regardless of the OS. And there are *nix applications available for a single instruction set as well.

      At the application level, the only issue you can have is where you have carefully crafted hand made assembler code - which may happen when you need high optimizations, or rely on processor specific libraries, for the same reason.

      For example Adobe lately worked with Intel to improve performance on multi-core systems, and a lot of the resulting code won't be portable to ARM but with a specific effort.

      11 9 Reply
      1. Ken Hagan Gold badge
        Reply Icon

        Re: "However it is really difficult for them to change"

        "And there are *nix applications available for a single instruction set as well."

        Such as Android Studio.

        (I find that example *particularly* odd. I can imagine that Google wouldn't want to port the emulator portion, but the editors and build tools are surely written in a portable language.)

        6 0 Reply
        1. bombastic bob Silver badge
          Reply Icon
          Devil

          Re: "However it is really difficult for them to change"

          "Such as Android Studio."

          well if you're emulating ARM on ARM, maybe it will RUN FASTER now? but yeah it probably means a re-write of the ARM emulation. You should expect any kind of virtualization and/or emulation to be like that. It's probably a lot of assembly code, and uses virtualization registers and other hardware-specific stuff.

          2 0 Reply
      2. Baldrickk
        Reply Icon

        Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

        Somebody never tried Windows XP-x64...

        Horrible driver support, terrible application support. It was a terrible mis-step.

        MS did improve on this with Vista - though that for many was still a 32-bit OS, and it's only with Windows 7 that 64-bit became mainstream for Windows users at home. By that time MS had had many years to get device manufacturers on-board with driver support. Even now, how many apps are 32-bit only?

        It's a bit like the Millennium Bug. Basically, nothing happened, but only because a lot of work was done to prevent it from happening.

        20 3 Reply
        1. Mage Silver badge
          Reply Icon

          Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

          Some older 32 bit apps (esp VB6) will work on Win7 & Win 10 32biit, but impossible on 64bit Win7 & Win 10. Also why removal of WOW16 and NTVDM? Dosbox works.

          0 2 Reply
          1. Colin 29
            Reply Icon

            Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

            I have VB6 running on Windows 10 64-bit, no problems

            4 0 Reply
            1. david 12 Silver badge
              Reply Icon

              Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

              VB6 runs on Win10 64. Some Apps don't run on Win64 (It really has nothing to do with VB6, which is, after all, the VS C++ compiler under the covers).

              In particular what doesn't work is some 32 bit OLE controls used by some Apps.

              Given that OLE is a technology for using independent and disconnected objects, there really is no technical reason why 32 bit OLE isn't supported with 64 bit OLE. It's a marketing and support decision from MS.

              1 3 Reply
          2. Anonymous Coward
            Reply Icon
            Anonymous Coward

            "so why removal of WOW16 and NTVDM? Dosbox works."

            Once again: AMD removed the Virtual86 mode from CPU in 64 bit mode. Without that CPU mode, WOW16 and NTVDM can't work.

            DosBox is a software CPU emulator, while the Virtual86 mode allows for running real mode software directly on the CPU, once the CPU is in protected mode automatically trapping operations forbidden in protected mode and allowing the OS to perform them as required.

            If older VB applications use 16 bit libraries or installers, they won't work on 64 bit Windows exactly for that reason.

            With virtual machine easily available, it takes little to run DOS in one if you need to run 16 bit code.

            7 0 Reply
            1. Richard Plinston
              Reply Icon

              Re: "so why removal of WOW16 and NTVDM? Dosbox works."

              > Once again: AMD removed the Virtual86 mode from CPU in 64 bit mode.

              While the _Intel_ 64 bit design also removed Virtual86 mode _and_ x86 32bit mode.

              2 0 Reply
          3. bombastic bob Silver badge
            Reply Icon
            Boffin

            Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

            WOW16 can't work in x64 because it doesn't have 16-bit support. that's just the way the architecture is.

            NTVDM - there's no Virtual 8086 mode any more on x64. hence, can't have that, either.

            As I recall, in 32-bit mode, a code selector is marked as 'USE16' or 'USE32' with a bit. I haven't looked, but I suspect in 64-bit mode, it switches between 'USE32' and 'USE64' in a similar way. To understand how the GDT and LDT work, you can start HERE:

            https://en.wikipedia.org/wiki/Global_Descriptor_Table

            (it's incomplete and oversimplified but you'll get the 'gist' and there are links to better resources)

            I used to play with selectors and call gates and stuff like that "back in the day", even wrote a program for Win 3.x and '9x that would dig into the guts of the 'virtual DOS' (aka VxD) stuff and even make calls into the kernel via the interface. You could find out useful stuff about running processes, figure out what VxD's were loaded, dump the global and local descriptor tables, read the page tables, stuff like that, by playing with "all that" and then list it conveniently in a simple Windows application. But naturally it had to be a 16-bit application to do it's magic, and only worked with '9x and 3.x (because they had VxDs).

            1 1 Reply
            1. bombastic bob Silver badge
              Reply Icon
              Boffin

              Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

              oh, one more thing I just found out.

              from https://en.wikipedia.org/wiki/X86-64#Architectural_features

              apparently in 64-bit mode (which they call "long" mode) you can have 16-bit protected mode processes (which actually surprises me quite a bit). However, you can't have 'real mode' nor 'virtual 8086' mode. Interesting.

              So maybe dumping WOW16 had something to do with legacy 16-bit applications and 64-bitness i the kernel. Because, in theory, a "well behaved" 16-bit application SHOULD be possible to run in 64-bit mode...

              1 0 Reply
              1. Anonymous Coward
                Reply Icon
                Anonymous Coward

                " in theory, a "well behaved" 16-bit application SHOULD be possible to run in 64-bit"

                The problem is not only the bitness of the application, but the whole environment it expects to run in. DOS applications do expect to be in real mode, access a given memory layout (interrupt tables, video memory, etc) and being able to change segment registers, Win16 applications do expect their memory layout and Win16 API entry points within their address space, etc. etc.

                1 0 Reply
              2. Richard Plinston
                Reply Icon

                Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

                > apparently in 64-bit mode (which they call "long" mode) you can have 16-bit protected mode processes

                16-bit protected mode is 80286 native mode. The 80286 was brain dead so nobody cares.

                > Because, in theory, a "well behaved" 16-bit application SHOULD be possible to run in 64-bit mode...

                It may be that "in theory" a particular design could run 16bit V86 and 64bit together, but the AMD design does not. Programs run by executing instructions. Instructions have particular bit layouts. These have a number of bits assigned to the op-code. You cannot have more different op-codes than the number of bits allow. AMD-64 long mode requires additional op-codes so they reused some numbers that overlapped stuff that was 20 years out of date.

                Virtual86 and Real86 are for running 8086 programs, that design is from 1978 - 40 years ago.

                1 0 Reply
            2. Joe Montana
              Reply Icon

              Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

              NTVDM uses vm86 mode on 32bit x86, but on other architectures (mips, ppc, alpha) it would emulate the cpu... There's no reason they couldn't use an emulation mode for 64bit x86 too, dosbox works fine like that.

              0 0 Reply
        2. Anonymous Coward
          Reply Icon
          Anonymous Coward

          "Somebody never tried Windows XP-x64..."

          Just, Windows 2003 64 bit worked flawlessly, and it run 32 bit code without issues. I know because we used it to run several 32 bit processes at once, each with its 4GB memory space, on a Windows machine that eventually can use more than 4GB of RAM without PAE/AWE trickery.

          XP 64 derived from 2003 64, but it is true it was somewhat "unfinished", and not many hardware OEM bothered to make drivers for it. But it is also true very few had a real reason to use it. On the server side, OEM provided 64 bit drivers for their systems.

          From desktop users perspective, especially consumer ones, there are very little benefits to move to a 64 bit OS until you have more than 4GB of RAM, and low-end machines with 8GB of RAM or more became common only recently. Very few consumer applications would benefit from 64 bit arithmetic, most benefit come from the larger address space, but you also need applications who can use it.

          3 0 Reply
        3. Anonymous Coward
          Reply Icon
          Anonymous Coward

          Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

          It is a problem for Apple as well. They have served notice that 32bit apps will not be supported but there are still holdouts. The Drobo desktop is still 32bit.

          Linux can be a PITA with lots of stuff still needing 32bit libraries. Come on Distros, get it sorted.

          I wish MS well in getting everything moved to 64bit (I probably need to go and sit down in a darkened room). The hardware has been 64bit for at least 5 years now so it really should be time to pension off 32bit binaries.

          3 1 Reply
          1. Richard Plinston
            Reply Icon

            Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

            > Linux can be a PITA with lots of stuff still needing 32bit libraries.

            In what way ? If you need 32bit libraries they are still there with most distros. Install a 32bit app from the repository and the appropriate libraries will automatically be installed.

            > I wish MS well in getting everything moved to 64bit (I probably need to go and sit down in a darkened room). The hardware has been 64bit for at least 5 years now so it really should be time to pension off 32bit binaries.

            And you complained about losing 20 year old 16bit stuff !!!

            Actually, Microsoft is reviving 32 bit with its ARM/x86 hybrid that will only run 32bit x86. Users are going to be pissed when it won't run the software they use on their desktops.

            4 0 Reply
        4. BinkyTheMagicPaperclip Silver badge
          Reply Icon

          Re: Going from 32 to 64 bit was so simple nobody really noticed it happened

          XP 64 was intended for very specific uses, not general purpose, as it was basically a neutered version of Windows Server 2003. It would run the apps that needed access to plenty of memory (as they would normally be designed for Windows Server) without the cost of a Windows Server license.

          To be fair, Alpha and Itanium were the only non Intel architectures that really succeeded. The other platforms didn't survive beyond NT4 SP3 (I think some gave up at SP1, i.e. immediately..).

          It's also worth mentioning, as has been noted above, that platforms are decidedly unequal on Unix. For the major commercial Unixes, I don't think Solaris Intel was *that* different to Solaris Sparc, except for functionality specifically enabled by the Sparc architecture. On the free Unix side there are many differences : the booting process varies wildly, some platforms don't have X, or support a very limited set of graphics cards. Then after finding that the platform does support X, and networking, none of the major browsers are supported as the build process and dependencies are considerable...

          4 0 Reply

      3. This post has been deleted by its author

      4. Doctor Syntax Silver badge
        Reply Icon

        Re: "However it is really difficult for them to change"

        "Backward binary compatibility has always been excellent, unlike some Unix where you can't run applications on a newer system unless your recompile them because binaries won't work."

        Yup. It was an absolute scandal that Solaris binaries wouldn't run on HPUX.

        Wasn't part of WIndows' problem that sometimes they had backwards bug compatibility because stuff like use-after-free was used in "important" applications?

        14 5 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          "Yup. It was an absolute scandal that Solaris binaries wouldn't run on HPUX."

          No, it's an absolute scandal you could not run the same binaries on different releases of the same distro of Linux... because breaking changes in libraries didn't allow that.

          Or 64-bit only distro you couldn't run 32 bit applications on unless you reconfigured them explicitly.

          "Wasn't part of WIndows' problem that sometimes they had backwards bug compatibility"

          I guess you are referring to old DOS applications like Flight Simulator - anyway Windows has a lot of specific support for allowing old applications to run. Read Raymond Chen's "The Old New Thing" blog to discover how far Microsoft went to ensure backward compatibility with bad written applications because some "500 Fortune" company relied on them and MS had to support them.

          4 7 Reply
          1. Hans 1
            Reply Icon
            Coat

            Re: "Yup. It was an absolute scandal that Solaris binaries wouldn't run on HPUX."

            No, it's an absolute scandal you could not run the same binaries on different releases of the same distro of Linux... because breaking changes in libraries didn't allow that.

            LD_LIBRARY_PATH is your friend. Now, this works on all ELF platforms, so Linux, as well as a bunch of UNIX systems, including the BSD's, Solaris and HP-UX* on iTanic .

            No such thing as DLL hell on *NIX.

            HP-UX has readelf: http://www.polarhome.com/service/man/?qf=readelf&tf=2&of=HP-UX&sf=1

            2 2 Reply
            1. Anonymous Coward
              Reply Icon
              Anonymous Coward

              Re: "Yup. It was an absolute scandal that Solaris binaries wouldn't run on HPUX."

              Try to run on CentOS 6 anything that require an updated GLIBC - LD_LIBRARY_PATH *is* not your friend....

              0 0 Reply
      5. Richard Plinston
        Reply Icon

        Re: "However it is really difficult for them to change"

        > Windows users do expect compatibility at the binary level.

        Most Windows users do not know that there are computers that are not x86. 'Binary incompatibility' is not a concept they are aware of. When Windows RT was available they expected to be able to run their existing applications on it. When Windows 10 IOT was announced for running on Raspberry Pi they thought they would be able to use a $35 computer to run a full desktop and Halo 5.

        > The only problem came when AMD dropped the Virtual86 mode in 64 bit mode so Windows 64 bit could no longer run 16 bit applications outside a full virtual machine.

        > It was an AMD decision, nor Microsoft nor Intel took it.

        Intel and Microsoft were perfectly free to continue developing Itanium for their 64bit systems. Of course those didn't do Virtual86 either, and neither did it do x86 32bit (except by emulation).

        > Going from 32 to 64 bit was so simple nobody really noticed it happened, but the availability of far more RAM.

        That was directly the result of an _AMD_ decision !!! Microsoft and Intel had to change course from their 'Itanic' decision to follow AMD.

        The instructions added to make x86 into AMD64 overlapped with some of the old 16bit instructions. This was a technical issue because the instruction set has a finite number of different operation codes. Thus the chip can _either_ do V86 _or_ AMD64.

        The 8086 (and later) couldn't do 8080 or 8085 either*. That was an Intel decision. Old stuff gets dropped, get over it.

        * actually the NEC V20 and V30 chips could do both 8086 and 8080.

        4 1 Reply
      6. Joe Montana
        Reply Icon

        Re: "However it is really difficult for them to change"

        Binary backward compatibility on unix is excellent too at the kernel level, the problems people encounter are due to distros not shipping the expected old versions of libraries but there is nothing stopping you adding those libs and having everything work...

        Microsoft ship with mountains of backwards compatibility libs, linux generally doesn't because 99% of applications come with source and can thus be recompiled against the newer libs.

        2 0 Reply
    5. david 12 Silver badge
      Reply Icon

      Re: Wedded to Intel

      Not to downplay the commercial success of wintel, but MS was a multi-platform company right from the start. Their product, MS Basic, was provided on scores of OS and hardware platforms. As was MS DOS:

      Like unix at the time, non-intel-MSDOS wasn't binary compatible, you had to compile for the specific platform. And non-PC-clone-MSDOS was only binary compatible if you used the OS primitives instead of PC-mapped hardware. That meant no DMA, no memory-mapped graphics, etc.

      So different platforms have always been part of the MS programmer expectation, part of the culture.

      1 5 Reply
      1. Richard Plinston
        Reply Icon

        Re: Wedded to Intel

        > MS was a multi-platform company right from the start.

        As was the whole personal computer and microcomputer industry from the mid 70s.

        > As was MS DOS:

        MS-DOS was Intel 8086/8088* only. It could be used on many different architectures (as long as they used 8088 or 8086) because each OEM had to write their own MS-BIOS to deal with the actual I/O hardware. This mechanism was copied from DRI's CP/M. It wasn't "provided" for score of architectures, the OEMs had to do it.

        > So different platforms have always been part of the MS programmer expectation, part of the culture.

        That was true a couple of developer generations ago. MS Basic on 6502 and 6800 was 40 years or more ago. The last MS-DOS that ran on non-IBM-PC-Clones was 4.x. Sure, if you're a developer now retired or moved to management then you may have dim memories of a time before.

        > So different platforms have always been part of the MS programmer expectation, part of the culture.

        Not for the current generation of developer and users it isn't. They were confused by RT and failed to buy it in droves, and returned it when they did buy it. Windows is Windows, if it doesn't run program x, then it is a failure.

        * There was MSX-DOS for MSX machines that ran on Z80 but it was a CP/M clone, not a version of MS-DOS. There was also MS-DOS 4.0 and 4.1 (not to be confused with the later 4.01) that was 80286 based but this was soon dumped.

        3 0 Reply
  2. Blotto Silver badge
    Facepalm

    Oh no not again...........

    did they not learn from last time?

    funny how the press are whipping this up to be great again..............

    9 4 Reply
  3. Refugee from Windows

    Playing catchup

    This is a game that Microsoft haven't put much effort into, and I'm afraid to say that they are so far behind I don't think they'll ever catch up. Being tied down to x86 has turned them into a one trick pony, and their speciality is wearing thin. ARM is likely to become the most popular platform from both embedded through to servers, if it hasn't already overtaken already, and so they are primarily in a declining market. They're playing second fiddle to Google.

    They've not even woken up to this, let alone smelt the coffee.

    11 7 Reply
  4. Andy Mac

    What really struck me with the folly of RT was calling it Windows at all. No-one ever complained that an iPad couldn’t do what a Mac could do, because they were clearly separate products (plus Apple had set the scene with the iPhone first).

    But calling something Windows which can’t run Windows applications seems a bit, well, dumb.

    58 0 Reply
    1. Jay 2
      Reply Icon

      Can't agree enough. I commented at the time that no good would come of having three different (and non-compatible) products called Windows 8 and sharing the same interface. An interface that was an OK idea on touch devices, but was stunningly un-suited to a traditional keyboard/mouse setup. The most stupid thing is that as soon as the public saw/used Windows 8 on a PC in test/beta they said it was shit and Microsoft decided they were all wrong and continued as planned.

      Windows 8 x86/x64 != Windows 8 RT != Windows Mobile 8 (or whatever it was called)

      26 0 Reply
      1. Richard Plinston
        Reply Icon

        > Windows 8 x86/x64 != Windows 8 RT != Windows Mobile 8 (or whatever it was called)

        You missed Windows 8 IOT (later there was Windows 10 IOT) which was completely different yet again.

        3 0 Reply
    2. John Smith 19 Gold badge
      Reply Icon
      Unhappy

      "But calling something Windows which can’t run Windows applications seems a bit,..dumb."

      Not at all.

      "Compatibility" is basically why people put up with Microsoft's s**t.

      I've lost count of the number of times Microsoft has claimed "Our new tablet/phone/watch is compatible with your desktop windows" (going pack to the "poquet PC" days) and turned out to be complete BS. That spreadsheet you wrote. Sorry, not going to run. That Word doc you wrote. Nothing you can't cut n paste from, eh?

      If they didn't call it "Windows" WTF would you buy it?

      5 3 Reply
    3. Wade Burchette
      Reply Icon

      Agreed. People use Windows because their programs from 20 years ago still work. It is the legacy compatibility. Windows on ARM takes that away. The whole purpose of it, like Windows 8 and 10, is to pad Microsoft's wallet and not what the customer wants. With Win on Arm you are limited to the Windows Store which conveniently gives Microsoft a cut of all sales. That Microsoft wants it to succeed, because now you will have to buy new apps from them. Windows on ARM will never succeed unless I can still install programs released 20 years ago and 1 year ago.

      12 1 Reply

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like