オペレーティングシステムを作成する方法

Ivan Ruzanovの報告によると、会議「 Platform 2009 」の「Windows-オペレーティングシステムの作成方法」。

antonmsがすでに書いているように、プラットフォームからのレポートが利用可能になりました。 それらのいくつかを見て、私が最も好きなものを共有したいと思います。 通常のhabr-userの忙しさと、最初のレポート記録の期間（1時間20分）を考慮して、以下に資料の詳細なプレゼンテーションを示します。

• Windowsの履歴
• 今日のWindows
• Windows開発
• Windows 7カーネルの変更
• Windowsメンテナンスの更新/修正

Windowsの履歴

Windows NTの開発が始まったのは20年以上前の1988年11月です。 噂では、Microsoft が Windows NTを購入/盗んだという 。 もちろん、そうではありません。 新しいオペレーティングシステムで作業するために、MicrosoftはDECに勤務し、 DEC VAX VMSオペレーティングシステムの開発者の1人であるDave Cutlerを招待しました。 1988年には、新しいオペレーティングシステム開発チームはわずか12人で、その中にはDave Cutlerとともに、DEC VAX VMSの開発に参加した元DEC従業員もいました。 そして、新しいWindows NTのすべてのコードはMicrosoftによって書かれました。
「NT」という略語は「New Technologies」としてマーケティングを表していますが、設計ドキュメントではまったく異なるものを意味します。 実際、Windows NTは新しいIntel i860プロセッサ用に開発されたもので、1988年にはまだリリースされていません。 コード名は「N10」（ NT en）でした。
最初のバージョン-Windows NT 3.1は、5年後の1993年にリリースされました。 この時点で、チームにはすでに250人の開発者がいました。

今日のWindows

• 10億人のユーザー
• 1億4000万行のコード（テストコードとツールを含む）
  Windowsコードは非常に異なります。 一部は20年前に書かれたもので、一部は現在のバージョンでのみ登場したものです。 たとえば、Windows VistaのデバイスのWebサービス（WSD）コードは最初のバージョンに存在し、 GDIコードは開発の最終段階にあり、ほとんど変更されていません。DirectXコードは既に十分に開発されていますが、現在活発に変更されています。
• 8000人の開発者
• 36言語のローカライズ
• 20年の開発

Windows開発

20〜30年前、Waterfallプログラミング手法は1つしか使用されていませんでした。 次のシーケンスです。
仕様→設計→実装→テスト→配信。
しかし、そのような方法論は小さなプロジェクトでのみ機能します。 現在のWindowsのような製品には、他の方法論が必要です。

• 製品サイクルモデル
• チームソフトウェアプロセス
• 極端なプログラミング

これらすべての方法には、長所と短所の両方があります。 チームの規模とコンポーネントの開発段階に応じて、異なるWindows開発チームが異なる開発方法論を適用します。
Windowsでは、一般に製品として、製品サイクルモデルが使用されます。

• 3〜4か月
• 期間中-「滝」

この規模の製品を開発する際の最大の問題は、開発に時間がかかることです。 初期段階では、現在の時間と既存の手段に存在する問題が解決されます。 しかし、一定である唯一のことは、すべてが変化するということです。 長年にわたる開発：

• 要件が変更されます
• 機会が変わる
• 勤務スケジュールが変わります
• プロジェクトが変更されます
• ユーザーが変更されます

さまざまなチームがさまざまな方法で開発を行うという事実にもかかわらず、「普遍的な」ルールがあります。

• テスター向けの中間バージョン（マイルストーン、ベータ、CTP）のリリース
• 短いサイクルでの内部アセンブリのリリース（1日）
• 設計のシンプルさと信頼性
• 個人およびチームのコード読み取り
• 単体テスト
• 検証試験
• 中間アセンブリは高品質である必要があります（書かれているものは機能するはずです）

私は、Windows 7ビルド6801を自宅のコンピューターのメインOSとして使用して1か月以上、このアセンブリについて肯定的な印象を受けたことに注意します。

Windows開発プロセス全体は、毎日のビルドを中心に構築されています。

• これは製品のパルスです。
• 開発は止まらない
• 毎日の自動テスト
• 早期統合
• 開発者の責任
• 見かけの製品状態

昔々、ソースコードブランチは1つしかなく、すべての開発者がそれに直接変更を加えました。 現在、開発チームは非常に大きいため、機能しません。 多くのブランチがサポートされており、その中にはメインブランチであるWinMainがあります。 各ラボには、変更が統合される独自のローカル開発ブランチがあります。 時間の経過とともに検証された変更は、WinMainに統合されます。
毎日の開発サイクル：

• 15:00-統合が許可されているソースコード管理システムの変更
• ビルド6バージョン（無料/チェック済み-x86、x64、IA64）
• 18:00-テスト用に新しいバージョンが利用可能
• 新しいバージョンは、テストのために数千のワークステーションとサーバーにインストールされます。
• 自動ストレステスト
• 05:00-テストレポートが分析され、障害が診断されます
• 09:00-要約レポートは自動的にチームに送信されます
• 09:30-目標を設定するためのチームリーダーの概要会議

ほとんどの上級管理者を含むすべてのプロジェクト参加者は、作業中（および通常は自宅）のコンピューターで中間バージョンを使用します。

Windowsは何に書かれていますか？

• C、C ++、C＃、アセンブラー（x86、x64、IA64）
  アセンブラーは、それなしでは実行できない状況で、かなり限られた範囲で使用されます。
• Visual Studio、Source Insight、ビルド、nmake
• ソースデポ-ソース管理システム
• WinDbg、KD、NTSD-デバッガー

ビルドなどの多くの内部ツールは、 microsoft.com / whdc / devtoolsからダウンロードできます。

Windows 7カーネルの変更

Windows 7カーネルには、次の変更が加えられています。

• リファクタリング
  Windowsでグラフィックサブシステムを削除できないのはなぜですか？
  技術的な観点からこの質問に対する答えは、Windowsのグラフィックスサブシステムは独立しておらず、Win32サブシステムの一部であるということです。
  Windows 7は、依存関係を解消するために多くの低レベルコンポーネントをリファクタリングしました。 これはユーザーには目立たず、新しいDllのみが表示されます。たとえば、 kernel32.dllは kernel32.dllとkernelbase.dllに分割されます。
  このパーティションにより、 MinWin （ディスクあたり20メガバイト）と呼ばれる最小のコアを割り当てることができました。
• x86およびx64のEFIサポート（Vista SP1と同様）
  多くのメーカーは、EFIを優先してBIOSを削除しようとしています。
• VHD（仮想ハードディスク）からの起動
• 並列デバイスの初期化とサービスの開始
  Windowsをロードするとき、デバイスツリーの構築にはかなり時間がかかります。 PNPマネージャーは、バスドライバー（PCI、USB、FireWireなど）をポーリングして、使用しているデバイスを調べます。 そして、ほとんどの場合、プロセッサはデバイスが応答する（または応答しない）のを待ちます。 実際、バス上のデバイスを特定するには、それらをインタビューする必要があります。 もしそうであれば、彼らは答えますが、そうでなければ、あなたは待たなければならず、プロセッサはアイドル状態です。 これらのタスクを並行して実行すると、ロード時間が短縮されます。
• スケジューラからDispatcherロックを削除し、メモリマネージャーからPFNロックを削除する
  過去数年間、プロセッサのクロック速度は向上しておらず、開発は1つのコアレベルとシステムレベル（マルチコア）の両方で並列実行命令の数を増やす方向に進んでいます。 この点で、スケーリングを改善するために多くの作業が行われました。
  カーネル内にあった2つの最もホットなロック、このDispatcherロックとPFNロックは削除されました。
  スレッドの状態を変更するときに、スケジューラがディスパッチャロックを使用しました。 このロックは削除され、「待機」スレッドのステータスはいくつかに分割されました。
  • 待機中：進行中
  • 待機中：完了
  • 保留中：キャンセル済み
  物理メモリページの属性を変更するときにPFNロックが使用されました。 マルチプロセッサシステムでは、各プロセッサがこのロックへのアクセスを要求したため、多大な時間を費やしました。
• 256個の論理プロセッサーのサポート
  以前は、Windowsではマシンワードがアフィニティマスクとして使用されていました。 これは、無料のプロセッサを見つけるのが非常に簡単だったためです。各ビットはプロセッサを表します。 したがって、32ビットシステムでは32個の論理プロセッサ、64ビットシステムでは64個の論理プロセッサがサポートされていました。
  Windows 7では、アフィニティマスクセグメントモデルへの移行の結果、256個の論理プロセッサのサポートが可能になりました。 プロセッサはグループ/セグメントにグループ化され始めました。 各グループには最大64個のプロセッサを含めることができます。 その結果、下位互換性が得られ、古いプログラムは1つのグループのプロセッサのみを「認識」し、新しいインターフェイスを使用する新しいプログラムはシステム内のすべてのプロセッサで動作します。
• 省エネの改善：プロセッサソケットの無効化今日、ラップトップの所有者だけでなく、データセンターの所有者にとっても省エネの深刻な問題があります。 米国では、電力の2％がコンピューターデータセンターで消費されています。 それらの多くは、低いユーザーアクティビティ（週末）の間、サーバーの一部をシャットダウンします。
  プロセッサソケット全体を切断するほうが、数個ごとに1コアよりもはるかに有益であることがわかった。 この場合、ソケットサポートインフラストラクチャ全体（メモリコントローラー）を無効にできます。

Windowsメンテナンスアップデート

以前は、更新は多くの場合累積的（累積的）でした。 これは、誤ったコードがコンポーネントの早期更新に含まれていた場合、後のバージョンにもこのコードが含まれることを意味していました。 ただし、すべてのユーザーがすべての更新を必要とするわけではなく、構成が異なります。
現在、Windowsでのリリース（RTM）後、ソースコードには2つのバージョンがあります。

• RTM GDR（一般配布リリース）
  皆のためのそれらのいくつかの変更が含まれています。 主にセキュリティの修正。
• RTM LDR（限定配布リリース）
  更新プログラムのインストール中に、Windows Updateクライアントは必要なブランチを選択し、そこからコードをインストールします。

セキュリティ更新プログラムを作成する

セキュリティ更新プログラムの作成作業は、脆弱性の発見から始まります。 内部のセキュリティチーム、セキュリティパートナー、開発者など、さまざまな検出方法があります。 脆弱性が発見されると、2つの並列プロセスが開始されます。

• すべてのプラットフォームのパッチ開発
• 「オプション」を検索
  すべてのプラットフォームで同様の脆弱性オプションの大規模な検索。 同一のコードではなく、類似のコードを検索します。

パッチの開発後、そのコードの検証が開始されます。 それらが完了すると、修正がアセンブリに統合され、アセンブリがテストのために送信されます。

• 手動および自動コンポーネントテスト
• ファイル形式の歪み、ネットワークコンポーネントなどの自動テスト （100万を超えるオプション）
• 下位互換性テストを含むシステム全体のテスト

すべての品質基準を満たすパッチのみが、Windows Updateおよびダウンロードセンターでのリリースが許可されています。

最後まで読んでくれたみんなに感謝=）