Windows NT vs. Unix: 設計比較
(blogsystem5.substack.com)- NTはしばしば「非常に先進的な」オペレーティングシステムと評価されていたが、その理由はよく分かっていなかった
- 2023年末に『Inside Windows NT』第1版を読み、NTとUnixを比較することにした
- NT（1993年7月）と、当時のUnixシステム（4.4BSD、Linux 1.0）の設計を比較したものである
- Unixの専門家として、NTには詳しくないため、NTの相違点を中心に述べる
- NTがUnixより優れている点は何か、そしてそれが今でも当てはまるのかという問いを扱う
ミッション
- Unixの歴史はNTよりはるかに古い
- Unixの開発は1969年に始まり、主な目標はプログラマーにとって便利なプラットフォームになることだった
- UnixはMulticsに着想を得ていたが、シンプルさに焦点を当てることでMulticsを上回った
- 移植性とマルチタスクはUnix設計の当初の目標ではなかった。これらの機能は数年後、Unixの多くの「フォーク」や再発明の中で追加された
- Microsoftの歴史
- MS-DOSの最初のリリースは1981年8月に発売され、「レガシーWindows」（DOSベースのバージョン）の最初のリリースは1985年11月に発売された
- MS-DOSは広く成功したが、Windowsが本当に重要になったのは1990年5月のWindows 3.0からだった
- Windows NTは1989年に構想され、1993年7月のNT 3.1リリースで世に姿を現した
- Microsoftの優位性
- NTの設計はUnixより20年遅れて始まり、Microsoftに有利に働いた
- MicrosoftはすでにMS-DOSとレガシーWindowsのおかげで大きなユーザーベースを確保していた
- NTを設計したMicrosoftチームは、これらの開発から得た知見、他のオペレーティングシステム開発経験、最新技術へのアクセスを備えており、NTの開発において「月を目指す」ことができた
カーネル
- Unixは、MinixやGNU Hurdのようないくつかの例外を除けば、モノリシックカーネルとして実装されており、オペレーティングシステムが提供する機能と相互作用するためのシステムコール群を公開している
- 一方、NTはモノリシックカーネルとマイクロカーネルの中間形態である。特権コンポーネントである executive は、ユーザー空間の subsystems に対して、自身をモジュール式コンポーネント群として表現する
- ユーザー空間のsubsystemsは、アプリケーションが利用するAPI（POSIX、OS/2など）をexecutiveのシステムコールへ「変換」する特殊なプロセスである
- NT executiveの重要な部分の1つがHALであり、マシンのハードウェアにアクセスするための抽象的な基本要素を提供し、カーネルの残りの部分の基盤として機能する
- この層は、NTがi386、Alpha、PowerPCを含むさまざまなアーキテクチャで動作できるようにする鍵である
- 当時のUnixは特定のアーキテクチャに結び付いていた。Unixの概念は移植可能でも、実装はそうではなかった
- SunOSは当初Motorola 68000しかサポートしておらず、386BSDはBSDをIntelアーキテクチャへ移植した最初の例であり、IRIXはSilicon GraphicsのMIPSベースワークステーション向けUnix派生版だった
- NT executiveのもう1つの重要な部分は、マルチプロセッシングシステムとプリエンプティブカーネルへの対応である
- カーネルには、何が別のものを中断できるかを決めるためのさまざまな割り込みレベル（BSD用語ではSPL）があるが、より重要なのは、カーネルスレッドが別のカーネルスレッドによってプリエンプトされうる点である
- これは今日ではすべての高性能Unixシステムが行っていることだが、多くのUnixが最初からそうだったわけではない
- これらのシステムは、プリエンプションやマルチプロセッシングをサポートしないカーネルから始まり、まずユーザー空間のマルチプロセッシング対応を加え、その後でカーネルプリエンプションを追加した
- 最後の段階が最も難しく、FreeBSD 5.0の騒動がその困難さを示している
- したがって、NTが最初から正しい基盤の上に出発したのは興味深い
オブジェクト
- NTはオブジェクト指向カーネルである
- Unixもそうだと考えることはできる。プロセスはstructで定義され、ファイルシステム実装はvnode（「仮想ノード」。inodeと混同しないこと）を扱う
- しかし、これはNTのやっていることとまったく同じではない。NTは、これらすべての異なるオブジェクトがシステム内で共通の表現を持つことを強制する
- プロセスやファイルハンドルのような異質なものに対して、どうやって意味のある抽象化を提供できるのか疑問に思うかもしれない
- 実際には不可能だが、NTはそれらすべてが共通のオブジェクト型から継承されるよう強制しており、驚くべきことに、これはいくつかの優れた性質を持つ
- 集中アクセス制御
- オブジェクトは object manager によってのみ生成されるため、ポリシーを適用するコードの位置が1か所に集約される
- 権限チェックのようなセマンティクスは1か所でのみ定義され、システム全体に一様に適用できるため強力である
- NetBSDもこれが良い考えだと結論づけたが、Kernel Authorization（kauth）フレームワークを得たのは2001年になってからだった
- 共通ID
- オブジェクトにはIDがあり、すべてが単一のツリーとして表現される
- これは、プロセス、ファイルハンドル、パイプの別を問わず、すべてのオブジェクトに対して一意の名前空間があることを意味する
- ツリー内のオブジェクトは名前（パス）でアドレス指定でき、ツリーの別の部分は異なるサブシステムが所有できる
- たとえば、ツリーの一部がマウントされたファイルシステムを表すことがあり、その場合、そのサブツリーのルートノードをたどると、ファイルシステムがパスの残りを解決することになる
- これはUnixシステムのVFS層に似ているが、VFSが扱うのはファイルシステムだけであるのに対し、オブジェクトツリーは あらゆる単一のカーネルオブジェクト を扱う
- Unixは
/proc/、/sys/などを通じてファイル以外のオブジェクト型をファイルシステムに押し込もうとしてきたが、これはNTの提供するものに比べると後付けに感じられる
- 統合イベント処理
- すべてのオブジェクト型には signaled 状態があり、その意味は各オブジェクト型ごとに異なる
- たとえば、プロセスオブジェクトはプロセスが終了するとsignaled状態に遷移し、ファイルハンドルオブジェクトはI/O要求が完了するとsignaled状態に遷移する
- これにより、単一のwaitスタイルのシステムコールでオブジェクト群の状態変化を待てるため、ユーザー空間でイベント駆動コード（asyncコード）を書くのが非常に容易になる
- UnixシステムでI/Oとプロセス完了を同時に待つのはつらい
- オブジェクトはNT固有の構成要素であり、NTがサポートしようとするすべてのAPIにうまく一般化できるわけではない
- たとえばPOSIXサブシステム。POSIXにはNTのようなオブジェクト概念がないが、NTはPOSIXアプリケーションと何らかの互換性を提供しなければならない
- そのため、POSIXサブシステムはexecutive内でオブジェクトを割り当てる一方で、それに対応するPOSIXエンティティを表すための独自の台帳管理を維持し、両者の論理的な変換をその場で行わなければならない
- 一方、Win32サブシステムは仲介者なしでクライアントにオブジェクトを渡す
プロセス
- プロセスは NT と Unix の共通するオブジェクトだが、完全に同一というわけではない
- Unix ではプロセスはツリーとして表現され、各プロセスには親があり、プロセスは 0 個以上の子を持つことができる
- しかし NT にはそのような関係はない。プロセスは作成元からリソースを「継承」できるが、作成後は独立したエンティティである
- NT が設計された当時、スレッドは一般的ではなかった
- Mach は 1985 年にスレッドを統合した最初の Unix 類似カーネルだった
- これは、他の Unix がこの概念を後から採用し、既存の設計に合わせて修正しなければならなかったことを意味する
- Linux は 1996 年 6 月の 2.0 リリースで、スレッドをそれぞれ固有の PID を持つプロセスとして表現することを選び、NetBSD は 2004 年の 2.0 リリースまで、プロセスとは別個のエンティティとして表現されるスレッドを持たなかった
- Unix と異なり、NT は SMP マシンでの高性能コンピューティングにスレッドが不可欠であることを理解し、当初からスレッドをサポートすることを選択した
- NT には伝統的な Unix の意味でのシグナルがない
- 代わりに alerts があり、これはカーネルモードにもユーザーモードにもなりうる
- ユーザーモード通知は他のオブジェクトと同様に待機対象であり、カーネルモード通知はプロセスからは見えない
- POSIX サブシステムはカーネルモード通知を使ってシグナルをエミュレートする
- シグナルはプロセス実行を妨げるその性質のため、Unix ではしばしば厄介者と見なされてきた。シグナルを正しく処理するのは本当に難しい作業なので、NT の代替案のほうがより洗練されているように思える
- NT における最近の興味深い開発として ピコプロセス の導入があった
- この機能が追加されるまで、NT のプロセスはかなり重かった。新しいプロセスは起動時に、アドレス空間へマップされた NT ランタイムライブラリ群を受け取っていた
- ピコプロセスでは、プロセスは Windows アーキテクチャとの結び付きが最小限であり、これは WSL 1 で Linux 互換プロセスを実装するために使われた
- ある意味でピコプロセスはネイティブな Windows プロセスよりも Unix プロセスに近いが、WSL 2 への移行により、2016 年 8 月から存在しているにもかかわらず、もはやあまり使われていない
- Windows のセキュリティ問題はいくらでも批判できるが、NT はシステムが基本的に capability-based system として動作するという点で、初期のインターネット標準に対して高度なセキュリティ設計から出発していた
- ログオン後に開始される最初のユーザープロセスは、ユーザーセッションの権限を表すアクセス トークンをカーネルから受け取り、プロセスとその子プロセスは権限を主張するためにこのトークンをカーネルへ提示しなければならない
- これは、プロセスが単に識別子を持ち、カーネルがプロセステーブル内で各プロセスに何ができるかを追跡しなければならない Unix とは異なる
互換性
- NT の主要な目標は、レガシー Windows、DOS、OS/2、および POSIX 向けに書かれたアプリケーションとの互換性を持つことだった
- その理由のひとつは技術的なもので、これによりシステムは洗練された設計を強いられた
- もうひとつの理由は政治的なもので、NT は IBM と共同開発されており、NT が最終的に Windows になったにもかかわらず、OS/2 アプリケーションを必ずサポートしなければならなかった
- この互換性の必要性により、NT の設計は Unix とは大きく異なった
- Unix では、ユーザー空間アプリケーションはシステムコールインターフェイスを通じてカーネルと直接通信し、このインターフェイスこそが Unix インターフェイスである
- C ライブラリはカーネルを呼び出すための接着剤を提供し、アプリケーションは直接システムコールを実行しないが、これは些細な詳細にすぎない
- NT では、アプリケーションは executive（カーネル）と直接通信しない
- 代わりに、各アプリケーションは特定の保護された サブシステム と通信し、これらのサブシステムは NT が互換性を持とうとするさまざまなオペレーティングシステムの API を実装する
- これらのサブシステムはユーザー空間サーバーとして実装される（NT の「マイクロカーネル」の内部ではない）
- Windows アプリケーション向けのサポートは Win32 サーバーによって提供される。これは、ユーザーが直接目にする唯一のサーバーであるため特別であり、コンソールプログラムと DOS ターミナルを制御し、性能上の理由から特定の権限を持つ
- 伝統的な Unix と比べると、BSD と Linux はモノリシックカーネルを持つため、NT の設計は大きく異なる
- これらのカーネルは、ユーザー空間アプリケーションがシステムと直接相互作用するために利用するシステムコールインターフェイスを公開する
- しかし BSD は、モノリシックカーネル内で長年にわたり代替 バイナリ 実行をサポートしてきた。これは、実行中のバイナリに応じて異なるシステムコールテーブルをユーザー空間へ公開し、その「外部」のシステムコールをカーネルが理解できるものへ変換することで機能する
- Linux も personalities を通じてこれへの限定的なサポートを提供する
- BSD のアプローチは、NT が他のシステムをサポートする方法とは大きく異なるが、WSL 1 は非常によく似ており、もともと定義された用語でいうサブシステムではない
- WSL 1 では、NT カーネルは Linux プロセスをピコプロセスとして示し、そこから別のシステムコールインターフェイスを公開する
- NT カーネル内では、これらの Linux 関連システムコールは NT 操作へ変換され、BSD の Linux 互換性と同様に、同じカーネル内で提供される
- 唯一の問題は、NT が Unix ではないため Linux の「エミュレーション」が厄介であり、BSD が提供できるものよりはるかに遅いことだ
- WSL 2 がこの設計の本質を失い、完全な VM 設計へ進んだのは残念である
- NT 設計の興味深い詳細
- NT 設計の目標は、単一のシェルからサブシステム間でシームレスな I/O リダイレクトを可能にすることだった
- サブシステムは ポート を介してアプリケーションに公開され、これは NT オブジェクトであり、Mach がプロセスとサーバーを通信させる方法に似ている
仮想メモリ
- NT は Unix と同様に、ページング機能を持つ Memory Management Unit（MMU）に依存してプロセス間保護を提供し、仮想メモリを実現する
- ユーザー空間プロセスのページングは、マシンの物理メモリ量より大きなアドレス空間を提供する一般的な仕組みである
- しかし、当時の Unix システムに対して NT を先進的にしていた点のひとつは、カーネル自体もディスクへページアウトできることだった
- カーネル全体がページング可能であれば、ページアウトされたファイルシステムドライバーのコードを必要とするカーネルページフォールトを解決しなければならない状況になりうるが、カーネルのかなりの部分はページング可能である
- 今日では、カーネルはマシンに搭載された一般的なメモリ量に比べて小さいため、特別に興味深い話ではないが、昔は 1 バイトごとに価値があったため、大きな違いを生んでいた
- 現在では仮想メモリやページングの動作を当然のものと考えがちだが、NT が設計された当時、これは大きな研究分野だった
- 以前の Unix 実装では、ファイルシステム用と仮想メモリ用に別々のメモリキャッシュがあり、SunOS が従来設計のオーバーヘッドを減らすために統合仮想メモリアーキテクチャを実装したのは 1987 年になってからだった
- 一方 NT は、最初から統合メモリアーキテクチャで始まっていた
- Unix で見つかった非効率性への洞察があり、また NT 設計が始まる前に SunOS が実装した解決策を見ることができたため、これを実現するのは容易だったと言えるかもしれない
- しかし、これにより NT は当時の多くのオペレーティングシステムより「より進んで」おり、他のシステムが追いついたのは NetBSD 1.6 の Unified Buffer Cache（UBC）実装が行われた 2002 年まで待たなければならなかったことは注目に値する
- NT と Unix の興味深い違いのひとつは、共有メモリを管理し表現する方法である
- NT では共有メモリセクションはオブジェクトなので、他のすべてのオブジェクトとまったく同じアクセス検証を受ける
- また、単一のオブジェクトツリーの一部であるため、他のすべてのオブジェクトと同じ方法でアドレス指定できる
- Unix ではこの機能は後付けされている。共有メモリオブジェクトは別の名前空間と、他のすべてのエンティティとは異なる API を持つため、一般的な権限は適用されない
I/O サブシステム
- 初期バージョンのUnixは1つのファイルシステムしかサポートしていなかった
- たとえばBSDがUFS以外もサポートするためにVirtual File System(VFS)抽象化を得たのは、1990年の4.3BSDに至ってからだった
- 一方でNTは、複数のファイルシステムを許容する設計として始まった
- 複数のファイルシステムをサポートするために、カーネルは何らかの形でその名前空間を公開しなければならない
- Unixはマウントポイントを通じて、単一のファイル階層構造の中でファイルシステムを結合する: VFS層はファイルシステムのルートに対応するノードを識別し、パスをたどる際に対応するファイルシステムドライバへ要求をリダイレクトする仕組みを提供する
- NTも、標準的なユーザーインターフェースではファイルシステムが分離されたドライブとして見えていても、似た設計を持っている: 内部的にはexecutiveがファイルシステムをオブジェクトツリー上のオブジェクトとして表現し、各オブジェクトがパスの残り部分を解析する責任を持つ
- そのファイルシステムオブジェクトは、ユーザー空間からアクセスできるようにDOSドライブへ再マッピングされる
- DOSドライブも、参照先のファイルシステムへI/Oをリダイレクトする、別個のサブツリー配下のオブジェクトである
- NTは最終的にNTFSとともにリリースされた
- NTFSは、性能が悪いと批判されがちではあるが（誤った主張だが）、当時としては本当に先進的なファイルシステムだった
- NTのI/OサブシステムはNTFSと組み合わさることで、64ビットアドレッシング、ジャーナリング、さらにはUnicodeファイル名まで提供していた
- Linuxは1990年代後半まで64ビットファイルサポートを持たず、2001年にext3がリリースされるまでジャーナリングも備えていなかった
- 代替の耐障害性メカニズムであるSoft updatesも、FreeBSDに現れたのは1998年になってからだった
- Unixはファイル名をUnicodeではなく、null終端のバイト配列として表現する
- NTのリリース時に含まれていたほかの機能としては、ディスクストライピングとミラーリング（現在ではRAIDとして知られる）およびデバイスのホットプラグがある
- SunOSが1990年代初頭からRAIDサポートを含んでいたため、これらの機能自体は新しいものではなかったが、興味深いのはそれらすべてが当初の設計の一部として考慮されていたことだ
- より高いレベルでは、NTのI/OサブシステムをUnixよりはるかに進んだものにしているのは、そのインターフェースが本質的に非同期であり、しかも最初からそうだったという事実である
- これを比較すると、FreeBSDでaio(7)のサポートが見られるのは1998年のFreeBSD 3.0まで待たねばならず、Linuxでも2002年のLinux 2.5まで実現しなかった
- 非同期I/Oのサポートは20年以上前からUnixシステムに存在しているにもかかわらず、今なお広く使われていない: こうしたAPIを知っている人はほとんどおらず、大多数のアプリケーションはそれを使わず、性能も良くない
- Linuxのio_uringは非同期I/Oを改善する比較的最近の追加機能だが、主要なセキュリティ脆弱性の原因でもあり、広く使われているわけでもない
ネットワーキング
- 今日ではインターネットは至るところにあるが、NTが設計された当時はそうではなかった
- Microsoftのエコシステムを振り返ると、DOS 3.1(1987)にはFATファイルシステム上でのファイル共有の基盤が含まれていたが、「OS」自体はネットワーク機能を提供しておらず、Microsoft Networks(MS-NET)という別製品がそれを担っていた
- Windows 3.0(1990)にはローカルネットワーク上で基本的なプリンタ共有とファイル共有を可能にするNetBIOSのサポートが含まれていたが、TCP/IPのサポートは見当たらなかった
- 一方でUnixは、まさにインターネットそのものだった: 基本的なインターネットプロトコルはすべてUnix向けに、そしてUnixとともに作られた
- NTの設計においては、優れたネットワークサポートを考慮することが重要であり、実際にNTはネットワーク機能を備えてリリースされた
- その結果、NTはインターネットプロトコルと、従来のMicrosoft環境で使われていた伝統的なLANプロトコルの両方をサポートし、これが企業環境でUnixに対する優位につながった
- たとえばNTのネットワークドメインがある
- Unixでは、ネットワーク管理者は通常、マシン間でユーザーアカウントを手動で同期していた
- SunOSのようなシステムが実装していたX.500ディレクトリプロトコル(1988)やKerberos(1980年代)をユーザー認証に使うこともできたが、これらの技術は決して簡単なものではなかった
- それに対してNTは、最初からディレクトリ機能と認証機能を統合したドメインを提供しており、設定がはるかに容易でシステムに組み込まれていたため、企業ネットワークで「勝利」したように見える
- 同期されたユーザーアカウントの目的は、マシン間でリソース、主としてファイルを共有することであり、その際には権限をどう表現するかが重要になる
- 長い間、Unixは各ファイルに対して単純な読み取り/書き込み/実行権限の集合しか提供していなかった
- 一方でNTは、最初から高度なACLを備えていたが、これは今でもUnixの弱点である
- LinuxやBSDにもいまではACLがあるが、システム間でインターフェースに一貫性がなく、システム設計にとって異質な追加機能のように感じられる
- NTではACLはオブジェクトレベルで動作するため、すべてのカーネル機能に一貫して適用される
- ファイル共有について語るなら、ネットワークファイルシステムについても語る必要がある
- Unixでは事実上のファイルシステムはNFSであり、NTではSMBだった
- SMBはMS-NETおよびLAN Managerから継承されており、リダイレクタと呼ばれるコンポーネントを通じてカーネルに実装されている
- 本質的にリダイレクタとは、UnixにおけるNFSと同様に、ファイル操作をトラップしてネットワーク越しに送信する「単純な」別のファイルシステムである
- protobufやgRPCは広く使われているため新しいアイデアのように見えるかもしれないが、古いアイデアに基づいている
- Unixでは主にNFSを支えるために、1980年代初頭からSun RPCが使われていた
- 同様にNTも、独自のDSL（インターフェース定義を記述し、リモートプロシージャ用のコードを生成するためのもので、MIDLとして知られる）と、RPCクライアントおよびサーバーを実装するための独自機能を通じて、組み込みのRPCサポートを備えていた
- Unixシステムは、任意のドライバサポートにはあまり重点を置いていなかった: Unixシステムは通常、特定のマシンやベンダーに結びついていた
- 一方でNTは「すべて」のマシンのためのOSになろうとしており、ソフトウェア企業によって販売されていたため、他者が書いたドライバのサポートが重要だった
- その結果、NTにはNetwork Driver Interface Specification(NDIS)が用意されていたが、これはネットワークカードドライバを容易にサポートするための抽象化である
- 今日に至るまで、メーカー提供のドライバはLinuxではそれほど一般的ではなく、そのため2000年代初頭には、Linux上でWiFiカード向けのWindowsドライバを再利用できる非常に人気の高い仕組みであるndiswrapperのような興味深いものが生まれた
- 最後に、NTとUnixのもう1つの違いは名前付きパイプの実装にある
- 名前付きパイプはUnixではローカルな構成要素である: 同一マシン上の2つのプロセスが、ディスク上の永続的なファイル名を使って相互に通信できる仕組みを提供する
- NTにも同じ機能はあるが、名前付きパイプはネットワーク越しにも動作できる
- 共有ファイルシステム上に名前付きパイプを置けば、異なるコンピュータ上の2つのアプリケーションが、ネットワークの詳細を気にすることなく相互に通信できる
ユーザー空間
- 設定:
- NTはレジストリというデータベースでシステムおよびアプリケーションの構成を一元化し、従来のWindowsで使われていた古いCONFIG.SYS、AUTOEXEC.BAT、および多数のINIファイルから脱却した
- これは一部の人々を大いに怒らせたが、最終的には統合された構成インターフェースは誰にとっても有益だった。単一の基盤をサポートすればよいためアプリケーションを書きやすくなり、確認すべき場所が1つだけなのでユーザーもシステムをより簡単に調整できる
- 一方でUnixは、いまだに数十種類のDSLと一貫性のないファイル配置によって苦しんでいる
- 設定ファイルをサポートする各プログラムは独自の構文を持っており、プログラムがどこを読むのかを把握するのは難しく、しかも常に十分に文書化されているわけではない
- LinuxエコシステムはXDGとdconf（以前はGConf）を通じてNTに似たアプローチを推進したが、デスクトップ構成要素はこれらの技術を排他的に利用する一方、システムの基本構成要素は採用しておらず、一貫性のない混乱を残している
- 国際化:
- MicrosoftはすでにWindows 3.xを世界中で展開していた大企業として、ローカライズの重要性を理解しており、NTが最初からこうした機能をサポートするようにした
- これを、UTFサポートが1990年代後半になるまで現れ始めず、他言語サポートも任意のgettext追加機能を通じて提供していたUnixと対比してみるとよい
- C言語:
- FreeBSDやNetBSDのようなUnix系システムがしばらく夢見ていたことの1つは、より安全な方法でカーネルを実装するために独自のC方言を考案することだった
- これは、GCC専用拡張に依存するLinuxを除けば、どこにも行き着かなかった
- 一方MicrosoftはCコンパイラを所有しているという特権があったため、Microsoft Cで書かれたNT上でこれを実現した
- たとえばNTは、ソフトウェアおよびハードウェア例外を処理するためにtry/except句を追加する機能であるStructured Exception Handling（SEH）に依存している
- これが大きな利点だとは言わないが、実際に存在する違いではある
結論
- NTはリリース当時、画期的な技術だった
- 上で説明したように、今日のシステム設計で当然視されている多くの機能がNTには最初から存在していたが、ほぼすべての他のUnix系システムは時間をかけてそうした機能をゆっくり獲得していかなければならなかった
- その結果、これらの機能はUnix哲学と常に円滑に統合されるわけではない
- しかし今日、NTがLinuxやFreeBSDより本当に「より進歩している」のかは明確ではない
- NTは当初からより堅牢な設計原則と同時代のオペレーティングシステムより多くの機能を備えていたが、現在ではその差はあいまいになっている
- つまりNTは進化したが、現代のUnixより著しく進歩しているわけではない
- NTにはこうした堅牢な設計原則がすべてあるにもかかわらず、UIの肥大化によって設計の良さが発揮されていないのは残念である
- 非常に高性能なマシン上であってもOSの遅さを見るのはつらく、さらにはこのOSの終焉につながる可能性すらある
GN⁺のまとめ
- この記事はNTとUnixの設計上の違いを比較し、NTの初期設計がどれほど先進的だったかを説明している
- NTは最初から移植性、マルチプロセッシング対応、互換性を目標に設計されており、これはUnixとの主要な違いである
- NTのオブジェクト指向カーネル、統合メモリアーキテクチャ、非同期I/Oインターフェースなどは、Unixよりも先進的な機能を提供する
- しかし今日ではNTとUnix系システムの違いは大きくなく、NTのUIの肥大化が性能低下を招いている
1件のコメント
Hacker Newsの意見
NTカーネルは優れているが、古い設計である
NTとUnixの最大の違いはドライバーへのアプローチである
現代のWinNTではDirect3Dがカーネルの必須部分である
NTカーネルはプロセスではなくスレッドを実行する
WindowsNTは初期にはLinuxよりはるかに優れた設計のシステムだった
NTは第三のシステムとして、第二システム症候群を回避した
開発者の観点からはWindowsとLinuxに違いがある
wchar_tの使用は問題であるNTカーネルには優雅さがあるが、オープンソースではない
LinuxのFUSEのような融合があった