C# und Java Programme in naive Anwendungen umwandeln
-
Das ist jetzt vielleicht ein blöder Einfall, aber er ist mir in den Sinn gekommen: Der bei Java und C# erstellte Zwischencode wird ja von der Virtual Machine bei Programmstart (oder während des Programms) in Maschinensprache umgewandelt. Könnte man da nicht irgendein Programm zwischenschalten, das die Daten der Umwandlung abfängt (zB indem es den Arbeitsspeicher ausliest) und daraus dann eine native Exe Datei macht?
-
Und dann?
-
Warum einen Mechanismus umgehen und damit alle seine Vorteile aushebeln?
Ob man könnte oder nicht:
Ich denke, dass ist eher sehr kompliziert da moderne JIT Compiler i.d.R nur das Übersetzen was gebraucht wird. Und auch wenn alles an einem Stück ist erscheint mir dies kompliziert.Simon
-
Es gibt auch sowas hier:
http://gcc.gnu.org/java/Damit lässt sich Java-Sourceode oder Java-Bytecode in native Programme übersetzen.
Inwiefern das nützlich ist, ist eine andere Frage. Es gibt sicherlich Fälle, wo das nützlich ist, aber in den meisten Fällen kann man Programme genauso gut in einer VM ausführen.
-
Helium schrieb:
Und dann?
Dann braucht der Benutzer kein .NET-Framework mehr. Ich finde die Sprache C# ziemlich gut gemacht, genauso wie die Funktionen, die das .NET-Framework bereit stellt. Aber ich bin kein Freund der Art und Weise, wie das ganze realisiert wird. Mir wäre es lieber, wenn es auch eine native WinAPI-Implementierung von .NET gäbe.
simon.gysi schrieb:
Warum einen Mechanismus umgehen und damit alle seine Vorteile aushebeln?
Welche Vorteile hat denn der Zwischencode von .NET? Er läuft auf allen Plattformen ... die Windows heißen. Na super! Eine WinAPI-Anwendung läuft in der Regel auch auf allen Windows-Plattformen.
nevermore schrieb:
Es gibt auch sowas hier:
http://gcc.gnu.org/java/Doch damit ist eine Hello-World-Anwendung mal eben 3 MB groß. Außerdem ging es mir eher um C#.
Helium schrieb:
Inwiefern das nützlich ist, ist eine andere Frage. Es gibt sicherlich Fälle, wo das nützlich ist, aber in den meisten Fällen kann man Programme genauso gut in einer VM ausführen.
Der typische Durchschnittsdau kommt mit Stand-Alone-Exe-Dateien besser zurecht als mit einem Programm, für das er erst mal ein riesiges Framework installieren muss.
-
Für Linux und andere Unices gibt's auch noch Mono.
-
.filmor schrieb:
Für Linux und andere Unices gibt's auch noch Mono.
Ich glaube, das hilft mir nicht weiter bei der Idee, C#-Programme in nativen Windows-Code umzuwandeln.
-
Sorry, aber du rallst ja wohl überhaupt nicht, welche Vorteile eine moderne VM gegenüber nativen Anwendungen hat. Ich empfehle dir, mal ein vernünftiges Buch über .NET oder Java zu lesen. Hinter der Laufzeitumgebung von .NET steht schon ein wenig mehr als "alle Plattformen die Windows heißen". Ich würde dir ja ein paar Punkte nennen die du mit deinem Gebrabbel völlig außer acht lässt, aber ich opfere meine Zeit lieber für sinnvolle Dinge.
-
Zumal das mit dem .NET kein Problem ist.
WEnn du nicht immer darauf hinweisen willst, dass das gebraucht ist nutzt du eben nen Installer.
Wenn du nur ne moderne Sprache suchst, die sonst aber nativ ist dann nimm D
-
LOLwieDoof schrieb:
Sorry, aber du rallst ja wohl überhaupt nicht, welche Vorteile eine moderne VM gegenüber nativen Anwendungen hat.
Dann nenn doch mal ein paar!
-
Mit .NET kannst du deine Asssembly native Abbilder erstellen, die dann optimiert sind auf deine Ziel CPU.
-
LOLwieDoof schrieb:
Sorry, aber du rallst ja wohl überhaupt nicht, welche Vorteile eine moderne VM gegenüber nativen Anwendungen hat.
Das müsstest Du dann aber auch jedem vorwerfen, der noch C++ benutzt, statt eine Sprache, die in einer VM läuft.
Mir geht es um folgendes: Ich finde C# gut und ich finde die .NET-Klassenbibliothek gut. Aber ich möchte trotzdem weiterhin nativ arbeiten.
Ich versteh sowieso nicht, wieso jedem, der mit .NET nativ arbeiten will, vorgeworfen wird, er hätte das Prinzip von .NET nicht verstanden. Rein logisch sind doch
- Programmiersprache,
- Framework-Klassensammlung und
- technische Implementierung
drei voneinander völlig unabhängige Sachen. Wieso wird also einer schief angeguckt, wenn er sagt, dass er auf Java oder C# umsteigen will, weil er dort leichter arbeiten kann, während die kompilierten Anwendungen weiterhin so sein sollen wie er es von C++ kennt? Was hat die logische Sprach- und Funktionendefinition mit der technischen Implementierung zu tun, so dass man sagen kann, C++ muss nativen Code erzeugen sein und C# muss Zwischencode erzeugen?
-
Hallo
Fred Burkle schrieb:
Ich finde die Sprache C# ziemlich gut gemacht, genauso wie die Funktionen, die das .NET-Framework bereit stellt. Aber ich bin kein Freund der Art und Weise, wie das ganze realisiert wird.
Kannst du das auch begründen oder ist das so ein Gefühl von dir?
chrische
-
Fred Burkle schrieb:
LOLwieDoof schrieb:
Sorry, aber du rallst ja wohl überhaupt nicht, welche Vorteile eine moderne VM gegenüber nativen Anwendungen hat.
Das müsstest Du dann aber auch jedem vorwerfen, der noch C++ benutzt, statt eine Sprache, die in einer VM läuft.
Über die Vorteile und Nachteile von VM und einer Sprache brauchen wir glaube ich nicht zu reden. Beides hat seine guten Gründe, und diese sind von Fall zu Fall unterschiedlich.
Fred Burkle schrieb:
Mir geht es um folgendes: Ich finde C# gut und ich finde die .NET-Klassenbibliothek gut. Aber ich möchte trotzdem weiterhin nativ arbeiten.
Ich versteh sowieso nicht, wieso jedem, der mit .NET nativ arbeiten will, vorgeworfen wird, er hätte das Prinzip von .NET nicht verstanden. Rein logisch sind doch
- Programmiersprache,
- Framework-Klassensammlung und
- technische Implementierung
drei voneinander völlig unabhängige Sachen.Nein, sind sie nicht. Sowohl Java als auch C# sind nicht nur Sprachen, sondern auf bestimmte Paradigmen hin geschaffen, und auch auf ihr Framework angepasst (oder umgekehrt die Sprache am Framework optimiert). Dies entspricht nicht den klassischen Sprachen wie C++ und Co, wo du einfach zwischen Bibliotheken hin und her wechseln kannst.
C# und das .Net Framework liefern gewisse Rahmenbedingungen. Sofern du diese Vorgaben verlässt, verwirfst du alles worin die Sprache und das Framework gut sind. Paradigmen und Entwurfsmethoden ändern sich nunmal, und entweder akzeptiert man die Vorgaben oder man sollte sich überlegen ob die eigenen Pläne und Zielsetzungen nicht überdacht werden müssen (Entweder in dem man bestimmte Sprachen/Frameworks ausschließt oder sich darauf einlässt).
cu André
-
Fred Burkle schrieb:
Mir geht es um folgendes: Ich finde C# gut und ich finde die .NET-Klassenbibliothek gut. Aber ich möchte trotzdem weiterhin nativ arbeiten.
Verabschiede dich von diesem Gedanken oder bleib bei C++. Ganz einfach.
-
Ganz einfach:
du musst System.Leichtgläubig und System.Ignorant und System.Bildungsmangel einbinden...
-
Sid2K7 schrieb:
...
Man sollte System.Beleidigungen lieber außen vor lassen. Unabhängig davon was ich von dem Anliegen des OPs halte, kann man auch normal diskutieren.
cu André
-
Fred Burkle schrieb:
Helium schrieb:
Inwiefern das nützlich ist, ist eine andere Frage. Es gibt sicherlich Fälle, wo das nützlich ist, aber in den meisten Fällen kann man Programme genauso gut in einer VM ausführen.
Der typische Durchschnittsdau kommt mit Stand-Alone-Exe-Dateien besser zurecht als mit einem Programm, für das er erst mal ein riesiges Framework installieren muss.
Wo bitte soll ich das geschrieben haben? Wenn du Zitierst, dann bitte richtig.
Jedenfalls, warum ist es besser, wenn der User die neuste VC Runtime installieren muss, als wenn er die .Net-Runtime installieren muss?
-
Warum sich einige immer gegen die Runtimes sträuben...
Am besten lässt man die Runtime und ihre selbstgeschriebene Superhyperapplikation weg, dann ist das sehr Userfreundlich und jeder DAU kommt damit zurecht, sogar die die ihre Superhyperapplikation geschrieben haben...SNCR. Ich weiss ist destruktiv.
-
Helium schrieb:
Wo bitte soll ich das geschrieben haben? Wenn du Zitierst, dann bitte richtig.
Tut mir leid, mein Fehler.
Helium schrieb:
Jedenfalls, warum ist es besser, wenn der User die neuste VC Runtime installieren muss, als wenn er die .Net-Runtime installieren muss?
Seit wann muss man bei C++-Progammen was installieren? Höchstens noch bei MFC-Anwendungen, aber das sind da bloß zwei DLL-Dateien, die auch lokal bei der Exe liegen bleiben können, im Gegensatz zu einem 20 MB Framework, das besonders bei älteren PCs schon mal so 15 Minuten braucht, bis es installiert ist und das der gewöhnliche DAU eben dann nicht installiert, wenn er nur das 100KB große Tool, das er eben aus dem Internet geladen hat, ausprobieren möchte.
tfa schrieb:
Verabschiede dich von diesem Gedanken oder bleib bei C++. Ganz einfach.
Kannst du mir denn ein C++ Framework nennen, das von den Funktionen her mit dem .NET-Framework mithalten kann?