Neue IDE, alter Quellcode, Access Violation

[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.

[Rollo62]

Ich würde mich mal fragen wo die Hauptlogik liegt,
Es hört sich so an als wäre das ausschliesslich in den Plugins.

Deswegen, aber auch generell, würde ich versuchen Plugins einzeln lauffähig zu bekommen,
Und zwar mit einem neuen Test- oder Hauptprogramm.
Falls das Hauptprogramm nur eine Hülle für Plugins ist,
Dann macht es Sinn das komplett neu aufzubauen, und erstmal die kritischen Teile zu separieren.

Was für eine Version hast Du denn jetzt ?
Wie himitsu schon geschrieben, leider sehr klein, gibt es eigentlich ältere Versionen dazu, wenn man eine neue Version gekauft hat.
Das kann man in seinem Maintainance von Emba finden.
Falls es das nicht gibt könntest Du auch den Emba Vertrieb in Langen kontaktieren,
Die können oft weiterhelfen bei solchen Problemen.