Support for Windows on Arm

[pbo-linaro]

Hi,

What is your question?
Linaro is currently working with Microsoft to help develop Windows on Arm ecosystem.
For this task, we would like to be able to use containers to create reproducible builds.

docker x64 binaries are working, thanks to Win 11 x64 emulation.
For technical reasons, we must use process level isolation (hyper-v is not available in our environment).
However, there is no base image matching our host yet (its architecture).

When running docker:
an error during hcsshim::System::Start: failure in a Windows system call: The container operating system does not match the host operating system. (0xc0370101).

We understand that it's difficult to bring support for this new platform, but is there a way to generate a windows base image ourselves (from an existing system)?
If not, is there a way to bypass this match check, to "force" a container to run?

Thanks,
Pierrick

[brasmith-ms]

Hey @pbo-linaro, thanks for this comment. ARM support is not available at the moment, but it's definitely on our roadmap. I can't promise any timelines on this, but it's good to continue to see asks for the feature. Creating new images from the binaries on the existing system is not currently possible either, primarily because it is against the Windows server license terms to repackage and distribute Windows OS binaries.

[pbo-linaro]

Thanks for your answer. Beyond licensing issue, is there something technical than can prevent it? The aim is not to redistribute anything, just to build/use an image locally.

[pbo-linaro]

For someone aking question "Why process level isolation needs same version of windows?", here is the reason.

To the opposite of Linux, Windows syscall interface is not stable. It can (and will) change between versions. A list is available here: https://hfiref0x.github.io/syscalls.html. Thus, the same approach than Linux containerization can't be used.

The only stable interface is Win32 API (that's what wine project is targetting). It is implemented as a list of dll, and I assume this is what must be present in your container.

From there, probably that Windows container runtime is having a translation layer between versions, or simply injecting it's own ntdll library directly in the running container. Who knows?

See a list of windows layers there: https://en.wikipedia.org/wiki/Microsoft_Windows_library_files

[driver1998]

IIRC there is a "Windows" image which is a specialized Windows 10/11 Enterprise image, not Windows Server. If Windows Server on ARM is not going to be public, providing Windows Client container base image would still be valuable.

[TBBle]

The Windows image is only currently maintained for Windows Server 2019, and has been replaced with the Windows Server image from the Windows Server 2022 release onwards, as the Windows Server and (Client) Windows release cycles have diverged.

Anecdotally, I recall seeing mentioned somewhere that even that "Windows" image was actually a Windows Server build configured to work like (Client) Windows (including IIS connection limits, etc), rather than just a containerised copy of the relevant Windows 10 release. (Assuming I am remembering correctly) This was possible because at the time, Windows Server and Windows 10 were releasing with the same cadence.

Sadly, we haven't heard anything public about Windows Server on ARM since 2017 as far as I know, and Windows Containers is part of the Windows Server development roadmap, so without Windows Server on ARM, we aren't going to see Windows Containers on ARM either. (Although if and when we do get Windows Server on ARM, I expect Windows Containers support to be run-up pretty quickly.)