衝撃 LinuxをWindows化!? WineでWindowsアプリが爆速動作する夢のディストリビューション爆誕か

よく使うWindowsフォントって、ライセンス的に Wine に入れられないものが多いんだよね。でも、Winetricks[1] 使えば、Microsoft から直接フォントをダウンロードしてインストールできるよ。あと、Windows のフォント fallback は Linux とかとは全然違うんだよね。Windows はフォント linking っていう仕組み[2] 使ってて、Wine でもうまく動かすにはレジストリの設定が必要[3]。

Wine には、プロプライエタリなフォントと同じメトリクスを持つフォントが標準で入っててほしいよね。フォントファイルには著作権があるけど、字形自体はコピーしても問題ないはず。DejaVu プロジェクトみたいに、Segoe とか Calibri みたいなフォントの equivalent を作ればいいじゃん。

俺は Linux 全体でフォント fallback がちゃんと動くようにしてほしいな。そもそもレンダリングが違うから、メトリクス合わせてもあんま意味ない気がする。

Windows フォントはインストールしたんだけど、それだけじゃ足りないのかな？ Wine って FreeType にレンダリングを任せてるんだよね？ だったら、フォント fallback も FreeType に任せればいいじゃん。

＞なんか Wine って、もうちょい polish してほしいって思うの、俺だけ？ ダイアログとかメニューのフォントが小さすぎてマジ見えないんだよね。＜br>それはお前だけ。俺は昔の Office アプリ動かすために DPI と高解像度の設定したら、2K のラップトップでも 4K の画面でも、すごく綺麗なフォントで表示されてるよ。xprop -root -f _XWAYLAND_GLOBAL_OUTPUT_SCALE 32c -set _XWAYLAND_GLOBAL_OUTPUT_SCALE 2 を試してみて。

新しいディストリビューションは必要ないと思う。よく使う Windows アプリは Wine で動くようにできるけど、一つのアプリを動かすためのハックが他のアプリを壊したりするんだよね。それに、設定も人それぞれで、ある人の環境でうまくいっても、別の人の環境ではうまくいかないことがある。つまり、設定に一貫性がないんだよね。一番簡単な解決策は、Wine が入ったコンテナ（またはサンドボックス）を配布して、そのコンテナの中で Windows プログラム（一つだけ）を動かすようにすることだと思う。そうすれば、誰でも同じものが手に入るし、いつでも動く。Wine の設定で悩む必要もなくなる。スペース効率は悪いけど、Wine をコンテナ向けにスリム化する方法もある。問題はライセンスとソフトウェアの anti pattern。ソフトウェアをコンテナにインストールするために、なんか裏技が必要になるかも。

Wine で Windows アプリケーションを動かすためのコンテナのコンセプトは、’bottles’ って呼ばれてるよ。
https://support.codeweavers.com/en_US/2-getting-started/2-in…
Cedega が最初だったと思うけど、間違ってるかも。俺が最初に遭遇したのはそこだった。

初めて知った。ちょっと試してみる。誰かがもう取り組んでるってのはいいことだね。だって、抽象化のレイヤーがたくさんあるんだから、効率が悪くても、どんな基盤システムでもソフトウェアを ergonomic に動かせるはずだって思うんだよね。

めっちゃ efficient だよ。古い Office スイートから Word をコールドスタートする方が、Libreoffice を起動するよりもずっと速いし、RAM の使用量も少ない。数年前、Wine が一番サポートしてるって言ってたバージョンの Office を ebay で買って、wine32 と wine64 で試してみた結果、Office 2010 が wine32 で動かすのが一番いいって結論になった（Wine は進化してるから変わってるかも）。15 年前のソフトウェアだけど、Unicode xkb symbols で完璧に動くし、ネットワークアクセスもないし、アプリごとにユーザー ID が違うから、問題ないと思う。vim で必要なことが全部できるし、変な変更で驚かされることもないから、昔の Excel を同じように使うのもアリだよね！

90年代のOfficeスイート見てると、マジで何が改善必要だったんだろって思うよね。Google Docsのクラウドでの自動保存が画期的だったくらいしか思いつかないわ。

＞何が改善必要だったんだろう？
あんまないのかもね？
数ヶ月前、電源切れちゃって（フルスクリーンアプリ使ってて気づかなかった）、Linux再起動して古いWord使ったら、自動保存されててマジ助かった！Excel 2010はAI向けじゃないけど、wineのコピペとスクリプトで意外となんとかなるし！

Excelの自動保存は昔からあったよ。Office 4.3の一部だったWord 6と一緒に配布されたバージョン（Excelのバージョン番号は覚えてないけど）の90年代初頭には有効にしてたもん。

今のExcelの自動保存はODSPと使うと違うんだよねー。セルの変更とか、表のフォーマットとか、一個ずつ自動保存されるの。エンドユーザーにはマジで意識させないのよ。Wordも似た感じ。

Word 2010使ってて最近作ったファイルも問題ないってこと？15年前のWordと今の.docxが互換性あるってのが意外だわ。

そんな驚くことないよ。zip圧縮されたxmlだから。将来のバージョンはxmlにオプションのノードを追加するかもしれんけど、前のバージョンはそれを無視できるし。

今のWordスイートの基本フォーマットはWord 2010で導入されたんだよね。だからドキュメント作った人がWord 2010に元々あった機能を使ってれば問題ないはず。新しいバージョンの機能は表示されなかったり、箱で表示されたりする。

共同編集機能がないのは痛い。「変更履歴の記録」じゃ、なんか違うんだよね。

それ良いこと言うね。もしかしてGoogle Docsがオフィススイートの頂点かも。

Google Docsの自動保存はマジで優秀だけど、Word 6.0 for Windows 3.1でも自動保存の間隔を分単位で設定できたんだよ。当時は、作業中のファイルを更新してたんだよね。今のバックアップファイル作るより好きだったな。

各アプリが別々のユーザーIDで隔離されるのは良いよね。でも、ファイルのアクセス権で問題が起きないかな？
もし問題ないなら、プログラムが全部のファイルにアクセスできるってことにならない？それだと隔離の意味なくない？

オレがOffice使うときは、Z:ドライブにある共有ディレクトリからファイルを持ってくるんだ。
スクリプトで全部自動化してて、wineがXwaylandを使えるようにしてる（アプリを起動するまで、そのユーザーIDはディスプレイにコンテンツを表示できないから）。
もしwineを違うユーザーIDで試したいなら、/tmp/wineみたいなグループ書き込み可能なディレクトリから始めるといいよ。Windowsアプリと自分のユーザーが同じグループに所属するようにしてさ。

いいね。ディストリビューションがもっと簡単にできるようにしてくれると嬉しいな！

bottlesの考え方はすごく好き。
これをディストリに組み込んで、ユーザーには見えないようにできたら最高だね。友達や家族に設定してあげられるじゃん。

Linuxシステムを色々変えるってことは、新しいディストリを作ってるのと同じだよ。
そもそも、Linuxが柔軟すぎるのがいけないんだ。オレのシステムとあんたのシステムは違うし、両方でテストした人いる？安定したABIが欲しいなら、もっと安定したシステムが必要だよ。

基盤となるシステムは何も変える必要ないんだよ、そこがポイント。
コンテナは基盤システムに関係なく同じように動くから、みんなの環境の違いを回避できる。
FedoraとUbuntuで同じコンテナを普通に使ってるし、RHELとか他のシステム向けのコンテナも作ってる。
コンテナの利点は、開発環境とデプロイ環境の差をなくせること。
みんながそれぞれのマシンでソフトウェアを動かすんじゃなくて、コンテナの中で一度動かせば、それを配布するだけ。

コンテナが動くのは、カーネルがほぼ同じで、他のものを全部コピーしてるから肥大化するんだよ。
しかも、ユーザーモードレベルでは互換性がない（グラフィックドライバーとか！）。
もしオレのカーネルが君のと全然違ったら（カーネルオプションとかメジャーバージョンが違うだけでも）、仮想マシンが必要になる。

WineをFlatpakのプラットフォームとして配布できるかもね。Flatpakはすでにコンテナで、どのディストリビューションでも同じように動くし。Win32のベースを同じツールで同じように作るのは難しくないんじゃないかな。

Flatpakの方が良いかも。共通部分をうまくまとめられるから、Wineのバージョンを一つ（かごく少数）だけ持ち込めば済むかもしれないし。

残念ながら、Flathub（最大のFlatpakリポジトリ）は技術的には可能だけど、Windowsアプリを許可してないんだよね。

https://docs.flathub.org/docs/for-app-authors/requirements にこう書いてあるよ。
＞WindowsアプリでWineとかエミュレーター使ってるやつは、公式にメンテするって意思があるなら受け付けるよ、とのこと。なんでだろ？普通のパッケージはOKなのに。Javaとか.netと何が違うんだろ？

たぶん、暗黙的に海賊版になっちゃうからじゃないかな。Windowsのフリーソフトなんて誰も共有しないし。皆MS OfficeとかPhotoshopとかCADとかを求めてるんだよ。そういうのはOSSの代替品がないし、導入のハードルも高いからね。やるなら大規模な組織が必要だね。ソフトウェアを配布できるような契約を結んで、ユーザーが購入できる仕組みも提供する必要がある。ライセンスの問題もあるし。難しいけど、基本的な考え方は単純で実現可能だよ。問題は技術的なことじゃなくて、Windowsソフトの配布方法とライセンスなんだよね。

ちょっと考えたんだけど、Dockerfileみたいに、再現可能なレシピを共有する方が良くない？Wineなら、FROM wine-1.23みたいな感じで。レシピをメンテして、古い依存関係に固定しておけば。コンテナはsyscallレベルで抽象化してくれるから、翻訳レイヤーとして使えると思うんだよね。GUIがあれば、アプリごとにサンドボックス作って、設定とかインストールしたものを覚えておいて（Winefileに追加して）。

それ、https://docs.flathub.org/docs/for-app-authors/requirements#l… に書いてあるけど、一般的じゃないと思う。Windows＝プロプライエタリ＝再配布不可ってわけじゃないし。MS Officeは無理でも、シェアウェアなら大丈夫だと思う（法律家じゃないけど）。例えば、Notepad++はGPLv3でWine platinum ratingだし、なんでFlathubにないの？

＞新しいディストリビューションはいらないと思う。よく使うWindowsアプリはWineで動くようにできるし。
シームレスなWindowsみたいな体験を提供して、ユーザーがWindowsと同じように作業できるようにするのが理想なんだと思う。設定とかいじらずに、クリックしたら動くように。

今さら新しいシステムなんて誰も学ばないよ。みんなexeの書き方とかパッケージの仕方を知ってるんだから。
＞一つのアプリを動かすためのハックが他のアプリを壊すことがある。
Windows exeをサポートすることだけを目的としたOSなら、そういう問題は避けられると思う。

それならSteamOSってのがあるじゃん。

Protonの重要な機能の一つは、アプリごとに設定を調整できることだよね。ローカルで必要な調整ができるように。

そうそう。アプリごとに調整できるけど、昔ほど必要じゃないかもね。

一般的に必要ないってこと？それともユーザーが？Protonは調整を全部まとめて、考えなくてもいいようにしてると思ってたんだけど、ちゃんと調べたわけじゃないんだ。

SteamOSは明らかにLinuxだから、ブログで言ってることとは違うよね。

dockerをパッケージマネージャーとして使うこともできるよ。実際にそういう仕事してたし。必要な依存関係をコンパイルして、プロセスを効率化してたんだ。
dockerの抽象化レイヤーを作って、コンテナ内で実行する”実行ファイル”をインストールできるようにすることも可能だよね。flatpakとかsnaps、appimagesも同じ考え方じゃない？
新しいシステムを学ぶ必要がないように、抽象化技術を活用するのが大事。

＞20年前のexeファイルは今でもWindowsで実行できるけど、Linuxのバイナリは1年前のものでも動かないことがあるよね。アップデートで動かなくなる可能性がある。
たぶん、違うものを比較してるんだと思う。
Windowsのアプリインストールは、必要な依存関係を全部含めるのが普通だけど、Linuxはアプリ間で共有するからね。だから、依存関係が変わると動かなくなるのは当然。
解決策はいくつかあるよ。Windowsと同じように配布するとか、静的にリンクするとか。

違うものを比較してるのはその通りだけど、そもそも元の主張も正しくないと思うな。一部のexeファイルはそうかもしれないけど、全部じゃないでしょ。
Linux + WineでWindowsシステムを置き換えたことがあるけど、レガシーソフトが動かなくなってたんだ。最新のWindowsじゃどうやっても動かなくて。WineならDLLファイルを見つければ問題なく動いたよ。
Wineは安定してるかもしれないけど、動的にリンクされたレガシーソフトはWindowsでもLinuxでも問題が起きる可能性があるよね。Kernelの変更もそうだし。Windowsは互換性があるって言われるけど、実際は違うこともある。

＞Linux + WineでWindowsシステムを置き換えたことがあるけど、レガシーソフトが動かなくなってたんだ。最新のWindowsじゃどうやっても動かなくて。WineならDLLファイルを見つければ問題なく動いたよ。
Windows 11からLinuxに乗り換えたのも同じ理由だよ。古いバージョンのOfficeの方が速かったんだ。WordpadよりWordの方が起動が速かったし（Notepad並み！）。古いOfficeのOutlookの方がメモリの使用量も少なくて、Windowsに付属してるやつより反応が良かった！
新しいノートPCを買ったとき、古いOfficeのインストールで問題が起きて、古いOfficeがブロックされるって噂もあったし。
リスクを取りたくなかったから、移行を始めたんだ。
＞Windowsは互換性があるって言われるけど、実際は違うこともある
完璧に互換性があったよ。Windows 11の一部のバージョンがおかしくなるまではね（Proライセンスでも）。
Windows（とAutoHotKeyとか）は大好きだったけど、今はLinuxに満足してるよ。

＞Windows（とAutoHotKeyとか）は大好きだったけど
あのさ、Win+1とかWin+2で仮想デスクトップを切り替える設定ってどうやるの？あと、あの遅いアニメーションを無効にして、すぐに切り替えるには？
何か情報があったら教えてほしいな。
Linuxを長く使ってるんだけど、仕事でWindowsを使わないといけなくなって。だから、できるだけLinuxと同じような操作感にしたいんだ。

＞Linuxでおなじみの操作感をWindowsでも実現したいんだよね。
regeditはUI調整の出発点として良いと思うよ。PowerToysもおすすめだけど、キーボード中心の操作ならAHKスクリプトを組むのが良いかも。例えば、ワークフローをキーボード操作に特化させたいならね。
＞Linuxでの効率をWindowsに近づけようとしたけど、Windowsには便利なツールがたくさんあるから、結局Windowsに戻っちゃった。

アニメーションは「設定」＞「アクセシビリティ」＞「視覚効果」＞「アニメーション効果」で全部オフにできるよ。特定のデスクトップに切り替えるホットキーは標準機能にはないね。あと、ウィンドウを別のデスクトップに移動させるホットキーがないのが不満だな。

LinuxならLD_PRELOADとLD_LIBRARY_PATHがあるじゃん。古いバイナリが動かない原因は、古いライブラリにリンクされてるからってことが多いんだよね。必要なライブラリを用意すれば、WindowsのDLLと同じように動くことが多いよ。

Windowsのバイナリ配布ではシステム層のものをバンドルする必要ないけど、Linuxはシステムライブラリとオプションライブラリの区別があいまいだし、API/ABIの保証もないから、依存関係をバンドルするだけじゃダメなんだよね。Mesa、libwayland、GTKとかはバンドルできないし、互換性が崩れないとも限らない。
WindowsはGUIライブラリ、OpenGLドライバー、サウンドライブラリをバンドルしないけど、Linuxはコンテナにシステムライブラリを入れなきゃいけなくて、互換性が残ってるか祈るしかない。静的リンクもGlibc以降は完全に動かないライブラリもあるから無理だよ。

それはそうかもね。でも、cmakeでC/C++の静的実行ファイルを作るのは上手くいってるよ（たぶんclang/gccに-staticを渡してる）。golangも静的実行ファイルを作れるみたいだし。
静的リンクが高コストじゃなければ、dockerイメージで共有ライブラリを使う必要ないと思うんだよね。イメージをリビルドするなら、全部作り直すことになるし。
静的実行ファイルなら、dockerイメージとか複雑なパッケージングを避けられるかも。

＞それはそうかもね。でも、cmakeでC/C++の静的実行ファイルを作るのは上手くいってるよ（たぶんclang/gccに-staticを渡してる）。golangも静的実行ファイルを作れるみたいだし。
リンクするものやアプリの内容にもよるよ。Dockerコンテナ上のGolangは相性が良いね。Dockerはベースディストリビューションに依存しなくて済むし、Goはlibcをスキップして独自のネットワークスタックを使うし、resolv.confを解析して独自のDNSクライアントを実行する。GUIアプリを全部静的リンクすると、ディスクを食いつぶすモンスターみたいなディストリビューションになるよ。
Linuxでクローズドソースのアプリを安心して配布するには、バイナリ互換性が重要だよ。Qt3やGTK2アプリはもう作られないし、サポートもされない。WindowsならWin32で書かれたアプリでも最新機能を使えるんだ。Win32、WPF、WinUIを同じアプリで使えるし、バンドルする必要もない。せいぜい最新のdotnetを入れてもらうくらい。

＞GUIアプリを全部静的リンクすると、ディスクを食いつぶすモンスターみたいなディストリビューションになる
昔のMacintoshのtoolboxは64KBだったけどね。白黒だけど。
1MBのGUIライブラリ（Smalltalk-80とか）でも、今のアプリなら誤差みたいなもんでしょ。

「あなた」が違うんだよね。配布者向けの選択肢を提示してるけど、引用はユーザー向けの選択肢について話してる。ユーザーからすると、配布者が過去に選んでれば楽になったはずの選択肢なんて役に立たない。

単純じゃないと思うよ。openglドライバーは複雑で、ハードウェアごとのuserlandライブラリが必要で、動的リンクが必要らしいし。WindowsのバイナリがLinuxでゲームをリリースする上で一番安定してるみたいだし。
Linuxのsyscall ABIの安定性とか、カーネル内の他のものも気になる。

＞openglドライバーは複雑で、ハードウェアごとのuserlandライブラリが必要で、動的リンクが必要らしい
そうだよ。OpenGLドライバーは動的にロードされるけど…
OpenGL ABIの安定性に問題があるって聞いたことないけど？

OpenGLのABIはめっちゃ安定してるんだけど、OpenGLドライバー(特にオープンソースのやつ)は、ディストリビューションが動的にリンクしたがる他のライブラリも使うんだよね。だから、プログラムと一緒に違うバージョンのライブラリを配布すると問題が起きる可能性があるんだ。静的にリンクされたライブラリでも、正しくビルドされてなくて、実行ファイルがまだライブラリのシンボルをエクスポートしてたら同じことが言えるよ。乗り越えられない問題じゃないけど、経験の浅いLinux開発者はしくじるかもね。

マジそれな。昔から、アーカイブされたEXEがDLLが見つからないって怒り出す問題にめっちゃ悩まされてるんだよね。
同じように、作者が言ってるように、Linux自体にバイナリ互換性の問題があるわけじゃないんだよ。もしこれが問題で、エミュレーションレイヤーを通してデフォルトでEXEを実行するディストリビューションを作ろうとしてるなら、Alpineとか他のmuslベースのディストリビューションを使った方が絶対いいと思うよ。

この件についてYouTubeの動画を見て勉強しなきゃ。コンピューターエンジニアリングではしょっちゅう出てくることだけど、ちゃんと理解せずに何とかやってこれちゃったんだよね。時々こういうコメントを見かけると、すごくよく分かる気がするんだけど、まだ学ぶべきニュアンスがたくさんあるんだろうな。

これって、クレムリンの前で「アメリカ大統領打倒！」って叫ぶソ連時代のジョークみたいなもんだよね。この場合、俺もLinuxのWine上で20年前のWindowsバイナリを実行できるってこと。

この記事の前提は悪くないんだけど、技術的な不正確さが目立つんだよね。
ある部分では、syscall、libc (たぶんglibcのこと)、PE vs. ELF、そして’ABI’について話してるけど、それらは全部違うものだし、IIUC的には全部Linux上ではかなり安定してるんだよね。安定してないのは、GTKとかQTみたいなユーザー空間ライブラリなんだよ。結局、何の話をしてるんだ？
＞ A small modification to the “exec” family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
っていう記述もあるけど、俺はカーネル開発者じゃないから本当かどうか疑わしいな。それに、Gatekeeper(無効にできる)、Recall(デフォルトで無効)、Microsoftアカウントでのサインイン(簡単にバイパスできる)についても話してる。それに”違法ファイルをスキャンする”って言ってるけど、それってAppleのiCloud CSAMスキャンみたいなやつでしょ？あれはコンピューター上にはないし、めっちゃ批判されて中止になったじゃん。LinuxがWine経由でWin32との互換性を持つっていうアイデアは悪くないけど、もっと正確に書いてほしいな。