Discussion :

[petitcoucou31]

Bonjour a tous,
comme le dit le titre je voudrais savoir ce que fait réellement cette instruction lors de son appel !
je pensais qu'elle ne faisait que "charger" la DLL sans tenir compte de son code,mais cela semble pas le cas !

J'ai des dLL qui fonctionnent très bien avec une application. Mais quand je les appelles depuis une autre application j'ai des erreurs consécutives qui aboutissent à un plantage des que j'exécute le "LoadLibrary". Voir code ci-dessous qui plante dans la nouvelle application mais fonctionne dans l'application d'origine, d'ou mes interogations !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
begin
  nomDll:='DLLRack.DLL' ;
  HandleDLLRack:=LoadLibrary(PChar(nomDll)); <= plantage

  if HandleDllRack=0 then showmessage('erreur de chargement')
  else
  begin
     @ExAllumeLedLv:=GetProcAddress(HandleDllRack,'ExAllumeLedLv');
       if @ExAllumeLedLv=nil then showmessage('erreur de chargement de la fonction  : ExAllumeLedLv');
   end;
end;

Pour que ça fonctionne je dois recompiler les DLL en retirant une unité (qui Affiche des messages perso style "showmessage") !

Une DLL n'est elle pas autonome une fois compilé et fonctionnelle ?
par autonome je veux dire être utilisée par n'importe quelle application tierce qui fait les appels a ses fonctions correctements.

Quelqu'un a t il une idée sur ce problème ?


merci a vous pour vos idées.

[guillemouze]

a mon avis, il te manque ShareMem en tout premier uses de ton dpr

[Dr.Who]

encore un cadeau (voir PJ unité LibLoader) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Uses LibLoader;
 
 
var
  { on vas recupéré GetTickCount dans Kernel32.dll }
  LibKernel32     : TLibraryLoader;
  DynGetTickCount : function : DWORD; stdcall;
 
  { ici on vas provoquer volontairement une erreur }
  LibUnknown : TLibraryLoader;
  DynUnknown : function : DWORD; cdecl;
 
 
 
procedure TFrmDemo.FormCreate(Sender: TObject);
begin
  { LibKernel32 : ne doit pas provoquer d'erreur }
  LibKernel32 := TLibraryLoader.Create(Kernel32);
  LibKernel32.OnLibError     := LibErrorEvent;
  LibKernel32.OnGetProcError := LibGetProcErrorEvent;
 
  LibKernel32.Load;
 
  if LibKernel32.GetProc('GetTickCount', @DynGetTickCount) then
    caption := format('%d =? %d',[DynGetTickCount, GetTickCount]);
 
  { LibUnknown : renvera deux erreur librairie inconnue et procedure inconnue }
  LibUnknown := TLibraryLoader.Create('unknown.dll');
  LibUnknown.OnLibError := LibErrorEvent;
  LibUnknown.OnGetProcError := LibGetProcErrorEvent;
 
  LibUnknown.Load;
 
  if LibUnknown.GetProc('Unknown', @DynUnknown) then
    ShowMessage('Incroyable! il existe une fonction Unknown dans Unknown.dll!');
 
end;

[Dr.Who]

a mon avis, il te manque ShareMem en tout premier uses de ton dpr

ShareMem est trés facultatif. uniquement nécessaire pour les chaines de caractères et encore ... on peu contourner le problème facilement grâce aux PChar.

[petitcoucou31]

Salut et merci pour vos réponses

En effet le ShareMem est très facultatif, car les paramètres passés entre DLL et application ne sont que des "Pchar" et "real".

Je ne met pas en doute l' utilisation de LoadLibrary, puisque toute ces DLLs sont parfaitement fonctionnelle avec l'application d'origine.

Donc le mode de chargement dynamique des DLLs et récupération des fonctions des DLLs sont OK.

Je peux bien avoir des plantages a l'utilisation des fonctions de la DLLs ou au moment de leur appel, si par exemple je passais de mauvais paramètres...

Mais la c'est au moment de leur chargement, et le code ci-dessous marche dans une application (donc charge la dll ) et plante dans l'autre ??

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
HandleDLLRack:=LoadLibrary(PChar(nomDll)); <= plantage (trop d'erreur consécutives)

D'ou mes questions cité en début de post.

merci pour vos idées

[Andnotor]

N'aurais-tu pas du code à l'initialisation de la DLL (DLL_PROCESS_ATTACH) qui rende son utilisation dépendante de l'exe ?
Par exemple l'ouverture d'un fichier mappé qui n'existe pas...

[petitcoucou31]

Voila , tu as aussi trouvé AndNotor..

je venais donner la solution mais tu m'as devancer lol...En fait oui, une unité commune aux dlls a dans sa partie d'initialisation une routine qui détermine les chemins d'accès a toutes les DLLs et fichiers utilitaires.

Cette routine utilise un Nom de répertoire précis, qui n'excitant planté au moment de son chargement.

Solution a éviter ce genre d'initialisation dans une DLL !! car a ce jour ne pouvant modifier mes DLLs , je suis contraint d'utiliser la structure de fichier définie.

Merci pour votre aide .