Discussion :

[Lorenzo77]

salut,


je viens d'essayer de creer une DLL pour faire un test d'appel dans un autre projet de ces procedures mais je bloque.

quand je mets :
use nomDeMaDLL

delphi me dit que je n'ai pas de fichier DCU qui va avec "nomDeMaDLL" et ne veux donc pas compiler.

comment faire pour creer le fichier dcu quand je construit la DLL ?


merci

[Lorenzo77]

pour que ca fonctionne il faut que je j'indique mes procedures dans le projet qui doit les utiliser :

Code :

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

procedure getHour; external 'Project_DLL_source.dll' name 'getTimeHour';

ce que j'aimerai eviter, ca alourdit pour rien ...

[slimjoe]

ce que j'aimerai eviter, ca alourdit pour rien ...

Ou bien j'ai rien compris ou bien on n'a pas la même définition de "alourdir" .

Je me trompe peut-être, mais la seule façon d'accéder à des méthodes d'une DLL, c'est de déclarer celles-ci dans ton code. Tu peux mettre la déclaration dans le unit qui utilise la DLL ou faire un nouveau unit et y placer la déclaration. Dans les 2 cas, tu déclares et ensuite tu appelles.

Par exemple, ShellExecute est une fonction stockée dans shell32.dll et elle est déclarée dans le unit ShellAPI. Quand tu veux utiliser ShellExecute, tu mets ShellAPI dans tes uses et implémente l'appel de la méthode.

Mais je suis peut-être complètement à côté de ta question

Bon dev!

[Lorenzo77]

non justement, j'ai une DLL qui permet d'utiliser les REGEXP PERL dans Delphi et il suffit de definir le nom de la DLL dans la clause use grace a ce fichier .dcu ... comme ca je n'ai pas besoin d'indiquer les procedures a utiliser, c'est tres pratique !

[slimjoe]

Ok

Comme ça m'arrive souvent j'ai sauté trop vite sur le bouton "Répondre" .

Un fichier .dcu, c'est un fichier .pas (de source) qui est précomplié, c'est à dire qu'il est prêt à être compilé dans un fichier binaire (EXE ou DLL). Quand Delphi dit qu'il ne trouve pas le .dcu, c'est qu'il ne trouve pas la source à l'endroit où tu lui a dit de chercher via tes uses.

Par exemple, si tu fais

Code :

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

1
2
uses
  MonUnit;

Delphi va s'attendre à accéder à du code dans MonUnit.pas ou MonUnit.dcu.

Toi, ce n'est pas ce que tu veux faire .

Si j'ai bien compris. tu ne veux pas avoir à inclure la source dans l'exécutable de ton projet, tu veux que ça reste DANS la DLL et que ton application accède aux méthodes (et non aux sources) quand il en a besoin. Donc tu n'as pas à dire à Delphi où trouver la source de ta DLL mais tu dois dire à Delphi où trouver les méthodes que tu veux qu'il utilise.

C'est pour ça qu'il t'es possible de créer un nouveau unit qui ressemblerait à ça :

Code :

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

1
2
3
4
5
6
7
8
9
unit MonUnit;
 
interface
 
procedure getHour; external 'Project_DLL_source.dll' name 'getTimeHour';
 
implementation
 
end.

Ensuite, dans ton application, tu pourras mettre MonUnit dans tes uses et appeller getTimeHour à ton aise.

Bon dev!

[slimjoe]

non justement, j'ai une DLL qui permet d'utiliser les REGEXP PERL dans Delphi et il suffit de definir le nom de la DLL dans la clause use grace a ce fichier .dcu ... comme ca je n'ai pas besoin d'indiquer les procedures a utiliser, c'est tres pratique !

Salut!

Encore une fois, je ne suis pas 100% certain, mais je crois que pour créer le dcu, ça prend la source. Pis encore, si tu as la source et que tu l'inclus dans ton projet, tu n'auras plus besoin de la DLL.

Mais là, plus je lis ce post, moins je suis certain de comprendre alors je suis probablement à côté de mes souliers...

Mais je reste à l'écoute. Ça m'intéresse .

[Lorenzo77]

je vais detailler un peu plus :

j'ai créés 2 projets dans le meme repertoire pour ne pas avoir des problemes avec les chemins.

1er projet : Project_DLL_source qui est juste un test pour voir comment creer une DLL
2eme projet : Project_appelDLL un autre projet dans lequel je veux utiliser les 2 procedures de ma DLL.


le but est d'arriver a utiliser le code de la DLL de la maniere la plus simple possible :
-donc avoir la DLL dans le meme repertoire que le projet qui doit l'utiliser
-declarer son nom dans la clause use afin de ne pas avoir a indiquer une par une toutes les procedures de la DLL que j'aurai envie d'utiliser dans mon projet .... mais pour ca j'ai besoin du fichier dcu

hors avec le pojet de la DLL voici tous les fichiers que j'ai :
Project_DLL_source.cfg
Project_DLL_source.dll
Project_DLL_source.dof
Project_DLL_source.dpr
Project_DLL_source.res

pas de .dcu, pas de .pas


-------------
Attention : ce n'est peut etre pas logique au niveua programmation ce que je veux faire, c'est juste un test

[Lorenzo77]

personne ne sait comment faire pour creer un fichier .dcu lors de la compilation d'une DLL ?

[slimjoe]

Salut!

Si ce que tu veux faire, c'est avoir 2 projets et utiliser des sources communes aux 2 projets tu dois donc sortir le code du fichier Project_DLL_source.dpr et le mettre dans un autre unit uProject_DLL_source.pas. Dans ton 2e projet, tu pourras y ajouter ce unit, le mettre dans tes uses et utiliser ses méthodes.

Mais tout ça n'a AUCUN rapport avec la création des DLL. Une bibliothèque sert à stocker des méthodes qui sont utilisées par plusieurs applications simultanément. Si tu fais ce que j'ai décrit plus haut, tu DOUBLES le code de tes méthodes (elles vont être compilées dans tes 2 projets au lieu de l'être uniquement dans la DLL et accédées par la 2e application). Aussi, si tu changes le code dans le projet 1 et que tu ne recompile pas le projet 2, tes méthodes vont donner des résultats différents.

personne ne sait comment faire pour creer un fichier .dcu lors de la compilation d'une DLL ?

Oui : pour créer un .dcu, tu dois compiler un .pas.

Si le .pas est dans ton projet, Delphi va le compiler, faire un .dcu et lier les .dcu pour faire un .exe. Si Delphi ne trouve pas le .dcu, c'est parce qu'il ne trouve pas la source et il ne sait pas quoi compiler quand tu lui parles de nomDeMaDLL.

[Lorenzo77]

voici tousles fichiers que j'ai :
Project_DLL_source.cfg
Project_DLL_source.dll
Project_DLL_source.dof
Project_DLL_source.dpr
Project_DLL_source.res

comme je l'indiquais precedemment, ni de .dcu ni de .pas


pourtant j'ai bien commencé un nouveau projet dans delphi 7 pour creer ma DLL en selectionnant Expert DLL.
je comprends pas ou j'ai merdouillé

[slimjoe]

voici tousles fichiers que j'ai :
Project_DLL_source.cfg
Project_DLL_source.dll
Project_DLL_source.dof
Project_DLL_source.dpr
Project_DLL_source.res

comme je l'indiquais precedemment, ni de .dcu ni de .pas


pourtant j'ai bien commencé un nouveau projet dans delphi 7 pour creer ma DLL en selectionnant Expert DLL.
je comprends pas ou j'ai merdouillé

Tu n'a pas merdouillé. C'est juste que l'assistant de Delphi est, disons, très peu d'assistance .

Si tu veux que je t'aide, j'aurai besoin de savoir une chose : est-ce que que tu veux réutiliser le code d'un projet dans un autre (et ainsi dupliquer le même code) ou est-ce que tu veux accéder, à l'exécution, aux méthode d'une DLL compilée ?

Merci!

[Lorenzo77]

accéder, à l'exécution, aux méthode d'une DLL compilée !

mais sans passer par des declarations interminables :
procedure getHour; external 'Project_DLL_source.dll' name 'getTimeHour';
imaginons que j'ai 50 procedures dans ma DLL ca risque de faire legerement crade dans le projet qui l'utilise


merci !

[slimjoe]

accéder, à l'exécution, aux méthode d'une DLL compilée !

mais sans passer par des declarations interminables :
procedure getHour; external 'Project_DLL_source.dll' name 'getTimeHour';
imaginons que j'ai 50 procedures dans ma DLL ca risque de faire legerement crade dans le projet qui l'utilise


merci !

Ben...
À moins qu'il existe un moyen dont j'ignore l'existance, tu dois toujours déclarer ce que tu veux utiliser. C'est d'ailleurs comme ça que Delphi te permet d'avoir des listes déroulantes.

Si tu regardes le unit Windows ou ShellAPI par exemple, chaque méthode de l'API interfacée est déclarée. Et y'en a beaucoup plus que 50!

Tu peux toujours, via LoadLibrary, charger les méthodes dont tu as besoin au fur et à mesure.

Mais chose certaine, si tu trouve le moyen d'ajouter le .pas à ton projet (ou le .dcu une fois compilé), ce n'est pas ta DLL qui sera utilisée mais le code contenu dans le .pas/.dcu. Si jamais ça t'arrive fais le test : supprime la DLL. Tu vas voir, le programme va quand même fonctionner!

Bon dev!

[Lorenzo77]

ben justement, je viens de voir ca dans le bouquin, ce LoadLibrary a l'air interessant meme si un peu plus compliqué a mettre en oeuvre.

j'ai testé justement ce que tu as dis concernant la DLL et DCU, j'ai fait un projet ou je testais les possibilités des PCRE PERL en delphi et ou j'utilisais cette DLL et fichier annexe :
(PCRE 6.1 DLL) http://www.renatomancuso.com/software/dpcre/dpcre.htm

des que je vire la DLL j'ai une erreur !
voici les fichiers qui vont avec la DLL quand je la telecharge sur le site :
pcre.dll
PCRE.pas
pcre_dll.pas

par contre quand je compile le projet delphi me rajoute 2 DCU :
pcre.dcu
pcre.dll
pcre.pas
pcre_dll.dcu
pcre_dll.pas

donc il est bien capable de les creer, mais comme tu dis il faut le .PAS hors en faisant EXPERT DLL j'ai pas l'impression que ca soit la bonne soluce ... a voir.

[Laurent Dardenne]

Salut,

mais sans passer par des declarations interminables :

procedure getHour; external 'Project_DLL_source.dll' name 'getTimeHour';

Il n'y a pas d'autre approche possible, c'est dû au système.
Regarde le code source de l'unité Windows, elle contient principalement des déclarations de fonctions DLL.

imaginons que j'ai 50 procedures dans ma DLL ca risque de faire legerement crade dans le projet qui l'utilise

Tu peux déporter le code d'appel dans une unité dédiée.

[Eric Sigoillot]

Tu n'as pas l'air de maîtriser le concept de DLL...
DLL signifie "Dynamic Link Library", autrement dit Bibliothèque à Liaison Dynamique. Les fonctions contenues dans la DLL sont chargées dynamiquement, c'est à dire à l'exécution. De fait, lorsque l'on utilise une DLL, il est posible de modifier la DLL sans avoir à toucher le programme qui l'utilise.

Toi, tu souhaites utiliser cette DLL en utilisant uses. Uses va créer un lien statique entre ton programme et le code source que tu inclus avec uses. Si tu retouches l'unité, alors il faudra recompiler tout le programme.

Tu as été induit en erreur par ta bibliothèque Perl. Tu disposes d'une fichier PCRE.DLL et d'un fichier PCRE.PAS. Mais ! PArce qu'il y a un mais... PCRE.PAS ne contient pas le code source de PCRE.DLL. La DLL a été créée avec un code source en C, compilé ailleurs. On te donne également PCRE.PAS qui contient les appels vers les fonctions de la DLL (les déclarations avec external, etc.) qui, après compilation, te donne un fichier PCRE.DCU, qui correspond à l'unité compilée.

Fais l'essai : renomme ta DLL en PCRE_.DLL et modifie les appels dans PCRE.PAS. Tu te rendras compte à la compilation que ta DLL n'aura pas changé. Et tu n'auras aucun fichier PCRE_.DCU.

Pour finir de t'en convaincre, regarde l'unité OpenGL. Dans les sources, tu auras OpenGL.pas, qui après compilation donnera OpenGL.dcu. Mais ça ne crée pas OpenGL.dll !

Conclusion : tu fais erreur sur toute la ligne et tu ne comprends pas le principe des DLL. Renseigne-toi sur les DLL pour voir à quoi elles servent et comment s'en servir dans ton programme Delphi.

@++

[Hauwke]

Bonjour,
@Lorenzo77
Outre le fait que je suis d'accord à 100% avec nos collégues sur le fait qu'il vous faut étudier les principes fondamentaux de fonctionnement des Dlls, je pense qu'il éxiste une solution hybride susceptible de satisfaire les différentes parties de cette file de discussion.
Il suffit d'établir la liste des fonctions exportées par la Dll au runtime, de vérifier que la fonction que l'on cherche existe bel et bien et de l'appeler. Afin de vous en convaincre, je vous donne un bout de code qui établit une liste des fonctions d'une Dll prise sur le disque:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
unit ImageHlp;
const 
IMAGE_SIZEOF_SHORT_NAME            = 8; 
IMAGE_NUMBEROF_DIRECTORY_ENTRIES   = 16; 

  IMAGE_DATA_DIRECTORY = packed record 
    VirtualAddress  : DWORD; 
    Size            : DWORD; 
  PIMAGE_DATA_DIRECTORY = ^IMAGE_DATA_DIRECTORY; 

IMAGE_SECTION_HEADER = packed record 
    Name     : packed array [0..IMAGE_SIZEOF_SHORT_NAME-1] of Char; 
    PhysicalAddress : DWORD; // or VirtualSize (union); 
    VirtualAddress  : DWORD; 
    SizeOfRawData   : DWORD; 
    PointerToRawData : DWORD; 
    PointerToRelocations : DWORD; 
    PointerToLinenumbers : DWORD; 
    NumberOfRelocations : WORD; 
    NumberOfLinenumbers : WORD; 
    Characteristics : DWORD; 
  end; 
  PIMAGE_SECTION_HEADER = ^IMAGE_SECTION_HEADER; 

  IMAGE_OPTIONAL_HEADER = packed record 
   { Standard fields. } 
    Magic           : WORD; 
    MajorLinkerVersion : Byte; 
    MinorLinkerVersion : Byte; 
    SizeOfCode      : DWORD; 
    SizeOfInitializedData : DWORD; 
    SizeOfUninitializedData : DWORD; 
    AddressOfEntryPoint : DWORD; 
    BaseOfCode      : DWORD; 
    BaseOfData      : DWORD; 
   { NT additional fields. } 
    ImageBase       : DWORD; 
    SectionAlignment : DWORD; 
    FileAlignment   : DWORD; 
    MajorOperatingSystemVersion : WORD; 
    MinorOperatingSystemVersion : WORD; 
    MajorImageVersion : WORD; 
    MinorImageVersion : WORD; 
    MajorSubsystemVersion : WORD; 
    MinorSubsystemVersion : WORD; 
    Reserved1       : DWORD; 
    SizeOfImage     : DWORD; 
    SizeOfHeaders   : DWORD; 
    CheckSum        : DWORD; 
    Subsystem       : WORD; 
    DllCharacteristics : WORD; 
    SizeOfStackReserve : DWORD; 
    SizeOfStackCommit : DWORD; 
    SizeOfHeapReserve : DWORD; 
    SizeOfHeapCommit : DWORD; 
    LoaderFlags     : DWORD; 
    NumberOfRvaAndSizes : DWORD; 
    DataDirectory: packed array[0..IMAGE_NUMBEROF_DIRECTORY_ENTRIES-1] of IMAGE_DATA_DIRECTORY; 
  end; 
  PIMAGE_OPTIONAL_HEADER = ^IMAGE_OPTIONAL_HEADER; 

IMAGE_FILE_HEADER = packed record 
    Machine              : WORD; 
    NumberOfSections     : WORD; 
    TimeDateStamp        : DWORD; 
    PointerToSymbolTable : DWORD; 
    NumberOfSymbols      : DWORD; 
    SizeOfOptionalHeader : WORD; 
    Characteristics      : WORD; 
  end; 
  PIMAGE_FILE_HEADER = ^IMAGE_FILE_HEADER; 

IMAGE_NT_HEADERS = packed record 
  Signature       : DWORD; 
  FileHeader      : IMAGE_FILE_HEADER; 
  OptionalHeader  : IMAGE_OPTIONAL_HEADER; 
end; 
PIMAGE_NT_HEADERS = ^IMAGE_NT_HEADERS; 

type LOADED_IMAGE = record 
  ModuleName:pchar;//Nom du module  
 hFile:thandle;//handle du fichier
  MappedAddress:pchar;// l'adresse de base du fichier mappé
 FileHeader:PIMAGE_NT_HEADERS;//Header du fichier. 
  LastRvaSection:PIMAGE_SECTION_HEADER; 
  NumberOfSections:integer; 
  Sections:PIMAGE_SECTION_HEADER ; 
  Characteristics:integer; 
  fSystemImage:boolean; 
  fDOSImage:boolean; 
  Links:LIST_ENTRY; 
  SizeOfImage:integer; 
end; 
PLOADED_IMAGE= ^LOADED_IMAGE;

Le code de l'unité:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
unit Unit1; 

interface 

uses 
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, 
  StdCtrls, Menus,structures,imagehlp; 

type 
  TForm1 = class(TForm) 
    ListBox1: TListBox; 
    MainMenu1: TMainMenu; 
    File1: TMenuItem; 
    Open1: TMenuItem; 
    OpenDialog1: TOpenDialog; 
    ListBox2: TListBox; 
    procedure Open1Click(Sender: TObject); 
  private 
  public 
   procedure DLLFuncstoList(fname:string;alistbox:tlistbox); 
  end; 

var 
  Form1: TForm1; 
implementation 

{$R *.DFM} 


procedure TForm1.DLLFuncstoList(fname:string;alistbox:tlistbox); 
var 
  fih:LOADED_IMAGE; 
  pexpdir:PIMAGE_EXPORT_DIRECTORY; 
  pexpnames:pdword;//pointer sur la liste des fonctions exportées
  pt1:PImageSectionHeader; 
  i:integer; 
  exportedfuncname:pchar;//Nom de la fonction exportée
begin 
   alistbox.items.clear; 
   pt1:=nil; 
   MapAndLoad(pchar(fname),pchar('#0'),@fih,true,true);//Charge le fichier en mémoire. 
   pExpDir:=PIMAGE_EXPORT_DIRECTORY(fih.FileHeader.OptionalHeader. 
                                    DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress); 
   pExpDir:=PIMAGE_EXPORT_DIRECTORY(ImageRvaToVa 
         (fih.FileHeader,fih.MappedAddress,DWORD(pExpDir),pt1)); 
   pExpNames:= pExpDir.pAddressOfNames; 
   pExpNames:=PDWORD(ImageRvaToVa 
       (fih.FileHeader,fih.MappedAddress,dword(pExpNames),pt1)); 
   pt1:=nil; 
   for i:=0 to pexpdir.NumberOfNames-1 do 
    begin 
     exportedfuncname:=pchar(ImageRvaToVa   
       (fih.FileHeader,fih.MappedAddress,dword(pExpNames^),pt1)); 
     alistbox.items.add(exportedfuncname); 
     inc(pexpnames); 
    end; 
   UnMapAndLoad(@fih);//Décharge le fichier de la mémoire. end; 

procedure TForm1.Open1Click(Sender: TObject); 
var 
begin 
if opendialog1.execute = true then 
  begin 
   DLLFuncstoList(opendialog1.filename,listbox1); 
  end; 
end; 
end.

Bon test et bon courage
Cordialement,
Hauwke

[Laurent Dardenne]

Une derniére pour la route
Les tutoriels sur les DLL en Delphi
http://delphi.developpez.com/cours/?dom=DLL

[Lorenzo77]

merci, j'ai vraiment du mal avec cette obligation de redefinir dans les projets les procedure a utiliser des DLL
je trouve ca redondant ....


imaginons que je veux faire une classe Y qui va me servir dans X projets, est il preferable de la mettre dans une DLL ou de la laisser dans un PAS ?

[Hauwke]

merci, j'ai vraiment du mal avec cette obligation de redefinir dans les projets les procedure a utiliser des DLL
je trouve ca redondant ....


imaginons que je veux faire une classe Y qui va me servir dans X projets, est il preferable de la mettre dans une DLL ou de la laisser dans un PAS ?

Décidément, votre pinguoin, charmant au demeurant, n'a pas pour vous l'usage d'une muse car il aurait pu vous inspirer...
Il aurait pu vous dire:
"-Imaginons que l'on dispose d'un bout de code capable de lire les fonctions exportées par une Dll à la volée et compte tenu du fait que l'un des tutos conseillés par Laurent Dardenne donne le code d'une procédure qui se nomme "lierfct()" alors on pourrait imaginer une liaison dynamique des méthodes d'une Dll quasiment au runtime..."
Vous devriez écouter votre pinguoin, il semble de bon conseil...
Cordialement,
Hauwke