est-il possible de patcher un ActiveX pour changer son GUID et ProgID sans
avoir à tout recompiler ?
J'ai vu des programmes qui patchent des CLSID (pour remplacer un composant
par une autre implémentation équivalente) en faisant un tout bête
chercher/remplacer dans les EXE; ils fonctionnenent avec plus ou moins de
succès.
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 ?
Pas bête du tout :-) En fait ça revient tout simplement à réécrire CoCreateInstance() sans passer par la BDR (le noeud du problème est de récupérer un IClassFactory)
Pour ceux que ça intéresse : * LoadLibrary * GetProcAddress("DllGetClassObject") * DllGetClassObject(CLSID, IID_IClassFactory) * classFactory->CreateInstance(NULL, IID)
Merci beaucoup pour cette aide qui m'a économisé quelques journées de travail. -- Cyrille Szymanski
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in
news:441889b7$0$18312$8fcfb975@news.wanadoo.fr:
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 ?
Pas bête du tout :-) En fait ça revient tout simplement à réécrire
CoCreateInstance() sans passer par la BDR (le noeud du problème est de
récupérer un IClassFactory)
Pour ceux que ça intéresse :
* LoadLibrary
* GetProcAddress("DllGetClassObject")
* DllGetClassObject(CLSID, IID_IClassFactory)
* classFactory->CreateInstance(NULL, IID)
Merci beaucoup pour cette aide qui m'a économisé quelques journées de
travail.
--
Cyrille Szymanski
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 ?
Pas bête du tout :-) En fait ça revient tout simplement à réécrire CoCreateInstance() sans passer par la BDR (le noeud du problème est de récupérer un IClassFactory)
Pour ceux que ça intéresse : * LoadLibrary * GetProcAddress("DllGetClassObject") * DllGetClassObject(CLSID, IID_IClassFactory) * classFactory->CreateInstance(NULL, IID)
Merci beaucoup pour cette aide qui m'a économisé quelques journées de travail. -- Cyrille Szymanski
Cyrille Szymanski
"Patrick Philippot" wrote in news:dvb6b0 $1vev$:
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.
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.
J'ai finalement opté pour ce court-circuitage de CoCreateInstance().
La bonne nouvelle c'est que ça m'a pris moins de 5 minutes à mettre en pratique. L'autre bonne nouvelle c'est que le code fait à peine 10 lignes ce qui est un bon point pour la maintenance.
Merci beaucoup pour vos explications claires.
-- Cyrille Szymanski
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in news:dvb6b0
$1vev$1@biggoron.nerim.net:
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.
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.
J'ai finalement opté pour ce court-circuitage de CoCreateInstance().
La bonne nouvelle c'est que ça m'a pris moins de 5 minutes à mettre en
pratique. L'autre bonne nouvelle c'est que le code fait à peine 10 lignes
ce qui est un bon point pour la maintenance.
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.
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.
J'ai finalement opté pour ce court-circuitage de CoCreateInstance().
La bonne nouvelle c'est que ça m'a pris moins de 5 minutes à mettre en pratique. L'autre bonne nouvelle c'est que le code fait à peine 10 lignes ce qui est un bon point pour la maintenance.
Merci beaucoup pour vos explications claires.
-- Cyrille Szymanski
françois
"Arnold McDonald (AMcD)" wrote in message news:44169d81$0$9656$
Patrick Philippot wrote:
> D'où l'avantage de .Net
[...]
> Vous y viendrez... :-) .
J'en doute.
Ca commence a décoller, apres 4 ans de dur démarrage. Beaucoup de nouveaux projets sont en .Net.
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in message
news:44169d81$0$9656$636a55ce@news.free.fr...
Patrick Philippot wrote:
> D'où l'avantage de .Net
[...]
> Vous y viendrez... :-) .
J'en doute.
Ca commence a décoller, apres 4 ans de dur démarrage.
Beaucoup de nouveaux projets sont en .Net.
"Arnold McDonald (AMcD)" wrote in message news:44169d81$0$9656$
Patrick Philippot wrote:
> D'où l'avantage de .Net
[...]
> Vous y viendrez... :-) .
J'en doute.
Ca commence a décoller, apres 4 ans de dur démarrage. Beaucoup de nouveaux projets sont en .Net.
Patrick Philippot
françois wrote:
Ca commence a décoller, apres 4 ans de dur démarrage.
En France. Ailleurs, cela a été plus vite. Il est vrai que nous sommes coutumiers du fait: attendre un peu pour voir si les autres se plantent. Mais cette fois-ci nous sommes franchement décalés.
Il y a des raisons structurelles à cela. Aborder .Net, c'est aussi devoir prendre en compte des sujets traditionnellement négligés chez nous et en particulier la programmation orientée objet. .Net, c'est de l'objet ou rien. Ceux qui n'ont pas cette culture doivent s'y former avant de bénéficier pleinement de l'infrastructure .Net. XML est également présent à tous les niveaux de .Net. Pour les gros projets, UML ou une méthodologie objet seront nécessaires.
Devant l'effort de formation qui en découle, beaucoup d'entreprises ont longtemps reculé. Ce qui n'a fait qu'amplifier le problème. Mais effectivement, il semblerait que ça se décoince.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
françois wrote:
Ca commence a décoller, apres 4 ans de dur démarrage.
En France. Ailleurs, cela a été plus vite. Il est vrai que nous sommes
coutumiers du fait: attendre un peu pour voir si les autres se plantent.
Mais cette fois-ci nous sommes franchement décalés.
Il y a des raisons structurelles à cela. Aborder .Net, c'est aussi
devoir prendre en compte des sujets traditionnellement négligés chez
nous et en particulier la programmation orientée objet. .Net, c'est de
l'objet ou rien. Ceux qui n'ont pas cette culture doivent s'y former
avant de bénéficier pleinement de l'infrastructure .Net. XML est
également présent à tous les niveaux de .Net. Pour les gros projets, UML
ou une méthodologie objet seront nécessaires.
Devant l'effort de formation qui en découle, beaucoup d'entreprises ont
longtemps reculé. Ce qui n'a fait qu'amplifier le problème. Mais
effectivement, il semblerait que ça se décoince.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Ca commence a décoller, apres 4 ans de dur démarrage.
En France. Ailleurs, cela a été plus vite. Il est vrai que nous sommes coutumiers du fait: attendre un peu pour voir si les autres se plantent. Mais cette fois-ci nous sommes franchement décalés.
Il y a des raisons structurelles à cela. Aborder .Net, c'est aussi devoir prendre en compte des sujets traditionnellement négligés chez nous et en particulier la programmation orientée objet. .Net, c'est de l'objet ou rien. Ceux qui n'ont pas cette culture doivent s'y former avant de bénéficier pleinement de l'infrastructure .Net. XML est également présent à tous les niveaux de .Net. Pour les gros projets, UML ou une méthodologie objet seront nécessaires.
Devant l'effort de formation qui en découle, beaucoup d'entreprises ont longtemps reculé. Ce qui n'a fait qu'amplifier le problème. Mais effectivement, il semblerait que ça se décoince.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
