Sesame Script

comment lire un kit SDK

Par The Microsoft Scripting Guys

Bienvenue dans Sesame Script, l'article qui s'adresse aux débutants en écriture de scripts. L'objectif de cet article est d'expliquer les bases des scripts Windows pour l'automatisation de l'administration du système. Nous allons fournir les informations dont vous avez besoin pour commencer à écrire et comprendre les scripts, ainsi que pour commencer à modifier ces scripts en fonction de vos besoins. Si un point particulier vous pose problème, dites-le-nous ; vous n'êtes probablement pas seul.

Consultez les archives de Sesame Script afin de voir les précédents articles.

Sur cette page

Qu'est-ce qui pourrait m'intéresser ?
Problèmes de mise en forme
Gras ou italique...
Espaces réservés
Référence de langage : une fois de plus
Avancé : kit SDK WMI
Conclusion

Cet article explique comment décrypter le code des kits SDK (Software Development Kits) et des références de langage. Pour ceux qui débutent totalement, nous allons commencer par expliquer pourquoi vous pourriez être amené à examiner un kit SDK ou une référence de langage.

Qu'est-ce qui pourrait m'intéresser ?

N'est-ce pas l'éternelle question ? Bien, nous allons vous l'expliquer. Le plus simple est de prendre un exemple. Supposons que vous souhaitiez trouver des informations sur un processus particulier. Vous avez exploré le Centre de script et vous avez trouvé un article Hey, Scripting Guy! intitulé « Comment déterminer la date et l'heure de début d'un processus ? » Voici le script qui répond à cette question :

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colProcessList = objWMIService.ExecQuery _
    ("Select * from Win32_Process Where Name = 'notepad.exe'")

For Each objProcess in colProcessList
    Wscript.Echo objProcess.CreationDate
Next

Vous vous dites sans doute « c'est très bien, mais je n'ai pas besoin de savoir la date et l'heure de démarrage du processus, je souhaite connaître le chemin vers le fichier exécutable ayant démarré le processus ». Comment faire en sorte qu'un processus indique le chemin de son fichier exécutable ? Comme vous pouvez le voir dans l'instruction Select de ce code, nous avons trouvé le processus en examinant la classe Win32_Process. Si vous examinez la classe Win32_Process dans le kit SDK WMI, vous pouvez voir que cette classe comporte une longue liste de propriétés :

Cliquez ici afin de voir l'image en taille réelle.

Une fois que nous aurons vu comment lire ce kit SDK, vous pourrez trouver dans cette liste la propriété qui vous donnera le nom et le chemin du fichier exécutable ayant démarré le processus.

Allons-y, arrêtons le suspense. La propriété est ExecutablePath. Remplacez CreationDate dans le script précédent par ExecutablePath ; vous obtenez immédiatement le script souhaité :

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colProcessList = objWMIService.ExecQuery _
    ("Select * from Win32_Process Where Name = 'notepad.exe'")

For Each objProcess in colProcessList
    Wscript.Echo objProcess.ExecutablePath
Next

Comme vous pouvez le voir, en savoir au moins un peu sur les kits SDK peut être pratique. Nous allons donc vous montrer comment démarrer.

Problèmes de mise en forme

Avant d'aborder les kits SDK proprement dits, nous devons faire une digression. Nous allons parler brièvement de la publication Web chez Microsoft.

Comme vous l'avez probablement remarqué, le site Web de Microsoft est volumineux. En fait, il est très volumineux. Il est si volumineux qu'il doit être fractionné en de très nombreuses sections, et beaucoup de gens sont responsables de ces différentes sections. Par exemple, il existe une section MSDN (constituée de beaucoup de sections plus petites) et d'une section TechNet (également constituée de beaucoup de sections plus petites). Ces différentes sections sont gérées différemment. Différents outils et modèles sont utilisés pour créer et publier du contenu Web.

Vous vous demandez sans doute pourquoi nous vous expliquons cela. Nous avons une bonne raison : nous nous excusons par avance de ce que vous allez voir. Les membres de Scripting Guys sont très forts pour faire des excuses, nous considérons cela comme une forme d'art.

Lorsque vous examinez les kits SDK des produits Microsoft, vous accédez souvent à MSDN. Voici un exemple de ce que vous pouvez voir :

Cliquez ici afin de voir l'image en taille réelle.

Cette page affiche la définition de la méthode Terminate de la classe Win32_Process. Avez-vous remarqué le gras et l'italique dans la section de code ? C'est ici que commencent les excuses. Étant donné que MSDN cible les développeurs, leur site Web est optimisé pour afficher la syntaxe du code et ce genre de choses. TechNet, à l'inverse, ne s'adresse pas souvent aux développeurs, mais plutôt aux professionnels de l'informatique tels que vous. Ils font un gros travail de fourniture d'informations aux administrateurs système et présentent ces informations de façon claire. Nous utilisons cependant parfois leur travail, puisqu'ils hébergent le Centre de script. Ce qu'ils ne font pas parfaitement, c'est fournir des modèles qui affichent la syntaxe du code. Cela signifie que nous ne pouvons pas reproduire ici le gras et l'italique que vous voyez sur MSDN. Nous allons donc inclure quelques graphiques et expliquer ce qui se passe du mieux que nous pouvons.

Revenons à présent au sujet de cet article : la lecture de documents de référence.

Gras ou italique...

Il existe quelques règles de syntaxe élémentaires qui sont généralement suivies de manière globale.

1. Les éléments en gras doivent être entrés exactement tels qu'indiqués dans la syntaxe.

2. Les éléments en italique sont soit des espaces réservés, qui doivent être remplacés par les valeurs réelles ou par les variables de votre script, soit des éléments facultatifs, en fonction de la référence.

3. Les éléments entre crochets ([]) sont facultatifs.

4. Le texte brut indique généralement un espace réservé.

Cela vous semble effrayant ? Amusons-nous d'abord un peu. Avez-vous déjà entendu parler de Mad Libs® ? Mad Libs est un jeu dans lequel il manque des substantifs, des verbes, des adjectifs, etc. Vous demandez à quelqu'un de fournir ces mots, vous les mettez à leur place, puis vous lisez l'histoire obtenue. Faisons un essai :

• Pensez à un substantif.

• Pensez à un verbe (au passé).

• Pensez à un autre substantif.

Placez à présent ces mots dans la phrase suivante :

The substantifverbe overthe substantif .

La phrase finale était-elle « The cow jumped over the moon » ? Probablement pas. Mais c'est ce qui rend le jeu Mad Libs rigolo.

Le fait de placer des variables dans une instruction VBScript n'est pas aussi rigolo, mais fonctionne de la même façon. Examinons la syntaxe de notre vieil ami Wscript.Echo, tel qu'illustré dans Windows Script Host Reference :

La première partie de l'instruction, object, n'est pas en gras, donc vous n'allez pas taper le mot object tel quel. Vous devez remplacer cette instruction par un objet réel. La partie suivante de l'instruction est l'appel de la méthode Echo. Comme vous pouvez le voir, Echo est en gras. Sur la base de la règle 1 ci-dessus, cela signifie que vous allez le taper exactement tel qu'il est indiqué.

Ensuite, nous avons [Arg1]. D'après la règle 3, nous savons que tout ce qui se trouve entre crochets est facultatif ; vous n'avez donc pas besoin d'ajouter quelque chose après Echo. Mais si vous souhaitez afficher quelque chose, vous devez l'indiquer à la place de Arg1. Arg1 n'est pas en gras ; vous n'allez donc pas taper simplement Arg1 dans votre script, vous devez le remplacer par un argument réel. En outre, les crochets ne servent qu'à indiquer que Arg1 est facultatif, vous n'avez pas besoin de taper les crochets dans votre script.

Après [Arg1] nous avons [,Arg2], [,Arg3] et des points de suspension (...). Les virgules permettent d'indiquer que si vous avez un deuxième argument (Arg2), vous devez le faire précéder d'une virgule afin de séparer Arg1 et Arg2. Là encore, vous devez remplacer Arg2 par un argument réel, et vous ne tapez pas les crochets. Il en va de même de Arg3. Les points de suspension indiquent que vous pouvez ajouter autant d'arguments que vous le souhaitez. S'il n'y avait pas de points de suspension, vous seriez limité au nombre d'arguments réellement affichés, à savoir trois arguments dans le cas présent.

Par conséquent, plutôt que

object.Echo [Arg1] [,Arg2] [,Arg3] …

vous taperez quelque chose comme cela :

Wscript.Echo "test" ,"script"

Dans ce cas, Wscript est votre objet, Echo est tapé exactement comme indiqué dans la syntaxe, « test » remplace [Arg1] et « script » remplace [,Arg2]. Voici la sortie :

"test","script"
"test" ,"script"
"test"    ,    "script"

Vous avez peut-être remarqué que l'instruction de la syntaxe ne comportait pas d'italique (mentionné dans la règle 2). Cela tient uniquement au fait que Windows Script Host Reference ne les utilise pas dans ses instructions de syntaxe. Des ensembles de référence différents utilisent des normes différentes. Pour illustrer cela, voici un exemple tiré de ActiveX Data Objects Reference :

Ne vous préoccupez pas trop des incohérences. Une fois que vous aurez passé un peu de temps sur ces références, vous les comprendrez mieux, et les petites différences vous paraîtront moins déroutantes.

Espaces réservés

Vous vous demandez probablement comment nous savions que l'objet devait être Wscript, et comment nous avons pu remplacer les chaînes Arg1 et Arg2. Simple : la référence nous l'a indiqué. Examinez la section suivante de WSH Reference afin de voir la méthode Echo :

Nous pouvons voir que l'objet est défini comme l'objet Wscript. Nous savons donc que object.Echo est toujours Wscript.Echo. Comme pour les arguments, la référence nous indique qu'ils sont facultatifs et qu'ils doivent contenir les chaînes que nous souhaitons afficher.

Référence de langage : une fois de plus

Nous allons examiner rapidement un autre exemple simple. Cette fois-ci, nous allons utiliser la fonction DateAdd, trouvée dans VBScript Language Reference.

Cette fonction ajoute une valeur à une date et renvoie une nouvelle date. Comment utiliser cette fonction pour faire cela ? Nous pouvons voir la partie en gras ; commençons par celle-ci :

DateAdd( )

Nous verrons ensuite interval. Lorsque nous examinons la description d'interval dans la section Arguments, nous voyons qu'il s'agit d'une chaîne. Cependant, si nous poursuivons la lecture, nous voyons que cette chaîne doit être une valeur d'un ensemble défini plus loin dans la documentation. Nous allons y revenir dans un moment.

Nous avons à présent besoin d'un nombre. Dans la section Arguments, nous voyons que c'est le nombre que nous souhaitons ajouter à la date. Supposons que nous souhaitions ajouter cinq à la date. Cinq quoi ? Nous allons y revenir concernant le paramètre interval. Voici ce que nous avons maintenant :

DateAdd( , 5, )

Le dernier élément illustré est date. La description indique : « Variant ou littéral qui représente la date à laquelle interval est ajouté ». Nous avons vu dans l'article précédent que toutes les variables VBScript sont des Variants, donc nous n'en savons pas beaucoup plus. Mais la description indique qu'il s'agit d'une date, donc nous devons saisir une date :

DateAdd( , 5, "10/10/2006")

Pourquoi avons-nous mis des guillemets autour de la date ? Parce que si nous ne l'avions pas fait, VBScript aurait dû deviner le type de données et voir que non seulement cette valeur comporte des chiffres, mais que nous effectuons une division dessus ; ce doit donc être un nombre. Il divise consciencieusement les nombres 10, 10 et 2006, et la date est un peu différente de ce que vous attendez.

Revenons à présent au premier argument, interval. Si nous pousuivons la lecture de la documentation, nous voyons une section intitulée Paramètres :

Cliquez ici afin de voir l'image en taille réelle.

Cette section indique les valeurs de chaîne que nous pouvons intégrer à notre fonction. Supposons que nous souhaitions ajouter cinq années à notre date ; l'intervalle doit donc être exprimé en années. Conformément aux paramètres, la chaîne interval pour année est « yyyy » ; l'appel de la fonction se présente donc comme suit :

DateAdd("yyyy", 5, "10/10/2006")

Nous avons terminé, non ? Euh… attendez une minute, où est la nouvelle date ? Nous devons pour cela revenir au début de la documentation et voir que, au-dessus de la syntaxe, il est précisé que cette fonction renvoie une date. Cela signifie que pour obtenir la date, nous devons affecter la sortie de cette fonction à une variable :

newDate = DateAdd("yyyy", 5, "10/10/2006")

Et voilà. Vous venez d'utiliser la référence VBScript pour ajouter un intervalle spécifié à une date. N'oubliez pas que vous pouvez utiliser ces variables pour une quelconque de ces valeurs. Voici un script complet qui fait cela et qui affiche la nouvelle date :

dtOldDate = "10/10/2006"
iTimeToAdd = 5
strInterval = "yyyy"

dtNewDate = DateAdd(strInterval, iTimeToAdd, dtOldDate)

Wscript.Echo dtNewDate

Avancé : kit SDK WMI

Passons à quelque chose de plus compliqué et essayons un exemple du kit SDK Windows Management Instrumentation. Nous allons supposer que vous avez déjà travaillé avec WMI et que vous comprenez lorsque nous disons que l'instruction suivante est liée au service WMI sur l'ordinateur local :

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Nous n'allons donc pas expliquer comment trouver la classe, la méthode ou la propriété dont vous avez besoin. C'est une vaste question à laquelle il n'est pas simple de répondre. En fait, il n'y a même pas de bonne réponse. Nous allons supposer que vous avez trouvé ce que vous cherchiez et que vous souhaitez examiner le kit SDK afin de déterminer comment l'utiliser. Passons à présent aux choses sérieuses.

Dans nos exemples précédents, nous avons accédé directement aux méthodes que nous souhaitions appeler. Dans WMI, nous allons commencer par la classe. En effet, toutes les propriétés et méthodes WMI sont associées à une classe. Une fois que nous avons la classe, nous pouvons utiliser le kit SDK pour déterminer les propriétés et méthodes qui existent sur cette classe, et comment les utiliser. Reportez-vous à l'article Classe dans une session pour une description des classes, propriétés et méthodes, ainsi que de la relation entre elles.

Classe Win32_Service

Pour cet exemple, nous allons examiner comment extraire l'état des services qui s'exécutent sur un ordinateur. Nous allons faire cela avec un script tel que le suivant :

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colRunningServices = objWMIService.ExecQuery("Select * from Win32_Service")

For Each objService in colRunningServices 
    Wscript.Echo objService.DisplayName  & VbTab & objService.State
Next

Notez que nous interrogeons l'objet Win32_Service. Notre requête renvoie une collection de tous les objets Win32_Service de l'ordinateur, dans lesquels nous effectuons un bouclage, puis nous affichons les propriétés DisplayName et State de ces services. Reportez-vous à l'article Thrown for a Loop pour plus d'informations sur le bouclage dans des collections.

Propriétés de Win32_Service

Comment savons-nous quelles propriétés sont nécessaires ? En examinant le kit SDK WMI, bien entendu.

Cliquez ici afin de voir l'image en taille réelle.

Le kit SDK affiche la définition de la classe Win32_Service. Examinons la première ligne :

class Win32_Service : Win32_BaseService

Le premier élément de la ligne, à savoir class, indique que Win32_Service est une classe. Je parie que vous auriez pu le trouver vous-même. Le deuxième élément est le nom de la classe, à savoir Win32_Service.

Vous trouverez ensuite un signe deux-points (:) suivi de Win32_BaseService. Qu'est-ce que c'est ? Précisons tout d'abord que vous pouvez sans problème ignorer cette partie de l'instruction. Si vous le souhaitez, vous pouvez même ignorer la suite de ce paragraphe. Vous êtes toujours là ? Bien, nous allons vous expliquer le secret. Cet élément est la classe à partir de laquelle est dérivé Win32_Service. N'abandonnez pas encore. Dans les langages de programmation tels que C et C++, vous pouvez créer des classes qui définissent les propriétés et les méthodes. Mais vous pouvez également créer d'autres classes basées sur (ou dérivées de) ces classes. La nouvelle classe hérite de toutes les propriétés et méthodes de la classe d'origine, et elle peut également ajouter ses propres propriétés et méthodes. Elle peut même créer une propriété ou une méthode qui remplace la même propriété ou méthode de la classe parent. En bref, Win32_Service est une copie de Win32_BaseService avec quelques modifications et ajouts aux propriétés et méthodes. Par conséquent, Win32_BaseService est la classe parent de Win32_Service, ou en langage de programmation correct, Win32_Service est dérivé de Win32_BaseService.

Pour ceux qui ont fait une pause café, la pause est terminée, vous pouvez revenir.

La ligne suivante de l'instruction est une accolade ouvrante ({). Vous trouverez une accolade fermante (}) à la fin de l'instruction (suivie d'un point-virgule). Il s'agit de la syntaxe standard pour définir un bloc de code dans les langages tels que C et JScript. Ces accoladades indiquent que tout ce qu'elles contiennent est lié à la classe Win32_Service. Un point-virgule définit la fin d'une ligne. Par conséquent, si dans VBScript vous devez placer un caractère de soulignement à la fin de chaque ligne à continuer, dans JScript une ligne est supposée se poursuivre si vous n'y placez pas un point-virgule à la fin.

Les accolades contiennent une liste de toutes les propriétés appartenant à la classe Win32_Service. Chaque propriété est répertoriée avec le type de données en premier, puis le nom de la propriété. Examinons la première propriété :

boolean AcceptPause;

Elle indique que la propriété AcceptPause de la classe Win32_Service contient une valeur booléenne, pouvant être True ou False. Comme vous le savez déjà (du moins si vous avez lu notre précédent article Sesame Script), il est important de connaître le type de données si vous écrivez des scripts VBScript, de façon à savoir quel type de données est attendu lors de la lecture d'une propriété, ainsi que le type de données requis pour l'écriture d'une propriété. En outre, le type de données indique si la propriété renvoie une valeur unique ou un tableau. Cela s'avère très important, car si vous extrayez la valeur d'une propriété et que vous tentez de l'afficher, vous recevez une erreur si cette propriété a renvoyé un tableau. Si la propriété renvoie un tableau, vous devez effectuer un bouclage dans ce tableau et afficher chaque élément individuellement. Vous pouvez savoir qu'une propriété contient un tableau, car le nom de la propriété est suivi de crochets. Par exemple, la propriété InsertionStrings de la classe Win32_NTLogEvent renvoie un tableau et est définie de la façon suivante :

string InsertionStrings[];

Étant donné qu'aucun des noms de propriété de la définition de la classe Win32_Service n'est suivi de crochets, nous savons qu'aucun n'est un tableau. Nous savons également que toutes les propriétés de la classe Win32_Service sont en lecture seule. Comment le savons-nous ? Là encore, c'est le kit SDK qui l'indique. Il existe deux façons de déterminer si une propriété est en lecture seule ou en lecture-écriture. La première consiste simplement à cliquer sur le nom de la propriété dans le kit SDK. Cela permet d'afficher une petite fenêtre qui décrit la propriété. Comme vous pouvez le voir, le type d'accès de la propriété AcceptPause est lecture seule :

Vous pouvez également faire défiler afin de voir les descriptions des propriétés :

Notez que les descriptions des propriétés sont la fonctionnalité la plus utile du kit SDK. Il est possible d'obtenir des propriétés d'autres sources, telles que Scriptomatic ou Wbemtest.exe. Mais les descriptions indiquent si la propriété est en lecture-écriture ou en lecture seule, et expliquent le type de comportement et d'information que vous pouvez attendre de cette propriété.

Méthodes de Win32_Service

Supposons que vous souhaitiez démarrer un service sur un ordinateur. Vous pouvez utiliser une propriété pour déterminer si le service a été démarré (avec la propriété Started), mais vous ne pouvez pas utiliser une propriété pour effectuer une action, telle que démarrer un service. Pour cela, vous avez besoin d'une méthode. La classe Win32_Service comporte plusieurs méthodes :

Cliquez ici afin de voir l'image en taille réelle.

Il doit être relativement évident de déterminer celle que nous souhaitons utiliser pour démarrer un service : StartService. Si nous cliquons sur la méthode StartService de l'écran précédent, nous obtenons la définition complète de cette méthode :

Cliquez ici afin de voir l'image en taille réelle.

Comme vous pouvez le voir, la méthode est définie comme suit :

uint32 StartService()

Le premier élément de la définition est un type de données : uint32. Il indique le type de valeur qui sera renvoyé par l'appel de la méthode. Autrement dit, lorsque vous appelez StartService pour démarrer un service et lorsque l'appel est terminé, vous recevez un nombre (entier 32 bits dans le cas présent) en retour. Vous pouvez ensuite examiner la section Valeurs renvoyées de la documentation afin de déterminer ce que représentent les valeurs que vous pouvez recevoir. Dans ce cas, si vous appelez StartService et que la valeur renvoyée est 0, vous savez que l'appel a réussi. Si vous recevez 10, cela signifie que la tentative de démarrage du service a échoué parce que ce service était déjà démarré.

En revenant à la définition de la méthode (ou plus précisément à la déclaration de la méthode), vous voyez que le nom de la méthode est suivi de parenthèses ouvrantes et fermantes (). Vous savez ainsi que vous n'avez pas besoin de transmettre des informations à StartService pour que la méthode s'exécute. Cela semble normal pour cette méthode : vous connaissez déjà le service, car vous appelez la méthode StartService sur l'objet service que vous souhaitez démarrer ; par conséquent, aucune autre information n'est nécessaire. Juste pour voir comment cela fonctionne, voici un script qui démarre le service Smart Card et qui affiche la valeur renvoyée par la méthode StartService :

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colServiceList = objWMIService.ExecQuery _
    ("Select * from Win32_Service where Name='SCardSvr'")

For Each objService in colServiceList
    errReturn = objService.StartService()
    Wscript.Echo errReturn
Next

Plus de méthodes Win32_Service

Lorsque nous disons « plus », nous voulons en fait dire « une de plus », car cet article commence à être long et c'est presque l'heure du déjeuner.

La méthode StartService que nous venons d'examiner ne comportait aucun paramètre. Comme nous l'avons dit, cela signifie que StartService n'avait pas besoin d'informations complémentaires pour s'exécuter. Ce n'est pas le cas de beaucoup d'autres méthodes. Examinons par exemple la méthode ChangeStartMode de la classe Win32_Service.

Cliquez ici afin de voir l'image en taille réelle.

uint32 ChangeStartMode(
  string StartMode
);

Comme dans le cas de la méthode StartService, la méthode ChangeStartMode renvoie uint32, un nombre. Et tout comme StartService, le kit SDK indique les valeurs possibles qui peuvent être renvoyées, ainsi que leur signification.

La différence entre ChangeStartMode et StartService devient claire lorsque vous regardez à l'intérieur des parenthèses. StartService était suivi de parenthèses vides, ce qui signifie qu'il n'accepte aucun paramètre. En revanche, ChangeStartMode contient une valeur dans les parenthèses :

string StartMode

Cela semble-t-il familier ? Cela vous rappelle peut-être les propriétés que nous avons examinées précédemment. La déclaration est la même : un type de données suivi d'un nom. Dans ce cas, il s'agit du type de données et du nom du paramètre que vous allez transmettre à la méthode.

Revenons en arrière et voyons pourquoi ChangeStartMode comporte un paramètre. Comme vous pouvez le voir dans la page Propriétés du service Smart Card, les services présentent un type de démarrage :

Cliquez ici afin de voir l'image en taille réelle.

Dans l'interface utilisateur, vous pouvez sélectionner Automatique, Manuel ou Désactivé. Lorsque vous changez le type de démarrage (ou le mode de démarrage) à partir d'un script, vous devez indiquer à la méthode ChangeStartMode vers quel mode vous souhaitez passer.

Cela nous ramène au paramètre StartMode. Examinons la description du paramètre StartMode dans le kit SDK. Voici la première ligne de la description :

[in] Start mode of the Windows base service.

La première chose que vous voyez est [in]. Cela indique que StartMode est un paramètre d'entrée. S'il s'agissait d'un paramètre de sortie, la description commencerait par [out]. Tout paramètre d'entrée est un paramètre auquel vous devez attribuer une valeur. Dans notre cas, nous allons donner à ce paramètre une valeur de chaîne (que nous connaissons grâce au type de données du paramètre, vu précédemment), qui spécifie le mode de démarrage. À l'inverse, s'il s'agissait d'un paramètre de sortie, vous placeriez une variable vide dans l'appel de la méthode, et cette dernière remplirait cette variable avec une valeur (elle générerait une valeur).

Vous voyez ensuite un tableau, tel que celui-ci :

Ce tableau spécifie les valeurs que vous pouvez transmettre dans ce paramètre, ainsi que la signification de chacune de ces valeurs. Par exemple, si vous souhaitez empêcher le démarrage d'un service, transmettez à la méthode ChangeStartMode la chaîne « Disabled ». Voici un script qui fait cela :

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colServiceList = objWMIService.ExecQuery _
    ("Select * from Win32_Service where Name='SCardSvr'")

For Each objService in colServiceList
    errReturn = objService.ChangeStartMode("Disabled")
    Wscript.Echo errReturn
Next

C'était simple, non ?

Conclusion

C'est tout pour aujourd'hui. Merci d'avoir suivi notre exploration des références de langage et des kits SDK. N'oubliez pas de jeter les gobelets dans les poubelles en sortant. Et soyez prudent en rentrant chez vous.