アカウント名:
パスワード:
winevdmの方が需要ありそうな気がする。Win16アプリが64bit Windowsで動かせるなんて
winevdmには独自実装のwinhlp32.exeが含まれててWindows 10で.hlpファイルも開ける
試しにWindows3.1版のぷよぷよをプレイしてみたけど、設定ダイアログのフォントが文字化けする以外は完璧に動作した
AMDが16-bitで仮想86モードのサポートを切らなければもっと早くx64の時代が来たし、今も16-bitアプリの互換性が高度に保たれていたのではないかと思うんですよね。たらればなのであれですが、なんでAMDが仮想86モードを1999年の段階で切る決断をしたのでしょうね。
仮想86モードを切るのはつまり、DOSアプリを切るってこと。さすがに1998年にもなれば、x64OSからDOSアプリの互換性を要求する意味はないとAMDが判断しても無理はない。vmwareでも使ってろ、みたいな。Win16はプロテクトモードなのでCPU的にはx64でも動く。Windows側でWin16互換性を持たせるのが大変で面倒だからMSがやらなかっただけ。32bit dllと64bit dllを同一プロセスで混ぜれないのと同じように、Windowsのアーキテクチャデザイン上の決心なわけで、AMDとx64は関係ないのよ。
Win16はOSの機能の一部をリアルモードのコード(BIOSコールとか)に依存していたので、仮想86モードのサポートは事実上必須。OS/2 1.xとかならx64でも動かせたのかもしれない。知らんけど。
AMD64は、当然MSと相談しながら考えたんでしょうしまぁいい加減切り捨てたかったんでしょうね
Win16アプリは同時にDOSアプリでもあるという側面があるのですよ。なのでアプリがDOSコール（INT 21H）をしていたりするので、DOSを無視しては互換性を含めての動作は成立しないのです。だからMSはNTでDOSベースではないカーネルを開発した後にNTVDMというDOS互換モードを別に作ったのです。これが仮想86モードを使うようにできていたので、x86-64の64-bitモードでは動作できなくなってしまったわけです。それによってx64時代の幕開けがだいぶ遅れたんじゃなかろうか、と。
NTVDMはMIPS版、PowerPC版、AlphaAXP版のWindowsNTにも（フルエミューレションで）搭載されてたので、MSがその気になれば、winevdmみたいなのを供給することも出来たはず。仮想86を搭載してDOSやWin16アプリが動いたからといって、じゃあたとえばWinXPやVistaが64bit Onlyで出てたか、といわれると、そんなわけないとしか。ディスクやメモリ使用量は増えるわけだし。x64 OSの普及はドライバ供給と需要（≒搭載メモリ量）によるものとおもうけどね。
jzkeyさんは当時からのWindows NTをご存じの方だったのですね。ご指摘その通りで、Insignia社のSoftPC由来のコードで実装されたWin16実行環境が載っていましたね。
じゃあたとえばWinXPやVistaが64bit Onlyで出てたか、といわれると、そんなわけないとしか。
市場が互換性を求める限り、Onlyだと厳しいのはその通りだと思います。Windows 10ですら途中まで32-bit版があったわけですし。ですが、64-bitの普及のしはじめのハードルを下げる効果はあったと考えています。結局個人の「たられば」の考えでしかないことは確かではありますが。
まだWin9xのPCも広く使われていた時代に仮想86モードのサポートを切ったなんてことあるはずないから何か妙な勘違いしてるとしか思えないんだけど。そもそもAMDがいなければIA-64のゴリ押しにより今頃32bitアプリの高度な互換性すら疑わしい事態になっていたのでは
AMDによるx86-64の発表は1999年 [impress.co.jp]で、そのx86-64の64-bitモードに仮想86モードがないのは誰でも知っている事実ではありませんか？だからこその話なんですが、もしかしてIA-32互換で仮想86モードを持っていたから切っていないという「妙な勘違い」ですか？
> 64-bitモードに仮想86モードがない
ならわかるけど、IA-32どころか「16-bitで仮想86モードのサポートを切らなければ」が意味不明すぎてわけがわからなかった。
なるほど。
AMDが16-bitで仮想86モードのサポートを切らなければもっと早くx64の時代が来たし
で通じると思った私に問題があったようです。というわけで、x84-64の64-bitモードで仮想86モードを切ってしまったがゆえにx64の時代が遅くなったのではないか、現代の16-bitモード互換性が高度に保たれていたのではないかと思うんですよね、ってことです。
未だにVisual Basic 4.0アプリの保守やる羽目になってた可能性も
＞なんでAMDが仮想86モードを1999年の段階で切る決断をしたのでしょうね。
「AMDがx86-64(AMD64)を2000年に提唱した」ということでは？
まあ、そっちだと考えるのが普通だろうなぁ。IA-64で阿鼻叫喚
マルチコアだったら、「一個のコアだけ、32bit モードに移行して。仮想 8086 モードにする」というのは駄目なんでしょうか ?そういうことはできない ?
いまwinevdmの存在を知りました。本体が32bitなのにインストーラだけ16bitというアホアプリがひとつあったのですが、業務の都合で捨ててしまうわけにもいかず困ってたんですよ。
導入したらすんなり動いたので大満足。
本体が32bitなのにインストーラだけ16bitというアホアプリ
これは当時にしてみると16-bit環境と32-bit環境が混在している期間があって、16-bit環境でインストールしようとした時に「32-bit環境でないと動かないよ」という表示をするために16-bit環境でも動作する16-bitアプリである必要性があったんです。
>16-bit環境でも動作する16-bitアプリである必要性混乱は当時から・・・ぢゃーないか。w
すっごく納得しました。Windows3.1と95と98が仲よく暮らしていた頃でしょうかね。いつからこれ使ってたんだよ弊社…
セットアップソリューション(多分InstallShield)はそうそう更新が必要ないから、ずっと使ってたんだろうね。5.xなら規定だとC:\Windows\SysWOW64\InstallShieldにすり替え用のEXEが有るのだけど。
x64なWindows OSが台頭するまで、それで問題がなかったということが大きいのではないかと思います。例えばWindows XPによる32-bit環境の長寿政権がこれに相当します。その後のx64の普及により、16-bitアプリによるインストーラーが引き起こす（非互換性による）弊害が可視化されてしまいました。Microsoftが既知としているインストーラーは自動的な置き換えが行われるという手当が行われましたが、そこから外れてしまったインストーラーは個別の対応を強いられるという結果となりました。当時の配慮と現在の状況を考えるとなかなか悩ましいものがありますね。
すみません。お伝えしたいこととは乖離のあることを書いてしまった気がしています。
お伝えしたかったのは「もしかすると、そのアプリはそんなに古くないかもしれませんよ！」ということです。
当時（最初）のビルド手順でそのまま作ったものが残ってしまっているのかもしれないからです。そうすると当時の慣習がそのまま残ってしまいますからね。
メジャーな16bitインストーラー(InstallShieldやVBの配布用Setup.exeとか)は、32bit版がOSに入ってるんだけどねぇ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ここのアレゲ的には (スコア:0)
winevdmの方が需要ありそうな気がする。Win16アプリが64bit Windowsで動かせるなんて
Re:ここのアレゲ的には (スコア:1)
winevdmには独自実装のwinhlp32.exeが含まれててWindows 10で.hlpファイルも開ける
Re:ここのアレゲ的には (スコア:1)
試しにWindows3.1版のぷよぷよをプレイしてみたけど、設定ダイアログのフォントが文字化けする以外は完璧に動作した
Re: (スコア:0)
AMDが16-bitで仮想86モードのサポートを切らなければもっと早くx64の時代が来たし、今も16-bitアプリの互換性が高度に保たれていたのではないかと思うんですよね。
たらればなのであれですが、なんでAMDが仮想86モードを1999年の段階で切る決断をしたのでしょうね。
Re:ここのアレゲ的には (スコア:2)
仮想86モードを切るのはつまり、DOSアプリを切るってこと。さすがに1998年にもなれば、x64OSからDOSアプリの互換性を要求する意味はないとAMDが判断しても無理はない。vmwareでも使ってろ、みたいな。
Win16はプロテクトモードなのでCPU的にはx64でも動く。Windows側でWin16互換性を持たせるのが大変で面倒だからMSがやらなかっただけ。32bit dllと64bit dllを同一プロセスで混ぜれないのと同じように、Windowsのアーキテクチャデザイン上の決心なわけで、AMDとx64は関係ないのよ。
Re: (スコア:0)
Win16はOSの機能の一部をリアルモードのコード(BIOSコールとか)に依存していたので、仮想86モードのサポートは事実上必須。OS/2 1.xとかならx64でも動かせたのかもしれない。知らんけど。
Re: (スコア:0)
AMD64は、当然MSと相談しながら考えたんでしょうしまぁいい加減切り捨てたかったんでしょうね
Re: (スコア:0)
Win16アプリは同時にDOSアプリでもあるという側面があるのですよ。
なのでアプリがDOSコール（INT 21H）をしていたりするので、DOSを無視しては互換性を含めての動作は成立しないのです。
だからMSはNTでDOSベースではないカーネルを開発した後にNTVDMというDOS互換モードを別に作ったのです。
これが仮想86モードを使うようにできていたので、x86-64の64-bitモードでは動作できなくなってしまったわけです。
それによってx64時代の幕開けがだいぶ遅れたんじゃなかろうか、と。
Re:ここのアレゲ的には (スコア:4, 興味深い)
NTVDMはMIPS版、PowerPC版、AlphaAXP版のWindowsNTにも（フルエミューレションで）搭載されてたので、MSがその気になれば、winevdmみたいなのを供給することも出来たはず。
仮想86を搭載してDOSやWin16アプリが動いたからといって、じゃあたとえばWinXPやVistaが64bit Onlyで出てたか、といわれると、そんなわけないとしか。ディスクやメモリ使用量は増えるわけだし。
x64 OSの普及はドライバ供給と需要（≒搭載メモリ量）によるものとおもうけどね。
Re: (スコア:0)
jzkeyさんは当時からのWindows NTをご存じの方だったのですね。
ご指摘その通りで、Insignia社のSoftPC由来のコードで実装されたWin16実行環境が載っていましたね。
市場が互換性を求める限り、Onlyだと厳しいのはその通りだと思います。Windows 10ですら途中まで32-bit版があったわけですし。
ですが、64-bitの普及のしはじめのハードルを下げる効果はあったと考えています。
結局個人の「たられば」の考えでしかないことは確かではありますが。
Re: (スコア:0)
まだWin9xのPCも広く使われていた時代に仮想86モードのサポートを切ったなんてことあるはずないから何か妙な勘違いしてるとしか思えないんだけど。
そもそもAMDがいなければIA-64のゴリ押しにより今頃32bitアプリの高度な互換性すら疑わしい事態になっていたのでは
Re: (スコア:0)
AMDによるx86-64の発表は1999年 [impress.co.jp]で、そのx86-64の64-bitモードに仮想86モードがないのは誰でも知っている事実ではありませんか？
だからこその話なんですが、もしかしてIA-32互換で仮想86モードを持っていたから切っていないという「妙な勘違い」ですか？
Re: (スコア:0)
> 64-bitモードに仮想86モードがない
ならわかるけど、IA-32どころか「16-bitで仮想86モードのサポートを切らなければ」が意味不明すぎてわけがわからなかった。
Re: (スコア:0)
なるほど。
で通じると思った私に問題があったようです。
というわけで、x84-64の64-bitモードで仮想86モードを切ってしまったがゆえにx64の時代が遅くなったのではないか、現代の16-bitモード互換性が高度に保たれていたのではないかと思うんですよね、ってことです。
Re: (スコア:0)
未だにVisual Basic 4.0アプリの保守やる羽目になってた可能性も
Re: (スコア:0)
＞なんでAMDが仮想86モードを1999年の段階で切る決断をしたのでしょうね。
「AMDがx86-64(AMD64)を2000年に提唱した」ということでは？
Re: (スコア:0)
まあ、そっちだと考えるのが普通だろうなぁ。
IA-64で阿鼻叫喚
Re: (スコア:0)
マルチコアだったら、「一個のコアだけ、32bit モードに移行して。仮想 8086 モードにする」というのは駄目なんでしょうか ?
そういうことはできない ?
助かった！ (スコア:0)
いまwinevdmの存在を知りました。
本体が32bitなのにインストーラだけ16bitというアホアプリがひとつあったのですが、業務の都合で捨ててしまうわけにもいかず困ってたんですよ。
導入したらすんなり動いたので大満足。
Re:助かった！ (スコア:1)
これは当時にしてみると16-bit環境と32-bit環境が混在している期間があって、16-bit環境でインストールしようとした時に「32-bit環境でないと動かないよ」という表示をするために16-bit環境でも動作する16-bitアプリである必要性があったんです。
Re: (スコア:0)
>16-bit環境でも動作する16-bitアプリである必要性
混乱は当時から・・・
ぢゃーないか。w
Re: (スコア:0)
すっごく納得しました。
Windows3.1と95と98が仲よく暮らしていた頃でしょうかね。
いつからこれ使ってたんだよ弊社…
Re: (スコア:0)
セットアップソリューション(多分InstallShield)はそうそう更新が必要ないから、ずっと使ってたんだろうね。
5.xなら規定だとC:\Windows\SysWOW64\InstallShieldにすり替え用のEXEが有るのだけど。
Re: (スコア:0)
x64なWindows OSが台頭するまで、それで問題がなかったということが大きいのではないかと思います。
例えばWindows XPによる32-bit環境の長寿政権がこれに相当します。
その後のx64の普及により、16-bitアプリによるインストーラーが引き起こす（非互換性による）弊害が可視化されてしまいました。
Microsoftが既知としているインストーラーは自動的な置き換えが行われるという手当が行われましたが、そこから外れてしまったインストーラーは個別の対応を強いられるという結果となりました。
当時の配慮と現在の状況を考えるとなかなか悩ましいものがありますね。
Re: (スコア:0)
すみません。
お伝えしたいこととは乖離のあることを書いてしまった気がしています。
お伝えしたかったのは「もしかすると、そのアプリはそんなに古くないかもしれませんよ！」ということです。
当時（最初）のビルド手順でそのまま作ったものが残ってしまっているのかもしれないからです。
そうすると当時の慣習がそのまま残ってしまいますからね。
Re: (スコア:0)
メジャーな16bitインストーラー(InstallShieldやVBの配布用Setup.exeとか)は、32bit版がOSに入ってるんだけどねぇ。