The Office apps for Android and iOS appear to have deep ties to the Windows API. A programmer going by the name of "Longhorn" and I recently took apart the Office applications for Android and iOS and inspected their code and content. This process is known as reverse-engineering. We found that they have a lot in common with the versions found on Windows 10 Mobile, and in some cases, with Windows 10, depending on the version you use.
Virtualised registry
Longhorn and I noticed that if you dig into the apps, you see that they offer almost identical Virtualized Registry Containers (VRC) as Universal Windows Platform (UWP) apps. What are VRCs? They are essentially copies of a system registry which are sandboxed and secured so they don't have contact with the system itself, so they don't break anything.
And what is a registry? The registry is essentially a database of different system settings and configurations that the apps need to access in order to adjust to specific system configurations and respect settings the user has set. The registry is built deep into Windows itself and has been since Windows 3.1. As this is a Windows component, iOS and Android do not include their own registries in the system, which leads to these VRCs to be present in the Office apps. By having a registry, these apps prove that they have some kind of Windows sub-system built in, which also explains the mediocre performance the Office apps offer.
Every UWP app, including Project Centennial apps, has its own registry so it doesn't mess with the system registry, bloat it down and break functionality like some incompatible legacy programs do. These registry containers are not actually necessary for UWP apps to work, but they are there for security and performance reasons. This is not the case with Android and iOS, making the VRCs obligatory for the apps to function at all.
Microsoft libraries
The performance of the Office apps on both iOS and Android has never been perfect. It's not bad, however, and navigating through the apps is pretty snappy. But the boot times can be slow and take a couple of seconds to open. This could have been blamed on poor coding, but if you count the compatibility layer Microsoft is using, it all fits into the puzzle. Xamarin, a powerful cross-platform tool which Microsoft bought last year, is pretty infamous among developers for its poor performance, because running the same code on completely different platforms is not an easy task.
Microsoft developed a powerful compatibility layer, allowing Windows components to run on other OSes, similarly to what "Wine is not an emulator" (Wine) has been doing for many years on platforms such as Linux, BSDs, macOS and even Android. The concept is the same: Running Windows applications on non-Windows-NT based systems. With this project, Microsoft developed multiple libraries that all bring a small part of Windows, and those libraries are:
- lib7zofficeassetdecoder.
- libd2d1.
- libplat.
- libd3d10warp.
- libdwrite.
- libmsxml.
- librichedit.
- libxmllite.
- libstg.
These names may not tell you much, and while some of them are less interesting, one rendered us speechless: libplat.
libplat includes a good chunk of the Windows API which essentially creates a Windows environment right on your device. We didn't have much luck in capturing the iOS libraries. However, based on the virtual registry found in iOS and the identical behavior of the apps, we suspect that the case is the same for iOS. This Windows-like environment that Office creates is not visible to the user, but it's definitely there in the background. A regular consumer would not notice any difference between UWP-like apps like these and native ones, which is a good thing because it means the porting technology is well done.
lib7zofficeassetdecoder is responsible for the long time spent on the first launch, and a launch after an update. Office on Android is so big that libraries and UI assets are compressed. This is the cause of the huge storage requirement boost after first launching the apps.
These heavy libraries are accompanied by other libraries, such as libd3d10warp, which is the most promising one out of all of these because it includes DirectX rendering, which could lead to something really big one day.
DirectX
DirectX is a very powerful graphics API. It's the core of virtually every game you've played on Windows or Xbox, and it's one of the biggest reasons why Windows has a gaming dominance over other platforms like macOS and Linux. This API has been discovered in Office for Android and iOS, under the library "libd3d10warp," as well, which is also interesting.
The DirectX rendering found in Office is still only software-based rendering, which means it's far from usable for things like games or GPU intensive tasks, but it does use the Windows Advanced Rasterization Platform (WARP). WARP is a full-featured Direct3D 10.1 renderer device, which is a very efficient implementation of software rendering and it definitely gets the job done for smaller things like rendering Office. The Office apps may be slow, but they are butter smooth with consistent frame rates and enjoyable animations, wall thanks to WARP.
This DirectX rendering could one day evolve from being just a software-based rendering system to a full-fledged hardware-rendered graphics API, which would open up a whole new world of possibilities for iOS and Android developers.
What does this mean for consumers and developers?
There is no official documentation of the technology used behind the Office apps, but this could change in the future. Microsoft already has the Xamarin development environment. However, it's not really a way of running UWP apps on other platforms because it requires writing the applications you want to be cross-platform from scratch. If this project ever gets released to the public, it could mean full UWP apps running on every major platform in the world.
As Windows 10 Mobile is slowly dying, and the chances of it ever reaching a major market share decreasing, Microsoft may be look for a way to boost developer interest in UWP. And putting this trojan horse inside Apple's and Google's popular mobile platforms may be exactly what Microsoft needs.
