Umstieg auf Delphi 2005

[mquadrat]

Die Frage ist doch erstmal, ob du nur von D7 auf D2005 als Umgebung umsteigen willst (also weiterhin Win32 Delphi programmiertst) oder ob du auch die "Sprache" wechseln willst und statt Win32 .NET programmieren willst.

Im ersten Fall ändert sich für dich nicht viel bis gar nichts, außer dass die IDE sehr viel komfortabler ist. (Wobei ich persönlich unbedingt zu D2006 raten würde).

Im zweiten Fall ändern sich tatsächlich die Befehle. Zumindest, wenn du direkt die Klassen des .NET Framework verwenden willst. Alternativ kannst du auch die Bibliotheken von Borland einbinden und schon sind IntToStr usw. wieder da. IMHO macht es aber keinen Sinn die Borland-Wrapper zu benutzen. Man sollte lieber gleich direkt auf dem .NET Framework arbeiten. Wobei sich dann naturlich die Frage stellt, ob man nicht lieber gleich zu C# wechselt.

Zum Thema .NET 1.1 vs. 2.0. Natürlich ist 2.0 besser und für den Entwickler komfortabler, aber auch mit .NET 1.1 kann man vernünftig und mit allen Features programmieren.

Win32 Delphi wird noch eine lange Zeit am Leben bleiben, wobei man allerdings sagen muss, dass bei manchen Dingen nachgelegt werden sollte / muss um gegen .NET zu bestehen. (z.B. die Datenbindung)

Zum Thema Source-Code auslesen: Man kann ein .NET Programm durch einen Obfuscator laufen lassen. Der fügt haufenweise sinnlosen miserabel bis gar nicht zu lesenden Code ein um so die Dekompilierung "aufwendiger" zu machen. Logischerweise geht das etwas auf Kosten der Geschwindigkeit.


@Khabarakh

Neue Algorithmen wird sicher keiner von uns erfinden. Aber schützenswert ist im Prinzip alles, was kommerziell entwickelt wird. Wenn man mehrere 100.000 EUR für die Entwicklung investiert hat, möchte man nicht, dass jemand das in fünf Minuten dekompiliert

[markusj]

Kleine Frage: Was habt ihr mit StrToInt und umgekehrt?
In meinem Delphi 2k5 sind die alle weiterhin in der SysUtils enthalten.
Ansonsten, ich finde, dass man mit der homogenen Oberfläche (wenn sie gerade mal nicht vor Fehlermeldungen überläuft) eigentlich ganz gut und inuitiv Arbeiten kann, wenn man ne Ahnung von dem hat, was man machen will.

mfG

Markus

[Alexander]

Zitat von mquadrat:

Zum Thema Source-Code auslesen: Man kann ein .NET Programm durch einen Obfuscator laufen lassen. Der fügt haufenweise sinnlosen miserabel bis gar nicht zu lesenden Code ein um so die Dekompilierung "aufwendiger" zu machen. Logischerweise geht das etwas auf Kosten der Geschwindigkeit.

Ich denke die Geschwindigkeitseinbußen kann man verkraften. Nur bringt diese "Verschlüsselung" nicht wirklich etwas. Das ist das Problem.

Zitat von markusj:

Kleine Frage: Was habt ihr mit StrToInt und umgekehrt?
In meinem Delphi 2k5 sind die alle weiterhin in der SysUtils enthalten.
Ansonsten, ich finde, dass man mit der homogenen Oberfläche (wenn sie gerade mal nicht vor Fehlermeldungen überläuft) eigentlich ganz gut und inuitiv Arbeiten kann, wenn man ne Ahnung von dem hat, was man machen will.

Unter .NET kann man die natürlich auch einbinden, aber dann ist die EXE gleich wesentlich größer. Und warum sollte man das dann nicht gleich so machen, wie es .NET will?
Unter Win32 bleibt natürlich alles so wie gehabt.

[Khabarakh]

Zitat von mquadrat:

@Khabarakh

Neue Algorithmen wird sicher keiner von uns erfinden. Aber schützenswert ist im Prinzip alles, was kommerziell entwickelt wird. Wenn man mehrere 100.000 EUR für die Entwicklung investiert hat, möchte man nicht, dass jemand das in fünf Minuten dekompiliert

Aber es bleibt doch die Frage, ob es ihm überhaupt etwas nützt. Es wäre nicht unwahrscheinlich, dass man zum Abschreiben und Umändern am Ende doppelt so lange wie der "ehrliche" Entwickler braucht .

http://yoda.arachsys.com/csharp/obfuscation.html

Many developers have been shocked by how easy it is to decompile their code, and fear that it means they no longer have any way of protecting their intellectual property. In practice, I don't believe the problem is nearly as big as it's claimed to be. Firstly, intellectual property is almost always within the design of a system, not in the individual bits of implementation. If you design a world-beating application, chances are that the reason it's world-beating will be obvious to anyone who uses it anyway. Only a very few areas in computing are really all about which algorithms are used, and how they're implemented - areas such as sound and video compression.

Have you ever tried to read a large amount of code without any documentation, comments or meaningful local variable names? In my experience, it can be hard enough to understand code when you do have design documents and comments, let alone without it. Now, let's make it even harder...

[stoxx]

Zitat:

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

bitte les Dir den Artikel von mquadrat nochmal durch, mir scheint es, als hättest Du das ganze Konzept von Delphi2005 oder Delphi2006 noch nicht verstanden. Delphi2005 hat, wenn man so will, nur nebenbei was mit .NET zu tun
Unter Delphi2005-Win32 (wie Delphi7) ist alles genauso wie vorher.
Und die Quelltexte sind auch die gleichen wie bei D7.

[gfjs]

@ Markus

Klar sind in Deiner SysUtils IntToSrr und Konsorten noch drin. Delphi 2005 gibt Dir ja die Möglichkeit, weiterhin WIN32-Anwendungen zu programmieren und dafür verwendest Du wie bisher die VCL: Wenn Du aber .NET-Anwendungen programmieren willst, dann gibts IntToStr nicht mehr. Dafür haben (fast) alle Objekte die .ToString-Methode.

Gruß Jürgen

[stoxx]

Zitat:

Win32 Delphi wird noch eine lange Zeit am Leben bleiben, wobei man allerdings sagen muss, dass bei manchen Dingen nachgelegt werden sollte / muss um gegen .NET zu bestehen. (z.B. die Datenbindung)

glaubst Du daran ? oder ist das schon konkret in Planung ?

[sir-archimedes]

Wenn ich mich nicht ganz irre, wird Delphi Win32 gar nicht mehr weiterentwickelt. <= Und genau da habe ich mich wohl doch geirrt. Es war nur mein Eindruck...

Ich würde auch keine neuen Projekte mehr darauf aufbauen. Windows Vista hat das .NET-Framework bereits fest verankert und in Zukunft sollte man meines Erachtens auf .NET setzen - es sei denn man kann viel alten Delphi Code übernehmen. Dann würde ich evtl. auch bei Delphi Win32 bleiben.

Ob Delphi die richtige IDE für .NET ist, ist auch die Frage. Schließlich kann Delphi noch kein .NET 2 und wird immer etwas hinterherhinken. Daher würde ich, eher auf VS mit C# umsteigen, als unter Delphi 2005/2006 mit .NET herumzuhantieren.

[mkinzler]

Zitat:

Wenn ich mich nicht ganz irre, wird Delphi Win32 gar nicht mehr weiterentwickelt.

Wie kommst du darauf? also in der Roadmap hat DevCO(DTG) diese für die nächste beiden Delphi-Versionen nicht abgekündigt, im Gegenteil es sollen sogar features von .Net 2.0 in den Win32-Compiler übernommen werden.

[sir-archimedes]

Ich hatte den Eindruck, dass sich an der Win32 Plattform nicht mehr groß was ändert und stattdessen auf den .NET-Zug aufgesprungen wird und Win32 daher nicht mehr weiterentwickelt wird. Ich bin da aber anscheinend nicht gut informiert. Habe auch meinen Beitrag oben dementsprechend geändert.