j'ai trouvé une dll

Bonsoir à tous,   
En fouillant sur internet j'ai trouvé qu'avec une api Windows on pouvait extraire des fonctions dll. Comme je commence à explorer un peu ce monde complexe et que dernièrement quelqu'un désirait chronométrer l'exécution d'un programme ou d'une sub, voici ce que j'ai réussi à faire:

Code:

' GetTickCount retourne le nombre de millisecondes écoulées depuis
' le démarrage de windows. J'ai trouvé son utilisation simple!
dim start%,stop%,i
dll_on "kernel32.dll"
start%=dll_call0("GetTickCount")
for i=1 to 50000
next i
stop%=dll_call0("GetTickCount")
message str$(stop%-start%)+" millisecondes"
dll_off

et un début de chronomètre:

Code:

label start,stopp,go
dim t,start%,stop%
alpha 1:caption 1,"0"
dll_on "kernel32.dll"
button 2:top 2,30:caption 2,"start":on_click 2,start
button 3:top 3,60:caption 3,"stop" :on_click 3,stopp

timer 5:timer_interval 5,1:on_timer 5,go:timer_off 5
end

go:
timer_off 5
stop%=dll_call0("GetTickCount")
t=stop%-start%
caption 1,str$(int(t/1000))+" secondes"
timer_on 5
return

start:
start%=dll_call0("GetTickCount"):timer_on 5
return

stopp:
dll_off:timer_off 5:inactive 2:inactive 3
return

En espérant avoir été utile, A+    

Erreur de page. Désolé.

Tu as raison, Bignono. La commande DLL_ON peut charger en fait n'importe quelle DLL, même celles de Windows comme user32.dll. C'est très intéressant pour celui qui cherche un peu à approfondir le système.

Mais on se heurte très vite au passage des paramètres? En effet, les fonctions Panoramic DLL_CALLx ne passent que des paramètres en format INTEGER, et uniquement en valeur. Pas par adresse pour avoir des paramètres en sortie, pas de passage de flottants ou de chaînes de caractères, pas de passage de tableaux, sans même parler des types de données plus exotiques qui sont parfois demandés par certaines fonctions système, comme des pointeurs sur des structures particulières etc.


Et c'est ici qu'une interface par une DLL intermédiaire devient indispensable. C'est en partie à ça que sert KGF.dll, ou les DLLs que j'ai faites pour gérer les cartes de robotique comme la carte Arduino. On eppelle bien des fonctions mises à disposition dans une DLL tierce, mais non appelable directement par Panoramic.

Donc, tant qu'on peut appeler une fonction directement par Panoramic, tant mieux: allez-y, ce sera utile et intéressant. Mais malheureusement, tant que l'interface mis à disposition par les fonctions DLL_CALLx n'évolue pas, ça ne va pas bien loin...

Bonjour Klaus,   
Oui tu as tout à fait raison, on ne peut pas exploiter cet immense réservoir de fonctions des api résidents dans Windows avec dll_callx, trop de restrictions. GDI.dll, user32.dll, kernel32;dll etc.. contiennent des centaines de fonctions plus interressantes les unes que les autres. Gestion de disque, de fichier, graphiques, horloge, système, etc...
Maintenant je me rend compte de l'énorme travail que tu fournis avec KGF.dll afin de rendre compatible avec Panoramic certaines de ces fonctions par ton interface.
Si les fonctions dll de Panoramic pouvaient accepter les flottants et les chaines de caractères ce serait déjà une avancée formidable de Panoramic!
A+    

bignono a écrit:

Si les fonctions dll de Panoramic pouvaient accepter les flottants et les chaines de caractères ce serait déjà une avancée formidable de Panoramic!

Elles le font déjà !

Voici un exemple tiré de ma calculatrice PANOCALC :

Fonction de la DLL (en FreeBASIC) :

Code:

function Evaluate(byref Expression as zstring ptr, _
                  byref Result     as double) as integer export

Appel depuis un SUB de Panoramic :

Code:

sub Eval(Expression$)
  Eval_Code% = dll_call2("Evaluate", adr(Expression$), adr(Eval_Result))
end_sub

D'une façon générale, il faut :

- Dans la DLL :

 * passer un flottant par référence

 * passer une chaîne de caractère sous forme de pointeur sur une chaîne à zéro terminal, ce pointeur étant lui-même passé par référence (pointeur sur un pointeur, donc)
 
- Dans le programme Panoramic :

 * appeler la fonction de DLL en lui passant les adresses des flottants et des chaînes de caractères (fonction adr)
 
 * les chaînes de caractères doivent être dimensionnées à une taille suffisante dans le programme appelant.

Je pense qu'un article sur les DLL dans le magazine ne serait pas superflu

Bonjour.

Jean-Debord, comment utilise-t-on l'appel de cette DLL ?

Car le code suivant ne fonctionne pas.

Merci.

Code:

' GetTickCount retourne le nombre de millisecondes écoulées depuis
' le démarrage de windows.

dim start%,stop%,i
dim Eval_Result, Eval_Code%
dim Expression$
Expression$="2+3"
Eval_Result=0

dll_on "kernel32.dll"

start%=dll_call0("GetTickCount")

for i=1 to 100000
next i

stop%=dll_call0("GetTickCount")

message str$(stop%-start%)+" millisecondes"

Eval_Code% = dll_call2("Evaluate", adr(Expression$), adr(Eval_Result))

dll_off

Il faut récupérer l'archive panocalc.zip qui se trouve ici :

http://sourceforge.net/projects/panolib/files/panocalc.zip

Il y a une DLL spécifique : eval.dll

Tout est expliqué dans la documentation, ainsi que dans mon article "Une calculatrice pour Panoramic" (PLM n° 3)

@Bignono et Jean-debord:
Je fais la même chose avec KGF.dll. Il faut passer l'adresse de la variable, et traiter cette adresse dans la DLL afin d'en faire quelque chose. Mais c'est tout à fait différent du passage d'une variable directement, ou d'un tableau, etc. De plus, la convention d'appel est systématiquement STDCALL - d'autres conventions ne sont pas supportées.

Il faudrait pouvoir déclarer une sorte de "template" pour une fonction DLL, quitte à inclure tous les template nécessaires dans un fichier #INCLUDE. Cela pourrait prendre la forme suivante:

Code:

FOREIGN UneFonction(convention param:type[,...]) in MaDll as MaFonction

avec:
convention = REF | VAL | CONST VAL
type = INT | WORD | BYTE | BOOLEAN | STRING | ...
sachant que WORD, BYTE et BOOLEAN seront des valeurs entières (variables %) en Panoramic
On pourrait ainsi appeler MaFonction avec ses paramètres, et ce serait UneFonction dans MaDll qui serait appelée.

Mais je pense qu'on sort là de l'objectif de simplicité de Panoramic.

Bon, ça ne sert pas à grand chose puisque l'on peut faire la même chose avec les commandes de Panoramic, mais c'est pour moi, afin d'essayer de comprendre comment tout cela fonctionne.

Code:

label liste,ici
dim res%,handle%
button 1:caption 1,"Fermer la liste":on_click 1,liste
button 2:top 2,30:caption 2,"Fermer ici":on_click 2,ici
form 3:left 3,left(0)+width(0)
command_target_is 3
list 4:width 4,150
item_add 4,"******************"
item_add 4,"**  TOP SCORES  **"
item_add 4,"******************"
item_add 4,"1- JOJO... 853 pts"
item_add 4,"2- BIJOU.. 802 pts"
item_add 4,"3- POK.... 722 pts"
item_add 4,"4- RATON.. 608 pts"
item_add 4,"5- WOLF... 601 pts"

dll_on "User32.dll"
end

liste:
handle%=handle(4)
res%=dll_call1("DestroyWindow",handle%)
return

ici:
handle%=handle(3)
res%=dll_call1("DestroyWindow",handle%)
return

Klaus, j'ai vu que dans shell32.dll et user32.dll il y a des commandes pour les icones, mais mes essais demeurent des échecs.
on a "ExtractIcon" dans shell32.dll et "DrawIcon" dans user32.dll
Ce que je n'arrive pas encore à saisir c'est les paramètres, par exemple ce qu'on entend par HINSTANCE ou type LPCTSTR ou UINT, etc...
Si tu peux éclairer un peu ma lanterne...
A+    

CE sont des types de données du langage C, et non reproductibles directement par des données Panoramic. On peut y arriver (et on en revient toujours à ça) par une DLL d'interface en Delphi (et certainement eb FreeBasic aussi). D'ailleurs, pour ces fonction d'extraction d'icônes, je les ai rendues accessibles dans KGF.dll. Voici le code Delphi, pour info:

Code:

function ExtractIconFromFile(pexeFilename,picoOutFileName:pstring;icoSize:Integer):integer; stdcall; export;
const
{$ifdef UNICODE}
 ExtractProcName='PrivateExtractIconsW';
{$else}
 ExtractProcName='PrivateExtractIconsA';
{$endif}
type
  TExtractFunc = function(lpszFile: PChar; nIconIndex, cxIcon, cyIcon: integer; phicon: PHANDLE; piconid: PDWORD; nicon, flags: DWORD): DWORD; stdcall;
var
  exeFilename,icoOutFileName: string;
  hIcon  : THandle;
  nIconId : DWORD;
  Icon    : TIcon;
  PrivateExtractIcons:TExtractFunc;
  hUserDll    : THandle;
begin
  result := 1;
  if (hUserDll<4) then begin
    hUserDll := LoadLibrary('user32.dll');
    if (hUserDll<4) then exit;
  end;
  exeFilename := pexeFilename^;
  icoOutFileName := picoOutFileName^;
    { PrivateExtractIcons:
        MSDN documentation says that this function could go away in a future windows
        version, so we must try to load it, and if it fails, return false, rather than
        doing a static DLL import.
    }
    PrivateExtractIcons :=    GetProcAddress(hUserDll, ExtractProcName);

    if not Assigned(PrivateExtractIcons) then exit;

    //extract a icoSize x icoSize  icon where icoSize is one of 256,128,64,48,32,16
    if PrivateExtractIcons ( PChar(exeFilename),
                            0, icoSize, icoSize, @hIcon, @nIconId, 1, LR_LOADFROMFILE) <>0 then
    try
      Icon:=TIcon.Create;
      try
        Icon.Handle:=hIcon;
        Icon.SaveToFile(icoOutFileName);
        result := 0;
      finally
        Icon.Free;
      end;
    finally
      DestroyIcon (hIcon);
    end;
end ;

function ExtractIconFromLNK(srcPath, dstPath: pString; path: integer):integer; stdcall; export;    // KGF64
var
  lnk, dst : string;
  Iico : WORD;
  hic : hicon;
  ico: TIcon;
  pth: string;
  pp: pointer;
begin {0}
  result := 0;
  try
    lnk :=  srcPath^;
    dst :=  dstPath^;
    Iico := 0;
    ico := TIcon.Create;
    hic := extractassociatedicon(Hinstance,pchar(lnk),Iico);
    ico.Handle := hic;
    ico.SaveToFile(dst);
    if rightstr(lnk,4)='.lnk' then pth := GetShellLink(lnk)
                              else pth := lnk;
    pp := @pth;
    CopyTextToPanoramic(integer(pp),0,path);
    result := ico.Height;
  finally
    ico.Free;
  end;
end; {0}

Un Hinstance, c'est une forme particulière de handle. Un handle n'est rien d'autre qu'une valeur integer (32 bits sur les systèmes 32 bits, 64 pour les autres). Et cette valeur est utilisée par le système comme un "indice" dans une des multiples tables internes du système. Un handle n'a donc une valeur que pour un contexte donné, et utilisé en-dehors de ce contexte, il est au mieux inopérent, mais produit plus volontiers des crashs spectaculaires.

Le mot "instance" signifie une entité dynamique créée à partir dun modèle, une catégorie. Un exemple bête mais parlant: si tu lances NotePad avec un fichier texte dedans, tu as une première "instance" de Notepad. Tu en lances un autre, tu as une deuxième "instance". Chacune a son handle. Maintenant, ce qui est vrai pour un exemple aussi basique, l'est également pour des notions beaucoup plus abstraites. En réalité, tous les objets que Windows gère, sont des instances dynamiques de modèles, souvent nommée "classes" (ça rappelle quelque chose aux familiers de C, j'en suis sûr). Et chacune de ces instances a son handle.

Des handles, il y en a des milliers, des dizaines de milliers à chaque instant, dans un système en cours d'exécution. Et ils sont créés et disparaissent constamment, souvent très rapidement. En plus, pour un même objet, il peut y avoir plusieurs handle, car un objet est souvent composé de plusieurs objets imbriqués les uns dans les autres, à la manière des poupées russes? Un exemple très simple: prenons une fenêtre Windows. Cela peut être une form dans le sens Panoramic, mais également un memo, une boite de dialogue, etc. Chacun de ces objets a son handle, bisn sûr. C'est son "instance". Mais en général, il a un autre handle: le handle de son canvas. on peut se représenter le canvas comme une feulle blanche sur laquelle un dessine littéralement la représentation graphique de l'objet, et qui est donc physiquement et logiquement distincte de l'objet lui-même. Ainsi, une form a un canvas sur lequel on peut faire un PRINT (on commence à comprendre pourquoi le print sur une form pose problème ?). C'est l'objet lui-même, dans notre exemple la form, qui est resposable de redessiner son propre canvas à chaque fois que cela devient nécessaire. La form le fait via le handle de son canvas. Or, un programmeur peut détourner ce mécanisme et dessiner directement sur le canvas (c'est ce que fait la commande print...). Donc, la form ne le sait pas, et n'a aucun moyen de savoir ce qu'il faut redessiner. Mais ce concept est ancré beaucoup plus provondément dans Windows. Tous les objets Windows vivibles ayant un handle d'instance, ont également un handle canvas. Une ListBoc, une Combo, un Memo, ... Tous. Et même si Panoramic ne donne pas accès à tous ces handles (et c'est heureux), dans d'autres langages on peut le faire. On peut ainsi assez facilement avoir un objet LIST où une ligne sur deux a une couleur de fond différent, genre papier listing bistré. Pour cela, tous ces objets ont entre autres un évènement ON_DRAW qui est appelé par Windows lorsque l'objet doit être redessiné. Et si l'on a implémenté des particularités non standard comme un fond bistré pour un objet list, c'est dans cette routine évènemen t qu'il faut l'appliquer. A l'évidence, c'est ce que l'objet form de Panoramic ne fait pas, concernant les print et autres fonctions 2d_xxx sur le canvas de la form 0.

Bon, j'ai été beaucoup plus bavard que je n'avais prévu. Tant pis. Ou tant mieux, c'est selon. Ces fonctionnalités internes du système, c'est ce qui me passionne. Donc, il ne fallait pas me lancer sur ce sujet, ou alors gare à la lecture !

Salut Klaus.

Klaus a écrit:

Bon, j'ai été beaucoup plus bavard que je n'avais prévu. Tant pis. Ou tant mieux, c'est selon. Ces fonctionnalités internes du système, c'est ce qui me passionne. Donc, il ne fallait pas me lancer sur ce sujet, ou alors gare à la lecture !

C’est un peu plus clair dans ma tête, maintenant, et ce grâce à toi.
Je te propose de confectionner un bon tutoriel sur ce sujet  (et sur d’autres sujets que tu juges intéressants)  qui aura (auront) sa (leur) place sur Le Mag.

C'est une idée. Je verrai ça à l'occasion.

Pour le moment, en-dehors de mes réponses aux questions ou problèmes techniques des uns et des autres, en-dehors de mon travail sur KGF.dll y compris la poursuite de la traduction en anglais - je suis sur un énorme projet. En effet, maintenant, KGF.dll contient, en-dehors des fonctions que j'ai réalisée en réaction aux besoins des Panoramiciens, toutes les fonctions dont j'ai besoin pour mes progres programmes. Et cela concerne particulièrement la gestion des fichiers binaires avec la gestion des enregistrements de longueur fixe composés de zones, ainsi que la gestion des fichiers chaînés qui est très puissante. Et avec cela, je suis en train de réécrire en Panoramic un logiciel de gestion de paie que j'avais réalisée il y a près de 30 ans et qui a tourné pendant 23 ans dans quelques centaines d'entreprises de nature très diverse. Malheureusement, ce logiciel, pour performant et souple qu'il était, était conçu initialement sur des systèmes Digital Equipment sous RT11, puis VAX/VMS, et ce n'est absolument pas compatible Windows. Je m'avais porté en version DOS sous Windows V3.1, puis Windows Xp toujours en mode DOS. Mais aujourd'hui, on attend autre chose d'un logiciel de gestion moderne. Je reprends donc tout (environ 430 fichiers sources pour près de 2,3 Mo de sources sur disque) pour le réécrire en Panoramic. Le gros handicap, c'était l'absence de gestion de fichiers digne de ce nom. Et j'y ai pallié avec les fonctions citées ci-dessus. Et le déclic était l'implémentation des SUB par Jack - c'était la condition siné qua non.

Le projet avance rapidement, et j'aurai bientôt un truc à montrer: la gestion complète de tous les fichiers de base, avec l'ensemble des paramétrages, et ils sont légion. Suivront les calculs proprement-dits, les éditions diverses et variées, divers outils. Tiens, voici la capture d'écran du menu principal:


Voici le menu de maintenance des fichiers de base:


Et voici un exemple de saisie de données. C'est l'écran de la création d'une grille d'un compsant de salaire, pour ceux qui sont payés selon une grille tarifaire:


Tu vois, je n'ai pas le temps de m'ennuyer.

Heureux soit celui qui, comme Klaus, n’a pas le temps de s’ennuyer !      

Bonjour Klaus    et grand merci pour tes explications. Je te souhaite de mener à bien ton projet de logiciel de gestion.
Comme Papydall, je pense qu'un tutoriel sur ce sujet pour le mag serait le bienvenu. Mais c'est à toi de voir, car KGF et ton logiciel t'occupent déjà à plein temps...
A+ et bon courage       

Wouah, beau projet Klaus. Bon courage

Pour ceux qui veulent s'initier aux DLLs, voici un petit résumé que j'avais fait il y a déjà pas mal de temps, essentiellement sur la base des informations données par Klaus et par D. J. Peters. Il pourrait faire la base d'un futur article ...

=============================
Règles d'utilisation des DLLs
=============================

1. La DLL est chargée en mémoire par l'instruction dll_on "xxx.dll", où xxx.dll est le nom de la bibliothèque.

Quand la DLL n'est plus nécessaire, la mémoire peut être libérée par l'instruction dll_off

2. La syntaxe d'appel d'une fonction de DLL est de la forme :

Code:

result% = dll_calln("DllFunctionName", par1%, ..., parn%)

où n est un entier de 0 à 6 qui représente le nombre de paramètres passés à la fonction. Il y a en fait 7 routines différentes :

Code:

dll_call0("DllFunctionName")
dll_call1("DllFunctionName", par1%)
dll_call2("DllFunctionName", par1%, par2%)
..........................................

Le premier paramètre est une chaîne contenant le nom de la fonction appelée. Il est suivi par les paramètres de la fonction, qui sont obligatoirement de type entier.

Notez aussi que :

* PANORAMIC ne peut appeler que des fonctions dans une DLL, pas de sous-programmes.

* Toute fonction appelée par dll_call doit retourner une valeur entière.

3. Par défaut, tous les paramètres sont passés par valeur. Si la fonction requiert un paramètre passé par référence, il faut utiliser la fonction adr() de PANORAMIC. Cette fonction s'applique aux variables simples de type entier, réel ou chaîne de caractères. Dans ce dernier cas cependant, le paramètre de la fonction appelée doit être un pointeur sur une chaîne à zèro terminal.

4. Les chaînes de caractères passées aux fonctions de la DLL doivent être dimensionnées à une longueur suffisante dans le programme appelant. C'est particulièrement important si la chaîne est modifiée par la DLL, car alors sa longueur peut varier.

5. Au stade actuel du développement de PANORAMIC, aucun tableau ne peut être passè, ni par valeur ni par référence avec adr().

6. L'appel des fonctions doit se faire selon la convention stdcall.

7. Le nom de la fonction appelée ("DllFunctionName") doit respecter les majuscules et les minuscules.

Si l'on prend l'exemple d'une DLL nommée fbdll.dll et écrite en FreeBASIC, la syntaxe pourrait être la suivante :

Code:

 extern "Windows-MS"

 function IntFunc(n as integer) as integer export
 ' fonction à paramètre entier
   ..............
 end function
 
 function RealFunc(byref x as double) as integer export
 ' fonction à paramètre réel (double précision)
   ..............
 end function
   
 function StrFunc(byref p as zstring ptr) as integer export
 ' fonction à paramètre chaîne de caractère
   ..............
 end function
 
 end extern

* La directive export indique que les fonctions de la DLL doivent être exportées, et donc transmises à PANORAMIC.

* Les fonctions sont incluses dans un bloc (extern "Windows-MS" … end extern) afin d'éviter que leurs noms ne soient modifiés durant l'exportation ("name mangling")

* Nous n'avons pas spécifié la convention stdcall car c'est la convention par défaut en FreeBASIC.

L'appel de ces fonctions par PANORAMIC se ferait de la manière suivante :

Code:

 dim n%, x, s$, result%

 ' Penser à dimensionner les chaînes de caractères !!
 s$ = string$(100, "  ")

 dll_on "fbdll.dll"

 result% = dll_call1("IntFunc", n%)
 result% = dll_call1("RealFunc", adr(x))
 result% = dll_call1("StrFunc", adr(s$))

 dll_off

Merci beaucoup JeanDebord pour ces précisions.

Je veux savoir.
Qui peut m’aider ?
Je souhaite tester les fonctions de la Gdi32.dll.
A la fonction Rectangle, il est dit que les arguments à transmettre à la fonctions sont :
ulong hwnd
long x1
long y1
long x2
long y2

Le retour est un booléen.

J’ai fait ceci :

Code:

dim hwnd,x1,y1,x2,y2, result
hwnd = handle(0)
x1 = 10 : y1 = 10 : x2 = 100 : y2 = 200
dll_on "Gdi32.dll"
' Equivalent de : 2d_rectangle x1,y1,x2,y2
result = dll_call5("Rectangle",hwnd,x1,y1,x2,y2)
dll_off
message "Ok"

Exécution du code sans erreur, mais aussi sans tracé !

Qu’ai-je ou que n’ai-je pas fait pour que que ça ne marche pas ?


Rendez-vous ici.
C’est très intéressent mais c’est aussi un peu (beaucoup) difficile pour moi !

Tu remplaces handle par handle_canvas et ... ça marche.

Code:

hwnd = handle_canvas(0)

Tu donnes à la DLL le handle de FORM0, mais c'est le handle de son canvas qu'il faut donner, car c'est sur son canvas qu'on dessine.

Bonsoir.

Il faut remplacer hwnd par hwnd%, et tout fonctionne.

Code:

dim hwnd%,x1,y1,x2,y2, result
hwnd% = handle_canvas(0)
x1 = 10 : y1 = 10 : x2 = 100 : y2 = 200
dll_on "Gdi32.dll"
' Equivalent de : 2d_rectangle x1,y1,x2,y2
result = dll_call5("Rectangle",hwnd%,x1,y1,x2,y2)
dll_off
message "Ok"

Bonsoir.

Un petit bout de code pour dessiner une ellipse, en complément du code précédent.

Code:

result = dll_call5("Ellipse",hwnd%,x1,y1,x2,y2)

Merci beaucoup Jack.
Merci pan59.

Ce n’est pas obligatoire hwnd --- > hwnd%
L’astuce c’est de remplacer Handle par handle_Canvas