コンピュータプログラムは、本質的にかなり異なる傾向があります。ささいな "hello world!" を実行できます。たとえば、本格的な OS を使用することもできます。
「拡張マシンとしてのオペレーティング システム」および「リソース マネージャーとしてのオペレーティング システム」という古典的な定義 (Tanenbaum による) を持つ OS は、多くのことを提供する必要があります。
OS がリソース マネージャーとして機能する必要がある場合、OS は、起動、割り込み、I/O、セキュリティ モードなどの機能を制御する基盤となるマシンの必要最低限の部分で実行されているだけです。Windows のソース コードを調べて確認することはできませんが、 x86 と ARM アーキテクチャの両方で既に実行されているオープン ソースの競合他社 (Linux) を見ると、これらの側面の違いは何ですか。
Linux では、異なるアーキテクチャのサポートはarchディレクトリにあります。たとえば、x86ディレクトリとARMディレクトリがあります。そこにあるディレクトリ名を確認するだけでも、必要な作業 (ブート、電源、メモリ管理など) に関するヒントが得られると思います。
ARM と x86 の世界にはかなりの違いがあります。x86 では、ほとんどすべてが標準化されており ( IBM PC 互換について聞いたことがありますか?)、多くのベンダーがアーキテクチャのクローンを構築しています。それとは対照的に、ARM エコシステムでは、ARM 会社自体が単なる IP プロバイダーであり、すべてのベンダーが互いにわずかな違いから大きな違いを持っています (mach で始まる arch フォルダーのサブディレクトリ名を確認してください - これはマシン用、または plat - それはプラットフォーム用です)。 . ARM では、 UEFIを使用した最近の開発の直前に BIOS のようなものはありませんでしたが、これはまだ大規模に実装されていません (BIOS が良いとも悪いとも言いませんが、単なる例です)。
Windows をあるべき姿にする OS の「拡張マシン」の役割については、移植は比較的容易なはずです。これは主に、ハードディスク パーティション「c:」の呼び出しなどの機能に関するものです。読み取り専用または非表示などのファイル アクセス許可を持ち、Win32 API などのコア API をほぼ機能させます。繰り返しますが、これは単純ではありません。
私は、品質と市場投入までのスピードを確保するために、MS が Linux の非常にオープンな世界と比較して、どの種類の ARM マシンで Windows がどの種類の周辺機器で実行できるかを厳密に定義することを期待しています。
これらは、私が想像できる問題の 2 つの大きなトラックですが、ターンごとに次のような小さな問題が発生する可能性があります。ARM は 32 ビット RISC アーキテクチャであり、char は符号なしであり、最近のハイエンド ARM コアでさえ整数除算をサポートしていません (パフォーマンス?)。