DCU in neue Delphi-Version einbinden

[TomyN]

Hallo,

Ich habe folgendes Problem: Ich habe eine DCU Datei, die ich in ein Projekt einbinde. Nun habe ich meine Delphiversion aktualisiert und kann nun die DCU nicht mehr einbinden.
Gibt es da einen Trick?

Tomy

[himitsu]

NEIN.

DCUs sind IMMER nur für für den jeweiligen Compiler gültig.
Abgesehn, davon, dass Abhängigkeiten (Units im USES dieser Unit) sich auch noch über die Versionen ändern können.

Delphi 2006 und 2007 hatte mal den "selben" Compiler, aber das war's dann auch schon.



Das ist auch der Grund, warum es immer besser ist, wenn man von Fremdkomponenten den Quellcode bekommt, anstatt nur DCUs.

[Kas Ob.]

Hi,

I have few minutes again before the blackout, and want to point a way that might work.

You need to fix the compiler magic number in the DCU, this might works, but no guarantee.
It did work with different steps from the ones i am listing below, between different versions, like it did work for Delphi2010 and 2009, and between XE8 and Seattle, but not between 2010 and XE8.

so here the steps:
1) build a small or empty project with one added unit lets call it Test.pas, build the same project by your two IDEs.
2) use HEX editor to compare both the DCUs
3) if the difference 4 bytes then change the first one only, most likely and if you are lucky the 4th byte at index 3 is the magic number for the compiler and it will fool the newer version.

after checking the change that worked for Test.pas/Test.dcu apply the same for your own DCU, if you changed more than one byte then... well you know what to do and what to experiment there.

Good luck !

ps: as himitsu pointed if there is huge difference in RTL/VCL dependency between the IDE versions then the steps above will not work, and to make it work there is many other steps of hacking the DCU structure and renaming, will be huge process that will not worth wasting time.

[jaenicke]

Zitat:

Zitat von TomyN (Beitrag 1538444)

Nun habe ich meine Delphiversion aktualisiert und kann nun die DCU nicht mehr einbinden.
Gibt es da einen Trick?

Wenn es nicht um eine visuelle Komponente geht, kannst du den Quelltext in einer Klasse kapseln, per Interface exponieren und dieses Interface in einer DLL bereitstellen. Das machhst du dann in der Delphiversion, für die du die DCU hast.

Eine Unit, von der ich nur die kompilierte Version habe, würde ich nur im absoluten Notfall 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. :stupid:

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

Zitat von himitsu (Beitrag 1538452)

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.

[Bernhard Geyer]

Zitat:

Zitat von TomyN (Beitrag 1538450)

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.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1538456)

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:

Zitat von Bernhard Geyer (Beitrag 1538464)

Zitat:

Zitat von TomyN (Beitrag 1538450)

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.