Delphi XE Update1

[himitsu]

Hab auch noch ein D7 installiert und dennoch steht es nicht im Profil.
Dann gibt es auch noch die Möglichkeit XE auf Arbeit und privat was Anderes.
usw.

Aber bekanntlich wird ja eh Vieles erst mit dem nächten "Update" Namens XE2 (oder wie auch immer) gefixt.

[Assarbad]

Zitat von himitsu:

Hab auch noch ein D7 installiert und dennoch steht es nicht im Profil.

War auch nur scherzhaft gemeint.

[Bummi]

Doch, aber wir setzen in der Firma noch überwiegend D2010 ein...

[Bernhard Geyer]

Zitat von Insider2004:

Für Plugin-Schreiber dürfte es jetzt schwer werden.

Für Plugin-Schreiber die nur die API verwenden wird sich nix ändern. Nur wenn über das Plugin versucht wird den Delphi-Code zu ändern wirds problematisch.

Aber Andreas kann ja sein Plugin soweit optimieren das der Crack-Check gepatcht wird

Ich könnte mir vorstellen das die FlexLM-Integration hier den Schutz bereitstellt. Evtl. wurde dieser aktualisiert.

[Assarbad]

Zitat von Bernhard Geyer:

Aber Andreas kann ja sein Plugin soweit optimieren das der Crack-Check gepatcht wird

Womit er mit dem angepaßten UrhG in Dtl in Konflikt geraten dürfte. Was dann wiederum Emba die Möglichkeit gibt rechtlich gegen ihn vorzugehen.

Ich weiß, daß ich maximal über TOR eine freie Emailadresse registrieren und über diese einen kostenlosen Webspace laufenlassen würde oder ggf. über diese Emailadresse bei SF.net ein Projekt machen würde (was Emba aber auch nicht recht sein dürfte) ... als Autor würde ich mich sicher nicht zu erkennen geben, wie es bspw. der Autor von "Delphi Distiller" gemacht hat.

[jbg]

Zitat von Insider2004:

Für Plugin-Schreiber dürfte es jetzt schwer werden. Wahrscheinlich wird über den geladenen Code eine Summe gebildet und wenn dann Andreas was im Memory patcht schlägt die Crack-Kontrolle zu.

Mein IDE Fix Pack funktioniert noch einwandfrei. Nur DDevExtensions hooked eine oder mehrere IDE Funktionen, die seit Update 1 nun geschützt sind. Leider muss ich mich aber in die IDE hooken, da die Open Tools API bei weitem zu schwach ist. Man muss sich nur mal anschauen, was man bei der Entwicklung von Plugins für Visual Studio also so machen kann. Und die Schnittstelle ist auch noch gut beschreiben. Nicht so wie bei der Open Tools API, bei der man Trial&Error spielen darf und hoffen muss dass das dann auch noch in der nächsten IDE Version so funktioniert, wie es das gerade tut.

Zitat:

Aber Andreas kann ja sein Plugin soweit optimieren das der Crack-Check gepatcht wird

Warum sollte ich. Da schreibe ich lieber eine eigene performante und thread-fähige IDE, bei der Komponenten nicht mehr das gesamte Programm zum Absturz bringen und unterschiedliche Compiler+FormDesigner-Version genutzt werden können. Ich habe mir da schon seit ein paar Monaten Gedanken darüber gemacht. Leider lässt sich das nicht mit meiner Freizeit vereinen.

[Assarbad]

Zitat von jbg:

Warum sollte ich. Da schreibe ich lieber eine eigene performante und thread-fähige IDE, bei der Komponenten nicht mehr das gesamte Programm zum Absturz bringen und unterschiedliche Compiler+FormDesigner-Version genutzt werden können. Ich habe mir da schon seit ein paar Monaten Gedanken darüber gemacht.

... das das das ist Häresie!!!

[TRomano]

Das wäre genau die richtige Reaktion von Andreas und Emba wäre dann mehr oder weniger "nur" noch der Compiler- und VCL-Bauer. Da könnten die sich auf Kern-Themen konzentrieren und müssten nicht ihre Ressourcen verschwenden. Bekommen wir vielleicht dadurch schneller einen gut funktionierenden 64Bit-Compiler ? Also, Andreas mache Dich schnell an die Umsetzung deiner Pläne ...

[Assarbad]

Zitat von TRomano:

Das wäre genau die richtige Reaktion von Andreas und Emba wäre dann mehr oder weniger "nur" noch der Compiler- und VCL-Bauer.

Dann müßte sich das im Preis aber auch niederschlagen

... denn vermutlich würde Andreas Geld sehen wollen für eine gute IDE.

[mleyen]

Steht eigentlich fest, das Emba noch ein Update rausbringen muss?

Ich weiß zwar nicht wie tief sich DDev da einhookt/patcht, aber ich würde da auch erstmal warten.