Delphi- und .NET - Funktion

[faux]

Hallo!

Ich versuch grad, mich mal mit Delphi.NET zu beschäftigen. Also mit den Unterschieden zu Win32 und so.
Jetzt hätte ich eine Frage:

Gibt es einen Unterschied zwischen den zwei Befehlen (Also ich meine jetzt vom Prinzip her - nicht speziell auf WriteLn bezogen):

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

begin
  Borland.Delphi.System.WriteLn('Ausgabe');
  Console.WriteLine('Ausgabe');
  ReadLn;
end.

Also bei dem 1. wird ja, wenn ich das richtig verstanden habe, der Delphi-Code und beim 2. die .NET Funktion benutzt.

[Robert_G]

Warum nimmst du nicht einfach Lutz Roeders genialen Reflector und schaust dir den Code der Borland-Funktion an?
Würde mich nicht wundern, wenn sie Console.WriteLine benutzt, würde mich aber auch nciht wundern wenn es dafür P/Invokes nutzt. :?

[faux]

Das einzige wasmir auffällt ist, dass das Assembly 42KB hat, wenn ichs mit der Borland-Funktion mache und nur 19KB, wenn ichs mit der .NET-Funktion mache.

[Robert_G]

Und bevor du noch weitere fragen stellst, die sich mit einem Blick in die Assembly lösen lassen: Werfe doch mal einen Blick in die Assembly. Lutz Roeder Reflector damit solltest du ihn doch finden können. ;)

[faux]

Das habe ich gleich nach dem Beantworten getan. Danke.
Also bei der Delphi-Funktion hat er das Dekompilliert:

Delphi-Quellcode:

procedure Project2.Project2;
begin
  System.IsConsole := true;
  TextOutput.Output.WriteWideString('Hello World using Delphi.NET', 0).WriteLn;
  System.@_IOTest;
  TextInput.Input.ReadLn;
  System.@_IOTest
end;

Und bei der .NET-Funktion das:

Delphi-Quellcode:

procedure Project1.Project1;
begin
  System.IsConsole := true;
  Console.WriteLine('Hello World using Delphi.NET');
  Console.ReadLine
end;

Was heißt das jetzt?

[Robert_G]

Zitat:

Zitat von faux

Das habe ich gleich nach dem Beantworten getan. Danke.
Also bei der Delphi-Funktion hat er das Dekompilliert:
...
Was heißt das jetzt?

Du kannst mit Reflector richtig geil kranke Sachen machen. :)
Zum Beispiel sind Methoden und Typen im disassemblierten Code Links, die zur Definition führen. Er wird dich dann nach der Borland.Delphi.Dll fragen, die du unter Program files\common files\Borland shared\bds findest.
Und *puff* schon siehst du wie Borland diese Funktion geschrieben hat. :)

Edit: Übermäßige Zitate entfernt...

[faux]

Also ich glaube das habe ich jetzt kapiert. Danke.

Eine Frage nochmal (passt zwar net in den Thread, aber einen neuen aufmachen zahlt sich auch net aus):
Mit .NET gibt es dann eigentlich nur noch OpenSource - Programme, oder? :S
Also kein Proigrammierer kann seinen Code verbergen.

[Robert_G]

Es gibt Obfuskatoren, wie den coolen DotFuscator, aber auch andere.
Der Reflector wurde auch durch einen gescheucht. ;)
Hier ein paar generelle Infos zu was und wie es gemacht wird:
https://blogs.msdn.com/obfuscator/
btw: obfuskatierte binaries laden im allgemeinen schneller, sind kleiner und werden auch schneller JIT compiled. (Die Bezeichner sind ja selten länger als 2-3 Zeichen)

[faux]

OK, das war klar, dass sich da Microsoft was einfallen lassen hat. ;)

[CalganX]

Hi,
ich weiß nicht, ob das ganz klar ist, deswegen sage ich das jetzt noch mal gerade. ;)
Beim ersten verwendest du die explizit die Borland VCL.net, die - wie ich dir im anderen Thread schon gesagt habe - zur einfachen Migration dient. Dass dadurch das Kompilat/Assembly größer wird ist klar, da du die VCL.net nun miteinkompilieren musst. Beim Zweiten werden Methoden verwendet, die so oder so schon einkompiliert werden, weil sie im entsprechenden Namespace stehen, der (fast) immer mit einkompiliert wird.

Wenn du mit .NET programmierst solltest du dich immer für eines entscheiden. Da du nie sicher sein kannst, was Delphi intern in der VCL.net macht. Nachher fliegen dir Pointer (bzw. PInvokes) um die Ohren, die in .NET nix zu suchen haben. :mrgreen:

Chris

[faux]

Zitat:

Zitat von Chakotay1308

Nachher fliegen dir Pointer (bzw. PInvokes) um die Ohren, die in .NET nix zu suchen haben.

Das find ich gut, dass die nimma gibt. Das ist was, was ich bis jetzt noch nicht kappiert hab... ;)

[Speedmaster]

Pointer gibt es in .NET nach meinen Infos mehr als viele Leute wissen.

Soweit ich weiss baut darauf ihre Speicherverwaltung auf, und du bekommst nur einen Pointer auf einen Pointer, oder anderstrum!

Nur das Programmieren mit Pointern ist nicht mehr "In", besonderst nicht von Untypisierten.
.NET geht sogar nocht einen Schritt weiter, sämtliche Variablen werden z.b. in Proceduren als Pointer übergeben( Typisiert ), und nur auf Wunsch des Programmierers wird anderst verfahren.
Dies führte bei mir zu einer bösen überraschung am Anfang, als ich merkte das meine Variablen überschrieben wurden!

[Robert_G]

Zitat:

Zitat von Speedmaster

Pointer gibt es in .NET nach meinen Infos mehr als viele Leute wissen.

Jupp, definiere eine Methode als unsafe und du kannst mit Pointern arbeiten, wie gehabt. ;)
Aber natürlich brauchst du nun FullTrust und wehe dir, mono/pnet haben andere Größen für ihre Strukturen oder deine Assembly läuft in Win64.
(Wobei nur .Net 2.0 Assemblies dort als 64 Bit laufen...)

Zitat:

Nur das Programmieren mit Pointern ist nicht mehr "In", besonderst nicht von Untypisierten.

Genau! :)

Zitat:

.NET geht sogar nocht einen Schritt weiter, sämtliche Variablen werden z.b. in Proceduren als Pointer übergeben( Typisiert ), und nur auf Wunsch des Programmierers wird anderst verfahren.

Ein Objekt ist ein Pointer. Nur value types werden durch Kopieren ihres Wertes übergeben.

Zitat:

Dies führte bei mir zu einer bösen überraschung am Anfang, als ich merkte das meine Variablen überschrieben wurden!

War entweder ein D.Net Artefakt oder es waren lokale Variablen. Diese haben keinen Namen. ;)

[Speedmaster]

Zitat:

Zitat von Robert_G

Zitat:

.NET geht sogar nocht einen Schritt weiter, sämtliche Variablen werden z.b. in Proceduren als Pointer übergeben( Typisiert ), und nur auf Wunsch des Programmierers wird anderst verfahren.

Ein Objekt ist ein Pointer. Nur value types werden durch Kopieren ihres Wertes übergeben.

Zitat:

Dies führte bei mir zu einer bösen überraschung am Anfang, als ich merkte das meine Variablen überschrieben wurden!

War entweder ein D.Net Artefakt oder es waren lokale Variablen. Diese haben keinen Namen. ;)

Hmm, verstehe deine Antwort nicht ganz, gibst du mir nun Recht oder nicht?

Ich habe mit C# Programmiert, und ein Objekt als Parameter übergeben. Dieses wurde natürlich nicht kopiert sondern einfach übergeben. D.h. keine neue Instanz! Allerdings war es eine Lokale Variable!

[Robert_G]

Zitat:

Zitat von Speedmaster

Hmm, verstehe deine Antwort nicht ganz, gibst du mir nun Recht oder nicht?

Da gab es doch nix als richtig oder falsch zu bezeichnen. ;)

Zitat:

Ich habe mit C# Programmiert, und ein Objekt als Parameter übergeben. Dieses wurde natürlich nicht kopiert sondern einfach übergeben. D.h. keine neue Instanz! Allerdings war es eine Lokale Variable!

Übergeben oder lokale variable, das ist hier die Frage.
Oder gar den parameter in die lokale Variable gepackt? Wäre aber alles uninteressant, denn lokale variablen haben keine Namen. ;)

Ist dir eigentlich klar, dass du für "!" genau einen Tastaturanschlag mehr brauchst als für "."? Nutze die Energie beim nächsten mal einfach, um nicht immer solche Schnipsel zu schreiben. ;)

[Insider2004]

Ich find das geil, das alle .net programme open source sind. Mit entsprechenden Programmen kann man sich den source .net code anzeigen lassen.

[Robert_G]

Zitat:

Zitat von Insider2004

Ich find das geil, das alle .net programme open source sind. Mit entsprechenden Programmen kann man sich den source .net code anzeigen lassen.

Ich finde das ja schön, dass du dich darüber freust., du hast nur anscheinend die Beiträge nicht gelesen. :lol:
Sorry, dich enttäuschen zu müssen.

[Insider2004]

@Robert

Bist Du sicher, dass die Obfuskatoren etwas bringen???
Nicht umsonst heisst es "Managed Code".

[Robert_G]

Sonst hätte ich es wohl nicht gesagt, sonst würden es nicht soviele benutzen und ...