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 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.

Chris