Il semble que jusqu'à 2Gb il n'y ait pas de souci.
J'ai tenté avec un (CRC en hexa)
2.04Gb : 4444 4646 (commence à faire bizarre)
3Gb : 6969 6969
29Gb : D4D4 D4D4
Je vais essayer de faire un test en générant des fichiers de différentes tailles pour voir où commence ce phénomène ...
Depassement de capacité n'a pas de sens en C, certainement faudrait que je te change l'algo du CRC que je n'avais pas testé sur de gros fichiers.
Je vois ça dès que possible.
Merci beaucoup, bn
J'ai mis en application et le tout fonctionne.
Si tu le permets, je vais publier une nouvelle source VB avec cette DLL, avec le lien, bien entendu, symbole d'une fructueuse collaboration !
Juste avant, une petite question :
Sur le calcul de CRC des gros fichiers (~12Go), les résultats ont vraiment des formes particulières (sans signalement de défaut de la part de la DLL) :
Par exemple, sur un fichier de 12.8Gb, le résultat donne 6B6B 6B6B
Sur un autre de 7.4Gb, j'obtiens F1F1 F1F1
Pour 1.93Gb, FCFC FCFC
Pour 583Mb, 3738 B9BA
Ces résultats sont les mêmes avec cette DLL (zip du dernier msg) et avec la DLL de ta source.
Ces résultats me paraissent bien singuliers dès que la taille des fichiers augmentent.
Y aurait-il un problème de saturation de capacité de variable ?
Salut BN
Je me risque dans cet espace CPP que je ne maîtrise pas, d'où les questions suivantes :
Mon terrain de prédilection, c'est VB6.
Pour mes sauvegardes perso, j'ai besoin de vérifier l'intégrité des fichiers transférés.
Sous VB6, l'instruction Get limite le pointeur d'accès aux données à 2Go (Long de VB6)
Je recherche donc une DLL capable de lire elle même les données et de me fournir ce fameux CRC.
J'ai un peu regardé dans cette source, mais j'ai du mal à comprendre si c'est l'EXE d'exemple ou la DLL qui assure cette tâche de lecture de buffer.
Je pense que c'est l'EXE car j'ai vu ta variable ONEMEGA (judicieusement nommée) et qui semble être la taille du buffer traité.
Me trompe-je ?
Serait-il pensable de fabriquer une DLL à laquelle on fournirait la chaine d'accès au fichier depuis VB6 ?
Merci de tes éclaircissements.
OK pour la liste des instructions (il y a aussi la fpu dedans, je signale), le reste est vraiment pas terrible.
J'ai retenu un passage intéressant:
"Qu'est ce que la canalisation? C'est un principe simple permettant la canalisation de instructions"
La suite est plus explicite, mais c'est le genre de phrase que je n'aime pas lire
ah oui à partir d'un angle 40, on est déjà hors liste car table fait 80 octets et il multiplie l'angle par 2 avant:
mov ax, [bx]
c'est du grand nimporte quoi, je n'avais pas lu les exemples et ils sont à éviter. L'intérêt du bouquin est dans la liste des instructions en format poche.
On ne peut pas faire autrement mais faut bien avouer que en pdf (de m***de), les manuels Intels ne sont pas pratiques à consulter, faudrait les passer en chm.
J'ai regardé le livre assembleur x86 à 10 euros dont vous parlez plus haut et je le trouve plutot inconsistant (très peu d'exemples en particulier, c'est pas terrible pour débuter). Une bonne partie du livre est la description des instructions, on peut trouver ca en mieux dans les livres intel. En plus je trouve que c'est mal écrit (on dirait que le gars ne se relit pas, c'est horrible)
Si quelqu'un a compris l'exemple pp 326-327 sur la table des sinus... Parce que j'ai pas trop compris un truc (il divise 571 par 32678, ca va donner 0, non?)
Je dis pas que c'est une arnaque parce qu'il est pas très cher, mais je suis plutot décu
Moi je suis du genre a poster une source plus mauvaise que la précédente, enfin quand c'est possible, parce que si la premiere source et vraiment médiocre... Lol enfin vous m'aurez compris :). J'aime bien aussi poster des commentaires sans passer de ligne, pour voir jusqu'ou le forum peut bugger lol
Si si j'ai vu. Mais ça ne change pas grand chose, j'ai acheté
ce livre (celui à 45 euros)il y quelques mois et je le trouve
très bien. Pourquoi ne le conseillerais tu pas ?
et tu n'as pas vu que celui que j'ai indiqué est sur la page que tu donnes, et bien à 10 euros. Dommage car je ne conseillerais pas celui que tu as pris.
ok,merçi pour votre aide.Cela confirme ce que je pensais.
Mais un livre type "Intel IA32" par exemple ne comprend t'il pas les explications du language assembleur ?
Et excuses pour ne parler seulement du code posté ici,j'aurai certainement plus de questions une fois ce livre sur assembleur lu.
Oui il est à la fnac, en revanche, j'aurais préféré l'acheter à 10 euros comme le dit Brunews, plutôt qu'à 45... je ne sais pas où t'as put avoir ce bouquin à 10 euros, mais t'es bien chanceux ! Faudrait que tu me donnes des tuyaux ;).
ASM dépend de:
- Processeur cible: ici compatible Intel 386 et supérieur.
- De l'Assembleur qu'utilise ton environnement de dev, si c'est MS ou Borland alors syntaxe standard Intel comme ici.
Pour 10 euros, "Assembleur x86" chez CampusPress est très bien.
le langage assembleur dépend des processeur, mais pour les pc, c'est x86 (si je me souviens bien) donc il te faut un assembleur x86, l'environement de dev ne change rien. Attention, le code assembleur ne change pas entre les AMD et les INTEL ou changement de fréquence, par contre le code assembleur PC est différent de celui de MAC. Il doit y avoir des petites subtilitée que je dois pas connaitre sur l'assembleur car j'ai jamais rien programmé avec, je le "comprend" juste un petit peu.
interessante ta source.
p'tite question:
y'a t'il qu'un language assembleur ou change t'il en fonction du proc utilisé ou de l'environnement de dev?
y'a t'il un livre a conseiller?
je parle de la navigation dans les winks, ya une astuce pour tous les avoir et le tps d'ouvrir le panneau de selection des winks ben tu peux aller boire le café, ya que une 50ene de winks pourtant ...
lol !! tu m'étonne qu'il fasse que 3.5 ko, ya que de l'asm sauf une fonction dedans, meme le winmain est codé en asm ...
Pour ce qui est de la vitesse, c'est mon disque dur qui limite. Le pross est seulement utilisé a 10%. Si tout les programmeurs étaient comme toi (et surtout ceux de microsoft) on aurait droit a des pc qui iraient deja 3* plus vite, sic, (sans dec vous avez vous le systeme des winks pour msn, ça ramme a la couane ... a se demander si ils le ralentissent pas expres ...)
Je suis sûr que je vais en avoir besoin pour augmenter la rapidité de mon SFV Checker :)
Pour les gros fichiers j'avais aussi préféré VirtualAlloc à HeapAlloc.
Bravo pour ce bien bel exemple une fois de plus ;)
- Messages postés
-
14008
- Date d'inscription
- samedi 29 décembre 2001
- Statut
- Modérateur
- Dernière intervention
- 28 août 2015
68J'ai tenté avec un (CRC en hexa)
2.04Gb : 4444 4646 (commence à faire bizarre)
3Gb : 6969 6969
29Gb : D4D4 D4D4
Je vais essayer de faire un test en générant des fichiers de différentes tailles pour voir où commence ce phénomène ...
- Messages postés
-
21042
- Date d'inscription
- jeudi 23 janvier 2003
- Statut
- Modérateur
- Dernière intervention
- 21 août 2019
20- Messages postés
-
21042
- Date d'inscription
- jeudi 23 janvier 2003
- Statut
- Modérateur
- Dernière intervention
- 21 août 2019
20Je vois ça dès que possible.
- Messages postés
-
14008
- Date d'inscription
- samedi 29 décembre 2001
- Statut
- Modérateur
- Dernière intervention
- 28 août 2015
68J'ai mis en application et le tout fonctionne.
Si tu le permets, je vais publier une nouvelle source VB avec cette DLL, avec le lien, bien entendu, symbole d'une fructueuse collaboration !
Juste avant, une petite question :
Sur le calcul de CRC des gros fichiers (~12Go), les résultats ont vraiment des formes particulières (sans signalement de défaut de la part de la DLL) :
Par exemple, sur un fichier de 12.8Gb, le résultat donne 6B6B 6B6B
Sur un autre de 7.4Gb, j'obtiens F1F1 F1F1
Pour 1.93Gb, FCFC FCFC
Pour 583Mb, 3738 B9BA
Ces résultats sont les mêmes avec cette DLL (zip du dernier msg) et avec la DLL de ta source.
Ces résultats me paraissent bien singuliers dès que la taille des fichiers augmentent.
Y aurait-il un problème de saturation de capacité de variable ?