If Office can run "natively" on Surface Pro X


Why cannot other Win 32 programs follow the same approach? Microsoft Edge also runs “natively” on Surface Pro X.

More generally, will all .Net programs be able to do the same?

Comments (6)

6 responses to “If Office can run "natively" on Surface Pro X”

  1. Paul Thurrott

    Office is a really complex set of applications. I don't have a Surface Pro X, but for the most part, the Office apps run great on the 8cx-based Flex 5G, which should offer similar performance.

  2. SWCetacean

    To some extent, I believe most Win32 programs already do what Office does to a degree. All of the Windows libraries are CHPE, so any app that uses the Windows libraries to do their heavy lifting will already be taking advantage of native library code. The advantage that Office has is that its application-specific libraries are also CHPEs. Basically the Office DLL files that the apps load are CHPE. Any 3rd-party app needs to recompile its own libraries as CHPE to be able to gain Office's performance improvements. And I don't think Microsoft has released developer tools to create CHPE libraries.

    The new Microsoft Edge is simply a natively-compiled Arm64 executable. No CHPE there, given that its platform shows up at "64-bit" in Task Manager. On a related note, Microsoft should put the actual architecture in Task Manager (i.e. x86, x64, arm32, arm64).

    • alsorun

      In reply to SWCetacean:

      Your explanation is great. So if a program heavily uses Windows system level library, it will not suffer too much from emulation from X68 to arm.

      But how do they make Edge arm 64 native? Office is too complex to make it arm 64 native?

      • SWCetacean

        In reply to alsorun:

        For Edge, they recompiled everything for arm64, and made the necessary code changes to ensure that it runs well on Arm. This is more complicated for browsers because browsers generate native code from javascript and other web code. I'm not that familiar with the technical underpinnings of Javascript compilers, but I think with an emulated x86 browser, you pay the emulation penalty twice: once for the x86 browser code, and again for the x86 code that is generated from the Javascript. The Edge team I think modified their Javascript compiler in Arm64 Edge to generate Arm64 code from Javascript.

        For Office, they kept the executables as 32-bit x86 to ensure compatibility with plugins. CHPE libraries are Arm64 code that use x86 calling conventions so that x86 programs can call functions in those libraries without issue. There's no technical reason that Office can't be made fully Arm64 (and I think the tablet-focused Office Mobile products are completely Arm32 on Windows on Arm), but using CHPE preserves compatibility. Lack of plugin compatibility was part of what sank Office RT, the version that was included with Windows RT tablets.

        As for your first question, it depends how much a program uses the Windows libraries vs their own libraries. If a program spends like 80% of its time running Windows library code, then the penalty will be lower than if it only spends 10% of its time in Windows code and the rest of it running its own code. The thing is that most programs don't spend most of their time just calling Windows code, they spend it running their own code.

        And the type of program and the kind of code also factors into it. The x86-Arm64 translation service will cache translated code, so if a program doesn't modify or generate code as it runs, the performance will get better as the Arm64 translations are saved for future use (note that I don't know if the translations are saved to disk, or if they have to be retranslated every time the program is run). From my experience, I use a music player called MusicBee that's an x86 emulated program. For normal usage, I can find very few differences in performance between it on my SPX and it running on my gaming desktop with a Ryzen 7 3700X. The only area where I notice MusicBee being slower on my SPX is when I have it generate a waveform for the song that's currently playing. It will take a second or 2 for the waveform to show up while that occurs instantly on my desktop. Waveform generation is more involved than displaying cover art and playing a file, and requires signal analysis code so I'm guessing that the signal analysis code suffers more from the x86-Arm64 emulation.

Leave a Reply