Wie TLS Callback in Delphi

[itsme]

Hallo zusammen... :wink:

Ich habe eine vlt. etwas ungewöhnliche Frage, nämlich wie kann ich eine TLS Callback Funktion in Delphi implementieren?

Längere Suche im Netz hat lediglich Lösungen in ASM und C++ ans Licht gebracht, wobei in C++ die Funktion offensichtlich programmiertechnisch, vor die Main() Funktion gepackt wird.
Aber wie sieht das in Delphi aus?

Wozu brauche ich sowas?
Nun mich stört, dass bei Mediaprogrammen immer die bass.dll separat dazu gelegt werden muss, daher habe ich die bass.dll als Resource mit in die EXE gepackt, um sie zur Laufzeit aus der Resource temporär zu erzeugen...

Code:

begin
  Application.Initialize;

  sAppPath := IncludeTrailingPathDelimiter(ExtractFileDir(Application.ExeName));
  if not FileExists(sAppPath + 'Bass.dll') then
  begin
     fName := sAppPath + 'Bass.dll';
     rStream := TResourceStream.Create(hInstance, 'Bass', RT_RCDATA);
    try
      fStream := TFileStream.Create(fName, fmCreate);
      try
        fStream.CopyFrom(rStream, 0);
      finally
        fStream.Free;
      end;
    finally
      rStream.Free;
    end;
  end;

  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Das klappt auch alles wunderbar, leider wird offensichtlich so früh versucht die DLL zu laden, dass jeder programmierte Aufruf einer Funktion dazu führt, dass wg. fehlender bass.dll das Programm erst gar nicht gestartet wird.
Selbst ein BASS_Free() in OnClose, welches ja erst zu Programmende benötigt, sprich aufgerufen wird, führt zu o. a. Fehler!

Daher meine Überlegung, die temporäre Erzeugung der bass.dll per TLS Callback, also vor Erreichen des Program Entry Point, zu gestalten, um dieser Fehlermeldung zu entgehen und ein (hoffentlich) funktionierendes Programm zu erhalten.

Jeder hilfreiche Tipp ist herzlich willkommen... :-D

[DeddyH]

Wird die DLL statisch gelinkt? Dann wundert mich das Verhalten nicht, da sie zum Programmstart ja noch gar nicht vorhanden ist. Oder hab ich Dich falsch verstanden?

[himitsu]

Wenn die DLL-Funktionen statisch eingebunden sind (external), dann werden alle Funktionsaufrufe und die zugehörigen DLLs vom ExeLoader der Anwendung (bzw. von Windows) zuerst geladen und erst danach wird der Code der Anwendung ausgeführt.

Ist ja auch richtig so, denn so werden erst alle Abhängigkeiten initialisiert, welche vom auszuführenden Code benötigt werden.

Wenn du die DLL erst zur Laufzeit initilasisieren willst, dann mußt du die DLL-Funktionen dynamisch laden (GetProcAddress), ebenso, wie du es mit der DLL machst.

Die Andere Alternative wäre ein eigener Loader, welcher noch vor dem eigentlichen Programmcode die DLL läd, aber das dynamische Laden sollte einfacher/besser sein.

[itsme]

Es geht weder statisch, noch dynamisch...

Ein wenig herumexperimentieren mit Breakpoints hat gezeigt, das die Fehlermeldung nicht nur vor LoadLibrary auftaucht, sondern selbst ein BP auf Application.Initialize wird est gar nicht erreicht!

Und letzterer liegt ja in jedem Fall, noch vor Erzeugung der temporären bass.dll :?

[himitsu]

Es geht hier nicht um ein statisches oder dynamisches Laden der DLL, diese lädst du ja definitiv dynamisch (LoadLibrary).

Wie verwendest du denn diese DLL?
Ohne weitere Kenntnis dessen kann man hier nicht weiter helfen.

Es dürfen auf keinen Fall irgendwelche statischen Referenzen auf irgendwelche Resourcen aus dieser DLL im Programm vorhanden sein, welche von einem Loader vor dem Programmcode versucht werden zu laden, also bevor du die DLL nicht geladen hast.

Zitat:

Zitat von z.B. sowas darfnirgendwo vorkommen

procedure test; external ...

[itsme]

Ok ich poste mal ein wenig mehr Code, da ich das ganze ohnehin nur in einem Testprojekt ausprobiert habe.
Wobei ich einfach mal das dynamische Laden weggelassen habe, da kompilieren auch so fehlerfrei funktioniert, was mit uses BASS zu tun hat.
Ich bin mir derzeit echt nicht im Klaren darüber, ob ich die bass.pas mit den Deklarationen benutzen darf (muss), oder ob ich bei LoadLibrary und GetProcAddress, diese besser weglasse...
Mag sein, dass hier ein Fehler meinerseits vorliegt, ich werde das aber noch ausprobieren.

Code:

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Bass;

procedure TForm1.OnActivate(Sender: TObject);
begin
//  BASS_Init(-1, 44100, 0, Handle, nil);
end;

procedure TForm1.OnClose(Sender: TObject; var Action: TCloseAction);
var
  fName: string;

begin
//  BASS_Free();
  fName := 'Bass.dll';
  if FileExists(fName) then
    if DeleteFile(fName) then
      Application.Terminate;
end;

Sobald ich eine der auskommentierten Funktionen in Betrieb nehme, kommt die Fehlermeldung mit der fehlenden bass.dll, ja auch, wenn ich über die entsprechenden API-Funktionen dynamisch linke. :)

Nichtsdestotrotz würde ich gerne auf meine Eingangsfrage zurückkommen.
Selbst wenn es durch eure Hilfe mit der bass.dll klappen sollte, würde ich trotzdem gerne wissen, wie man TLS Callback in Delphi implementiert.

[omata]

Ich bin mir nicht ganz sicher, ob ich verstehe was du da eigentlich wissen willst. Aber ich bin der Meinung, genau das mache ich hier

[itsme]

@omata

Ich habe nun natürlich nicht in der Kürze der Zeit die gesamten Attachments herunterladen können, sondern lediglich im Schnelldurchgang den gesamten Thread gelesen...

Leider habe ich weder etwas über temporäres Erstellen der bass.dll aus einer Resource in der EXE finden können, noch wie man dieselbe anschließend problemlos nutzen kann.

Und das Problem TLS Callback ist dort ganz bestimmt nicht behandelt worden.
Irgendwie habe ich das Gefühl, dass dieser Begriff doch für Verunsicherung und evtl. falsche Vorstellungen sorgt.
TLS steht für Thread Local Storage und die hier erwähnte Callback-Funktion ist ein Teil des Programmcodes, welcher bereits vor dem endgültigen Laden des Programms ausgeführt wird.
Letztendlich quasi unsichtbar, was sich viele Protektoren o. ä. Software zu Nutze machen.

Ich will hier gerne eingestehen, ein Hobbyprogrammierer älteren Semesters zu sein, der öfter eigene Unzulänglichkeiten kompensieren muss, daher den Delphi-Debugger nicht besonders prickelnd findet, ferner sein Hobby über die Assemblerprogrammierung begonnen hat und daher gerne mit externen Debuggern a là OllyDbg arbeitet.
Dort kann man z.B. gut einstellen "Break on TLS Callback" und wird feststellen, dass dieser Breakpoint schon lange vor Erreichen des OEP, also des Anfangs des Programms erreicht wird, was letztendlich meinen Gedankengang dahin geführt hat, hier bereits eine DLL zu erzeugen, welche ich dann nach Programmstart tatsächlich und uneingeschränkt nutzen kann... :)

[himitsu]

Noch einen/zwei Tipp(s):

- die DLL nicht in das Programmverzeichnis entpacken, sondern lieber ins temporäre Verzeichnis von Windows (GetTempPath).

- statt dem FileStream direkt über die WinAPI gehn, also WriteFile und CreateFile.
bei Letzerem gibst du dann noch FILE_ATTRIBUTE_TEMPORARY mit an.

Grund:
Nicht immer hat man Schreibrechte im Programmordner und nicht jeder User mag es, wenn man da rumschreibt, bzw. man nutzt einen schreibgeschützten Datenträger (CD/DVD).
FILE_ATTRIBUTE_TEMPORARY sagt Windows, daß es eine temporäre Datei ist, welche dann automatisch gelöscht wird, sobald alle Handles auf diese Datei geschlossen sind.
Auch wenn dein Programm abstürzt und somit das OnClose nicht mehr ausgeführt würde

[itsme]

@himitsu

Ok, ich will und werde deine Tipps gerne berücksichtigen, wobei die User eigentlich aus mir und meiner Familie bestehen, wo es nicht so die große Rolle spielen würde... :)

Ich habe mich ja bereits in in meinem vorherigen post als Hobbyprogrammierer geoutet, hoffe daher hier nicht unnötigerweise Resourcen von den Profis verschwendet zu haben.
Falls doch, bitte ich um Entschuldigung und Nachsicht. :oops:

Aber mit mittlerweile (leider) fast 60, möchte man den Dingen eben restlos auf den Grund gehen, auch wenn es zugegebenermaßen vollkommen uninteressant ist, ob ich auf den Rechner vom Junior nur Test.exe, oder aber Test.exe UND Bass.dll kopiere... :wink: