Neue IDE, alter Quellcode, Access Violation

[beginnerXE1]

Hallo liebe Delphi-Praktiker,

ich bin ein kompletter Neuling im Bereich Delphi, aber das wird sicher gleich ersichtlich.
Mir liegt ein eingestaubtes Quellcode-Projekt von ca. 2010 vor, was der Entwickler wohl bis 2016 weiterentwickelt hat. Die Software ist für mich als Beginner äußerst komplex und bietet die Möglichkeit zu Erweiterung mit Plugins. Jedes Plugin ist als eigenes Projekt dproj, womit eine .dll erzeugt wird und die Software lädt sie automatisch. In seiner Anleitung hat er sich auf Delphi 2010 bezogen, aber die existiert auch nur für die Plugin-Entwicklung.

Nun wollte ich mit solch einem kleinen Plugin anfangen. Die vorhandene dproj laden und im Original kompilieren. Laut Anleitung soll ich nur den Haken bei "Mit Laufzeit kompilieren" entfernen und fertig. Soweit so gut, das funktioniert.

Wenn ich die ursprüngliche .dll nun durch die neue .dll austausche, werden beim Programmschritt, dass das Plugin verwendet, einige Access Violation Fehler ausgegeben.

Im Unterschied zu ihm nutze ich natürlich mittlerweile Windows 10 x64 (statt Windows 7) und RAD Studio 10.3 Delphi Community Edition (statt Delphi 2010). Laut RAD Studio wird dcc32 für Windows x32 verwendet, da die Software ursprünglich dafür ausgelegt wurde.


Meine Ideen jetzt: die Delphi Version ist zu neu oder beim Kompilieren ist ein Haken gesetzt, den es früher so nicht gab. Mit dem neueren .NET-Framework dürfte es ja nichts zu tun haben, oder doch?

Hat jemand eine Idee, wie ich vorgehen kann?
Das Projekt komplett in die IDE zu laden ist mir leider nicht gelungen, da die Software aus 3 .groupproj Komponenten besteht, core, view und sdk und ich da ehrlich gesagt noch keinen Durchblick habe.

Vielen Dank bereits im Voraus.

[stahli]

Erst mal herzlich willkommen und Respekt, dass Du Dich da ran traust...

Bist Du außerhalb von Delphi ein erfahrener Programmierer?
Hast Du Delphi 2010 noch irgendwie verfügbar?

Sicherlich wäre es erst mal am einfachsten, das wieder mit D2010 zu aktivieren und alle Projekte fehlerfrei kompilieren zu können.

Wenn das nicht möglich ist, solltest Du Dir m.E. einen Delphi-Entwickler mit ins Boot nehmen, um das erst mal wieder in Gang zu kriegen.
Dabei kannst Du ja auch schon mal etwas Erfahrung sammeln, was dann auch die spätere Weiterentwicklung vereinfacht...

[Der schöne Günther]

Hallo und Herzlich Willkommen in den Heiligen Hallen des Wissens und des Wahnsinns

Das ist wirklich der erste Punkt: Sicherstellen dass Quellcode der dir vorliegt auch wirklich mit den fertig kompilierten .exe/.dlls übereinstimmt. Sonst vermutet man nur Fehler wo keine sind. Ohne passende Lizenz für ein altes Delphi 2010 ist das sicher auch möglich irgendwie ans Ziel zu kommen, aber man macht es sich auch unnötig schwer.

Auch: Ich gehe davon aus du nimmst die original dir vorliegenden Dateien und willst deine neue .dll jetzt als neues Plug-In mitbenutzen? Hier ist genau die Option "Mit Laufzeit-Packages kompilieren" was für die Inkompatiblität sorgt: Grundliegende Laufzeitbibliotheken liegen in der 2010er Version in irgendwelchen .bpl-Dateien (meine ich) vor. Wenn deine 10.3er-DLL nun diese verwenden soll fällt sie natürlich auf die Nase, denn sie erwartet Dinge in der Laufzeitbibliothek die vor über zehn Jahren noch nicht erfunden waren. Ich kenne mich damit ehrlich gesagt nicht aus, ich glaube der einzige Grund diese Option zu verwenden wäre höchstens wenn man Speicherplatz in den Binaries sparen will.

Daher die ganz dumme Idee:
1. Was ist wenn du ALLE Bestandteile mit 10.3 kompilierst (falls das geht)
2. Was ist wenn du den Haken "Mit Runtime-Packages kompilieren" doch setzt?

[beginnerXE1]

Vielen Dank!

Ich bin Programmierer, daran sollte es zumindest nicht scheitern, zumal mein Änderungswunsch minimal ist (siehe unten).
Ich werde mich mal auf die Suche begeben, um es mit Delphi 2010 noch mal zu probieren.

Alle Komponenten neu zu kompilieren ist aktuell nicht möglich. Einige Plugins haben laut Kompiler tatsächlich "Errors" im Code, wo Typen inkompatibel sind. Die Gründe verstehe ich zugegeben noch nicht ganz, aber das Plugin habe ich auch nie verwendet. Es kann also auch sein, dass das sowieso nicht funktioniert. Andere Komponenten bekomme ich aktuell nicht in RAD Studios "importiert", weil nur die Plugins mit eigenen Projekten aufgebaut sind.

Wenn ich den Haken doch setze, kommt es zu einem Fehler, dass "framework" nicht vorhanden ist. Der Fehler wird in der Anleitung aber auch tatsächlich so beschrieben und vorhergesagt. Fun fact: 2-3 Access Violations treten laut Fehlermeldung auch in der framework.bpl auf, wenn ich mich richtig erinnere, aber insgesamt sind rund 10 Fenster aufgegangen.

Meine Änderung an dem Plugin ist aber auch nur eine Kleinigkeit: das Plugin gibt nur den Wert einer Berechnung plain zurück und ich würde gern einen JSON-Format außenrum packen. Also eigentlich nur den vorhandenen String um ein paar Buchstaben und zwei geschweifte Klammern erweitern. Der Workaround ist aktuell ein 2. Programm, was das Ergebnis in ein JSON-Format packt, sodass es weiterverarbeitet werden kann. Ich hatte nur gehofft, dieses 3-Zeilen-Programm in der Mitte mit einer einfachen Änderung abschaffen zu können. Und mich jetzt ein wenig darin verbissern, dass das doch schaffbar sein sollte...

Aber ich lese zumindest mal aus euren Antworten raus, dass es im RAD Studio keine einfache Option gibt, wo ich nur einen Haken setzen muss. Wäre auch zu schön gewesen...

[himitsu]

Zitat:

Laut Anleitung soll ich nur den Haken bei "Mit Laufzeit kompilieren" entfernen und fertig.

Das kommt drauf an, wie die Verwaltung von Speicher und Typen gehandhabt wird.

• DLL/EXE mit Laufzeitpackage teilen sich den "selben" Kern
  Also Speichermanager und Typen sind die "selben" aus den gleichen System-Units.
  z.B. die Variable FormatSettings aus der SysUtils, da greifen EXE und DLL auf die "gleiche" Variable zu
• DLL mit ShareMem haben jeder seine eigenen Typen und globalen Variablen, aber den gleichen Speichermanager.
  Hier können Strings (AnsiString und UnicodeString) und sowas wie GetMem übergeben und auf der anderen Seite erstellt/geändert/freigegeben werden.
  z.B. haben EXE und DLL hier jeder ihre eigene Variable FormatSettings (sie ist also doppelt/mehrfach vorhanden)
• DLL ohne ShareMem hat jeder seine eigene "Delphi"-Umgebung und die andere Seite kann auch in einer anderen DelphiVersion und sogar anderen Sprache ala C++ geschrieben sein.
  Hier kann man also nur WideString, Interfaces oder andere Typen/Funktionen verwenden, welche nicht delphi-spezifisch sind und die somit von Windows behandelt werden.

Einfach so an-/abschalten der Laufzeitpackages ist sogesehn eigentlich garnicht immer möglich.

Mit Laufzeitpackage muß alles mit Der selben Delphi-Verion geschrieben sein. (oft sogar die gleichen installierten Update/Patch/Hotfix)
> also bezüglich "Wenn ich die ursprüngliche .dll nun durch die neue .dll austausche, werden beim Programmschritt, dass das Plugin verwendet, einige Access Violation Fehler ausgegeben"


Zumindestens da ursprünglich nicht "Vor"-Delphi2009 verwendet wurde, sollte es hier wenigstens keine großen Unicode-Probleme geben.
Ich weiß aber grade nicht wann, also ob 2010 oder erst XE, da wurden die Strings nochmal etwas umgebaut.


Was die Windows-Versionen betrifft, da sollte es keine großen Probleme geben.
Da Delphi keine externen Bibliotheken, ala zusätzlicher "Installationen für .NET-Framework, Java-Runtime(JRE) und Dergleichen verwendet,
ist es in Win32 sehr weit kompatibel.
Abwärts gibt es aber Beschränkungen, was hier allerdings egal ist.
Also mit neuem Delphi kompiliert läuft nicht alles in "uralten" Windows-Versionen, da Delphi ab und an auch "neuere" WinAPIs benutzt, die es damals womöglich noch nicht gab.


.NET-Framework: Die kompilierten Programme für Win32 benutzen kein .NET, abgesehn in speziellen .NET-Delphis ala Delphi 8 oder Delphi Prism. (was tot ist)
Nur einige Teile der IDE benutzt/benutzte das .Net-Framwork (z.B. das Refactoring), aber für den Betrieb deiner eigenen Programme ist das egal.




Tja, wenn man Delphi gekauft hat, kann man sich gratis Delphi-Lizenzen für viele Vorgängerversionen besorgen (Delphi 7 und 2006 bis aktuell),
da hätte man jetzt ein Delphi 2010 mit dabei gehabt.



Da wir bis jetzt noch nicht wissen wie das mit den Plugins bei dir aubläuft und was wie gemacht wird, können wir auch nicht so einfach direkt sagen was nun richtig wäre.

Aber grundsätzlich: Du weißt wie man den Debugger benutzt? (um selbst zu versuchen rauszubekommen wo es hängt)

[beginnerXE1]

Danke auch für deine Antwort und den Überblick mit dem Net-Framework sowie der Speicherverwaltung. Damit habe ich in meinem Alltag sonst eher wenig zu tun.

> Mit Laufzeitpackage muß alles mit Der selben Delphi-Verion geschrieben sein. (oft sogar die gleichen installierten Update/Patch/Hotfix)

So ähnlich hat er das Entfernen des Hakens auch begründet, auch wenn nicht so ausführlich. Die Kommunikation mit den Plugins läuft hauptsächlich über Interfaces und WideString, wenn ich das richtig überblicke. Diese sind natürlich selbst definiert. Es gibt auch Wordbool, die zurückgegeben werden. Ein Parameter mit "string" hat mich stutzig gemacht, aber der wird über eine SysUtil-Funktion im Plugin erzeugt und verlässt das Plugin auch nicht.

> Da wir bis jetzt noch nicht wissen wie das mit den Plugins bei dir aubläuft und was wie gemacht wird, können wir auch nicht so einfach direkt sagen was nun richtig wäre.
Da fehlte mir das Wissen, was ich an Informationen bereitstellen muss / sollte. Aber für mich reichte erst einmal auch die Antwort, dass ich es am besten mit der 2010er noch einmal probieren sollte.

> Aber grundsätzlich: Du weißt wie man den Debugger benutzt? (um selbst zu versuchen rauszubekommen wo es hängt)
Den vom RAD Studio tatsächlich noch nicht, aber da werde ich noch mal nachlesen, ob ich auch nur die .dll debuggen kann, während der Rest der Software außerhalb gestartet wird, und wenn ja, wie. Ich hatte gehofft, dass die Version vielleicht über ein Häkchen einfach umstellbar ist und es dann auch so funktioniert. Häufig benötigen neue IDEs anfangs mehr Einarbeitungszeit als die Programmiersprache selbst. Den Code in dem Projekt habe ich großteils auch verstanden, ohne vieles explizit nachlesen zu müssen. Das sah beim RAD Studio gleich zu Beginn ganz anders aus.

Wenn ich eine ältere Version mit Lizenz gefunden habe, probiere ich es damit noch mal und gebe dann Rückmeldung.

[himitsu]

ShortString und die LongStrings (AnsiString, String/UnicodeString und AnsiString-Ableitungen ala UTF8String oder RawByteString) sind Delphi-Typen.
Auch wenn es da für C++, C# und andere Sprachen kompatible Implementierungen gibt, fehlt dennoch meistens noch der Zugriff auf den Speichmanager vom Delphi, in welchem die Delphi-Strings verwaltet werden.

WideString ist eine Kapelung der WinAPIs für den BSTR der OleAut32.dll (siehe SysAllocStringLen/SysReAllocStringLen/SysFreeString/SysStringLen), drum lässt der sich problemlos an Alles übergeben, was die Win32-API (32/64 Bit) unterstützt.

ShortString ist aber ein Record, und der lässt sich in anderen Sprachen auch nachbauen (ein LängenByte, gefolgt von bis zu 255 AnsiChar)
PS: Darum fangen im Delphi die Strings auch standardmäßig mit 1 an.

ByteBool, WordBool und LongBool sind auch Typen, welche z.B. ebenfalls C++ kennt (LongBool=BOOL).
https://docs.microsoft.com/en-us/win...ows-data-types

Ja, so lange man nur lesend auf einen String zugreift, wird im Speichermanager nichts geändert.
Speicher auf einer Seite erstellen und über eine Free-Prozedur auf der selben Seite wieder freigeben, ist kein Problem,
aber z.B. sich eine Kopie zu machen (in einer Variable speichern) und später nochmal drauf zuzugreifen, ergibt gern massig Probleme,
also sicherheitshalber "String" garnicht erst übergeben, damit das potentielle Risiko garnicht erst vorhanden ist.
(ohne Packages oder ShareMem sind es ja zwei Speichermanager und der Eine kann mit dem Speicher des Anderen nichts anfangen = Exception)

Zitat:

Aber für mich reichte erst einmal auch die Antwort, dass ich es am besten mit der 2010er noch einmal probieren sollte.

Ohne Packages und möglichst ohne Übergabe von Typen/Speicher in eine "abgetrennte" EXE/DLL sollte es mit einem neuen Delphi auch gehn.

Aber wenn es schon in D2010 Probleme gibt, dann weißt du zumindestens, dass es vorviegend andere Fehler sind (kaputter Code), die mit dem Delphi nichts zu tun haben.


Debuggen:

Im Menü "Start > Parameter" kannst zu deiner DLL die EXE angeben, welche für die Ausfühung benutzt werden soll.
Ebenso über das Menü "Start > Prozess laden".
Hier startet Delphi dann statt der DLL (was ja nicht geht) die EXE, hängt sich an den erstellten Prozess und in dessen Speicher wird dann deine DLL gedebuggt.

Oder über das Menü "Start > Mit Prozess verbinden", da kannst du die EXE vorher selbst starten und dich dann anschließend mit dem Debugger dranhängen.
Was hier nun gedebuggt wird, hängt von den einkompilierten oder danebengelegten Debuginfos ab (in EXE und DLL) und davon welche Quellcodes (Projekte/Units) in der IDE geladen sind.


Es gibt oftmals auch ältere Versionen zu kaufen. (eBay und so)
* Achtung, bei Upgrade-Lizenzen solltest du auch die vorhergehende Lizenz mit kaufen, denn das Upgrade ist ohne einen Vorgänger nicht gültig/legal.
* Und nach dem Kauf kommen nochmal paar Euro drauf, für das Überschreiben der Lizenz auf deinen EDN-Account (20-50€ ... weiß grad nicht wie teuer aktuell)
* Und da die gebrauchten Lizenzen oftmals nicht sehr viel billiger werden ... da kann man sich vermutlich auch direkt eine aktuelle Prof kaufen (ein/zwei Mal jedes Jahr gibt/gab es Sonderaktionen mit paar Prozent Rabatt, bis 30%)
https://www.embarcadero.com/de/produ...vious-versions

[Rolf Frei]

Hast du bisher nur das Plugin neu kompiliert oder auch das Hauptprogramm? Das wäre sonst mal das erste was du machen solltest, damit beide Version auf der gleichen Delphiversion basieren, solange nicht klar ist wie die Plugins mit dem Hauptprogamm interagieren. Auch stellt sich die Frage, was das für DLL's das sind. Also klassische DLl mit Exports oder Com-Klassen die im System registriert werden müssen?

[beginnerXE1]

Erneut vielen Dank für eure Antworten.

> Es gibt oftmals auch ältere Versionen zu kaufen. (eBay und so)
Also die Version neu im Shop ist für mich als Privatperson dann doch zu teuer, vor allem für meinen Anwendungszweck. Neben der kleinen JSON-String-Anpassung gäbe es zwar noch 1-2 Kleinigkeiten, aber den Preis rechtfertigt es für mich dann leider nicht. Dazu funktioniert die Lösung mit Zwischenschritt zu gut. Im Forum hatte ich schon nachgelesen, dass ältere Lizenzen nur geringfügig im Preis verlieren und in einer kurzen Suche bei ebay.de/com nichts direkt gefunden. Aber ich habe noch 1-2 Hoffnungen, die ich ansprechen kann. Ich möchte euch natürlich auch nicht zu viel Zeit kosten, nur weil die Software recht alt ist, ich kaum Ahnung von der Materie habe und für 2-3 Zeichen keine Unsummen ausgeben möchte.

> Hast du bisher nur das Plugin neu kompiliert oder auch das Hauptprogramm
Bisher nur das Plugin, das Hauptprogramm + IDE stellt mich noch vor andere Probleme und da man die Plugins theoretisch einfach austauschen kann, wollte ich damit anfangen.

>Also klassische DLl mit Exports oder Com-Klassen
Ich nehme mal an Exports:

Delphi-Quellcode:

function LoadPlugin(var plugin: interface): WordBool; safecall; export;
begin
  try
    plugin := TGoogleCh.Create;
    Result := True;
  except
    Result := False;
  end;
end;

exports LoadPlugin name 'LoadPlugIn';

Durch die Debug-Anleitung, danke himitsu, ist das Programm früher als ich dachte gecrashed. Habe es über Rad Studio gestartet und ein paar Projekteinstellungen angepasst, aber lief dann auch.

Delphi-Quellcode:

unit uGoogleCH;

interface

uses
  // Delphi
  Windows, SysUtils,
  // RegEx
  RegExpr,
  // HTTP + Plugin
  ....
type
  TGoogleCH = class(TSearchPlugin)
  protected { . }
  const
    SITE: string = 'http://google.ch';
    // ...
  public
    function GetName: WideString; override;

    { ...sinnvolle Funktionen, die ich zur Einfachheit ignoriere...; } override;
  end;
  
  function TGoogleCH.GetName: WideString;
  begin
    Result := 'Google.ch'; // Breakpoint, 3x Einzelschritt F7 ab hier und es crashed: access violation
  end;

Ich habe bei allen Funktionen einen Breakpoint in die erste Zeile gesetzt. Der erste Haltepunkt wurde bei GetName ausgelöst, was für mich sinnvoll erscheint. 3x F7 gedrückt, also drei Schritte weiter das Programm crashed. Leider habe ich ja bisher nur Plugins als Quellcode-Projekte laden können, sodass ich (noch) nicht exakt sagen kann, was der genaue Aufruf ist. Ich versuche mich noch ein bisschen daran, mehr Quellcode in das RAD Studio laden zu können, vielleicht komme ich dann schon weiter.

[himitsu]

Zitat:

Ich versuche mich noch ein bisschen daran, mehr Quellcode in das RAD Studio laden zu können, vielleicht komme ich dann schon weiter.

Da sich der Aufbau der DPROJ ab und an mal ändert und die MigrationsFunktion der IDE bissl grauenhaft arbetet.

Am Einfachsten erstmal alle DPROJ löschen,
dann die DPR in der IDE laden (Doppelklick/Drag&Drop im Explorer oder Öffnendialog im Delphi)

Allerings sind dann die Projektoptionen dann erstmal auf "Standard" (nur die USES/REQUIRED und wenige Optionen werden aus der DPR übernommen)
und sowas wie geänderte Optionen, Ausgabepfade, Suchepfade und Dergleichen müssen neu eingestellt werden.


Für den Quellcode und dessen Funktion isses egal, aber beim Buildprozess stimmen eventuell einige Dinge nicht mehr. (welche die Migration grob fahrlässig vergessen hat)

Und natürlich hast du bestimmt irgendein Versionsverwaltungssystem ala GIT/SVN/HG,
um Änderungen sehen und bei Problemen reverten zu können.