J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement des DLL.
Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il
fonctionne internement.
Comment ça fonctionne ?
Voici pourquoi je me pose cette question:
1- Je dois distribuer une application avec une dll qui est "peut être" déja
sur le poste du client et utilisé par d'autres applications. Je met la dll
dans le répertoire de mon application et l'enregistre.
2- Donc je veux connaitre les impacts losque j'enregistrerais Ma copie de la
dll
3- Et ce qu'il arrivera lorsque je désinstallerais mon application, est-ce
que les autres applications qui utilisaient la dll vont continuer de
foncitonner ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Claude BELLAMY
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement des DLL. Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il fonctionne internement. Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire) de la dll et obtient la liste des fonctions exportées, qui sont, pour tout contrôle activeX qui se respecte : DllRegister DllUnregister ... A l'aide de DllRegister, il va être récupéré : - le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...) - le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..) - le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx") (il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID trouvé>, de valeur par défaut le ProgID, et dans laquelle il crée des sous-clefs "InprocServer32", "ProgID", "TypeLib", "Version", "ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le ProgID) accèdent au composant.
Voici pourquoi je me pose cette question: 1- Je dois distribuer une application avec une dll qui est "peut être" déja sur le poste du client et utilisé par d'autres applications. Je met la dll dans le répertoire de mon application et l'enregistre. 2- Donc je veux connaitre les impacts losque j'enregistrerais Ma copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application, est-ce que les autres applications qui utilisaient la dll vont continuer de foncitonner ? Oui, bien sur ...
C'est indépendant ..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :OZIuSmN2GHA.2036@TK2MSFTNGP05.phx.gbl,
Patrick Paquette <NoSpam@4me.com> a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement
des DLL.
Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il
fonctionne internement.
Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire) de
la dll et obtient la liste des fonctions exportées, qui sont, pour tout
contrôle activeX qui se respecte :
DllRegister
DllUnregister
...
A l'aide de DllRegister, il va être récupéré :
- le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...)
- le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..)
- le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx")
(il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID trouvé>,
de valeur par défaut le ProgID, et dans laquelle il crée des sous-clefs
"InprocServer32", "ProgID", "TypeLib", "Version", "ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le
ProgID) accèdent au composant.
Voici pourquoi je me pose cette question:
1- Je dois distribuer une application avec une dll qui est "peut
être" déja sur le poste du client et utilisé par d'autres
applications. Je met la dll dans le répertoire de mon application et
l'enregistre.
2- Donc je veux connaitre les impacts losque j'enregistrerais Ma
copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le
chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application,
est-ce que les autres applications qui utilisaient la dll vont
continuer de foncitonner ?
Oui, bien sur ...
C'est indépendant ..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement des DLL. Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il fonctionne internement. Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire) de la dll et obtient la liste des fonctions exportées, qui sont, pour tout contrôle activeX qui se respecte : DllRegister DllUnregister ... A l'aide de DllRegister, il va être récupéré : - le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...) - le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..) - le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx") (il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID trouvé>, de valeur par défaut le ProgID, et dans laquelle il crée des sous-clefs "InprocServer32", "ProgID", "TypeLib", "Version", "ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le ProgID) accèdent au composant.
Voici pourquoi je me pose cette question: 1- Je dois distribuer une application avec une dll qui est "peut être" déja sur le poste du client et utilisé par d'autres applications. Je met la dll dans le répertoire de mon application et l'enregistre. 2- Donc je veux connaitre les impacts losque j'enregistrerais Ma copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application, est-ce que les autres applications qui utilisaient la dll vont continuer de foncitonner ? Oui, bien sur ...
C'est indépendant ..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Patrick Paquette
Merci Jean-Claude,
Les morceaux du puzzle commence à ce placer. Mais il reste une chose à éclaircir.
Voici un exemple précis: - dsofile.dll est installer sur le poste du client dans le system32. - J'installe mon application qui contient une copie de dsofile.dll que je met dans un sous répertoire de mon application et enregistre cette dll au cas où celle-ci ne serrait pas déja présente sur le poste. (Donc l'entrée InprocServer32 dans le registre va être changer pour le path du sous répertoire) puisque le CLSID et PROGID sont les mêmes. -Lorsque je vais désinstaller mon application et supprimer du même coup la dll, la référence au path dans le registre n'existera plus. Donc en théorie les autres applications qui utilisaient dsofile.dll du system32 (avant que j'enregistre ma copie) ne fonctionneront plus.
C'est exact ?
merci
"Jean-Claude BELLAMY" wrote in message news:%
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement des DLL. Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il fonctionne internement. Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire) de la dll et obtient la liste des fonctions exportées, qui sont, pour tout contrôle activeX qui se respecte : DllRegister DllUnregister ... A l'aide de DllRegister, il va être récupéré : - le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...) - le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..) - le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx") (il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID trouvé>, de valeur par défaut le ProgID, et dans laquelle il crée des sous-clefs "InprocServer32", "ProgID", "TypeLib", "Version", "ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le ProgID) accèdent au composant.
Voici pourquoi je me pose cette question: 1- Je dois distribuer une application avec une dll qui est "peut être" déja sur le poste du client et utilisé par d'autres applications. Je met la dll dans le répertoire de mon application et l'enregistre. 2- Donc je veux connaitre les impacts losque j'enregistrerais Ma copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application, est-ce que les autres applications qui utilisaient la dll vont continuer de foncitonner ? Oui, bien sur ...
C'est indépendant ..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Merci Jean-Claude,
Les morceaux du puzzle commence à ce placer.
Mais il reste une chose à éclaircir.
Voici un exemple précis:
- dsofile.dll est installer sur le poste du client dans le system32.
- J'installe mon application qui contient une copie de dsofile.dll que je
met dans un sous répertoire de mon application et enregistre cette dll au
cas où celle-ci ne serrait pas déja présente sur le poste. (Donc l'entrée
InprocServer32 dans le registre va être changer pour le path du sous
répertoire) puisque le CLSID et PROGID sont les mêmes.
-Lorsque je vais désinstaller mon application et supprimer du même coup la
dll, la référence au path dans le registre n'existera plus. Donc en théorie
les autres applications qui utilisaient dsofile.dll du system32 (avant que
j'enregistre ma copie) ne fonctionneront plus.
C'est exact ?
merci
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> wrote in message
news:%2341dFUO2GHA.3476@TK2MSFTNGP04.phx.gbl...
Dans le message :OZIuSmN2GHA.2036@TK2MSFTNGP05.phx.gbl,
Patrick Paquette <NoSpam@4me.com> a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement
des DLL.
Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il
fonctionne internement.
Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire)
de la dll et obtient la liste des fonctions exportées, qui sont, pour tout
contrôle activeX qui se respecte :
DllRegister
DllUnregister
...
A l'aide de DllRegister, il va être récupéré :
- le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...)
- le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..)
- le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx")
(il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID
trouvé>, de valeur par défaut le ProgID, et dans laquelle il crée des
sous-clefs "InprocServer32", "ProgID", "TypeLib", "Version",
"ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le
ProgID) accèdent au composant.
Voici pourquoi je me pose cette question:
1- Je dois distribuer une application avec une dll qui est "peut
être" déja sur le poste du client et utilisé par d'autres
applications. Je met la dll dans le répertoire de mon application et
l'enregistre.
2- Donc je veux connaitre les impacts losque j'enregistrerais Ma
copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le
chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application,
est-ce que les autres applications qui utilisaient la dll vont
continuer de foncitonner ?
Oui, bien sur ...
C'est indépendant ..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Les morceaux du puzzle commence à ce placer. Mais il reste une chose à éclaircir.
Voici un exemple précis: - dsofile.dll est installer sur le poste du client dans le system32. - J'installe mon application qui contient une copie de dsofile.dll que je met dans un sous répertoire de mon application et enregistre cette dll au cas où celle-ci ne serrait pas déja présente sur le poste. (Donc l'entrée InprocServer32 dans le registre va être changer pour le path du sous répertoire) puisque le CLSID et PROGID sont les mêmes. -Lorsque je vais désinstaller mon application et supprimer du même coup la dll, la référence au path dans le registre n'existera plus. Donc en théorie les autres applications qui utilisaient dsofile.dll du system32 (avant que j'enregistre ma copie) ne fonctionneront plus.
C'est exact ?
merci
"Jean-Claude BELLAMY" wrote in message news:%
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Bonjour,
J'aimerais savoir comment fonctionne RegSvr32 pour l'enregistrement des DLL. Je veux savoir non pas comment utiliser RegSvr32, mais bien comment il fonctionne internement. Comment ça fonctionne ?
Quand on exécute REGSVR32 nom-de-dll, REGSVR32 examine le code (binaire) de la dll et obtient la liste des fonctions exportées, qui sont, pour tout contrôle activeX qui se respecte : DllRegister DllUnregister ... A l'aide de DllRegister, il va être récupéré : - le ProgID (p.ex. "jcb.tools", "VBDataView.docDataView", ...) - le CLSID (p.ex. {42DA526B-298E-4B70-9DA9-45D1BFCC835A},..) - le InprocServer32 (chemin complet du binaire, p.ex. "I:VBSjcb.ocx") (il y a d'autres infos, mais je simplifie)
Il y a alors création d'une clef HKEY_CLASSES_ROOTCLSID<le CLSID trouvé>, de valeur par défaut le ProgID, et dans laquelle il crée des sous-clefs "InprocServer32", "ProgID", "TypeLib", "Version", "ToolboxBitmap32",...)
Et c'est par cette arborescence que les applis (qui ne connaissent que le ProgID) accèdent au composant.
Voici pourquoi je me pose cette question: 1- Je dois distribuer une application avec une dll qui est "peut être" déja sur le poste du client et utilisé par d'autres applications. Je met la dll dans le répertoire de mon application et l'enregistre. 2- Donc je veux connaitre les impacts losque j'enregistrerais Ma copie de la dll
La sous-clef de la classe de ta DLL clef InprocServer32 va contenir le chemin exact de cette DLL
3- Et ce qu'il arrivera lorsque je désinstallerais mon application, est-ce que les autres applications qui utilisaient la dll vont continuer de foncitonner ? Oui, bien sur ...
C'est indépendant ..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Jean-Claude BELLAMY
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Merci Jean-Claude,
Les morceaux du puzzle commence à ce placer. Mais il reste une chose à éclaircir.
Voici un exemple précis: - dsofile.dll est installer sur le poste du client dans le system32. - J'installe mon application qui contient une copie de dsofile.dll que je met dans un sous répertoire de mon application et enregistre cette dll au cas où celle-ci ne serrait pas déja présente sur le poste. (Donc l'entrée InprocServer32 dans le registre va être changer pour le path du sous répertoire) puisque le CLSID et PROGID sont les mêmes. -Lorsque je vais désinstaller mon application et supprimer du même coup la dll, Et bien NON, justement, dans ce cas, il ne FAUT PAS désinstaller la DLL car
c'est un ActiveX! (et même, il est toujours dangereux une DLL si on n'est pas sûr qu'aucune autre appli ne l'utilise)
la référence au path dans le registre n'existera plus. Donc en théorie les autres applications qui utilisaient dsofile.dll du system32 (avant que j'enregistre ma copie) ne fonctionneront plus. C'est exact ? OUI
Une des avantages des ActiveX, c'est que depuis n'importe quelle appli qui les utilise (C/C++, Delphi, VB, VBS, ...) il suffit de connaitre leur "nom de contrôle" ("jcb.tools" p.ex.) et à partir de cette simple indication, le système retrouve leur ID, le nom de la DLL associée, son emplacement,...
L'inconvénient, c'est qu'on ne sait pas (ou ne sait plus) qui les utilise. Donc une suppression (ou désenregistrement) est très plantogène ! Moi je suis partisan de les laisser en paix, tant pis pour la place occupée sur disque et dans la BDR !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :eZWIgkO2GHA.3588@TK2MSFTNGP06.phx.gbl,
Patrick Paquette <NoSpam@4me.com> a pris la peine d'écrire ce qui suit :
Merci Jean-Claude,
Les morceaux du puzzle commence à ce placer.
Mais il reste une chose à éclaircir.
Voici un exemple précis:
- dsofile.dll est installer sur le poste du client dans le system32.
- J'installe mon application qui contient une copie de dsofile.dll
que je met dans un sous répertoire de mon application et enregistre
cette dll au cas où celle-ci ne serrait pas déja présente sur le
poste. (Donc l'entrée InprocServer32 dans le registre va être changer
pour le path du sous répertoire) puisque le CLSID et PROGID sont les
mêmes. -Lorsque je vais désinstaller mon application et supprimer du
même coup la dll,
Et bien NON, justement, dans ce cas, il ne FAUT PAS désinstaller la DLL car
c'est un ActiveX!
(et même, il est toujours dangereux une DLL si on n'est pas sûr qu'aucune
autre appli ne l'utilise)
la référence au path dans le registre n'existera
plus. Donc en théorie les autres applications qui utilisaient
dsofile.dll du system32 (avant que j'enregistre ma copie) ne
fonctionneront plus.
C'est exact ?
OUI
Une des avantages des ActiveX, c'est que depuis n'importe quelle appli qui
les utilise (C/C++, Delphi, VB, VBS, ...) il suffit de connaitre leur "nom
de contrôle" ("jcb.tools" p.ex.) et à partir de cette simple indication, le
système retrouve leur ID, le nom de la DLL associée, son emplacement,...
L'inconvénient, c'est qu'on ne sait pas (ou ne sait plus) qui les utilise.
Donc une suppression (ou désenregistrement) est très plantogène !
Moi je suis partisan de les laisser en paix, tant pis pour la place occupée
sur disque et dans la BDR !
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :, Patrick Paquette a pris la peine d'écrire ce qui suit :
Merci Jean-Claude,
Les morceaux du puzzle commence à ce placer. Mais il reste une chose à éclaircir.
Voici un exemple précis: - dsofile.dll est installer sur le poste du client dans le system32. - J'installe mon application qui contient une copie de dsofile.dll que je met dans un sous répertoire de mon application et enregistre cette dll au cas où celle-ci ne serrait pas déja présente sur le poste. (Donc l'entrée InprocServer32 dans le registre va être changer pour le path du sous répertoire) puisque le CLSID et PROGID sont les mêmes. -Lorsque je vais désinstaller mon application et supprimer du même coup la dll, Et bien NON, justement, dans ce cas, il ne FAUT PAS désinstaller la DLL car
c'est un ActiveX! (et même, il est toujours dangereux une DLL si on n'est pas sûr qu'aucune autre appli ne l'utilise)
la référence au path dans le registre n'existera plus. Donc en théorie les autres applications qui utilisaient dsofile.dll du system32 (avant que j'enregistre ma copie) ne fonctionneront plus. C'est exact ? OUI
Une des avantages des ActiveX, c'est que depuis n'importe quelle appli qui les utilise (C/C++, Delphi, VB, VBS, ...) il suffit de connaitre leur "nom de contrôle" ("jcb.tools" p.ex.) et à partir de cette simple indication, le système retrouve leur ID, le nom de la DLL associée, son emplacement,...
L'inconvénient, c'est qu'on ne sait pas (ou ne sait plus) qui les utilise. Donc une suppression (ou désenregistrement) est très plantogène ! Moi je suis partisan de les laisser en paix, tant pis pour la place occupée sur disque et dans la BDR !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
