regsvr32 permet d'enregistrer du code de type dll dans un composant
COM.
Dans le cadre d'une mise a jour de cette dll, j'aimerai faire joujou
avec cette dll et faire tourner en // deux versions dff=E9rentes.
Dans une fenetre de commande, j'enregistre la version 1, je lance
l'exe, je laisse tourner.
Dans l'autre fenetre de commande, j'enregistre la deuxieme version et
lance l'exe.
A priori il y aurait en memoire deux versions de cette dll chacune
attache a un exe diff=E9rent.
Est-ce que windows ne pas se prendre les pieds dans le tapis ? ... en
testant ca a l'air possible.
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 :, a pris la peine d'écrire ce qui suit :
Bonjour,
regsvr32 permet d'enregistrer du code de type dll dans un composant COM.
Dans le cadre d'une mise a jour de cette dll, j'aimerai faire joujou avec cette dll et faire tourner en // deux versions dfférentes. Dans une fenetre de commande, j'enregistre la version 1, je lance l'exe, je laisse tourner. Dans l'autre fenetre de commande, j'enregistre la deuxieme version et lance l'exe.
A priori il y aurait en memoire deux versions de cette dll chacune attache a un exe différent.
Est-ce que windows ne pas se prendre les pieds dans le tapis ? ... en testant ca a l'air possible.
Tout dépend de la façon dont la DLL a été compilée pour générer le composant. S'il y a un nouvel ID et ProgID, les 2 versions peuvent cohabiter sans pb. Il y aura alors 2 entrées distinctes dans la BDR (dans HKEY_CLASSES_ROOTCLSID)
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
REGSVR32 crée alors 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.
-- 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 :1148915444.562734.66350@y43g2000cwc.googlegroups.com,
christophe.delarue@gmail.com <christophe.delarue@gmail.com> a pris la peine
d'écrire ce qui suit :
Bonjour,
regsvr32 permet d'enregistrer du code de type dll dans un composant
COM.
Dans le cadre d'une mise a jour de cette dll, j'aimerai faire joujou
avec cette dll et faire tourner en // deux versions dfférentes.
Dans une fenetre de commande, j'enregistre la version 1, je lance
l'exe, je laisse tourner.
Dans l'autre fenetre de commande, j'enregistre la deuxieme version et
lance l'exe.
A priori il y aurait en memoire deux versions de cette dll chacune
attache a un exe différent.
Est-ce que windows ne pas se prendre les pieds dans le tapis ? ... en
testant ca a l'air possible.
Tout dépend de la façon dont la DLL a été compilée pour générer le
composant.
S'il y a un nouvel ID et ProgID, les 2 versions peuvent cohabiter sans pb.
Il y aura alors 2 entrées distinctes dans la BDR (dans
HKEY_CLASSES_ROOTCLSID)
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la
dll et obtient comme infos principales :
- 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)
REGSVR32 crée alors 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.
--
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 :, a pris la peine d'écrire ce qui suit :
Bonjour,
regsvr32 permet d'enregistrer du code de type dll dans un composant COM.
Dans le cadre d'une mise a jour de cette dll, j'aimerai faire joujou avec cette dll et faire tourner en // deux versions dfférentes. Dans une fenetre de commande, j'enregistre la version 1, je lance l'exe, je laisse tourner. Dans l'autre fenetre de commande, j'enregistre la deuxieme version et lance l'exe.
A priori il y aurait en memoire deux versions de cette dll chacune attache a un exe différent.
Est-ce que windows ne pas se prendre les pieds dans le tapis ? ... en testant ca a l'air possible.
Tout dépend de la façon dont la DLL a été compilée pour générer le composant. S'il y a un nouvel ID et ProgID, les 2 versions peuvent cohabiter sans pb. Il y aura alors 2 entrées distinctes dans la BDR (dans HKEY_CLASSES_ROOTCLSID)
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
REGSVR32 crée alors 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.
-- 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
christophe.delarue
Merci pour cette reponse plus qu'abondante.
A coup de "strings", j'ai pu recuperer ces informations de mes differentes dll et les differents CLSID. Ils sont tous les memes.
J'en conclus donc qu'il vaut mieux les lancer les uns apres les autres.
Merci pour cette reponse plus qu'abondante.
A coup de "strings", j'ai pu recuperer ces informations de mes
differentes dll et les differents CLSID. Ils sont tous les memes.
J'en conclus donc qu'il vaut mieux les lancer les uns apres les autres.
A coup de "strings", j'ai pu recuperer ces informations de mes differentes dll et les differents CLSID. Ils sont tous les memes.
J'en conclus donc qu'il vaut mieux les lancer les uns apres les autres.
Philippe Majerus
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
Petite précision technique qui je pense t'interessera Jean-Claude: RegSvr32 ne se charge en fait pas de tout cela lui-même. Il execute simplement la fonction DllRegisterServer exportée par la dll ou l'ocx, ou la fonction DllRegisterServerEx exportée par le helper AutoRegister de ce type de fichier dans le cas d'un autre type de fichier fournissant des serveurs COM (tel que les .wsc). En gros, chaque dll peut faire ce que bon lui semble dans cette fonction, en général enregistrer ses ProgIDs et ClassIDs, mais également TypeLibs, initialisation de sa config ou tout autre fonction utile pour elle.
Tout comme rundll32, regsvr32 permet donc l'execution de code contenus dans la dll (la seule différence en fin de compte étant le prototype de la fonction exécutée), et peut à ce titre être également utilisé à mauvais escient (faire tourner son code sans être listé dans le task manager).
-- Philippe Majerus Software, Documentation and stuff - http://www.phm.lu
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de
la dll et obtient comme infos principales :
- 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)
Petite précision technique qui je pense t'interessera Jean-Claude:
RegSvr32 ne se charge en fait pas de tout cela lui-même. Il execute
simplement la fonction DllRegisterServer exportée par la dll ou l'ocx, ou la
fonction DllRegisterServerEx exportée par le helper AutoRegister de ce type
de fichier dans le cas d'un autre type de fichier fournissant des serveurs
COM (tel que les .wsc).
En gros, chaque dll peut faire ce que bon lui semble dans cette fonction, en
général enregistrer ses ProgIDs et ClassIDs, mais également TypeLibs,
initialisation de sa config ou tout autre fonction utile pour elle.
Tout comme rundll32, regsvr32 permet donc l'execution de code contenus dans
la dll (la seule différence en fin de compte étant le prototype de la
fonction exécutée), et peut à ce titre être également utilisé à mauvais
escient (faire tourner son code sans être listé dans le task manager).
--
Philippe Majerus
Software, Documentation and stuff - http://www.phm.lu
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
Petite précision technique qui je pense t'interessera Jean-Claude: RegSvr32 ne se charge en fait pas de tout cela lui-même. Il execute simplement la fonction DllRegisterServer exportée par la dll ou l'ocx, ou la fonction DllRegisterServerEx exportée par le helper AutoRegister de ce type de fichier dans le cas d'un autre type de fichier fournissant des serveurs COM (tel que les .wsc). En gros, chaque dll peut faire ce que bon lui semble dans cette fonction, en général enregistrer ses ProgIDs et ClassIDs, mais également TypeLibs, initialisation de sa config ou tout autre fonction utile pour elle.
Tout comme rundll32, regsvr32 permet donc l'execution de code contenus dans la dll (la seule différence en fin de compte étant le prototype de la fonction exécutée), et peut à ce titre être également utilisé à mauvais escient (faire tourner son code sans être listé dans le task manager).
-- Philippe Majerus Software, Documentation and stuff - http://www.phm.lu
Jean-Claude BELLAMY
Dans le message :eZj8oa$, Philippe Majerus <Use: http://www.phm.lu/?action=email> a pris la peine d'écrire ce qui suit :
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
Petite précision technique qui je pense t'interessera Jean-Claude: RegSvr32 ne se charge en fait pas de tout cela lui-même.
J'ai voulu simplifier !
C'est l'éternel pb de la vulgarisation : - ou bien on dit tout, et çà devient vite imbuvable et surtout très (trop!) long...
- on bien on extrait le principal, mais alors on risque de faire des "raccourcis" un peu rapides. C'est pourquoi je n'ai pas voulu parler des 4 fonctions standard "DllCanUnloadNow", "DllGetClassObject", "DllRegisterServer", "DllUnregisterServer" (au minimum) (les seuls noms de fonctions exportées visibles p.ex. dans "Dependency Walker", alors que concrètement le composant offre plein d'autres fonctions appelables depuis un VBS ou autre programme)
Il execute simplement la fonction DllRegisterServer exportée par la dll ou l'ocx, ou la fonction DllRegisterServerEx exportée par le helper AutoRegister de ce type de fichier dans le cas d'un autre type de fichier fournissant des serveurs COM (tel que les .wsc). En gros, chaque dll peut faire ce que bon lui semble dans cette fonction, en général enregistrer ses ProgIDs et ClassIDs, mais également TypeLibs, initialisation de sa config ou tout autre fonction utile pour elle. Tout comme rundll32, regsvr32 permet donc l'execution de code contenus dans la dll (la seule différence en fin de compte étant le prototype de la fonction exécutée), et peut à ce titre être également utilisé à mauvais escient (faire tourner son code sans être listé dans le task manager).
Merci Philippe d'avoir été plus précis que moi ... ;-)
-- 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 :eZj8oa$gGHA.5104@TK2MSFTNGP04.phx.gbl,
Philippe Majerus <Use: http://www.phm.lu/?action=email> a pris la peine
d'écrire ce qui suit :
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code
(binaire) de la dll et obtient comme infos principales :
- 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)
Petite précision technique qui je pense t'interessera Jean-Claude:
RegSvr32 ne se charge en fait pas de tout cela lui-même.
J'ai voulu simplifier !
C'est l'éternel pb de la vulgarisation :
- ou bien on dit tout, et çà devient vite imbuvable
et surtout très (trop!) long...
- on bien on extrait le principal, mais alors on
risque de faire des "raccourcis" un peu rapides.
C'est pourquoi je n'ai pas voulu parler des 4 fonctions
standard "DllCanUnloadNow", "DllGetClassObject",
"DllRegisterServer", "DllUnregisterServer" (au minimum)
(les seuls noms de fonctions exportées visibles p.ex.
dans "Dependency Walker", alors que concrètement
le composant offre plein d'autres fonctions appelables
depuis un VBS ou autre programme)
Il execute
simplement la fonction DllRegisterServer exportée par la dll ou
l'ocx, ou la fonction DllRegisterServerEx exportée par le helper
AutoRegister de ce type de fichier dans le cas d'un autre type de
fichier fournissant des serveurs COM (tel que les .wsc).
En gros, chaque dll peut faire ce que bon lui semble dans cette
fonction, en général enregistrer ses ProgIDs et ClassIDs, mais
également TypeLibs, initialisation de sa config ou tout autre
fonction utile pour elle.
Tout comme rundll32, regsvr32 permet donc l'execution de code
contenus dans la dll (la seule différence en fin de compte étant le
prototype de la fonction exécutée), et peut à ce titre être également
utilisé à mauvais escient (faire tourner son code sans être listé
dans le task manager).
Merci Philippe d'avoir été plus précis que moi ... ;-)
--
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 :eZj8oa$, Philippe Majerus <Use: http://www.phm.lu/?action=email> a pris la peine d'écrire ce qui suit :
Quand on exécute REGSVR32 nomdedll, REGSVR32 examine le code (binaire) de la dll et obtient comme infos principales : - 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)
Petite précision technique qui je pense t'interessera Jean-Claude: RegSvr32 ne se charge en fait pas de tout cela lui-même.
J'ai voulu simplifier !
C'est l'éternel pb de la vulgarisation : - ou bien on dit tout, et çà devient vite imbuvable et surtout très (trop!) long...
- on bien on extrait le principal, mais alors on risque de faire des "raccourcis" un peu rapides. C'est pourquoi je n'ai pas voulu parler des 4 fonctions standard "DllCanUnloadNow", "DllGetClassObject", "DllRegisterServer", "DllUnregisterServer" (au minimum) (les seuls noms de fonctions exportées visibles p.ex. dans "Dependency Walker", alors que concrètement le composant offre plein d'autres fonctions appelables depuis un VBS ou autre programme)
Il execute simplement la fonction DllRegisterServer exportée par la dll ou l'ocx, ou la fonction DllRegisterServerEx exportée par le helper AutoRegister de ce type de fichier dans le cas d'un autre type de fichier fournissant des serveurs COM (tel que les .wsc). En gros, chaque dll peut faire ce que bon lui semble dans cette fonction, en général enregistrer ses ProgIDs et ClassIDs, mais également TypeLibs, initialisation de sa config ou tout autre fonction utile pour elle. Tout comme rundll32, regsvr32 permet donc l'execution de code contenus dans la dll (la seule différence en fin de compte étant le prototype de la fonction exécutée), et peut à ce titre être également utilisé à mauvais escient (faire tourner son code sans être listé dans le task manager).
Merci Philippe d'avoir été plus précis que moi ... ;-)
-- 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
