Wine 8.0 リリース 46
ストーリー by nagazou
メジャー 部門より
メジャー 部門より
「Wine」の最新版「Wine 8.0」が公開された。毎年1回実施されているメジャーバージョンアップで、今回リリースされた「Wine 8.0」では、この1年間に寄せられた8600以上もの変更が反映されているという。大きなものとしては、PE（Portable Executable:Windowsの実行ファイル形式）フォーマットへの変換が完了し、すべてのモジュールがPEフォーマットでビルドできるようになったことなどがあるとしている。このほか、「WOW64」サンクがほぼすべてのUnixライブラリに対して実装され、32bitのPEモジュールが64bit Unixライブラリを呼び出せる改善が図られたとしている（WineHQリリース、窓の杜、ubunlog）。
32bitコード (スコア:2)
（単独では）今の x86 macOS では動かないんですね。
Wine won't work on macOS Catalina 10.15 as 32-bit x86 support is required
そりゃそうか。Apple 的には 32bit コードはもうレガシーだった。x64 macOS と呼ぶべきなのか。
オフトピックですが、Arm 系 CPU も Apple は 64bit でスッキリしているけど、Qualcomm Snapdragon 8 Gen 2 は 32bit 対応のために 4種類もコアを積んでいるのを思い出しました。
Windows 系 PC の CPU から 32bit サポートが消える日は来るのだろうか。
Re:32bitコード (スコア:1)
x64のCPUは32bit(IA-32)どころか、16bitもサポートしてますよ。
むしろサポートしていることがIA-64に勝った要因なんですけどね。
なので、50年単位で消えないと思いまっせ。
Re:32bitコード (スコア:2)
x64のCPUは32bit(IA-32)どころか、16bitもサポートしてますよ。
だからデコーダ周りの効率では Arm 系に敵わず、電力効率で勝てないないわけで。
マイクロソフト次第かもしれませんが、Windows が命令セットによってコアを割り当てることができるようになったら、コアレベルでは 32bit サポートが無くなるのではないかと思っています。Pコアは 64bit 専用、Eコアは 32bit コードも実行できる、みたいな。
むしろサポートしていることがIA-64に勝った要因なんですけどね。
32bit をサポートしていることが要因であって、16bit は 32bit のおまけだと思っています。
Re: (スコア:0)
まだ80386で実装された仮想86モードでメインメモリをEMSメモリに使ったりも出来るんですかね。
仮想マシンとFreeDOS使えば割とお手軽に試せそうだけど、自分で試す気にはなれない程度の興味しかない。
Re: (スコア:0)
x64のCPUは、16bitモードや32bitモード上での16bit命令の実行はできるが、64bitモード上では16bit命令は実行できない。
64bitモードでは、16bit命令のためのバイナリコードを、新しい命令やレジスタの増設で上書きしちゃったから。
Re:32bitコード (スコア:2)
バイナリコードが流用されたのが原因なら、32bit命令でも同じように動かなくなるバスなので、それは原因ではない。(32bit codeからでもAAAは呼べる。)
csセグメントデイスクリプタのLとdフラグでそこら辺は切り替わるようになってる。
ないのは仮想86モード。(セグメントが単に16倍したアドレスになる)
Re:32bitコード (スコア:1)
Windows on Arm とか、どうせ x86 のプログラムちゃんと動かないし、
A32 切り捨てても問題ないように思えるけど。
Re: (スコア:0)
macの場合はWine CrossOverを使うのかな。
Re: (スコア:0)
armv9自体はaarch32/64両方サポートしてるだろ。
Re:32bitコード (スコア:2)
armv9自体はaarch32/64両方サポートしてるだろ。
ARMv9-A に A32/A64 両方が定義されている、というべきでは？ 実際のチップに両方を実装するかどうかは別の問題で、新しい Cortex-X3、A715、A510 はすべて A64 専用です。だから Snapdragon 8 Gen 2 は旧世代の A710 を 32bit コード実行用に混ぜている。
Armが次世代CPU「Cortex-X3」および「Cortex-A715」を発表
https://texal.jp/2022/06/29/arm-announces-next-generation-cortex-x3-an... [texal.jp]
AArch32命令がないことで、Armは命令デコーダのサイズを先代比で4倍に縮小し、そのすべてのデコードでNEON、SVE2などの命令を扱えるようになった。全体として、面積、電力、実行の面で効率が良くなっている。
Apple は良い資料が見つからないけどかなり以前 A12 あたりで A64 専用になっているよう。
WSLで動くのかな (スコア:0)
xpまででしか正常に動かず、Windowsの互換設定も効果がない昔のゲームを動かすのにどうかなって。
Re:WSLで動くのかな (スコア:1)
Wineって普通にWindows上で動かないのかなと思ったら、無理らしい(フォーラム [winehq.org]、削除された公式Wikiの項目 [archive.org])。
WSLで動いたという報告ならある。まぁ動くだろうな。
時折便利だとは思う。あんまり古いとさすがに動かないことあるし。
Windows自体古いソフトウェアとの互換性は仮想マシンかエミュレーションでも使えば良いのにと言いたいところだけど、Windows 7にWindows XP Modeってあったね。
そして非互換なAPI変更をしたら影響するのは古いソフトだけではないからあんまり意味なさげ。
個人的にはパス長の問題だけ鬱陶しいけど、これは対応ソフトなら普通に扱えるからそういう話ではなさげ。
Re:WSLで動くのかな (スコア:2, すばらしい洞察)
ほんと？
実際はどうかはともかく、著作権がらみの問題を招かないために
リークされたコードは見ない、Microsoft関係者には貢献させない、といったポリシーがあるもんじゃないの
Re: (スコア:0)
建前はそうでも、リーク騒動があれば知識もモラルも裾野が広がるからなあ
やけに克明な互換性情報がたくさん得られるロンダリングマージは避けられないだろ
その辺をふまえたコメントなんじゃないの
Re: (スコア:0)
現実に基づいてる話を理想で否定するのは最近のスラドカラーですね。
Re: (スコア:0)
著作権的には
「リークされたコードを見てドキュメントを書く人」
と
「ドキュメントを見て実装する人」
が分かれていてば大丈夫。
ソースコードを解析したのは Wine プロジェクトではなく外部の人で、Wine の人はソースを見たり盗んだりしたのではなく、その解析結果だけを見て、互換実装を作成しただけなので問題無しという解釈。
動く・動かないのバランス感覚がよくわからない (スコア:0)
X68000のエミュレータなど難しいことしてそうなものが意外なほどよく動くのに対し、
Kindle for PCはインストーラ立ち上げ後すぐ落ちるとか。
これは動きそう、これは難しそう、という予測があてにならず試してみるまでわからない。
Wineも25年ほど経つと思うけど、Windowsも開発(や劣化)が進むし、なかなか追いつかせてくれませんね。
Re:動く・動かないのバランス感覚がよくわからない (スコア:1)
低水準でガリガリ書かれたバイナリはそのまま動き、
高水準なAPIに依存するほど未実装で詰まりやすい。
あまり意外なところも無いと思うけど。
Re: (スコア:0)
x68000のエミュとかは呼んでるWin32 APIは逆に少ないだろうから良く動くだろうし、
Kindle for PCとか、DRMとかでむしろ面倒な奴だと思う。
Re: (スコア:0)
7より後のWindowsでしか動作しないソフトをWINE上で動作させたければ対応するしかないでしょう。
つまりWindowが糞であればあるほど対応する必要があるということ。
Re: (スコア:0)
7までは捨てでいいよ
ゴミOSなんかサポートする必要なし
7より後だけでOK
Re: (スコア:0)
最近のWindowsだとWPFとかWinUIとかの.NET系GUIフレームワークはどうせ無理だし、
Windows 8以降に追加されたWin32 API機能とかそんなに使われるんかね。
Re:動く・動かないのバランス感覚がよくわからない (スコア:1)
WinUI は.NETじゃなく完全にネイティブAPIやで。Win32のGUI関連APIのリプレース(を目指してる)。
.NET からWinUI使うためには(意識しないけど) WinUI2なら WinRTラッパー(.NET Core 3まで)、WinUI3以降は作りなおされたC#/WinRTラッパーを使うことになる。
.NET Framewoek時代のP/Invokeみたいなもの。
WINEは、WPFを含む.NET Framework 4系統をサポートしてるし、.NET 5、6もLinux版じゃなく、Windows版が(ほとんど)動くので、WPFアプリも普通に使えるで。
Re: (スコア:0)
そうだべか
Re: (スコア:0)
んだ
16bitコード (スコア:0)
10年くらい前かな、Windows 3.1時代の16bitコードを動かすときに使いました。
当時、すでに手元に16bitコードを動かせるWindowsマシンがなかった。
Re: (スコア:0)
windowsで動くWineが欲しいですね
Re:16bitコード (スコア:1)
それは既にあります
winevdm [srad.jp]というアプリケーションです
すごい (スコア:0)
シンプルにすごいと思うわ…
簡単なエミュしか書いたことないけど、互換機作るのってひたすら地味な作業なくせに、細かい仕様があるせいで気を抜けないんだよね。
無理矢理レイヤー繋いだりするから、コードもぐちゃぐちゃだし（下手ってのあるだろうけど）
Re: (スコア:0, 参考になる)
え？Wineが提供するDLLとかは全て実装し直してたと思うよ。ユーザーが互換性のためにパクってくるのは勝手だけど。
サードパーティーのWindows用のバイナリっていう意味なら、WindowsもWSLでLinuxのバイナリ走らせてるし。。。
Android (スコア:0)
AndroidスマホでWin32アプリを動かしたいなと思っているけど、ARM上でIntelの命令が動くようになるようなロードマップはあるのでしたっけ？
Re: (スコア:0)
> ARM上でIntelの命令が動くようになる
Appleの通った道だな
Re: (スコア:0)
ちょっと違う。命令はArm64（ソフトでIntel->Arm64に変換してる）だけど、メモリオーダーにIntel互換のモードを足してる（だから命令だけ変換すれば良い）
Re: (スコア:0)
Windows自体（とWindows上で動くx86/x64アプリ）は動いてますけど
Windows on Armのドキュメント
https://learn.microsoft.com/ja-jp/windows/arm/overview [microsoft.com]
毎年1回実施されているメジャーバージョンアップ (スコア:0)
Windows12よりWine12が先に出てきそうだな。
Re: (スコア:0)
まあでも、95や2000に追いつくのは当分先だな。
Re: (スコア:0)
まあでも、95や2000に追いつくのは当分先だな。
95や2000でVunkanうごくんでしたっけ？(すっとぼけ
Re: (スコア:0)
ソフトウェア関係に詳しくないので教えてほしいのですけども、
Vunkanなるシステムはどういったものなのでしょうか？
悲しいことに私はググってもカスな者のため、調べてもVulkan(OpenGLの後継的なもの)しか見つけられず、
誤字脱字に厳しいAC氏ならタイプミスはあり得ないため真意を見いだせず苦悩して夜しか眠れません。
OSDN Magazineの更新が止まった (スコア:0)
スラドの上部にリンクが表示されるOSDN Magazineの更新が3ヶ月ほど止まっているように見える。
この手のossアップデート関連情報を見てたので「またsamba？」と思ったら止まってた。
中の人大丈夫？
Wineなんて読む？ (スコア:0)
発音的にはウイニ？
Re: (スコア:0)
普通にワインではないのか？