DCU in neue Delphi-Version einbinden

[TomyN]

Im Prinzip habt ihr ja alle recht. Nun ist es aber so, dass es sich hier um den Zugriff auf einen Lizenzdongle handelt, und da bin ich eigentlich ganz froh, dass nicht alles offen liegt.
Bisher hat der Hersteller auch immer die entsprechende DCU bereit gestellt, ab und zu hat es halt etwas gedauert.
Gibt es eigentlich einen technischen Grund für diese enge Versionsbindung und die fehlende Aufwärtskompatibilität der DCUs? Marketingtechnisch ist es doch eher ein Grund gegen ein kostenpflichtiges Update.
Das mit der magischen Nummer hab ich schon probiert, da meckert Delphi dann, dass die DCU fehlerhaft sei. Ich vermute eine interne(?) Checksumme die ich auch ändern müsste, dazu finde ich aber nix im Netz.
Es geht aktuell nur um den Versionssprung von 10.3.2 auf 10.4.2.
I tried the magic number (4th byte) but in this case the compiler will report 'faulty DCU'.

[himitsu]

Zitat:

Sicherheit durch Verstecken

Nein, das ist nicht sicherer. (Denkt auch grad wer an die Vollbitverschlüsselung?)
Drum ist nahezu alles "Sichere" auch OpenSource, damit jeder die Sicherheit prüfen kann.

DCU und BPL sind nunmal nur für je eine Delphi-Version.

10.3 zu 10.4 verhält sich wie XE zu XE2, bzw. wie D6 zu D7.

In eine DLL gepackt wäre es quasi unabhängig, so lange man nichts delphi-typisches übergibt. (z.B. Delphi-Strings oder Objekte)
Oder in eine andere EXE und via IPC.

Man muß es ja nicht gleich übertreiben.
https://www.delphipraxis.net/213691-...-methoden.html
https://www.delphipraxis.net/213732-...n-gesucht.html
-> https://www.delphipraxis.net/213736-...-fuer-neu.html

https://www.delphipraxis.net/214881-...nis-frage.html
https://www.delphipraxis.net/213949-...elphi-6-a.html

[Uwe Raabe]

Zitat von himitsu:

In eine DLL gepackt wäre es quasi unabhängig

Eine DLL hat aber auch den Nachteil, dass sie relativ leicht ersetzt und der Schutz damit umgangen werden kann.

Ich verwende bei einem Programm seit ca. 25 Jahren (damals mit Delphi 5, jetzt Delphi 12) auch einen Lizenzdongle. Allerdings liegt dafür der benötigte Zugriffscode zum Dongle-Treiber als OBJ-Datei vor, die ich problemlos in die EXE linken kann. Die Delphi-Unit dazu habe ich selbst geschrieben, da mir die mitgelieferte Version irgendwie etwas lieblos zusammengestrickt erschien. Aber ich gestehe dem Hersteller zu, dass er ja sowas auch für zig andere Sprachen liefern muss.

Zwischenzeitlich hatte ich mal versucht, das auf eine simple, personalisierte Lizenznummer umzustellen, die hardwareunabhängig lief. Leider wurde das sehr schnell und übermäßig missbraucht. Man glaubt gar nicht, wie dreist manche Leute sind und mit so einer offensichtlich fremden Lizenz bei mir anrufen und Support erwarten.

[himitsu]

Zitat von Uwe Raabe:

Eine DLL hat aber auch den Nachteil, dass sie relativ leicht ersetzt und der Schutz damit umgangen werden kann.

Verschlüsselte Kommunikation,
oder z.B. die DLL signieren und die Signatur dann auch ordentlich prüfen.

[TomyN]

Zitat von Uwe Raabe:

Zitat von himitsu:

In eine DLL gepackt wäre es quasi unabhängig

Eine DLL hat aber auch den Nachteil, dass sie relativ leicht ersetzt und der Schutz damit umgangen werden kann.

Ich verwende bei einem Programm seit ca. 25 Jahren (damals mit Delphi 5, jetzt Delphi 12) auch einen Lizenzdongle. Allerdings liegt dafür der benötigte Zugriffscode zum Dongle-Treiber als OBJ-Datei vor, die ich problemlos in die EXE linken kann. Die Delphi-Unit dazu habe ich selbst geschrieben, da mir die mitgelieferte Version irgendwie etwas lieblos zusammengestrickt erschien. Aber ich gestehe dem Hersteller zu, dass er ja sowas auch für zig andere Sprachen liefern muss.

Ja, das musste ich auch erleben, bin aber aktuell immer noch bei beiden Lizenzmodellen (gerade weil die Software weltweit im Einsatz ist). Es ist nicht zufällig der Felsenschlüssel den Du verwendest? Ich hab ne ganze Menge Dateien hier, mal sehen was ich basteln kann.
Und eine verschlüsselte Kommunikation mit einer DLL, die das nicht unterstützt????

[Uwe Raabe]

Zitat von TomyN:

Es ist nicht zufällig der Felsenschlüssel den Du verwendest?

Da ich mit der Bezeichnung nichts anfangen kann, gehe ich mal davon aus, dass es nicht der gleiche ist.

[himitsu]

dafür müsste man aber auch in den Compilern ständig alte Dinge mitschleppen, wenn man sowas implementieren wöllte.

[TomyN]

Man müsste das nicht unbedingt im Compiler mitschleppen, eine einfache Konvertierung würde völlig reichen. Und es muss auch nicht von Delphi5 auf 12.2 sein, aber dass eine DCU aus 10.3 in 10.4 nicht mehr funktioniert finde ich schon, sagen wir mal 'Schwach'.

[Bernhard Geyer]

Zitat von TomyN:

Gibt es eigentlich einen technischen Grund für diese enge Versionsbindung und die fehlende Aufwärtskompatibilität der DCUs?

Eine Fomat ohne Versionsabhängigkeiten zum Compiler sind entweder weniger Flexibel oder die Runtime dafür ist komplexer zu definieren und zu Entwickeln.
Für Delphi haben die Entwickler das damals evtl. in Betracht gezogen und dann verworfen.

[TomyN]

Zitat von Bernhard Geyer:

Zitat von TomyN:

Gibt es eigentlich einen technischen Grund für diese enge Versionsbindung und die fehlende Aufwärtskompatibilität der DCUs?

Eine Fomat ohne Versionsabhängigkeiten zum Compiler sind entweder weniger Flexibel oder die Runtime dafür ist komplexer zu definieren und zu Entwickeln.
Für Delphi haben die Entwickler das damals evtl. in Betracht gezogen und dann verworfen.

Hmm, also ich weiss ja nicht genau, was in so einer DCU drin ist. Entweder bereits kompilierter Code + Infos über die Schnittstellen. Da sehe ich keinen Aufwand in einer neuen Version, evtl. würde im aktuellen Compiler vielleicht etwas effektiver übersetzten, aber man könnte den Code weiter einbinden.
Oder es ist eine Metasprache, dann wäre es doch auch kein Problem, den alten Interpreter (oder Meta zu ASM Compiler) über ein if dcu version = xx einzubinden. Oder man convertiert das ganze halt schnell in das neue Format. Man müsste nur wollen, will man aber nicht bei E. man will ja auch keine Bugs zum 'nulltarif' beheben.