Nativ vs. Managed
-
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
-
Schonmal in solch eine "native" exe rein geschaut? Die gebaute .Net exe beinhaltet IL Code kein Mnemonik
Und es wird als exe ausgeliefert das du es normal ausführen kannst, wie jedes nicht-.net auch.
-
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Also nach dem Compileren sollten die nicht native sein, aber dafür gibst ein Tool von Microsoft:
http://msdn.microsoft.com/de-de/library/bb978898.aspx
-
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Weil .EXE unter Windows einfach enorm praktisch ist.
Denn damit kann es keine kompatibilitaetsprobleme geben wie man sie zB bei java hat, dass man regelmaessig .bat Dateien und sonstwas zum starten braucht
Und auf anderen Plattformen ist die extension ja eh egal, da es dort keine EXE gibt. Einzig wine <-> mono duerften sich ein bisschen beissen...
-
Hinzu kommt das der JIT-Compiler weit mehr kann. So kann z.B. Menge des freien Speichers und/oder Profiling-Statistik des ZIELCOMPUTERS vom JIT ausgenutzt werden um das Program optimal an den jeweiligen Kundenrechner anzupassen.
Das ist Wunschdenken ...
-
Shade Of Mine schrieb:
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Weil .EXE unter Windows einfach enorm praktisch ist.
Denn damit kann es keine kompatibilitaetsprobleme geben wie man sie zB bei java hat, dass man regelmaessig .bat Dateien und sonstwas zum starten braucht
Und auf anderen Plattformen ist die extension ja eh egal, da es dort keine EXE gibt. Einzig wine <-> mono duerften sich ein bisschen beissen...
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?
-
Eines will ich noch anmerken: Weder Java noch C# noch irgendeine .NET-JIT-bla-Sprache ist plattformunabhängig. In die Richtung gehen eher C und C++. Die "neueren" Sprachen bringen ihre ganz eigenen Plattformen ja mit. Ich halte es für Overhead. Den Sinn der JIT-Cs habe ich nie verstanden. Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
-
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
Klar, man kann auch einfach ausführbare .jar-Dateien haben, aber die registrieren einschlägige Packprogramme schon mal für sich, und das ist noch das geringste Problem. Wenn du kein (oder nicht das richtige) Java installiert hast, kannst du mit .jar-Dateien nichts anfangen. Wenn du kein .NET installiert hast oder die falsche Windows-Version verwendest, kann der native Stub in der Executable dir eine hübsche und hilfreiche Fehlermeldung anzeigen. Und wenn ich einen Prozeß terminieren will, fällt die Suche nach "MyDotNetApp.exe" eben doch etwas leichter als nach der richtigen "java.exe"-Instanz
Selbst für Java gibt es doch einige .exe-Packer; praktisch jedes ernstzunehmende Java-Programm wird unter Windows mit .exe-Stub ausgeliefert. So ganz sinnlos ist das nicht.
Ad aCTa schrieb:
Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus
Weil der Sourcecode dann für jeden, der ein bißchen mit einem Disassembler umgehen kann, offen zugänglich ist?
-
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
In der theorie sehr nett, in der praxis aber nicht so toll.
es hat seinen grund warum man die meisten java programme per bat datei/shell script startet. weil eben jar nicht immer korrekt verlinkt ist.das problem faellt bei exe dateien weg.
und bedenke: namen sind schall und rauch. welchen vorteil haette es denn wenn .net anwendungen eine andere extension haetten? keinen einzigen. waehrend ich dir fuer .exe einige vorteile aufzaehlen kann...
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?man koennte die datei auch .devent_ist_doof nennen. namen sind schall und rauch. exe ist automatisch mit dem system verknuepft, das ist auch schon alles. da muss kein x86 oder x64 oder xdevent Code drinnen sein...
-
Wozu denn denn ganzen Quellcode mitliefern? Bytecode hat doch genau den Zweck weitergegeben zu werden und auf dem Zielsystem in Maschinencode umgewandelt zu werden. Egal ob man das vor der Ausführung macht oder JIT.
Ich würd das ganze auch nicht so schwarzweiß sehen. Man kann Java Programme auch vor der Ausführung in Maschinencode wandeln, braucht dann aber natürlich eine Runtime Library statt einer VM. VC++ compiliert Quellcode auch erst in Bytecode, und erstellt daraus beim Linken dann Maschinencode. Da dies aber nicht auf dem Zielsystem passiert muss man natürlich Abstriche machen.
-
Ad aCTa schrieb:
Eines will ich noch anmerken: Weder Java noch C# noch irgendeine .NET-JIT-bla-Sprache ist plattformunabhängig. In die Richtung gehen eher C und C++. Die "neueren" Sprachen bringen ihre ganz eigenen Plattformen ja mit. Ich halte es für Overhead. Den Sinn der JIT-Cs habe ich nie verstanden. Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
Und wo ist da der Unterschied zum JIT-Compiler?
JIT-Compiler-Ansatz: es wird ein Sourcecode ausgeliefert (MSIL) der dann auf der Zielmachine compiliert wird.
Ad aCTa vorschlag: es wird ein Sourceode ausgeliefert der dann auf der Zielmachine compiliert wird.
Unterschied:
JIT-Compiler: User startet das Programm... Fertig
Ad aCTA vorschlag: User bekommt einen Sourcecode, mus den compilieren und kann dann erst das Programm starten.
-
Shade Of Mine schrieb:
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
In der theorie sehr nett, in der praxis aber nicht so toll.
es hat seinen grund warum man die meisten java programme per bat datei/shell script startet. weil eben jar nicht immer korrekt verlinkt ist.das problem faellt bei exe dateien weg.
und bedenke: namen sind schall und rauch. welchen vorteil haette es denn wenn .net anwendungen eine andere extension haetten? keinen einzigen. waehrend ich dir fuer .exe einige vorteile aufzaehlen kann...
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?man koennte die datei auch .devent_ist_doof nennen. namen sind schall und rauch. exe ist automatisch mit dem system verknuepft, das ist auch schon alles. da muss kein x86 oder x64 oder xdevent Code drinnen sein...
Ich kenne nur Java genau und da kann man die Jar Datei jemanden geben und er kann sie auf Linux/Windows/Mac/Solaris starten. Weil die Jar Datei nur Java-Bytecode enthält und man sie mit dem Java App Launcher (z.B. java.exe auf Windows) starten kann.
Wieso kriegt man also mit C#/.net eine Exe Datei? Damit man für Linux/Windows/Mac/Solaris jeweils eine eigene Executable kompilieren muss? (Wenn man davon ausgeht, dass man .net für Mono entwickelt).
Oder ist es, wie du sagst, gar keine Executable sondern eine C# Bytecode als eine .exe Datei benannt? So wie eine Jar Datei ja nur ein Zip-Archiv ist.
PS: Ich frage, weil ich mit C# nicht auskenne. Mich als doof zu bezeichnen ist nicht sehr nett.
-
Die .Net exe beinhalten schon eine native Anwendungen. Allerdings macht die nicht viel. Es wird eine DLL geladen und dann eine Funktion aufgerufen die den Bytecode ausführt. Der Bytecode steht allerdings in einem abgetrennten Bereich, so dass dieser auch direkt ausgelesen werden kann. Daher ist das kein Problem die Anwendung auch unter anderen Betriebssystemen auszuführen.
-
Hallo,
Ad aCTa schrieb:
Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
Also ich finde den Vorschlag gut.
Der Vorteil ist das der Compiler-Vorgang teil des Installieren ist und damit für den User keine extra Belastung (okay das kostet etwas zusätzliche Zeit, dafür ist vielleicht der Download kleiner weil Source-Code besser komprimiert werden kann). Beim JIT wird bei jedem Programmstart erneut angefangen zu optimieren, dafür kann man zwar ne Datenbank im Hintergrund haben die das Optimierungsergebnis des letzten Laufs enthält aber das erfordert wieder zusätzliche Arbeit. Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer). Da der Compiler bei der Installation nur ein mal angeworfen wird darf der sich auch etwas mehr Zeit zum optimieren nehmen als der JIT (dessen Zeitbedarf (auch wenn der mit ner Datenbank klein sein könnte) der User bei jedem Programmstart als Verzögerung sieht).
Von der Sicherheit nehmen sich beide Varianten gar nichts, in beiden fällen kommt man immer an den Source-Code ran. Selbst eine kompilierte EXE kann man disassemblieren, Okay das macht nicht wirklich Spaß ist aber prinzipiell möglich.Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
Grüße
Erik
-
Wenn ihr so was mögt, dann installiert euch Gentoo oder Sabyorn Linux.
Ich finde den Vorschlag sehr schlecht. Nicht nur weil ich nicht gerne 30min lang ein Programm kompiliere, sondern auch weil man dann die gesamte Build Umgebung und alle Abhängigkeiten des Programms braucht. Dann lade ich nicht ein 5 Megabyte, sondern ein 50 Megabyte Archiv runter.Unter Windows wird es ja noch schlimmer, weil die Programme untereinander nicht die Abhängigkeiten teilen können (z.B. muss jedes Programm seinen eigenen Compiler mitliefern). Des weiteren, vielleicht muss ein Programm mit einem Compiler oder Bibliothek kompiliert werden, das man gar nicht ausliefern darf. Muss man das dann alles mit DRM sichern? Wenn die Spinnerei von "Trusted Computing" (TPM) sich durchsetzt, dann vielleicht.
JIT macht schon Sinn. Man vereint die Vorteile eine vor-kompilierten Datei mit auf die Maschine optimierbaren Source Code.
-
erik.vikinger schrieb:
Der Vorteil ist das der Compiler-Vorgang teil des Installieren ist und damit für den User keine extra Belastung (okay das kostet etwas zusätzliche Zeit,
Etwas. ja. Ich denke an so lustige Sachen wie mal eben 3 Tage die Anwendung kompilieren die ich brauche. Toll. Jeder der Gentoo einmal verwendet hat kennt den Nachteil von diesem Ansatz (er hat natuerlich auch vorteile, aber die zeit die es dauert bis etwas installiert ist, ist krass hoch. und ich rede nicht von minuten, ich rede von stunden).
dafür ist vielleicht der Download kleiner weil Source-Code besser komprimiert werden kann).
vermutlich nicht wirklich viel.
Beim JIT wird bei jedem Programmstart erneut angefangen zu optimieren, dafür kann man zwar ne Datenbank im Hintergrund haben die das Optimierungsergebnis des letzten Laufs enthält aber das erfordert wieder zusätzliche Arbeit.
es gibt ja ansaetze, zB bei python wo beim ersten ausfuehren kompiliert wird und danach immer das kompilat benutzt wird. ist aber auch nicht wirklich so toll.
jitten geht so schnell, dass du keinen unterschied merkst ob der nativ startet oder erst gejittet wird. das einzige was du merkst ist das starten der virtuellen maschine - was ja zB bei .net wegfaellt.
Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer).
falsch.
Da der Compiler bei der Installation nur ein mal angeworfen wird darf der sich auch etwas mehr Zeit zum optimieren nehmen als der JIT (dessen Zeitbedarf (auch wenn der mit ner Datenbank klein sein könnte) der User bei jedem Programmstart als Verzögerung sieht).
Wie gesagt, wenn du mal 3 Tage zeit hast die creative suite zu komplieren oder aehnliches, bitte
und wie gesagt, das jitten merkst du nicht und jitter koennen PGO machen.Von der Sicherheit nehmen sich beide Varianten gar nichts, in beiden fällen kommt man immer an den Source-Code ran. Selbst eine kompilierte EXE kann man disassemblieren, Okay das macht nicht wirklich Spaß ist aber prinzipiell möglich.
nein. absoluter bloedsinn.
Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
nein
-
Shade Of Mine schrieb:
Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer).
falsch.
Gegenbeispiel?
-
maximAL schrieb:
Gegenbeispiel?
.net
die VM ist geladen und die DLLs dadurch auch. dadurch ist das starten einer anwendung fast instant, da keine externen dependencies geladen werden muessen. startest du dann eine Qt Anwendung, muessen da erst die relevanten dlls in den speicher geladen werden.
PS:
und da sich alle anwendungen eine vm teilen koennen, hast du auch keinen doppelten memory footprint bei den dependencies. waehrend du in c++ oefters sachen statisch linkst oder wegen der DLL hell lieber eigene DLLs mitnimmst.PPS:
natuerlich ist das nicht immer der fall, aber manchmal und das reicht um das argument zu widerlegen
-
Ureinwohner schrieb:
Dass "performanter" falsch ist, ist Quatsch und beruht in der Regel auf Vergleichen, die sorgsam so durchgeführt werden, dass das gewünschte Ergebnis rauskommt (d.h. so dass die Verzögerung vom JIT-Compiler und Laden des ganzen Frameworks nicht so stark ins Gewicht fällt und bestimmte Vorteile voll zuschlagen können). So wie Java angeblich auch genauso schnell sein soll wie C++ und C++ angeblich genauso schnell wie C.
-
Hallo,
Shade Of Mine schrieb:
erik.vikinger schrieb:
Der Vorteil ist das der Compiler-Vorgang teil des Installieren ist und damit für den User keine extra Belastung (okay das kostet etwas zusätzliche Zeit,
Etwas. ja. Ich denke an so lustige Sachen wie mal eben 3 Tage die Anwendung kompilieren die ich brauche. Toll. Jeder der Gentoo einmal verwendet hat kennt den Nachteil von diesem Ansatz (er hat natuerlich auch vorteile, aber die zeit die es dauert bis etwas installiert ist, ist krass hoch. und ich rede nicht von minuten, ich rede von stunden).
Das es so lange dauert war mir nicht bewusst.
Wenn ich an einen Media-Player denke der bei mir (Kubuntu) per Default als i586 installiert ist und manchmal ruckelt aber als i786 (oder was auch immer für nen Pentium M steht) mit SSE3 usw. ein anspruchsvolles Video gerade doch noch flüssig abspielt würde ich dafür gerne 1 oder 2 Stunden opfern.Shade Of Mine schrieb:
jitten geht so schnell, dass du keinen unterschied merkst ob der nativ startet oder erst gejittet wird. das einzige was du merkst ist das starten der virtuellen maschine - was ja zB bei .net wegfaellt.
Wenn das so schnell geht frage ich mich was die Compiler falsch machen oder ob der JIT nur ein deutlich schlechteres Ergebnis abliefert?
Shade Of Mine schrieb:
erik.vikinger schrieb:
Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer).
falsch.
Der JIT kostet auf jeden Fall Speicher, das ist bei einer fertig compilierten Executable nicht so. Ich rede nicht von irgendwelchen Librarys.
Shade Of Mine schrieb:
erik.vikinger schrieb:
Von der Sicherheit nehmen sich beide Varianten gar nichts, in beiden fällen kommt man immer an den Source-Code ran. Selbst eine kompilierte EXE kann man disassemblieren, Okay das macht nicht wirklich Spaß ist aber prinzipiell möglich.
nein. absoluter bloedsinn.
Bitte erklären. Eine vorcompilierte Executable ist etwas "sicherer" als ein Byte-Code und der ist etwas "sicherer" als der Source-Code, sicherer im Sinne von schwerer beim Reverse-Engineering. Wobei ich denke das der Unterschied zwischen Byte-Code und Quell-Text nur gering ist, zumindest haben mir Java-Decompiler diesen Eindruck vermittelt.
Shade Of Mine schrieb:
erik.vikinger schrieb:
Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
nein
Okay, ich hab übersehen das die Compile-Zeiten so extrem lang sind. Wenn die besser wären dann hätte JIT IMHO keine Existenzberechtigung.
Shade Of Mine schrieb:
die VM ist geladen und die DLLs dadurch auch. dadurch ist das starten einer anwendung fast instant, da keine externen dependencies geladen werden muessen. startest du dann eine Qt Anwendung, muessen da erst die relevanten dlls in den speicher geladen werden.
Der Vergleich hingt! Du redest von den Librarys, ich hab von dem JIT ansich gesprochen. Die Librarys kann man auch zwischen mehreren Prozessen teilen und die können auch schon beim OS-Start geladen sein. Das so eine in sich geschloßene Umgebung wie .net den Vorteil hat das es nicht X verschiedene Librarys für den selben Zweck gibt ist unbestritten, trotzdem lässt sich dieser Vorteil auch ohne VM und ohne JIT erreichen (zumindest theoretisch).
Grüße
Erik