VB6, CALCUL LE CRC D'UN FICHIER: MODULE.VB ET API.ZLIB
yan35
Messages postés
185
Date d'inscription
dimanche 29 juin 2003
Statut
Membre
Dernière intervention
20 juin 2013
-
20 déc. 2006 à 11:02
ritalino60 Messages postés 1 Date d'inscription vendredi 12 juin 2009 Statut Membre Dernière intervention 12 juin 2009 - 12 juin 2009 à 10:26
ritalino60 Messages postés 1 Date d'inscription vendredi 12 juin 2009 Statut Membre Dernière intervention 12 juin 2009 - 12 juin 2009 à 10:26
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40785-vb6-calcul-le-crc-d-un-fichier-module-vb-et-api-zlib
https://codes-sources.commentcamarche.net/source/40785-vb6-calcul-le-crc-d-un-fichier-module-vb-et-api-zlib
12 juin 2009 à 10:26
Merci bcp bonne journée
Voici le programme:
1) création d’un ligiciel d’acquisition de mesure
Ecriver un prog (analyse en pseudocode + en vb) qui permetra, la résolution du problème ci-dessous.
Votre prog permetra la lesture de 4 mesure de tension su un/des convertisseur analogique/numérique (can) 12bits ( valeur = 2³ à 2² de byte1 * 256 + 2^7 à 2^0 de byte 2) , (les lecture sont à simuler de facon aléatoire (fonction rnd)).Le phénomène (variation des mesures) est considéré comme « lent ». La configuration suivante : un seul convertisseur et un multiplexeur à 4 canaux peut éventuellement convenir.
La série de mesures doit être prise toutes les 120 sec (toutes les deux « minutes pleines » , le nombre de sec =00)
Les mesures seront stockées dans un fichier à acces séquentiel. Une trame d’information étant structurée de la manière suivante.
jj / MM /AA / HH / MM / SS / M1L / M1H / M2L / M2H / M3L / M3H / M4H / CRC16L / CRC16H
jj MM AA rerésente la date ; jour – moi- année = 3 bytes (pour l’année, on retranche 2000 avant stockage et on ne reprend que les deux dernier chiffre)
HH MM SS représente l’heure : heure minute seconde = 3bytes (SS toujours égal à 00).
M1H M1L … M8H M8L représente les mesures de (0 à 16*256 +255 2bytes) 16bytes.
CRC16L CR16H représente le calcul du checksum = 2bytes. Ce CRC16 vous donnera une indication sur la validité de votre trame d’information.
28 déc. 2006 à 22:52
Cordialement
28 déc. 2006 à 22:39
De toute façon c'etait trop lent !
J'ai donc fait deux méthodes biens distinctes: VB-CRC et ZLIB-CRC.
Vu qu'il n'y as pas de norme particulière pour ce calcul, on peut très bien accepter une valeure de CRC différente; surtout si ca a comme effet d'accelerer l'executions des routines.
Le compilateur C permet de faire des calculs que VB ne supportent pas.
[C]; Pour la compatibilité, on dit ZLIB.
[VB]; Pour la rapidité, on dira Vérification Parallèle.
La suite logique serait que quelqu'un optimise ce code d'avantage.
Pas pour en faire un code qui soit compatible, VB lui meme ne l'es pas.
Mais plutot de marginaliser un code fiable et rapide pour les programmeurs en basic.
27 déc. 2006 à 11:32
27 déc. 2006 à 03:58
<Je reprends ton calcul pour le comparer avec celui que j'utilise. Je ne tombe pas sur le même résultat.>
- Pourquoi devrais-t'il etre les mêmes ?
- Il n'y a pas de loi universelle pour définir la résultante d'une redondance entre guillmet "physique" ?
Exemple: 2 sportifs avec les memes baskets, mais un a les semelles plus usées; quel est le résultat de cette perte d'adhésion sur 150 mètres ?
Résultat: optimisation.
Exemple comparatif CRC sur un (SCSI°2) vs (UDMA-66) ?
Résultat: rapidité.
Exemple de cryptage, peut importe ton algorithme final, sans ta clé sa doit être difficile à décrypter.
Résultat: performance
OBJECTIF COMMUN: une solution
<Je teste donc + loin et je m'apperçois que tu n'obtiens pas non + le même résultat entre ta méthode VB et la zLib !>
- Le temps d'affichage entre "Internet explorer" et "Firefox" a afficher la même page ?
- L'exemple qui ce rapproche de nos méthodes:
- Un Anti-Virus.
- Pourquoi un AV examiant une même signature est plus rapide sur l'un que sur l'autre ?
- Il n'utilise peut etre pas les mêmes calculs, mais ce qui importe pour eux c'est de reconnaitre la menace au profit de la satisfaction de son utilisateur.
- Toujours une histoire de résultat !
- Un résultat n'est qu'une forme linéaire d'une conséquence.
Définisons une conséquence:
- Si A est égale à 1+1+1, c'est B
- Si A n'est pas égale à 1+1+1, c'est C
- Le résulat de ma séquence c'est B
- Si Mr.XY, dit: Si A est égale à 2+1, c'est C
- Si A n'est pas égale à 3, c'est R
- Le résultat de la séquence de Mr.XY c'est C
Test Yan35:
Non modifié: DF8AA9
1 byte changé: E9BFF0
Résultat: Approuvé fonctionnel
Test Duke49:
Non modifié: 14FB77
1 byte changé: F9E9A0
Résultat: Approuvé fonctionnel
Le point fort qui détermine nos conséquences est une solution.
Peut importe la façon et dérivé de le faire !
Les solutions ont eux memes plusieurs sous solutions...
Si tu voie une objection aux sous-solutions, je veut bien en débattre :)
27 déc. 2006 à 02:02
Je reprends ton calcul pour le comparer avec celui que j'utilise. Je ne tombe pas sur le même résultat. Je teste donc + loin et je m'apperçois que tu n'obtiens pas non + le même résultat entre ta méthode VB et la zLib !
Désolé, j'ai refait plusieurs fois l'essai ... Enfin, il est tard, je ne vois peut-être plus clair.
Cordialement.
22 déc. 2006 à 19:22
Bref, sinon le code est fonctionnel, bravo ! Très belle source et woahouuw quelle rapidité :O
J'aime les sources ou l'on pense à décharger des variables trop lourde, on en vois pas souvent.
Je ne note pas car je ne me suis pas penché sur la subtilité du code mais d'après ce que j'ai pu voir ça mérite bien un 10
20 déc. 2006 à 18:23
pfff... fatigué.
20 déc. 2006 à 13:22
Si sa sature en mémoire, j'avais mise au point le calc en fractionnant le fichier lors de sa lecture.
On peu très bien suivre cette routine pour un fichier allant jusqu'a
10 mégas.
<=10mo = VB-CRC lecture en 1 passe.
<=50mo = VB-CRC lecture en 5 passes.
<=100mo = VB-CRC lecture 10 passes.
...
<=1000mo = VB-CRC lecture 100 passes.
Pour la rapidité j'ai prit ta facon de timer et j'ai fait un test.
Pour 16.257.024 octets, il met 5,921875 secondes sur mon vieux-coucou.
20 déc. 2006 à 11:02
J'ai hâte de voir comment tu fais et de voir si ton calcul est + performant que celui que j'avais repris et adapté dans l'amélioration d'une classe Zip (http://www.vbfrance.com/codes/CLASSE-ZIP-POUR-ZIPPER-OU-DEZIPPER_40387.aspx), lorsque je n'utilise pas la zlib.
Cas où la mise en tableau d'octets d'1 trop gros fichier sature la mémoire lors de l'entrée dans la zlib.
De toutes façons le calcul fonctionne, alors je note 10, et je le reprendrai si + rapide. MERCI