Discussion :

[colorid]

Bonjour,

Quelqu'un sait-il comment développer un logiciel d'essai ne fonctionnant que pendant trente jours par exemple...

Merci à tous

[madlozoz]

personne ne le sais ;-) La date de l'ordinateur peut etre modifier et à moins d'exiger une conection sur ton serveur internet, toute tes protection de ce type peuvent etre détournée.

Sinon, la solution simple, c'est:
- Inclure un fichier de parametre (par exemple XML) avec le parametre "date instalation" et l'initialiser à "vide"
- au lancement, si la date est "vide", la remplacer par la date courante (fonction "now" de delphi)
-si elle n'est pas vide est que (date installation +30 > now ), tu met un message d'erreur


Pour eviter de réinventer la roue :
Perso, j'utilise Install Creator Pro de l'éditeur Clickteam. Il ne permet pas ça, mais il inclu un systeme de clé pour installer sois la version d'eval soit la version complete. Je n'ai pas testé cette fonction, mais le programme est globalement très bon et simple (et les devs sont francais et répondent sur le forum)
Il est payant(logique faut tester cette fonctionnalité en vrai) , mais la version d'eval est tres permissive.

[Droïde Système7]

ben, chacun a ses propres méthodes et algos... dans la BdR, dans un fichier texte ou image, dans plusieurs en même temps pour comparaison...

Ensuite comparaison entre le premier lancement de ton programme et le jour courant.

Si date passée ; alors tu bloques le lancement selon tes souhaits, ou bien lance une boite disant que la fin d'essai est arrivé à échéance.

Faut jouer de ruse pour cacher intelligemment les paramètres en question.

@+

[madlozoz]

Faut jouer de ruse pour cacher intelligemment les paramètres en question.

Ouaip!
Le corolaire étant que plus tu la joue subtil, plus tu risque pourrir la vie des utilisateur honetes (genre que tu a oublier de tester le cas d'un utilisateur avec les droits minimums ou que tu tente de planquer les info dans un endroit n'existant pas sous Windows 98).

Perso, pour mon programme à moi, j'ai préféré retirer des fonctions. C'est moins dépendant du système et donc moins à même d'être bloquer/débloqué. Reste à voir si c'est pertinent dans ton cas.

[Gilbert Geyer]

Bonjour,

Quelqu'un sait-il comment développer un logiciel d'essai ne fonctionnant que pendant trente jours par exemple...

Ben comme il est rare qu'un utilisateur dérègle la pendule de Windows le moins compliqué est de faire un DeleteFile(const FileName: string) du fichier *.exe situé dans le répertoire RepAppli:=ExtractFilePath(Application.ExeName); au bout des 30 jours. La date de la première utilisation pouvant être cachée par exemple dans un mini-fichier auto-généré lors de cette première et dont l'extension n'incite pas de curiosité à l'utilisateur lambda comme par exemple .dll

Mais il peut également être intéressant au bout des 30 jours, au lieu de déclencher cette auto-destruction, de faire apparaître toutes les minutes ou toutes les 30 secondes une fenêtre de harcèlement rappelant que la période d'essai et de gratuité est dépassée : et de deux choses l'une ou-bien l'utilisateur agacé met le logiciel à la poubelle, ou-bien il achète le logiciel s'il lui rend un réel service.

A+

[Kaféine]

Salut,

OnGuard de Turbopower permet de faire des versions d'évaluations (limite n jours, réseaux...). C'est facile à prendre en main et la doc est plutôt bien faite.

http://sourceforge.net/projects/tponguard/

[sat83]

Hello!

Comme expliqué dans les réponses précédentes, aucune solutions n'est efficace à 100%...

Voici une solution que j'avais mis en place il y a quelques année :

- Je sauvegarde 3 dates : première utilisation, date de fin et dernière utilisation
- J'enregistre ces informations à la fois dans le registre, et à la fois dans un fichier crypté
- Donc à chaque lancement de l'application je met a jour les infos.

=> Si une infos du registre est différentes des infos dans le fichier l'utilisateur a modifier le registre => LA LICENCE EXPIRE
=> Si la date du système est supérieur à la date de fin => LA LICENCE EXPIRE
=> Si la date du système est inférieur à la date de début ou à la date de dernière utilisation (l'utilisateur a modifier la date du système) => LA LICENCE EXPIRE

Bien sûr il y a des parades contre ce système (comme contre tout système de protection), mais dans mon cas c'était tout à fais satisfaisant.

[colorid]

L'incription des dates dans le registre avec un double dans un fichier caché (une image par exemple) me parait intéressante.

Quelqu'un peut m'expliquer comment inscrire trois dates dans le registre et comment les lire ?

Un code source serait le bienvenu...

[Just-Soft]

L'incription des dates dans le registre avec un double dans un fichier caché (une image par exemple) me parait intéressante.

Quelqu'un peut m'expliquer comment inscrire trois dates dans le registre et comment les lire ?

Un code source serait le bienvenu...

tout y est là : http://delphi.developpez.com/faq/?page=basederegistre

Bonne chance.

[Franck SORIANO]

Ouaip!
Le corolaire étant que plus tu la joue subtil, plus tu risque pourrir la vie des utilisateur honetes

Oui, ou encore, plus tu la joue subtil, et plus tu vas attirer l'attention d'un pirate :
Le pirate va lancer un processmon (ou filemon et regmon), lancer ton appli et regarder tous les fichiers et clés de la base de registre auxquels elle accède.

Si tu vois qu'elle va chercher des trucs dans des endroits où elle n'a rien à faire (encore plus si elle y écrit) -> C'est probablement qu'elle essaie de planquer des trucs...
Et comme ça tu repères en 30s les fichiers de paramètres (ou clé de registre) qui mémorisent la date d'installation de l'appli !

Il est très difficile de se protéger efficacement contre ça.

On peut cependant envisager différentes solutions :
- La clé d'évaluation : Lorsque l'appli est installée, elle réclame une clé d'évaluation pour fonctionner. Tu mets en place une procédure d'enregistrement quelque part et l'utilisateur doit s'enregistrer pour démarrer son évaluation. Dans la clé d'éval que tu lui envoie, tu cryptes la date de fin de validité de l'appli ! Ca oblige en plus l'utilisateur à s'inscrire, et ça te permet de suivre les évaluations.
L'inconvénient, c'est que pour une appli grand publique, beaucoup refuse de s'enregistrer.
- Autre possibilité, si c'est possible : Ne pas utiliser de fichier de paramètres pour mémoriser la date d'installation, mais se baser directement sur les données de l'appli. Par exemple, si tu fais un logiciel de facturation, tu peux tester les dates des factures ! Le client est forcé de garder ses factures avec les bonnes dates de facturation. Donc il te suffit de tester la date de la facture la plus ancienne...

Une autre variante à peine différente, au lieu de tester une durée d'utilisation, tu limites la volumétrie des données gérées (pas plus de n clients, pas plus de n factures...). Bon le problème dans ce cas, c'est que le prospect ne pourra pas vérifier les perfs de ton appli sur sa volumétrie...

[Droïde Système7]

Ou encore une idée : pourquoi ne pas distribuer (librement) une appli absolument identique à la version commerciale.

Sauf que... la version librement distribuable sera codée pour se détruire ou s'auto-limiter en fonctions, avec message de rappel à l'ordre = période d'essai dépassée ?

Hé oui un peu plus lourd puisque deux versions pour une seule appli, mais au final, pas le plus simple et léger ?

Car ne pas oublier que sur 100 logiciels téléchargés = pour x raisons ; seulement UN sera acheté.

Cette dernière analyse, n'est pas de moi, mais d'un développeur qui distribue un freeware, justement à ces fins de gestions. L'autre fois j'avais vu et lu avec ça avec intérêt, sur l'un des forums DVP d'ici.

A méditer...