メモリ空間はまずカーネル空間とユーザー空間で分けられてるし，ユーザー空間のメモリも 1 のプロセスが全部占有できるわけではなくプロセスあたりのスタック容量とヒープ容量は決まってて，そうしたプロセスに紐付いた仮想メモリのページテーブルをガンガン切り替えていってプロセスを切り替えてマルチプロセス動作するので

Linux なら sysctl とかでスタックの容量とかの制限はとっぱらえるんけど，Windows がそこらへんどういう設計でどうやっていってるのかはあんまり覚えてないから知らない

Linux には kexec(2) というシステムコールがあって，名前の通りカーネルを起動するシステムコールなのですが，exec(2) が自分自身のプロセスを全く新しいプロセスとして作り替えて別のプログラムを起動するように kexec(2) は新しくカーネルを起動しなおしてソフトリブートみたいなことをする

Wine は DirectX 9 はかなりの完成度で，DirectX 10 や DirectX 11 も一部はサポートしてる

wine は互換レイヤーやエミュレーターとはまたやってることが少し違うので場合によってはグラフィック処理なんかでも Windows より性能向上することもあるよ

とはいえ Windows と *nix は根本的に違う仕組みのモノなので性能が落ちるときこともあるし，Windows の user32.dll とか kernel32.dll とかを経由する普通のアプリとかじゃなくてわりと ntdll.dll を叩いちゃうとかあるいはもっとハードウェアに直接働きかけるようなソフトウェアは微妙になりがち

DirectX 12 とか現に GPU ガンガン叩いてるじゃないですかヤダー

あと ASIO みたいなオーディオミキサバイパスするやつも

抜きもなにも，べつに Windows に限らずカーネルやソフトウェアスタックをある程度バイパスして性能稼ぐアプリなんて今時いくらでもあるじゃないですか

それに Windows の常駐アプリとかシレっとカーネルドライヴァみたいなことしたりなんなら rootkit みたいなことするやつたくさんおるし……

まあ DirectX12 じゃなくても Vulkan とか Metal とかみんなどんんどん低レイヤなので

抽象化が厚すぎると性能出ないし思ったように操作できないってゲーム屋がみんな言うから

MS-DOS の問題はそこじゃなくてメモリ保護がないことのほうが重大なので

カーネルもアプリもフラットなメモリ空間に居るので，アプリがカーネルのデータを別のアドレスに勝手に移動するとかやりたい放題だったし，そういう環境だと素で C の for 文書き間違えたとかだったとしてもそのまま buffer overrun してカーネルの領域のメモリまで上書きしてブッ壊すとかそういうのだったんで

まあ MacOS もそれは同じだったんだけど

Windows NT カーネルはマイクロカーネルとしてキチンと設計されてたけれど，ver. が進むにつれてグラフィック描画とかはガンガンカーネルに戻して性能稼ぐようになって，ハイブリッドカーネルになっちゃった

NT カーネルになっても行儀の悪いカーネルドライヴァーはいくらもでいるし，それに DirectX とかは野放図にみんながデヴァイスを勝手に奪いあって描画するのではなくて，そこにカーネルによる調停とを入れた上でアプリがハードウェアを直接叩く感じなので

これは Linux もそうで，本来 Linux の描画はみんな X が変わりにやるハズだったのに，みんな X をスルーして Linux の DRM（Direct Rendering Manager）な GPU ドライヴァーを通じてガンガンデヴァイスに直で描画してるし

そうしたらフォント描画も XFont は無視して DRM の上に実装したフォント描画ライブラリで描画するようになったりしたし，X がやってることがマウスやキーボードのイベント通知くらいしかやることなくなったから，じゃあ X 要らないじゃんねってのが Wayland です

Dune とかみたいな，いっそのことプロセスという概念を仮想マシン（VM）に置き換えて OS のカーネルの変わりに kvm とか Xen みたいなハイパーヴァイザーが調停すればアプリケーションは DOS みたいにハードウェアを完全に OS 無しで叩くみたいなプログラム書けるじゃん！という研究があったりはします

それは逆で，元々は OS がないあるいは OS がただのベアメタル（OS 無しの環境のことね）のアプリのライブラリでしかなかった時代に，CPU とメモリという計算機 1 台の概念をセットにして仮想的に複数作っちゃえば，複数のプログラムが同時に動作できるじゃん！という発明がプロセス

んで，時代が 30 年とか 40 年くらい下ってきてハードウェアによる仮想化支援が一般的になってきてプロセスみたいな OS によるエミュレーションじゃなくて本格的に計算機複数台をご家庭でも仮想化できるようになった時代に，「じゃあプロセスじゃあなくてこの仮想マシンを使うのもアリじゃん」っていった天才が出てきたわけよ

実際 Chrome なんかはプロセスをサンドボックスに突っ込んで仮想化することでセキュリティとかやってるけど，じゃあそもそもプロセスという形じゃなくても仮想マシンならもっと強いサンドボックスとして機能するじゃん，というのもまあ自然

WSL なんかもこの方向の研究の別の枝みたいなもんっすね，あれ Microsoft の論文が元ネタだし

そうするとアプリケーションが完全にハードウェアに先鋭化して書けるし，OS によるメモリ保護よりもハードウェアによる仮想化支援のほうがよっぽど強力に分離されてるから VM の中から外へ攻撃するのは難しいし

ただ，この方法だとせっかく OS が抽象化していた部分を完全に抛棄してしまうのでアプリの実装がクソ面倒になるという問題があって，Dune は libDune みたいな OS の変わりになるライブラリを作ってるし，Dune 以前に仮想化が一般化する前にも仮想化を使わずに似たようなことをしようとした ExoKernel が 1995 年には既にありました

まあいくら OS 代わりの library（libraryOS，LibOS）を用意しても，プロセスに比べて VM はやっぱり重いしプロセス同士は簡単に通信できるけど VM 同士の通信はめっちゃ重いので，みんなの家庭の OS のアーキテクチャを新しくしてしまうほどのブレイクスルーには至ってない

ただその libraryOS という考え方やアーキテクチャ（設計）の一端が産業的に成果として応用されたのが WSL です

ハイパーヴァイザーが介在する以上はたとえば kvm なら virtio なデヴァイスに限定できるから全部のハードウェアを制御しないといけないわけじゃないけど，とはいえドライヴァからアプリを書くのはやりたくないよなって感じ（だからこその LibOS ではあるのですが，まだクラウドとかでみんなが使う段階にはなってませんね）

一応クラウド向けの LibOS である unikernel というアーキテクチャは商業製品も出てきたことがあるのですが

実は Xbox One はゲームが Hyper-V の VM として動作してるっぽいし PS3 とか PS4 とか Nintendo Switch とかも VM としてゲーム起動してたりするようなので，案外この概念自体は応用がされてる感じはする

changelogの何を読んでるんだろう...