J'aurais aimé savoir s'il y avait un moyen, qui fonctionne aussi bien
sur NT 4.0 que sur XP, 2000, 2003 (donc pas la ToolHelp library), de
réccupérer le nom d'un process à partir de son PID?
J'ai bien réccupéré un bout de code qui fait ça, mais si l'utilisateur
qui l'exécute n'est pas administrateur, alors certains process ne sont
pas accéssibles (comme Winlogon par exemple).
Le code en question fait un OpenProcess avec les flags
PROCESS_QUERY_INFORMATION et PROCESS_VM_READ avant de faire un
EnumProcessModules suivi d'un GetModuleFileNameEx.
Ce qui ne marche pas pour un utilisateur lamba (enfin pas sur tous les
process), c'est le PROCESS_VM_READ.
Je me dit qu'il doit quand même bien y avoir moyen de réccupérer une
info aussi idiote que le nom du process... même quand l'utilisateur n'a
pas de préivilèges particulier... non?
Ce qui me fait penser ça, c'est que l'outil Process Explorer (pris sur
sysinternals) y arrive bien lui... je dois passer à côté de quelque chose :(
Je n'ai malheureusement aucun contrôle sur l'authentification des utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun pouvoir puisse executer mon programme et lister (et nommer, puisque c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess ne plantera pas pour tous les processus, je pense. Ceux pour lesquels l'autorisation ne sera pas accordée sont peut-être moins importants pour l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je vérifie...
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Fred wrote:
Je n'ai malheureusement aucun contrôle sur l'authentification des
utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun
pouvoir puisse executer mon programme et lister (et nommer, puisque
c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess
ne plantera pas pour tous les processus, je pense. Ceux pour lesquels
l'autorisation ne sera pas accordée sont peut-être moins importants pour
l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une
version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je
vérifie...
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je n'ai malheureusement aucun contrôle sur l'authentification des utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun pouvoir puisse executer mon programme et lister (et nommer, puisque c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess ne plantera pas pour tous les processus, je pense. Ceux pour lesquels l'autorisation ne sera pas accordée sont peut-être moins importants pour l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je vérifie...
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Fred
Patrick Philippot a écrit :
Fred wrote:
Je n'ai malheureusement aucun contrôle sur l'authentification des utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun pouvoir puisse executer mon programme et lister (et nommer, puisque c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess ne plantera pas pour tous les processus, je pense. Ceux pour lesquels l'autorisation ne sera pas accordée sont peut-être moins importants pour l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je vérifie...
OK, merci.
Sinon, j'avais pensé à l'utilisation de la fonction ZwQuerySystemInformation... Est ce que ça pourrait me sortir d'affaire?
Je me dit qu'il doit bien y avoir une solution puisque Process Explorer y arrive bien.
Merci encore.
Fred
Patrick Philippot a écrit :
Fred wrote:
Je n'ai malheureusement aucun contrôle sur l'authentification des
utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun
pouvoir puisse executer mon programme et lister (et nommer, puisque
c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess
ne plantera pas pour tous les processus, je pense. Ceux pour lesquels
l'autorisation ne sera pas accordée sont peut-être moins importants pour
l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une
version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je
vérifie...
OK, merci.
Sinon, j'avais pensé à l'utilisation de la fonction
ZwQuerySystemInformation... Est ce que ça pourrait me sortir d'affaire?
Je me dit qu'il doit bien y avoir une solution puisque Process Explorer
y arrive bien.
Je n'ai malheureusement aucun contrôle sur l'authentification des utilisateurs. Il faut bien, dans mon cas, qu'un utilisateur sans aucun pouvoir puisse executer mon programme et lister (et nommer, puisque c'est ce dernier point qui m'interesse) tous les process du système...
Bien. Je ne suis pas sûr qu'il y ait une solution. En fait, OpenProcess ne plantera pas pour tous les processus, je pense. Ceux pour lesquels l'autorisation ne sera pas accordée sont peut-être moins importants pour l'utilisateur lambda?
J'ai posé la question sur le forum privé MS concernant l'existence d'une version NT 4 de TOOLHELP.DLL. Je ne pense pas que ça existe mais je vérifie...
OK, merci.
Sinon, j'avais pensé à l'utilisation de la fonction ZwQuerySystemInformation... Est ce que ça pourrait me sortir d'affaire?
Je me dit qu'il doit bien y avoir une solution puisque Process Explorer y arrive bien.
Merci encore.
Fred
Patrick Philippot
Fred wrote:
Sinon, j'avais pensé à l'utilisation de la fonction ZwQuerySystemInformation... Est ce que ça pourrait me sortir d'affaire? Je me dit qu'il doit bien y avoir une solution puisque Process Explorer y arrive bien.
Process Explorer utilise effectivement largement les fonctions natives. Dans son bouquin sur "Windows NT/2000 Native API Reference", Gary Nebbett présente même un exemple de l'utilisation de ZwQuerySystemInformation pour recréer une implémentation partielle de Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait partie des ouvrages archaïques livrés sans CD et non supportés sur un site quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc pas vous envoyer cet exemple.
Ceci étant, les explications concernant l'utilisation de cette seule fonction occupent quasiment tout le premier chapitre et il y a de nombreuses restrictions. Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Fred wrote:
Sinon, j'avais pensé à l'utilisation de la fonction
ZwQuerySystemInformation... Est ce que ça pourrait me sortir
d'affaire?
Je me dit qu'il doit bien y avoir une solution puisque Process
Explorer y arrive bien.
Process Explorer utilise effectivement largement les fonctions natives.
Dans son bouquin sur "Windows NT/2000 Native API Reference", Gary
Nebbett présente même un exemple de l'utilisation de
ZwQuerySystemInformation pour recréer une implémentation partielle de
Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait partie
des ouvrages archaïques livrés sans CD et non supportés sur un site
quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc pas vous
envoyer cet exemple.
Ceci étant, les explications concernant l'utilisation de cette seule
fonction occupent quasiment tout le premier chapitre et il y a de
nombreuses restrictions. Utiliser ces techniques dans un programme de
production me semble donc aventureux (avez-vous noté que Process
Explorer se plante de temps en temps?).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Sinon, j'avais pensé à l'utilisation de la fonction ZwQuerySystemInformation... Est ce que ça pourrait me sortir d'affaire? Je me dit qu'il doit bien y avoir une solution puisque Process Explorer y arrive bien.
Process Explorer utilise effectivement largement les fonctions natives. Dans son bouquin sur "Windows NT/2000 Native API Reference", Gary Nebbett présente même un exemple de l'utilisation de ZwQuerySystemInformation pour recréer une implémentation partielle de Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait partie des ouvrages archaïques livrés sans CD et non supportés sur un site quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc pas vous envoyer cet exemple.
Ceci étant, les explications concernant l'utilisation de cette seule fonction occupent quasiment tout le premier chapitre et il y a de nombreuses restrictions. Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AMcD®
Patrick Philippot wrote:
Process Explorer utilise effectivement largement les fonctions natives.
Plus des drivers perso. Le code pondu par Russinovich, heu c'est pas du VB hein...
Dans son bouquin sur "Windows NT/2000 Native API Reference", Gary Nebbett présente même un exemple de l'utilisation de ZwQuerySystemInformation pour recréer une implémentation partielle de Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait partie des ouvrages archaïques
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas de CD ? Je préfère un bouquin sans CD à prix abordable à un bouquin avec CD rempli de trucs à la con qui n'ont aucun intérêt et que tu charges partout sur le Net.
livrés sans CD et non supportés sur un site quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc pas vous envoyer cet exemple.
Ce livre montre des exemples d'implémentations, c'est vrai. Mais je conseille tout de même d'écrire les siennes, le style de programmation de l'ami Nebbett est un peu lourdingue et tu vas aussi vite d'écrire par toi-même en utilisant son bouquin comme manuel de référence des fonctions. Concernant l'API native, il n'y a qu'un artcile de Russinovich sur le Net, en anglais et 2-3 autres trucs sans intérêts, en anglais aussi. En français, un article également. De moi :-). Je ne l'héberge plus, mais on le trouve facilement sur le Net.
Ceci étant, les explications concernant l'utilisation de cette seule fonction occupent quasiment tout le premier chapitre et il y a de nombreuses restrictions.
Tout à fait. Ce n'est pas du "simple".
Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe encore. Un bon article ici : http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même, il faut éviter les magouilles utilisant les fonctions non-officielle (oui, c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal de restrictions au niveau du code. En clair, il y a des choses qu'on ne pourra pas faire.
-- AMcD®
http://arnold.mcdonald.free.fr/
Patrick Philippot wrote:
Process Explorer utilise effectivement largement les fonctions
natives.
Plus des drivers perso. Le code pondu par Russinovich, heu c'est pas du VB
hein...
Dans son bouquin sur "Windows NT/2000 Native API Reference",
Gary Nebbett présente même un exemple de l'utilisation de
ZwQuerySystemInformation pour recréer une implémentation partielle de
Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait
partie des ouvrages archaïques
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas de CD
? Je préfère un bouquin sans CD à prix abordable à un bouquin avec CD rempli
de trucs à la con qui n'ont aucun intérêt et que tu charges partout sur le
Net.
livrés sans CD et non supportés sur un
site quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc
pas vous envoyer cet exemple.
Ce livre montre des exemples d'implémentations, c'est vrai. Mais je
conseille tout de même d'écrire les siennes, le style de programmation de
l'ami Nebbett est un peu lourdingue et tu vas aussi vite d'écrire par
toi-même en utilisant son bouquin comme manuel de référence des fonctions.
Concernant l'API native, il n'y a qu'un artcile de Russinovich sur le Net,
en anglais et 2-3 autres trucs sans intérêts, en anglais aussi. En français,
un article également. De moi :-). Je ne l'héberge plus, mais on le trouve
facilement sur le Net.
Ceci étant, les explications concernant l'utilisation de cette seule
fonction occupent quasiment tout le premier chapitre et il y a de
nombreuses restrictions.
Tout à fait. Ce n'est pas du "simple".
Utiliser ces techniques dans un programme de
production me semble donc aventureux (avez-vous noté que Process
Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe
encore. Un bon article ici :
http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même,
il faut éviter les magouilles utilisant les fonctions non-officielle (oui,
c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce
n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas
avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal
de restrictions au niveau du code. En clair, il y a des choses qu'on ne
pourra pas faire.
Process Explorer utilise effectivement largement les fonctions natives.
Plus des drivers perso. Le code pondu par Russinovich, heu c'est pas du VB hein...
Dans son bouquin sur "Windows NT/2000 Native API Reference", Gary Nebbett présente même un exemple de l'utilisation de ZwQuerySystemInformation pour recréer une implémentation partielle de Toolhelp.dll. Malheureusement, ce livre, malgré son intérêt, fait partie des ouvrages archaïques
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas de CD ? Je préfère un bouquin sans CD à prix abordable à un bouquin avec CD rempli de trucs à la con qui n'ont aucun intérêt et que tu charges partout sur le Net.
livrés sans CD et non supportés sur un site quelconque (en tous cas, je n'ai pas trouvé). Je ne peux donc pas vous envoyer cet exemple.
Ce livre montre des exemples d'implémentations, c'est vrai. Mais je conseille tout de même d'écrire les siennes, le style de programmation de l'ami Nebbett est un peu lourdingue et tu vas aussi vite d'écrire par toi-même en utilisant son bouquin comme manuel de référence des fonctions. Concernant l'API native, il n'y a qu'un artcile de Russinovich sur le Net, en anglais et 2-3 autres trucs sans intérêts, en anglais aussi. En français, un article également. De moi :-). Je ne l'héberge plus, mais on le trouve facilement sur le Net.
Ceci étant, les explications concernant l'utilisation de cette seule fonction occupent quasiment tout le premier chapitre et il y a de nombreuses restrictions.
Tout à fait. Ce n'est pas du "simple".
Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe encore. Un bon article ici : http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même, il faut éviter les magouilles utilisant les fonctions non-officielle (oui, c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal de restrictions au niveau du code. En clair, il y a des choses qu'on ne pourra pas faire.
-- AMcD®
http://arnold.mcdonald.free.fr/
Patrick Philippot
AMcD® wrote:
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas de CD ?
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne serait-ce que pour les corrections d'erreurs. C'est quand même le minimum de nos jours, non? Et USD $50 en prix de base n'est pas spécialement bon marché :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AMcD® wrote:
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas
de CD ?
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne
serait-ce que pour les corrections d'erreurs. C'est quand même le
minimum de nos jours, non? Et USD $50 en prix de base n'est pas
spécialement bon marché :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
??? Archaïque ??? Qu'est ce qui est archaïque ? Parce qu'il n'y a pas de CD ?
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne serait-ce que pour les corrections d'erreurs. C'est quand même le minimum de nos jours, non? Et USD $50 en prix de base n'est pas spécialement bon marché :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AMcD®
Patrick Philippot wrote:
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne serait-ce que pour les corrections d'erreurs. C'est quand même le minimum de nos jours, non?
Heu, tu dois pas lire beaucoup de livres actuels... :-) Perso, j'en lis environ une douzaine par an, plus ceux que je relis, etc. Les sites de support sont rarissimes. Les liens donnés par les éditeurs sont souvent vides, mis à jour chaque 14e pleine de lune ou... tout simplement bidons ! Ne parlons même pas des CDs fournis parfois...
Et USD $50 en prix de base n'est pas spécialement bon marché :-) .
Tu le trouve partout à 43 $ (ne tient pas compte du prix de base, ça ne veut rien dire). Une fois "transformé" en euros, une quarantaine. Vu les tas de boue qu'on te vends à 50 euros ou bien plus actuellement (genre 350-400 p. de screenshots sur 500 p.), je ne trouve pas ça excessif.
-- AMcD®
http://arnold.mcdonald.free.fr/
Patrick Philippot wrote:
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne
serait-ce que pour les corrections d'erreurs. C'est quand même le
minimum de nos jours, non?
Heu, tu dois pas lire beaucoup de livres actuels... :-) Perso, j'en lis
environ une douzaine par an, plus ceux que je relis, etc. Les sites de
support sont rarissimes. Les liens donnés par les éditeurs sont souvent
vides, mis à jour chaque 14e pleine de lune ou... tout simplement bidons !
Ne parlons même pas des CDs fournis parfois...
Et USD $50 en prix de base n'est pas
spécialement bon marché :-) .
Tu le trouve partout à 43 $ (ne tient pas compte du prix de base, ça ne veut
rien dire). Une fois "transformé" en euros, une quarantaine. Vu les tas de
boue qu'on te vends à 50 euros ou bien plus actuellement (genre 350-400 p.
de screenshots sur 500 p.), je ne trouve pas ça excessif.
Parce qu'il n'y a même pas de support en ligne chez l'éditeur, ne serait-ce que pour les corrections d'erreurs. C'est quand même le minimum de nos jours, non?
Heu, tu dois pas lire beaucoup de livres actuels... :-) Perso, j'en lis environ une douzaine par an, plus ceux que je relis, etc. Les sites de support sont rarissimes. Les liens donnés par les éditeurs sont souvent vides, mis à jour chaque 14e pleine de lune ou... tout simplement bidons ! Ne parlons même pas des CDs fournis parfois...
Et USD $50 en prix de base n'est pas spécialement bon marché :-) .
Tu le trouve partout à 43 $ (ne tient pas compte du prix de base, ça ne veut rien dire). Une fois "transformé" en euros, une quarantaine. Vu les tas de boue qu'on te vends à 50 euros ou bien plus actuellement (genre 350-400 p. de screenshots sur 500 p.), je ne trouve pas ça excessif.
-- AMcD®
http://arnold.mcdonald.free.fr/
Fred
AMcD® a écrit :
Patrick Philippot wrote:
Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe encore. Un bon article ici : http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même, il faut éviter les magouilles utilisant les fonctions non-officielle (oui, c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal de restrictions au niveau du code. En clair, il y a des choses qu'on ne pourra pas faire.
Certes... j'essaye en effet d'éviter d'utiliser des fonctions non documentées. Mais je ne compte utiliser cette implémentation que sur NT 4.0 (donc peu, voire pas du tout, soumis au changement ou aux services packs) et utiliser la ToolHelp sur XP, 2000 et suivants...
Merci beaucoup en tout cas de l'intêret que vous avez porté à ma queston...
Fred
AMcD® a écrit :
Patrick Philippot wrote:
Utiliser ces techniques dans un programme de
production me semble donc aventureux (avez-vous noté que Process
Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe
encore. Un bon article ici :
http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même,
il faut éviter les magouilles utilisant les fonctions non-officielle (oui,
c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce
n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas
avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal
de restrictions au niveau du code. En clair, il y a des choses qu'on ne
pourra pas faire.
Certes... j'essaye en effet d'éviter d'utiliser des fonctions non
documentées. Mais je ne compte utiliser cette implémentation que sur NT
4.0 (donc peu, voire pas du tout, soumis au changement ou aux services
packs) et utiliser la ToolHelp sur XP, 2000 et suivants...
Merci beaucoup en tout cas de l'intêret que vous avez porté à ma queston...
Utiliser ces techniques dans un programme de production me semble donc aventureux (avez-vous noté que Process Explorer se plante de temps en temps?).
Je partage encore ton avis. Enfin bon, ZwQuerySystemInformation(), passe encore. Un bon article ici : http://www.thecodeproject.com/system/kernelspying.asp. Mais, tout de même, il faut éviter les magouilles utilisant les fonctions non-officielle (oui, c'est bien moi qui dit ça). Ce n'est pas portable, ça change à chaque SP, ce n'est pas supporté, etc. Il vaux mieux s'appuyer sur Win32.
Enfin, si on n'a pas tous les droits administrateurs, si on ne peut pas avoir un contrôle total, ben il ne faut pas rêver, on sera soumis à pas mal de restrictions au niveau du code. En clair, il y a des choses qu'on ne pourra pas faire.
Certes... j'essaye en effet d'éviter d'utiliser des fonctions non documentées. Mais je ne compte utiliser cette implémentation que sur NT 4.0 (donc peu, voire pas du tout, soumis au changement ou aux services packs) et utiliser la ToolHelp sur XP, 2000 et suivants...
Merci beaucoup en tout cas de l'intêret que vous avez porté à ma queston...
