ハクソク

世界を動かす技術を、日本語で。

Loss32: Win32/Linuxを構築しよう

108日前原文(loss32.org)

概要

  • Linuxデスクトップの未来像として、Win32/Linux（loss32）構想を提案
  • LinuxカーネルとWINE、ReactOSユーザーランドを組み合わせた新しいOSビジョン
  • Win32ソフトウェアを中心としたデスクトップ環境の実現
  • 従来のReactOSとは異なるアプローチで安定性と互換性を追求
  • 協力者募集・今後の展望についても言及

Win32/Linux（loss32）構想の概要

  • Win32/Linux（loss32）は、Linuxカーネル上でWINEとReactOSユーザーランドを組み合わせて動作する新しいデスクトップ環境の提案
  • .exeファイルを直接ダウンロードして実行できる、自由でオープンソースなOSの実現
  • Unix系に馴染みのないパワーユーザーや、単に面白そうだと思うユーザー向け
  • 従来のLinuxディストリビューションとしても機能し、必要に応じてLinuxソフトウェアも利用可能

ReactOSとの違い

  • ReactOSはWindows NTカーネルの再実装を目指すが、それがハードウェア互換性や安定性の課題となっている
  • loss32は、既に実績のあるLinuxカーネルとWINEを基盤に、ReactOSユーザーランドの便利機能を追加
  • ReactOSではできないLinuxソフトの利用も可能

ユーザーランドの置き換えについて

  • 可能な限りWINEでユーザーランドを置き換え、Win32ソフト中心の環境を目指す
  • 90年代後半～2010年代初頭のPCデスクトップ体験の再現と進化
  • WINEの問題点を露呈・改善し、全ユーザーの利益に

Win32が「安定したLinux ABI」である理由

  • Win32 ABIは30年以上の互換性実績を持ち、膨大な.exe資産が利用可能
  • WINEはWin16アプリも動作可能
  • LinuxやPOSIX系ソフトの選択肢が少ない分野（クリエイティブ系・ゲーム等）でも、Win32なら高品質なソフトが多数利用可能
  • 「世界の安定ABI」としてのWin32の価値

スクリーンショットと現状

  • 実際のスクリーンショットは、Debian 13上の安定版WINE環境
  • 見えない部分に多くの粗さがあり、今後の改善が目標
  • 簡単にインストール可能な形での提供を目指す

参加・協力の呼びかけ

  • Waylandコンポジタ（デスクトップ環境を強制しないもの）の知識・協力者募集
  • WINEのexplorer.exeやshell32.dll、HiDPI対応、パッケージング等の改善協力者募集
  • ReactOSユーザーランドとWINEの互換性問題の知識・協力者募集
  • GNU/Linuxデスクトップスタックの詳細知識を持つ方も歓迎
  • 連絡先：#loss32（irc.libera.chat）、メール

今後の展望・リリース予定

  • 完全なビジョン実現の時期は未定
  • **2026年1月頃に初期PoC（Proof of Concept）**をAPTリポジトリ経由で提供予定
  • 多くの未対応・不具合リストと共に、コミュニティと共に改善を目指す

Hackerたちの意見

皮肉じゃなくて、マジで。マイクロソフトも自分たちの「抱きしめて、拡張して、消す」ってやつを味わうべきだよ。
└
聞いてほしいんだけど、MicrosoftがWindows 13にLinuxカーネルを切り替えるっていうのはどう？（この10年でMicrosoftはLinuxとオープンソースをかなり取り入れてきたし）
現状のウェブ技術じゃなくて、VB6を使ったGUIユーティリティを作る方が、実はもっと安定して生産的かもしれないね。
└
正直、エミュレーションを使った方が、普通のElectronアプリよりも速くてリソースも少なくて済むと思うよ :-/
└
Delphi/FreePascalに投票したいけど、気持ちは同じだね。
└
Win32の組み込みウィジェットやエフェクトだけで済むならいいけど、それ以上のことが必要になると、成熟していてドキュメントも充実してる、アクティブにメンテナンスされているアプリケーションランタイム（Webみたいな）を使ってる方が生産性が高いと思う。
└
Delphiを選ぶかな（これでWindows、Linux、macOS、Android、iOSアプリが作れるよ - https://www.embarcadero.com/products/delphi）。それか、RemObjectsのElementsもいいね。これもRADプログラミング環境で、Oxygene（彼らのObject Pascal）、C#、Swift、Java、Go、Mercury（VB）でコードを書いて、すべてのプラットフォームに対応できるよ：.Net、iOS、macOS、Android、WebAssembly、Java、Linux、Windows。
└
VB6から始めたから、たまに懐かしくなるけど、現実を見よう。Reactみたいな宣言型のトップダウンコンポーネントモデル（命令型UIとは違って）は大きな進歩だったよね。特に、初回レンダリングと再レンダリングの違いがないこと、状態を更新するだけで全てが下に伝播するっていうのがね。だから、ウェブを超えて、今のモダンなネイティブUIフレームワークは似たようなモデルを持ってるんだ。
└
しかも、パフォーマンスもいい。2005年のWindows向けに書かれたソフトは、今のシステムでめっちゃ速く動くよ。
└
CコードとVB6コードを簡単に組み合わせられるように作られたら、ReactOS上にFOSS版のVB6（それが使うかもしれない他のコンポーネントも）を提供すれば、ウェブ技術を使うよりも良いかもしれないし、いろんな面で優れていると思う。（まだ多くの問題はあるけど、それによって避けられる問題もたくさんある。）
ワインやプロトンのおかげで、Linuxが今や古いWindowsゲームに対してWindowsよりも互換性が高いのはすごいよね。90年代や00年代のゲームは、Windowsで動かすのにいろいろ手間がかかるけど、Steamを使えばLinuxではクリックするだけで遊べるんだ。
└
ワインはWindowsでも動くよ。ショートホーンプロジェクトでは、新しいバージョンのWindows用のソフトをXPで動かすために使われてる。
└
> 90年代や00年代のゲームは、Windowsで動かすのにいろいろ手間がかかる 具体的にはどんなゲームがあるの？
└
ゲーミングPCがWindows 11に対応してないから、最初にLinuxにアップグレードしたんだ。体験がすぐに大幅に改善されたよ。Windowsは、ライセンスも持ってないし、欲しくもない言語バージョンのWordをダウンロードしようとして、システムを落としてばかりだったし。Steamもクラッシュ再起動のループに入っちゃってた。ウイルススキャナーも...ちょっと難しかった。Linuxでは、ほとんどすべてがうまく動くけど、Protonで動かす一部のゲームには音の問題があって、まだ解決しないといけないんだ。
└
なんか両方のパターンがあるよね。昨日、Linuxのネイティブ版の8bit.runnerを試してみたけど、動かなかったから、Windows（ベータ）版をインストールして、プロトン経由で動かしたよ。
ちょっと気を悪くする人もいるかもしれないけど、リーナス・トーバルズもLinuxディストリビューションのABI互換性が十分じゃないって思ってるし、これがデスクトップでLinuxが人気がない主な理由の一つなんだ。https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s
└
ほんとにglibcだけだね。
└
Linusに100%同意するよ。WinXPの.exeをWin10や11でほぼ毎回動かせるけど、Linuxでは最新のMintやUbuntuディストリビューションで動くバージョンを探さないといけないことが多い。前は動いてたものが壊れちゃうことが多いし、特にアプリがリポジトリに入ってないとね。
└
多くの点で真実だけど（今でも）、この意見は12年前のものだってことは指摘しておく価値があるね。
└
友達の言葉を引用すると、「glibcは完璧に安定したカーネルABIを無駄にしてる」って。
└
理論的には、AppImage（またはFlatPak）がこの問題を解決するよね。問題は、死んだ/放棄されたソフトウェアをパッケージ化する人を集めることだね。
└
これがOpenBSDが魅力的に見える理由かもしれないね。カーネルと様々なアプリケーションが完全に統合されていて、ディストロもない！シンプルさを目指していると思うから、セキュリティも高くてバグも少ないんじゃないかな。正直、OSってつまらないと思うし、1995年くらいからそうであるべきだったと思う。基本的な概念、例えばマルチプロセッシング、コンテキストスイッチ、ツリー型ファイルシステム、複数ユーザー、アクセス権限なんかは1970年から変わってないし、GUIの進化も90年代初頭からあんまり変わってない。ツリー型ファイルシステムやWIMP GUI、ユーザーごとの権限、"オペレーティングシステム"の定義や役割の曖昧さなんかは、もしかしたら恣意的かもしれないけど、ZFS（60年代から標準のツリー型データストレージを非常に良く設計して実装している）みたいな、より良いアイデアの基盤として機能するかもしれない。OSSが「全てのバグを浅くする」と言われているのに、どうしてその旗艦OSをもっと安定させてつまらなくできなかったのか不思議だよ。パッケージシステムの無秩序、アップグレードや更新の破損、不安定なglibc、変わり続けるデスクトップ環境、音声の不具合、電源管理の不安定さとか、色々問題があるよね。
└
カーネルがABIを担当してるんじゃないの？
└
考えると面白いのは、コンウェイの法則とモノレポ、Linuxカーネルとユーザーランドの関係だね。もし全部が一つの大きなリポジトリだったら、破壊的な変更をすることもなかったかもしれない。ifconfig > ipの騒動は、巨大なモノレポがあれば物事がどう変わったかの一例だね。
└
AndroidはABIの互換性を壊すのが得意だけど、それでも最も人気のあるモバイルOSになってるよね。
PythonとWxWindowsの変化で、私の個人WikiであるWikidPadが壊れちゃったから、Windowsに戻ってきたよ。2012年の.exeは今でも完璧に動くから、面倒なく使えるようにUbuntuから戻ったんだ。Windows 2000 Server SP4が最高のデスクトップOSだったと思ってる。
└
Server 2003はCutlerが監督した最後のリリースだから、俺の投票はこれだね。技術的にはソースも公開されてるし。
└
> 私の強い意見として、Windows 2000 Server SP4が今までで最高のデスクトップOSだと思ってる。2025年には、64GBのRAMとSSDを搭載して、「Windows 11のタスクマネージャーが本当に15%のCPUを食って、起動に数秒かかるなんておかしいよね。」って声が聞こえてくるだろう。
└
Debianでこういう問題がたまにあるんだよね。信頼できる解決策は、debootstrapとsnapshots.debian.orgだよ。過去10年以上遡ったことはまだないから、永遠に大丈夫とは言えないけど、GPUアクセラレーションのものは多分まだ壊れることがある。でも、X11はかなり後方互換性があるよ。
誰か説明してくれない？ 1. Linux ABIの具体的な問題 2. それがどうしてそんなに難しいのか 3. 年々どう変わってきたのか、今の状態はどうなのか 4. 解決しようとした真剣な試みはあったのか もう20年近くLinuxを使ってるけど、ABIの問題には気づいてないな。多分、ディストリビューションのリポジトリから全部インストールしてるからか、パッケージマネージャーでビルドしてるからだと思う。もし俺が理解できてないなら、他の人も知りたいはずだよね。（自慢するつもりはないけど、やってきた時間のことを言ってるんだ。）これは大きなお願いだって分かってる。自分で調べるのが一番なんだけど、歴史を知ってる人は、整理された視点や他では得られない貴重な洞察を持ってることが多いから、もしそういう人がいたら、他の人のために書いてみてほしい。ブログが一番いいフォーマットかもね。
└
GLIBCのバージョン問題にぶつかったことはないの？
└
OSのリリースごとにパッチ当てて再コンパイルするモデルは、開発者もユーザーも嫌がるひどいハックだよ。99%の人がこれを嫌ってる。クソみたいなモデルだからね。開発者は、自分たちのソフトを黙ってめちゃくちゃにして、上流にゴミを残す中間業者が嫌いだし、ユーザーは2年前に流行ったソフトに縛られるのが嫌だ。ローリングディストリビューションを使ってると、常に壊れてるのも嫌だよね。この状況を嫌ってない1%の人のうち、99%はただ耐えてるだけで、残りはイデオロギーや埋没コストに目がくらんでるDebianの開発者たち。良いOSは、1. ユーザーがどこからでもソフトを取得できること 2. 前のバージョン用に書かれたプログラムを確実に実行できること 3. ユーザーと開発者の取引に中間業者として介入しないこと。この視点から見ると、Windowsは良いOSだよ。いつも3つの条件を満たしてるわけじゃないけど、最も近い。Linuxは悪いOS。君の質問への答えは、(1) 洗練されたGUIアプリに対して後方互換性がないこと。ウィジェットツールキットのようなコアAPIは常にAPIが変わる（GTK 1→2→3→4、Qtも同様）。前方互換性もない。新しいリリースで同じプログラムをコンパイルすると、古いリリースでは動かないバイナリができることがある。Linuxのライブラリ作者はこれを問題だと思ってないけど、MicrosoftやApple、他の人たちはそう思ってる。これが、みんなが時々経験するglibcシンボルバージョンエラーの原因だよ。(2) 安定したAPI/ABIを維持するのは楽しくないし、「アプリXを動かし続けなければ解雇するぞ」と言う資本家が必要。資本家はユーザーのために戦う。Linuxは、誰もその役割を果たさない社会主義/集団主義のプロジェクトだ。Red Hatのようなディストリビューションは、ソフトウェアエコシステムを半資本主義的なプライベートスペースにクローンして、安定したABIを提供するけど、リリースは単なるエコシステムのフォークで、広い問題は残ってる。(3) 変わってないし、まだ悪い。(4) Dockerは、サーバー上で全てのアプリと一緒にユーザースペースを配信することで問題を「解決」してるけど、利益追求の会社が開発してる。サーバーはソケットを開いてファイルを読み書きする以上の共有サービスを必要としないから、カーネルは十分良くて、安定したABIを維持してる。サーバースペースを出ると、調整の要件が大きくなるから、Dockerは明らかに役に立たない。
└
カーネルは安定してるけど、グラフィカルアプリを作るために必要なシステムライブラリはそうじゃない。過去20年で、GTK 2から4、X11からWayland、Qt 4から6に進化して、各変更で互換性が壊れてる。20年前のアプリケーションをそのままソースからビルドすると、ほぼ確実に動かないし、20年前のバイナリを動かすのはさらに難しい。
└
LinuxのAPI/ABIは、WindowsのAPIがカバーしている全ての範囲を網羅しているわけじゃないんだよね。カーネルの低レベルな部分からデスクトップ環境、さらにはその先まで色々ある。Linuxの展開では、異なる開発者からの様々なライブラリを組み合わせて実現していて、これも時間とともに変わっていくんだ。
└
ABIの問題はないよ。問題は重要なAPIやインフラの標準化が欠けていることなんだ。これを解決しようとした真剣な試みがあった：Linux Standard Base（LSB）ね。https://en.wikipedia.org/wiki/Linux_Standard_Base 標準化が唯一の解決策だと思うよ。エコシステムをさらに分断するようなパッケージフォーマットを新たに作るんじゃなくて。LSBは関心の欠如で死んじゃった。いろんな産業の利害関係者が、Linuxのデスクトップでの成功よりもエコシステムに対するちょっとしたコントロールを得ることに興味を持っているからだと思う。もう一つの大きな問題は、ソフトウェアのメンテナンスが楽しくないこと。これがCADTと呼ばれる状況を生んでるんだ。https://www.jwz.org/doc/cadt.html WaylandやRustのリライトを見てもわかるように、CADTは今でも続いていて、リライトが本当に必要だという理由がいつもクソみたいな言い訳で正当化されてる。これが意味するのは、基本的に誰もアプリケーションを実装しなくなっているってこと。商業アプリケーションは市場が分断されすぎていて、手間がかかりすぎる。オープンソースのアプリケーションは成長するのに時間がかかるし、基盤が常に変わっていたら、イライラするだけだよ。生き残るプロジェクトはほんの少しで、そもそもそれらも苦労してる。例えば、GIMPはGTK 2から3に移植されるのに10年かかったんだ。
誰かWindows 7みたいなユーザーインターフェース、あるいはXPみたいなインターフェースを作ってくれたら、マジでファンになるかも。初心者にもおすすめできるし、Windows 7には特別な愛着があるんだよね。あんまり使ってなかったけど、Windows 10よりもずっとエレガントだし、面白い実験になると思う。どうなるか見てみたいな。
└
XFCEにWindowsテーマを組み合わせればかなり良い感じになるよ。何か特別に考えてることがあるの？それに加えて、事前に設定されたWineがあれば大体カバーできると思うけど。
└
polishedな1:1の2K/XP/7クローンのデスクトップ環境が10年以上も存在しないなんて驚きだよ。これは多くの技術者や一般の人たちが喜んで使う、マスアピールするLinuxデスクトップの明らかなターゲットだと思う。2000年代初頭からざっくりしたものは可能だったけど、あくまでざっくりしたものなんだよね。細部が重要で、古いXPや7のボックスを起動すると、KDEのような人気のあるデスクトップ環境と比べても、もっと洗練されていると感じる部分がある。特定の固定環境のクローンとしてデスクトップ環境を構築することは、機能の拡張を防ぎ、バグ修正や最適化に集中するのに役立つと思う。これは現代のソフトウェア全般に必要なことだよね。
└
> それは本当に面白い実験になりそうだし、どうなるか見てみたいな。結局失敗して、デスクトップOSの墓場にまた一つ死体が増えるだけだろうけど。 自分のハードウェアを出荷するか、ベンダーにOSを出荷させるかしない限り（上記参照）、ユーザーが実際に使えるように設定しないといけない。だから、ユーザーにWindowsハードウェアにインストールさせる必要があるんだよね。そうなると、OEMの助けなしに壊れた消費者ハードウェアのデバッグをしなきゃいけなくなる。誰かがその構成で無料でインストールしてくれることを期待して。これは成功するビジネスモデルじゃないよ。
└
KDEを試してみるべきだよ！https://github.com/ivvil/aerothemeplasma のスクリーンショットを見たら、実際にWindows 7だと信じちゃいそうだ :p
└
https://github.com/SerenityOS/serenity はそれそのもので、Win2kスタイルのOSなんだ。もし良いハードウェアサポートが得られれば、チャンスがあるかも。もしくは、実際のWindowsクローンであるReactOSが完成するかもね。噂では、最初のリリース日はHurdの後になるらしい。
API/ABIの安定性よりも、問題は一貫性がないことと、脆弱な依存関係が多すぎることだと思う。例えば、Systemdみたいな重要なコンポーネントが、d-busという非必須のサービスに依存する必要があるのはなんで？そのd-busも、libexpatというXMLパーサーライブラリに依存してるし。d-busとlibexpatだけで数メガバイトになるよ。前に確認したとき、NTカーネル全体、そして多分Linuxカーネルイメージも、サイズは一桁MBしかなかった。ちなみに、Systemd自体は設定にXMLを使ってないし、INIスタイルの設定フォーマットを使ってるんだ。
└
だから今はvarlinkをやってるんだよね。
この記事を書いてる時点で、最初の100件くらいのコメントは脱線してるから、要するにこれは「Linuxディストリビューション」を作る話で、すべてのユーザーランドソフトウェアがWine上で動くwin32ソフトウェアなんだ。目的の一つは、90年代から10年代のWindowsの体験を再現することだよ。まだ初期段階だけどね。
これ変だな、俺はゲームのためにしかWineを使わないけど、名前はうまいね。他のソフトは全部ネイティブのLinuxだし、Steam自体もそうだよ。