bridé un programme

LE TROLL

05/01/2008 à 09:50

Tu n'as pas une assurance professionnelle ???

Sinon, totalement d'accord avec toi, on doit
tendre à une indépendance maximum d'une
application !

--
Merci beaucoup, au revoir et à bientôt :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Jean-marc"
a écrit
dans le message de news:
477ebece$0$22308$
| Kiriasse wrote:
| > On ne peut pas faire autrement si l'on veut
avoir quelque chance de
| > ne pas être piraté.
|
| Il y a d'autres méthodes quand même.
|
| > Un bon FAI ne tombe que rarement en panne et,
si ça arrive, ça ne
| > dure pas très longtemps (et on peut toujours
en utiliser un autre).
|
| Ce ne sont pas des arguments raisonnables.
|
| Pour un logiciel critique (utilisé en
production) une telle protection
| est inaccpetable : tu ne peux pas prendre en
otage l'utilisateur d'un
| logiciel vital en lui disant "Sorry mon vieux,
c'est votre FAI qui déconne,
| prenez en un autre, moi c'est pas mon problème",
le laissant d'en
| l'impossibilité de bosser le jour ou il est en
rade de connexion.
|
| Si je fais ça à n'importe lequel de mes clients,
dans le meilleur de cas
| j'aurais un procès avec quelques centaines de
millions d'Euros (si si)
| à payer. Dans le pire des cas, je te laisse
imaginer ...
|
| Ce type de protection est Ok pour un logiciel en
évaluation, ou pour une
| version de Démo ou que sais-je. Mais pas dans un
Vrai Soft tournant sur
| de Vraies Machines pour de Vrais clients faisant
un Vrai travail (dans
| la Vraie vie)...
|
| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ;

|
|
|
|

Kiriasse

05/01/2008 à 09:59

Cher ami,

Vos arguments ne sont pas raisonnables.

1) Je doute qu'un « vrai soft » comme celui que vous évoquez soit écrit en
Visual Basic, mais passons.

2) La probabilité pour que votre « vrai » logiciel tournant sur une «
vraie » machine, etc., et n'exigeant pas une connexion internet tombe en
panne n'est jamais nulle non plus. Ni que l'ordinateur utilisé rende
subitement l'âme (à supposer que de telles machines aient une âme).

3) Un algorithme simple prenant en compte deux ou trois FAI différents (un
abonnement à plusieurs FAI n'est pas un problème dans le cas d'entreprises
comme celles que vous évoquez) suffit à rendre très improbable
l'impossibilité de se connecter à Internet.

<--->
If FAI_1 actif Then
Fais le boulot
Else
If FAI_2 actif Then
Fais le boulot
Else
If FAI_3 actif Then
Fais le boulot
Else
MsgBox "Connexion à Internet impossible." & vbcrlf & _
"Tous les FAI que vous avez déclarés dans la configuration du "
& _
"logiciel sont actuellement en panne !" & vbcrlf & _
"Nous vous recommandons de vous abonner à de « vrais » FAI " & _
"dignes de votre « vraie » entreprise.", 16
End If
End If
End If
<--->

Kiriasse
En réponse à

== "Jean-marc"
Kiriasse wrote:

On ne peut pas faire autrement si l'on veut avoir quelque chance de
ne pas être piraté.

Il y a d'autres méthodes quand même.

Un bon FAI ne tombe que rarement en panne et, si ça arrive, ça ne
dure pas très longtemps (et on peut toujours en utiliser un autre).

Ce ne sont pas des arguments raisonnables.

Pour un logiciel critique (utilisé en production) une telle protection
est inaccpetable : tu ne peux pas prendre en otage l'utilisateur d'un
logiciel vital en lui disant "Sorry mon vieux, c'est votre FAI qui déconne,
prenez en un autre, moi c'est pas mon problème", le laissant d'en
l'impossibilité de bosser le jour ou il est en rade de connexion.

Si je fais ça à n'importe lequel de mes clients, dans le meilleur de cas
j'aurais un procès avec quelques centaines de millions d'Euros (si si)
à payer. Dans le pire des cas, je te laisse imaginer ...

Ce type de protection est Ok pour un logiciel en évaluation, ou pour une
version de Démo ou que sais-je. Mais pas dans un Vrai Soft tournant sur
de Vraies Machines pour de Vrais clients faisant un Vrai travail (dans
la Vraie vie)...

Cher ami,

Vos arguments ne sont pas raisonnables.

1) Je doute qu'un « vrai soft » comme celui que vous évoquez soit écrit en
Visual Basic, mais passons.

2) La probabilité pour que votre « vrai » logiciel tournant sur une «
vraie » machine, etc., et n'exigeant pas une connexion internet tombe en
panne n'est jamais nulle non plus. Ni que l'ordinateur utilisé rende
subitement l'âme (à supposer que de telles machines aient une âme).

3) Un algorithme simple prenant en compte deux ou trois FAI différents (un
abonnement à plusieurs FAI n'est pas un problème dans le cas d'entreprises
comme celles que vous évoquez) suffit à rendre très improbable
l'impossibilité de se connecter à Internet.

<--->
If FAI_1 actif Then
Fais le boulot
Else
If FAI_2 actif Then
Fais le boulot
Else
If FAI_3 actif Then
Fais le boulot
Else
MsgBox "Connexion à Internet impossible." & vbcrlf & _
"Tous les FAI que vous avez déclarés dans la configuration du "
& _
"logiciel sont actuellement en panne !" & vbcrlf & _
"Nous vous recommandons de vous abonner à de « vrais » FAI " & _
"dignes de votre « vraie » entreprise.", 16
End If
End If
End If
<--->

Kiriasse
En réponse à

== "Jean-marc"
Kiriasse wrote:

On ne peut pas faire autrement si l'on veut avoir quelque chance de
ne pas être piraté.

Il y a d'autres méthodes quand même.

Un bon FAI ne tombe que rarement en panne et, si ça arrive, ça ne
dure pas très longtemps (et on peut toujours en utiliser un autre).

Ce ne sont pas des arguments raisonnables.

Pour un logiciel critique (utilisé en production) une telle protection
est inaccpetable : tu ne peux pas prendre en otage l'utilisateur d'un
logiciel vital en lui disant "Sorry mon vieux, c'est votre FAI qui déconne,
prenez en un autre, moi c'est pas mon problème", le laissant d'en
l'impossibilité de bosser le jour ou il est en rade de connexion.

Si je fais ça à n'importe lequel de mes clients, dans le meilleur de cas
j'aurais un procès avec quelques centaines de millions d'Euros (si si)
à payer. Dans le pire des cas, je te laisse imaginer ...

Ce type de protection est Ok pour un logiciel en évaluation, ou pour une
version de Démo ou que sais-je. Mais pas dans un Vrai Soft tournant sur
de Vraies Machines pour de Vrais clients faisant un Vrai travail (dans
la Vraie vie)...

Vous avez filtré cet utilisateur ! Consultez son message

Cher ami,

Vos arguments ne sont pas raisonnables.

1) Je doute qu'un « vrai soft » comme celui que vous évoquez soit écrit en
Visual Basic, mais passons.

2) La probabilité pour que votre « vrai » logiciel tournant sur une «
vraie » machine, etc., et n'exigeant pas une connexion internet tombe en
panne n'est jamais nulle non plus. Ni que l'ordinateur utilisé rende
subitement l'âme (à supposer que de telles machines aient une âme).

3) Un algorithme simple prenant en compte deux ou trois FAI différents (un
abonnement à plusieurs FAI n'est pas un problème dans le cas d'entreprises
comme celles que vous évoquez) suffit à rendre très improbable
l'impossibilité de se connecter à Internet.

<--->
If FAI_1 actif Then
Fais le boulot
Else
If FAI_2 actif Then
Fais le boulot
Else
If FAI_3 actif Then
Fais le boulot
Else
MsgBox "Connexion à Internet impossible." & vbcrlf & _
"Tous les FAI que vous avez déclarés dans la configuration du "
& _
"logiciel sont actuellement en panne !" & vbcrlf & _
"Nous vous recommandons de vous abonner à de « vrais » FAI " & _
"dignes de votre « vraie » entreprise.", 16
End If
End If
End If
<--->

Kiriasse
En réponse à

== "Jean-marc"
Kiriasse wrote:

On ne peut pas faire autrement si l'on veut avoir quelque chance de
ne pas être piraté.

Il y a d'autres méthodes quand même.

Un bon FAI ne tombe que rarement en panne et, si ça arrive, ça ne
dure pas très longtemps (et on peut toujours en utiliser un autre).

Ce ne sont pas des arguments raisonnables.

Pour un logiciel critique (utilisé en production) une telle protection
est inaccpetable : tu ne peux pas prendre en otage l'utilisateur d'un
logiciel vital en lui disant "Sorry mon vieux, c'est votre FAI qui déconne,
prenez en un autre, moi c'est pas mon problème", le laissant d'en
l'impossibilité de bosser le jour ou il est en rade de connexion.

Si je fais ça à n'importe lequel de mes clients, dans le meilleur de cas
j'aurais un procès avec quelques centaines de millions d'Euros (si si)
à payer. Dans le pire des cas, je te laisse imaginer ...

Ce type de protection est Ok pour un logiciel en évaluation, ou pour une
version de Démo ou que sais-je. Mais pas dans un Vrai Soft tournant sur
de Vraies Machines pour de Vrais clients faisant un Vrai travail (dans
la Vraie vie)...

LE TROLL

05/01/2008 à 10:17

Oui, timoré...

On peut trouver des applets, et autres.

Mais non, une application doit rester
indépendante au maximum. De toute façon, il n'y a
pas de protection infaillible !
Les clefs de cryptage à algorithmes multiples,
les gros logiciels, genre Microsoft, rien n'y
fait. Certains on réussi à entrer au Pentagone,
d'autre à craquer les OS...

Donc, ce n'est pas nous, avec nos petits, ou
moyens niveaux, qui allons faire mieux que les
équipes des meilleurs ingénieurs de ces firmes...

Moa, je dis:
D'une part: une protection doit être adaptée en
fonction de certains critères, sachant qu'elle ne
sera jamais infaillible:
- La valeur du logiciel.
- La valeurs apportée par le craquage en
publicité, par rapport à la perte de vente.
- Le temps à passer aux protections par rapport au
temps passé sur la conception du logiciel.
- Le niveau de l'utilisateur supposé.
- Ce qu'apporteront les versions futures.
- Ne pas faire des protection qui seraient
handicapantes pour l'utilisateur (genre CD à
mettre).
- Etc.

D'autre part: un logiciel doit être le plus
possible indépendant, ce qui sous entend davantage
de programmation, mais en retour, bien plus de
sécurité de fonctionnement, notamment et si
possible:
- Fichiers faits mains (pas de BDD).
- Images et son embarqués avec le programme (les
images sur des forms).
- Limitations des API, à cause des ocx et dll.
- Pas d'accès à distance inutiles (notamment: Net,
réseau).
- Graphiques dessinés au pixel sur la form.
- Calendrier et autres, développés soi même, et
intégrés au code...

Avec tout ça, généralement, c'est quasi
indestructible, ça tourne un quart de siècle...

Par contre, si comme beaucoup, tu prends les
BDD, les ocx et dll, les API, tu peux parier qu'au
premier changement de version, ça va être en rade
partiellement, si tu en doutes, vois les question
dans ce forum sur les BDD, tu verras que ça tombe
souvent en panne à cause des applications
annexes... Certes, pour les pros, c'est une
aubaine, ça leur fait du boulot, alors il y vont
franchement dans la future panne... Mais pour les
indépendants, trop de pannes, ben ça fait perdre
des clients...

A méditer, un programme fait en 1979 en CPM,
ou en 1982 sous Dos, par exemple, tourne toujours
maintenant, 30 ans après... Certes, l'interface
n'est pas terrible à cause du changement de type
d'OS (Windows), mais si le programme MsDos avait
un bon graphique, ben ça marche encore totalement
aujourd'hui... Ce qui ne serait pas le cas, si
c'était truffé de BDD, d'API, de dll et d'ocx
(enfin, pour ce qui existait)...

------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Kiriasse"
<http://www.kiriasse.fr/mailtokir/mailtokir.html>
a écrit dans le message de news:
477ea9c5$0$858$
| Il suffit de faire une recherche dans Google
pour trouver des exemples de
| programmes PHP tout faits ou qu'il suffit de
modifier un peu (ce qui est
| possible sans même avoir de connaissances très
avancées en langage PHP).
| VB permet de réaliser des applications
intéressantes mais si vous ne
| programmez qu'en VB, vos programmes seront
toujours un peu boîteux. Pour ma
| part, je fais appel à d'autres langages BASIC
sous Windows assez simples à
| maîtriser (Pure Basic, RapidQ) qui ont l'intérêt
de ne pas avoir besoin de
| runtime. Et, pour un programme qui fonctionne
sous connexion internet, le
| PHP (ou autre langage fonctionnant sur le
serveur) est incontournable.
| Ne soyez pas timoré.
| Kiriasse
| Répondant à
|
| == | "LE TROLL"
| On est pésumé en VB, savoir programmer en PHP,
ou
| Java, ou autre, ah bon...
|

Oui, timoré...

On peut trouver des applets, et autres.

Mais non, une application doit rester
indépendante au maximum. De toute façon, il n'y a
pas de protection infaillible !
Les clefs de cryptage à algorithmes multiples,
les gros logiciels, genre Microsoft, rien n'y
fait. Certains on réussi à entrer au Pentagone,
d'autre à craquer les OS...

Donc, ce n'est pas nous, avec nos petits, ou
moyens niveaux, qui allons faire mieux que les
équipes des meilleurs ingénieurs de ces firmes...

Moa, je dis:
D'une part: une protection doit être adaptée en
fonction de certains critères, sachant qu'elle ne
sera jamais infaillible:
- La valeur du logiciel.
- La valeurs apportée par le craquage en
publicité, par rapport à la perte de vente.
- Le temps à passer aux protections par rapport au
temps passé sur la conception du logiciel.
- Le niveau de l'utilisateur supposé.
- Ce qu'apporteront les versions futures.
- Ne pas faire des protection qui seraient
handicapantes pour l'utilisateur (genre CD à
mettre).
- Etc.

D'autre part: un logiciel doit être le plus
possible indépendant, ce qui sous entend davantage
de programmation, mais en retour, bien plus de
sécurité de fonctionnement, notamment et si
possible:
- Fichiers faits mains (pas de BDD).
- Images et son embarqués avec le programme (les
images sur des forms).
- Limitations des API, à cause des ocx et dll.
- Pas d'accès à distance inutiles (notamment: Net,
réseau).
- Graphiques dessinés au pixel sur la form.
- Calendrier et autres, développés soi même, et
intégrés au code...

Avec tout ça, généralement, c'est quasi
indestructible, ça tourne un quart de siècle...

Par contre, si comme beaucoup, tu prends les
BDD, les ocx et dll, les API, tu peux parier qu'au
premier changement de version, ça va être en rade
partiellement, si tu en doutes, vois les question
dans ce forum sur les BDD, tu verras que ça tombe
souvent en panne à cause des applications
annexes... Certes, pour les pros, c'est une
aubaine, ça leur fait du boulot, alors il y vont
franchement dans la future panne... Mais pour les
indépendants, trop de pannes, ben ça fait perdre
des clients...

A méditer, un programme fait en 1979 en CPM,
ou en 1982 sous Dos, par exemple, tourne toujours
maintenant, 30 ans après... Certes, l'interface
n'est pas terrible à cause du changement de type
d'OS (Windows), mais si le programme MsDos avait
un bon graphique, ben ça marche encore totalement
aujourd'hui... Ce qui ne serait pas le cas, si
c'était truffé de BDD, d'API, de dll et d'ocx
(enfin, pour ce qui existait)...

------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Kiriasse"
<http://www.kiriasse.fr/mailtokir/mailtokir.html>
a écrit dans le message de news:
477ea9c5$0$858$ba4acef3@news.orange.fr...
| Il suffit de faire une recherche dans Google
pour trouver des exemples de
| programmes PHP tout faits ou qu'il suffit de
modifier un peu (ce qui est
| possible sans même avoir de connaissances très
avancées en langage PHP).
| VB permet de réaliser des applications
intéressantes mais si vous ne
| programmez qu'en VB, vos programmes seront
toujours un peu boîteux. Pour ma
| part, je fais appel à d'autres langages BASIC
sous Windows assez simples à
| maîtriser (Pure Basic, RapidQ) qui ont l'intérêt
de ne pas avoir besoin de
| runtime. Et, pour un programme qui fonctionne
sous connexion internet, le
| PHP (ou autre langage fonctionnant sur le
serveur) est incontournable.
| Ne soyez pas timoré.
| Kiriasse
| Répondant à
|
| == | "LE TROLL"
| On est pésumé en VB, savoir programmer en PHP,
ou
| Java, ou autre, ah bon...
|

Vous avez filtré cet utilisateur ! Consultez son message

Oui, timoré...

On peut trouver des applets, et autres.

Mais non, une application doit rester
indépendante au maximum. De toute façon, il n'y a
pas de protection infaillible !
Les clefs de cryptage à algorithmes multiples,
les gros logiciels, genre Microsoft, rien n'y
fait. Certains on réussi à entrer au Pentagone,
d'autre à craquer les OS...

Donc, ce n'est pas nous, avec nos petits, ou
moyens niveaux, qui allons faire mieux que les
équipes des meilleurs ingénieurs de ces firmes...

Moa, je dis:
D'une part: une protection doit être adaptée en
fonction de certains critères, sachant qu'elle ne
sera jamais infaillible:
- La valeur du logiciel.
- La valeurs apportée par le craquage en
publicité, par rapport à la perte de vente.
- Le temps à passer aux protections par rapport au
temps passé sur la conception du logiciel.
- Le niveau de l'utilisateur supposé.
- Ce qu'apporteront les versions futures.
- Ne pas faire des protection qui seraient
handicapantes pour l'utilisateur (genre CD à
mettre).
- Etc.

D'autre part: un logiciel doit être le plus
possible indépendant, ce qui sous entend davantage
de programmation, mais en retour, bien plus de
sécurité de fonctionnement, notamment et si
possible:
- Fichiers faits mains (pas de BDD).
- Images et son embarqués avec le programme (les
images sur des forms).
- Limitations des API, à cause des ocx et dll.
- Pas d'accès à distance inutiles (notamment: Net,
réseau).
- Graphiques dessinés au pixel sur la form.
- Calendrier et autres, développés soi même, et
intégrés au code...

Avec tout ça, généralement, c'est quasi
indestructible, ça tourne un quart de siècle...

Par contre, si comme beaucoup, tu prends les
BDD, les ocx et dll, les API, tu peux parier qu'au
premier changement de version, ça va être en rade
partiellement, si tu en doutes, vois les question
dans ce forum sur les BDD, tu verras que ça tombe
souvent en panne à cause des applications
annexes... Certes, pour les pros, c'est une
aubaine, ça leur fait du boulot, alors il y vont
franchement dans la future panne... Mais pour les
indépendants, trop de pannes, ben ça fait perdre
des clients...

A méditer, un programme fait en 1979 en CPM,
ou en 1982 sous Dos, par exemple, tourne toujours
maintenant, 30 ans après... Certes, l'interface
n'est pas terrible à cause du changement de type
d'OS (Windows), mais si le programme MsDos avait
un bon graphique, ben ça marche encore totalement
aujourd'hui... Ce qui ne serait pas le cas, si
c'était truffé de BDD, d'API, de dll et d'ocx
(enfin, pour ce qui existait)...

------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Kiriasse"
<http://www.kiriasse.fr/mailtokir/mailtokir.html>
a écrit dans le message de news:
477ea9c5$0$858$
| Il suffit de faire une recherche dans Google
pour trouver des exemples de
| programmes PHP tout faits ou qu'il suffit de
modifier un peu (ce qui est
| possible sans même avoir de connaissances très
avancées en langage PHP).
| VB permet de réaliser des applications
intéressantes mais si vous ne
| programmez qu'en VB, vos programmes seront
toujours un peu boîteux. Pour ma
| part, je fais appel à d'autres langages BASIC
sous Windows assez simples à
| maîtriser (Pure Basic, RapidQ) qui ont l'intérêt
de ne pas avoir besoin de
| runtime. Et, pour un programme qui fonctionne
sous connexion internet, le
| PHP (ou autre langage fonctionnant sur le
serveur) est incontournable.
| Ne soyez pas timoré.
| Kiriasse
| Répondant à
|
| == | "LE TROLL"
| On est pésumé en VB, savoir programmer en PHP,
ou
| Java, ou autre, ah bon...
|

John-Pet

05/01/2008 à 13:15

Merci à vous trois pour vos réponses

je vais regarder ce qui me convient le mieux, mais aussi le plus simple
à faire.

JP

--
Adresse mail :
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

bridé un programme

4 réponses

Veuillez sélectionner un problème