j'aime bien le merci 'quand même'.
oublie mon commentaire, je te met 10/10.

Salut,
En quoi le fait d'utiliser Sleep() permet d'eviter les erreurs du serveur ?
Il servirait pas plutot a masquer des bugs de ton propre programme ?

Salut,
Dommage que ton prog ne fasse pas le monitoring du nombre d'object GDI qu'il utilise, tu aurais été surpris ;)
Ouvre le gestionnaire des taches windows a coté de ton prog et regarde dans la colone 'Object GDI'. il suffit de déplacer ta fenetre quelques secondes pour que ca dépasse 1500 objets gdi, ce qui est vraiment enorme, surtout pour un prog de monitoring comme le tiens qui est destiné a rester lancé longtemp.
Verifie qu'a chaque fois que tu crée un object gdi (HFONT / HBITMAP / HBRUSH / HPEN / HRGN) tu le détruis bien des que tu n'en a plus besoin...
Bonne chasse aux bugs.

à ce moment la, pourquoi coder ? paint permet déjà d'ouvrir et d'éditer des bmp et il fait ca très bien aussi.

Salut,
Ca marche impec chez moi.

Salut,
C'est sur qu'avant d'ecrire dans le fichier, il faut prendre en compte les offsets de la reponse et pas ceux que tu as demandés, car ils peuvent etre different.
Par contre pour le fichier corrompu, je pense qu'il faut logguer toutes les requetes et les reponses et que tu fais, avec les offsets et les content-length des réponses, et verifier 'a la main'.

Ce qui est marrant avec SAKingdom, c'est que le truc qui sert a rien et qui fait perdre 1 milliardième de seconde au cpu, il le repère tout de suite, alors que le fait que le prog prenne 60 mo de mémoire et qu'il consomme en permanence 10-20% de cpu pendant le download d'un fichier de 50 mo, ça le choque même pas.

Plus serieusement, le HeapAlloc() de la taille du fichier, je pense que ca fait un peu lourd. Et aussi, le bouton download reste disponible lors d'un download, ce qui fait qu'on peut lancer plusieurs fois le même download.

Salut,
Pas du tout, le WriteFile ne fait qu'ecrire sur le disque (comme fwrite). Pour specifier l'offset ou tu veux écrire, il faut utiliser SetFilePointer(comme fseek).

Salut,
C'est un petit prog que j'avais posté comme ca, c'est pas vraiment utilisable en vrai pour les raisons que tu as cité. Pour que ca soit vraiment utilisable, faudrait gerer le resuming, splitter le download en plusieurs transferts, faire un traitement d'erreur plus poussé... en bref, faire un vrai download manager.

Pour gerer le resuming en http:

1) requete
On peut demander une partie du fichier en mettant le champ 'Range' dans la requete GET.
Les offsets que l'ont met dans le champ sont tous inclusifs.
Range: bytes=1000-2000 // demander de l'offset 1000 (inclus) a l'offset 2000 (inclus)
ou
Range: bytes=1000-     // demander tout le fichier a partir de l'offset 1000 (inclus)
On peut faire d'autres trucs plus compliqué avec Range, mais ca ca suffit pour faire du resuming.

2) reponse
En cas de success, le serveur réponds a une requete qui contient un 'Range' par un code 206 ('Partial Content' ou un truc du genre), et
place un champ 'Content-Range' de cette forme la:
Content-Range: bytes 3668247-7336494/11004733
qui contient de gauche a droite: l'offset de depart des données, l'offset de fin des données, et la taille du fichier.
Souvent, il met aussi un 'Content-Length', mais faut pas trop s'y fier et plutot regarder le 'Content-Range' (a mon avis).

3) support
Et aussi, le serveur indique qu'il supporte les requetes 'Range' en mettant 'Accept-Ranges: bytes' dans toutes ses réponses.

Salut,
c'est surement ca, le protocol n'a pas changé mais maintenant les connexions aux serveurs sont 'obfuscated', pour contourner les protections de certains fournisseurs d'acces à internet.
eMule peut te retourner autant voire plus de résultats, en cliquant sur le bouton More quand celui ci est activé.