Macht IL Sinn?

Hallo Leute,

warum macht man sich den Umweg und nutzt bei .NET einen P-Code-Interpreter statt eines normalen Compiler? Ich denke die Plattform und Sprachabhängigkeit hängt doch vom Framework gesamt ab und nicht von einem Zwischencode, der sich nicht mal bearbeiten lässt aber ausspionieren lässt (kann man das verhindern?).

Naja, P-Code-Interpreter ist nicht der passende egriff (-> VB), aber du meinst sicher IL-JIT-Compiler 😁

Nun, mit solchem Zwischencode erhält man sich binäre Kompatibilität. Wenn man lediglich eine Bibliothek anbieten würde, die auf verschiedenen Plattformen erhältlich ist, ansonsten aber nativen Code erzeugt, muss man jedes mal das Programm neu kompilieren. IL-Code vereinfacht es zudem, neue Sprachen für .NET zu erschließen. Da IL-Code auf einem höheren Niveau arbeitet, muss man sich als Programmiersprachenanbieter nicht um Plattformdetails kümmern.

Schließlich und endlich kommen noch Argumente wie Laufzeitoptimierung hinzu. IL-Code hat das Potenzial, von der Laufzeit abhänig von der Plattform optimiert zu werden (z.B. für MMX, 3DNow!, SSE, SSE2, Multiprozessoren usw.).

Auf der anderen Seite zahlt man natürlich auch den Preis, dass IL-Code leichter dekompiliert werden kann. Wenn du mal nach "obfuscator" suchst, wirst du aber Mittel und Wege finden, die es erschweren.

MfG VizOne

Hallo Seby,

als kleiner Zusatz zu VizOne's Antwort noch der Hinweis: Ohne IL-Code funktioniert Sprachenunabhängigkeit eben nicht. Einer der großen Vorteile von .NET ist, dass der eine in VB.NET eine DLL schreiben kann, der nächste sie in C# verwenden oder von darin enthaltenen Klassen ableiten kann usw.

Ohne den "Umweg" über IL funktioniert das eben nicht 🙂. Der IL-Code ist sozusagen der gemeinsame Nenner für alle .NET-Sprachen 🙂.

Viele Grüße,

Frank
www.frankeller.de

Aha, danke schön! nun ist leider ne neue Frage aufgetaucht: Wenn ich nicht gerade den CsharpEditor verwende, schlägt mir guidetocsharp.de vor. dass mit Notepad und dem Befehl csc die Kompilierung manuell gehe, aber die WinXP-Konsole kennt scheinbar kein csc zu verstehen (unbekannter Befehl ectl.)?!
Schließlich wundere ich mich, warum man nur mit int rechnen kann und nicht mit short oder byte bis zum jeweiligen gültigen Bereich (z.B. wird Byte/Short-Rechnung 1+1 nicht angezeigt, aber in int klappts).

Du solltest Windowsverzeichnis\Microsoft.NET\Framework_.NET Version_ in deine PATH-Variable aufnehmen. (WinXP: Systemsteuerung->System->
Erweitert->Umgebungsvariablen)

MfG VizOne

Du kannst aber eine NET-Anwendung sehr wohl mit ngen.exe zu Native Code kompilieren.
Dabei wird im Global Assembly Cache ein native code image erzeugt und
jedesmal verwendet wenn man die Anwendung startet.

Dadurch verliert man aber ein gewisses Potenzial an Laufzeitoptimierung (naja, z.Z. wohl eher ein theoretische Faktor).

MfG VizOne

Aha, so gehts es schon viel besser, danke!!