Patch GUID/CLSID

Bonjour,

est-il possible de patcher un ActiveX pour changer son GUID et ProgID
sans avoir à tout recompiler ?

1. L'endroit où et la manière dont cette information est stockée dépend
de l'outil de développement. Si c'est dans les ressources, il faut faire
la recherche en UNICODE. De plus, le ProgId peut être généré
dynamiquement, donc introuvable. Si le ProgId a une longueur différente,
cela pose bien sûr un problème... de taille.

2. Dans la majorité des cas, changer le CLSID et le ProgId et recompiler
doit prendre environ 30 secondes.

3. Je ne vois pas bien quels desseins peut servir une telle
manipulation.

Ou bien vous avez le code source et comme expliqué plus haut, cela prend
moins de temps de recompiler que de lancer un programme de patch, de
spécifier à la main le CLSID à trouver et le CLSID de remplacement, etc.

Ou bien vous n'avez pas le code source et je ne vois pas bien pourquoi
vous voudriez faire cela. Voyons voir... modifier le CLSID d'un
composant dont je n'ai pas le code source et le réenregistrer sous un
autre identifiant avec toutes les conséquences inévitables sur le reste
du système et des applications qui utilisent éventuellement ce
composant. Non, je ne vois pas...

Je me souviens d'une BD dans ma jeunesse où le héros était sans arrêt
tenté par des actions disons discutables et qui se disait au moment de
passer à l'acte "Séraphin - son ange gardien -, dirait que c'est mal.".

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in
news:dv3u3i$2g8g$1@biggoron.nerim.net:

Bonjour,

est-il possible de patcher un ActiveX pour changer son GUID et ProgID
sans avoir à tout recompiler ?

1. L'endroit où et la manière dont cette information est stockée
dépend de l'outil de développement. Si c'est dans les ressources, il
faut faire la recherche en UNICODE. De plus, le ProgId peut être
généré dynamiquement, donc introuvable. Si le ProgId a une longueur
différente, cela pose bien sûr un problème... de taille.

Bien vu !
Ok c'est ce que je voulais savoir.

3. Je ne vois pas bien quels desseins peut servir une telle
manipulation.

J'ai pourtant le code source de l'application, mais j'ai la flemme (une
bonne grosse flemme de vendredi après-midi d'août) de me plonger dans
toutes les monstrueuses étapes de configuration de l'environnement de
build juste pour changer cette info (installation des dépendances, des
bibliothèques tierces et outils tiers requis, installation de la bonne
version du compilateur... ce genre de chose qui prend rapidement des
jours entiers).

Séraphin peut-il réellement me reprocher ça ?

Ou bien vous n'avez pas le code source et je ne vois pas bien pourquoi
vous voudriez faire cela. Voyons voir...

C'est encore une fois une variante du sempiternel "DLL hell".

Je veux éviter qu'une mise à jour quelconque installe une nouvelle
version du composant et casse mon application, d'où l'idée d'isoler ce
composant en lui donnant un GUID de *mon* choix. Je contrôlerai
totalement la version utilisée, je serai maître du monde, niark niark
niark...

Mais tout n'est pas perdu, et ma soif de domination pourra probablement
être assouvie car en fait il me suffit d'analyser le code source pour
savoir quoi patcher le cas échéant :-D

Je ne me suis pas trop penché sur la question, mais je suppose qu'il est
impossible d'instancier un objet COM qui ne serait pas enregistré ? Ça
serait une alternative intéressante...


Merci beaucoup !

--
Cyrille Szymanski

"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:Xns9785D7ACC92E1cns2cnsinvalid@212.27.42.129...

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in
news:dv3u3i$2g8g$1@biggoron.nerim.net:

J'ai pourtant le code source de l'application, mais j'ai la flemme (une
bonne grosse flemme de vendredi après-midi d'août) de me plonger dans
toutes les monstrueuses étapes de configuration de l'environnement de
build juste pour changer cette info (installation des dépendances, des
bibliothèques tierces et outils tiers requis, installation de la bonne
version du compilateur... ce genre de chose qui prend rapidement des
jours entiers).

ha, programmeur fainéant peut il etre un bon programmeur ? :-) ca se discute
:-)

Je ne me suis pas trop penché sur la question, mais je suppose qu'il est
impossible d'instancier un objet COM qui ne serait pas enregistré ? Ça
serait une alternative intéressante...

En toute rigueur ca doit pouvoir se faire, mais pas par un CoCreateInstance.
Il faut faire un LoadLibrairie et trouver la fonction DllGetClassObject et
voila.

VB

Cyrille Szymanski wrote:

J'ai pourtant le code source de l'application, mais j'ai la flemme
(une bonne grosse flemme de vendredi après-midi d'août) de me plonger
dans toutes les monstrueuses étapes de configuration de
l'environnement de build juste pour changer cette info

Quel est l'outil que vous utilisez? Avec un projet VC++ par exemple,
changer le CLSID est une affaire de quelques minutes au plus: générer un
nouveau CLSID avec GUIDGEN dans la console, le copier dans le code
source où se trouve l'original à remplacer, recompiler. Point final.
Pour un projet VC++ ATL, il suffit de remplacer le CLSID dans le fichier
de ressources généré automatiquement. Pour des projets Delphi ou VB,
c'est également aussi simple (VB6 recrée en fait un nouveau CLSID à
chaque compilation tant que l'option "Compatibilité binaire" n'est pas
cochée).

Séraphin peut-il réellement me reprocher ça ?

Séraphin dirait que la paresse, ça s'organise. Philippe Kahn disait
qu'un bon développeur est un développeur obsédé, moi je dirais plutôt
que c'est quelqu'un qui a "l'intelligence de la paresse" ou la "paresse
intelligente". Si on veut être paresseux, comme Alexandre le
Bienheureux, il faut que le gain en énergie soit réel. Là, je ne suis
pas sûr qu'il y ait économie d'énergie :-) .

Je ne me suis pas trop penché sur la question, mais je suppose qu'il
est impossible d'instancier un objet COM qui ne serait pas enregistré
? Ça serait une alternative intéressante...

Non mais rien n'empêche d'enregistrer à la volée juste avant de demander
une instanciation. C'est exactement ce que fait VB6 par exemple quand il
active en mode debug un composant ActiveX qui n'a même pas encore été
compilé. Il crée dynamiquement une entrée dans HKCRCLSID et cette
entrée pointe en fait sur l'instance de VB6 en cours d'exécution. Cette
instance de VB6 se charge elle-même d'instancier le composant qui en
fait n'existe pas encore sauf dans la mémoire de l'IDE.

Tout est possible à condition que l'entrée dans HKCRCLSID existe au
moment de l'instanciation.

D'où l'avantage de .Net qui ne demande aucun enregistrement préalable,
toutes les meta données nécessaires étant portées par le module
lui-même. De toutes façons, avec .Net vous n'auriez pas ce problème de
versionnage puisque l'on peut faire vivre côte à côte autant de versions
que l'on veut d'un même composant. Un progrès considérable. Vous y
viendrez... :-) .

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Patrick Philippot wrote:

D'où l'avantage de .Net

[...]

Vous y viendrez... :-) .

J'en doute.

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Vincent Burel, le 14/03/2006 a écrit :
[...]

ha, programmeur fainéant peut il etre un bon programmeur ? :-)

Bien sûr que oui. Et même, la flemme est sans doute LE moteur de toute
activité technique. Non ?

--
Pierre Maurette

"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:mn.73ea7d63169e9942.31483@laposte.net...

Vincent Burel, le 14/03/2006 a écrit :
[...]
> ha, programmeur fainéant peut il etre un bon programmeur ? :-)
Bien sûr que oui. Et même, la flemme est sans doute LE moteur de toute
activité technique. Non ?

ben ca se discute. Si l'on invente pour se soulager d'une tache (donc pour
satisfaire à une certaine fainéantise), dans la pratique fabriquer la dites
invention n'est pas de tout repos... Pour ma part, je trouve que le
programmeur fainéant a tendance à générer deux fois plus de problèmes qu''il
apporte de solutions. Notons que générer du travail de cette manière est
d'ailleurs le premier revenu de l'informatique (créer des problèmes pour
vendre des solutions).

VB

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in
news:dv628e$5gt$1@biggoron.nerim.net:

Quel est l'outil que vous utilisez?

Il s'agit de l'activex Mozilla. C'est un composant ATL tout bête mais qui
nécessite la compilation de *tout* Mozilla et c'est assez galère à
configurer cette usine à gaz là.

Le dit composant m'arrive sur un plateau grâce au système de nightly
builds du projet Mozilla et je voulais juste changer son GUID pour
pouvoir m'en servir.

Séraphin dirait que la paresse, ça s'organise. Philippe Kahn disait
qu'un bon développeur est un développeur obsédé, moi je dirais plutôt
que c'est quelqu'un qui a "l'intelligence de la paresse" ou la "paresse
intelligente".

Oui justement l'idée c'est de réfléchir avant de foncer... Je me fais
peut-être des idées mais mon petit doigt me dit que ce n'est pas une
opération triviale.

rien n'empêche d'enregistrer à la volée juste avant de demander
une instanciation.

Est-ce possible (raisonnable ?) de créer les entrées dans la BDR avec un
GUID différent de celui qui est enregistré dans le composant ? Ça me
semble vraiment hasardeux.

D'où l'avantage de .Net qui ne demande aucun enregistrement préalable,
Vous y viendrez... :-)

Mais dans le fond je ne demande que ça d'ailleurs. Au point où j'en suis,
le framework c'est une goutte d'eau...

Je ne pense pas qu'un Mozilla .net soit près de voir le jour.


Merci
--
Cyrille Szymanski

"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:Xns9787CE04D3813cns2cnsinvalid@212.27.42.202...

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in
news:dv628e$5gt$1@biggoron.nerim.net:

> rien n'empêche d'enregistrer à la volée juste avant de demander
> une instanciation.

Est-ce possible (raisonnable ?) de créer les entrées dans la BDR avec un
GUID différent de celui qui est enregistré dans le composant ? Ça me
semble vraiment hasardeux.

pourquoi vous ne le considérez pas comme une DLL privée (sans l'enregistrer)
vous faite un LoadLibrary et un GetProAdress pour obtenir son
DllGetClassObject... et c'est fini , non ?

VB

Cyrille Szymanski wrote:

rien n'empêche d'enregistrer à la volée juste avant de demander
une instanciation.

Est-ce possible (raisonnable ?) de créer les entrées dans la BDR avec
un GUID différent de celui qui est enregistré dans le composant ? Ça
me semble vraiment hasardeux.

Le fait de créer temporairement une entrée dans la clé CLSID ne pose pas
de problème particulier. De plus, comme le précise Vincent, il est
toujours possible de faire le binding à la main après un chargement
explicite de la DLL. Tout dépend du contexte et des outils utilisés côté
client. Après tout, le but de la manip est de récupérer les interfaces
COM de l'objet en question. Une fois qu'on les a, peu importe comment on
les a obtenues.

Quand on fait un CoCreateInstance, c'est en fait ce qui se passe de
manière automatique. Le système recherche la clé InprocServer32 ou
LocalServer32 pour le CLSID en question, localise le module à charger et
fait un chargement explicite. Le module, au moment du chargement,
enregistre lui-même sa (ou ses) class factory(ies) auprès du système qui
est ensuite capable de réclamer l'instanciation de l'objet et de
récupérer au minimum son interface IUnknown.

Ce que font automatiquement les routines de la bibliothèque COM, on peut
le faire à la main dans un programme mais en bypassant l'étape de
localisation à partir du CLSID puisque l'on sait déjà où se trouve la
DLL. La registry ne sert en fait qu'à rendre le client indépendant de la
localisation effective du composant.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr