Bonjour,
Le Boot Manager des OS basés sur Windows NT impose que
ntdlr , boot.ini , etc... soient dans les premiers 8Go d'un Hdd
d'après :
Windows NT #limitesNT 8Go adressage ntldr
http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
« La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
être entièrement dans la première zone de 7.9 Goctets du disque.
...dans le cas où la défragmentation déplacerait des données
au-delà de cette zone, le boot deviendrait impossible. »
Est-ce toujours d'actualité sous Windows XP ?
Est-ce :
la première zone de 7.9 Goctets du disque physique ou bien
celle des Partitions principales de ce disque physique?
Comment vérifier qu'une défragmentation ne va pas déplacer
ces fichiers sur des Partitions supérieure à 8 Go ?
D'une manière générale comment obtenir facilement la liste des
noms de fichiers fragmentés et leur localisation sur le Volume
pour pouvoir déplacer ceux que l'on souhaite.
Merci.
Bonjour,
Le Boot Manager des OS basés sur Windows NT impose que
ntdlr , boot.ini , etc... soient dans les premiers 8Go d'un Hdd
d'après :
Windows NT #limitesNT 8Go adressage ntldr
http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
« La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
être entièrement dans la première zone de 7.9 Goctets du disque.
...dans le cas où la défragmentation déplacerait des données
au-delà de cette zone, le boot deviendrait impossible. »
Est-ce toujours d'actualité sous Windows XP ?
Est-ce :
la première zone de 7.9 Goctets du disque physique ou bien
celle des Partitions principales de ce disque physique?
Comment vérifier qu'une défragmentation ne va pas déplacer
ces fichiers sur des Partitions supérieure à 8 Go ?
D'une manière générale comment obtenir facilement la liste des
noms de fichiers fragmentés et leur localisation sur le Volume
pour pouvoir déplacer ceux que l'on souhaite.
Merci.
Bonjour,
Le Boot Manager des OS basés sur Windows NT impose que
ntdlr , boot.ini , etc... soient dans les premiers 8Go d'un Hdd
d'après :
Windows NT #limitesNT 8Go adressage ntldr
http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
« La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
être entièrement dans la première zone de 7.9 Goctets du disque.
...dans le cas où la défragmentation déplacerait des données
au-delà de cette zone, le boot deviendrait impossible. »
Est-ce toujours d'actualité sous Windows XP ?
Est-ce :
la première zone de 7.9 Goctets du disque physique ou bien
celle des Partitions principales de ce disque physique?
Comment vérifier qu'une défragmentation ne va pas déplacer
ces fichiers sur des Partitions supérieure à 8 Go ?
D'une manière générale comment obtenir facilement la liste des
noms de fichiers fragmentés et leur localisation sur le Volume
pour pouvoir déplacer ceux que l'on souhaite.
Merci.
"Michel_D" écrit dans le message de
news:
En préambule, merci pour ta réponse, Michel.
| > Windows NT #limitesNT 8Go adressage ntldr
| > http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
| >
| > « La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
| > être entièrement dans la première zone de 7.9 Goctets du disque.
| > ...dans le cas où la défragmentation déplacerait des données
| > au-delà de cette zone, le boot deviendrait impossible. »
| >
| > Est-ce toujours d'actualité sous Windows XP ?
|
| Non, ce n'est plus d'actualité car en fait c'était lié au mode
| employé pour accéder au disque dur, or la séquence de boot a été
| remanié pour utiliser le mode approprié (CHS ou LBA) suite au
| évolution des normes liés au disque dur.
| > Est-ce :
| >
| > la première zone de 7.9 Goctets du disque physique ou bien
| > celle des Partitions principales de ce disque physique?
|
| C'était par rapport au disque physique et non par rapport aux
| partitions.
OK , bien noté.
| > D'une manière générale comment obtenir facilement la liste des
| > noms de fichiers fragmentés et leur localisation sur le Volume
| > pour pouvoir déplacer ceux que l'on souhaite.
| >
| > Merci.
|
| Il me semble que certain utilitaire donne la localisation des
| différents blocs occupés par un fichier.
Contig de Sysinternals le permet , mais contig -v -a liste tous
les fichiers (fragmentés et non fragmentés) mais je ne crois
qu'il y ait les clusters, dans un bloc-notes ... énorme pour
les 22Go du Volume sur lequel je veux intervenir.
( -v: Verbose , -a: Analyze fragmentation )
Il faut que je regarde si une version plus récente ne permet
pas de ne récupérer que les fichiers fragmentés.
JkDefrag (que je ne manipule pas encore très bien) donne
certain clusters mais pas tous (option d 4) dans un bloc-notes
... de 32 Mo à analyser, donc pas très facile à analyser.
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
"Michel_D" écrit dans le message de
news:u3wZEtuoHHA.3484@TK2MSFTNGP04.phx.gbl
En préambule, merci pour ta réponse, Michel.
| > Windows NT #limitesNT 8Go adressage ntldr
| > http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
| >
| > « La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
| > être entièrement dans la première zone de 7.9 Goctets du disque.
| > ...dans le cas où la défragmentation déplacerait des données
| > au-delà de cette zone, le boot deviendrait impossible. »
| >
| > Est-ce toujours d'actualité sous Windows XP ?
|
| Non, ce n'est plus d'actualité car en fait c'était lié au mode
| employé pour accéder au disque dur, or la séquence de boot a été
| remanié pour utiliser le mode approprié (CHS ou LBA) suite au
| évolution des normes liés au disque dur.
| > Est-ce :
| >
| > la première zone de 7.9 Goctets du disque physique ou bien
| > celle des Partitions principales de ce disque physique?
|
| C'était par rapport au disque physique et non par rapport aux
| partitions.
OK , bien noté.
| > D'une manière générale comment obtenir facilement la liste des
| > noms de fichiers fragmentés et leur localisation sur le Volume
| > pour pouvoir déplacer ceux que l'on souhaite.
| >
| > Merci.
|
| Il me semble que certain utilitaire donne la localisation des
| différents blocs occupés par un fichier.
Contig de Sysinternals le permet , mais contig -v -a liste tous
les fichiers (fragmentés et non fragmentés) mais je ne crois
qu'il y ait les clusters, dans un bloc-notes ... énorme pour
les 22Go du Volume sur lequel je veux intervenir.
( -v: Verbose , -a: Analyze fragmentation )
Il faut que je regarde si une version plus récente ne permet
pas de ne récupérer que les fichiers fragmentés.
JkDefrag (que je ne manipule pas encore très bien) donne
certain clusters mais pas tous (option d 4) dans un bloc-notes
... de 32 Mo à analyser, donc pas très facile à analyser.
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
"Michel_D" écrit dans le message de
news:
En préambule, merci pour ta réponse, Michel.
| > Windows NT #limitesNT 8Go adressage ntldr
| > http://jc.bellamy.free.fr/fr/windowsnt.html#limitesNT
| >
| > « La partition de boot (contenant NTLDR, boot.ini, etc.) DOIT
| > être entièrement dans la première zone de 7.9 Goctets du disque.
| > ...dans le cas où la défragmentation déplacerait des données
| > au-delà de cette zone, le boot deviendrait impossible. »
| >
| > Est-ce toujours d'actualité sous Windows XP ?
|
| Non, ce n'est plus d'actualité car en fait c'était lié au mode
| employé pour accéder au disque dur, or la séquence de boot a été
| remanié pour utiliser le mode approprié (CHS ou LBA) suite au
| évolution des normes liés au disque dur.
| > Est-ce :
| >
| > la première zone de 7.9 Goctets du disque physique ou bien
| > celle des Partitions principales de ce disque physique?
|
| C'était par rapport au disque physique et non par rapport aux
| partitions.
OK , bien noté.
| > D'une manière générale comment obtenir facilement la liste des
| > noms de fichiers fragmentés et leur localisation sur le Volume
| > pour pouvoir déplacer ceux que l'on souhaite.
| >
| > Merci.
|
| Il me semble que certain utilitaire donne la localisation des
| différents blocs occupés par un fichier.
Contig de Sysinternals le permet , mais contig -v -a liste tous
les fichiers (fragmentés et non fragmentés) mais je ne crois
qu'il y ait les clusters, dans un bloc-notes ... énorme pour
les 22Go du Volume sur lequel je veux intervenir.
( -v: Verbose , -a: Analyze fragmentation )
Il faut que je regarde si une version plus récente ne permet
pas de ne récupérer que les fichiers fragmentés.
JkDefrag (que je ne manipule pas encore très bien) donne
certain clusters mais pas tous (option d 4) dans un bloc-notes
... de 32 Mo à analyser, donc pas très facile à analyser.
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
Oui fixmbr replace une séquence de démarrage qui supprime cette
restriction.
PS: fixmbr ne permet pas l'effacement de la signature du disque.
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
Oui fixmbr replace une séquence de démarrage qui supprime cette
restriction.
PS: fixmbr ne permet pas l'effacement de la signature du disque.
| PS: Par contre pour les partitions qui ne sont de type FATxx,
| si l'on modifie la séquence contenu cette fois au niveau du
| MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
Important à savoir si on fait une réparation de MBR sous
MSDOS ou 9x .
Est-ce que fixmbr [nom_de_périphérique] en CDR
(Console de récupération), donc lié à Windows XP, ne
permet pas de contourner cette difficulté ? (je ne l'ai jamais
utilisé, car j'ignore si cette commande n'écrase pas en
même temps la table des partitions ?
Oui fixmbr replace une séquence de démarrage qui supprime cette
restriction.
PS: fixmbr ne permet pas l'effacement de la signature du disque.
Michel_D a écrit dans
news:
| > "Michel_D" avait écrit:
| > | Daniel92 avait demandé :
[..]
| > | PS: Par contre pour les partitions qui ne sont de type FATxx,
| > | si l'on modifie la séquence contenu cette fois au niveau du
| > | MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
| >
| > Important à savoir si on fait une réparation de MBR sous
| > MSDOS ou 9x .
| >
| > Est-ce que fixmbr [nom_de_périphérique] en CDR
| > (Console de récupération), donc lié à Windows XP, ne
| > permet pas de contourner cette difficulté ? (je ne l'ai jamais
| > utilisé, car j'ignore si cette commande n'écrase pas en
| > même temps la table des partitions ?
|
|
| Oui fixmbr replace une séquence de démarrage qui supprime cette
| restriction.
| PS: fixmbr ne permet pas l'effacement de la signature du disque.
|
| J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
À propos de la signature du disque j'ai une (grosse) difficulté
de compréhension. La séquence/programme de démarrage fait
442 octets , ce qui chez moi englobe les deux premiers octets
de la signature du disque 2B EE 2B EE ?
visible sur ce petit pense-bête que je suis en train de faire :
http://cjoint.com/?gbqUbx5ILX
Michel_D a écrit dans
news:OtsMaa6oHHA.716@TK2MSFTNGP05.phx.gbl
| > "Michel_D" avait écrit:
| > | Daniel92 avait demandé :
[..]
| > | PS: Par contre pour les partitions qui ne sont de type FATxx,
| > | si l'on modifie la séquence contenu cette fois au niveau du
| > | MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
| >
| > Important à savoir si on fait une réparation de MBR sous
| > MSDOS ou 9x .
| >
| > Est-ce que fixmbr [nom_de_périphérique] en CDR
| > (Console de récupération), donc lié à Windows XP, ne
| > permet pas de contourner cette difficulté ? (je ne l'ai jamais
| > utilisé, car j'ignore si cette commande n'écrase pas en
| > même temps la table des partitions ?
|
|
| Oui fixmbr replace une séquence de démarrage qui supprime cette
| restriction.
| PS: fixmbr ne permet pas l'effacement de la signature du disque.
|
| J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
À propos de la signature du disque j'ai une (grosse) difficulté
de compréhension. La séquence/programme de démarrage fait
442 octets , ce qui chez moi englobe les deux premiers octets
de la signature du disque 2B EE 2B EE ?
visible sur ce petit pense-bête que je suis en train de faire :
http://cjoint.com/?gbqUbx5ILX
Michel_D a écrit dans
news:
| > "Michel_D" avait écrit:
| > | Daniel92 avait demandé :
[..]
| > | PS: Par contre pour les partitions qui ne sont de type FATxx,
| > | si l'on modifie la séquence contenu cette fois au niveau du
| > | MBR via un fdisk /mbr cette restriction est toujours d'actualitée.
| >
| > Important à savoir si on fait une réparation de MBR sous
| > MSDOS ou 9x .
| >
| > Est-ce que fixmbr [nom_de_périphérique] en CDR
| > (Console de récupération), donc lié à Windows XP, ne
| > permet pas de contourner cette difficulté ? (je ne l'ai jamais
| > utilisé, car j'ignore si cette commande n'écrase pas en
| > même temps la table des partitions ?
|
|
| Oui fixmbr replace une séquence de démarrage qui supprime cette
| restriction.
| PS: fixmbr ne permet pas l'effacement de la signature du disque.
|
| J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
À propos de la signature du disque j'ai une (grosse) difficulté
de compréhension. La séquence/programme de démarrage fait
442 octets , ce qui chez moi englobe les deux premiers octets
de la signature du disque 2B EE 2B EE ?
visible sur ce petit pense-bête que je suis en train de faire :
http://cjoint.com/?gbqUbx5ILX
Michel_D écrit dans
news:%23Mkin%
| > Michel_D a écrit dans
| >
[..]
| > | J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
| >
| > À propos de la signature du disque j'ai une (grosse) difficulté
| > de compréhension. La séquence/programme de démarrage fait
| > 442 octets , ce qui chez moi englobe les deux premiers octets
| > de la signature du disque 2B EE 2B EE ?
| >
| > visible sur ce petit pense-bête que je suis en train de faire :
| > http://cjoint.com/?gbqUbx5ILX
|
| Non, j'ai visualisé ta pièce jointe et la sequence de démarrage
| s'arrète bien aux octets 0x2C,0x4A,0x7C qui servent à afficher
| les messages d'erreurs (voir la séquence désassemblée) :
| 1er message à 0x012C
| 2ème message à 0x014A
| 3ème message à 0x017C
|
| Et ta signature commence bien à l'offset 0x01B8.
|
:-) J'aurais dû poser ma question différemment;
442 octets donc fin de séquence de démarrage en
441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
il écrase les deux premiers octets de la signature 0x01B8
et 0x01B9 . Par contre si cette séquence ne fait que
440 octets, elle finit bien sur l'octet contenant 0x7C à
l'offset 0x01B7 .
| La séquence désassemblée :
| :0000.0600 33C0 xor ax, ax
| :0000.0602 8ED0 mov ss, ax
| :0000.0604 BC007C mov sp, 7C00
| :0000.0607 FB sti
|
| [...]
|
Tu connais de bons tutoriaux accessibles sur Internet ? J'ai fait
beaucoup d'Assembleur ... mais c'est loin ... loin ; par contre C
je ne l'ai jamais pratiqué ... et je n'ai aucune prétention que de
m'amuser avec de petits programmes et comme tout le monde
je manque de temps... :-)
Michel_D écrit dans
news:%23Mkin%23QpHHA.3264@TK2MSFTNGP04.phx.gbl
| > Michel_D a écrit dans
| >
[..]
| > | J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
| >
| > À propos de la signature du disque j'ai une (grosse) difficulté
| > de compréhension. La séquence/programme de démarrage fait
| > 442 octets , ce qui chez moi englobe les deux premiers octets
| > de la signature du disque 2B EE 2B EE ?
| >
| > visible sur ce petit pense-bête que je suis en train de faire :
| > http://cjoint.com/?gbqUbx5ILX
|
| Non, j'ai visualisé ta pièce jointe et la sequence de démarrage
| s'arrète bien aux octets 0x2C,0x4A,0x7C qui servent à afficher
| les messages d'erreurs (voir la séquence désassemblée) :
| 1er message à 0x012C
| 2ème message à 0x014A
| 3ème message à 0x017C
|
| Et ta signature commence bien à l'offset 0x01B8.
|
:-) J'aurais dû poser ma question différemment;
442 octets donc fin de séquence de démarrage en
441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
il écrase les deux premiers octets de la signature 0x01B8
et 0x01B9 . Par contre si cette séquence ne fait que
440 octets, elle finit bien sur l'octet contenant 0x7C à
l'offset 0x01B7 .
| La séquence désassemblée :
| :0000.0600 33C0 xor ax, ax
| :0000.0602 8ED0 mov ss, ax
| :0000.0604 BC007C mov sp, 7C00
| :0000.0607 FB sti
|
| [...]
|
Tu connais de bons tutoriaux accessibles sur Internet ? J'ai fait
beaucoup d'Assembleur ... mais c'est loin ... loin ; par contre C
je ne l'ai jamais pratiqué ... et je n'ai aucune prétention que de
m'amuser avec de petits programmes et comme tout le monde
je manque de temps... :-)
Michel_D écrit dans
news:%23Mkin%
| > Michel_D a écrit dans
| >
[..]
| > | J'ai oublié de préciser que fixmbr n'écrase pas la table de partition.
| >
| > À propos de la signature du disque j'ai une (grosse) difficulté
| > de compréhension. La séquence/programme de démarrage fait
| > 442 octets , ce qui chez moi englobe les deux premiers octets
| > de la signature du disque 2B EE 2B EE ?
| >
| > visible sur ce petit pense-bête que je suis en train de faire :
| > http://cjoint.com/?gbqUbx5ILX
|
| Non, j'ai visualisé ta pièce jointe et la sequence de démarrage
| s'arrète bien aux octets 0x2C,0x4A,0x7C qui servent à afficher
| les messages d'erreurs (voir la séquence désassemblée) :
| 1er message à 0x012C
| 2ème message à 0x014A
| 3ème message à 0x017C
|
| Et ta signature commence bien à l'offset 0x01B8.
|
:-) J'aurais dû poser ma question différemment;
442 octets donc fin de séquence de démarrage en
441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
il écrase les deux premiers octets de la signature 0x01B8
et 0x01B9 . Par contre si cette séquence ne fait que
440 octets, elle finit bien sur l'octet contenant 0x7C à
l'offset 0x01B7 .
| La séquence désassemblée :
| :0000.0600 33C0 xor ax, ax
| :0000.0602 8ED0 mov ss, ax
| :0000.0604 BC007C mov sp, 7C00
| :0000.0607 FB sti
|
| [...]
|
Tu connais de bons tutoriaux accessibles sur Internet ? J'ai fait
beaucoup d'Assembleur ... mais c'est loin ... loin ; par contre C
je ne l'ai jamais pratiqué ... et je n'ai aucune prétention que de
m'amuser avec de petits programmes et comme tout le monde
je manque de temps... :-)
Michel_D écrit dans le message de
news:f418lb$2cf$
|
| >
| > |
[...]
| > 442 octets donc fin de séquence de démarrage en
| > 441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
| > séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
| > il écrase les deux premiers octets de la signature 0x01B8
| > et 0x01B9 . Par contre si cette séquence ne fait que
| > 440 octets, elle finit bien sur l'octet contenant 0x7C à
| > l'offset 0x01B7 .
|
|
| La séquence restaurée par fixmbr ne fait que 440 octets.
|
C'est bien ce que je pensais :-)
| > | La séquence désassemblée :
| > | :0000.0600 33C0 xor ax, ax
| > | :0000.0602 8ED0 mov ss, ax
| > | :0000.0604 BC007C mov sp, 7C00
| > | :0000.0607 FB sti
| > | [...]
|
Si je ne suis pas indiscret, comment récupères-tu le
code objet de la séquence dans le MBR ?
| Je ne connais pas de bon tutoriaux, seulement de la pratique
| sous Turbo Pascal, pour par exemple mon gestionnaire de boot.
|
| Nota: Ce n'est que quelque notion de programmation en mode
| réel, mais cela sert parfois.
|
Est-ce un outil pour ton usage personnel ou bien un outil que
tu as diffusé ?
Michel_D écrit dans le message de
news:f418lb$2cf$1@news.rd.francetelecom.fr
|
| >
| > |
[...]
| > 442 octets donc fin de séquence de démarrage en
| > 441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
| > séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
| > il écrase les deux premiers octets de la signature 0x01B8
| > et 0x01B9 . Par contre si cette séquence ne fait que
| > 440 octets, elle finit bien sur l'octet contenant 0x7C à
| > l'offset 0x01B7 .
|
|
| La séquence restaurée par fixmbr ne fait que 440 octets.
|
C'est bien ce que je pensais :-)
| > | La séquence désassemblée :
| > | :0000.0600 33C0 xor ax, ax
| > | :0000.0602 8ED0 mov ss, ax
| > | :0000.0604 BC007C mov sp, 7C00
| > | :0000.0607 FB sti
| > | [...]
|
Si je ne suis pas indiscret, comment récupères-tu le
code objet de la séquence dans le MBR ?
| Je ne connais pas de bon tutoriaux, seulement de la pratique
| sous Turbo Pascal, pour par exemple mon gestionnaire de boot.
|
| Nota: Ce n'est que quelque notion de programmation en mode
| réel, mais cela sert parfois.
|
Est-ce un outil pour ton usage personnel ou bien un outil que
tu as diffusé ?
Michel_D écrit dans le message de
news:f418lb$2cf$
|
| >
| > |
[...]
| > 442 octets donc fin de séquence de démarrage en
| > 441 , soit en Hexa offset 0x01B9 ; si le code assemblé de la
| > séquence, écrit sur le disque, va de 0x000 à 0x01B9 ,
| > il écrase les deux premiers octets de la signature 0x01B8
| > et 0x01B9 . Par contre si cette séquence ne fait que
| > 440 octets, elle finit bien sur l'octet contenant 0x7C à
| > l'offset 0x01B7 .
|
|
| La séquence restaurée par fixmbr ne fait que 440 octets.
|
C'est bien ce que je pensais :-)
| > | La séquence désassemblée :
| > | :0000.0600 33C0 xor ax, ax
| > | :0000.0602 8ED0 mov ss, ax
| > | :0000.0604 BC007C mov sp, 7C00
| > | :0000.0607 FB sti
| > | [...]
|
Si je ne suis pas indiscret, comment récupères-tu le
code objet de la séquence dans le MBR ?
| Je ne connais pas de bon tutoriaux, seulement de la pratique
| sous Turbo Pascal, pour par exemple mon gestionnaire de boot.
|
| Nota: Ce n'est que quelque notion de programmation en mode
| réel, mais cela sert parfois.
|
Est-ce un outil pour ton usage personnel ou bien un outil que
tu as diffusé ?