Discussion :

[sidahmed]

Bonjour,

je veux livrer une application Delphi en version d'évaluation et mono-utilisation, comment je dois faire ça ? Je pense à un TTimer pour calculer le nombre de secondes écoulées mais je ne sais pas si ça marche ? Je ne cherche pas une méthode efficace à 100 %, juste une solution faisable !

Merci d'avance.

Cordialement,
Sidahmed.

[ShaiLeTroll]

Dans le Timer, disons tu le mets à 1000 en interval, tu as une variable globale initialisé à zéro, que tu incrémente, et passer une valeur, tu arrête le programme, voir tu le supprime ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure TMainForm.TimerSecondTimer(Sender: TObject);
begin
  Inc(gSecondStart);
  LabelDecompte := Format('Il vous reste %d secondes d''utilisation', [MAX_SECONDE_USE - gSecondStart]);
  if gSecondStart >= MAX_SECONDE_USE then
     AutoTerminateAndDelete();
end;

Pour le code "AutoTerminateAndDelete", inspire toi de ce sujet ou de Phidels

Ensuite, tu peux toujours écrire en base de registre pour éviter que l'on lance une éventuelle copie ... voire carrément, via un WebService demandé une autorisation à un site internet, ... mais faut vraiement que ton programme soit bon pour déployer de tel sécurité ... quoi qu'il arrive, un petit comprendra l'Assembleur du programme et remplacera ton code par une série de jmp ... car la méthode 100% garanti, celui qui là trouve, il sera riche ... j'ai appliqué cette méthode à l'un de mes programmes, qui le 01/01/2006 et après, dès qu'il est lancé, il s'auto supprime, ne servant à rien après cette date

[droggo]

Hui,

Le mieux est de faire une version spéciale, ne contenant pas tout le code nécessaire à une véritable utilisation du programme.

Par exemple, ne pas pouvoir sauver les données, ou ne pas pouvoir imprimer, ou bien d'autres suppressions si génantes qu'on ne peut pas envisager d'utiliser efficacement le programme.

Car toute protection peut être craquée, il suffit d'y mettre le temps. Et si ton programme en vaut la peine, il y aura quelqu'un pour s'y mettre, alors qu'avec une version incomplète, ne contenant pas certaines parties du code, c'est impossible.

[Coussati]

je dois faire aussi une version limité de mon prog

j'avais pensé à limité à 20 utilisations

écire dans la bdr ou dans un fichier (system32)

qu'en pensez vous ?

[anapurna]

salut


comme cela ta été dit il est plus sûr de désactiver certaine fonctionnalité.
pour ce faire utilise les directive de compilation il n'y a rien de plus facile.

pour le nombre d'utilisation j'utiliserai plutôt un fichier
.dat
par exemple tu en vérifie l'existence lors de l'exécution .
lors de la première utilisation tu modifie un champs date et
un champs clé
et ensuite a partir de ce nombre clé tu incrémente un autre champs
ce qui te permet de vérifié la cohérence de version et le nombre d'utilisation ou de jour

sachant que les données dans le fichier peuvent être crypté

@+ Phil

[CapJack]

Je m'associe à tous ceux qui pensent que la méthode la plus efficace est de livrer une version "bridée", ne contenant qu'un partie du code (ce qui empêche définitivement de pouvoir réactiver les fonctionnalités masquées en modifiant quelques octets...)

Je te propose ma méthode pour le faire sans se casser la tête : une fois ton appli finalisée, le projet étant défini par un fichier .dpr et un fichier .bdsproj (suivant versions), fais "Sauvegarder le projet sous...", et sélectionne un autre nom, par exemple, en ajoutant "_demo" au nom de fichier du projet.

Ensuite, dans ce "nouveau" projet (en fait c'est le même, mais avec un autre nom) ajoute la directive de compilation globale DEMO par exemple (sous D2005, c'est dans "Projet/Options -> Répertoires conditions -> Déf. conditionnelles"). Les directives de compilations ainsi définies sont accessibles dans toutes les unités du projet.

Il ne reste plus qu'à modifier les unités "critiques" du projet, en désactivant les fonctionnalités à ne pas intégrer, comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
{$IFNDEF DEMO}
 
// Procédures à désactiver dans la démo
 
{$ENDIF}

Bien sûr, on peut en mettre à plusieurs endroits.

Cette façon de procéder permet d'utiliser les mêmes unités pour l'appli complète et l'appli de démo, ce qui simplifie l'évolution. Et ça simplifie aussi la compilation, puisqu'on n'a qu'à charger le projet démo, et le compiler, l'exécutable de la démo sera automatiquement créé avec le nom choisi, et le code manquant, sans qu'on ait rien d'autre à faire. C'est du travail au début, mais après on n'a plus à y penser.

Par la suite, il faudra juste penser à rafraîchir le fichier projet de la démo (enregistrer projet sous, sans oublier de mettre la directive de compilation), chaque fois qu'une modification de l'appli aura engendré une modification des fichiers du projet. Par sécurité, on peut refaire cette manip-là à chaque publication d'une nouvelle version. Par contre, l'ajout des directives {$IFNDEF ...} dans les fichiers .pas n'aura plus à être refait sauf si on ajoute par la suite une nouvelle fonctionnalité à désactiver dans la démo.

J'utilise la même méthode aussi pour construire plusieurs applications semblables bâties sur le même squelette de base.