Travaux pratiques: Dump fichier

Un petit exercice vite fait de dump d'un fichier en hexadécimal, pour tester la fonction FILE_READBUF. C'est bien ce que j'attendais, celle-ci est insensible aux caractères de fin d'article.
Le programme dumpe 67 lignes de 16 octets (modulable), mais manque d'un test de fin de fichier, je n'ai pas trouvé comment faire (il n'y a pas de génération d'erreur si on dépasse).
On peut imaginer facilement de poursuivre la lecture par blocs d'affichage.
Il manque maintenant un moyen de fixer le pointeur de lecture, et un FILE_Writebuf pour écrire où on veut. EDIT: pardon, je n'avais pas lu la rubrique "Ce qui est en cours..." du 7/12

Code:

REM DUMP.BAS dump hexadécimal de fichier
DIM f$, a$, b$, c$, ll%, nbl%, ad, i%, j%, car$, x$
DIM d, h$, lh%
DIM hx$(16)
hx$(0)="0":hx$(1)="1":hx$(2)="2":hx$(3)="3":hx$(4)="4":hx$(5)="5"
hx$(6)="6":hx$(7)="7":hx$(8)="8":hx$(9)="9":hx$(10)="A":hx$(11)="B"
hx$(12)="C":hx$(13)="D":hx$(14)="E":hx$(15)="F"
LABEL ConvHex

CAPTION 0, "Dump fichier"
FULL_SPACE 0
WIDTH 0, 530
MEMO 3
FULL_SPACE 3

REM ***** Choix du fichier
OPEN_DIALOG 1
f$ = FILE_NAME$(1): REM f$= nom absolu du fichier choisi
IF LEN(f$) < 2 THEN END: REM clic bouton Annuler
CAPTION 0, "Dump "+f$

ll% = 16: REM nombre d'octets par ligne
nbl% = 67: REM nombre de lignes à éditer

PRINT_TARGET_IS 3
FONT_NAME 3,"Courier New"
FILE_OPEN_READ 2,f$
ad = 0
FOR j% = 1 TO nbl%
  FILE_READBUF 2, a$, ll%: REM lecture de ll% octets
  d = ad: lh% = 5: GOSUB ConvHex
  c$ = h$+": "
  b$ = " "
  FOR i% = 1 to ll%
    car$ = MID$(a$, i%, 1)
    x$ = ".": IF ASC(car$) >= 32 THEN x$ = car$
    b$ = b$ + x$
    d = ASC(car$): lh% = 2: GOSUB ConvHex
    c$ = c$ + h$ + " "
  NEXT i%
  PRINT c$ + b$
  ad = ad + ll%
NEXT j%
FILE_CLOSE 2
END

ConvHex:
REM conversion décimal/hexa de d, résultat h$ sur lh% caractères
h$=""
REPEAT
  h$ = hx$(16*(d/16 - INT(d/16))) + h$: d = INT(d/16)
UNTIL d <= 0
IF LEN(h$) < lh% THEN h$ = STRING$(lh% - LEN(h$), "0") + h$
RETURN

Bravo pour votre programme de DUMP et votre conversion décimal/hexadécimal.

Comme annoncé dans la rubrique "Ce qui est en cours", une commande et une fonction qui répondent à votre besoin sont en préparation:

FILE_WRITEBUF N,V$,S
Commande d'écriture dans le fichier numéro N de S octets à partir de la position courante, ces octets viennent de la variable chaine Vs.
Le pointeur courant se déplace de S positions. Si S est supérieur au nombre de caractères de la variable, tous les caractères de la variable sont écrits dans le fichier, et des caractères SPACE (c'est à dire " ") sont ajoutés jusqu'à concurrence de S.

FILE_EOF(N)
Fonction qui retourne 1 si la fin du fichier numéro N est atteinte, 0 sinon.

N'aurait-il pas été plus simple (histoire d'économiser un paramètre) de lire ou d'écrire systématiquement la longueur de V$ (comme en Basic):
FILE_WRITEBUF n, V$
ou
V$ = SPACE$(20)
FILE_READBUF n, V$: REM lecture de 20 octets
----------------------------------------------------------------
Y a-t-il un moyen simple d'obtenir la taille d'un fichier ?
----------------------------------------------------------------
Fausse joie en ce qui concerne le dump, je n'ai pas assez testé:
la fonction FILE_READBUF reste bloquée sur le premier caractère '1A' rencontré, après on n'a plus que des 1A ...
----------------------------------------------------------------
J'ai légèrement modifié le code ci-dessus pour le rendre plus propre, mais après tests un peu plus poussés sur des fichiers 'binaires' (exécutables, ou images), je tombe souvent en erreur 'Not a correct expression. Error in ASC() function Line 36', c'est à dire:

Code:

x$ = ".":IF ASC(car$) >= 32 THEN x$ = car$

toujours au même endroit pour un fichier donné, différent suivant les fichiers, mais pas sur un caractère particulier.

Autant pour moi, j'ai regardé de plus près et ça bute toujours sur le même caractère: 34

Code:

DIM car$, x%
car$ = CHR$(34)
x% = ASC(car$)

ne marche pas.

Je regarde votre exemple sur le code ASCII 34.

En fait ce qui ne marche pas c'est le:
car$ = CHR$(34), qui rend un caractère vide, ce qui donne une erreur dans la fonction ASC(car$).
Dans mon programme, si le car$ = MID$(a$,i,1) rencontre un caractère 34, ça coince.
J'ai mis une rustine en mettant:
IF car$ = "" THEN d = 34: GOTO ssui
d = ASC(car$)
ssui:
...
ça ne plante plus, mais ce n'est pas très joli.
On peut très bien avoir à écrire (ça marche en Basic):
a$ = CHR$(34) + "ABC" + CHR$(34), ce qui devrait rendre la chaîne "ABC", guillemets compris (par exemple certains programmes appelés exigent des paramètres entre guillemets).

ASC(A$) ne fonctionne pas si A$ contient le code ASCII 34 en premier caractère.
Ce bug sera corrigé dans la prochaine version.

Je précise bien que c'est le fait de mettre le caractère 34 dans une chaîne qui ne marche pas, par exemple: c$ = CHR$(34)
ASC(c$) est une conséquence, tombe en erreur puisque c$ est vide.
A vérifier s'il marcherait si c$ contenait effectivement le caractère 34.

En fait, Panoramic dérape quand une chaîne commence ET finit par un guillemet (a fortiori un guillemet tout seul). Exemple:

Code:

DIM a$
a$ = STRING$(10, CHR$(34))
PRINT STR$(LEN(a$)) + " " + a$: REM Faux
a$ = "A"+STRING$(10, CHR$(34))+"B"
PRINT STR$(LEN(a$)) + " " + a$: REM Correct
a$ = STRING$(10, CHR$(34))+"B"
PRINT STR$(LEN(a$)) + " " + a$: REM Correct
a$ = "A"+STRING$(10, CHR$(34))
PRINT STR$(LEN(a$)) + " " + a$: REM Correct

Merci de vos précisions et de vos tests.
PANORAMIC a besoin d'être testé jusque dans ses retranchements, c'est comme cela qu'il va s'améliorer, ce qui est mon but.

J'ai corrigé mon programme de dump en fonction des nouvelles instructions concernant les fichiers binaires:

Code:

REM * DUMP.BAS dump hexadécimal de fichier *
DIM f$, a$, b$, c$, ll%, nbl%, ad, i%, j%, x$, lof
DIM d, h$, lh%
LABEL ConvHex, nxf

CAPTION 0, "Dump fichier"
FULL_SPACE 0
WIDTH 0, 530
MEMO 3
FULL_SPACE 3

REM ***** Choix du fichier
OPEN_DIALOG 1
f$ = FILE_NAME$(1): REM f$= nom absolu du fichier choisi
IF LEN(f$) < 2 THEN END: REM clic bouton Annuler

FILEBIN_OPEN_READ 2, f$: REM ouverture binaire du fichier
lof = FILEBIN_SIZE(2): REM taille du fichier
CAPTION 0, f$

ll% = 16: REM nombre d'octets affichés par ligne
nbl% = 67: REM nombre de lignes à éditer

PRINT_TARGET_IS 3: FONT_NAME 3, "Courier New"
ad = 0
FOR j% = 1 TO nbl%
  IF FILEBIN_POS(2) >= lof THEN GOTO nxf
  d = ad: lh% = 5: GOSUB ConvHex
  a$ = h$ + ": "
  b$ = " ": c$ = ""
  FOR i% = 1 TO ll%
    IF FILEBIN_POS(2) < lof
      FILEBIN_READ 2, d
      x$ = ".": IF d >= 32 THEN x$ = CHR$(d)
      b$ = b$ + x$
      lh% = 2: GOSUB ConvHex
      c$ = c$ + h$ + " "     
    END_IF
  NEXT i%
  IF LEN(c$) < ll%*3 THEN c$ = c$ + STRING$(3*ll% - LEN(c$), " ")
  PRINT a$ + c$ + b$
  ad = ad + ll%
NEXT j%
nxf:
FILEBIN_CLOSE 2
END

ConvHex:
REM conversion décimal/hexa de d, résultat h$ sur lh% caractères
h$=""
REPEAT
  h$ = MID$("0123456789ABCDEF", 1+16*FRAC(d/16), 1) + h$
  d = INT(d/16)
UNTIL d <= 0
IF LEN(h$) < lh% THEN h$ = STRING$(lh% - LEN(h$), "0") + h$
RETURN

Remarques:
- la fonction FILE_EOF(N) semble refusée pour les fichiers binaires ("File not in use..").
- on doit lire le fichier octet binaire par octet (contrairement au Basic où on peut lire une grande chaîne d'un coup sous forme Ascii et en extraire ensuite les octets binaires par des ASC(MID$...).
- le branchement sauvage après le NEXT j% pour sortir de la boucle en cas de fin de fichier n'est pas très élégant, dommage qu'il n'y ait pas un EXIT FOR. Peut-être vaudrait-il mieux mettre le test avant le next et écrire j% = nbl%+1 pour sortir tout de suite ?

Bravo pour votre nouveau programme de dump!

Je me rends compte qu'il manque la possibilité à un MEMO d'avoir un ascenseur vertical, horizontal ou même les deux car lorsqu'on "dumpe" un fichier important, il est impossible de visualiser le début du fichier.
Je vais regarder la faisabilité des commandes:
BAR_HORIZONTAL Numéro pour mettre un ascenseur horizontal à l'objet numéro N
BAR_VERTICAL Numéro pour mettre un ascenseur vertical à l'objet numéro N
BAR_BOTH Numéro pour mettre un ascenseur horizontal et un ascenseur vertical à l'objet numéro N
BAR_NONE Numéro pour ne mettre aucun ascenseur à l'objet numéro N

1 - En effet, la fonction FILE_EOF(Numéro) ne s'applique qu'aux fichiers textes.
Pour savoir si la fin de fichier est atteinte, il suffit comme vous le faites, de comparer la position actuelle à la taille du fichier, et pour ne pas recalculer la taille à chaque fois, de mettre celle ci dans une variable:

Code:

eof=FILEBIN_SIZE(2): rem taille du fichier numéro 2
if FILEBIN_POS(2)<eof THEN - - -

2 - Les fichiers binaires doivent être lus octets par octet, pour l'instant.
Avec une nouvelle commande (à développer) du type
FILEBIN_READBUF Numéro_de_fichier, Tableau_Entiers , Nombre_octets
Il serait possible de remplir directement un tableau d'entiers.
Je pense à un code du genre, par exemple, pour lire 100 octets à la fois et les placer à partir de v%(25):

Code:

dim v%(150)
filebin_open_read 1,"test"
filebin_readbuf 1,v%(25),100
filebin_close 1

3 - Sortir brutalement d'une boucle FOR / NEXT n'a aucune importance pourvu qu'on ne réutilise pas l'indice de boucle dans une deuxième boucle!
Ainsi l'exemple:

Code:

dim i%

label loop2

for i%=1 to 10
 print i%
 if i%=5 then goto loop2
next i%

loop2:
print "boucle 2"
for i%=1 to 10
 print i%
 if i%=5 then end
next i%

provoque le message d'erreur "Variable Already Used In An External Loop." lors du début de la deuxième boucle.
En fait, cette contrainte n'a aucune raison d'exister. Lorsque je l'ai codée, je pensais éviter ainsi des boucles imbriquées utilisant la même variable comme indice. Mais en Basic, on doit pouvoir sortir d'une boucle par un GOTO puis faire ce que l'on veut.
Je vais supprimer cette contrainte dans la prochaine version : il sera possible de réutiliser dans une autre boucle la variable d'une boucle par laquelle on est sorti.

4 - un EXIT_FOR comme un EXIT_SUB pourraient être envisagés. Je vais regarder la faisabilité.

Effectivement, j'avais limité le dump aux 67 premières lignes (*16 octets) par manque d'ascenseur. Ce sera évidemment beaucoup mieux de pouvoir tout voir d'un coup.

La lecture octet par octet ne me gêne pas, c'est même plus facile à programmer, mais ce serait pour ne pas faire un accès disque à chaque octet. Maintenant en réalité ça doit être tempéré par le buffer tampon du disque.

Pour l'exit sauvage d'une boucle, j'avais pensé que ça pouvait perturber une pile quelconque... effectivement l'exit_for ou l'exit_sub me semblent bien plus propres.

Et tout ça ça fait un peu plus de boulot à chaque fois !
Bon courage !

Citation :

Je me rends compte qu'il manque la possibilité à un MEMO d'avoir un ascenseur vertical, horizontal ou même les deux car lorsqu'on "dumpe" un fichier important, il est impossible de visualiser le début du fichier

Il y a un possibilité sans ascenseur c'est de sélectionner le texte et de descendre ou monter comme cela on vois tout le DUMP

PS:J'ai ésayer le DUMP mais je ne voie pas vraiment a quoi sa sert autre que de coder un document en binaire?

Eh bien, si on est un peu curieux (ce que doit être tout programmeur), ça permet de voir le contenu d'un fichier quelconque, sa structure, etc., et éventuellement de le modifier, en sachant bien ce que l'on fait.
Un exemple: on peut "dumper" l'en-tête d'un fichier image .bmp, savoir où sont stockées les informations de taille, de dimensions en pixels, de profondeur de couleurs, etc.
Ca permet de savoir où "patcher" un fichier en binaire avec un éditeur en hexadécimal. Prudemment évidemment si c'est un fichier important, et qu'on n'a pas d'autre moyen.
Ca permettait surtout, autrefois (il y a bien des lunes), d'étudier un vidage mémoire pour savoir ce qui avait fait planter la machine. Et en général dans l'urgence, devant un listing kilométrique, le stabilo à la main.

JL35 a écrit:

Ca permettait surtout, autrefois (il y a bien des lunes)Et en général dans l'urgence, devant un listing kilométrique, le stabilo à la main.

lol j'imagine ca ^^

Avec des exploitants derrière ton dos qui te disent "vous en avez pour longtemps pour trouver l'erreur ?"...

Ouhh ca sent le vécu ca non ?

Et bien justement je suis curieux et y t-il un endroit autre qu'au lycée (ou autre école) pour apprendre à comprendre les DUMP? Parce toute chose qui est plus ou moins compliqué il faut que au moins j'essaye de comprendre c'est un peu plus fort que moi...

Dans les livres huhu

Pas facile à trouver dans les livres, il n'y a plus que les spécialistes pour programmer en langage assembleur, c'est à dire le premier niveau de la machine, des instructions (traduites en binaire par l'assembleur) comprise directement par le processeur. Donc ça n'intéresse plus assez de monde pour en faire des livres, comme c'était le cas dans les années 70 et 80.
Mais il suffit d'abord de savoir lire l'hexadécimal (qui n'est qu'une représentation pratique du binaire qui régit toute l'informatique de base, des 0 et des 1).
Tu peux jeter un coup d'oeil ici: http://www.vulgarisation-informatique.com/binaire-hexa.php mais avec google on trouve tout ce qu'on veut. Evidemment il faut avoir des notions de mathématiques élémentaires.
Bon, ça entraîne un peu trop loin de Panoramic tout ça...

Ok et bien merci quand même...

^^ Moi j'ai testé l'ASM c'est bien compliqué ^^
sinon cherche sur le site du zéro

J'ai déjà "survolé" le site du zero et la je vais voir le lien de JL35 merci a vous deux pour votre aide

Je viens de regarder de plus près le DUMP mais logiquement un code binaire c'est fait qu'avec des nombres (?) non? parce que la il y a des lettres
je comprend pas trop le dump (plus sa va moin je comprend ^^)...


___________________________________________

Je n'ait rien dit...
Je vient de mieux regarder le site que JL35 m'a donné...