Résumé des conditions nécessaires au bon fonctionnement de Windows

Article
06/17/2008

Sur cette page

Chapitre 1 – Bases d'utilisation de Windows Chapitre 1 – Bases d'utilisation de Windows
Résumé des conditions nécessaires au bon fonctionnement de Windows.
Justification
Avantages pour les clients
Comment se conformer aux exigences fondamentales de Windows
1. Exécutez les fonctionnalités primaires et veillez à assurer la stabilité du système
2. Utilisez des composants 32 bits et documentez les codes éventuels en 16 bits
Comment mener sur vos applications des tests préalables de conformité avec les conditions fondamentales de Windows ?

Chapitre 1 – Bases d'utilisation de Windows

Résumé des conditions nécessaires au bon fonctionnement de Windows.

Justification

En respectant ces conditions, vous pourrez être en grande part assuré du fonctionnement stable et fiable de votre application sur les systèmes d'exploitation Windows.

Avantages pour les clients

Les clients ont la certitude qu'un produit respectant ces conditions n'aura pas d'impact négatif sur la fiabilité du système d'exploitation.

Conditions requises

Exécutez les fonctionnalités primaires et veillez à assurer la stabilité du système
Utilisez des composants 32 bits et documentez les codes éventuels en 16 bits
Assurez la prise en charge des noms de fichiers longs et des chemins d'accès UNC
Assurez la prise en charge des imprimantes possédant un long nom et des chemins d'accès UNC
Évitez formellement de lire ou d'écrire sur les fichiers Win.ini, System.ini, Autoexec.bat ou Config.sys
Assurez-vous que les fichiers non cachés situés en dehors du répertoire de votre application possèdent des types de fichiers associés, et que tous les types de fichiers possèdent des icônes, des descriptions et des actions associées.
Effectuez une vérification correcte de votre version de Windows
Les pilotes en mode noyau doivent avoir été testés
Les pilotes matériels doivent passer les tests WHQL
Les composants client doivent respecter les spécifications des applications bureautiques pour Windows 2000

Références

Utilisation de l'outil Driver Verifier Site en anglais

Procédure générale de test des fonctionnalités et de la stabilité en vue de l'obtention du logo "Certified for Microsoft Windows" Site en anglais

VeriTest-Analyseur rationnel d'installation pour Windows 2000

Utilitaire de liens—Plate-forme SDK de Microsoft

Comment se conformer aux exigences fondamentales de Windows

1. Exécutez les fonctionnalités primaires et veillez à assurer la stabilité du système

Votre application doit exécuter ses fonctionnalités primaires sans compromettre la stabilité du système d'exploitation.

Les fonctions primaires sont les fonctions dont l'importance est telle que leur dysfonctionnement ou leur dégradation rendrait le produit, aux yeux d'un utilisateur normal, impropre à remplir ses objectifs. Par exemple :

Les utilisateurs doivent pouvoir entrer de nouveaux enregistrements, et modifier et supprimer des enregistrements existants dans une application de base de données. Ils doivent être capables d'enregistrer des documents, de les ouvrir par la suite et de les imprimer sur les imprimantes prises en charge.
Les utilisateurs doivent être en mesure d'afficher toutes les ressources prises en charge dans le cadre normal d'une application de gestion de ressources. Ils doivent être en mesure de créer, d'enregistrer, d'ouvrir et d'imprimer tous les états pris en charge.
Les utilisateurs doivent pouvoir afficher les données attendues dans une application de traitement analytique en ligne (OLAP) et effectuer toutes les analyses prises en charge.
Les utilisateurs doivent être en mesure de sauvegarder tous les fichiers, dossiers ou lecteurs pris en charge sur des machines locales ou distantes à partir d'une application de sauvegarde installée sur un serveur.

Pendant que les utilisateurs exécutent les fonctions primaires de votre application, celle-ci ne doit ni se bloquer, ni tomber en panne, ni perdre des données des utilisateurs. Les fonctions primaires ne peuvent devenir inutilisables ou inopérantes, et l'application ne peut interrompre le fonctionnement de Windows ni d'aucune autre application en cours d'exécution sur l'ordinateur.

Les utilisateurs doivent être en mesure d'utiliser les fonctions du système prises en charge par Windows 2000 avec votre application. Par exemple :

Votre application ne doit pas tomber en panne, se bloquer ou perdre des données lorsque des utilisateurs pris en charge se connectent ou se déconnectent du serveur qui l'héberge.
Un utilisateur local doit être à même de copier vers le presse-papier de Windows ou de coller à partir de celui-ci dans d'autres applications lorsque votre application est en cours d'exécution.

Pour en savoir plus sur les fonctions primaires et la stabilité du système, consultez la Procédure de test des fonctionnalités et de la stabilité pour l'obtention du logo "Certified for Microsoft Windows" Site en anglais .

2. Utilisez des composants 32 bits et documentez les codes éventuels en 16 bits

Une application doit être un fichier exécutable 32 bits au format PE (Portable Executable). Ceci signifie que tous les fichiers exécutables, y compris les fichiers de programme DLL (bibliothèques de liens dynamiques) et exécutables (EXE), doivent être des fichiers 32 bits. Vous pouvez tester le format exécutable correct à l'aide de l'utilitaire de liens du Kit du développeur de logiciels pour la plate-forme Microsoft (SDK) ou de l'analyseur d'installation VeriTest-Rational, que vous pouvez télécharger gratuitement.

Si votre application n'est pas présentée sous forme d'un code au format PE, le "moteur d'exécution" doit être un fichier exécutable Win32 au format PE. Par exemple, si vous développez une application dans Microsoft Access, votre application sera un fichier .mdb et non un fichier .exe. Cependant, msaccess.exe est un fichier exécutable Win-32 au format PE.

Important : au moment de soumettre votre produit à un test de conformité, vous devez répertorier le nom de ficher et expliquer en détail l'utilisation des fichiers 16 bits que votre application pourrait installer. Ceci doit se faire dans le Questionnaire du fournisseur électronique que vous renverrez en même temps que votre application.

Remarque : chaque fichier 16 bits doit être testé dans le cadre du processus de certification pour garantir que la stabilité du système n'est pas compromise. Ceci peut augmenter la durée des tests et la facture de l'organisme qui s'en charge. La durée et le coût seront déterminés cas par cas par l'organisme de test.

Dans la mesure du possible, évitez d'utiliser un code en 16 bits, même pour des raisons de compatibilité amont, parce que les versions 64 bits de Windows ne prendront pas en charge le code 16 bits.

3. Assurez la prise en charge des noms de fichiers longs et des chemins d'accès UNC

Si votre application expose les noms de fichiers aux utilisateurs et/ou permet à ces derniers de saisir des noms de fichiers, votre application doit prendre en charge tous les noms de fichiers Win32 valides, y compris les noms de fichiers longs (Long File Names - LFN) et les noms qui suivent la convention universelle (Universal Naming Convention - UNC). Les noms de type LFN et UNC peuvent être plus longs que les noms autorisés par les applications 16 bits de Windows et que les applications héritées sous DOS, et ils peuvent en outre contenir des caractères non autorisés sous Windows 16 bits et sous DOS.

Par exemple, votre application doit reconnaître correctement et afficher les chemins d'accès suivants :

C:\documents et paramètres\utilisateur joe\mes documents\ma lettre.txt

C:\documents et paramètres\Joe [joeutilisateur]\mes documents\Ca$h;flow\ma lettre à André.txt

D:\Notre dossier\projet 10\projet 11\projet 12\projet 13\projet 14\projet 15\ projet 16\projet 17\projet 18\projet 19\projet 20\projet 21\ projet 22\projet 23\projet 24\projet 25\projet 26\projet 27\ projet 28\projet 29\projet 30\nom de fichier.ext

\\serveur\nom de réseau\utilisateur joe\ma lettre.txt

Toutes les fonctions Win32 qui créent, ouvrent, recherchent et enregistrent des fichiers ou des dossiers, utilisent la constante MAX_PATH comme taille maximale du tampon pour les informations de chemin d'accès. Votre application doit permettre aux utilisateurs de créer des fichiers dont le chemin atteint la longueur définie par MAX_PATH, et elle doit ouvrir tous les fichiers pris en charge que l'utilisateur crée, à l'aide de votre application et d'autres, sur des chemins d'accès d'une longueur inférieure ou égale à MAX_PATH. La constante MAX_PATH est définie dans le fichier windef.h de la plate-forme SDK. Dans la plate-forme SDK actuelle, la valeur de MAX_PATH est de "260". Vous devez utiliser le nom de constante MAX_PATH au lieu de coder la valeur dans votre application. L'utilisation du nom en lieu et place de la valeur vous permettra d'adapter rapidement votre application aux futures versions de Windows qui prennent en charge des chemins plus longs mais conservent le même nom de constante.

4. Assurez la prise en charge des imprimantes possédant un long nom et des chemins d'accès UNC

Windows autorise les noms de fichiers longs pour les imprimantes. Si votre application prend en charge l'impression, elle doit accepter des noms d'imprimante pouvant atteindre 220 caractères, et imprimer sur des périphériques portant des noms tels que ceux-ci :

\\PrintServer44.domain.com\Imprimante duplex: numéro 0047 (groupe comptabilité)

Laser couleur – Département recherche et conception IP 123.456.78.9 voir Fred ou Wilma

Remarque : l'usage des virgules et des points d'exclamation n'est pas permis dans les noms d'imprimante.

5. Évitez formellement de lire ou d'écrire sur les fichiers Win.ini, System.ini, Autoexec.bat ou Config.sys

Votre application ne doit rien lire à partir des fichiers Win.ini, System.ini, Autoexec.bat ou Config.sys, et elle ne doit rien y écrire. Ces fichiers ne sont pas utilisés par les systèmes Windows 2000 et certains utilisateurs les suppriment.

6. Assurez-vous que les fichiers non cachés situés en dehors du répertoire de votre application possèdent des types de fichiers associés, et que tous les types de fichiers possèdent des icônes, des descriptions et des actions associées.

Tous les fichiers non cachés que votre application crée en dehors de son répertoire dans le dossier "Program Files" (voir condition 2.3) doivent posséder un type de fichier enregistré associé, à savoir :

Fichiers créés en cours d'installation
Fichiers de mise en œuvre et fichiers de données
Fichiers natifs de l'application créés par l'utilisateur

Si le type de fichier est déjà enregistré, aucune action n'est requise, ce qui ne vous empêche pas de reprendre le type de fichier si vous le souhaitez.

Si le type de fichier n'est pas déjà enregistré, vous devez procéder comme suit pour chaque nouveau type de fichier :

Créer une icône telle qu'aucun des fichiers créés par votre application ne soit identifié par l'icône Windows par défaut.
Créez une description de type convivial, comme par exemple, "Fichier de messagerie hors ligne Outlook".
Vérifiez que chaque type de fichier possède une action associée lorsque vous double-cliquez dessus (par ex. lancer votre application et charger le fichier), ou est désigné comme "NoOpen"

La désignation NoOpen est destinée aux fichiers que vous ne souhaitez pas voir ouvrir par les utilisateurs. Lorsque l'utilisateur double-clique sur un fichier marqué NoOpen, le système d'exploitation crée automatiquement un message qui l'avertit de ne pas ouvrir le fichier. Notez que si une action est associée par la suite à un type de fichier NoOpen, la désignation NoOpen sera ignorée.

Exception : si votre application autorise l'utilisateur à enregistrer ou exporter les types de fichiers qui ne sont pas natifs dans votre application, il peut choisir d'enregistrer un fichier sous un type qui ne possède pas d'association sur son ordinateur. Votre application peut enregistrer le fichier sous la forme requise par l'utilisateur, même si le fichier possède une icône Windows par défaut.

Détails de mise en œuvre

Pour vérifier si une extension est déjà enregistrée :

Sous HKCR, cherchez la clé désignée par les trois caractères (ou plus) de l'extension du fichier, par ex. ".txt". Si la clé représentant cette extension n'existe pas, vous devez l'enregistrer (voir ci-dessous).

Pour enregistrer de nouveaux types de fichiers :

Créez un type de fichier sous HKCR. Le type de fichier est l'identificateur unique de tous les fichiers possédant une certaine extension. Par exemple, "txtfile" est le type des fichiers possédant l'extension .txt. Notez que plusieurs extensions peuvent indiquer le même type de fichier. Par exemple, ".txt" et ".log" indiquent tous deux le même type de fichier, "txtfile". La valeur par défaut de la clé du type de fichier est le "nom convivial ” qui s'affiche dans l'Explorateur. Par exemple, les extensions qui pointent vers la clé "txtfile" ont pour nom convivial, "Document texte".
Sous HKCR, créez une extension à trois caractères ou plus pour votre type de fichier. Nous recommandons d'utiliser 4 ou 5 caractères, de manière à éviter des conflits de types de fichiers et à rendre ceux-ci plus faciles à identifier. Ensuite, définissez la valeur par défaut de l'extension de fichier pour la faire pointer vers le type de fichier que vous venez de créer. Par exemple, la valeur par défaut de ".txt" est le type de fichier "txtfile".

Pour enregistrer une icône pour un type de fichier :

Sous la clé de type de fichier, créez la clé 'DefaultIcon' en tant que type de données REG_SZ ou REG_EXPAND_SZ, et faites-la pointer vers une icône que vous avez créée. Par exemple, la valeur pour "txtfile" est "%SystemRoot%\system32\shell32.dll,-152", qui signifie "utiliser la 152e icône de shell32.dll".

Pour identifier un fichier comme "No Open" :

Sous la clé du type de fichier, ajoutez la valeur "NoOpen" Reg_SZ. Un texte de message personnalisé peut être ajouté à la valeur si vous le souhaitez. Voir la clé "ocxfile" dans HKCR comme exemple.

Exemple : Structure de registre permettant d'associer une extension de fichier ".txt" au type de fichier "Txtfile" :

HKEY_CLASSES_ROOT.txt
     (default)="txtfile"
     HKEY_CLASSES_ROOT \txtfile
     \DefaultIcon
     (default)=%SystemRoot%\system32\shell32.dll,-152
     \shell\open\command
     (default)=%SystemRoot%\system32\NOTEPAD.EXE %1

7. Effectuez une vérification correcte de votre version de Windows

Votre application doit vérifier que le système d'exploitation correspond à la version minimale qu'elle requiert. L'application doit aussi pouvoir être installée et exécutée sur toutes les versions plus récentes de ce système d'exploitation.

Par exemple, si l'application requiert Windows 2000 avec Service Pack 1 (SP1), votre vérification de version doit permettre l'installation sur la Version Majeure 5, Version Mineure 0, SP1, et elle doit aussi pouvoir être installée sur toutes les versions du système d'exploitation portant des numéros supérieurs (telles que Windows 2000 Service Pack 2 (SP2) etc.).

Exception : dans certains cas, il est admis de bloquer l'installation sur des versions ultérieures de Windows. Pour procéder de cette manière, vous devez :

Fournir la documentation nécessaire dans le Questionnaire du fournisseur et expliquer les raisons de ce choix.
Afficher un message lors du blocage de l'installation, indiquant à l'utilisateur que votre application n'est pas conçue pour les versions ultérieures de Windows.

Cette manière de procéder peut se justifier pour des utilitaires de disque de niveau inférieur. Dans ce cas, l'exécution d'une telle application sur une version de Windows plus récente et pour laquelle le produit n'est pas conçu pourrait conduire à la perte de données de l'utilisateur. Il pourrait notamment y avoir des changements du système de fichiers que l'application ne détecterait pas.

Pour les applications qui s'exécutent uniquement sur Windows 2000 et les versions postérieures, nous recommandons d'utiliser l'API VerifyVersionInfo pour déterminer la version du système d'exploitation. Il convient de noter toutefois que cette API n'est pas disponible sur les plates-formes de niveau inférieur. Pour les applications qui s'exécutent aussi sur Windows NT 4, vous devez utiliser l'API GetVersionEx() pour déterminer la version du système d'exploitation. Voir les exemples de code ci-dessous pour des modèles de mise en œuvre.

Exemple de code utilisant VerifyVersionInfo (pour Windows 2000 et au-delà)

L'utilisation de VerifyVersionInfo permet aux applications de déterminer de manière plus fiable si elles peuvent être installées sur un certain système d'exploitation. Auparavant, l'application avait besoin de l'info de version du système d'exploitation pour décider si la version installée répondait à ses exigences. En revanche, VerifyVersionInfo permet à l'application d'indiquer au système d'exploitation la version dont il a besoin, puis de lui demander si la version installée remplit ces conditions. Moins de lignes de code sont requises.

#ifdef Windows2000
     //
     //Cet exemple est destiné à Windows 2000 et aux
    versions ultérieures
     //
     BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor, DWORD
    wSPMajor )
     {
     OSVERSIONINFOEX osvi;
     DWORDLONG dwlConditionMask;
     ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
     osvi.dwOSVersionInfoSize=sizeof(OSVERSIONINFOEX);
     osvi.dwMajorVersion=dwMajor;
     osvi.dwMinorVersion=dwMinor;
     osvi.wServicePackMajor=wSPMajor;
     // Définit le masque de condition.
     VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION,
    VER_GREATER_EQUAL );
     VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION,
    VER_GREATER_EQUAL );
     VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMAJOR,
    VER_GREATER_EQUAL );
     // Exécute le test.
     return VerifyVersionInfo(&osvi,
     VER_MAJORVERSION | VER_MINORVERSION |
    VER_SERVICEPACKMAJOR,
     dwlConditionMask);
     }
     #endif

Exemple de code destiné à la vérification de la version de Windows sur les plates-formes de niveau inférieur

Ce code s'exécute sur toutes les plates-formes 32 bits de Windows. Notez que, si vous vérifiez la version d'un NT4 Service Pack antérieur au Service Pack 4, vous devez aussi interroger la clé suivante du registre pour déterminer le niveau du Service Pack, comme dans cet exemple.

HKLM\system\CurrentControlSet\control\windows\CSDVersion

Les valeurs de CSDVersion seront de 0x100 pour Service Pack 1, 0x200 pour Service Pack 2, etc. Voir ci-dessous l'exemple de code pour déterminer le niveau du Service Pack.

BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor,
    DWORD dwSPMajor )
     {
     OSVERSIONINFO osvi;
     // Initialise la structure OSVERSIONINFO.
     //
     ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
     osvi.dwOSVersionInfoSize=sizeof(OSVERSIONINFO);
     GetVersionEx((OSVERSIONINFO*)&osvi);
     // En premier lieu la version majeure
     if ( osvi.dwMajorVersion > dwMajor )
     return TRUE;
     else if ( osvi.dwMajorVersion== dwMajor )
     {
     // Puis la version mineure
     if (osvi.dwMinorVersion > dwMinor )
     return TRUE;
     else if (osvi.dwMinorVersion== dwMinor )
     {
     // Détermination du niveau du Service Pack
     if ( dwSPMajor &&
     osvi.dwPlatformId== VER_PLATFORM_WIN32_NT )
     {
     HKEY hKey;
     DWORD dwCSDVersion;
     DWORD dwSize;
     BOOL fMeetsSPRequirement=FALSE;
     if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
     "System\\CurrentControlSet\\Control\\Windows",
     0, KEY_QUERY_VALUE, &hKey)== ERROR_SUCCESS)
     {
     dwSize=sizeof(dwCSDVersion);
     if (RegQueryValueEx(hKey, "CSDVersion",
     NULL, NULL,
     (unsigned char*)&dwCSDVersion,
     &dwSize)== ERROR_SUCCESS)
     {
     fMeetsSPRequirement=
     (LOWORD(dwCSDVersion) >= dwSPMajor);
     }
     RegCloseKey(hKey);
     }
     return fMeetsSPRequirement;
     }
     return TRUE;
     }
     }
     return FALSE;
     }

8. Les pilotes en mode noyau doivent avoir été testés

Les pilotes en mode noyau mal écrits peuvent bloquer le système. Il est dès lors essentiel que toute application comportant des pilotes en mode noyau, tels les produits anti-virus, soient testés très soigneusement pour réduire les risques.

Si votre application comprend des pilotes en mode noyau, chacun d'eux devra être validé par l'outil de gestion Windows 2000 Driver Verifier (Verifier.exe). Sur les systèmes Windows 2000, Driver Verifier se trouve dans le dossier \system32. Pour en savoir plus sur l'utilisation du Gestionnaire de Driver Verifier et sur le diagnostic des problèmes de pilotes Site en anglais .

9. Les pilotes matériels doivent passer les tests WHQL

Si votre produit comporte des pilotes de périphérique, ces pilotes doivent être testés par nos laboratoires de qualité du matériel (WHQL – Windows Hardware Quality Labs). Il est à noter que les temps de retour du WHQL peuvent atteindre 30 jours.

10. Les composants client doivent respecter les spécifications des applications bureautiques pour Windows 2000 (Desktop Application Specification for Windows 2000).

Tous les composants client prévus pour Windows 2000 Professionnel et qui accompagnent votre application doivent être conformes aux spécifications des applications bureautiques pour Windows 2000 de sorte que l'application soit intégralement agréée Windows (Certified for Microsoft Windows). Les applications distribuées qui possèdent des composants client peuvent éventuellement porter la mention Windows 2000 Server et Windows 2000 Professionnel sur leur logo de certification pour Windows.

Les clients suivants peuvent être dispensés de la mise en conformité avec les spécifications des applications bureautiques :

Les outils d'administration destinés à vos applications serveur sont exemptés jusqu'au 31 mars 2001. Après cette date, ils devront être conformes aux spécifications des applications bureautiques.
Les "Agents" dépourvus d'interface utilisateur

En outre, des considérations spéciales concernent les applications client pour navigateurs. Pour plus de détails, reportez-vous à l'Annexe B.

Remarque : les tests des composants client seront exécutés sur Windows 2000 Professionnel, mais pas sur les systèmes d'exploitation de niveau inférieur.

Comment mener sur vos applications des tests préalables de conformité avec les conditions fondamentales de Windows ?

Comment vérifier que votre application est une application 32 bits ?

Utilisez l'analyseur d'installation VeriTest-Rational pour Windows 2000, OU utilisez l'utilitaire Link dans la plate-forme Microsoft SDK.

Si vous vous servez de l'utilitaire Link, sur la ligne de commande, tapez : >"link –dump –headers exename.exe | more". Si votre application est au format PE approprié, le résultat de cette commande sera :

Microsoft COFF Binary File Dumper Version
    5.12.8181
     Copyright (C) Microsoft Corp 1992-1998. All rights
    reserved.
     Dump of file exename.exe
     PE signature found
     File Type: EXECUTABLE IMAGE
     .
     .
     .

Vous ne devez pas obtenir le résultat suivant, qui signifierait que l'application est en 16 bits :

Microsoft COFF Binary File Dumper Version
    5.12.8181
     Copyright (C) Microsoft Corp 1992-1998. All rights
    reserved.
     Dump of file exename.exe
     LINK : warning LNK4095: >" exename.exe" is an NE
    format executable; use EXEHDR to dump it
     .
     .
     .

Pour vérifier l'absence d'entrées dans les fichiers Win.ini, System.ini, Autoexec.bat et Config.sys :

Créez et enregistrez des copies de ces fichiers avant d'installer l'application sur un ordinateur où Windows vient d'être installé.
Installez l'application.
Lancez l'application, exécutez les fonctions de base, puis fermez l'application.
Comparez la version installée et la version enregistrée des fichiers et vérifiez qu'aucune modification n'y a été apportée. L'Analyseur d'installation le vérifiera pour vous.

Pour tester si votre produit traite correctement les noms de fichiers longs :

Les noms de fichiers longs doivent pouvoir :

Accepter partout la présence de signes plus, de points, de virgules, de points-virgules, de signes égal et de crochets.
Ne pas enregistrer d'espaces de début ou de fin. Vous pouvez le vérifier en tapant "###test###" ou un texte similaire dans la boîte de dialogue Enregistrer sous. (Dans cette section, le signe numérique (#) indique un espace de la barre d'espacement - ANSI 0032) Le programme doit éliminer les espaces et ajouter une extension, pour renvoyer ensuite le nom de fichier "test.ext".

Remarque : le caractère ANSI 0160, utilisé dans de nombreuses polices comme espace insécable, doit toujours être conservé, même lorsqu'il est utilisé comme caractère de début ou de fin dans les noms de dossiers et de fichiers.
Prendre en charge les caractères de MAX_PATH (y compris le chemin d'accès et l'extension).

Testez la liste des noms de fichiers suivants (sans les guillemets), qui doivent s'enregistrer sur le disque dur comme prévu :

Si vous tapez	Il doit s'enregistrer sous
"test"	"test.ext"
" test"	"test.ext"
"test "	"test.ext"
"test#;#+#,#=#[#]"	"test#;#+#,#=#[#].ext"
" test " (espaces insécables ANSI 0160)	" test .ext"
"U..testU.."	"U..testUUext"
"\\server\share one\folder three\file"	"\\server\share one\folder three\file.ext"

**Remarque :** si vous tapez un nom UNC contenant des espaces sur la ligne de commande, vous devez entourer le nom de guillemets.

Pour effectuer des tests de vérification des pilotes en mode noyau

Connectez un débogueur en mode noyau à votre machine de tests. Plusieurs débogueurs de qualité sont disponibles, y compris des débogueurs en mode caractère et IUG, sur les CD Windows 2000 SDK et DDK, ainsi que sur le CD de Symboles et support technique de Windows 2000.
Installez votre application avec ses pilotes en mode noyau.
Lancez Verifier.exe et sélectionnez l'onglet Paramètres. Recherchez le nom de chaque pilote dans la liste des pilotes. Sélectionnez chacun des pilotes de l'application dans la liste, puis cliquez sur Vérifier. Si vous ne trouvez pas un ou plusieurs noms de pilotes dans la liste, saisissez les noms dans la zone d'édition Vérifiez ces pilotes supplémentaires après le prochain démarrage. Séparez les noms des différents pilotes dans la zone d'édition avec des espaces et utilisez seulement le nom du pilote et son extension. N'incluez pas les informations de chemin d'accès.

Vérifiez uniquement ces options dans Type de vérification :
1. Pool spécial
2. Forcer la vérificationdes niveaux IRQL
3. Suivi de pool
4. Vérification d'E/S
Cliquez sur Appliquer, quittez et relancez.
Après le redémarrage, lancez votre application et exécutez une série de tests généraux d'utilisateur. Si le noyau détecte des erreurs sur votre pilote au cours du démarrage ou pendant les tests d'utilisateur, il arrêtera Windows 2000 et affichera les informations appropriées sur l'écran en mode caractères (écran bleu) et sur le débogueur du noyau. Si la corruption est indiquée dans le débogueur, désactivez Suivi de pool dans Type de vérification et redémarrez Après avoir éliminé les erreurs, réactivez Suivi de pool et recommencez à tester.
Si vous ne trouvez pas d'erreurs, relancez Verifier.exe. Sélectionnez à nouveau chaque nom de pilote et cliquez sur Vérifier, ou saisissez à nouveau les noms des pilotes (nom de fichier.extension, sans le chemin d'accès) dans la zone d'édition Vérifiez ces pilotes supplémentaires après le prochain démarrage. Séparez-les par des espaces.
Désactivez toutes les options dans Type de vérification, puis activez Simulation de ressources faibles.
Cliquez sur Appliquer, puis quittez et redémarrez. Lancez votre application et exécutez une série de tests généraux d'utilisateur.
L'option Simulation de ressources faibles entraîne le renvoi périodique par le noyau de données incorrectes et de codes d'erreur à votre pilote. Tandis que vous effectuez des tests d'utilisateur, votre pilote doit traiter graduellement les codes incorrects, en réduisant les requêtes d'utilisateur ou en affichant des boîtes de dialogue d'erreur. Si votre pilote essaie d'utiliser les données incorrectes ou ignore les codes d'erreurs, votre application deviendra instable et présentera des incidents. Les symptômes exacts varient en fonction de l'application et de l'objectif du pilote. Le but est ici de vous assurer que votre pilote ne "plante" pas le système et ne le bloque pas. Il se peut que des applications utilisant votre pilote présentent des pannes intermittentes, mais le système ne DOIT PAS se bloquer.

Dernière mise à jour le mercredi 27 septembre 2000

Pour en savoir plus

Le site Windows

Partager via