Umstieg auf Delphi 2005

[ferby]

Hallo,

ich arbeite jetzt schon ca. 3 Jahren mit Delphi 7 und habe mir vor kurzen Delphi 2005 besorgt.
Es ha sich da einiges geändert.

Einige unklarheitten habe ich noch:
1) Ich habe gelesen das Befehle wie IntToStr nicht mehr existieren und die jetzt anders heißen,
gibt es irgendwo eine Liste von Befehlen die sich geändert haben?

2) Wo ist der Unterschied zwischen einen D7-Programm und einen .Net Programm?

3) Was passiert wenn man ein .Net Programm öffnet und der Benutzer hat das Net Framework (oder wie das heißt) nicht installiert?

4) Was für Vorteile hat D 2005 gegenüber D7?

5) Irgendetwas anderes was ich wissen sollte wenn ich auf D 2005 umsteige?

[himitsu]

1)
Variable.asString, oder so ... mach einfach mal 'nem Punkt dahinter und schau was dir Delphi anbietet ._.

2)
das .Net-Framework gibt es nicht nur für Windows, deine Programme laufen also auch auf anderen Systemen, ohne das es neu/anders kompiliert/geschrieben werden muß (also sowas wie Kylix für Delphi ist nicht nötig)

3)
Es kommt 'ne Fehlermeldung und dein Programm startet nicht.

4)
siehe 2)

5)
es gibt massig Fehler in D2005 (drum hab ich mein 2005 wieder weggeräumt und bin immernoch bei D4/D7 ... OK, manchma och bei D2006, aber eigentlich warte ich noch auf Delphi2008/BDS2008)

Ach ja, es fehlen auch noch andere Dinge, oder heißen anders, oder werden anders aufgerufen ... nicht nur IntToStr.
(in einer .Net-Anwendung ... in einer Win32-Anwendung ist eigentlich alles noch fast gleich)

[ferby]

Hallo,

das klingt aber nicht so gut.....
wenn das wirklich so ist, muss ich mir den umstieg noch überlegen,

gibt es von andren noch irgendwelche KOmmentare, pros und kons von Delphi 2005?

[Alexander]

Du solltest unbedingt die Service-Packs von Borland installieren. Danach geht es eigentlich einiger Maßen. Ich arbeite damit zumindest momentan. Allerdings ist es von der Performance und den Fehler kein Vergleich zu D7 oder früher. Die Fehler scheinen aber hauptsächlich bei der Programmierung mit .NET zu liegen. Was mich aber besonders stört, ist dass D2005 und D2006 nicht .NET 2.0 unterstützt. Man ist da schon ziemlich eingeschränkt. Sprich riesige Programme kann man da nicht mit basteln.
Was aber IMHO noch sehr wichtig ist. .NET Code Executables kann man mehr oder weniger problemlos dekompilieren. Am besten schaust du dir das mal an.

Die Funktion StrToint ist durch "int.toString" ersetzt (das toString Property toString gibt es bei allen Objecten). Und umgekehrt: System.int32.parse(string);

Vieles bei .NET scheint mir auch von JAVA abgekupfert zu sein, was nicht heißen soll, dass es schlecht ist :thuimb:.

[ferby]

Heißt das,
das jemand aus meinen fertigen Programm, sprich die exe Datei, den Quellcode herausbekommen kann,
den ich selbst in Delphi geschrieben habe?

[himitsu]

Im Grunde ja (bei 'ner .Net-Anwendung),
den dieses ist ja sowas wie 'ne Interpretersprache.
Also alle Befehle liegen so ähnlich, wie es z.B. in Basic und JavaScript der Fall ist, noch fast genauso vor, wie du sie geschrieben hast ... halt nur nicht als Worte, sondern als Bytes ... diese Befehle werden dann er bei der Ausführung vom .Net-Framework in für den Computer verständliche Befehle umgewandelt.

Es ist also "leicht" möglich diese Befehle wider zurück in einen Quelltext umzuwandeln.


Das ist ja auch der Grund, warum soein Programm ohne .Net-Framework nicht läuft (irgendwer muß dem PC ja sagen, was er zu machen hat) und auch warum es auf anderen System läuft (man kann die Befehle ja nicht nur Windows verständlich machen, sondern auch Linux und wer weiß wem sonst noch)

[ferby]

Hallo,

dann finde ich jetzt schon .Net ein Schwachsinn!
Ich möchte nicht das jemand meinen Quellcode so einfach heruas bekommt,
hab ja ich programmiert und nicht wer anderer,
und wenn wer wirklich einen Quellcode haben will kann er mich ja fragen.....

....da bleib ich lieber bei D7.....

[himitsu]

Na ja, mit "normalen" Delphi (also auch D7) ist es im Grunde auch möglich sich den QuellCode zu besorgen ... nur halt ein klein bissl schwerer :zwinker:

siehe http://www.delphipraxis.net/internal...ct.php?t=85979

[Khabarakh]

Zitat:

Zitat von ferby

dann finde ich jetzt schon .Net ein Schwachsinn!

Da muss ich dich einfach mal frank und frei fragen: Hast du denn deiner Meinung nach schon einmal überhaupt etwas Schützenswertes programmiert?
Nehmen wir zum Bleistift eine normale Datenbankanwendung: Was zum Teufel sollte man da klauen? Wie man eine Datenbank entwirft, auf sie zugreift, dem User die Daten zeigt, ... das alles lese ich doch in Büchern, auf Webseiten oder dem SDK nach, aber doch sicher nicht in einem undokumentierten Quellcode, für den ich erst einmal 7 Tage brauche, um ohne Dokumentation überhaupt die Grundstruktur zu verstehen!
Und selbst wenn du irgendwann einen tollen Algorithmus entwickelst, kannst du ihn immer noch in eine unmanaged DLL stecken. Aber auch dort wird er wohl nur kurze Zeit sicher sein...

PS: Alexanders Artikel bitte ganz durchlesen ;)

[Alexander]

Aus einer Win32-Exe kann man aber AFAIK nur Assembler-Code bekommen, aus einer .NET Exe dagegen den richtigen Source-Code. Nur die Kommentare und die ursprüngliche Benennung der Variablen. Außerdem ist noch die Reihenfolge der Methoden ggf. eine andere.
Es gibt es bei .NET aber noch die Möglichkeit die exe zu obfuskatieren (gibt es das Verb?). Dann ist die Datei verschlüsselt und der potentielle Angreifer hat es wesentlich schwerer, da er die Namen der Methoden nur verschlüsselt sieht. Aber ein richtiger Scbutz ist natürlich auch das nicht. Da haben IMHO Win32 Anwendungen schon Vorteile...