Comment marchent ces fichues dll ?
ccm4life
Messages postés
3
Statut
Membre
-
imilca -
imilca -
Hello à tous
combien de fois elles sont utiles et combien de fois elles nous posent des problemes ...en informatique elles sont primordiales ...mais comment fonctionnent elles ? avec quoi les ouvrires ? comment les configurées ? bref c'est quoi une DLL ?
Merci de vos réponses
combien de fois elles sont utiles et combien de fois elles nous posent des problemes ...en informatique elles sont primordiales ...mais comment fonctionnent elles ? avec quoi les ouvrires ? comment les configurées ? bref c'est quoi une DLL ?
Merci de vos réponses
A voir également:
- Comment marchent ces fichues dll ?
- Logilda dll ✓ - Forum Windows 8 / 8.1
- Advapi32.dll ccleaner ✓ - Forum Windows
- Cccleaner procédure introuvable dans biblio liens dynamiques - Forum Windows 7
- %Systemroot%\system32\shell32.dll - Forum Windows
- Xinput1_3.dll - Forum Jeux vidéo
6 réponses
Ca ne s'ouvre pas et ca ne se configure pas.
Elles sont utilisées par le système (Windows uniquement: il n'y en a pas sous Unix/Linux/MAC) et permette aux programmes d'accéder à certaines fonctionnalités proposées par le système.
En fait, l'utilisateur lamda n'y touche pas. Les gens qui développent sous windows ont interet à en connaitre et peuvent créer les leurs.
C'est en gros, hein ;-)
Plus de détail sur Google ^^
a+
dje-dje
Elles sont utilisées par le système (Windows uniquement: il n'y en a pas sous Unix/Linux/MAC) et permette aux programmes d'accéder à certaines fonctionnalités proposées par le système.
En fait, l'utilisateur lamda n'y touche pas. Les gens qui développent sous windows ont interet à en connaitre et peuvent créer les leurs.
C'est en gros, hein ;-)
Plus de détail sur Google ^^
a+
dje-dje
Une DLL est une librairie, c'est à dire un ensemble de fonctions qui peuvent être utilisées par d'autres programmes.
Certains DLL fournissent aux programmes des fonctions de calcul, de communications ou autre.
Il y a des DLL qui permettent d'afficher des fichier PDF, d'autres qui permettent de "parler" avec un graveur de CD (comme ASPI).
Certaines DLL permettent de faire de la 3D (sans que le programme n'ait à connaître chaque carte graphique différente, par exemple).
etc.
C'est très varié.
Le principe des DLL (et plus généralement des librairies dynamiques partagées) est de:
- fournir aux programmes des fonctions toute prêtes à l'emploi (pour rendre la création de programmes plus simple).
- grouper dans un fichier (.DLL) des fonctions qui seront utilisées par plusieurs programmes. Cela permet (en principe) de gagner de la place (sur disque et en mémoire).
- de charger en mémoire uniquement les fonctions dont les programmes ont besoin (une DLL n'est généralement chargée en mémoire que quand un programme la demande), d'où une (théorique) économie de mémoire.
Donc en théorie, c'est très bien, mais dans la pratique c'est le bordel... :-)
Raisons:
- Certains programmes exigent beaucoup de DLL. ça devient compliqué à installer et les programmes sont plus lourds à télécharger.
- Les programmes partagent des DLL, et il arrive qu'il y ait des conflits (Plusieurs versions différentes de la même DLL, et Windows qui charge la mauvaise version).
- Windows (et ses logiciels) partagent des DLL. Quand on installe un nouveau logiciel, on met en péril la stabilité de Windows. Et de même, quand on met à jour Windows, certains logiciels peuvent ne plus fonctionner.
Donc, de nos jours quand on programme, on essai tant que possible de limiter le nombre de DLL dont un programme dépend.
Cela rend le programme plus fiable.
Certains DLL fournissent aux programmes des fonctions de calcul, de communications ou autre.
Il y a des DLL qui permettent d'afficher des fichier PDF, d'autres qui permettent de "parler" avec un graveur de CD (comme ASPI).
Certaines DLL permettent de faire de la 3D (sans que le programme n'ait à connaître chaque carte graphique différente, par exemple).
etc.
C'est très varié.
Le principe des DLL (et plus généralement des librairies dynamiques partagées) est de:
- fournir aux programmes des fonctions toute prêtes à l'emploi (pour rendre la création de programmes plus simple).
- grouper dans un fichier (.DLL) des fonctions qui seront utilisées par plusieurs programmes. Cela permet (en principe) de gagner de la place (sur disque et en mémoire).
- de charger en mémoire uniquement les fonctions dont les programmes ont besoin (une DLL n'est généralement chargée en mémoire que quand un programme la demande), d'où une (théorique) économie de mémoire.
Donc en théorie, c'est très bien, mais dans la pratique c'est le bordel... :-)
Raisons:
- Certains programmes exigent beaucoup de DLL. ça devient compliqué à installer et les programmes sont plus lourds à télécharger.
- Les programmes partagent des DLL, et il arrive qu'il y ait des conflits (Plusieurs versions différentes de la même DLL, et Windows qui charge la mauvaise version).
- Windows (et ses logiciels) partagent des DLL. Quand on installe un nouveau logiciel, on met en péril la stabilité de Windows. Et de même, quand on met à jour Windows, certains logiciels peuvent ne plus fonctionner.
Donc, de nos jours quand on programme, on essai tant que possible de limiter le nombre de DLL dont un programme dépend.
Cela rend le programme plus fiable.
OHOH mais c 'est assez inquiétant tout ça !!
donc moins y a de DLL mieux c'est ?
et pas possible de les configurer ?!
donc moins y a de DLL mieux c'est ?
et pas possible de les configurer ?!
mais c 'est assez inquiétant tout ça !!
bah disons que ce n'est pas vraiment inquiétant, mais très chiant.
donc moins y a de DLL mieux c'est ?
En gros, oui.
(Rercher *.dll sur ton disque C:
Le nombre de DLL présente est tout simplement hallucinant).
et pas possible de les configurer ?!
Pas toutes.
On ne peut pas configurer une DLL soi-même.
Certains sont configurées par les programmes qui les appellent.
D'autres DLL ont leur configuration en base de registre.
C'est très variable.
bah disons que ce n'est pas vraiment inquiétant, mais très chiant.
donc moins y a de DLL mieux c'est ?
En gros, oui.
(Rercher *.dll sur ton disque C:
Le nombre de DLL présente est tout simplement hallucinant).
et pas possible de les configurer ?!
Pas toutes.
On ne peut pas configurer une DLL soi-même.
Certains sont configurées par les programmes qui les appellent.
D'autres DLL ont leur configuration en base de registre.
C'est très variable.
ok j'oublie définitivemnt les dlls ....
je pensai que c'etait facile d'accés avec un ptit programme pourri et tu modifis deux trois trucs et sa marche ...mais à vous entendre .....
not so easy
je pensai que c'etait facile d'accés avec un ptit programme pourri et tu modifis deux trois trucs et sa marche ...mais à vous entendre .....
not so easy
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Hello !
Comment appelle t-on une DLL dans access, par exemple ?
Peut on obtenir, grace à son appel, les commandes pouvant lui être passées ?
Merci de vos réponses !
Comment appelle t-on une DLL dans access, par exemple ?
Peut on obtenir, grace à son appel, les commandes pouvant lui être passées ?
Merci de vos réponses !
Salut,
généralement, on l'appelle dans le code en créant une fonction.
Voici un exemple qui permet de récupérer le nom de l'utilisateur :
Dans un module, tu déclares une fonction :
C'est dans cette déclaration que tu dis que tu vas utiliser la dll "advapi32.dll" grâce au mot-clé "Lib" et que tu appelleras la fonction GetUserName. (vois l'aide ACCESS concernant "Declare")
Dans ton code, tu appelles la fonction :
Sur le site de JC.Bellamy (une référence !), tu peux avoir un utilitaire qui permet de scanner les binaires pour voir leurs entrées...
http://bellamyjc.net/fr/scanbin.html
Pour windows, il y a win32.hlp, on en parle ici :
http://www.usenet-fr.net/fur/comp/os/faq-winprog.html
Le fichier d'aide fait quand même 12 Mo...
généralement, on l'appelle dans le code en créant une fonction.
Voici un exemple qui permet de récupérer le nom de l'utilisateur :
Dans un module, tu déclares une fonction :
Public Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, NSize As Long) As Long
C'est dans cette déclaration que tu dis que tu vas utiliser la dll "advapi32.dll" grâce au mot-clé "Lib" et que tu appelleras la fonction GetUserName. (vois l'aide ACCESS concernant "Declare")
Dans ton code, tu appelles la fonction :
Dim Buff As String * 255 Dim NSize As Long Dim Ret As Long NSize = Len(Buff) Ret = GetUserName(Buff, NSize) UsrName = Left(Buff, NSize) UsrName = Left(UsrName, Len(UsrName) - 1) MsgBox UsrName
Sur le site de JC.Bellamy (une référence !), tu peux avoir un utilitaire qui permet de scanner les binaires pour voir leurs entrées...
http://bellamyjc.net/fr/scanbin.html
Pour windows, il y a win32.hlp, on en parle ici :
http://www.usenet-fr.net/fur/comp/os/faq-winprog.html
Le fichier d'aide fait quand même 12 Mo...
Bonjour,
J'ai developpé une DLL(en VC++) normale liée de maniere dynamique aux MFC permettant de
maintenir une structure de donnée en l'occurence une arborescence(designé par le pointeur racine)
j'effectue à traver un programme VisualBasic .Net un premier appel d'une fonction exportée ("genereArbre"),
cette dernière crée alors l'arbre avec les differents noeuds passés en arguments,jusque la aucun probleme.
Par contre si j'effectue un 2 ieme appel, je remarque que les données locales de la DLL changent.
Parmis ces donnée la valeur du pointeur d'instance de la DLL CWinnApp.
Ma question : Est ce qu'à chaqque appel d'une fonction exportée une instance de la DLL est crée (l'ancienne est t elle detruite) ?
Si c'est le cas y 'a t-il un moyen de maintenir à jour des données locales d'une DLL durant
le basculement du programee executable vers la DLL et vis versa. Merci d'avance.
Voici le code
--------------------------------------------------------------------
// Arbre.h : fichier d'en-tête principal pour la DLL Arbre
//
#pragma once
#ifndef __AFXWIN_H__
#error include 'stdafx.h' before including this file for PCH
#endif
#include "resource.h" // symboles principaux
// CArbreApp
// Consultez Arbre.cpp pour l'implémentation de cette classe adWChar
//
class CArbreApp : public CWinApp
{
public:
CArbreApp();
// Overrides
public:
virtual BOOL InitInstance();
DECLARE_MESSAGE_MAP()
private:
// structure personne
typedef struct person
{
struct person *descendance;
char *reference;
struct person *fraterie;
}st_person;
st_person *racine;
st_person *node;
st_person *perePtr;
st_person *savePtr;
st_person* searchPere(LPSTR father);
st_person* preOrdre(st_person* t,LPSTR father);
public:
void generArbre(LPSTR FsPr[],short id_t);
void insertFils(LPSTR ref,st_person *perePtr);
bool ArbreVide(void);
};
--------------------------------------------------------------------
// Arbre.cpp : fichier definition principal pour la DLL Arbre
//void CArbreApp::generArbre(LPSTR FsPr[],short id_t)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
for (int cr=0;cr<id_t;cr+=2)
{
savePtr=NULL;
perePtr = searchPere(FsPr[cr+1]);
insertFils(FsPr[cr],perePtr);
}
}
Au premier appel l'arbre est cree est designe par le pointeur racine qui a une valeur
----------------------------------------------------------------
bool CArbreApp::ArbreVide(void)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
if (racine==NULL)
return true;
else
return false;
}
Une deuxieme fois quand j'appelle cette fonction, je remarque que racine désine n'importe quoi
J'ai developpé une DLL(en VC++) normale liée de maniere dynamique aux MFC permettant de
maintenir une structure de donnée en l'occurence une arborescence(designé par le pointeur racine)
j'effectue à traver un programme VisualBasic .Net un premier appel d'une fonction exportée ("genereArbre"),
cette dernière crée alors l'arbre avec les differents noeuds passés en arguments,jusque la aucun probleme.
Par contre si j'effectue un 2 ieme appel, je remarque que les données locales de la DLL changent.
Parmis ces donnée la valeur du pointeur d'instance de la DLL CWinnApp.
Ma question : Est ce qu'à chaqque appel d'une fonction exportée une instance de la DLL est crée (l'ancienne est t elle detruite) ?
Si c'est le cas y 'a t-il un moyen de maintenir à jour des données locales d'une DLL durant
le basculement du programee executable vers la DLL et vis versa. Merci d'avance.
Voici le code
--------------------------------------------------------------------
// Arbre.h : fichier d'en-tête principal pour la DLL Arbre
//
#pragma once
#ifndef __AFXWIN_H__
#error include 'stdafx.h' before including this file for PCH
#endif
#include "resource.h" // symboles principaux
// CArbreApp
// Consultez Arbre.cpp pour l'implémentation de cette classe adWChar
//
class CArbreApp : public CWinApp
{
public:
CArbreApp();
// Overrides
public:
virtual BOOL InitInstance();
DECLARE_MESSAGE_MAP()
private:
// structure personne
typedef struct person
{
struct person *descendance;
char *reference;
struct person *fraterie;
}st_person;
st_person *racine;
st_person *node;
st_person *perePtr;
st_person *savePtr;
st_person* searchPere(LPSTR father);
st_person* preOrdre(st_person* t,LPSTR father);
public:
void generArbre(LPSTR FsPr[],short id_t);
void insertFils(LPSTR ref,st_person *perePtr);
bool ArbreVide(void);
};
--------------------------------------------------------------------
// Arbre.cpp : fichier definition principal pour la DLL Arbre
//void CArbreApp::generArbre(LPSTR FsPr[],short id_t)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
for (int cr=0;cr<id_t;cr+=2)
{
savePtr=NULL;
perePtr = searchPere(FsPr[cr+1]);
insertFils(FsPr[cr],perePtr);
}
}
Au premier appel l'arbre est cree est designe par le pointeur racine qui a une valeur
----------------------------------------------------------------
bool CArbreApp::ArbreVide(void)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
if (racine==NULL)
return true;
else
return false;
}
Une deuxieme fois quand j'appelle cette fonction, je remarque que racine désine n'importe quoi
