Ich habe ein etwas exotisches Problem, und zwar versuche ich, innerhalb einer Methode einen Freiraum zu schaffen, der sich nach dem Compilieren in einer Ansammlung von "00"en, oder NOPs äußern soll, damit ich dort dann nachträglich assemblierten Code (manuell mit einem Hex-Editor oÄ) einfügen kann. Wie könnte ich sowas erreichen ?

mfg
- VampireSilence

Ich nehme an, dass du mit "nachträglich assembliertem Code" CIL-Code meinst. Dann könntest du z.B. mit Cecil die Assembly relativ komfortabel manipulieren. Aber beantworte doch bitte erst einmal die Frage, die sich jeder Leser dieses Threads stellen dürfte: Wofür??

German Grammar Glitch damit meinte ich nicht "nachträglich assembliert", sondern "assemblierter Code" und "nachträglich einfügen". Aber zu deiner Frage.

Wir Chemiker würden jetzt sagen "zur Grundlagenforschung". Genauer gesagt, will ich testen, ob es mir gelingt, auf diese Weise Code zu schreiben, der elementare Funktionen ersetzt, ohne dabei den Umweg über das .NET Framework zu nehmen. Davon erhoffe ich mir, die Geschwindigkeit bei bestimmten Berechnungen und Aufgaben zu erhöhen.

mfg
- VampireSilence

Da du auf das "CIL" in meinem Beitrag nicht eingegangen bist, gehe ich davon aus, dass dir noch niemand gesagt hat, dass eine Assembly nicht aus Assembler-Code besteht . .NET-Sprachen kompilieren nach CIL-Bytecode, also bringt es dir überhaupt nichts, wenn du dazwischen Assembler einfügst. Nur C++/CLI kennt den Trick, in einer Assembly nativen und Byte-Code zu vereinigen.

Wenn du nativ arbeiten möchtest, dann hast du dich schlicht für die falsche Programmiersprache entschieden...

Man sollte immer die Sprache wählen, die auch die Anforderungen erfüllt. Und wenn du mit Assembler optimieren möchtest, ist eine .NET Sprache ganz bestimmt das falsche.

Nebenbei hat eine solche Optimierung auf Assemblerebene aber auch gravierende Nachteile was die Portabilität des Codes usw. angeht...

Und Assembler so zu programmieren das es schneller ist als die gegebenen Funktionen ist meines Wissens nach eher schwierig.

Wenn man Assembler einigermaßen kann ist das nicht so schwer, denn insbesondere bei den heutigen Sprachen ist die Compileroptimierung nicht mehr das Hauptaugenmerk. Es geht da eher um in der Regel wichtigere Dinge wie Stabilität usw.

Du hast aber ganz andere Probleme:
Wenn du mit .NET normal entwickelst, kannst du den Code direkt auf 32-Bit und 64-Bit, auf verschiedenen Plattformen, ... verwenden. Das gilt mit XE 2 dann auch für Delphi. Wenn du Assembler benutzt, kann das logischerweise nicht gehen...

Also laut meinem Prof damals, wird der .NET-Code zuerst in JIT-Code umgewandelt und später von Plattformabhängigen Frameworks erst in Bytecode umgewandelt der der Plattform entspricht (.NET => Windows, Mono => Linux, etc.), ist das also falsch ?

Und ansonsten, naja ich meine .NET kann ja soviel CIL- oder JIT-Code oder was auch immer erzeugen so viel es will. Wenn ich irgendwo Assembler reinschreibe, sollte das doch eigtl auch Assembler bleiben, oder nicht ?

mfg
- VampireSilence

VampireSilence hat folgendes geschrieben :

Also laut meinem Prof damals, wird der .NET-Code zuerst in JIT-Code umgewandelt und später von Plattformabhängigen Frameworks erst in Bytecode umgewandelt

Genau andersherum: Der plattformunabhängige Bytecode wird vom Compiler in die Assembly geschrieben und zur Laufzeit dann vom JIT in Assembler übersetzt. Assembler in der Assembly nützt dir also wie gesagt überhaupt nichts.

VampireSilence hat folgendes geschrieben :

Wenn ich irgendwo Assembler reinschreibe, sollte das doch eigtl auch Assembler bleiben, oder nicht ?

Nein, wieso sollte das die CLR zulassen? Du wüsstest ja nicht einmal, aus welchen Registern du die Variablen lesen musst.

Ok, den ersten Teil hab ich dann wohl falschrum in Erinnerung gehabt. Ist auch ne Weile her. ^^

Aber zurück zu der CLR. Ich kann mir noch nicht genau vorstellen, wo genau die CLR dann meckern würde, aber ich glaub euch einfach mal, dass es einfach nicht geht.

Trotzdem: Könnte man dann nicht alternativ einfach die Assembly direkt in fertigen Assemblercode umsetzen und dann dort hinein den Assembler Code einfügen ? Auch auf die Gefahr hin, dass ich mich dann statisch auf eine Plattform festlegen müsste (kann mir ja relativ egal sein, weil ich überall nur Windows installiert habe).

mfg
- VampireSilence

VampireSilence hat folgendes geschrieben :

Aber zurück zu der CLR. Ich kann mir noch nicht genau vorstellen, wo genau die CLR dann meckern würde

Die CLR erwartet einfach Code in der CIL, einer bestimmten Sprache. Mit den Bytes einer nativen Exe kann diese schlicht nichts anfangen.

Du kannst das damit vergleichen als ob du einen C++ Compiler über Delphi-Quelltext jagst. Der kann damit auch nichts anfangen.

Oder damit, dass du ein fremdsprachiges Dokument irgendwo in Deutsch übersetzen lässt, dann aber eine Übersetzung in Swahili bekommst. Damit kannst du vermutlich auch nicht viel anfangen.

VampireSilence hat folgendes geschrieben :

Trotzdem: Könnte man dann nicht alternativ einfach die Assembly direkt in fertigen Assemblercode umsetzen und dann dort hinein den Assembler Code einfügen ?

Es gibt ngen. Das kompiliert deine Assembly. Allerdings kommt da keine Exe heraus, sondern es wird nur das kompilierte Image in dem passenden Verzeichnis abgelegt. Und das funktioniert auf genau deinem Rechner. Ich weiß nicht inwiefern auf CPU-Features optimiert wird, aber wenn funktioniert das auf einem anderen Rechner mit dem gleichen Betriebssystem auch nicht unbedingt. Denn der (JIT-)Compiler weiß ja exakt mit welcher CPU und welchem System die Exe laufen wird...


Wie gesagt: Wenn du so etwas willst, nimm nicht C# bzw. .NET.

Also auf www.eziriz.com/ wird ein Tool namens "NET Reactor" angepriesen, dass .NET-Anwendungen angeblich in native .exe-Dateien umwandeln kann, ohne sie von einem System abhängig zu machen. Die Demo sieht vielversprechend aus. Was meint ihr denn dazu ?

Und um mal auf die Ursprungsfrage zurück zu kommen: wenn ich jetzt meine .exe habe (durch ngen, oder was auch immer), wie bekomme ich dort dann den Freiraum in die Methoden hinein ?

mfg
- VampireSilence

Naja, es gibt viele solcher Tools, allen gemein ist aber normalerweise, dass es .NET Code bleibt. Es wird z.B. bei manchen das Framework mit integriert. Dann ist die Exe riesig, aber es muss kein .NET Framework installiert werden.

Und in diesem Fall ruft eine native Exe offenbar stückchenweise .NET Code auf um das Dekompilieren schwerer zu machen.

Ein Tool, das eine echte komplett native Exe erzeugt, kenne ich jedenfalls nicht. Und ich glaube auch nicht, dass sich jemand die Mühe macht. Denn es gibt eben genug Sprachen und Compiler, die das direkt schon machen...

Stimmt, ich hab mal die Demo getestet und die .exe ist nun 6 mal so groß wie vorher. Dann werde ich mich wohl doch irgendwann mit C++ auseinandersetzen müssen. Aber das is erstmal nicht weiter schlimm. Wäre ohnehin nur ein Test aus Neugierde geworden.

mfg
- VampireSilence

Da du von C# kommst, würde ich eher zu Delphi raten, das ist abgesehen von der grundsätzlichen Sytax (geschweifte Klammern, for mit Parametern in Klammern, ...) näher an C# dran finde ich.

Nein, also falls ich jemals wieder die Programmiersprache wechseln sollte, dann mache ich keine halben Sachen mehr.

Damit will ich C# in keinster Weise abwerten, aber C++ scheint offensichtlich die meisten Freiheiten zu bieten. Der Aufwand ist mir dabei völlig egal, weil ich ja sowieso nur nebenbei als Hobby programmiere.

mfg
- VampireSilence