Sous Windows XP il existe un moyen d'utiliser le fichier AUTOEXEC.BAT
Pour celà il faut mettre à jour le registre
La valeur HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\ParseAutoexec
- doit être à 1 pour que l'autoexec.bat soit exécuté
- doit être à 0 pour qu'il ne soit pas.
A partir de Windev je veux pouvoir créer à la demande un fichier NN.BAT
qui serait lancé dans AUTOEXEC.BAT
Avant d'écrire cette procédure je veux simplement vérifier si cette
possibilité est bien réelle.
Pour celà j'ai créé dans AUTOEXEC.BAT les commandes suivantes pour
vérifier la bonne exécution de AUTOEXEC.BAT au démarrage de Windows XP
Je cherche simplement à récupérer la date et l'heure dans deux fichiers
.TXT
date/T >C:\wdate.txt
time/T >C:\wtime.txt
Après démarrage je ne trouve pas ces fichiers
Mes questions sont :
Est-ce que cette procédure est vraiment valable ?
Est-ce qu'il y a une erreur dans l'écriture des commandes date et time
Le fichier AUTOEXEC.BAT est dans le répertoire C:\ ... est-ce correct
?
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations"
Merci : je vais essayer çà
Cordialement
-- Elle est pas belle la vie ?
Georges Peyre
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00) Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR : [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager] "PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête ;-)
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS Je charge les données de la façon suivante : iHandle est un entier strCle est une chaîne strValeur est une chaîne strDonnees est une chaîne
Résultat après démarrage : a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent ) b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou s'il a bien été supprimé mais a été recherché avec les URL d'un répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Cordialement
-- Elle est pas belle la vie ?
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager]
Et utiliser la valeur "PendingFileRenameOperations"
La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples)
Tu mets ton 1er fichier sous la forme :
"??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00)
Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR :
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager]
"PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête ;-)
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS
Je charge les données de la façon suivante :
iHandle est un entier
strCle est une chaîne
strValeur est une chaîne
strDonnees est une chaîne
Résultat après démarrage :
a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent )
b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide
et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou
s'il a bien été supprimé mais a été recherché avec les URL d'un
répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier
fichier chargé dans le registre n'est jamais supprimé
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00) Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR : [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager] "PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête ;-)
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS Je charge les données de la façon suivante : iHandle est un entier strCle est une chaîne strValeur est une chaîne strDonnees est une chaîne
Résultat après démarrage : a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent ) b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou s'il a bien été supprimé mais a été recherché avec les URL d'un répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Cordialement
-- Elle est pas belle la vie ?
Georges Peyre
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00) Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR : [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager] "PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS Je charge les données de la façon suivante : iHandle est un entier strCle est une chaîne strValeur est une chaîne strDonnees est une chaîne
Résultat après démarrage : a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent ) b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou s'il a bien été supprimé mais a été rechargé avec les URL d'un répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Cordialement
-- Elle est pas belle la vie ?
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager]
Et utiliser la valeur "PendingFileRenameOperations"
La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples)
Tu mets ton 1er fichier sous la forme :
"??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00)
Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR :
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager]
"PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS
Je charge les données de la façon suivante :
iHandle est un entier
strCle est une chaîne
strValeur est une chaîne
strDonnees est une chaîne
Résultat après démarrage :
a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent )
b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide
et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou
s'il a bien été supprimé mais a été rechargé avec les URL d'un
répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier
fichier chargé dans le registre n'est jamais supprimé
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
tu ajoutes 5 zéro binaires (00) Et là tu recommences pour le fichier suivant, etc...
Exemple :
pour effacer c:toto.txt et c:tata.txt, soit en chaine :
??c:toto.txt
??c:tata.txt
et en binaire dans la BDR : [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager] "PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,
Voilà, au reboot, ca devrait gicler sans que Windows t'embête
Pas tout à fait
Voici mes tests :
-1- Je cherche à supprimer 4 fichiers NON TENUS PAR WINDOWS Je charge les données de la façon suivante : iHandle est un entier strCle est une chaîne strValeur est une chaîne strDonnees est une chaîne
Résultat après démarrage : a) le fichier ASupp2.txt n'est pas supprimé ( idem essai précédent ) b) Là je n'ai pas de certitude car le fichier Index.dat n'est pas vide et je ne sais pas s'il n'a pas été supprimé avant le lancement de XP ou s'il a bien été supprimé mais a été rechargé avec les URL d'un répertoire Internet quelconque.
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Cordialement
-- Elle est pas belle la vie ?
Gilles Guédikian
Georges Peyre a écrit :
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets) Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Tu as essayé de doubler le dernier fichier, juste pour test? Ajoute 2 fois le même fichier final, et vois si ca supprime.
Il manque peut être un caractère de fin.
Georges Peyre a écrit :
Gilles Guédikian a présenté l'énoncé suivant :
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager]
Et utiliser la valeur "PendingFileRenameOperations"
La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples)
Tu mets ton 1er fichier sous la forme :
"??C:nom de ton dossiernom de ton fichier" (sans les guillemets)
Voilà : en résumé je voudrais au moins savoir pourquoi le dernier
fichier chargé dans le registre n'est jamais supprimé
Tu as essayé de doubler le dernier fichier, juste pour test?
Ajoute 2 fois le même fichier final, et vois si ca supprime.
[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager] Et utiliser la valeur "PendingFileRenameOperations" La valeur est de type REG_MULTI_SZ (Valeur de chaines multiples) Tu mets ton 1er fichier sous la forme : "??C:nom de ton dossiernom de ton fichier" (sans les guillemets) Voilà : en résumé je voudrais au moins savoir pourquoi le dernier fichier chargé dans le registre n'est jamais supprimé
Tu as essayé de doubler le dernier fichier, juste pour test? Ajoute 2 fois le même fichier final, et vois si ca supprime.
Il manque peut être un caractère de fin.
Georges Peyre
Gilles Guédikian a exprimé avec précision :
Tu as essayé de doubler le dernier fichier, juste pour test? Ajoute 2 fois le même fichier final, et vois si ca supprime.
Effectivement, dans ce cas il y a bien suppression du fichier : je garde la solution
Merci infiniment pour ton aide
Cordialement
-- Elle est pas belle la vie ?
Gilles Guédikian a exprimé avec précision :
Tu as essayé de doubler le dernier fichier, juste pour test?
Ajoute 2 fois le même fichier final, et vois si ca supprime.
Effectivement, dans ce cas il y a bien suppression du fichier : je
garde la solution