シェルとカーネルの概念とプログラムの処理の流れ

質問

興味本位で「プログラミング」について、調べ学んでる内にひとつの壁にぶつかりましたので質問させていただきます。
質問内容は「シェルとカーネル。そしてアプリケーション」になります。

素人ながら現在持っている論理を下記に列挙します。誤認識などあれば指摘いただければ幸いであります。
狭義での論争は、避けたいので、広義として理解頂ければと思います。（狭義や曖昧な点においてもある程度学習済み）

1. プログラミング言語には、低級・高級言語があり、ハードよりのC言語（影響下のC++, Objective-C）で作られたプログラムの実行速度は速い。
2. プログラム処理系には、インタプリタ・コンパイラがあり、一般ユーザーが使用するアプリケーションのほとんど（.exeなど）がコンパイラアプリケーション。
3. JavaなどVM環境下動作するアプリケーションは、中間言語で実行される。
4. OSには中核であるカーネルがあり、カーネルは人工言語（コンピューター言語）を機械語に訳し、各リソース（CPU・RAMなど）に処理を実行させる。
5. カーネルはシェルに覆われており、実際のユーザー側の処理のリクエストは、シェルを介して行われる。
6. シェルには大別して、CLI(CUI)とGUIがあり、CLIシェルはプロンプトが表示されるコマンドラインインタプリタ。
7. GUIシェルは、OSがオペレーションの意から、OSの各種機能（Windows System, エクスプローラー等）。※ 私は理解を容易する為にOSそのものをシェルと捉えてます。

長くなりましたが、上記を踏まえた上での質問が下記になります。

Q. iTunes, Word, などの各種アプリケーションの各種操作（処理、実行）というのは、コンピューター言語でシェルを介し機械語でカーネルまで橋渡しされるのでしょうか？

なぜこのような質問になるかといいますと...
プログラミング言語は機械語にコンパイルして、はじめてコンピューターに理解してもらえる事は百も承知です。
プログラミング言語で制作されたアプリケーションの処理や実行は当然、コンパイル済みの機械語で行うものと認識しております。（ここでは中間言語は除く）
ここで冒頭に述べた壁に当たりました。洒落ではなく、私の中で「殻」もとい「壁化」してしまったシェルの存在です。
現在、持ち合わせてる論理から考察すると、機械語で実行された処理をシェルを介す意味がどこにあるのか？それとも介さずカーネルにそのまま引き渡してるのか？
私が間違っており、そもそも制作されたアプリケーションの処理や実行は、コンピューター言語であり、それをシェルを介しカーネルという流れがあるのならば、コンパイラの存在意義が分かりません。

本来はもっと自分が思ってる事を言語化出来ればいいのですが、これが現時点で精一杯です。

回答No.3

notnot

No1です。おおむね合ってると思います。

＞1. そもそも絶対的な位置付けは、コンピューターが解釈・実行するには機械語での指示が必須。

最終的にはそういうことですね。

＞2. それを容易にするための「シェル」であり。または、プログラム（プログラミング言語）。

シェルもプログラムの一種だと言うことをさておけば、その通り。

＞3. 私のような素人の「容易的シェル（造語で恐縮です）」の代表がGUIシェル（抽象度の高い）であり、より具体度が高い（ワイルドカードなど）処理等をするのであればCUIシェル。

ここはよく文意がとれず。

＞4. 一般的にアプリケーション開発は、OSに実装されているAPI（各種機能）を使う。そのAPIにも、低級・高級があり、Windows APIは高級に位置付けされ、ネイティブAPIと比べ開発がし易い。

「WindowsAPIは高級な物も低級な物もある」ということでしょうかね。「高級」「低級」は主管の問題とも言えます。また、何を以て「ネイティブAPI」というかは難しいです。OSが直接提供している物はすべてネイティブとも言えるし。
Unix/Linuxだと、APIは、OS機能を呼び出す「システムコール」と、それ以外の「サブルーチン」に明確に分かれているのですが、システムコール＝低級、サブルーチン＝高級と呼ぶと、一般用語の「低級」「高級」のイメージと合わないこともありますね。

あと、APIは「何らかの機能を提供するプログラムに対して、その機能を呼び出すときのやり方」のことなので、「Twitter.comに、HTTPでリクエストを送って、つぶやきの検索結果を得る」という機能もAPIです。アプリケーションがアプリケーションに対してのAPIですね。

＞5. アプリケーションの実行（処理）は、幾つかの形態があり一般化し難い部分があるが、広義において、APIを使うという点では一般化可能。（認識的意味合い）

これも文意がとれません。

＞コンパイルされたプログラム（.exe）の処理や実行は、機械語にコンパイル済みだからこそ実行出来るものだと思いますが、そこにはAPIを使用する上での手段も記述として含まれてると思います。私は当初、「コンパイル済みの処理や実行をなぜ、シェルを介さないといけないのか」愚直に悩んでおりましたが、

プログラムがシェルを利用する必要はありません。利用しても良いのですが。

＞そもそもGUI環境上で操作している事に盲目になっておりました、自ら「理解を容易にするためOSをシェルそのもの」と言っておきながらです...。単に「.exeの実行・処理」と抽象化し、それをする上でのアプローチ（OSの各機能の使用）を見逃しておりました。

これも、文意がとれません。

＞また、別質問になりますが、GUIアプリケーション開発にはAPI（またはその類）は必須なのでしょうか？例えば、純粋なプログラミング言語（C言語）のみで記述してもGUIの実現は可能なのか。

上で書いたように、「別のプログラムの機能を利用する」＝「（広義の）APIを利用する」です。
「広義の」というのは、「API」と名乗っていないかもしれないという意味。

従って、グラフィックチップに直接命令を出すプログラムを書けばAPIを使わずにGUIアプリを作ることは可能です。グラフィックチップの種類ごとに別のプログラムを書かないといけないので、現実的ではありませんが。そうでなければ何らかのAPIを使うことになります。ハードウェアに依存しないプログラムを書くのにはAPIは必須です。

＞または、CUIでGUI同等の操作（操作によると思いますが...）は出来るのかよければ教えていただきたいです。

これも意味がよくわからないのですが、ドット単位じゃ無くて、キャラクタベースのGUI（Windowsのコマンドプロンプトや、Linux等のターミナルの中で動くGUI）はあります。TUIとか言うみたいですね。
例えばRedHat系Linuxだと、system-config-network-tui をターミナルから起動すると、メニュー対話形式で、ネットワークの設定ができます。
http://www.atmarkit.co.jp/flinux/prodreview/rhel4/rhel4a.html の下の方に画面があります。

回答No.2

jjon-com

質問者は「カーネルを囲む殻」というイメージに単純化するあまり，一般的にはシェルと呼ばないものもシェルという用語で捉えていると思います。

シェルの要点は次の【】で示した点にあります。

--------
5. カーネルはシェルに覆われており、【実際のユーザー側の処理のリクエストは、】シェルを介して行われる。（shirouto8374自身の発言）

シェル (shell) はオペレーティングシステム (OS) の【ユーザーのために】インタフェースを提供するソフトウェア。

シェルはUNIXで使用される呼称であり、より一般的には【コマンドインタプリタ】と呼ぶ。
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB
--------

ユーザーは間違うんです。起動したいプログラムがどのディレクトリにあるのか知らないので探し回るし，どんなオプションを与えればよいのか分からずに人間は試行錯誤する。ファイル名の指定も単純な見落としや思い込みで間違えるかもしれない。
そんな人間にとっても使いやすい「ユーザーとの間の対話型のインタフェース」を提供するソフトウェア，それがシェルです。
ですからシェルを介したユーザーからの指示の解釈は，CUIにしろGUIにしろインタプリタ（通訳）的になるんです。最終的に行いたい機能自体を提供するのはカーネルであり，シェルはその機能に人間が到達するための「使いやすさ」を提供する通訳に徹する，シェル自身が機能自体を提供しているわけではないということです。

逆に言うと，
プログラム名・オプション・ファイル名などの指定は絶対に間違いがない，という前提で行ける。コンパイル済のアプリケーションプログラムがカーネルを呼び出すため，命令呼び出し上のエラーがないことは保証できる。というのであれば，シェルは介さないのです。
ただ，その場合，
コンパイル済のアプリケーションプログラムが素のカーネルを直接呼び出しているとは限りません。素のカーネルにさらに高度な機能を追加するための「カーネルを囲む殻」のような別ソフトウェアを呼び出していることが多々あります。
しかし，
その種のソフトウェアは一般的にはシェルとは呼びません。なぜならその種のソフトウェア自身が最終的に行いたい機能自体を提供するソフトウェアであり，人間との対話型環境を提供しているわけではないから。その種のソフトウェアの呼称としては，ミドルウェア，ライブラリ，APIなどが適当でしょう。
http://okwave.jp/qa/q7533808.html の私の回答No.1, No.2
http://okwave.jp/qa/q7443196.html の私の回答No.4

回答No.1

notnot

５のシェルの位置づけを除けば、おおむねあってます。

6,7でお書きのように、シェルは人間が直接OSに指示するときに使うプログラムのことです。シェルはあくまでアプリケーションプログラムの一種です。
Unix/Linuxだと、sh/bash/ksh/zsh/csh/tcsh や、各種ウィンドウマネージャ。
Windowsだと、Explorer とか cmd.exe など。

ユーザープログラムがOSカーネルの機能を利用するときの境界面は、一般的にはシステムコールと呼ばれます。Windowsだと、(OSに対しての)APIとかも呼ばれます。
生のシステムコールはプログラマフレンドリでは無いので、「システムコールを内部で呼び出すサブルーチン」をユーザープログラムから呼び出すことも多いです。printf()とか。

補足

回答ありがとうございます。

今の私にはやや難解な内容でしたが、概念を改める事が出来たので補足質問させてください。

ご指摘がありました、「シェルの位置付け」になりますが、厳密に考察することをやめました。（投げやりな言い方で恐縮です）

1. そもそも絶対的な位置付けは、コンピューターが解釈・実行するには機械語での指示が必須。

2. それを容易にするための「シェル」であり。または、プログラム（プログラミング言語）。

3. 私のような素人の「容易的シェル（造語で恐縮です）」の代表がGUIシェル（抽象度の高い）であり、より具体度が高い（ワイルドカードなど）処理等をするのであればCUIシェル。

4. 一般的にアプリケーション開発は、OSに実装されているAPI（各種機能）を使う。そのAPIにも、低級・高級があり、Windows APIは高級に位置付けされ、ネイティブAPIと比べ開発がし易い。

5. アプリケーションの実行（処理）は、幾つかの形態があり一般化し難い部分があるが、広義において、APIを使うという点では一般化可能。（認識的意味合い）

回答者さまの「API, システムコール, サブルーチン, 生のシステムコール」等のキーワードを頼りすることで、少し習熟度が向上したような気がします。

文脈から察するに「生のシステムコール」はネイティブという意味合いなのかなと思ったりしました。そう捉え、ユーザープログラムから呼び出す多様性もイメージしてる私がおります。

コンパイルされたプログラム（.exe）の処理や実行は、機械語にコンパイル済みだからこそ実行出来るものだと思いますが、そこにはAPIを使用する上での手段も記述として含まれてると思います。私は当初、「コンパイル済みの処理や実行をなぜ、シェルを介さないといけないのか」愚直に悩んでおりましたが、そもそもGUI環境上で操作している事に盲目になっておりました、自ら「理解を容易にするためOSをシェルそのもの」と言っておきながらです...。単に「.exeの実行・処理」と抽象化し、それをする上でのアプローチ（OSの各機能の使用）を見逃しておりました。

長文恐縮ではございますが、以上の認識に誤りがあるのであればご指摘いただきたいです。

また、別質問になりますが、GUIアプリケーション開発にはAPI（またはその類）は必須なのでしょうか？例えば、純粋なプログラミング言語（C言語）のみで記述してもGUIの実現は可能なのか。または、CUIでGUI同等の操作（操作によると思いますが...）は出来るのかよければ教えていただきたいです。