[Archives des newsletters ^] [< Volume 2, Numéro 2] [Volume 2, Numéro 4 >]
Bulletin d’information System Internals Volume 2, Numéro 3
http://www.sysinternals.com
Copyright (C) 2000 Mark Russinovich
14 juin 2000 : Dans ce numéro :
ÉDITORIAL
NOUVEAUTÉS DE SYSINTERNALS
- Regmon v4.25
- ListDlls v2.22
- TDImon v1.0
- AutoRuns v1.1
- LDMDump v1.0
- Colonnes d’éléments internes avril/juin
INFORMATIONS INTERNES
- Historique des builds Windows NT
- Résolution du minuteur Windows NT/2000
- Remappage du clavier
- Mappage de mémoire système sécurisé
- Journalisation du système de fichiers Windows 98 masquée
- WinDev 00 Ouest
NOUVEAUTÉS À VENIR
- Clés de Registre Windows 98 « sécurisées »
SPONSOR : WINTERNALS SOFTWARE
Le bulletin d’informations Systems Internals est parrainé par Winternals Software, sur le web à l’adresse http://www.winternals.com. Winternals Software est le principal développeur et fournisseur d’outils de systèmes avancés pour Windows NT/2K. Les produits Winternals Software incluent FAT32 pour Windows NT 4.0, ERD Commander Professional Edition (fonctionnalité avancée de disque de démarrage pour Windows NT) et récupération à distance.
La nouvelle version de TCPView Pro vous permet de surveiller l’activité TCP/IP sur les systèmes Windows NT 4.0, Windows 2000 et Windows 95/98. Contrairement aux outils de surveillance TCP/IP intégrés à Windows (tels que netstat), TCPView Pro vous montre quel processus est associé à chaque adresse TCP/IP, ce qui permet de déterminer facilement quelle application est responsable de connexions et d’activités spécifiques. TCPView Pro fournit une vue dynamique et une vue statique. La vue statique affiche les adresses IP locales actuellement ouvertes, le processus associé à chaque point de terminaison et l’adresse IP distante à laquelle un point de terminaison est connecté. La vue dynamique, qui n’est disponible avec aucun autre utilitaire, vous permet de voir l’activité TCP/IP par processus en temps réel.
Obtenez des informations sur les tarifs et téléchargez une version d’essai de 14 jours à l’adresse http://www.winternals.com/products/tcpview.shtml.
Bonjour,
Bienvenue dans le bulletin Systems Internal. Le bulletin compte actuellement 22 000 abonnés.
Dave Solomon et moi-même travaillons sur la phase finale de « Dans Windows 2000, 3e édition », ce qui signifie que le livre sera disponible à la mi-août plutôt qu’à la fin du mois de juillet (il ne s’agirait pas d’un produit Microsoft sans un décalage dans la date de livraison). Maintenant que le livre est dans sa forme définitive, je peux vous donner un aperçu de ce qu’il contient. Tout d’abord, il contient environ 50 % de contenu en plus que l’édition précédente, et comprend quatre nouveaux chapitres. Voici la table des matières :
- Présentation
- Architecture
- Mécanismes système
- Démarrage et arrêt
- Mécanismes de gestion
- Processus et threads
- Gestion de la mémoire
- Sécurité
- Système d’E/S
- Stockage
- Gestionnaire de cache
- Systèmes de fichiers
- Mise en réseau
Comme la 2e édition, le livre est rempli d’expériences qui illustrent les concepts que nous décrivons. Le livre comprend également un CD qui contient une copie de l’intégralité du site web SysInternals, ainsi que les outils que nous utilisons dans les expériences.
Deux outils que j’ai écrits spécifiquement pour le livre ont été très bien reçus par les réviseurs de livres. Le premier est nommé LiveKD et vous permet d’exécuter n’importe quel débogueur de noyau Windows 2000 (i386kd, kd, WinDbg) sur un système actif. Cela signifie que vous lancez LiveKd, en spécifiant le débogueur que vous souhaitez qu’il héberge, puis que vous entrez le débogueur et disposez de toutes les commandes du débogueur que vous auriez si vous déboguiez une image mémoire après incident. Pratiquement toutes les expériences basées sur le débogueur dans le livre peuvent être exécutées à l’aide de LiveKD, ce qui signifie que vous n’avez pas besoin d’un deuxième système ou d’un câble série pour les exécuter.
Le deuxième outil est une extension d’analyseur de performances qui vous permet d’afficher les valeurs actives de n’importe quelle variable de noyau. Si vous souhaitez surveiller la quantité de réserve non paginée en cours d’utilisation avec PerfMon, par exemple, vous devez sélectionner la variable MmAllocatedNonPagedPool.
Je vous informerai dans le bulletin d’informations quand le livre sera publié, mais vous pouvez dès à présent le précommander via le lien Amazon.com sur www.sysinternals.com/links.htm. Comme d’habitude, n’hésitez pas à transmettre le bulletin à des amis qui pourraient être intéressés.
Merci !
- Mark
NOUVEAUTÉS DE SYSTEMS INTERNALS
REGMON V4.25
Cette dernière mise à jour de l’outil de surveillance de registre Regmon inclut la prise en charge du nouveau type de requête KeyNameInformation de Windows 2000 pour les services système ZwEnumerateKey et ZwQuerykey. Cette fonctionnalité n’est pas exportée pour être utilisée par les applications Win32, mais elle est utilisée par les fonctions de registre dans ADVAPI32 dans le cadre de l’utilisation par le système des ruches d’inscription de classe de registre par utilisateur.
Il existe deux façons pour les applications Win32 sur Windows 2000 d’ouvrir la partie Inscription de classe du registre : elles peuvent spécifier HKEY_CLASS_ROOT ou HKLM\Software\Classes. La première renvoie une clé de classe par utilisateur combinée à la clé de classe globale, et la seconde renvoie une clé d’information globale uniquement. La fonction de registre ADVAPI32ne peut déterminer laquelle l’utilisateur a spécifiée qu’en examinant le nom sous-jacent de la clé de registre transmise par l’utilisateur, d’où la nécessité d’un nouveau type de requête. Pour plus d’informations, consultez la documentation du Kit de développement logiciel (SDK) sur RegOpenKeyEx.
Téléchargez Regmon v4.25 à l’adresse http:www.sysinternals.com/regmon.htm.
LISTDLLS V2.22
Lorsqu’un développeur crée une bibliothèque de liens dynamiques (DLL), il indique à l’éditeur de liens l’« adresse de base » de la DLL, qui est l’adresse pour laquelle l’éditeur de liens crée des informations d’adresse relatives dans le fichier image de la DLL. Si une DLL se charge à une adresse différente de son adresse de base, le chargeur doit corriger toutes les adresses relatives dans l’image DLL chargée pour tenir compte de la différence.
Ces correctifs, ou relocalisations, peuvent augmenter le temps de démarrage d’une application, c’est pourquoi les développeurs souhaitent évidemment empêcher les relocalisations. Toutefois, il est fastidieux d’examiner la sortie d’un programme comme ListDLLs, en comparant les adresses de charge avec l’adresse de base. J’ai donc ajouté une nouvelle option à la version 2.22 de ListDLLs, -r, qui lui permet de noter les DLL relocalisées dans sa sortie.
Téléchargez ListDLLs v2.22 à l’adresse http://www.sysinternals.com/listdlls.htm.
TDIMON V1.0
TDImon est le dernier né de la puissante suite d’outils de surveillance de SysInternals. Il vous montre l’activité TCP et UDP sur votre système au fur et à mesure qu’elle se produit. L’outil tire son nom du fait qu’il surveille l’activité TCP et UDP au niveau de l’interface jusqu’à la pile TCP/IP, et que cette interface est appelée l’interface TDI (Transport Driver Interface). Toutes les activités TCP et UDP des applications et des pilotes doivent passer par cette interface, ce qui signifie qu’aucune activité TCP ou UDP n’échappe à TDImon.
TDIMon partage la même interface graphique ses cousins Filemon, Regmon, Portmon et DebugView, et, comme ces autres outils de surveillance, il affiche les noms des processus en activité, les horodatages, et dispose d’une fonctionnalité de filtrage et de mise en surbrillance. Cela fait de TDIMon un outil idéal de résolution des problèmes réseau pour les administrateurs et de débogage TCP/IP pour les développeurs d’applications. TDImon fonctionne sur Windows 95, 98, NT 4 et Windows 2000.
Téléchargez TDImon v1.0 à l’adresse http://www.sysinternals.com/tdimon.htm.
LDMDUMP V1.0
Windows 2000 inclut un nouveau format de partitionnement appelé partitionnement logiciel qui résout certains des inconvénients du partitionnement de style MS-DOS que tous les systèmes d’exploitation Windows ont utilisés jusqu’à présent. Un composant appelé Gestionnaire de disques logiques (LDM) gère les volumes sur les disques formatés avec des partitions logicielles, appelées disques dynamiques (les disques avec partitionnement de style MS-DOS sont appelés disques de base). En plus d’être plus robustes en raison de la mise en miroir de partitions qu’ils implémentent, les disques dynamiques présentent l’avantage de créer des volumes à plusieurs partitions sans avoir à redémarrer le système pour qu’ils soient reconnus et montés par les pilotes de système de fichiers.
Microsoft n’a pas documenté le format de la base de données de partitionnement du LDM. En fait, étant donné qu’il a concédé sous licence la technologie à Veritas, qui a utilisé la même base de données dans son logiciel de gestion de volume UNIX, les contrats de licence peuvent empêcher Microsoft de la documenter. Il est possible qu’il y ait un jour une interface Win32 IOCTL pour le LDM, mais en attendant, j’ai compris le format et écrit un outil appelé LDMDump que vous pouvez utiliser pour accéder à la base de données d’un disque dynamique. LDMDump présente à peu près les mêmes informations que l’outil DmDiag du Kit de ressources Windows 2000, mais LDMDump présente, selon moi, les informations de manière beaucoup plus propre. Je n’offre pas de code source pour cet outil pour le moment, mais si vous êtes intéressé par une licence pour vos propres applications, veuillez me contacter.
Pour en savoir plus sur la base de données du LDM, consultez la colonne « Stockage intérieur, partie 2 » du magazine Windows 2000 à l’adresse http://www.sysinternals.com/publ.htm.
Téléchargez LDMDump v1.0 à l’adresse http://www.sysinternals.com/ldmdump.htm.
AUTORUNS V1.1
Vous connaissez peut-être déjà les AutoRuns, que nous avons lancés au cours des deux derniers mois. AutoRuns affiche les paramètres d’exécution automatique pour chaque emplacement du registre et des fichiers .INI où ces informations sont spécifiées (c’est du moins ce que nous pensions). Les commentaires des utilisateurs nous ont indiqué quelques emplacements où AutoRuns manquait, et cette dernière version les affiche désormais.
Télécharger AutoRuns v1.1 à l’adresse http://www.sysinternals.com/misc.htm.
COLONNES D’ÉLÉMENTS INTERNES JUIN/JUILLET
Vous êtes-vous déjà demandé exactement en quoi les services Win32 diffèrent des applications Win32 standard ? Ou peut-être voulez-vous savoir ce qui rend la séquence de démarrage ou d’arrêt NT si longue. Je réponds à ces questions et plus encore dans ma série en deux parties sur les services Win32 dans les numéros de juin et juillet du magazine Windows 2000.
Dans la partie 1, je vous présente la structure d’un service Win32, en expliquant comment ils acceptent les commandes des applications clientes. Ensuite, je commence à décrire le gestionnaire de contrôle des services (SCM), qui est responsable de la gestion des services Win32, y compris de leur démarrage et de leur arrêt. Dans la partie 2, je termine ma description du processus de démarrage du service, qui a lieu pendant le démarrage du système, puis je vous explique comment le SCM arrête les services. J’examine également les améliorations apportées par Microsoft au SCM dans Windows 2000, et je vous guide dans l’outil Kit de ressources SrvAny.
Les abonnés au magazine Windows 2000 peuvent lire les articles en ligne à l’adresse http://www.sysinternals.com/publ.htm.
INFORMATIONS INTERNES
HISTORIQUE DES BUILDS WINDOWS NT
Comme vous l’avez appris dans les bulletins d’informations précédents, le numéro de build pour Windows NT (maintenant Windows 2000) s’incrémente chaque jour lorsque l’équipe de génération génère une nouvelle build avec les vérifications de code du jour. À l’aide de mes anciens CDs bêta et release candidate, ainsi que l’aide d’autres utilisateurs qui utilisent Windows NT depuis plus longtemps que moi, j’ai compilé une liste des numéros de build qui correspondent aux versions publiques (bêtas, release candidates et versions complètes). Notez que les dates sont la date de la build, et non la date de publication de la build. Par exemple, la build finale de Win2K, 2195, a été réalisée en décembre, mais elle a été accessible au public en février.
| Build | Libérer | Date |
|---|---|---|
| 297 | PDC | 1992 |
| 340 | NT 3.1 Bêta 1 | Octobre 1992 |
| 397 | NT 3.1 Bêta 2 | Mars 1993 |
| 511 | NT 3.1 | Juillet 1993 |
| 611 | NT 3.5 Bêta 1 | Avril 1994 |
| 683 | NT 3.5 Bêta 2 | Juin 1994 |
| 756 | NT 3.5 RC 1 | Août 1994 |
| 807 | NT 3.5 | Septembre 1994 |
| 944 | NT 3.51 Bêta 1 | Février 1995 |
| 1 057 | NT 3.51 | Mai 1995 |
| 1234 | NT 4.0 Bêta 1 | Janvier 1996 |
| 1314 | NT 4.0 Bêta 2 | Mai 1996 |
| 1381 | NT 4.0 | Juillet 1996 |
| 1671 | NT 5.0 Bêta 1 | Septembre 1997 |
| 1877 | NT 5.0 Bêta 2 | Septembre 1998 |
| 1946 | Win2K RC0 de Bêta 3 | Décembre 1998 |
| 2000.3 | Win2K RC1 de Bêta 3 | Mars 1999 |
| 2031 | Win2K Bêta 3 | Avril 1999 |
| 2072 | Win2K RC1 | Juillet 1999 |
| 2128 | Win2K RC2 | Septembre 1999 |
| 2183 | Win2K RC3 | Novembre 1999 |
| 2195 | WIN2K | Décembre 1999 |
RÉSOLUTION DU MINUTEUR WINDOWS NT/2000
Alors que Windows NT/2000 fournit des services, y compris QueryPerformanceCounter, qui vous permettent de mesurer les temps jusqu’à la résolution du compteur de cycles du Pentium, ses services de minutage d’intervalle ont une résolution légèrement inférieure. En fait, la résolution du minuteur par défaut est la même que l’intervalle d’horloge système, qui est de 10 ms sur les systèmes x86 monoprocesseur (généralement 7,5 ms ou 15 ms sur les systèmes SMP). Les applications peuvent utiliser les fonctions du minuteur multimédia dans l’espace utilisateur pour augmenter la résolution à 1 ms, mais les pilotes sont dans l’impossibilité d’obtenir des résolutions plus élevées, jusqu’à Windows 2000 en tout cas.
Windows 2000 introduit une nouvelle fonction DDK, ExSetTimerResolution, que les pilotes peuvent utiliser pour réduire l’intervalle du minuteur système à 1 ms. Vous voulez savoir ce qui se passe sous le capot des minuteurs multimédias et ExSetTimerResolution ? Consultez « Inside Windows NT High Resolution Timers » (Dans les minuteurs haute résolution Windows NT) à l’adresse http://www.sysinternals.com/timer.htm.
MAPPAGE DE MÉMOIRE SYSTÈME SÉCURISÉ
Puisque nous parlons des nouvelles fonctions du noyau Windows 2000 pour les développeurs de pilotes, il convient de mentionner MmGetSystemAddressForMdlSafe. Dans les versions précédentes de Windows NT, un développeur de pilotes souhaitant obtenir un pointeur d’espace d’adressage système pour la mémoire tampon ou la mémoire physique d’un utilisateur devait transmettre une liste de descripteurs de mémoire MDL (liste de descripteurs de mémoire) décrivant MmGetSystemAddressForMdl la mémoire tampon physique.
La création d’un mappage virtuel dans l’espace d’adressage du système utilise une ressource appelée entrées de table des pages système (PTE système), où une PTE système est requise pour chaque page physique mappée. Malheureusement, les PTE système sont des ressources limitées et peuvent s’épuiser si les pilotes mappent de grandes quantités de mémoire. Que se passe-t-il quand MmGetSystemAddressForMdl ne peut pas obtenir les PTE système dont il a besoin ? On pourrait penser qu’il fait quelque chose d’utile, comme renvoyer NULL comme adresse virtuelle mappée. Mais non, il abandonne et génère des écrans bleus sur le système. Un tel comportement donne une mauvaise image du pilote qui effectue la requête.
MmGetSystemAddressForMdlSafe de Windows 2000 fait ce que MmGetSystemAddressForMdl aurait dû faire : renvoyer NULL s’il n’y a pas assez de PTE système pour créer le mappage de la mémoire tampon. Utilisez cette fonction pour éviter un vidage gênant qui pointe vers votre pilote. Si vous avez un pilote qui s’exécute sur NT 4 et Windows 2000, il vaut la peine de publier deux versions différentes, une pour chaque plateforme, afin que vous puissiez tirer parti de cette nouvelle API sur Windows 2000.
REMAPPAGE DU CLAVIER
Si vous êtes comme moi, vous avez commencé sur un clavier UNIX où une touche ctrl était présente sur le clavier à la position occupée sur les claviers PC par la touche de verrouillage des majuscules. Pour améliorer mon taux de saisie et en savoir plus sur le développement de pilotes de périphérique sur Windows 9x et Windows NT, l’un de mes premiers projets de pilotes sur ces deux systèmes d’exploitation a été d’implémenter un pilote de remappage de clavier. Vous trouverez la version de Windows 9x à l’adresse http://www.sysinternals.com/c2cap95.htm et la version de Windows NT/2K à l’adresse http://www.sysinternals.com/ctrl2cap.htm.
Sur Windows NT/2K, il existe une alternative à l’utilisation d’un pilote de filtre clavier. En définissant des entrées de remappage du scancode dans le registre, vous pouvez entièrement reprogrammer le comportement du clavier. En fait, le Kit de ressources Windows 2000 inclut un outil appelé RemapKey qui vous permet d’échanger des touches à l’aide d’une représentation graphique du clavier. Cet article sur le site web de Microsoft parle du remappage de clavier et de son fonctionnement : http://www.microsoft.com/HWDEV/input/W2kscan-map.htm. Notez que l’outil fonctionne également sur NT 4.
Supposons donc que vous n’avez pas le Kit de ressources Windows 2000 et que vous préférez ne pas dépenser d’argent pour celui-ci (je vous recommande de le faire, il contient toutes sortes d’outils et de documentation intéressants). Dans ce cas, vous pouvez remappper manuellement le clavier. L’article Microsoft que je viens de référencer vous indique le format de la touche de Registre où le pilote de clavier recherche les codes de remappage (HKLM\ SYSTEM\CurrentControlSet\Control\Keyboard Layout\Scancode Map), et cet article, également disponible auprès de Microsoft, vous indique les scancodes qui correspondent aux touches : http://www.microsoft.com/hwdev/download/desinit/scancode.zip.
Si tout ce que vous voulez, c’est échanger la touche de verrouillage des majuscules et la touche contrôle (notez que les filtres de mon clavier suppriment totalement la touche de verrouillage des majuscules puisque je ne l’utilise jamais), vous pouvez copier le texte suivant (sans inclure les séparateurs "----") dans un fichier (nommez-le quelque chose comme swapcaps.reg) et double-cliquer sur le fichier. Les paramètres seront importés dans le registre et prendront effet après un redémarrage.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,3a,00,1d,00,1d,00,3a,00,\
00,00,00,00
Si vous souhaitez annuler le mappage, supprimez simplement la valeur Scancode Map du registre et redémarrez.
JOURNALISATION DU SYSTÈME DE FICHIERS WINDOWS 98 MASQUÉE
Avez-vous déjà parcouru votre répertoire système Windows 98 et remarqué un sous-répertoire nommé \Windows\Applog ? Dans ce répertoire, vous trouverez probablement des fichiers avec des noms correspondant à ceux des applications que vous avez récemment exécutées et des extensions telles que .LGC et .LGD. Ouvrez l’un des fichiers dans le Bloc-notes et vous verrez clairement une trace d’activité du système de fichiers, avec des noms de fichiers, des décalages et des appels d’ouverture et de fermeture. Un virus génère-t-il ces journaux ou s’agit-il d’un utilitaire secret inclus dans Windows 98 qui signale à Microsoft les schémas d’utilisation de votre application ? Ni l’un ni l’autre (si c’était l’un ou l’autre, vous liriez cela dans la presse spécialisée, et non dans le bulletin d’information de SysInternals). Cela fait partie de la fonction « chargez vos applications les plus fréquemment utilisées jusqu’à 36 % plus rapidement » de Windows 98.
En raison de l’entrée Taskmon dans HKLM\Software\Microsoft\Windows\CurrentVersion\Run, Windows 98 lance un programme de service pendant le démarrage nommé Taskmon. Taskmon charge un VxD nommé FioLog (\Windows\System\FioLog.Vxd) pour installer un crochet d’activité du système de fichiers afin qu’il puisse voir l’utilisation des fichiers lors du lancement de l’application. Taskmon surveille l’activité du système de fichiers de toutes les applications lorsqu’elles démarrent, à l’exception de celles répertoriées dans HKLM\Software\Microsoft\Windows\CurrentVersion\Taskmon\ExcludeApps. FioLog enregistre l’activité du système de fichiers au démarrage de l’application dans le répertoire Applog. Les fichiers journaux qu’il crée commencent par l’extension .LGA. La manière dont il détermine quand supprimer un journal et quand en créer un nouveau pour une application avec une nouvelle extension dont la dernière lettre est incrémentée n’est pas claire. Voici une partie d’un exemple de fichier journal :
{
o da3034d0 d000 "C:\WINDOWS\NOTEPAD.EXE"
R da3034d0 0 40
R da3034d0 80 f8
R da3034d0 80 1c0
R da3034d0 7000 1000
R da3034d0 6000 e00
o da2b2610 156000 "C:\WINDOWS\SYSTEM\SHELL32.DLL"
R da2b2610 83000 1000
o da2b2f40 45110 "C:\WINDOWS\SYSTEM\SHLWAPI.DLL"
R da2b2f40 3c000 1000
R da2b2f40 3c000 1000
...
Les lignes sont divisées en quatre champs : le premier est le code d’opération, où o est ouvert, R est lu et C est fermé. Vous ne verrez pas de W (pour l’écriture), car FioLog n’enregistre que les opérations de lecture au démarrage de l’application afin que le lancement de l’application puisse être optimisé. Le deuxième champ est le pointeur de fichier interne. Les troisième et quatrième champs doivent être interprétés en fonction du code d’opération de la ligne. Si le code d’opération est R, le troisième champ est le décalage de fichier et le quatrième champ est la longueur de la lecture. Toutefois, si le code d’opération est o, le troisième champ correspond aux drapeaux ouverts et le quatrième est le nom du fichier ouvert. Dans l’exemple de trace, l’ouverture de notepad.exe renvoie le pointeur de fichier da3034d0, que vous pouvez voir utilisé dans les opérations de lecture ultérieures.
Lorsque vous lancez une opération de défragmentation, le programme Defrag.Exe exécute un programme nommé CvtApLog (\Windows\System\Cvtaplog.exe) pour traiter les fichiers journaux. CvtApLog utilise une DLL nommée ClusAlgo.Dll (\Windows\System\Clusalgo.dll) pour déterminer le placement optimal du cluster en fonction des fichiers journaux qu’il lit, et enregistre ces informations dans des fichiers nommés \Windows\Applog\Applog.d* qui guident le processus de défragmentation. CvtApLog génère également un fichier nommé \Windows\Applog\Optlog.txt qui résume les optimisations au démarrage de l’application que dictent les fichiers journaux. Voici le contenu partiel d’un fichier Optlog.txt :
Program Launch Optimization Log - Created Tue Jun 13 11:42:52 2000
Programs Eligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
1 RUNDLL32 65 2000.06.13 C:\WINDOWS\RUNDLL32.EXE
2 ATIPTAAB 31 2000.06.13 C:\WINDOWS\SYSTEM\ATIPTAAB.EXE
3 NOTEPAD 22 2000.06.13 C:\WINDOWS\NOTEPAD.EXE
4 PING 9 2000.06.10 C:\WINDOWS\PING.EXE
…
17 IEXPLORE 2 2000.06.01 C:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE
Programs Ineligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
18 S GREP 5 2000.06.13 C:\BIN\GREP.EXE
19 S STRINGS 12 2000.06.13 C:\BIN\STRINGS.EXE
20 S ATI2CWXX 31 2000.06.13 C:\WINDOWS\SYSTEM\ATI2CWXX.EXE
Control Parameters:
Use app profile = Yes
Minimum log size = 1000
Maximum no use days = 90
Maximum apps = 50
Flags for Ineligible Programs:
S = Log size smaller than <Minimum log size>
U = Program not used for more than <Maximum no use days>
P = No profile for program
E = Associated program no longer exists
D = Log deleted (may be combined with one of the above)
La capacité de Windows 98 à déplacer les parties de fichiers utilisées lors du démarrage d’une application vers une zone contiguë sur le disque est une technologie sous licence Microsoft d’Intel (pour la voir, exécutez Defrag.exe manuellement et vous verrez le texte « Accélérateur de lancement d’application Intel »).
WINDEV 00 OUEST
WinDev 00 EST s’est déroulé la semaine dernière avec une participation record de 660 personnes (le nombre de personnes maximal que l’hôtel pouvait contenir). Les intervenants présents à la conférence représentent les grands noms dans tous les domaines du développement Windows, du Dieu COM Don Box aux experts des pilotes Jamie Hanrahan et Brian Catlin. Mes sessions comprenaient les sujets suivants : « Windows 2000 Internals », « Advanced Drivers », « Windows NT/2000 File System Drivers » et « Cluster Server ».
Si vous n’avez pas pu y assister, vous avez de la chance parce que vous avez une deuxième chance. WinDev 00 OUEST se tiendra à Santa Clara, en Californie du 11 au 15 septembre, et les mêmes intervenants seront présents. Je présenterai les mêmes sessions, et comme à WinDev Est, je donnerai gratuitement des t-shirts SysInternals aux participants qui répondent à mes questions ou posent des questions particulièrement pertinentes. Pour plus d’informations, consultez http://www.butrain.com/windev/west/default.htm.
NOUVEAUTÉS À VENIR
CLÉS DE REGISTRE WINDOWS 98 « SÉCURISÉES »
Bien que le registre Windows 98 ne prend pas en charge la sécurité, Microsoft a implémenté un mécanisme de définition des clés de registre masquées. Quelle application utilise cette technologie furtive ? Internet Explorer, bien sûr. La prochaine fois, je vous expliquerai quelles clés IE masque et comment Windows 98 les implémente.
Merci d’avoir lu le bulletin d’information Systems Internals.
Publié le mercredi 14 juin 2000 à 19:08 par ottoh
[Archives des newsletters ^] [< Volume 2, Numéro 2] [Volume 2, Numéro 4 >]