history - 最初からコードを「管理」しなかったのはなぜですか?

Question

これは、Microsoft がマネージコードの概念を広めるために大々的に宣伝している .NET CLR に関するものではないことに注意してください。ほとんどの人は、マネージコードがかなり前から存在しており、ロケットサイエンスとはあまり関係がないことを知っています。

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

これは、「なぜ最初の T 型フォードにエアバッグとシートベルトが装備されなかったのか?」と尋ねるようなものです。しかし、既知の危険から身を守ることは人間の本能の範囲内であるため、この問題の関連性は依然として残っています。たとえば、最初の T-Ford は、エアバッグの研究を動機付けるほどの速さではありませんでした。人々が致命的な判断ミスを頻繁に犯すほど速く進まなかったので、多くの国でシートベルトが法律および標準として動機付けられました.

コンピュータの進化では、ほとんど逆です。私たちはアセンブラーから始めました。これは、眼帯を付けて時速 200 マイルで T フォードを運転するのと同じです。この時代の何人かの年配のトラック運転手と会話することができて、アセンブリコードの手作業による組み立て、ヒューマンデバッガー、コードのグリリオン行などについて話を聞くことができました。ブルースクリーンで。何十年も前に、ハードウェアが損傷してしまう可能性がありました。しかし、それは私にとっては謎です。何十年もの間、クラッシュの痛みを軽減するために私たちが行ったのは、ブルースクリーンだけでした (MS を原型として使用して申し訳ありません)。

既知の危険から保護することは人間の本能の範囲内にあるだけでなく、エラーチェック、メモリ診断、ロギングフレームワーク、バックアップメンテナンスなどの一般的な機能を自動化およびシステム化することは、プログラマの本能の範囲内でもあります。

プログラマー/人間は、システムにフィードするコードがシステムに害を与えないようにするタスクを自動化し始めなかったのはなぜですか? はい、もちろん、パフォーマンス. しかし、これは、真剣に浸透するハードウェア標準よりもずっと前のことです。「マネージコード」を容易にするために、バスアーキテクチャと追加のプロセッサを備えたマザーボードを設計しなかったのはなぜですか?

モデル T フォードが十分に速くないという比喩はありますか?

score 18 · Accepted Answer

セキュリティなどに組み込まれたマネージコードは、かなり前から存在しています。

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

由緒ある IBM メインフレームは、70 年代以来、アドレッシング、アンタッチャブルカーネルライブラリ、ロールベースのセキュリティなどを保護してきました。さらに、アセンブラーコードはすべて、洗練された (当時としては) 変更管理システムによって管理されていました。(Univac、Burroughs などにも同様のものがありました。)

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

したがって、これは非常にウィンドウ/Webスペースの問題だと思います。

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

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

score 11 · Accepted Answer

実際、マネージコードは非常に長い間使用されてきました。検討：

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

すべてが、メモリやその他のリソース制御の問題から使用を保護する、オペレーティングシステムのような環境を提供しました。そして、すべては相対的な失敗でした (BASIC が実際に成功したのは、基になるシステムをいじることができる PEEK や POKE などの機能が導入されたときだけでした)。

score 10 · Accepted Answer

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

私が最初に使用したコンピューターは、1982 年にSinclair ZX Spectrumでした。このコンピューターのRAM (16K) は、現在の単一の Windows フォントファイルのサイズよりも少なくなっています。そして、それは比較的最近のホームコンピューター時代のことです。1970 年代半ばまでは、自宅にコンピューターがあるという考えは考えられませんでした。

score 7 · Accepted Answer

記録のために、アセンブリを手動でコンパイルしたことはありません。アセンブリ言語コードを手作業で組み立てました。これではっきりしました...

車の速度はこの意味でコンピューターの速度に類似していないため、あなたのアナロジーは質問を曇らせています。コンピューターのセキュリティを変更する必要があるのは、接続性の向上です。少し別の角度から：車にとって、速度を上げることは安全性を高めるための運転技術です。コンピュータにとって、高速化は安全性を高めるための実現技術です。

そのため、最初の車は速度が遅かったため、事故が発生しても安全でした。最初のコンピュータはネットワークに接続されていなかったので安全でした。

現在、自動車はシートベルト、エアバッグ、ABS、衝突防止装置などによってより安全になっています。コンピュータは追加の技術によって安全になりますが、それでもネットワークケーブルを抜くことには勝てません。

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

score 6 · Accepted Answer

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

マネージドプラットフォームは、高水準言語からプラットフォームでの実行により適した形式 (IL バイトコード) に作成されたプログラムコードを実行するための、比較的サンドボックス化された領域を提供します。ガベージコレクションやモジュールの読み込みなどのユーティリティ機能もあります。

ここで、ネイティブアプリケーションについて考えてみましょう。OS は、高水準言語からプラットフォームでの実行により適した形式 (x86 オペコード) に作成されたプログラムコードを実行するために、比較的サンドボックス化された領域 (プロセス) を提供します。仮想メモリ管理やモジュールの読み込みなどのユーティリティ機能もあります。

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

最終的には、これらすべてのマネージド機能を一連のネイティブ dll に入れ、中間バイトコードのアイデアを廃棄し、代わりにネイティブコードに JIT コンパイルすることができたはずです。GC のような「管理された」機能は、ネイティブヒープで簡単に実現できます。例として、Boehm C++ の機能を参照してください。

MS がそれを行った理由の 1 つは、コンパイラの記述が容易になったためであり、Java がそのように作成された (そして、.NET は精神的にのみ Java の子孫である) ためでもあると思いますが、Java はクロスを作成するためにそのようにしました。 -プラットフォームのコーディングが可能で、MS は気にしません。

では、最初からマネージドコードを取得しなかったのはなぜですか。「マネージド」コードの一部として言及されているものはすべてネイティブコードだからです。今日のマネージドプラットフォームは、既に抽象化されたプラットフォームにさらに抽象化を加えたものにすぎません。高水準言語には、自分自身を保護するための機能が追加されています。バッファオーバーフローは過去のものですが、C が最初に発明されたときに C で実装できなかった理由はありません。そうではなかったというだけです。後から考えると、これらの機能が欠けているように見えるかもしれませんが、10 年後には、「今日のように明らかに便利な機能 XYZ を C# が実装しなかった理由」を尋ねることになるでしょう。

score 4 · Accepted Answer

300年前に電車がなかったのと同じ理由。30年前に携帯電話がなかったのと同じ理由。テレポーテーションマシンがまだないのと同じ理由です。

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

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

score 2 · Accepted Answer

1970 年、メモリのコストは約 1 ドル/ビット(インフレなし) でした。そんな費用で贅沢なガベージコレクションを買う余裕はありません。

score 1 · Accepted Answer

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

実行時の解釈。パフォーマンスが大幅に低下します（大きく変動します。場合によっては2倍以下、場合によっては100倍以上）。
ジャストインタイムコンパイラ。追加のRAMが必要であり、実行されるステートメントの数ではなく、プログラムのサイズにほぼ比例した遅延が追加されます。

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

ジャストインタイムコンパイルは長い間可能でしたが、1980年代または1990年代には、パフォーマンスコストは許容できませんでした。テクノロジーが変化するにつれて、JITコンパイルの実際のコストは完全に実用的なものになりました。

score 1 · Accepted Answer

ほとんどの質問と同じように、「Y年前にプログラミングにXがなかったのはなぜですか」という答えは、速度とリソースの割り当てです。リソースが限られているため、可能な限り効果的に管理する必要がありました。マネージコードに関連付けられた汎用タイプの管理は、リソースを消費しすぎて、当時のパフォーマンスが重要なアプリケーションでメリットを得ることができなかったでしょう。これは、今日のパフォーマンスが重要なコードがまだC、Fortran、またはアセンブラーで記述されている理由の一部でもあります。

score 1 · Accepted Answer

馬車や退屈なものをいじくり回す代わりに、なぜ飛行機と宇宙船を一度に構築しなかったのですか?

score 0 · Accepted Answer

答えはより明確になります - 人間はプログラムを書くために作られたのではありません。マシンがそれを行い、パックマンをプレイすることで私たちをリラックスさせてくれるはずです.

score 0 · Accepted Answer

参考までに、60 年代と 70 年代に特にこれを提唱したコンピューティング言語クラスの論文をいくつか (1 つは CAR Hoare によるもの、もう 1 つは Nicholas Wirth によるもの) 読みました。

これらのことが起こらなかった理由を正確に話すことはできませんが、当時は明らかではなかったものの、後から考えると明らかなことの1つにすぎないと思います. 以前のコンパイラがセキュリティを考慮していなかったわけではありません。それは、彼らがこれを行う方法について異なる考えを持っていたということです.

Hoare は、「チェックアウトコンパイラ」のアイデアについて言及しています。私が知る限り、これは基本的に静的解析を行うコンパイラです。彼にとって、これは失敗した (または少なくとも意図したほど多くの問題を解決しなかった) 人気のある手法でした。彼への解決策は、マネージコードを作成することでプログラミング言語をより安全にすることでした (少なくとも、彼は現代の言葉で言えばそう言ったでしょう)。

C (およびその後の C++) が普及すると、マネージコードの概念は本質的に消滅したと思います。C が悪い言語だったわけではなく、アプリケーションプログラミング言語ではなくアセンブリ言語を意図していたというだけです。

機会があれば、プログラミング言語設計のヒントを読むとよいでしょう。この種のことに興味があるなら、それはかなり良い読書です。

score 0 · Accepted Answer

この質問に対する最良の答えは、私見ですが、当時は誰もマネージコードのアイデアを持っていませんでした。知識は実際には時間とともに進化します。建築や農業などの分野と比較すると、コンピュータサイエンスは非常に新しい分野です。そのため、この分野に関する集合的な知識も若く、時間とともに進化します。おそらく数年後には、新しい現象に遭遇し、誰かが同じ質問をするようになるでしょう。

score -1 · Accepted Answer

ガベージコレクションの非効率性に対する誤った認識と相まって、GC および関連技術の採用を遅らせたのは、主に変更への抵抗であると言えます。もちろん、Intel 8086 の脳死状態のセグメントメモリモデルは、PC での適切なメモリ管理の促進にはまったく役立ちませんでした。

history - 最初からコードを「管理」しなかったのはなぜですか?

15 に答える 15

Related

Reference