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
<CIT> "...tu trouve pas sa excessif..." </CIT>

@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.
ELCouz
Messages postés
135
Date d'inscription
jeudi 22 mars 2007
Statut
Membre
Dernière intervention
25 juillet 2008

9 mai 2007 à 14:42
lol dsl , cest le seul example que javais ...
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
"j'ai reussi a faire un keygen pour..." => pas de pub pour des développements qui frizent le limite du légal... on s'est compris...

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.
ELCouz
Messages postés
135
Date d'inscription
jeudi 22 mars 2007
Statut
Membre
Dernière intervention
25 juillet 2008

9 mai 2007 à 02:39
Vrai!
[...] 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
Quoi ? URLDownloadToFile() utilise IE ?
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 ?!
ELCouz
Messages postés
135
Date d'inscription
jeudi 22 mars 2007
Statut
Membre
Dernière intervention
25 juillet 2008

8 mai 2007 à 11:21
Malheureusement UrlDownloadToFile passe par iexploder tout est mis en cache (bref moi mes updates marchais 1 fois sur 3) amoins quon efface lentré avec DeleteURLCacheEntry.Il y a autre moyen ... clicker sur le bouton vider le cache dans propriete internet d'internet explorer mais pas pratique. xD Source: http://vbnet.mvps.org/code/internet/urldownloadtofilenocache.htm (Attention Code en Visual Bullshit!! :O ) et http://msdn2.microsoft.com/en-us/library/aa383983.aspx

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
Merci ElCouz pour ton bout de code. Je ne connaissais pas la fonction DeleteURLCacheEntry().
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
Francky23012301
Messages postés
400
Date d'inscription
samedi 6 août 2005
Statut
Membre
Dernière intervention
11 février 2016
1
7 mai 2007 à 01:00
Salut Flo,

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
ELCouz
Messages postés
135
Date d'inscription
jeudi 22 mars 2007
Statut
Membre
Dernière intervention
25 juillet 2008

7 mai 2007 à 00:33
dsl comme jai ecrit cest involontaire mais bon jai ecrit a nix a propos de cela .. en passant URLdownloadToFile() i faut mettre ceci DeleteURLCacheEntry(PChar(Source)) pour eviter que le download soit ne soit pas mis en cache ,, javais ce problem avec les updates ,, i gardais tjrs une version en cache:

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;
Twinuts
Messages postés
5372
Date d'inscription
dimanche 4 mai 2003
Statut
Modérateur
Dernière intervention
24 mai 2022
111
6 mai 2007 à 11:56
Salut,

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 ..... ^^
Merci ElCouz pour tes 30 commentaires !
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 ^^
ELCouz
Messages postés
135
Date d'inscription
jeudi 22 mars 2007
Statut
Membre
Dernière intervention
25 juillet 2008

6 mai 2007 à 09:48
tres bon code cest plus simple de passer par une composante mais reste que l'api wininet existe aussi pour ceux qui ne veule pas utiliser indy ;) et/ou garder son application de petit taille.

Bravo pour le source :D

Laurent
"pourquoi ne pas avoir traitée la partie : vérification d'une nouvelle version disponible sur le serveur ?"

=> 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
Francky23012301
Messages postés
400
Date d'inscription
samedi 6 août 2005
Statut
Membre
Dernière intervention
11 février 2016
1
2 mai 2007 à 08:47
Et ben voila un source de plus ou j'ai appris de nouvelles fonctions.

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.