back to article Windows on Arm keeps low profile at IFA as Intel takes swipe at platform's compatibility problems

Is Windows on Arm a thing? Yes, both Samsung and Lenovo had models on display at IFA in Berlin. But it has yet to take off with the great majority of laptops running Intel or AMD chipsets. Windows on Arm runs either applications compiled for ARM32 or ARM64, or x86 applications under emulation. It will not run x64 applications …

  1. theOtherJT Silver badge

    An answer in search of a question

    I don't think anyone actually wants Windows on Arm. I think people want all the Windows only applications that they've become wedded to (sometimes via shotgun, admittedly) on Arm - and the thing that keeps coming back time and time again with Microsoft's attempts to push this is that they won't get that. They'll get some vaguely-similar-but-not-quite things plus that stuff that was trivial to emulate - so didn't actually need Windows in the first place.

    It's not Windiows that sells Windows. It's the Windows application ecosystem, and this doesn't get us that.

    1. disco_stu

      Re: An answer in search of a question

      What Windows on ARM really needs is x64 application compatibility, I imagine the performance overhead of emulating x64 on ARM means this is going to be a non starter for a while.

      1. AMBxx Silver badge

        Re: An answer in search of a question

        Maybe Windows on Arm is just a big stick for Microsoft to beat Intel with. Make your CPUs more efficient or we do WoA.

        1. Richard Plinston

          Re: An answer in search of a question

          > Maybe Windows on Arm is just a big stick for Microsoft to beat Intel with.

          Previous iterations of WoA, which became Windows RT, was a big stick to beat OEMs with: "Make your ARM devices run WoA or lose your 'loyalty' discounts on _all_ devices and computers."

          This worked for HP and WebOS.

          Actually i think that this iteration of WoA is to beat OEMs who think they can make ChromeBooks and still keep their discounts. It would be a shame if they had to pay retail prices for Windows 10 and Office to install on their PCs and laptops they wanted to sell.

          Similarly they revived XP to beat netbook making OEMs who thought they could get away with running Linux.

      2. Christian Berger

        It's probably not the performance overhead

        But Intel and AMD have lots of patents regarding x64. Any commercial emulator would need to license those, and both companies don't seem to be open to licensing their patents.

        What they could do in theory is to emulate a 15 year old version of x86. That might even work as most of the software that depends on x86 and Windows is old enough to not need anything newer. In any case it's better than nothing.

  2. alain williams Silver badge

    I can't see what the fuss is all about

    Almost 40 years ago I ported applications onto at least 3 completely different sorts of hardware before I considered them ready to release. It was not hard, I just had to be aware of what lint and the C compiler told me. That was UNIX, pretty much the same under Linux these days - although the range of widespread different forms of hardware is less.

    So: why, all these years later, is this a big thing in the Microsoft world ? Are they still trying to catch up ?

    1. Anonymous Coward
      Anonymous Coward

      Re: I can't see what the fuss is all about

      The clue is in the chipset name. .CX? That'll get your goats...

    2. Anonymous Coward
      Anonymous Coward

      "Almost 40 years ago I ported applications"

      Yes, it was 40 years ago. It was far easier back then - as the CPUs were far less complex, and with that all the low level-stuff. Just think today about the different SIMD implementations.

      Today it's difficult even to achieve good GUI application portability across Linux distros - that's why a lot of what you see is actually written in Java because it takes care of the portability issues, especially for complex applications.

      1. joeldillon

        Re: "Almost 40 years ago I ported applications"

        No mate, it really wasn't. So many different weird Unixes back in the day.

        What does SIMD have to do with it? How many applications out there have handcoded assembler SIMD stuff for different CPUs? You don't need that for most stuff.

        What universe are you living in where most Gnome or KDE apps are written in Java?

        1. Anonymous Coward
          Anonymous Coward

          Re: "Almost 40 years ago I ported applications"

          Oh my god, another graybeard still thinking 40 years ago he learned all he needed to learn, and nothing changed from the days Unix was carved into animal bones with a C shaped stone.

          40 years ago stuff was much, much easier. Not surprisingly even NT run on Alpha and MIPS.

          There are a lot of Intel highly optimized SIMD libraries around, which are not simple to port to ARM.

          And today you need SIMD for a lot of stuff, of course when you are not writing 40 years old applications. Even your C compiler today can use SIMD instructions to speed up computations even when you're not aware of it. Very often, the FPU is not used and SIMD kicks in. And today graphics manipulations does need very fast computations. Motif-like UIs are long dead.

          Just recompiling them it's not enough. Threading and synchronization primitives could be another issue. How many highly concurrent applications were you writing 40 years ago?

          Your average application today is far more complex than whatever you wrote 40 years ago.

          Why Linux lacks so many GUI applications? You named already two different libraries you have to cope with, plus the different versions and often lack of compatibility. Plus the libraries that attempts to be a layer atop them like Qt or wxWidgets. Heck, even with web applications you may have browser compatibility issues.

          Put a very different hardware architecture into the mix and things becomes even more complex.

          Write once, run anywhere it's still the Graal of IT - and nobody ever got close to it - especially for complex, highly interactive applications.

          1. mevets

            Re: "Almost 40 years ago I ported applications"

            NT was first written for a non-x86 cpu. And os portability across cpus has never been much of a big deal.

            SIMD is primarily a compiler concern; and 40 years ago, SIMD was a huge deal, just it was called an array processor and parallelizing fortran compilers did most of the heavy lifting.

            Badly implemented libraries and apps is precisely what the OP is getting at -- why is so much modern software such crap? Weak, over-featured, under-engineered.

            If the average app is more complicated; that is solely the fault of the designer (or is it scrum master). Machines are far more modular in computational units now than then. You could excuse some rancid crap like office, since deploying it in a proper fashion would have been terribly slow. That is not true today, yet the monolithic mentality remains.

            Yeah, linux remains a mess with multiple choices of everything and nothing inter-operates. sad.

            Hardware architectures are less different today than ever; mulit-core; forward mapped page table sets; gobs of registers; linear address spaces. Hell ARM even added all the intel atomic memory ops.

            Plan 9 did a petty nice job of write once. Didn't need a multi-level interpreter and VM to do it. The gui was consistent, the network service architecture scalable and secure. If Linux keeps at it, it might reach this point in another decade or so.

      2. Richard Plinston

        Re: "Almost 40 years ago I ported applications"

        > Today it's difficult even to achieve good GUI application portability across Linux distros

        Complete nonsense - is that you, RICHTO/TheVogan? still churning out uninformed dogma for 30 years?

    3. Warm Braw

      Re: I can't see what the fuss is all about

      Almost 40 years ago I ported some ICL FORTRAN applications to IBM hardware and it was a nightmare - different character sets, different packing of binary data into data types, differences in COMMON alignment, differences in I/O, etc.

      Given that K&R didn't appear until 1978 you were lucky to have such conformant compilers - or trivial applications. My copy of Advanced Unix Programming (dated 1985) contains 250 pages on the different ways things were done in AT&T Unixes (System III, System V, Version 7), BSD and Xenix (a product from the Microsoft world). And that was before the ubiquity of GUIs...

      Getting 32-bit applications to work on ARM is probably in principle good enough for this class of device, but the problem with the last iteration of Windows on ARM was user confusion - RT didn't run any traditional Windows applications, Windows on ARM won't run all of them. Perhaps the solution is something that will run Windows applications, but isn't actually Windows. I'd be extremely surprised if Microsoft doesn't have a Windows on Linux project hidden in a basement somewhere.

    4. MacroRodent

      Re: I can't see what the fuss is all about

      Yes, it is the GUI that spoils portability. Making command-line or text-only applications portable is trivial these days, even between Linux and Windows. Especially compared to the Elder Days, when C compilers had far more quirks, bugs and differences in what variant of C they accepted. (Actually you can nowadays cheat here and use GCC on Windows, too).

      1. Richard Plinston

        Re: I can't see what the fuss is all about

        > Yes, it is the GUI that spoils portability.

        In the past I have written Python/Glade GUI applications that ran on Linux, Windows and Nokia N800 (small ARM tablet) with no code changes and no recompiles. Just make sure that the GTK libraries are installed, load and run.

        1. MacroRodent

          Re: I can't see what the fuss is all about

          > written Python/Glade GUI applications that ran on Linux, Windows and Nokia N800

          Sure, and you can do the same with Java and some other cross-platform languages or toolkits. But then your code is dependent on the tookit or runtime, a large 3.party component with its on versioning and deployment issues.

          1. Richard Plinston

            Re: I can't see what the fuss is all about

            > Sure, and you can do the same with Java and some other cross-platform languages or toolkits.

            Exactly. There are many GUIs for Linux and most are cross platform.

            > versioning and deployment issues.

            Just like Windows has.

            1. MacroRodent

              Re: I can't see what the fuss is all about

              >> versioning and deployment issues.

              > Just like Windows has.

              Yes, but when you use the cross-platform toolkit or runtime, you in effect have two window system libraries to worry about, not one. An incompatible change in either may spoil your day.

              1. Richard Plinston

                Re: I can't see what the fuss is all about

                > An incompatible change in either may spoil your day.

                Actually I see it the other way. The cross-platform layer will cope with changes in the OS layers better than application code using that directly. Given that Microsoft has dead-ended or re-implemented several of its toolkits over the years some isolation from this may be appropriate.

    5. BinkyTheMagicPaperclip Silver badge

      Re: I can't see what the fuss is all about

      Companies cannot be bothered to support multiple platforms, and as mentioned elsewhere for applications with platform specific optimisation whilst a port might be reasonably straightforward, a port with appropriate performance can take a great deal of effort.

      Windows is little endian everywhere, so for a basic port even that obstacle is removed. It has pretty much always been multi platform, with possibly only a small gap between the end of itanium support, and the beginning of ARM support (beyond x86/x64).

      1. Richard Plinston

        Re: I can't see what the fuss is all about

        > It has pretty much always been multi platform

        NT yes. Windows 1 to 3 was 8086, 80286 and 80386. NT was written on MIPS because the contemporary 20MHz 80386 was not up to doing the job.

        But it is the applications that have not been multi-platform. Office had to run in a form of emulation mode on Alpha and the RT version was very cut down and still needed Win32 libraries that were unavailable to other applications.

        Most applications can't or won't be ported to other CPUs making it pointless to run Windows on anything but Intel/AMD.

        Even though this WoA will run x86 (32bit only and slowly) many applications are 64bit only now. I recall when MS was trying to force everyone to 64bit by announcing that Windows 7 was the 'last 32bit version'.

        1. BinkyTheMagicPaperclip Silver badge

          Re: I can't see what the fuss is all about

          I didn't think I needed to be pedantic enough to point out that I'm talking about NT here.

          NT was actually initially developed for the intel i860, the other platforms came later. MIPS was killed off almost immediately after the release of NT 4.

          Alpha included FX!32, but had native versions of at least some of the Office apps and a load of the server applications.

          Yes, the fact that applications won't be ported was the entire point of my post.

          There's little reason not to move applications to x64 - although the memory usage will generally increase, x64 apps automatically gain access to additional registers, so will probably run faster.

          1. Richard Plinston

            Re: I can't see what the fuss is all about

            > There's little reason not to move applications to x64

            Now there is one: WoA, which Microsoft is pushing against ChromeOS, will only run 32 bit x86.

  3. DrXym

    A totally pointless exercise

    A version of Windows that is not compatible with Windows software is as useful as a chocolate teapot. Even if Microsoft lob in some kind of x86 emulation that works for *some* software, the reality is that it will still suck - any vaunted power efficiences of ARM are lost from the burden of emulation, and stuff runs at speeds that even the worst atom processor could outpace. What's the point?

    1. analyzer

      Re: A totally pointless exercise

      Just to put that to bed chocolate teapots work after a fashion and are also very tasty so not entirely pointless, just mostly

    2. mevets

      Re: A totally pointless exercise

      I don't think windows is the goal; but it is a good way to show viability. The real goal should be something based on the RISC-V, so that the manufacture can work within an open ecosystem for chips and system software. Reduce intel, arm, microsoft, ... to the parts suppliers they really are.

  4. jelabarre59

    Power-ful

    So how about MSWin on Power, then? Something to run inside all those Openstack instances on Power9.

  5. Lorribot

    If MS released a copy of Windows that could be put on old tablets and other old kit for people to play with and start generating some interest in the tech community they might start getting some traction.

  6. Jason Hindle

    Apple will gazump Microsoft and get there first

    With the first fully 5G, ARM based laptops with little (if no) noticeable performance penalty. Apple's lead in chip design pretty much determines events. It won’t affect Microsoft too much though - not for most of the money. If nothing else, Microsoft has time. It is Google and Chromebook that still vexes me. The best devices are still Intel based/sans SIM. What the hell are they playing at?

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like