"Remi THOMAS" wrote in message news:43fda69c$0$27146$
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code (CreateWindow...) et non pas un fichier .RES?
Merci d'avance, Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en contradiction avec votre approche. -- Paul Bacelar
"Remi THOMAS" <remi@xtware.com> wrote in message
news:43fda69c$0$27146$626a54ce@news.free.fr...
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code
(CreateWindow...) et non pas un fichier .RES?
Merci d'avance,
Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est
pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la
génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour
générer des interfaces. Pourquoi polluer votre code avec du code auto généré
?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en
contradiction avec votre approche.
--
Paul Bacelar
"Remi THOMAS" wrote in message news:43fda69c$0$27146$
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code (CreateWindow...) et non pas un fichier .RES?
Merci d'avance, Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en contradiction avec votre approche. -- Paul Bacelar
Paul Bacelar
"Remi THOMAS" wrote in message news:43fda69c$0$27146$
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code (CreateWindow...) et non pas un fichier .RES?
Merci d'avance, Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en contradiction avec votre approche. -- Paul Bacelar
"Remi THOMAS" <remi@xtware.com> wrote in message
news:43fda69c$0$27146$626a54ce@news.free.fr...
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code
(CreateWindow...) et non pas un fichier .RES?
Merci d'avance,
Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est
pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la
génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour
générer des interfaces. Pourquoi polluer votre code avec du code auto généré
?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en
contradiction avec votre approche.
--
Paul Bacelar
"Remi THOMAS" wrote in message news:43fda69c$0$27146$
Bonjour,
Auriez-vous croisé un éditeur de ressources win32 qui génére du code (CreateWindow...) et non pas un fichier .RES?
Merci d'avance, Rémi
Les ressources sont figées dans un segment du fichier exécutable et n'est pas du code.
Quel est votre problème initial que vous voulez résoudre avec de la génération automatique de code ?
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
L'autre est de pouvoir modifier les IHM sans recompilation, donc en contradiction avec votre approche. -- Paul Bacelar
Arnold McDonald \(AMcD\)
Paul Bacelar wrote:
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce qui pollue et c'est très simple à faire. Bien plus clair que le code d'un .rc en tout cas ! On y gagne un meilleur contrôle et, surtout, as-tu déjà entendu parler d'espionnage industriel ?
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Paul Bacelar wrote:
L'une des raisons d'être des ressources est la simplification du code
pour générer des interfaces. Pourquoi polluer votre code avec du code
auto généré ?
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce
qui pollue et c'est très simple à faire. Bien plus clair que le code d'un
.rc en tout cas ! On y gagne un meilleur contrôle et, surtout, as-tu déjà
entendu parler d'espionnage industriel ?
L'une des raisons d'être des ressources est la simplification du code pour générer des interfaces. Pourquoi polluer votre code avec du code auto généré ?
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce qui pollue et c'est très simple à faire. Bien plus clair que le code d'un .rc en tout cas ! On y gagne un meilleur contrôle et, surtout, as-tu déjà entendu parler d'espionnage industriel ?
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter
Arnold McDonald (AMcD) wrote:
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce qui pollue et c'est très simple à faire. Bien plus clair que le code d'un .rc en tout cas !
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça se saurait, tout de même. Menus à part, le seul intérêt que je vois à générer et gérer du code pur et dur à la place de ressources, c'est quand la fenêtre est du genre élastique ou dynamique. Autrement, je vois pas trop.
J'ai une grande tendresse pour le code, mais quand même pas à ce point. Là, ça frise la monomanie.
On y gagne un meilleur contrôle et, surtout, as-tu déjà entendu parler d'espionnage industriel ?
Bah, celui qui veut espionner trouvera de toute façon une solution. Quelle que soit l'origine de ce qui est affiché, il pourra toujours capturer et recopier.
Arnold McDonald (AMcD) wrote:
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce
qui pollue et c'est très simple à faire. Bien plus clair que le code d'un
.rc en tout cas !
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça
se saurait, tout de même. Menus à part, le seul intérêt que je vois à
générer et gérer du code pur et dur à la place de ressources, c'est
quand la fenêtre est du genre élastique ou dynamique. Autrement, je vois
pas trop.
J'ai une grande tendresse pour le code, mais quand même pas à ce point.
Là, ça frise la monomanie.
On y gagne un meilleur contrôle et, surtout, as-tu déjà
entendu parler d'espionnage industriel ?
Bah, celui qui veut espionner trouvera de toute façon une solution.
Quelle que soit l'origine de ce qui est affiché, il pourra toujours
capturer et recopier.
99.9 % des "ressources" de mes codes sont "auto-générées". Je ne vois pas ce qui pollue et c'est très simple à faire. Bien plus clair que le code d'un .rc en tout cas !
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça se saurait, tout de même. Menus à part, le seul intérêt que je vois à générer et gérer du code pur et dur à la place de ressources, c'est quand la fenêtre est du genre élastique ou dynamique. Autrement, je vois pas trop.
J'ai une grande tendresse pour le code, mais quand même pas à ce point. Là, ça frise la monomanie.
On y gagne un meilleur contrôle et, surtout, as-tu déjà entendu parler d'espionnage industriel ?
Bah, celui qui veut espionner trouvera de toute façon une solution. Quelle que soit l'origine de ce qui est affiché, il pourra toujours capturer et recopier.
Arnold McDonald \(AMcD\)
Bertrand Lenoir-Welter wrote:
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça se saurait, tout de même.
Je n'ai jamais dit que c'était un boulet. C'est très pratique ! Seulement c'est plein de défauts et surtout, tu ne peut pas TOUT faire avec.
Menus à part,
Lol, ben oui, les menus, c'est souvent très intéressant de les auto-générer :-)
Bah, celui qui veut espionner trouvera de toute façon une solution. Quelle que soit l'origine de ce qui est affiché, il pourra toujours capturer et recopier.
Tu peux tout de même sérieusement compliquer son travail ! Imagine que tes chaîne de caractères de l'application sont dans un.rc. Ben n'importe qui peut les extraire, modifier, remplacer, etc. Pareil pour les autres ressources, menus, icônes, bitmaps, etc. Même si tu chiffres ces ressources (bon courage !), il suffit de tracer par exemple un appel à LoadString() et de voir ce que le code fait avec ensuite. Facilement détournable donc.
Si tes chaînes sont dans l'appli, là, c'est bien plus difficile à détourner. Des défauts ? Niveau place mémoire, ça prend pas plus que si tu les mets en ressource. Gestion du multi-langue ? Ben tu les mets dans une DLL et tu reproduis la même chose que si c'est dans le code principal. Difficulté de patching ? Ben c'est justement le but recherché ! Si tes tables de chaînes sont dans l'appli, leur chiffrement/déchiffrement est bien plus complexe à détourner, tu peux me croire.
Les .rc, c'est excellent et très bien. Mais si tu veux protéger tes ressources, c'est quasiment impossible avec :-(.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter wrote:
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça
se saurait, tout de même.
Je n'ai jamais dit que c'était un boulet. C'est très pratique ! Seulement
c'est plein de défauts et surtout, tu ne peut pas TOUT faire avec.
Menus à part,
Lol, ben oui, les menus, c'est souvent très intéressant de les auto-générer
:-)
Bah, celui qui veut espionner trouvera de toute façon une solution.
Quelle que soit l'origine de ce qui est affiché, il pourra toujours
capturer et recopier.
Tu peux tout de même sérieusement compliquer son travail ! Imagine que tes
chaîne de caractères de l'application sont dans un.rc. Ben n'importe qui
peut les extraire, modifier, remplacer, etc. Pareil pour les autres
ressources, menus, icônes, bitmaps, etc. Même si tu chiffres ces ressources
(bon courage !), il suffit de tracer par exemple un appel à LoadString() et
de voir ce que le code fait avec ensuite. Facilement détournable donc.
Si tes chaînes sont dans l'appli, là, c'est bien plus difficile à détourner.
Des défauts ? Niveau place mémoire, ça prend pas plus que si tu les mets en
ressource. Gestion du multi-langue ? Ben tu les mets dans une DLL et tu
reproduis la même chose que si c'est dans le code principal. Difficulté de
patching ? Ben c'est justement le but recherché ! Si tes tables de chaînes
sont dans l'appli, leur chiffrement/déchiffrement est bien plus complexe à
détourner, tu peux me croire.
Les .rc, c'est excellent et très bien. Mais si tu veux protéger tes
ressources, c'est quasiment impossible avec :-(.
Là, je suis plutôt d'accord avec Paul. Si les RC étaient un boulet, ça se saurait, tout de même.
Je n'ai jamais dit que c'était un boulet. C'est très pratique ! Seulement c'est plein de défauts et surtout, tu ne peut pas TOUT faire avec.
Menus à part,
Lol, ben oui, les menus, c'est souvent très intéressant de les auto-générer :-)
Bah, celui qui veut espionner trouvera de toute façon une solution. Quelle que soit l'origine de ce qui est affiché, il pourra toujours capturer et recopier.
Tu peux tout de même sérieusement compliquer son travail ! Imagine que tes chaîne de caractères de l'application sont dans un.rc. Ben n'importe qui peut les extraire, modifier, remplacer, etc. Pareil pour les autres ressources, menus, icônes, bitmaps, etc. Même si tu chiffres ces ressources (bon courage !), il suffit de tracer par exemple un appel à LoadString() et de voir ce que le code fait avec ensuite. Facilement détournable donc.
Si tes chaînes sont dans l'appli, là, c'est bien plus difficile à détourner. Des défauts ? Niveau place mémoire, ça prend pas plus que si tu les mets en ressource. Gestion du multi-langue ? Ben tu les mets dans une DLL et tu reproduis la même chose que si c'est dans le code principal. Difficulté de patching ? Ben c'est justement le but recherché ! Si tes tables de chaînes sont dans l'appli, leur chiffrement/déchiffrement est bien plus complexe à détourner, tu peux me croire.
Les .rc, c'est excellent et très bien. Mais si tu veux protéger tes ressources, c'est quasiment impossible avec :-(.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter
Pour les chaînes, je suis d'accord. Je vois pas l'intérêt de les mettre en RC et d'ailleurs je le fais jamais, et pourtant je code toujours en multilangues. Mes chaînes sont soit dans des fichiers .H (un exe par langue), soit dans des matrices (exe unique pour toutes les langues).
L'intérêt majeur des ressources, pour moi, c'est d'inclure dans le code des bitmaps ou icones, et dessiner des boites de dialogue. Ce qui pose problème d'ailleurs pour les traductions (l'Anglais est court, l'Allemand long) et pour les traducteurs non équipés d'un éditeur de ressources. J'ai tendance aussi à mettre en ressource un menu générique que je modifie ensuite à l'exécution. Rien d'autre dans mes RC, et je vois pas ce que je pourrais y mettre de toute façon.
Avoue tout de même que, question maintenance, l'avantage va aux RC quand bien même y'a du code derrière.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller tes ressources ou bricoler ton programme sans plonger dans le code. Mais si ton exe est du genre sensible, de toute façon on joue plus la même partition. Mais à la limite, tu peux toujours ajouter un système subtil de vérification.
Au demeurant, je ne crypte jamais que la note de copyright ou les chaînes associées. Vieille habitude, et mon cryptage n'est pas très sérieux, juste de quoi casser les pieds des amateurs d'EditHexa.
Pour les chaînes, je suis d'accord. Je vois pas l'intérêt de les mettre
en RC et d'ailleurs je le fais jamais, et pourtant je code toujours en
multilangues. Mes chaînes sont soit dans des fichiers .H (un exe par
langue), soit dans des matrices (exe unique pour toutes les langues).
L'intérêt majeur des ressources, pour moi, c'est d'inclure dans le code
des bitmaps ou icones, et dessiner des boites de dialogue. Ce qui pose
problème d'ailleurs pour les traductions (l'Anglais est court,
l'Allemand long) et pour les traducteurs non équipés d'un éditeur de
ressources. J'ai tendance aussi à mettre en ressource un menu générique
que je modifie ensuite à l'exécution. Rien d'autre dans mes RC, et je
vois pas ce que je pourrais y mettre de toute façon.
Avoue tout de même que, question maintenance, l'avantage va aux RC quand
bien même y'a du code derrière.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller tes
ressources ou bricoler ton programme sans plonger dans le code. Mais si
ton exe est du genre sensible, de toute façon on joue plus la même
partition. Mais à la limite, tu peux toujours ajouter un système subtil
de vérification.
Au demeurant, je ne crypte jamais que la note de copyright ou les
chaînes associées. Vieille habitude, et mon cryptage n'est pas très
sérieux, juste de quoi casser les pieds des amateurs d'EditHexa.
Pour les chaînes, je suis d'accord. Je vois pas l'intérêt de les mettre en RC et d'ailleurs je le fais jamais, et pourtant je code toujours en multilangues. Mes chaînes sont soit dans des fichiers .H (un exe par langue), soit dans des matrices (exe unique pour toutes les langues).
L'intérêt majeur des ressources, pour moi, c'est d'inclure dans le code des bitmaps ou icones, et dessiner des boites de dialogue. Ce qui pose problème d'ailleurs pour les traductions (l'Anglais est court, l'Allemand long) et pour les traducteurs non équipés d'un éditeur de ressources. J'ai tendance aussi à mettre en ressource un menu générique que je modifie ensuite à l'exécution. Rien d'autre dans mes RC, et je vois pas ce que je pourrais y mettre de toute façon.
Avoue tout de même que, question maintenance, l'avantage va aux RC quand bien même y'a du code derrière.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller tes ressources ou bricoler ton programme sans plonger dans le code. Mais si ton exe est du genre sensible, de toute façon on joue plus la même partition. Mais à la limite, tu peux toujours ajouter un système subtil de vérification.
Au demeurant, je ne crypte jamais que la note de copyright ou les chaînes associées. Vieille habitude, et mon cryptage n'est pas très sérieux, juste de quoi casser les pieds des amateurs d'EditHexa.
Arnold McDonald \(AMcD\)
Bertrand Lenoir-Welter wrote:
Avoue tout de même que, question maintenance, l'avantage va aux RC quand bien même y'a du code derrière.
Oui, oui, sans problème. Et recommandons-les chaudement et en premier lieu.
Je réagissais juste aux propos de notre ami qui disait qu'on polluait en créant de l'auto-généré. Il est des cas où on ne peut pas faire autrement.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller tes ressources ou bricoler ton programme sans plonger dans le code.
Voilà. Et ça, c'est le gros défaut des ressources.
Mais si ton exe est du genre sensible, de toute façon on joue plus la même partition. Mais à la limite, tu peux toujours ajouter un système subtil de vérification.
Moi, en ressource, je n'ai que la triple icône associé à l'application et des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes. etc. Tout le reste c'est auto-généré comme dirait PB. C'est sûr qu'à coup de copie d'écran un gars peu piquer les icônes, tout ça, mais bon, l'essentiel et qu'il ne puisse rien extraire de l'exe, sinon à grand coup de nuits blanches.
juste de quoi casser les pieds des amateurs d'EditHexa.
Tout à fait, cela est parfois suffisant de simplement XORer quelques bitmaps, icônes, chaînes, etc. Cela rebute tous les hackers en bois. Mais si t'utilises les .rc, ça leur facilite par contre grandement la tâche. Tout dépend de ton application quoi...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter wrote:
Avoue tout de même que, question maintenance, l'avantage va aux RC
quand bien même y'a du code derrière.
Oui, oui, sans problème. Et recommandons-les chaudement et en premier lieu.
Je réagissais juste aux propos de notre ami qui disait qu'on polluait en
créant de l'auto-généré. Il est des cas où on ne peut pas faire autrement.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller
tes ressources ou bricoler ton programme sans plonger dans le code.
Voilà. Et ça, c'est le gros défaut des ressources.
Mais si ton exe est du genre sensible, de toute façon on joue plus la
même partition. Mais à la limite, tu peux toujours ajouter un système
subtil de vérification.
Moi, en ressource, je n'ai que la triple icône associé à l'application et
des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes. etc. Tout
le reste c'est auto-généré comme dirait PB. C'est sûr qu'à coup de copie
d'écran un gars peu piquer les icônes, tout ça, mais bon, l'essentiel et
qu'il ne puisse rien extraire de l'exe, sinon à grand coup de nuits
blanches.
juste de quoi casser les pieds des amateurs d'EditHexa.
Tout à fait, cela est parfois suffisant de simplement XORer quelques
bitmaps, icônes, chaînes, etc. Cela rebute tous les hackers en bois. Mais si
t'utilises les .rc, ça leur facilite par contre grandement la tâche. Tout
dépend de ton application quoi...
Avoue tout de même que, question maintenance, l'avantage va aux RC quand bien même y'a du code derrière.
Oui, oui, sans problème. Et recommandons-les chaudement et en premier lieu.
Je réagissais juste aux propos de notre ami qui disait qu'on polluait en créant de l'auto-généré. Il est des cas où on ne peut pas faire autrement.
Pour ce qui est du cryptage, c'est sûr que n'importe qui peut piller tes ressources ou bricoler ton programme sans plonger dans le code.
Voilà. Et ça, c'est le gros défaut des ressources.
Mais si ton exe est du genre sensible, de toute façon on joue plus la même partition. Mais à la limite, tu peux toujours ajouter un système subtil de vérification.
Moi, en ressource, je n'ai que la triple icône associé à l'application et des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes. etc. Tout le reste c'est auto-généré comme dirait PB. C'est sûr qu'à coup de copie d'écran un gars peu piquer les icônes, tout ça, mais bon, l'essentiel et qu'il ne puisse rien extraire de l'exe, sinon à grand coup de nuits blanches.
juste de quoi casser les pieds des amateurs d'EditHexa.
Tout à fait, cela est parfois suffisant de simplement XORer quelques bitmaps, icônes, chaînes, etc. Cela rebute tous les hackers en bois. Mais si t'utilises les .rc, ça leur facilite par contre grandement la tâche. Tout dépend de ton application quoi...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter
Arnold McDonald (AMcD) :
Tout à fait, cela est parfois suffisant de simplement XORer quelques bitmaps, icônes, chaînes, etc.
Arnold, t'es fou ! Faut pas révéler des trucs comme ça !
Arnold McDonald (AMcD) :
Tout à fait, cela est parfois suffisant de simplement XORer quelques
bitmaps, icônes, chaînes, etc.
Arnold, t'es fou ! Faut pas révéler des trucs comme ça !
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:43ff0512$0$29217$
Arnold McDonald (AMcD) :
Tout à fait, cela est parfois suffisant de simplement XORer quelques bitmaps, icônes, chaînes, etc.
Arnold, t'es fou ! Faut pas révéler des trucs comme ça !
Franchement, si votre propriété intellectuelle est dans une chaîne ou une image, il est clair que l'on ne fait pas le même travail.
-- Paul Bacelar
Arnold McDonald \(AMcD\)
Paul Bacelar wrote:
Franchement, si votre propriété intellectuelle est dans une chaîne ou une image, il est clair que l'on ne fait pas le même travail.
Si ton appli comporte 200 icône qu'un graphiste a pris cher pour dessiner, si ton appli comporte 500 bitmaps qu'un graphiste a pris cher à dessiner, si ton appli comporte des milliers de chaînes de caractères qui ont coûté cher à traduire, si ton appli comporte des textures, des curseurs, des composants personnalisés, etc. qui ont mis du temps à être élaborées, des ressources personnelles (binaires, graphiques, etc.) qui ont coûté de l'argent (j'arrête ici), alors, il est concevable de s'échiner à retarder un peu les hackers a deux sous qui veulent te piquer tes ressources en deux coups de cuillère à pot.
Une application, ce n'est pas que de l'implémentation d'algorithme...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Paul Bacelar wrote:
Franchement, si votre propriété intellectuelle est dans une chaîne ou
une image, il est clair que l'on ne fait pas le même travail.
Si ton appli comporte 200 icône qu'un graphiste a pris cher pour dessiner,
si ton appli comporte 500 bitmaps qu'un graphiste a pris cher à dessiner, si
ton appli comporte des milliers de chaînes de caractères qui ont coûté cher
à traduire, si ton appli comporte des textures, des curseurs, des composants
personnalisés, etc. qui ont mis du temps à être élaborées, des ressources
personnelles (binaires, graphiques, etc.) qui ont coûté de l'argent
(j'arrête ici), alors, il est concevable de s'échiner à retarder un peu les
hackers a deux sous qui veulent te piquer tes ressources en deux coups de
cuillère à pot.
Une application, ce n'est pas que de l'implémentation d'algorithme...
Franchement, si votre propriété intellectuelle est dans une chaîne ou une image, il est clair que l'on ne fait pas le même travail.
Si ton appli comporte 200 icône qu'un graphiste a pris cher pour dessiner, si ton appli comporte 500 bitmaps qu'un graphiste a pris cher à dessiner, si ton appli comporte des milliers de chaînes de caractères qui ont coûté cher à traduire, si ton appli comporte des textures, des curseurs, des composants personnalisés, etc. qui ont mis du temps à être élaborées, des ressources personnelles (binaires, graphiques, etc.) qui ont coûté de l'argent (j'arrête ici), alors, il est concevable de s'échiner à retarder un peu les hackers a deux sous qui veulent te piquer tes ressources en deux coups de cuillère à pot.
Une application, ce n'est pas que de l'implémentation d'algorithme...
