Q&A
シェルと言えば一般的にCUIの方を指すんですか？
GUIもシェルだと思っていたんですが・・・
以前、よくwin32 APIを使用してGUIを作っていたんですが、このライブラリはwindows に依存しています。
GUIなどのシェルは、OSに依存しているものなのでしょうか？？
win32 APIがwindows上でしか動かせないのはOSに依存しているからですよね。
GUIはシェルとして扱われると思います。
Linux では着せ替え人形のようにシェルを変えることができます。
システムコールなどはOSによって違いますが、アセンブリ言語レベルでの命令はCPUによって違います。
しかし**シェルとカーネルは別物です。**arch linux などは最初からGUIが入っているわけではないです。
シェルがカーネルに依存していないなら、どうして他の環境に移せないのでしょうか？
(windowsにしかないシステムコールがあるのかな？このシステムコールじゃないとGUIを使えないよ・・・と言うならOSに依存していることになりますが)
・・・GUIはあくまでシェルなので、OSに依存していると言えるのでしょうか？
標準ライブラリでGUIを作成するのは無理です。
(本当はできるのかな？)
なぜできなんですか？
例えば
Windows - win32 API
Mac OS - objective-C
Linux - GTK+
ライブラリはOSによって異なると言うよりそのGUIに採用されているアプリケーションによって異なるのではないでしょうか？
つまり、カーネルが着ているGUIを変えれば必然とライブラリも変わりますよね。
windows のネイティブGUIはwin32 APIを使用しています。
windowsのGUIシェルは剥ぎ取り、例えばLinuxが採用しているGUIをwindows着せればGUIのネイティブライブラリはwin32 APIではなくなるのでは？
(Linux のGUI はgnome, GTK+, X window systemなどなど)
もしかして、WindowsのGUIコンポーネントはカーネルと融合しているのでしょうか？？
それだと、Windowsはシェルの着せ替えが出来ないことになりますよね。
独自のOSなので分からないですが・・・
GUIは他の環境に移せない・・・とよく言われますが（クロスプラットフォーム以外）
それは、OSが標準で採用しているGUIシステムの構成が異なるからですよね。
OSが標準で採用しているGUIシステムの構成を変えてしまえばよいのではないでしょうか？
windowsはブラックボックスで中身が分からないのですが・・・
分かる方いましたら教えて下さい。
回答2件
0
win32 APIがwindows上でしか動かせないのはOSに依存しているからですよね。
いえ、（理論上は）APIのインターフェースさえわかれば、他の環境で再現させることができます。実際に、wineというライブラリがあって、Unix系の環境上でWindows APIを再現して、Windows用のプログラムを一定の程度動かすことができます。
GUIなどのシェルは、OSに依存しているものなのでしょうか？
シェルもOSのAPIを使って動くアプリケーションなので、依存関係はAPIのほうにあります。
Windowsはシェルの着せ替えが出来ないことになりますよね。
Windows 3.1までは「プログラムマネージャ」というのがありましたが、Windows 95以降も（正確な時期は忘れましたが）シェルとして選ぶことができました。あまり一般的ではありませんが、Win32 APIでサードパーティーのシェルを作ることもできます。
投稿2017/07/17 09:47
総合スコア145183
0
ベストアンサー
こんにちは。
GUIなどのシェルは、OSに依存しているものなのでしょうか？？
「シェル・スクリプト」という言葉ご存知でしょうか？
bashなどのシェルをプログラムするための簡易言語ですね。
この文脈ではシェルはCUIオンリーです。
しかし、最近は「ウェブブラウザや電子メールクライアントはHTMLレンダリングエンジンの「シェル」といわれることがある。」そうです。
ならば、恐らくJava VMもその１つですね。
であれば、GUIシェル・プログラムは、既にOSフリーを実現できているということになります。
ところで、GUIプログラム開発の話なのか、GUIシェル・プログラム開発の話なのか、きちんと区別した方が良いと思います。
CUIの文脈だと、前者は例えばC言語でコマンドライン・プログラムを開発するイメージです。後者はBashスクリプトを作るイメージです。
【追記】
GUIプログラム開発の話ということですので、その主旨で回答してみます。
GUIライブラリを使うプログラムは当然GUIライブラリの作法に則ってプログラムを開発します。
当該GUIライブラリがマルチ・プラットフォームだったら、それを使うプログラムもマルチ・プラットフォーム対応しやすいです。（GUI以外の部分もちゃんとマルチ・プラットフォーム開発しないといけません。）
windowsのGUIシェルは剥ぎ取り、例えばLinuxが採用しているGUIをwindows着せればGUIのネイティブライブラリはwin32 APIではなくなるのでは？
それは無理です。Windowsはその名前の通りGUIと密接に関係しています。本来必要のない単なる非同期APIに何故かWindowに依存する部分があったりします。
それを剥ぎ取ったものは、もはやWindowsではないと思います。今までのWindows用プログラムは一切動かなくなります。
「WindowsにXwindowを入れよう」のリンク先で既にX-Window SystemをWindowsで動かしてますね。
シミュレションですが、それは仕方ないでしょう。カーネルの機能が異なるので、その部分のシミュレーションは必須です。
投稿2017/07/17 09:44
編集2017/07/17 10:21
総合スコア23272
WindowsでいうExplorerのような「GUIシェル」についての質問だと考えていました。
シェルのそもそもの意味はOSとユーザの間に挟まる薄い層を意味してます。
Shell=貝殻ですから。
GUIは重いのでそれを「薄い層」と言うのは厳しい印象です。
ただ、昔からC言語プログラムよりはシェル・スクリプトの方が簡単に開発できました。同様に、GUIプログラムを簡単に開発できる環境という意味で、ウェブブラウザをGUIシェルと表現するのは理解できます。
Explorerは簡易言語をサポートしていないように思います。
それをシェルと呼ぶのにはかなり抵抗を感じます。
今回の話は前者のほうかな？
後者は以前質問したので！！
自分としては、「OSのユーザーに対するI/Fとなるプログラム」というものとしてシェルを捉えていました。
たしかに、シェルをスクリプトで動かせれば便利ですが、それはシェルの必要条件ではないでしょう（DOS時代に、GUIの「MS-DOS Shell」がありましたが、これにもスクリプティング機能はなかったはずです）。
？(´Д｀)
あまり昔の話はさっぱりなのですが・・・
GUIはシェルと呼ばずになんと呼ぶのが自然なのでしょう？
シェルについての明確な定義はないので議論してもしかたないですね。
ただ、質問が曖昧すぎるのでそれを指摘した積りでした。
結局GUIプログラムの話だったようです。
GUIはGUIで良いのでは？ 何が問題か良く分からないです。
質問を超簡単に要約いたしますと・・・
「別の環境に移動した時、別のライブラリを使用するのではなく、GUIとして採用しているプログラムを変えればOSが変わってもライブラリ変えて１から勉強し直す手間が省けるのでは？？」
という事ですね。
「GUIがOSに依存していたらそれは無理ですよね・・・」
といった質問です。
わかりにくくてすいません。
「それは無理です。Windowsはその名前の通りGUIと密接に関係しています。」
つまり・・・Windowsカーネルと関わりが深いため、Linuxのように着せ替えができないわけですね。
ん～～。
他のOSと違ってwindowsはかなり特別なものなんですね。
> 質問を超簡単に要約いたしますと・・・
良く分からないです。単にマルチ・プラットフォームに対応したGUIライブラリを使えば「OSが変わってもライブラリ変えて１から勉強し直す手間が省け」ます。それとは異なる話でしょうか？
> 「GUIがOSに依存していたらそれは無理ですよね・・・」
WindowsはGUIに強く依存してますが、例えばQtを使えばlinuxとWindowsの両方で動作するアプリを開発しやすいです。
（追記：コメントが行き違ったのでコメント先を明記しました。）
> 他のOSと違ってwindowsはかなり特別なものなんですね。
確かにその通りですね。
windowsのGUIがカーネルと密接に関係しているなら、クロスプラットフォームなライブラリはどうやってOSに依存しないGUIの作成を実現しているんでしょうか??
おそらく、コンパイラがネイティブコードのレベルに落とし込んでいるのではないですか？
環境によって使用するAPIを切り替えればできそうですが・・・・
クロスプラットフォームなGUIよりネイティブなGUIの方が優れているのではないでしょうか？（私の予測ですが・・・）
windowsが採用しているGUIプログラムを調べ上げ、それをLinuxカーネルに着せれば、Win32 APIを使用してLinuxGUIを作成できるかと思ったのですが・・・それは無理ですね。
maisumakunさんの言う「APIの再現」をしない限りは・・・
> windowsのGUIがカーネルと密接に関係しているなら、クロスプラットフォームなライブラリはどうやってOSに依存しないGUIの作成を実現しているんでしょうか??
ライブラリが頑張って相違を吸収してます。
本質的に同じことができるのであればば可能です。
同じことをやるにしても、OS毎に流儀が異なるのでAPIも異なりますが、マルチ・プラットフォームなライブラリはその相違を吸収してます。
> おそらく、コンパイラがネイティブコードのレベルに落とし込んでいるのではないですか？
コンパイラがCやC++等で書かれたコードをマシン語に落としてますね。
その意味であればYESです。
> クロスプラットフォームなGUIよりネイティブなGUIの方が優れているのではないでしょうか？
速度やサイズという意味ならその通りです。
同じソースが多くのマシンで走ると言う意味では違いますね。クロスプラットフォームなGUIの方がネイティブのGUIより優れています。
> windowsが採用しているGUIプログラムを調べ上げ、それをLinuxカーネルに着せれば、Win32 APIを使用してLinuxGUIを作成できるかと思ったのですが・・・それは無理ですね。
既にありますよ。
https://ja.wikipedia.org/wiki/Wine
カーネルにシェルを着せ替えるのと「APIを再現する」というのは全く同じものなんですかね？
「OS毎に流儀が異なるのでAPIも異なりますが、マルチ・プラットフォームなライブラリはその相違を吸収してます。」
つまり、win32 APIにできることは全てクロスプラットフォームのライブラリでもできる！ということですか？
> カーネルにシェルを着せ替えるのと「APIを再現する」というのは全く同じものなんですかね？
少なくともCUIのシェルは単なるユーザ・プロセスのひとつですから、当然、複数同時に起動できます。マルチ・ウィンドウ・システムがなかった時代は、RS-232C等で接続した端末を標準入出力として複数の端末でBashやZsh等、異なるShellを同時に稼働できました。（当然、今も可能です。）
で、これらのShell上で走るプログラムは、シェル・スクリプトと呼ばれるものですね。Shellでやりたいことに特化したプログラムを作りやすいような命令文群をサポートしています。
このようなシェル・スクリプトを「アプリケーション・プログラム」と呼んでも必ずしも間違いではないですから、Shellの命令文群をAPIと呼んでも間違いではないと思います。
その意味で、「カーネルにシェルを着せ替える」＝「Bashを移植する」＝「Bash APIを再現する」と呼んでも間違いではないと思います。
Wikipediaの記事によるとウェブブラウザをGUIシェルと呼ぶ人たちもいるそうです。ウェブブラウザ上でJavaScriptが走りますね。当然JavaScript向けの命令群があり、それらをAPIと呼んでも間違いではないでしょう。
例えば、Chromeを昔のフィーチャフォンOSであるSymbianに移植することで、Symbian OS上で「JavaScript APIを再現する」ことは可能でしょう。このことを「Symbian OSのシェルを着せ替えた」と表現することも間違いではないと思います。
> つまり、win32 APIにできることは全てクロスプラットフォームのライブラリでもできる！ということですか？
そんなことはないですよ。OSが同じ機能を提供していなかったら、どう頑張っても出来ないかも知れません。同じ機能を提供していても、必要性が低くてライブラリがサポートしていないこともあるでしょう。
例えば、linuxとwindowsではセキュリティの考え方が大きく異なるので、みなさん苦労してます。Bash on ubuntu on Windowsとか涙ぐましい感じを受けます。Windowsのファイルシステにはないセキュリティ情報をサポートしないといけないから苦労してますよ。また、ファイル名に使える文字が異なるけどどのように吸収しているのか興味深いです。
> 「カーネルにシェルを着せ替える」＝「Bashを移植する」＝「Bash APIを再現する」
なるほど！！
CUIの場合は端末ごとに違うシェルを使用できますが、GUIの場合は複数の異なるシェルを同時に使用することって可能なんですか？
ウェブブラウザをGUIシェルと考えるなら、当然可能ですね。
chromeを複数起動できますし、更にfirefoxとchromeとIEを同じOSにインストールしたうえで、それぞれを複数起動できますね。
ああ～！
なるほど！
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/17 09:52
2017/07/17 10:01
2017/07/17 10:01
2017/07/17 10:02
2017/07/17 11:45
2017/07/17 12:13
2017/07/17 12:46
2017/07/17 12:56