DLL einsprungspunkt mehrfach laden

[toni]

hallo,

ich habe folgendes problem:
ich habe eine delphi.exe die eine cobol.dll mittels dynamischen einbinden lädt.

das problem ist das ich innerhalb dieser cobol.dll nur einen einsprungspunkt habe und dieser allerdings mehrfach geladen werden soll. d.h. die cobol.dll öffnet ein fenster und bleibt solange aktiv bis dieses wieder geschlossen wird. wenn ich es schliesse zieht freelibrary und ich kann die dll erneut aufrufen. ich erhalte im moment beim 2. aufruf der funktion aus der dll eine externe exception. die frage ist ob es überhaupt möglich ist die funktion mehrfach zu laden!?!

kleines codebeispiel:

Type Tcobol = array[1..1] of Char;
type tcobolopen = function(parameter: string) :tcobol; cdecl;

...
dllhandle := LoadLibrary('COBOL.DLL');
if (dllhandle <> 0) then
begin
@cobolopen := GetProcAddress(dllhandle,'COBOLDLL');
if (@cobolopen <> nil) then
cobol := cobolopen(parameter)
else
showmessage(pchar(@cobolopen));
end
else
showmessage('COBOLDLL konnte nicht geladen werden!');

freelibrary(dllhandle);


weiss jemand rat

[Bernhard Geyer]

Ist wohl diese DLL so buggy implementiert?

Du könntest Sie umbennen und dann unter anderem Namen nochmals laden.

[toni]

richtig ist ne etwas gewachsene anwendung die bisher über mehrere exe dateien per command line miteinander verknüpft war. ich möchte nun diese anwendung von einer delphi.exe als menü diese programmteile starten - wobei ich immer in einen startpunkt springen muss!

dein vorschlag is zwar nich grad die eleganteste lösung könnte aber funktionieren!
zumindest wenn ich die datei kopiere.
hm schade gibts denn wirklich keine andere lösung - irgendwas mit nem referenzzähler.

was macht der eigentlich genau?

[Bernhard Geyer]

dein vorschlag is zwar nich grad die eleganteste lösung könnte aber funktionieren!zumindest wenn ich die datei kopiere.
hm schade gibts denn wirklich keine andere lösung - irgendwas mit nem referenzzähler.

Das Problem wird sein das einfach die Cobol-DLL Müll macht. Elegander wäre natürlich die Fehler in der DLL zu beseitigen das sie auch mit mehrfachen Aufrufen zurecht kommt. Aber vermutlich wollt ihr diesen alten Code nicht mehr Anfassen.

[toni]

was heist hier alter code - das ist feinstes cobol!!!

naja

das problem ist das jedes cobol modul eine startprocedure braucht wo die parameter die von delphi kommen geprüft und verarbeitet werden müssen.
lässt sich leider nicht anders machen.

das andere problem was ich sehe ist das die delphi.exe eine startcobol.dll lädt die die parameter prüft und dann eine weitere cobol.dll aufruft die das eigentliche programmfenster öffnet. der einsprungspunkt ist also immer die startcobol.dll die ich ja ggf. kopieren oder umbennenen kann, aber das selbe müsste ich dann mit der 2. cobol.dll machen ist auch sehr umständlich!

gibt es denn wirklich keine andere möglichkeit???

[toni]

kann man nicht den einsprungspunkt der dll mit einem parameter definieren? wenn ja wie? wie läuft das denn wenn ich eine delphi.dll hätte - ist doch im grunde das selbe problem - kann man da nicht die einsprungspunkte in der dll irgendwie mit parametrisierung angeben? (also unter exports)

[Bernhard Geyer]

was heist hier alter code - das ist feinstes cobol!!!

naja

Eben. Prädestiniert für Bugs

Da ich den genauen Cobol-Code nicht kenne (und auch nix damit zu tun haben will) sag ich einfach das dieser Code einfach nicht darauf ausgelegt ist mehrmals verwendet zu werden. Also mußt du Windows austricksen so das jeder instanziierung von Delphi aus eine "jungfreuliche" Cobol-DLL bekommt die keine gemeinsamen Speicherbereich (global Variablen, ...) mit der anderen Instanz hat.

Oder es wird die Implementierung in der DLL angepaßt das sie mehrfach "instanzierbar" ist.

[toni]

danke für deinen tipp,
da ich aber dadurch die struktur der cobol anwendung um 100grad umstricken müsste (etwa 1000 cobol module die dadurch angepasst werden müssten), wäre mein problem in einem halben jahr sicher gelöst! schade - beantwortet allerdings auch nicht meine vorhergehenden fragen!

[Bernhard Geyer]

schade - beantwortet allerdings auch nicht meine vorhergehenden fragen!

Udn wieso das?

Also zu deinem Delphi-DLL einwurf. Sicherlich kann man unter Delphi genauso das (eingeschrängte) Verhalten der Cobol-DLL nachbauen.
Einfaches Beispiel:

Eine Delphi-DLL hat 2 Funktionen:

procedure SetInteger(i: Integer);
function GetInteger: Integer;

Implementiert ist es mit:

var
iGlobaleVar: Integer;

procedure SetInteger(i: Integer);
begin
iGlobalVar := I;
begin;

function GetInteger: Integer;
begin
result := iGlobalVar;
end;

Wird jetzt die DLL 2* von einem Programm geladen so kann die zweite Stelle wo diese DLL verwendet wird die Daten der ersten Stelle im Code überbügeln

Lösung:
1, Umbenennen der DLL so das 2 mal unabhängige Datenadressräume zur verfügung stehen

2, DLL erweitern das mit einem sogenannten Handel der Kontext des Aufrufes erkannt wird:

var
GlobalList: THandleIntegerList (Verwaltungliste die "Handle" -> Integerwert "auflösen" kann)

function InitDLL: THandle;
begin
result := GlobalList.GetNewHandle;
end;

procedure SetInteger(Handle: THandle; i: Integer);
begin
GlobalList.SetIntForHandle(Handle, i);
iGlobalVar := I;
begin;

function GetInteger(Handle: THandle): Integer;
begin
result := GlobalList.GetIntForHandle(Handle);
end;

Und schon kommen sich die beiden verwendungen nicht mehr in die Quere.

Das man beim Laden einer DLL angeben könnte das es keine gemeinsamen Speicherbereiche gibt wäre mir neu bzw. kenn ich dafür keinen entsprechende WinAPI-Befehl/Parameter.