Beachten Sie, dass es nicht um die .NET CLR geht, die Microsoft in die Atmosphäre drängt, um das Konzept des verwalteten Codes zu evangelisieren. Die meisten von euch wissen, dass verwalteter Code schon seit geraumer Zeit existiert und wenig mit Raketenwissenschaft zu tun hat.
Was ich gerne wissen würde, ist warum das Konzept der Laufzeit-Sicherheit in der Evolution von Computern so spät kam .
Ich weiß, das ist wie die Frage "Warum ist das erste Modell T Ford nicht mit Airbags und Sicherheitsgurten gekommen?". Dennoch bleibt die Relevanz der Frage bestehen, denn es liegt in der Natur des Menschen, bekannte Gefahren zu schützen. Z.B. Der erste T-Ford ging nicht schnell genug, um die Airbag-Forschung zu motivieren. Es ging nicht schnell genug, dass die Menschen so oft verurteilende Fehler machen, dass sie den Sicherheitsgurt in vielen Ländern als Gesetz und Standard motivieren würden.
In der Computer-Evolution ist es fast umgekehrt. Wir begannen mit Assembler, das Äquivalent, einen T-Ford bei 200mph mit einer Augenklappe zu fahren. Ich hatte das Vergnügen, mich mit ein paar alten Truckern aus dieser Ära zu unterhalten und diese Geschichten über den Assembler-Code, menschliche Debugger, Codezeilen usw. zu hören. Wenn wir einen wirklich fiesen Fehler in C machen, könnten wir enden mit einem Bluescreen. Vor Jahrzehnten konnte man mit beschädigter Hardware fertig werden und weiß was. Aber es ist ein Mysterium für mich - so viele Jahrzehnte, und alles, was wir getan haben, um den Crash weniger schmerzhaft zu machen, war der Bluescreen (Entschuldigung für die Verwendung von MS als Archetyp für alles).
Es liegt nicht nur in der menschlichen Natur, sich vor bekannten Gefahren zu schützen, es liegt auch in der Natur eines Programmierers, allgemeine Einrichtungen zu automatisieren und zu systematisieren , wie Fehlerprüfung, Speicherdiagnose, Protokollierungs-Frameworks, Backup-Wartung usw.
Warum haben Programmierer / Menschen nicht begonnen, die Aufgabe zu automatisieren, sicherzustellen, dass der Code, den sie dem System zuführen, das System nicht schädigt? Ja, natürlich, Leistung . Aber hey, das war lange vor jedem ernsthaft durchdringenden Hardware-Standard. Warum wurden Motherboards nicht mit Busarchitekturen und zusätzlichen Prozessoren ausgestattet, um "verwalteten Code" zu ermöglichen?
Gibt es irgendeine Metapher für Model T Fords, die nicht schnell genug sind, dass ich vermisse?
Lassen Sie uns dies von den ersten Prinzipien aus durchdenken.
Eine verwaltete Plattform bietet einen relativ sandboxierten Bereich zum Ausführen von Programmcode, der aus der Hochsprache erstellt wird, in ein Formular, das geeigneter ist, um von der Plattform ausgeführt zu werden (IL-Bytecodes). Darin sind auch Funktionen wie Garbage-Collection und Laden von Modulen.
Denken Sie jetzt über eine native Anwendung nach - das Betriebssystem stellt einen relativ sandboxierten Bereich (einen Prozess) zur Verfügung, um Programmcode, der von einer höheren Sprache erzeugt wird, in ein Formular zu bringen, das besser von der Plattform ausgeführt werden kann (x86-Opcodes). Darin sind auch Funktionen wie virtuelle Speicherverwaltung und Laden von Modulen enthalten.
Es gibt nicht viel Unterschied, ich denke, der Grund, warum wir die Plattform überhaupt verwaltet haben, ist einfach, weil sie die Programmierung der Plattform vereinfacht. Es sollte den Code zwischen Betriebssystemen portierbar machen, aber MS kümmerte sich nicht darum. Sicherheit ist Teil der verwalteten Plattform, sollte aber Teil des Betriebssystems sein - z. Ihre verwaltete App kann Dateien und ähnliches schreiben, genau wie bei einem normalen Prozess. Einschränken, dass dies ein Sicherheitsmerkmal ist, ist es kein Aspekt einer verwalteten Plattform, der nicht auf nativem existiert.
Letztendlich hätten sie alle diese verwalteten Funktionen in eine Reihe von nativen DLLs einfügen und die Idee des intermediären Bytecodes verwerfen können, JIT-Kompilierung stattdessen in nativen Code. "Verwaltete" Features wie GC sind auf nativen Heaps leicht möglich - siehe zum Beispiel das Beispiel von Boehm C ++.
Ich denke, MS hat es teilweise getan, weil es den Compiler einfacher zum Schreiben machte, und teilweise, weil Java so gemacht wurde (und .NET ist, wenn auch nur im Geist, ein Nachkomme von Java), obwohl Java es so gemacht hat um eine plattformübergreifende Kodierung zu ermöglichen, kümmert sich MS nicht darum.
Also, warum haben wir den Code nicht von Anfang an verwaltet - weil all die Dinge, die Sie als Teil von "verwaltetem" Code erwähnen, systemeigener Code sind. Managed-Plattformen, die wir heute haben, sind einfach eine zusätzliche Abstraktion auf einer bereits abstrahierten Plattform. Hochsprachen haben mehr Funktionen hinzugefügt, um Sie vor sich selbst zu schützen, Pufferüberläufe gehören der Vergangenheit an, aber es gibt keinen Grund, warum sie nicht in C implementiert werden konnten, als C erfunden wurde. Es ist nur so, dass sie es nicht waren. Im Nachhinein scheint es so, als ob diese Features fehlten, aber ich bin mir sicher, dass wir in 10 Jahren fragen werden "warum hat C # das offensichtlich nützliche Feature XYZ nicht implementiert, wie wir es heute haben"
Verwalteter Code, der in Sicherheit usw. eingebaut ist, gibt es schon lange.
In der ursprünglichen PC-Plattform war dafür kein Platz und es wurde später nie hinzugefügt.
Der ehrwürdige IBM Großrechner hat seit den 70er Jahren geschützte Adressierung, unantastbare Kernbibliotheken, rollenbasierte Sicherheit usw. usw. Außerdem wurde der gesamte Assembler-Code von einem (für die Zeit) hochentwickelten Änderungsmanagementsystem verwaltet. (Univac, Burroughs usw. hatten etwas Ähnliches.)
Unix hatte von Anfang an ziemlich gute Sicherheit eingebaut (und es hat sich im Laufe der Jahre nicht sehr verändert).
Also ich denke, das ist ein Windows- / Webspace-Problem.
Es gab noch nie einen Mainframe-Virus! Die meisten Finanztransaktionen in der Welt passieren diese Systeme irgendwann, also ist es nicht so, als wären sie kein attraktives Ziel.
Das interne IBM Mail-System hat allerdings den ersten "Trojaner" gehostet!
Tatsächlich gibt es verwalteten Code schon sehr lange. Überlegen Sie:
Alle bereitgestellten Betriebssystem-ähnlichen Umgebungen, die die Verwendung von Speicher- und anderen Ressourcensteuerungs-Problemen schützen. Und alle waren relative Misserfolge (BASIC war nur wirklich erfolgreich, wenn Features wie PEEK & amp; POKE, mit denen Sie sich mit dem zugrundeliegenden System anlegen konnten, eingeführt wurden).
Computer waren nicht stark genug, und sie leistungsfähig genug zu machen, war zu teuer. Wenn Ihnen nur begrenzte Ressourcen zur Verfügung stehen, zählt jeder Byte- und CPU-Zyklus.
Der erste Computer, den ich verwendet wurde, war ein Sinclair ZX Spectrum im Jahr 1982. Es weniger RAM hatte (16K) als die Größe einer einzigen Windows-Schriftdatei heute. Und das war relativ kürzlich, im Heimcomputer-Zeitalter. Vor der Mitte der 1970er Jahre war die Idee, einen Computer zu Hause zu haben, undenkbar.
Nur zur Erinnerung, wir haben die Montage nie manuell kompiliert. Wir haben Assemblersprachcode von Hand zusammengestellt. Nun, das ist klar ...
Ihre Analogie trübt die Frage, weil die Geschwindigkeit des Autos in diesem Sinne nicht der Geschwindigkeit des Computers entspricht: Die zunehmende Geschwindigkeit des Autos erforderte die Änderung der automatischen Sicherheit, aber es ist nicht die erhöhte Geschwindigkeit des Computers Dies führt zu Änderungen in der Computersicherheit und erhöht die Konnektivität. Aus einem etwas anderen Blickwinkel: Für das Auto ist die zunehmende Geschwindigkeit die fahrende Technologie zur Erhöhung der Sicherheit. Für Computer ist die zunehmende Geschwindigkeit die ermöglichende Technologie zur Erhöhung der Sicherheit.
So waren die ersten Autos bei Unfällen sicher, weil sie langsam waren. Die ersten Computer waren sicher, weil sie nicht vernetzt waren.
Autos werden jetzt sicherer gemacht durch Sicherheitsgurte, Airbags, ABS, Antikollisionsgeräte und so weiter. Computer werden durch zusätzliche Techniken sicher gemacht, obwohl Sie immer noch nicht das Netzwerkkabel abziehen können.
Das ist eine Vereinfachung, aber ich denke, dass es im Mittelpunkt steht. Wir brauchten das damals nicht, weil Computer nicht mit dem Netzwerk verbunden waren.
Derselbe Grund, warum es vor 300 Jahren keine Züge gab. Aus dem gleichen Grund gab es vor 30 Jahren keine Handys. Derselbe Grund, warum wir immer noch keine Teleportationsmaschine haben.
Technologie entwickelt sich im Laufe der Zeit, es heißt Evolution.
Der Computer war damals nicht stark genug. Das Ausführen eines Garbage Collectors im Hintergrund hätte die Anwendungsleistung beeinträchtigt.
Ich spreche zu Ihrer Frage, warum Computer nicht über die Schutzmechanismen auf der Ebene von verwaltetem Code verfügten, und nicht darum, warum VMs nicht auf langsamer Hardware ausgeführt werden konnten (bereits in anderen Posts erläutert). Die kurze Antwort ist, dass es war. CPUs wurden entwickelt, um eine Ausnahme auszulösen, wenn der Code falsch war, damit das System nicht beschädigt wird. Windows behandelt das notorisch schlecht, aber es gibt andere Betriebssysteme da draußen. Unix übergibt es als Signale, so dass die Programme beendet werden, ohne das System herunterzufahren. Unabhängig davon, ob Sie verwalteten Code ausführen oder nicht, wird eine Nullzeiger-Ausnahme auf die gleiche Weise ausgeführt - bei Programmbeendigung. Der virtuelle Speicher sorgt dafür, dass Programme sich nicht mit anderem Code anlegen, also tun sie sich nur selbst weh.
Was mich zu meinem zweiten Punkt bringt. All das ist unnötig, wenn Sie wissen, was Sie tun. Wenn ich meine Möbel sauber halten will, lasse ich einfach kein Essen darauf fallen. Ich muss mein Haus nicht mit Plastik bedecken, ich muss nur vorsichtig sein. Wenn Sie ein schlampiger Programmierer sind, wird die beste VM der Welt Sie nicht retten können, es wird Ihnen nur erlauben, Ihren schlampigen Code ohne Rauschen zu laufen. Portierungscode ist auch einfach, wenn Sie die richtige Kapselung verwenden. Wenn Sie ein guter Coder sind, hilft verwalteter Code nicht ausgiebig. Deshalb benutzen nicht alle es. Es ist einfach eine Frage der Präferenz, nicht besser / schlechter.
Was die Laufzeit-Sicherheit betrifft, gibt es nichts, was ein P-Code-Compiler vorhersagen kann, was ein Maschinencode nicht kann, und nichts, was ein Interpreter mit verwaltetem Code handhaben kann, kann das OS nicht (oder nicht) . Motherboards mit extra Bussen, CPUs und Befehlssätzen kosten viel mehr Geld - bei der IT kommt es auf das Preis- / Leistungsverhältnis an.
Im Jahr 1970 waren die Kosten für die Erinnerung rund $ 1 / Bit (ohne Inflation) ). Sie können die Luxusabfallsammlung mit solchen Kosten nicht leisten.
Warum haben wir nicht einfach Flugzeuge und Raumschiffe gebaut, anstatt mit Pferdewagen und all den langweiligen Sachen herumzuhupen?
Ich denke wie die meisten Fragen: "Warum hatten wir vor zehn Jahren noch kein X in der Programmierung?" Die Antwort ist die Geschwindigkeits- / Ressourcenzuweisung. Mit begrenzten Ressourcen mussten sie so effektiv wie möglich verwaltet werden. Die allgemeine Art der Verwaltung in Verbindung mit verwaltetem Code wäre zu ressourcenintensiv gewesen, um in zeitkritischen Anwendungen von Vorteil zu sein. Dies ist auch ein Grund dafür, dass der heutige leistungskritische Code immer noch in C, Fortran oder Assembler geschrieben ist.
Die Verwendung einer Zwischensprache erfordert eines von zwei Dingen:
Eine Sache, die sich im Laufe der Jahre geändert hat, ist, dass viele Programme die am häufigsten verwendeten Teile ihres Modus viel öfter als früher verwenden. Angenommen, das erste Mal, wenn eine bestimmte Anweisung ausgeführt wird, wird eine Strafe in Höhe von 1.000 Mal so lange wie bei nachfolgenden Ausführungen entstehen. Wie wirkt sich diese Strafe in einem Programm aus, in dem jede Anweisung durchschnittlich 100 Mal ausgeführt wird? Welche Auswirkungen hat diese Strafe auf ein Programm, in dem jede Anweisung durchschnittlich 1.000.000 Mal ausgeführt wird?
Just-in-Time-Compiling war lange Zeit möglich, aber in den achtziger oder neunziger Jahren wären die Performance-Kosten inakzeptabel gewesen. Da sich die Technologien geändert haben, sind die praktischen Kosten der JIT-Kompilierung so weit zurückgekommen, dass sie völlig praktisch sind.
Für was es wert ist, lese ich ein paar Papiere für meine Computersprachklasse (eine von CAR Hoare und eine andere von Nicholas Wirth), die genau das unter anderem in den 60er und 70er Jahren vertritt.
Ich kann nicht genau sagen, warum diese Dinge nicht passierten, aber ich vermute, dass es nur eines dieser Dinge ist, die im Nachhinein offensichtlich sind, was zu dieser Zeit nicht offensichtlich war. Es ist nicht so, dass frühere Compiler sich nicht um Sicherheit kümmerten. Es ist so, dass sie unterschiedliche Vorstellungen davon hatten, wie man das macht.
Hoare erwähnt die Idee eines "Checkout-Compilers". Soweit ich das beurteilen kann, ist dies im Wesentlichen ein Compiler, der statische Analysen durchführt. Für ihn war dies eine beliebte Technik, die versagte (oder zumindest nicht so viele Probleme löste, wie sie gelöst werden sollte). Die Lösung für ihn bestand darin, Programmiersprachen sicherer zu machen, indem man verwalteten Code erstellte (zumindest hätte er es so formuliert).
Ich könnte mir vorstellen, dass die Idee von verwaltetem Code im Wesentlichen tot war, als sich C (und später C ++) durchsetzten. Es ist nicht so, dass C eine schlechte Sprache war, nur dass es eine Assemblersprache und nicht eine Anwendungsprogrammiersprache sein sollte.
Wenn Sie eine Chance bekommen, können Sie Hinweise zum Programmiersprachen-Design . Es ist eine ziemlich gute Lektüre, wenn Sie an so etwas interessiert sind.
Beste Antwort auf diese Frage ist, IMHO, niemand hatte zu dieser Zeit eine Vorstellung von verwaltetem Code. Wissen entwickelt sich im Laufe der Zeit. Im Vergleich zu Feldern wie Architektur oder Landwirtschaft ist die Informatik ein sehr junges Feld. Das kollektive Wissen über das Feld ist also auch jung und wird sich mit der Zeit entwickeln. Vielleicht stoßen wir in ein paar Jahren auf ein neues Phänomen und jemand wird die gleiche Frage stellen: "Warum hat jemand nicht an XYZ gedacht?".
Ich würde sagen, dass es hauptsächlich der Wechselwiderstand war, gepaart mit der falschen Wahrnehmung der Ineffizienz der Speicherbereinigung, die die Einführung von GC und verwandten Techniken verzögerte. Natürlich hat das hirntote segmentierte Speichermodell auf Intel 8086 nicht gerade dazu beigetragen, vernünftiges Speichermanagement auf dem PC zu fördern.
Tags und Links history managed-code