3 ポイント 投稿者 GN⁺ 2026-01-01 | 1件のコメント | WhatsAppで共有
  • loss32 は、WINEとReactOSの構成要素を活用し、Win32環境を標準デスクトップとして使うLinuxディストリビューションを目指している
  • ユーザーは .exeファイルを直接ダウンロードして実行でき、完全なオープンソースOSとして設計されている
  • ReactOS がWindows NTカーネルの再実装を目指すアプローチであるのに対し、loss32は Linuxカーネル上で安定性と互換性を確保しようとする方向性
  • プロジェクトの主な動機は、WINEの改善Win32ベースのデスクトップ体験の復元創作向けソフトウェアへのアクセス拡大
  • 2026年1月に 初期プロトタイプの配布を予定しており、その後段階的に改善していく計画

Win32/Linuxの概念

  • Linuxは単体のOSではなく、WINEやReactOSのユーザー空間などで構成される完全なシステムの一部として説明されている
    • この組み合わせを 「Win32/Linux」 または 「Win32 plus Linux」 と呼称
  • Microsoftが定義する完全なOSの概念を踏まえ、LinuxカーネルとWin32環境の結合を志向

プロジェクト概要

  • 目標は、WINE上でWin32ソフトウェアによって構成された完全なデスクトップ環境を構築すること
    • ユーザーは .exeファイルを直接実行できる
    • Unix志向のユーザーでなくても利用しやすい、自由でオープンなOSの形を目指す
  • ReactOSとは異なりカーネルを新たに実装せずLinuxカーネルと実績のある構成要素を使う
    • ReactOSのユーザー空間の一部も取り込み、使い勝手の向上を図る
    • Linuxベースのため、Linux向けソフトウェアの実行も可能であり、ReactOSにはない利点となる

ユーザー空間の置き換え範囲

  • 可能な限り ユーザー空間全体をWINEに置き換える方針
  • 具体的な制限や例外についての言及はない

開発の動機

  • 1990年代後半〜2010年代前半のPCデスクトップ体験を維持したい考え
  • WINEの不完全な部分を改善し、すべてのユーザーがより良い互換性を得られるようにする
  • Win32を「安定したLinux ABI」 と見なしている
  • 単に「できるから」という実験的な動機も含まれる

Win32の安定性に関する主張

  • Win32 ABI は数十年にわたり維持されてきた互換性の実績を持つ
    • WINEを通じて Win16ソフトウェアまで実行可能
  • 創作向けソフトウェアやゲームなど、GNU/Linuxエコシステムで不足している分野においても、Win32は幅広いアクセス性を提供する
  • 「世界の安定したABI」 と表現され、文化的遺産へのアクセスを高める役割を果たすと評価されている

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

  • 公開されているスクリーンショットは、Debian 13上でWINEが動作している実際の画面
  • 現時点では 扱いづらい要素や未完成の部分がある
  • 目標は、この環境を安定化し、簡単にインストールできる形でパッケージ化すること

参加方法

  • プロジェクトは hikari_no_yume が2025年12月29日に 39C3イベント中に執筆し、12月30日に更新
  • 参加や問い合わせは メール(hikari@noyu.me) または IRCチャンネル #loss32 (irc.libera.chat) から可能
  • 協力を求めている分野:
    • Waylandコンポジター とWINEの統合改善(現在は standalone mutter を使用中)
    • WINEの explorer.exe、shell32.dll、HiDPIスケーリング、パッケージング に関する作業
    • ReactOSの explorer.exe、shell32.dll、WINEとの互換性問題
    • GNU/Linuxデスクトップスタックの細かな構造全般

今後の予定

  • 2026年1月初期プロトタイプを配布予定
    • /etc/apt/sources.list に追加した後、sudo apt install でインストールできる形を想定
    • 多くの 未完成・不具合のある要素を含む予定で、その後 反復的な改善プロセスを進めていく

1件のコメント

 
GN⁺ 2026-01-01
Hacker Newsの意見
  • Linus Torvalds でさえ、ABI 互換性は十分ではないと言っていた。これが Linux がデスクトップで人気がない主な理由の一つだと思う
    関連動画

    • 友人の言葉を借りれば、「Glibc は完全に安定したカーネル ABI を無駄にしている」という表現がぴったり
    • AppImage や FlatPak のような形式はこの問題を理論上は解決するが、古いソフトウェアをパッケージ化する人がいないのが現実的な問題
    • この主張には今でも一理あるが、12年前の話でもある点は押さえておくべき
    • Linus の意見に全面的に同意する。Windows では WinXP 向けの exe が Win10 や 11 でもほぼ常に動くが、Linux では Mint や Ubuntu のバージョンが変わるたびに互換性の問題で苦労する
    • こういう理由で OpenBSD が魅力的に見えることもある。カーネルとアプリが完全に統合されていて、単純さのおかげで安全性と安定性が高い。
      だが、オープンソース陣営がこれほど古い概念の上で、いまだに不安定な OS を作っているのは皮肉でもある。
      パッケージングシステムの混乱、壊れるアップデート、不安定な glibc、変わり続けるデスクトップ環境などは今なお問題として残っている
  • Wine と Proton のおかげで、Linux が古い Windows ゲームとより高い互換性を持っているのは驚きだ。90〜00年代のゲームは Windows では動かしにくいのに、Steam ではクリック一つで Linux 上で動く

    • 実際、Wine は Windows でも動く。Shorthorn プロジェクトが XP で最新ソフトウェアを動かすために使っている
    • 自分のゲーミング PC は Windows 11 に対応していなかったので Linux に替えたが、体感では性能向上がすぐに感じられた。Windows は不要なダウンロードやクラッシュが多かったが、Linux では大半がうまく動く。ただし Proton では一部ゲームのサウンド問題が残っている
    • Windows で動かしにくいゲームの具体例がどんなものか気になる
    • 逆に、Linux ネイティブ版のゲームが動かず、Windows 版を Proton で動かさなければならなかったこともある
  • VB6 ベースで GUI ユーティリティを作るほうが、今どきの Web 技術より安定していて生産的かもしれない

    • 自分なら Delphi を選ぶ。Delphi は Windows、Linux、macOS、Android、iOS をすべてサポートしている。
      また、RemObjects の Elements は、さまざまな言語で複数プラットフォームを対象にできる RAD 環境だ
    • 自分も VB6 から始めたので郷愁はあるが、React の宣言的 UI モデルがもたらした進歩は否定できない。初期レンダーと再レンダーの区別が消え、状態更新だけで UI が更新される構造は革新的だ
    • Delphi や FreePascal に一票入れたいが、基本的な感情には共感する
    • しかも 2005 年向けのソフトウェアが、今のシステムではものすごく高速に動く
    • ただし、Win32 の標準ウィジェットとエフェクトだけを使う場合の話だ。それ以上のことをするなら、Web ランタイムのような成熟して文書化された環境のほうが生産的だ
  • Linux の ABI 問題を具体的に知りたい。20年以上 Linux を使ってきたが、パッケージマネージャ経由で入れたアプリでは問題を感じたことがない。
    もし歴史全体を知っている人がいたら、ブログに整理してくれるとありがたい

    • カーネルは安定しているが、グラフィカルアプリに必要なシステムライブラリがよく壊れる。GTK、Qt、X11 など主要な構成要素が変わり続け、互換性の断絶が起きる
    • 実際の問題は ABI ではなく、標準化の欠如だ。Linux Standard Base がこれを解決しようとしたが、関心不足で消えていった。
      保守が面白くないという理由で、**CADT(Rewrite 文化)**が続いている。例: Wayland、Rust へのリライト
      こうした環境では商用アプリが育ちにくく、オープンソースアプリでさえ移植に何年もかかる(例: GIMP の GTK2→3 移行)
    • Linux は Windows のようにスタック全体を包含していない。複数の開発者によるライブラリが混在していて、時間とともに変化し続ける
    • GLIBC のバージョン問題を経験したことがないのか気になる
    • OS リリースのたびに全体をパッチして再コンパイルするモデルはひどい。
      開発者はディストリビューションという中間業者のせいで苦しみ、ユーザーは旧版アプリしか使えない。
      良い OS なら、過去のアプリをそのまま実行できるべきだ。
      Windows はこの点で Linux よりずっと優れていて、Linux は社会主義的な構造だから責任主体がない。
      Docker はサーバー側では解決策だが、デスクトップには適用できない
  • Windows 7 や XP のようなクラシック UIを持つ Linux デスクトップがあれば、本当にファンになると思う。
    その優雅さは Windows 10 よりずっと魅力的だ

    • 驚くべきことに、完成度の高い 1:1 の XP/7 クローン DE がまだないのが不思議だ。
      こうした固定された環境を複製すれば、機能過多を防ぎ、バグ修正と最適化に集中できるはず
    • KDE 向け Aero テーマ を試してみるといい。スクリーンショットだけ見れば本当に Windows 7 のように見える
    • だが、こうした試みはたいてい失敗する。LinspireBeOS PC のように、ハードウェアと一緒に出荷されない限り維持できない
    • SerenityOS は Win2k スタイルの完全な OS で、ハードウェア対応さえ整えば可能性がある。
      あるいは ReactOS が完成するのを待つしかない
    • XFCE に Windows テーマを当てれば、かなり近い体験が得られる。そこに Wine の設定を加えれば十分だ
  • Python と WxWindows のバージョン変化でWikidPadが壊れ、結局 Windows に戻った。
    2012 年の exe は今でも完全に動く。個人的には Windows 2000 Server SP4 が最高のデスクトップ OS だったと思う

    • Cutler が指揮した最後のバージョンである Server 2003 が自分の選択だ。技術的にはソースアクセスも可能
    • Debian でも似た問題を経験したが、debootstrap と snapshots.debian.org で解決した。
      GPU アクセラレーションは壊れるかもしれないが、X11 は今でも強力な下位互換性を保っている
    • 2025 年になっても「Task Manager が CPU を 15% 食う」と聞くあたり、Windows 11 は依然として非効率的
  • Microsoft はそろそろ、自分たちが作った embrace, extend, extinguish 戦略の味を知る時だと思う

    • 自分は Windows 13 がLinux カーネルベースに切り替わる可能性すらあると思っている。
      実際、Microsoft はここ 10 年で Linux とオープンソースを積極的に受け入れてきた
  • Linux のアイデアは良いが、依然としてハードウェア対応が足りない。ARM が広がればさらに悪化しそうだ。
    Google がなぜ Android を本物のデスクトップ OS にしないのか不思議だ。ChromeOS は制限が多すぎる

    • 実際には Linux はデバイス次第で、Windows より互換性が高い場合も多い
      Google は Android 16 からデスクトップ化を本格的に進めている。
      ChromeOS も特定の作業には十分すばらしい。
      ただし Google は顧客の声を聞くのが苦手だ。
      それでも Web 技術の発展に貢献した点は認めるべきだ
    • ChromeOS は決しておもちゃではない。開発環境としては macOS より優れている部分もある。
      最後に使ったのが 2013 年なら、今は完全に別物だ
    • 最近はむしろLinux しか対応していないハードウェアも多い
    • デスクトップ環境では、たいていのハードウェアはそのまま動く。特殊な機器でなければ問題ない
  • 主要ディストリビューションが binfmt_misc を使って Wine をデフォルト登録してくれればいいのにと思う。
    Windows アプリを Linux のセキュリティ機構の中で隔離実行し、ログやクラッシュレポートを統合管理すれば、
    Windows の代替 OSとして現実的な道が開けるはずだ

    • こういう機能こそ、Linux を初心者に優しいものにする鍵だ
  • Longene プロジェクトを思い出した。
    Linux カーネルに Windows API を統合しようとした試みで、興味深い歴史的参考事例だ