なぜOSが違うと実行ファイルを実行することができないのか?
実行ファイルにはマシンコードが記述されている。(と私は解釈している)
ダイナミックライブラリのことを考えなければ、OSは、実行ファイルを実行する時、ただ単にそのマシンコードをスタックに積む作業をしているだけなのではないだろうか?
つまり、実行ファイルに記述されているマシンコードがそのコンピューター上で有効なものならば、どんなOSを使っていても関係ないのではないだろうか?
もちろん、exeやapp、linuxの実行ファイルはそれぞれ情報の格納方法が違うため、そのままでは実行できないだろう。
ここで、wineというソフトを考えてみよう。
この論法で行くと、もしかしてwineは次にスタックに積むべきマシンコードをOSに教えているだけなのではなかろうか。
あるいは、wineが直接スタックに積んでいるのかもしれない。(複数の実行ファイルを同時に実行する管理を行うのはOSの仕事だからこれは考えづらい<←OSの仕事であることに自信はないけど多分そう>)
ということは、wineで実行できないような実行ファイルは存在しないのではないか?
しかし、現実には実行できないソフトが報告されており、実際、私がためしたwindowsソフトで動いたものは一つもない。(ためしたソフトはCoolNovoとJanetterだけですが)
考えられる原因と言えばただ一つ。
そう。ダイナミックライブラリだ。
実行ファイルが必要としているダイナミックライブラリが存在していなければ、当然動くはずがない。
また、聞くところによると、DirectXが関係してくると、動かない可能性が格段にアップするらしい。
しかし、常識的に考えて、wineがそれを準備していないわけがない。
一体なぜ動かないケースが出てくるのだろうか?
ところで、OSの仕事はどこからどこまでなのだろうか?
まずファイルやフォルダについて。
ファイルシステムに名前が付いているということは「HDDのどの位置に保存するか」とか「HDDのどの位置に特定の名前のファイルがあるのかを調べる」とかはOSの管轄外?
次にディスプレイの表示について。
もしかして1ピクセルずつどんな色を出力するかっていうマシンコードをスタックに積んでたりする?
ひょっとすると明確な区切りというのは無いのかもしれない。
ちょっと考え直してみよう。
やはりOSの仕事はマシンコードをスタックに積むだけなのではないだろうか。
実行ファイルに「この設定でウインドウを表示」とかいう記述を見つけたらその通りに計算して…っていうのはそういうダイナミックライブラリ
を用意しといてそのマシンコードを積めばいいだけの話だし…。
結局、複数の実行ファイルを実行するとき、いかにしてマシンコードをスタックに積むかというのがOSの仕事なのではないかという結論に至る。
考察以上。
なんだか煮え切らない気分。
今度調べよう。
ああそういえば、今度調べようって言ってて調べてない事柄沢山あるなあ。
とりあえず複素平面をまだ調べてないことを思い出したからまずそれを調べてみよう。
OSと実行ファイルについて。考察
- tk-xleader
- 記事: 158
- 登録日時: 14年前
Re: OSと実行ファイルについて。考察
Windowsの場合は、物理メモリのアドレスに直接アクセスしているわけではなくて、OSが用意した仮想アドレス空間のメモリにアクセスしてますからね。そのあたりが、Linuxなど他のOSと異なる部分なんでしょう。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 14年前
Re: OSと実行ファイルについて。考察
えーと。気になる記述が幾つか。
考えるのは良いことなのですよ。でも、同時に色々調べましょう。
1.マシンコードをスタックに積む
スタックに積むのはアドレスやデータです。命令をスタックに積むことはありません。
2.仮想アドレス空間
LinuxもMacOSXも仮想メモリ空間を使っています。
3.OSの仕事。正確にはOSカーネルの仕事。
リソースの管理と制限が仕事です。
メモリ・CPU・GPU・HDD・I/O全般。
4.OSとのインターフェイス
(1)プログラム→(2)DLL→(3)システムコール
スーパーバイザコールとかシステムコールとかOS毎に専用のインターフェスがあります。
これが大きな違いですね。DLLが無いことも問題ですが(3)の違いが決定的です。
C言語でもputs()でコンソールに出力するにはシステムコールのお世話になります。
デバッガで関数の中までステップインで追っかけてみると分かります。
つまり、WindowsAPIも最終的にはシステムコールが呼び出されるわけです。
5.Wineの仕組み
私も詳しくないですが、DLLをごまかしているのと(3)のシステムコールをシミュレートしていると思われます。
考えるのは良いことなのですよ。でも、同時に色々調べましょう。
1.マシンコードをスタックに積む
スタックに積むのはアドレスやデータです。命令をスタックに積むことはありません。
2.仮想アドレス空間
LinuxもMacOSXも仮想メモリ空間を使っています。
3.OSの仕事。正確にはOSカーネルの仕事。
リソースの管理と制限が仕事です。
メモリ・CPU・GPU・HDD・I/O全般。
4.OSとのインターフェイス
(1)プログラム→(2)DLL→(3)システムコール
スーパーバイザコールとかシステムコールとかOS毎に専用のインターフェスがあります。
これが大きな違いですね。DLLが無いことも問題ですが(3)の違いが決定的です。
C言語でもputs()でコンソールに出力するにはシステムコールのお世話になります。
デバッガで関数の中までステップインで追っかけてみると分かります。
つまり、WindowsAPIも最終的にはシステムコールが呼び出されるわけです。
5.Wineの仕組み
私も詳しくないですが、DLLをごまかしているのと(3)のシステムコールをシミュレートしていると思われます。
最後に編集したユーザー softya(ソフト屋) on 2012年10月30日(火) 15:28 [ 編集 1 回目 ]
Re: OSと実行ファイルについて。考察
DLLを用意してもLinux側でそれを再現できなければ動かすことができないわけですよ。
そもそもLinux(UNIX系OS)とWindowsでは画面を表示するアーキテクチャがまるきり異なるのでDirectXの再現が難しいのでしょうね。
あとLinuxで採用されているサウンドシステムに決定打がなくふらふらしているのもありますね。
ハードに直結する部分の多くは規格化されていますから資料を入手して調べることが大切だと思います。
そもそもLinux(UNIX系OS)とWindowsでは画面を表示するアーキテクチャがまるきり異なるのでDirectXの再現が難しいのでしょうね。
あとLinuxで採用されているサウンドシステムに決定打がなくふらふらしているのもありますね。
ハードに直結する部分の多くは規格化されていますから資料を入手して調べることが大切だと思います。
- MoNoQLoREATOR
- 記事: 284
- 登録日時: 14年前
- 住所: 東京
Re: OSと実行ファイルについて。考察
沢山の返信ありがとうございます。
調べるべきキーワードが沢山みつかったので、これから調べてみてその結果を日記にレポートしようと思います。
調べるべきキーワードが沢山みつかったので、これから調べてみてその結果を日記にレポートしようと思います。