なぜコードは最初から「管理」されなかったのですか？ [閉まっている

Question

これは、マイクロソフトがマネージドコードの概念を福音化するために雰囲気に突き刺さっている.NET CLRに関するものではないことに注意してください。あなたのほとんどは、管理されたコードがかなり長い間存在しており、ロケット科学とあまり関係がないことを知っています。

私が知りたいのはです コンピューターの進化におけるランタイムセキュリティの概念がとても遅れた理由.

これは、「最初のモデルTフォードにエアバッグとシートベルトが付いていなかったのはなぜですか？」と尋ねるようなものです。しかし、質問の関連性は、それにもかかわらず、まだ人間の性質の範囲内で、既知の危険を再び保護するのはよくあるからです。たとえば、最初のTフォードは、エアバッグの研究をやる気にさせるのに十分な速さではありませんでした。人々が致命的な判断のエラーを頻繁に行うのに十分な速さではありませんでした。

コンピューターの進化では、それはほぼ逆です。アセンブラーから始めました。アセンブラーは、アイパッチで200mphでTフォードを運転することに相当します。私はこの時代からいくつかの古いトラック運転手と会話することができて喜びを感じて、ハンドアセンブのアセンブリコード、人間のデバッガー、グリリオンのコードラインなどについてのこれらの話を聞くことができました。ブルーススクリーン付き。数十年前、あなたは損傷したハードウェアで終わる可能性があり、神は何を知っています。しかし、それは私にとって謎です - 何十年もの間、私たちがクラッシュするために私たちがしたことは、ブルーススクリーンだけでした（何でもArchetypeとしてMSを使用して申し訳ありません）。

既知の危険から保護することは人間の性質の中でだけではありません。 また、一般的な施設を自動化および体系化するプログラマーの性質の範囲内にあります, 、エラーチェック、メモリ診断、ロギングフレームワーク、バックアップメンテナンスなど

プログラマー/人間がシステムにフィードするコードがシステムに害を及ぼさないようにするタスクを自動化し始めなかったのはなぜですか？はい、もちろん、 パフォーマンス. 。しかし、ちょっと、これは深刻な浸透ハードウェアの標準のかなり前でした。マザーボードがバスアーキテクチャと追加のプロセッサで設計されて、「管理されたコード」を促進しなかったのはなぜですか？

T Fordsをモデル化するメタファーは、私が欠けているほど速く速くないことはありますか？

Answer 1

これを第一原則から考えてみましょう。

マネージドプラットフォームは、高レベルの言語から作成されたプログラムコードを実行するための比較的サンドボックス型エリアを提供します。ガベージコレクションやモジュールの読み込みなどのユーティリティ機能もあります。

ネイティブアプリケーションについて考えてみてください - OSは、高レベルの言語から作成されたプログラムコードを実行するための比較的サンドボックス領域（プロセス）を提供します。仮想メモリ管理やモジュールの読み込みなどのユーティリティ機能もあります。

大きな違いはありません。そもそもプラットフォームを管理した理由は、プラットフォームのコーディングを容易にするからです。 OS間のコードポータブルにするはずですが、MSはそれを気にしませんでした。セキュリティはマネージドプラットフォームの一部ですが、OSの一部である必要があります。管理されたアプリは、通常のプロセスと同様に、ファイルなどを書き込むことができます。セキュリティ機能である制限は、ネイティブに存在しない管理されたプラットフォームの側面ではありません。

最終的に、それらはすべての管理された機能をネイティブDLLのセットに入れ、中間バイトコードのアイデアを廃棄し、代わりにネイティブコードにコンパイルすることができました。 GCのような「管理された」機能は、ネイティブヒープで簡単に可能になります。たとえば、Boehm C ++ 1を参照してください。

MSは、コンパイラの書き込みを簡単にしたため、それがJavaの作成方法だからです。 - プラットフォームコーディングは可能です。MSは気にしません。

したがって、なぜ「管理された」コードの一部であると言及しているすべてのものがネイティブコードであるため、最初からマネージドコードを取得しなかったのはなぜですか。今日私たちが持っている管理されたプラットフォームは、すでに抽象化されたプラットフォームに加えて、単に追加の抽象化です。高レベルの言語には、あなた自身からあなたを保護するためのより多くの機能が追加されています。それは彼らがそうではなかったということです。おそらく、後知恵でこれらの機能が欠落しているように見えるかもしれませんが、10年後には「なぜ私たちが持っているように明らかに有用な機能XYZを実装しなかったのか」と尋ねると確信しています。

Answer 2

セキュリティなどで構築された管理コードは長い間存在しています。

元のPCプラットフォームには余地がなく、後で追加されることはありませんでした。

Venerable IBM Mainframeは、70年代以来、アドレス指定、手に負えないKernalライブラリ、ロールベースのセキュリティなどを保護しています。さらに、すべてのアセンブラーコードは、洗練された（当時）変更管理システムによって管理されました。 （Univac、Burroughなどには似たようなものがありました。）

Unixには、最初からかなりまともなセキュリティが組み込まれていました（長年にわたってあまり変わっていません）。

これは非常にWindows/Webスペースの問題だと思います。

メインフレームウイルスはありませんでした！世界の金融取引のほとんどは、ある時点でこれらのシステムを通過するため、魅力的なターゲットを否定しているわけではありません。

内部IBMメールシステムは、最初の「トロイの木馬」をホストしました！

Answer 3

実際、管理コードは非常に長い間存在しています。検討：

• 舌足らずの発音
• スモールトーク
• ベーシック（オリジナルフレーバー）

すべてが、メモリやその他のリソース制御の問題から使用を保護するオペレーティングシステムのような環境を提供しました。そして、すべてが相対的な障害でした（基本的なシステムを混乱させることができるPeek＆Pokeのような機能が導入された場合にのみ、基本的に成功しました）。

Answer 4

コンピューターは十分に強力ではなく、それらを十分に強力にすることは高すぎました。自由に限られたリソースしか持っていない場合、すべてのバイトとCPUサイクルがカウントされます。

私が使用した最初のコンピューターはaでした シンクレアZXスペクトル 1982年。今日の単一のWindowsのフォントファイルのサイズよりもRAM（16K）が少なくなりました。そして、それは比較的最近では、ホームコンピューターの時代でした。 1970年代半ば以前は、家にコンピューターを置くというアイデアは考えられませんでした。

Answer 5

記録のためだけに、私たちはアセンブリをハンドコンパイルすることはありません。アセンブリ言語コードを手で編成しました。今ではそれが明確です...

この意味では、車の速度がコンピューターの速度に類似していないため、あなたの類推が問題を曇らせています。自動車の速度の増加は、自動車の安全性の変化を必要としますが、コンピューターの速度が向上したのではなく、コンピューターセキュリティの変化が必要であり、接続の増加です。わずかに異なる角度から：車の場合、速度を上げることは 運転 安全性を高めるための技術。コンピューターの場合、速度の増加はです 有効化 安全性を高めるための技術。

したがって、最初の車は遅いため、事故で安全でした。最初のコンピューターはネットワーク化されていなかったため安全でした。

現在、車はシートベルト、エアバッグ、ABS、衝突防止装置などを通じてより安全にされています。コンピューターは追加のテクニックを通じて安全にされていますが、ネットワークケーブルのプラグを抜くことに勝るものはありません。

これは単純化ですが、私はそれが中心にあると思います。コンピューターはネットワークに接続されていなかったため、当時はそのようなものは必要ありませんでした。

Answer 6

300年前に列車がなかったのと同じ理由。 30年前に携帯電話がなかったのと同じ理由。私たちがまだテレポートマシンを持っていないのと同じ理由。

テクノロジーは時間とともに進化し、進化と呼ばれます。

コンピューターは当時十分に強力ではありませんでした。バックグラウンドでゴミコレクターを実行すると、アプリケーションのパフォーマンスを殺すでしょう。

Answer 7

VMが遅いハードウェアで実行できなかった理由ではなく、コンピューターにマネージドコードのレベルに保護メカニズムがなかった理由についての質問に話すと（他の投稿で説明されています）。簡単な答えは、そうだったということです。 CPUは、システムに損害を与えないように、悪いコードが発生したときに例外をスローするように設計されています。 Windowsはこれをうまく処理しませんが、他にもOSSがあります。 Unixは、システムを倒さずにプログラムが終了するように信号として渡します。実際には、マネージドコードを実行しているかどうかにかかわらず、ヌルポインターの例外が同じ方法で、プログラムの終了でも同じ方法で生じます。仮想メモリは、プログラムが他のコードを台無しにしないことを保証するため、できることは自分自身を傷つけることだけです。

それが私の2番目のポイントに私をもたらします。あなたが何をしているのかを知っていれば、これはすべて不要です。家具を清潔に保ちたい場合は、単に食べ物を落とさないでください。私は自分の家をプラスチックで覆う必要はありません、私はただ注意する必要があります。あなたがずさんなコーダーなら、世界で最高のVMがあなたを救うつもりはないので、ノイズなしでずさんなコードを実行することができます。また、適切なカプセル化を使用すると、コードの移植は簡単です。あなたが優れたコーダーである場合、管理されたコードは広範囲に役立ちません。だから、誰もがそれを使用していない理由です。それは単に好みの問題であり、より良く /さらに悪いことではありません。

ランタイムセキュリティに関する限り、Pコードコンパイラがマシンコードができないと予測できるものは何もありません。また、OSがまだできない（またはそうでない）マネージドコードインタープリターが処理できるものはありません。余分なバス、CPU、および命令セットを備えたマザーボードは、より多くの費用がかかります - それはすべてコスト/パフォーマンスの比率に関するものです。

Answer 8

1970年には、記憶のコストがありました 約1ドル/ビット （インフレなし）。そのようなコストで豪華なゴミコレクションを買う余裕はありません。

Answer 9

ほとんどの質問のように、「なぜ私たちは何年も前にプログラミングにXを持っていなかったのか」という答えは、速度/リソースの割り当てです。限られたリソースでは、可能な限り効果的に管理する必要がありました。マネージドコードに関連付けられた管理の一般的なタイプは、当時のパフォーマンス重要なアプリケーションで利益を得るにはリソースが消費されすぎていたでしょう。これは、今日のパフォーマンスクリティカルコードがまだC、Fortran、またはアセンブラーで書かれている理由の一部でもあります。

Answer 10

なぜ私たちは、馬と運動やそのすべての退屈なもので動き回るのではなく、飛行機と宇宙船を一度に建設したのですか？

Answer 11

中間言語の使用には、次の2つのことのいずれかが必要です。

1. 実質的なパフォーマンスのペナルティ（広く変動する - 発生的には2倍以下ですが、時には100倍以上）があります。
2. 余分なRAMが必要であり、実行されたステートメントの数の数ではなく、プログラムのサイズにほぼ比例する遅延を追加するジャストインタイムコンパイラ。

長年にわたって変化してきたことの1つは、多くのプログラムが、以前よりも多くの場合、モードの最も多くの使用を使用している部分を実行していることです。特定のステートメントが最初に実行されると、後続の実行が1,000倍のペナルティが発生するとします。各ステートメントが平均100回実行されるプログラムでは、そのペナルティの影響はどうなりますか？各ステートメントが平均1,000,000回実行されるプログラムに対して、そのペナルティの影響は何ですか？

ジャストインタイムコンパイルは長い間可能でしたが、1980年代または1990年代には、パフォーマンスコストは受け入れられなかったでしょう。テクノロジーが変化するにつれて、JITコンピレーションの実用的なコストは、それらが完全に実用的であるという点に帰着しました。

Answer 12

答えはより明確になります - 人間は執筆プログラムのために構築されていませんでした。マシンはそれをして、パックマンをプレイしてリラックスさせるべきです。

Answer 13

それが価値があることについては、私のコンピューティング言語クラス（1つは車のホア、もう1つはニコラスのワースによるもの）の論文をいくつか読みました。

なぜこれらのことが起こらなかったのか正確には話すことはできませんが、私の推測では、当時は明らかではなかった後知恵で明らかに見えるものの1つにすぎないと思います。以前のコンパイラがセキュリティを心配していなかったわけではありません。彼らはこれを行う方法についてさまざまなアイデアを持っていたということです。

Hoareは、「チェックアウトコンパイラ」のアイデアに言及しています。私が知る限り、これは基本的に静的分析を行うコンパイラです。彼にとって、これは失敗した人気のテクニックでした（または、少なくとも解決するために強化されたほど多くの問題を解決しませんでした）。彼にとっての解決策は、管理されたコードを作成することにより、プログラミング言語をより安全にすることでした（または、少なくとも彼はそれを最新の用語で置く方法です）。

C（およびその後のC ++）が捕まると、管理されたコードのアイデアが本質的に死んだと思います。 Cが悪い言語であるということではなく、アプリケーションプログラミング言語ではなくアセンブリ言語であることを意図していたということです。

チャンスがあれば読むかもしれません プログラミング言語デザインのヒント. 。あなたがこの種のことに興味があるなら、それはかなり良い読み物です。

Answer 14

この質問に対するベストアンサーは、IMHO、その時点で管理されたコードについて誰も考えていなかったことです。知識は実際には時間とともに進化します。建築や農業などの分野と比較して、コンピューターサイエンスは非常に若い分野です。そのため、この分野に関する集合的な知識も若く、時間とともに進化します。おそらく数年のうちに、私たちはいくつかの新しい現象に出くわし、誰かが「なぜ誰かがXyz Beoforeについて考えなかったのか」という同じ質問をするでしょう。

Answer 15

GCの採用と関連技術の採用を遅らせるガベージコレクションの非効率性の誤った認識と相まって、それは主に変化抵抗と結びついていると思います。もちろん、Intel 8086のBrain Deadセグメント化されたメモリモデルは、PCの正気なメモリ管理を促進するのに正確に役立ちませんでした。