Problem mit Def und External

[AHT]

In meiner Profanversion (XProfan9) ergibt das hier einen dicken Programmabsturz:

DEF ImageList_Create(5) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_Create"
DEF ImageList_AddIcon(2) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_AddIcon"
DEF ImageList_Destroy(1) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_Destroy"
REM DEF ImageList_Create(5) !"COMCTL32.dll", "ImageList_Create"
REM DEF ImageList_AddIcon(2) !"COMCTL32.dll", "ImageList_AddIcon"
REM DEF ImageList_Destroy(1) !"COMCTL32.dll", "ImageList_Destroy"
Def ExtractIcon(3) !$SYSPATH + "\" + "shell32.dll", "ExtractIconA"
DEF LoadIcon(2) !$SYSPATH + "\" + "USER32", "LoadIconA"
Def GetModuleHandle(1) !$SYSPATH + "\" + "Kernel32", "GetModuleHandleA"
Def GetModuleFileName(3) !$SYSPATH + "\" + "Kernel32", "GetModuleFileNameA"
 
Declare Imagecount%, Imagelist&, IconHolder$, IconHandle&, Listview&, Comctl32&, DLL$
 
Windowstyle 31+512
Windowtitle "Probleme mit Systempfad"
Window 0, 0 - 640, 440
Usermessages $10
 
Clear ImageList&
Listview& = Control("SysListView32", "", $54018001, 20, 100, 400, 250, %HWND, 2801, %Hinstance, $200)
IF FileExists($SYSPATH + "\" + "COMCTL32.dll")
 Print "Comctl32 im Systemverzeichnis: "+$SYSPATH + "\" + "COMCTL32.dll"
endif
DLL$ = "Comctl32"
Comctl32& = GetModuleHandle(addr(DLL$))
Print "Handle der geladenen comctl32: " + str$(Comctl32&)
DLL$ = Space$(600)
GetModuleFileName(Comctl32&, addr(DLL$), 560)
Print "Dateiname der geladenen comctl32: "
Print Trim$(DLL$)
CreateImagelist
sendmessage(Listview&, $1003, 1, Imagelist&)
 
While %UMESSAGE <> $10
  Waitinput
EndWhile
Case ImageList&<>0 : Imagelist_Destroy(ImageList&)
Freedll Comctl32&
 
Proc CreateImagelist
  Imagecount% = 0
  Case ImageList&<>0 : Imagelist_Destroy(ImageList&)
  Imagelist& = ImageList_Create(16, 16, $FE | $1, 300, 50) 'Imagelist erzeugen
  Print ImageList&
  Print $SYSPATH + "\" + "COMCTL32.dll"
  IconHolder$ = $SYSPATH + "\" + "Shell32.dll"
  IconHandle& = ExtractIcon(%HINSTANCE, addr(IconHolder$), 23)
  ImageList_AddIcon(Imagelist&, IconHandle&) 'Index 0 ist Hilfe
endproc

Ist das in aktuellen Versionen von Profan noch so?
Grund dafür dürfte sein, dass die comctl32.dll bereits unter einem anderen Pfad vom Prozess geladen wurde.

Bei External passiert übrigens das gleiche.

Da die PSAPI.DLL ebenfalls in mehreren Versionen auf einem PC vorhanden sein kann, könnte das zu gewaltigen "Verwicklungen" führen.

[Bangkok]

Das stürzt in der neuesten Version auch ab. Aber in DEF sind auch keine Pfade vorgesehen.
Normalerweise lädst du ja die DLL mit usedll() und hier gehört der Pfad zur DLL hin nicht in DEF. Mit Def werden ja nur die Funktionen einer geladenen DLL eingebunden.

[AHT]

Na ja - aber in External?

Def ExtractIcon(3) !$SYSPATH + "\" + "shell32.dll", "ExtractIconA"
DEF LoadIcon(2) !$SYSPATH + "\" + "USER32", "LoadIconA"
Def GetModuleHandle(1) !$SYSPATH + "\" + "Kernel32", "GetModuleHandleA"
Def GetModuleFileName(3) !$SYSPATH + "\" + "Kernel32", "GetModuleFileNameA"
 
Declare Imagecount%, Imagelist&, IconHolder$, IconHandle&, Listview&, Comctl32&, DLL$
 
Windowstyle 31+512
Windowtitle "Probleme mit Systempfad"
Window 0, 0 - 640, 440
Usermessages $10
 
Clear ImageList&
Listview& = Control("SysListView32", "", $54018001, 20, 100, 400, 250, %HWND, 2801, %Hinstance, $200)
IF FileExists($SYSPATH + "\" + "COMCTL32.dll")
 Print "Comctl32 im Systemverzeichnis: "+$SYSPATH + "\" + "COMCTL32.dll"
endif
DLL$ = "Comctl32"
Comctl32& = GetModuleHandle(addr(DLL$))
Print "Handle der geladenen comctl32: " + str$(Comctl32&)
DLL$ = Space$(600)
GetModuleFileName(Comctl32&, addr(DLL$), 560)
Print "Dateiname der geladenen comctl32: "
Print Trim$(DLL$)
CreateImagelist
sendmessage(Listview&, $1003, 1, Imagelist&)
While %UMESSAGE <> $10
  Waitinput
EndWhile
Case ImageList&<>0 : External($SYSPATH + "\" + "COMCTL32.dll", "Imagelist_Destroy", ImageList&)
REM Case ImageList&<>0 : External("COMCTL32.dll", "ImageList_Destroy", ImageList&)
 
Proc CreateImagelist
  Imagecount% = 0
  Case ImageList&<>0 : External($SYSPATH + "\" + "COMCTL32.dll", "ImageList_Destroy",ImageList&)
  REM Case ImageList&<>0 : External("COMCTL32.dll", "ImageList_Destroy",ImageList&)
  Imagelist& = External($SYSPATH + "\" + "COMCTL32.dll", "ImageList_Create", 16, 16, $FE | $1, 300, 50) 'Imagelist erzeugen
  REM Imagelist& = External("COMCTL32.dll", "ImageList_Create", 16, 16, $FE | $1, 300, 50) 'Imagelist erzeugen
  IconHolder$ = $SYSPATH + "\" + "Shell32.dll"
  IconHandle& = ExtractIcon(%HINSTANCE, addr(IconHolder$), 23)
  External($SYSPATH + "\" + "COMCTL32.dll", "ImageList_AddIcon", Imagelist&, IconHandle&) 'Index 0 ist Hilfe
  REM External("COMCTL32.dll", "ImageList_AddIcon", Imagelist&, IconHandle&) 'Index 0 ist Hilfe
endproc

Wie du siehst, ist das auch nicht der Grund des Absturzes...
Bei manchen DLLs scheinen "Def" und External die DLL aus dem Systemverzeichnis nachzuladen, in diesenm Fall wird nicht nachgeladen.

[RGH]

Hallo,

das ist leider eine (meines Erachtens sehr dumme) Eigenart von Windows:
Ist ein Modul (meist eine DLL) erst einmal geladen, dann wird beim neuerlichen Laden desselben Moduls (selbst wenn es eigentlich eine andere Version in einem anderen Pfad ist) nur der Zähler des geladenen Moduls hochgezählt. Es wird offensichtlich der interne Modulname zur Unterscheidung herangezogen und nicht der Pfad.

Das hat uns in der Firma, in der ich arbeite und wo Programme an über 2000 Mitarbeiter auf ihre Notebooks verteilt werden, schon einiges an Kopfzerbrechen bereitet. Es ging da um eine Steuer-Berechnungs-DLL, die von verschiedenen Programmen genutzt wurde und dummerweise mehrmals auf dem System vorhanden war. Bei einem Update wurde ein Speicherort übersehen und je nachdem, welches Programm zuerst aufgerufen wurde, wurde in allen Programmen falsch oder richtig gerechnet.

External() kann da auch nicht helfen, denn es werden intern ja immer die gleichen Windows-APIs benutzt. Wenn der Programmierer einen Pfad angibt, wird dieser an die API übergeben.

COMCTL32.DLL ist in diesem Zusammenhang ein besonders "beliebter" Kandidat. Es gibt die eine oder anderer Anwendung, die eine eigene Version mitbringt.

Gruß
Roland

[Bangkok]

Man könnte ja überprüfen ob die DLL bereits geladen ist, wenn ja entladen und die gewünschte Version neu laden.

[AHT]

Roland - das kann so aber nicht stimmen, denn folgendes funktioniert wieder perfekt:

 
DEF ImageList_Create(5) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_Create"
DEF ImageList_AddIcon(2) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_AddIcon"
DEF ImageList_Destroy(1) !$SYSPATH + "\" + "COMCTL32.dll", "ImageList_Destroy"
REM DEF ImageList_Create(5) !"COMCTL32.dll", "ImageList_Create"
REM DEF ImageList_AddIcon(2) !"COMCTL32.dll", "ImageList_AddIcon"
REM DEF ImageList_Destroy(1) !"COMCTL32.dll", "ImageList_Destroy"
Def ExtractIcon(3) !$SYSPATH + "\" + "shell32.dll", "ExtractIconA"
DEF LoadIcon(2) !$SYSPATH + "\" + "USER32", "LoadIconA"
Def GetModuleHandle(1) !$SYSPATH + "\" + "Kernel32", "GetModuleHandleA"
Def GetModuleFileName(3) !$SYSPATH + "\" + "Kernel32", "GetModuleFileNameA"
 
Declare Imagecount%, Imagelist&, IconHolder$, IconHandle&, Listview&, Comctl32&, DLL$
 
Windowstyle 31+512
Windowtitle "Probleme mit Systempfad"
Window 0, 0 - 640, 440
Usermessages $10
 
Clear ImageList&
Listview& = Control("SysListView32", "", $54018001, 20, 200, 400, 140, %HWND, 2801, %Hinstance, $200)
 
DLL$ = "Comctl32"
Comctl32& = GetModuleHandle(addr(DLL$))
Print ""
Print "Handle der zuerst geladenen comctl32: " + str$(Comctl32&)
Print ""
DLL$ = Space$(600)
GetModuleFileName(Comctl32&, addr(DLL$), 560)
Print "Dateiname der zuerst geladenen comctl32: "
Print Trim$(DLL$)
Comctl32& = UseDLL($SYSPATH + "\" + "COMCTL32.dll")
Print ""
Print "Handle der zuletzt geladenen comctl32: " + str$(Comctl32&)
DLL$ = Space$(600)
GetModuleFileName(Comctl32&, addr(DLL$), 560)
Print ""
Print "Dateiname der zuletzt geladenen comctl32: "
Print Trim$(DLL$)
 
CreateImagelist
sendmessage(Listview&, $1003, 1, Imagelist&)
 
While %UMESSAGE <> $10
  Waitinput
EndWhile
Case ImageList&<>0 : Imagelist_Destroy(ImageList&)
Freedll Comctl32&
end
 
Proc CreateImagelist
  Imagecount% = 0
  Case ImageList&<>0 : Imagelist_Destroy(ImageList&)
  Imagelist& = ImageList_Create(16, 16, $FE | $1, 300, 50) 'Imagelist erzeugen
  IconHolder$ = $SYSPATH + "\" + "Shell32.dll"
  IconHandle& = ExtractIcon(%HINSTANCE, addr(IconHolder$), 23)
  ImageList_AddIcon(Imagelist&, IconHandle&) 'Index 0 ist Hilfe
endproc

Wie man hier sieht, wird die DLL mit dem falschen Pfad sehr wohl zusätzlich geladen (anderes Handle und anderer Pfad => andere DLL). Das Mapping des Pfades vernachlässigen wir jetzt mal.
Da baut also nicht Windows den Mist - oder sehe ich das falsch?

[RGH]

Hallo Andreas,

SORRY, ich habe wohl nicht genau genug geschaut und geschrieben. Jetzt sehe ich, was im ersten Listing das Problem ist: Du verwendest nur die API GetModuleHandle(). Diese lädt ein Modul aber nicht, sondern ermittelt nur das Handle eines geladenen Moduls aufgrund des Modul-Namens. Hier spielt der Pfad offensichtlich keine Rolle.

Im letzten Beispiel nutzt Du UseDLL (hinter dem die Api LoadLibrary() steckt). Diese lädt ein Modul in den Speicher, wenn es noch nicht im Speicher ist und setzt anderenfalls den Zähler hoch. Hier wird offensichtlich der Pfad berücksichtigt.

Gruß
Roland

[AHT]

Nein Roland, denn folgendes funktioniert ja auch:

Def GetModuleInformation(4) !"Psapi.dll", "GetModuleInformation"
DEF GetCurrentProcess(0) !"kernel32", "GetCurrentProcess" 'Ermittel das Handle des aktiven Prozesses.
Def GetModuleHandle(1) !"Kernel32", "GetModuleHandleA"
Def GetModuleFileName(3) !"Kernel32", "GetModuleFileNameA"
 
Declare MODULEINFO#, DLL$, PSAPI$, PSAPI&

CLS
DLL$ = "Psapi.dll"
PSAPI&=GetModuleHandle(addr(DLL$))
Print "Handle der Psapi.dll: " +Str$(PSAPI&)
Print "Dateiname der Psapi.dll: "
PSAPI$ = Space$(600)
IF PSAPI&<>0
 GetModuleFileName(PSAPI&, addr(PSAPI$), 560)
 Print PSAPI$
endif
Print ""
Print ""
Print "Kernel32.dll Daten: "
DIM MODULEINFO#, 12
DLL$ = "Kernel32.dll"
GetModuleInformation(GetCurrentProcess(), GetModuleHandle(addr(DLL$)), MODULEINFO#, 12)
Print "Base:" + Str$(Long(MODULEINFO#, 0))
Print "Size:" + Str$(Long(MODULEINFO#, 4))
Print "Entry:" + Str$(Long(MODULEINFO#, 8))
Dispose MODULEINFO#
 
While 1
 Waitinput
EndWhile

Hier lädt XProfan die PSAPI.DLL nach, obwohl ich hier nicht USEDLL angewendet habe....



Warum verhält sich XProfan bei der Comctl32.dll anders? Das liegt doch nicht an Windows???
Dass das nicht an Windows liegen kann, sieht man doch hier, oder?

[AHT]

Ich möchte noch etwas kontrollieren und brauche deshalb dringend noch einen Screenshot von diesem Quelltext vom Rechner von Frank Abbing.

[RGH]

Zu GetModuleHandle:

Zitat aus MSDN: "Retrieves a module handle for the specified module. The module must have been loaded by the calling process.
...
If lpModuleName does not include a path and there is more than one loaded module with the same base name and extension, you cannot predict which module handle will be returned. To work around this problem, you could specify a path, use side-by-side assemblies, or use GetModuleHandleEx to specify a memory location rather than a DLL name.
..."

Die ComCtl32.dll ist üblicherweise schon immer geladen. Die PSAPI.DLL offensichtlich nicht. Daher bringt GetModuleHandle() da auch die 0 als Ergebnis = Modul ist nicht geladen.

Und nun kommt's: GetModuleInformation() verwendet die PSAPI.DLL und lädt diese, wenn sie zuvor nicht geladen wurde. Das lässt sich zeigen, indem Du die Programmzeilen zur Ermittlung des Handles und Namens der PSAPI.DLL nach diesem Aufruf nochmal einbaust.

Zitat aus MSDN: "The GetModuleInformation function does not retrieve information for modules that were loaded with the LOAD_LIBRARY_AS_DATAFILE flag. For more information, see LoadLibraryEx. Starting with Windows 7 and Windows Server 2008 R2, Psapi.h establishes version numbers for the PSAPI functions. The PSAPI version number affects the name used to call the function and the library that a program must load.
If PSAPI_VERSION is 2 or greater, this function is defined as K32GetModuleInformation in Psapi.h and exported in Kernel32.lib and Kernel32.dll. If PSAPI_VERSION is 1, this function is defined as GetModuleInformation in Psapi.h and exported in Psapi.lib and Psapi.dll as a wrapper that calls K32GetModuleInformation.
Programs that must run on earlier versions of Windows as well as Windows 7 and later versions should always call this function as GetModuleInformation."

Ich hoffe, das hilft Dir weiter.

Gruß
Roland

[AHT]

OK, dann anders:
Wie du siehst, wird hier aber ein Pfad übergeben. Warum sollte sich also LoadLibrary, wenn es innerhalb von External aufgerufen wird, anders veralten als LoadLibrary, wenn es über UseDLL aufgerufen wird???

Was tut External genau? Welche API ruft External auf bzw. welchen Delphibefehl?

PS:

Und nun kommt's: GetModuleInformation() verwendet die PSAPI.DLL und lädt diese, wenn sie zuvor nicht geladen wurde. Das lässt sich zeigen, indem Du die Programmzeilen zur Ermittlung des Handles und Namens der PSAPI.DLL nach diesem Aufruf nochmal einbaust.

Def GetModuleInformation(4) !"Psapi.dll", "GetModuleInformation"
DEF GetCurrentProcess(0) !"kernel32", "GetCurrentProcess" 'Ermittel das Handle des aktiven Prozesses.
Def GetModuleHandle(1) !"Kernel32", "GetModuleHandleA"
Def GetModuleFileName(3) !"Kernel32", "GetModuleFileNameA"
Declare MODULEINFO#, DLL$, PSAPI$, PSAPI&
 
CLS
DLL$ = "Psapi.dll"
PSAPI&=GetModuleHandle(addr(DLL$))
Print "Handle der Psapi.dll vor dem Aufruf: " +Str$(PSAPI&)
Print "Dateiname der Psapi.dll vor dem Aufruf: "
PSAPI$ = Space$(600)
IF PSAPI&<>0
 GetModuleFileName(PSAPI&, addr(PSAPI$), 560)
 Print PSAPI$
endif
Print ""
Print ""
Print "Kernel32.dll Daten: "
DIM MODULEINFO#, 12
DLL$ = "Kernel32.dll"
GetModuleInformation(GetCurrentProcess(), GetModuleHandle(addr(DLL$)), MODULEINFO#, 12)
Print "Base:" + Str$(Long(MODULEINFO#, 0))
Print "Size:" + Str$(Long(MODULEINFO#, 4))
Print "Entry:" + Str$(Long(MODULEINFO#, 8))
Print ""
Print ""
DLL$ = "Psapi.dll"
PSAPI&=GetModuleHandle(addr(DLL$))
Print "Handle der Psapi.dll vor dem Aufruf: " +Str$(PSAPI&)
Print "Dateiname der Psapi.dll vor dem Aufruf: "
PSAPI$ = Space$(600)
IF PSAPI&<>0
 GetModuleFileName(PSAPI&, addr(PSAPI$), 560)
 Print PSAPI$
endif
Dispose MODULEINFO#
While 1
 Waitinput
EndWhile

[RGH]

Zitat von AHT

OK, dann anders:
Wie du siehst, wird hier aber ein Pfad übergeben. Warum sollte sich also LoadLibrary, wenn es innerhalb von External aufgerufen wird, anders veralten als LoadLibrary, wenn es über UseDLL aufgerufen wird???

Was tut External genau? Welche API ruft External auf bzw. welchen Delphibefehl?

Hallo Andreas,
was soll der Quellcode bezüglich Deiner Frage demonstrieren? Weder External() noch UseDLL() kommen vor.
Es wird in beiden Fällen API verwandt.
Zum genauen Aufruf in XProfan kann ich vielleicht heite Abend antworten. Am Arbeitsplatz liegt mir der Quellcode nicht komplett vor.

Gruß
Roland

[Frabbing]

Zitat von AHT

Ich möchte noch etwas kontrollieren und brauche deshalb dringend noch einen Screenshot von diesem Quelltext vom Rechner von Frank Abbing.

Wenn ich dabei helfen kann... hier ist der Screenshot:

[AHT]

@Frank: Wir hatten mal das Problem, dass beim Beenden eines Quellcodes, der vorher die PSAPI.DLL geladen hatte, das Programm mit Zugriffsverletzung abstürzte - und das nur auf deinem Rechner. Ich wollte mal nachsehen, ob auf deinem Rechner die PSAPI.DLL evtl. bereits schon vorher über den Hook, der Auslöser des Problems war, geladen wird. Das ist nicht der Fall.

@Roland: Ob nun External oder Def ist eigentlich egal - in beiden Fällen wird durch das Aufrufen der jeweiligen API die DLL nachgeladen, wenn sie nicht bereits geladen ist. Ist sie geladen, wird, so denke ich, der Loadcount um 1 erhöht. Beim Laden passiert ein Fehler - das was die DLL lädt, kümmert sich nicht in ausreichender Weise um den Pfad der DLL.
PS: Nach dem Aufruf der API wird die DLL auch wieder entladen, bzw. der Loadcount verringert.

Wenn ich nichts übersehen habe, kann derjenige, der da falsch lädt, eigentlich nicht Windows selbst sein - dann bleibt im Prinzip nur Profan oder Delphi über.

Im Augenblick vermute ich bei dem Fehler, der bei Frank passiert ist und der Sache mit der COMCTL32 einen Zusammenhang, denn auch die PSAPI.DLL ist oft in mehreren Versionen auf einem Rechner vorhanden - und bei anderen DLLs sind mir solche Sachen noch nie passiert.
Wenn so etwas wie bei Frank passieren kann, kann im Prinzip alles passieren - und da möchte ich schon genau wissen, was da die Ursache ist und was dort abläuft.

[RGH]

Hallo,
ich habe noch mal nachgesehen. Es ist so wie ich vermutet habe:
(Pfad ist ein Delphi-String mit dem Namen der DLL incl. des Pfades, wie vom Programmierer im Programm angegeben.)

  X := LoadLibrary(Addr(Pfad));
  If X <> 0 Then Begin
    Proc := GetProcAddress(X,Addr(Funktion));
    <...>
    <Schieben der Parameter auf den Stack und Aufruf der Funktion>
    <...>
    FreeLibrary(X);
  End;

So funktioniert es mit Def und mit External, sowie den anderen Aufrufmöglichkeiten.
Reine API, ohne dass XProfan oder Delphi da etwas machen.

Gruß
Roland