RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN
Francky23012301
Messages postés
400
Date d'inscription
samedi 6 août 2005
Statut
Membre
Dernière intervention
11 février 2016
-
2 mai 2007 à 08:47
Albedo039 Messages postés 18 Date d'inscription mercredi 8 novembre 2006 Statut Membre Dernière intervention 31 janvier 2008 - 23 juin 2007 à 18:03
Albedo039 Messages postés 18 Date d'inscription mercredi 8 novembre 2006 Statut Membre Dernière intervention 31 janvier 2008 - 23 juin 2007 à 18:03
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/42534-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien
https://codes-sources.commentcamarche.net/source/42534-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien-rien
23 juin 2007 à 18:03
@ELCouz:
IMHO, "noui!" (en Français dans le texte ;-)
En fait, au début de Pascal (j'suis 1 vieux, j'ai commencé avec Pascal 3.0, sans l'Turbo :o) un gros compilat faisait jusqu'à 0,25%-1% du disque dur (quand on en avait un...) ou 30-50% de la disquette.
Aujoud'hui: un prog de 1,5 MBytes sur un disque dur de 250 GBytes, c'est juste 0,000006% :)))
Plus important (!), il y a une SOLUTION à ton problème:
si tu compiles tes progs en utilisant les biblios (BPLs) linkées "extérieures", alors:
--> la taille des exécutables reste très modérée (~50 KBytes ?).
--> tu distribues les BPLs une seule fois.
--> pour les mises à jour, il n'y a presque plus rien à télécharger.
--> tu économises en principe de la bande passante et de la place sur ton disque.
--> tu compiles plus vite.
--> tu économises de la mémoire: les DLLs/BPLs sont "partagées" par tous les progs et ne sont pas chargées plusieurs fois ... si tu utilises un répertoire commun au différents progs (celui de Windows par ex.) pour les sauvegarder/gérer...
--> ... et quand ton prog se plante, il y a en moyenne des fuites de mémoire moins importantes.
Par contre, il vaut mieux tester à fond les progs sur un system "sans Delphi" avant de distribuer les EXE. On a vite fait d'oublier une BPL... :)
Au minimum, tu peux analyser l'EXE avec un prog correspondant (PEBuilder et similaires...) pour t'assurer de toutes les biblios requises.
9 mai 2007 à 14:42
ta raison sur la taille mais par example quand ta plusieur projets metton une 20aine different a distribuer qui sont pratique 400K pour un pop-up killer , 350k pour un prog ki ouvre un fichier texte , 100k pour une console application avec 10 lignes ,etc... tu trouve pas sa excessif ?
Laurent
9 mai 2007 à 13:14
Pour KOL et MCK, en fait, je préfère quand même utiliser la VCL de Delphi. De nos jours, on n'est pas à 500Ko près. Et de plus, même si ça peut paraitre "gros" pour une application qui ne fait rien, tu verras que la taille n'augmente pas énormément plus tu rajoutes de code.
Et puis... ce qui est fait... est fait! Autant en profiter. La VCL est tout de même assez complète.
9 mai 2007 à 02:39
[...] moi je ne peu pas le telecharger par contre pcq mon delphi 2006 lite est configurer pour ne marcher qu'avec KOL & MCK .. jai pas access a rien de VCL delphi ... jaime sa programmer et avoir comme resultat un programme complet pour 30K :)
La preuve jai reussi a faire un keygen pour VMWare 65.2K (la bmp de fond fait 130K, 16K de music XM + 5K pour uFMOD pas de dll rien) cest puissant!
pour ceux qui non pas KOL & MCK jai compiler une version ici : http://www.elcouz.net/delphifr/LiTEKGeN - VMware v5.rar
je posterai la source si qqn est interesser a travailler avec KOL-MCK...
PS: oui je sais mon calcul de la spiral logarithmique nest pas parfait ,, mais c dure mathematiquement loll !
Bonne journee
ELCouz
8 mai 2007 à 12:49
Alors poubelle !!!!!
Je préfère encore me trimballer un .exe trois fois plus gros qu'utiliser les fonction de cette usine à gaz !
Je verrai si je peux utiliser seulement WinInet ... mais c'est pas dit.
Oh ! Puis ceux qui ont pas Indy n'ont qu'a le télécharger, non ?!
8 mai 2007 à 11:21
OU faire toute la fonction avec WinInet ... donc plus besoin dajouter DeleteURLCacheEntry ... suffit de mettre le flag INTERNET_FLAG_NO_CACHE_WRITE .
Source: http://msdn2.microsoft.com/en-us/library/aa383661.aspx
Je ne te demande pas de le refaire! ton code est tres bien ... Jte donne des conseils cest tout ;)
A-Pluche!
Laurent
7 mai 2007 à 09:18
Je vais cependant devoir l'adapter car j'ai besoin d'utiliser la fonction de callback pour pouvoir signaler l'avancement ainsi que la possibilité d'annuler.
(toujours dans le concept de "l'utilisateur est roi").
@36-15 :
Oui enfin bon, utiliser le port HTTP ne signifie pas que la transaction n'est pas sécurisée. Pour un simple cas de mise à jour, on peut faire un checksum pour vérifier l'intégrité des fichiers.
Pour allez plus loin et éviter les "fausses updates", on peut aussi choisir de crypter la liste des fichiers à mettre à jour mais après, on s'en sort plus...
"Tu as été au plus court": en effet, c'était le but ! Par contre, il y a un truc qui est plus dur à faire: mettre à jour le module de mise à jour ....
++ et merci
7 mai 2007 à 01:00
Effectivement ce que je sous entendais pas là c'était d'utiliser la dll WinSock et ne pas utiliser un protocole prédifinis mais un port libre afin de créer son propre protocole afin d'assurer une plus grande sécurité et configurations.
Tu as été au plus court mais le code est vraiment de qualité.
Bon coding
7 mai 2007 à 00:33
petit exemple ...
uses urlmon,wininet;
function DownloadFile(Source, Dest: string): Boolean;
begin
try
DeleteURLCacheEntry(PChar(Source));
Result :UrlDownloadToFile(nil, PChar(Source), PChar(Dest), 0, nil) 0;
except
Result := False;
end;
end;
6 mai 2007 à 11:56
ELCouz > merci ne pas insister comme tu l'as fais pour poster sur les sources et sur le forum, parce que tu as passé 10 minutes pour poster et moi 10 minutes pour faire le ménage ..... ^^
6 mai 2007 à 11:54
Oui, y'a moyen de faire sans Indy mais j'avais pas envie de m'embetter avec autre chose.
Je vais voir si on peu facilement faire la même chose avec l'API URLdownloadToFile().
Bon, quand un admin passera par ici, il aura du boulot ^^
6 mai 2007 à 09:48
Bravo pour le source :D
Laurent
2 mai 2007 à 22:16
=> La raison est simple: car chaque programme a une structure différente et que la fonction de détection des mises à jour dépend aussi des possibilités du serveur web qui les héberge.
Si tu as du php, tu peux faire un script qui, à partir de la version de l'exécutable donne la liste des fichiers à mettre à jour (archi simple à faire, j'ai testé en local)
Par contre, si tu n'as pas php sur le serveur, ben il faut créer un fichier statique qui recense les versions, ou bien choisir de mettre à jour tous les fichiers à chaque fois ...
"J'aurais pas traité le sujet sous cet angle"
=> Tiens, ça m'intéresse. Tu peux développez stp ?
Merci pour ton intérêt pour cette source
++
Flo
2 mai 2007 à 08:47
J'aurais pas traité le sujet sous cet angle mais ta stratégie est vraiment excellente.
Par contre pourquoi ne pas avoir traitée la partie : vérification d'une nouvelle version disponible sur le serveur ? Bref ca n'enlève rien à la qualité de ce source.
Ps : C'est vrai que hormis celui de Matt, il n'y avait pas d'autres sources tenant la route. Tu as eu une bonne idée surtout que la question a été posée plusieurs fois ces derniers temps.