ReactOSの開発 > 開発者向けFAQ

開発者向けFAQ

ReactOSについての開発者向けFAQです。もっと一般的な疑問に関してはよくある質問集をご参照ください。

• 概要
• グラフィックサブシステム
• ファイルシステム
• デバッグ

概要

お決まりの「Microsoft」という文字列から、どうやってReactOSを逃がすのですか？

私たちは、そのような状態はフェア・ユース (fair use) の範囲内だと考えています。しかもレジストリ以外では必要ありません。

Windows向けのドライバはReactOSでも動くのですか？

いくらかのドライバが動くことはわかっていますが、まだ決定的な答えはいえません。カーネル中の部分には未実装の領域があります。

ソースコードからReactOSをコンパイルするためには何が必要なのですか？

環境構築のためのページをご参照ください。どうやってソースコードからReactOSをコンパイルするかの情報があります。

どうしてWineプロジェクトを手伝おうとしないのですか？

じつはWineプロジェクトとは協力しています。WineとReactOSの共通点は、恐らくLinuxとの共通点よりもあるのです。Wineプロジェクトの目標は、完全なWindows APIをWineSever上に実装することです。ほんの少しのWineのDLLがReactOSで使えないだけなのです。NTDLL、USER32、KERNEL32、GDI32、ADVAPIに関しては、ReactOSと共有しています。他のWineのDLLもReactOSと共有できるはずです。そのうえ私たちの開発者のうちの何人かは、WineとReactOS、二束のわらじを履いています。Linux + Wineでは、Microsoft(R) Windows(R)を置き換えることは絶対にできません。ReactOSには潜在能力があり、より高次の互換性を――特にMicrosoft(R) Windows(R)のドライバへは――秘めていますが、Wineとは方向性が異なります。

ReactOSの開発に適しているIDEは何ですか？

IDEを使うにサポートされているコードエディタの情報があります。

SEH問題とは、いったい何ですか？

構造化例外ハンドリング (SEH) は、ReactOSのプログラミングで使われるもので、またOS/2やMicrosoft(R) Windows(R) NTのプログラミングでも使われています。SEHは、OSとコンパイラの間での駆け引きです (キーワード: __try、__except、__finally)。ReactOSはしっかりSEHを内臓していてインフラを提供しています。しかし、今のところはGNUのコンパイラを使うと、SEH内臓のコードが通らなくなってしまいます。つまりドライバやプログラムで、SEHを使ってGNUのコンパイラでコンパイルしても通らないのです。

グラフィックサブシステム

グラフィックサブシステムが、特権リング3ではなくてリング0なのはなぜですか？

簡単に答えるとWindowsがそうしているからです。ドライバ互換の観点から同じ方法をとっています。

どうしてマイクロソフトはリング0なんかにGUIを配置したのですか？

スピードを出すためです。GUIサーバと違って独自プロセスで動くわけではないので、コンテキストの変更はGUIの動作パフォーマンスのために必要ないのです。もちろん構造が多少ゆがんでしまい、GUIがクラッシュすると全部がクラッシュしてしまうのは分かります。しかし同じ議論がレドモンドでかわされてから、GUIがMicrosoft(R) Windows(R) NT 4.0のカーネル部分にうつされたのです。彼らの結論では、GUIが熟成すれば、今の使えないドライバみたいにはならず、ユーザーモード部分で駄目になるのと影響はなんら変わりがない、というものでした。

ReactOSにはMicrosoft(R) Windows(R)と同じセキュリティ問題があるのですか？

Microsoft(R) Windows(R) NTとその後継のOSは、伝統的に危険なシステムであるのではありません。私たちは、マイクロソフトは安全であるはずのシステムを危険にしてしまったのは、いくつかのまずい決定のせいだと考えています。例えば、Windows XPは初期設定で全てのユーザーに管理者権限をあたえてしまいます。いくつかのサービスは実装がへたで、安全な範囲を超えて権限を乱用してしまうのです。でも私たちは、こういった権限問題ならReactOSで解決できます。将来、本当に問題となるのは、マイクロソフトがソフトウェア開発者に対し、通常の権限の範囲でプログラムを走らせるように指導していないことなのです。

どのGUIを使えばいいのでしょうか？

この質問に答えることで、ReactOSとMicrosoft(R) Windows(R)でどのようにGUIが機能しているかがわかるでしょう:
- (グラフィックサブシステムの) DIBエンジンは、ビデオカードドライバと協調して、長方形、線、BitBlitのような簡単な描画機能を提供します。
- Win32サブシステム (CSRSS) は、コンソールウィンドウのようなウィンドウへの機能性を提供します。
- USER32.DLLライブラリは、ボタンやチェックボックスのように、いささか複雑な構造のウィンドウを提供します。
- COMCTL32ライブラリは、ファイルオープンダイアログのような、もっと凝っているウィンドウを提供します。
- シェル (つまりExplorer) は、通常のプログラムと同じく起動中に開始します。その後、アイコン付のデスクトップとスタートメニューを作ります。Explorerは他のシェルに変更できる最後のコンポーネントです。オープンソースの有名な「代替Explorer」には、例えばLiteStepやBlackBoxがありますが、私たちはサポートするつもりです。

ファイルシステム

ReactOSは、ファイルシステムのドライバをMicrosoft(R) Windows(R)とおなじように扱います。そのために、ReactOSはIFS (Installable File System; インストール可能ファイルシステム) インターフェースというものを実装しています。ですから、ReactOSはIFSドライバをロードして使うことができます。今のところ、ReactOSは Microsoft(R) Windows(R) NTネイティブなIFSドライバをロードすることはできないのですが、将来的にはネイティブなNTFSドライバでさえロードすることができるようになります。

FreeDOSバージョンのFAT32ファイルシステムを実装できますか？

ReactOSは以前、ずっとFAT32をサポートしていました。しかしもう他のファイルシステムを実装する必要はありません。

ReactOSはVFATとロングファイルネームをサポートしているのですか？

ReactOSはネイティブで、ロングファイルネームとUnicodeをサポートしています。ということで、ファイルシステムのドライバ次第です。現状では、FATドライバがReactOSに付属しており、VFAT (FATにロングファイルネームを足したものです) をサポートしています。

Ext2/3を実装せず、替わりに、NTFSを使おうとするのはなぜですか？

なぜなら、NTFSはいつかサポートするべきとても重要な機能だからです。Ext2/3はもちろん目標にできますが、実はもう、Ext2/3をNTに実装するプロジェクトは存在しているのです。ですから、彼らの成果が出てからそのドライバを使おうと思います。

NT用のExt2/3のIFSは、どこにありますか？

こちらにあります: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.

私でもIFSドライバのプログラミングを手伝えますか？

はい。IFSドライバには、やらなければいけないことが、たくさんあります。ですが、とてもプログラミングが難しいのです。ただ言えることは、ドライバのプログラミングは難しいのですが、ファイルシステムのドライバのプログラミングは王道である、ということです。もしも本当のカーネル・ハッカーの方でしたら、私たちのメーリング・リストにお越しの上、お知らせください。

NTFSを押し出してExt2/3を使うことはできますか？

はい。どのファイルシステムを使うかは、あなた次第です。ただ現状ではExt2/3のIFSでもNTFSのIFSでも、読み書きができません。ですから、まだまだ作業しないといけませんので、今の選択肢はFATのIFSだけです。

Linux-NTFSプロジェクトの成果を使わないのはどうしてですか？

ソースコードは役立つのですが、どんなNTFSの実装も、(本家マイクロソフトの実装以外は) 書き込みをサポートしていないのです。しかも、まだ知られていない、NTFSの未公開ドキュメントがあるのです。彼らと一緒に作業していますが――今は――彼らのコードを使うだけです。NTFSには優先権はありませんから、この分野の積極的な貢献はなく、休止状態なんです。

NTFSのサポートはReactOSでうまくいくと思うのに、どうして挑戦しないのですか？

ReactOSのプロジェクトでは、ゆくゆくは、NTFSのサポートが優先事項になるでしょう。しかし今は、サポートする決定的な理由はありません。NTFSは、元来、ハードディスクのファイルシステムですから、絶対に必要になるのは、NTFSでフォーマットされた物理パーティションにアクセスして、ハードディスクを動かすために、ReactOSを使うときだけです。NTFSへの完全な互換性が必要ないのなら、他のファイルシステムでも、NTFS以上の能力を兼ね備えており (ジャーナリング、アクセス制御リスト、圧縮、ハードリンクなど)、使うことができます。全てのソフトウェアは、CDやDVDメディア (ISO-9660かUDFS) からか、場合によっては、(FATの) フロッピーディスクから使用します。拡張メディア (コンパクトフラッシュや、メモリースティックなど)には、FATでフォーマットされたものを使いましょう。

JFSのソースは (OS/2用も) ダウンロード自由です。どうしてJFSを標準のファイルシステムとしてReactOSで用いないのですか？

はい、すでに一つのIFSとして計画されています。JFSはまだまだ画期的なファイルシステムで、ジャーナリング、巨大なファイルとパーティション、アクセス制御リスト、拡張属性、ハードリンクに対応していますから、よりReactOSにはぴったりです。いまはまだ作業中ですが、途中参加は大歓迎です。

大文字と小文字の区別 (例えば、Ext2のようなもの) はどうしているのですか？

大文字小文字の区別は、ファイルシステムの扱う問題ではありません。通信するドライバが対処します。オブジェクトマネージャが名前空間全体を把握しており、ネイティブでの大文字小文字の区別をサポートしています。ですから、IFSドライバが特別なケースフラグを受け取り、それによって対応を迫られます。そのため、ポートされたファイルシステムドライバは必ず、大文字小文字、両方の場合に対応します。

64ビットのファイルシステムも、32ビットのマシンで動きますか？

はい。64ビットの部分に関係するのは、ディスクのアドレス動作だけです。実行には、ドライバでも、関係ありません。実行ファイルには、オペレーティングシステム全体と同じく、多数のビット列があります。

ファイルシステムのなかで、今ReactOSがサポートしているのは、何ですか？

FAT(12/16/32) 及びVFAT、ISO-9660 (CD-ROM)、NPFS (名前つきパイプ) のファイルシステム (internal FS)、MSFS (メールスロット・ファイルシステム) (internal FS)

ファイルシステムの中で、これからReactOSがサポートするのは、何ですか？

私たちの目標は、できるだけ多くのファイルシステムをサポートすることです。IFSドライバが開発されたのは、せめてLinuxで使えるファイルシステムを使うためです。しかし、すなおで、まともに動くファイルシステムドライバを書くことは、至難の業です。ですから、時間がかかります。目標とするもの：FAT (12/16/32) 及びVFAT、ISO-9660 (CD-ROM)、Ext3のような高等FS、NTFSかJFS、NPFS (名前つきパイプ)のファイルシステム (internal FS)、MSFS (メールスロット・ファイルシステム) (internal FS)

考えがあります：へんてこりんなドライブレターを取り去らないのは、どうしてですか？

それは古い考え方です。マイクロソフトも同じことを考えていましたが、実装しようとはしませんでした。ReactOSチームでも、同じことが繰り返されました。今のところは、その考えには説得力がないのです。色々な考えがあります。メモリを基にしたマウント式ファイルシステム、オブジェクトマネージャの名前空間を、Win32のアプリやドライブ名には使わない、など。しかし、どの方法にも欠点があります。思い出してください：ReactOSも、Microsoft(R) Windows(R) NTのカーネルも、ドライブレターを軸にはしていません。DOS (いや、CP/Mと言うべきかな) のなごりがWin32に残っているだけです。

リダイレクタ (Redirector) とは何ですか？

リダイレクタとは、特殊なIFSドライバのことです。ディスク上のファイルシステムには、実装されていません。その代わりに、カーネルのネットワークの山にあって、遠隔用のファイルシステム (たとえば、SMB、Server Message Blockの共有) を提供しています。

ファイルシステムRecognizerとは何ですか？

真のファイルシステムドライバは、鈍重です。たとえば、ファイルシステムをローディングするのが、パーティションが空か調べるためだけであったら、時間の無駄です。このため、Deva Cutlerが開発したのが、上記のRecognizerドライバです。Recognizerドライバは、多かれ少なかれ、ドライバ構造のうちの、必須部分です。このRecognizerドライバは、読み込まれると、ファイルシステム用のパーティションを探して、付属のIFSが読み込みできるようにします。パーティションが見つかったら、IFSを読み込んで、マウントします。

SEH問題

構造化例外ハンドリング (SEH) は、ReactOSのプログラミングで使われるもので、OS/2やMicrosoft(R) Windows(R) NTのプログラミングでも使われています。SEHは、ゲームみたいなもので、OSとコンパイラの間で (__try、__except、__finallyなどの予約語で) 使われます。ReactOSはしっかりSEHを内臓していて、インフラを提供しています。しかし今のところは、GNUのコンパイラを使うと、SEH内臓のコードが通らなくなってしまいます。つまりドライバやプログラムで、SEHを使って、GNUのコンパイラでコンパイルしても、通らないのです。

デバッグ

未ハンドル例外 (Unhandled Exception) をユーザーモードでトレースするには？

トレースは以下の様になると思います： (KERNEL32:process/create.c:328) Process terminated abnormally due to unhandled exception (KERNEL32:process/create.c:329) Address: 761a13e0 (KERNEL32:process/create.c:334) Frames: (KERNEL32:process/create.c:338) 761a2be9 ええと、reactos/baseaddress.cfgをご覧になって、トレースしようとしているアドレスの付近を見てください。.mapファイルを、応答しているDLLのために、ビューアで開いてから、オフセットを探してください。