ハクソク

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

Windows 9x用Linuxサブシステム

4時間前原文(social.hails.org)

概要

  • Mastodonのウェブアプリ利用時にJavaScriptの有効化が必要
  • JavaScript未対応の場合の代替手段について案内
  • 各プラットフォーム向けネイティブアプリの利用推奨
  • ユーザーが取るべき対応策の明確化
  • Mastodon利用環境の柔軟な選択肢提示

Mastodonの利用に関する注意事項

  • Mastodonのウェブアプリを利用するには、JavaScriptの有効化が必須
  • ブラウザでJavaScriptが無効の場合、正常動作不可
  • JavaScriptを有効にできない場合は、ネイティブアプリの利用が推奨
  • Mastodonは、iOS用・Android用など各種プラットフォーム向けアプリを提供
  • 公式サイトやApp Store・Google Playからアプリのダウンロードが可能
  • ネイティブアプリ利用で、快適なMastodon体験を実現

Hackerたちの意見

現代のLinuxカーネルがWindows 9xカーネルの中で協調して動いてるなんて、すごいね！
こっちの方が簡単そうだね。https://github.com/haileys/doslinux
└
それを追いかけるのに6年かかったからね！
WSLが出る前は、Windows内で修正なしのLinuxバイナリを動かすにはCoLinuxとflinuxが一番だったよ。http://www.colinux.org/ https://github.com/wishstudio/flinux flinuxは基本的にWSL1のアーキテクチャを持ってて、CoLinuxはLinuxカーネルをサイドロードしたWSL2みたいな感じだった。Cygwinは技術的には正しいアプローチで、外国のLinuxの仕組みを無理に使うんじゃなくて、Windows上でネイティブなPOSIXバイナリを使うものだった。軽量のDLLをリンクするだけだったから、リング0をいじることもなく、余計なものも少なかった。ただ、当時はCLIパッケージマネージャーの便利さがなかったから、Windowsで作業する時はCoLinuxにハマってたのを覚えてる。
└
CygwinはCoLinuxよりずっと古いよ。CoLinuxは2004年のもので、Cygwinは1995年に初めてリリースされた。Cygwinの問題は、俺の記憶ではDLL地獄だった。アプリケーション（例えばWindows用のOpenSSHポート）が独自のcygwin1.dllを含んでいて、異なるバージョンのDLLで問題が起きることがあった。Cygwinはオーバーヘッドが少なかったから、限られたRAMと重いスワッピング（x86-32、限られたI/O、PATAなど）の世界では重要だった。その制約のおかげで、Web 2.0のNodeJSとかじゃなくてネイティブアプリケーションが必要だった。Javaは特に評判が悪くて、当時は一貫したUIツールキットすらなかった。いつも通り、前に二歩進んで一歩下がる感じだね。
└
いや、ベストな方法はVMWare Workstationで、その次がVirtual Boxだったよ。
└
CygwinはWin32上でPOSIX APIを実装してるけど、互換性を高めるためにNt*コールも少し使ってるんだよね。でも、正しいセマンティクスを得るためには結構面倒なことをしなきゃいけない。例えば、フォークはコピーオンライトじゃないし。1999年から2022年くらいまでCygwinユーザーだったけど、ちょっとだけwsl2も使ったことある（今もノートパソコンではそれを使ってる）。でも、去年からデスクトップは完全にLinuxになったよ。
└
最近はMSYS2があって、これは裏でCygwinに依存してるけど、パッケージマネージャー（Arch Linuxのpacman）を提供してるんだ。これでLinuxのVMなしで、Windows上でネイティブなPOSIXバイナリを簡単に実行できるのはかなりユーザーフレンドリーだよ。
└
でもCygwinでの開発は本当に面倒だった。使いたいCライブラリにCygwinのプリビルド版がなかったら（それは理解できるけど！）、依存関係のツリーのすべてで'configure, make'をやらなきゃいけなくて、記憶によるとそのうちの約3分の2の確率で何かを編集しなきゃいけなかった。たまにPOSIXに足りないことがあるからね。
└
Windows NTでInterix[0]（旧OpenNT、後に「Unixアプリケーション用サブシステム」）の下でソースからソフトウェアをビルドするのはかなり良かったよ。InterixはちゃんとしたNTカーネルの「サブシステム」として実装されてたし、例えばGNU automakeのための別のビルドターゲットだったんだ。（Interixが実際のカーネルサブシステムだったから、Win32サブシステムなしで動くテキストモードのNTの「ディストリビューション」っていう夢のようなアイデアがあるんだ。）[0] https://en.wikipedia.org/wiki/Interix
つまり、colinux[0]みたいなもので、NT以前のWindows用ってこと？いいね！まだWindowsを使ってた頃（多分XPの時代）、colinuxを動かしてたんだけど、LAMPスタックをLinux側で設定するのがすごく簡単で、Windowsのエディタで編集するのがかなりいいローカル開発環境になってたと思う！Windows上でX11サーバーを試して、Linuxデスクトップを使うこともできたし。WindowsでどんどんUnixっぽい環境に近づいていくのを感じて、最終的にはmacOSに切り替えたよ。明らかなハック価値を除けば、486時代のマシンでの使い道は想像できないな。メモリにすぐ制限がかかりそうだし！[0] http://colinux.org/
ちょっと遅れたけど、これってWindows 95が出た90年代に初期のLinuxをWindowsで動かすことを実現できたのかな？その頃はデュアルブートしかなかった気がする。
これってLinuxの中でWindows 9xを動かす話だと思ってたんだけど、仮想化なしでそんなことできるの？
> "ハードウェア仮想化なし" > 中を覗く > 仮想8086モード
マイクロソフトの命名規則だと、これはWindows用のLinuxサブシステムってことになるね。
うーん、どれくらい安定してるんだろう… ウィンドウのコントロールボタン（最小化、最大化、閉じる）が正しく描画できないみたい。そんな基本的なタスクで失敗するなら、どこでクラッシュするのか気になるな…
これって、Linuxで動くのか、Windowsで動くのか、よくわからないんだよね。このMSの「サブシステム」って名前、混乱するわ。