アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
QEMUねぇ。 (スコア:2, 興味深い)
> エミュレーション力ではBochsに劣り、速度でもVPCに劣るQEMU
私はそれなりのスピードでぶん回るプロセッサ(AthlonXP 2000+ですが)でbochsを走らせているので、bochsのエミュレーション速度には文句はありません(CPUをアップグレードすればも
Re:QEMUねぇ。 (スコア:1, フレームのもと)
bochsはx86マシンをフルエミュレーションします。
QEMUはCPUエミュレーションが主体で仮想マシンはオマケです。
#といっても、そのオマケに力を注いでいる人が多いのですが
QEMUの主な目的は、x86以外のarch上でx86の"アプリ"を動かす事にあります。OSごと動かすのが目的ではありません。
#そのためのCPUエミュです。
例えばWINE
Windowsアプリで、広く流通してるものの殆どがx86専用です。
それをx86以外のarchで使おうとか
# sparc上で
# qemu-i386 wine notepad.exe とすると、Windows(x86)のnotepadが動きます。
さらにQEMUはx86だけではな
IA-32エミュレーション (スコア:0)
bochs-2.1ですら、あるCPUエミュレーションのバグで動かない某国産OS等を確認してますし。
(以前に挙げられているパッチをあてるとそれらは動くので)
それより、LINUXというかELFに依存してるのが気になるかなあ。
例えばCE機とかでWindows(x86)のアプリ動かすのにWINE経由は無駄じゃない?
個人的にはマルチCPUとユーザーモード(OS-APIトラップ)とフルエミュレー
Re:IA-32エミュレーション (スコア:-1, フレームのもと)
誰も言いきってませんよ?何言ってんですか?
必ずしもそうだとは言えないでしょうし
そうではないとも言えません。
バグだと言いきりたいならQEMUおいかけましょう。
わからんのにバグだバグだ 性能悪い性能悪いと騒ぎたてんのはバカです。
それに現状で完成というわけではありません。
#もしかして、0.0.xの段階で既に完成であることを求めてるんですか?早漏ですか?
>例えばCE機とかでWindows(x86)のアプリ動かすのにWINE経由は無駄じゃない?
何、馬鹿な事言ってるんですか?
WINEって何か知っ
Re:IA-32エミュレーション (スコア:0)
つまり他のOSに移植する事を考えるとLinuxのエミュレートが必要で、折角の「CPUエミュレータ」としての可搬性が損なわれてるように思ったからです。
これが単にローカルプラットフォーム固有の機能で、要はMacOSはPPCでも68kアプリ動きます。palmOSで…なんていう代物なら別にいいんですが、そのOSを使っていないと関係ない話になってしまいますね。
>仮想機の性能ではbochsやVPCに劣りますが、CPUエミュレーションだけを行う場合は断然コストが低いので快速 快適です。
コスト重視ならば、OSレベルでサポートしてほしいようなものをユーザーでやってても仕方がないわけで、それじゃニッチなだけじゃないかと。
>>例えばCE機とかでWindows(x86)のアプリ動かすのにWINE経由は無駄じゃない?
>何、馬鹿な事言ってるんですか?
そうですか、ふむ。唐突にCEなんて例えを使ったものだからどうも混乱されたようですね。
単にOSにCPUエミュ機能が搭載されてなくて、CPU別のバイナリ配布が目立つものといえばCEがあるだろう。そういうハードになんとかLinuxを入れてQEMUでWINEで代りのWin32バイナリが動かないものだろうか?といった話なんですが、元々サブセット?なネイティブAPIが入ってるようなマシンで、わざわざ代替APIをエミュレーションで動かすのもなんだなあと思ったんですが、まあそれはWINEの設定次第かもしれません。でも。
>仮想機上に、もう一個OS入れるなんて無駄。
>じゃあ、QEMUで。というわけです
こういうコンセプトであるなら、なんで実機にわざわざ新しいOS(Linux)を導入しなければならないのでしょう?
そんなことせずに今使っているOSで、同じOS等での別CPUバイナリが動くQEMUが欲しくなりませんか?
>archの違う同一OS上で、アプリの相互利用やテスト
>WINEのような代替APIがあれば、x86以外のarchでそのOSのアプリが動かせる
というのがQEMUということであれば、なにもLinuxに限定されるようなものではないはずです。
現在のQEMUのユーザーモードはLINUXで動いてるから、LINUXアプリの時がネイティブAPIでそれ以外が代替API(WINE等)という話になるんであって、他のOSでのportを考えるんだったらあべこべなのでそこを差し替えないといけない訳です。(別に全部代替APIでもいいけど)
だからこそ、高速なCPUライブラリと、それを利用したフルエミュレーションモード、LINUXが前提なユーザーモードを、わけてそれぞれ類似プロジェクトと連携させたほうがいいのではないかということです。
QEMUのCPU部分以外が別プロジェクトなんていう話はきいてませんが?
>そもそも、Windows系OSにWINEはportもされてません。
WINEではないですけど、「エミュレートを行なわずにWindowsプログラムをNetBSDで実行可能にするためのDLL群」である PEACE [haun.org] の一部をWindows(Cygwin/XFree)に 移植した例 [dion.ne.jp]はあるようです。
どちらかというとWINEのほうがシステムから独立してて移植しやすそうな印象なんだけど、そうでもないってことなんでしょうね。