I heard that Microsoft ported Windows on ARM chipsets.
I just wondered that what does it mean to port a program to a different chipset. Being a Java programmer I do not know much about the low-level details.
Naively I suppose that Windows is written in a mixture of C, C++ and C#. I’m pretty sure that ARM already had its C and C++ compilers so these codes should have been only recompiled using these compilers. C# needs the .NET interpreter that might be also written in lower level languages and theoretically could be recompiled with the ARM specific C or C++ compiler.
I know of course that the procedure is not so straightforward, so I’d like to learn about the theoretical limitations, possible problems and so on that could make such a procedure difficult.
Note: the question is not specific to the example that I mentioned
Computer programs tends to be quite different in nature. You can have a trivial “hello world!” for example, then you can also have an full-fledged OS.
An OS with classical definitions (from Tanenbaum) of “The Operating System as an Extended Machine” and “The Operating System as a Resource Manager” needs to provide many things.
When OS needs to act as a Resource Manager it is just running on bare bones of the underlying machine controlling its features like booting, interrupts, I/O, security modes, etc. While we can’t look into Windows’ source code to see what are the differences in these aspects we can look at an open source competitor of it which already runs on both x86 and ARM architectures – Linux!
On Linux support for different architectures lays in arch directory. For example we have x86 and ARM directories among many others there. I believe even checking the directory names there gives you a hint on the required effort (boot, power, memory management, etc.)
There are quite differences between ARM and x86 worlds. In x86 pretty much everything is standardized (ever heard about IBM PC compatible?) with many vendors building clones of an architecture. On the contrary in ARM ecosystem, ARM company itself just being an IP provider every vendor has slight to great differences between each other (just check the sub directory names in arch folder starting with mach – that’s for machine, or plat – that’s for platform). With ARM you had nothing like a BIOS just before recent developments with UEFI which is still not vastly implemented (I don’t say BIOS is a good or bad thing, just an example).
For the OS’s “extended machine” role, which makes Windows what it is, porting should be relatively easier. This is mostly about features like calling an hard disk partition “c:” – having of file permissions like read-only or hidden and keeping the core APIs like Win32 API mostly functional. Yet again this is not straight forward.
I’m expecting MS to strictly define on what kind of ARM machine Windows can run on with what kind of peripherals compared to very open world of Linux to secure the quality and speed to market.
These are the two big tracks of problems I can imagine, however then with every turn there can be small issues like; ARM is a 32 bit RISC architecture, char is unsigned, even recent high end ARM cores doesn’t have integer division support (performance?), all those small things Windows code thought for granted might bite them back…