Question juste pour comprendre même si aucun intérêt pratique.

Je suis tombé par hasard sur un sujet dans lequel un gars voulait pouvoir déterminer quel langage de prog a été utilisé pour créer un soft dont il n'a que l'exe.
On lui réponds que c'est impossible car lors de la compile; le code est changé en binaire et qu'il ne subsiste rien de langage de prod de départ.

La question que je me pose est la suivante :
Si on a un "code" binaire qui "explique" à l'ordi comment se comporter.
Qu'à la source on avait un code "moins primaire" qui a servit à générer ce code "primaire".

Comment se fait-il qu'il soit impossible pour un ordinateur de recréer le code "moins primaire" sur base du "plus primaire".

Je veux dire...
Si je prends une soupe aux tomates, avec un peu de chimie je pourrai reconstituer les différents ingrédients et avec un peu de logique je pourrai recréer une recette qui même si elle n'est pas la même, aura tout de même comme résultat une soupe aux tomates.

--> Si on prends un PRG en assembleur ou en binaire, pourquoi ne sait on pas le "recomposer" en langage comme du C ?

Merci d'avance pour vos explications.

A fort bientôt.

Le problème c'est que deux langages utilisant le même paradigme peuvent (et dans le cas idéal, devraient) donner exactement le même code.

Citation:

---

Envoyé par Yepazix

Je veux dire...
Si je prends une soupe aux tomates, avec un peu de chimie je pourrai reconstituer les différents ingrédients et avec un peu de logique je pourrai recréer une recette qui même si elle n'est pas la même, aura tout de même comme résultat une soupe aux tomates.

---

En reprenant ton exemple, ici ce que tu demandes ce n'est pas de recomposer la recette de savoir quel langage a été utilisé mais plutôt : "sur quel support la recette a été écrite ?"

Que ta recette soit sur papier / numérique / dans ta mémoire / écrite sur ton mur. Au final ça donnera la même soupe.

Bonjour :coucou:

Citation:

---

Envoyé par Yepazix

Si je prends une soupe aux tomates, avec un peu de chimie je pourrai reconstituer les différents ingrédients et avec un peu de logique je pourrai recréer une recette qui même si elle n'est pas la même, aura tout de même comme résultat une soupe aux tomates.

---

Ok. Je te sers un verre d'eau. Comment détermineras-tu si c'est de l'eau extraite d'une feuille de salade, ou bien l'eau de la fonte d'une neige éternelle, ou bien de mon urine filtrée ?

Si l'exécutable mets 120 dans l'accumulateur du processeur, comment sais-tu si cette action vient de A=120; ou de A=factorielle(5); ? Et je ne pose pas cette question au hasard. Le compilateur peut faire sauter des pans entiers de ton code, car inutiles.

Bonjour,

Je ne suis pas forcément d'accord, ça va beaucoup dépendre du contenu de l'exe en fait.

Souvent, les exe sont dépendants de librairies présentes sur la machine, dont parfois une ou plusieurs librairies liées à un langage. Bien sûr, il est possible de charger des librairies Java en C, mais l'exe reste lié à la lib C.
Ensuite, tous les exe ne sont pas strippés, et certains outils permettent dans ce cas de lister les symboles et la librairie.

En se basant sur plusieurs choses bas niveau, il est tout de même possible d'obtenir une forte probabilité du langage de départ. Ou d'un langage de départ. Car il ne faut pas oublier qu'il y a aussi des langages qui sont compilés vers un 1er langage cible, qui lui-même est compilé vers du langage machine.
Le langage cible est souvent un langage bas-niveau permettant des optimisations fortes et disposant de nombreux compilateurs pour toutes les plateformes, comme le C.

Mais même dans ce cas, il est possible avec des connaissances de ces langages de remonter : le code généré (le C donc) va souvent comporter des manières de faire qui sont spécifiques et qui peuvent être reconnues (parfois, avec de l'habitude et tout et tout).

Pour ceux qui veulent jouer avec un exe et approfondir le sujet, je ne peux que conseiller l'utilisation de ghidra, un outil de reverse engineering de la NSA : https://en.wikipedia.org/wiki/Ghidra.
Pensez à faire une copie de l'exe que vous ciblez, et tout ceci doit être fait dans le respect des lois.

Citation:

---

Envoyé par Yepazix

Si je prends une soupe aux tomates, avec un peu de chimie je pourrai reconstituer les différents ingrédients et avec un peu de logique je pourrai recréer une recette qui même si elle n'est pas la même, aura tout de même comme résultat une soupe aux tomates.

---

C'est bien simple : on parle de LANGUAGE (C, ADA, Pascal, etc.), pas des ingrédients (instructions du CPU).

Ainsi, si tu prends un livre de recette en français et que tu prépares une sauce tomate, un chimiste polonais saura retrouver quels ingrédients tu as utilisé, peut-être même dans quel ordre tu les a mis, mais ne saura pas réécrire ta recette en français : au mieux il écrira une recette en polonais !

Par contre, un bémol sur ce qui a été répondu à ton collègue.

La plupart des langages ont leurs propres spécificités et frameworks.

Ainsi, un programme *.exe créé avec .NET ou Java ne pourront probablement pas être décompilés avec un décompilateur C.
Et l'inverse est encore plus vrai !

Donc à partir de l'EXE, on peut retrouver des pistes (ou en écarter) pour déduire le langage utilisé. Si ton EXE référence des librairies .NET c'est probablement du C# ou VB.NET, s'il référence un JDK, c'est du Java, s'il référence les redistribuables C++ bah... c'est probablement du C++ (ou pas)

Dans tous les cas, à l'image du VB.NET et C#, il est possible de décompiler un même programme dans l'un ou l'autre des deux langages sans aucun problème, tout comme une recette en français peut être transcrite en polonais simplement en étudiant le résultat.

Avant tout , merci a tous pour vos commentaires tres enrichissants.

Je comprends certains éléments de ce que vous dites mais pas la finalité "logique".

Citation:

---

Ainsi, si tu prends un livre de recette en français et que tu prépares une sauce tomate, un chimiste polonais saura retrouver quels ingrédients tu as utilisé, peut-être même dans quel ordre tu les a mis, mais ne saura pas réécrire ta recette en français : au mieux il écrira une recette en polonais !

---

C'est justement ce qui me perturbe.
Si je prends ma recette en Français, je fais ma soupe.
Ensuite un "expert" analyse ma soupe, trouve les ingrédient, leur ordre, leur proportion et refait une recette en polonais qui donne une soupe identique.

On peut donc penser qu'en prenant un exe ecrit en C et compilé, on pourrait le décompiler en Pascal.

Bon OK, je comprends pourquoi dans l'absolu c'est difficile, voir impossible à cause des librairies.
Mais si on le décompilait dans le même langage ?

Bon après ça n'a en fait pas grand intérêt de décompiler pour décompiler.

Là ou je veux en venir c'est que je vois parfois des discussion sur tel langage qui a un "bon" compilateur ou pas.
Je me suis donc dit que l'ordinateur était un étrange machine capable de comprendre plein de langages qui peuvent lui dire de faire la même chose mais qu'en fonction de la manière dont on lui parle il va faire ces choses + ou - bien.
Dans la mesure ou finalement avant de "faire" il va de toute façon traduire ça en assembleur, je me suis dit OK, le PC traduit un langage plus ou moins bien dans sa langue.
Mais comme généralement quand on traduit ca marche dans les deux sens, pourquoi ne pas pouvoir revenir dans l'autre sens.
Interet de la finalité de ce raisonnement:
Imaginons un vieux exe développé sur Delphi 3 (donc Pascal Object si je ne me trompe).
On l'a compilé, on l'a utilisé les années ont passées.
Ajd on se dit, tiens je reprendrait bien ce vieux brol pour le mettre au gout du jour...
ce serait tout de même cool de pouvoir le "retranscrire" dans un langage récent (du moins la base) pour ensuite le retravailler ?

Bon ok oui je me drogue de temps en temps.... mais avouez que ce serait cool non ?

Hello,

C'est tout à fait possible, mais ça reste compliqué.

Si tu écris un code (propre), tu obtiens quelque chose de lisible et de (normalement) à peu près compréhensible par beaucoup de développeurs.
Ensuite, tu prends ce code, puis tu le compiles, et là ça complique les choses, parce que le compilateur peut soit produire du code machine qui est "au plus proche" de ton code, soit appliquer tout un tas d'optimisations.

Tu peux essayer (par exemple) de prendre un programme simple en C (ou autre), puis de produire l'assembleur avec ou sans optimisation, et comparer. [avec gcc, tu peux lancer "gcc -S test.c" et "gcc -O2 -S test.c" par exemple pour produire les 2 sorties].

Après, dans le cas que tu cites, pourquoi ne pas repartir des sources, et appliquer un programme comme p2c (pascal to C) ?

• Tout d'abord, c'est trop compliqué. Même si dans l'absolu c'est imaginable. (le temps c'est de l'argent, on vit dans une société consumériste qui ne répare pas, etc)
• Ensuite, un logiciel peut faire appel à des fonctions stockées dans des bibliothèques extérieures... qui n'existent plus !
• Enfin, on ne peut pas forcément faire du "poste pour poste". Imaginons une instruction qui décale à gauche dans la mémoire. Sur un système 32 bits, les données les plus à gauche sont perdues. Dans un système 64 bits, les données qui auraient dû disparaître, selon le programmeur, ne disparaissent plus. Et il faut comprendre, au-delà du code, ce qu'a voulu faire l'auteur, pour le reproduire. Ce n'est pas facile. En tout cas, pas systématique.

Je vois que j'ai encore une fois réussi à poser une questions surréaliste ou même les experts comme vous ne tombent pas d'accord :lol::lol::lol::lol:

Bon j'ai un peu regardé Ghidra.
Si je ne me trompe c'est un peu un ancêtre non ?
Je vois des "brocantes" comme les regrettés processeurs 68000 (Ah un bon vieil Amiga, Amos Pro et un disque dur de 20Mo) :lol::lol::lol::lol:
Par contre je ne vois pas de 64 bits...

ET il faut aussi installer java pour que ça tourne non ?

Du coup j'ai essayé X64dbg que j'ai trouvé sur le net.
J'ai pris un tout petit et vieux programme de dessin que j'utilisais avec mon XP (et dont j'ai la licence).
Et j'ai essayé de voir à quoi ça ressemble.
Bon je crois que j'ai piger ce que sont des points d'arrêt et j'ai modifié quelques chaines de caractère pour que les menus soient en Français.
Ca marche et c'est marrant :-).

Mais bon ça reste complexe à lire...
Est ce que c'est ça qu'on appel débugger en live ? Ou est ce que c'est debugger Off line ?

Est ce qu'il y a des autres trucs que X64dbg qui permettent de voir plus clair ?

Ou est ce que je pourrais prendre des cours ou des tutos la dessus car même si je comprends certaines choses il y a encore des choses assez mystérieuse comme par exemple cette pile.
Et d'ailleurs une pile comment AA ? AAA? 1.5v, 9v ? :lol::lol::lol::lol::lol:

Je vois aussi qu'il y a des commandes spécifiques .
Si on prend les instructions J par exemple c'est assez "ergonomique" ça saute, c'est une sorte de GOTO quoi...
Par contre il y a plein de brols comme les AES, AND, CVT, VFN,... qui sont dans l'abstraction totale.

Je pensais trouver quelque chose d'un minimum compréhensible mais en fait ce sont des opérations qui sont hors de la (ma) portée humaine aussi bien en lecture en qu'en écriture.

Par exemple si je voulais simplement écrire un tout petit exe qui lit la première ligne d'un fichier texte et l'affiche... ou si je devais trouver cette petite routine dans un exe... Ca me semble impossible car, arretez moi si je me trompe mais je n'aurai à aucun endroit une commande du genre
ouvrirfichier "machin".
affichercontenufichier "machin".

Ca ressemblerait plus à un brol du genre.
Ajoute un octet par ci.
Permute un octet par la.
Multiplie 4 paquets par la valeur réel de brol.
etc...

Je suis dans le bon ?

Voilà. Tu as tout compris.

C'est la différence entre les logiciels propriétaires et les logiciels libres. Dans les logiciels libres, on te donne le code compréhensible par un être humain. Dans le logiciel propriétaire, on te donne uniquement le code exécutable par la machine; et tu ne peux rien en faire. Si tu as des envies, mets-toi au logiciel libre.

À noter : j'ai déjà vu un dé-constructeur java qui produit du code java à partir d'un fichier compilé.

@Flodelarab Oui JE ne sais rien en faire car je suis un navet mais quelqu'un qui connait super bien l'assembleur ne pourrait il pas s'y retrouver ?

Bonjour,

Quand on connait l'assembleur, on peut modifier directement le programme compilé sans avoir besoin de le décompiler.

Voici un exemple de jeu vidéo qui a continué à évoluer grâce à sa communauté pendant 20 ans après sa sortie :
https://www.ttdpatch.net/

Ceci dit, l'assembleur est très compliqué et pas bien pratique. Généralement, on le réserve pour faire des modifications mineures (ce qu'était à a base TTDPatch d'ailleurs) genre, le plus souvent, les cracks de logiciels sont codés en assembleur.
Sorti de ça, quand tu commences à vouloir refondre en profondeur le programme, l'assembleur montre ses limites (sans oublier qu'un code de 3 lignes en C++ peut en faire des dizaines, voir centaines en ASM).

C'est pour cette raison que TTDPatch ici donné en illustration a, à terme, été remplacé par OpenTTD : une décompilation en C puis réécriture complète du programme du C++.
https://www.openttd.org/

J'insiste ici sur :
- décompilation en C
- PUIS réécriture complète (tout d'abords en C puis en C++)

En effet, le code décompilé d'origine n'était :
- pas lisible
- donc pas maintenable

Et accessoirement, même si l'auteur original Chris Sawyer et son éditeur Microprose ne se sont jamais opposés à ces deux forks, modifier du code d'un autre (y compris décompilé) cause des droits d'auteur.

https://fr.wikipedia.org/wiki/Transport_Tycoon

Bref, oui, on peut s'y retrouver mais tout dépend de ce qu'on veut faire, et c'est généralement un travail de longue haleine.

Ah, on s'approche un peu de ce que mon esprit malade ébauchait sans vraiment le savoir...

Tu dis :

Citation:

---

J'insiste ici sur :
- décompilation en C
- PUIS réécriture complète (tout d'abords en C puis en C++)

En effet, le code décompilé d'origine n'était :
- pas lisible
- donc pas maintenable

---

Donc, si je te comprends bien...
Un PC à décompilé un exe pour créer du C mais ça donne un truc tout pourri et bordélique.
Ensuite un humain à repris ce code tout pourri et a ré-écrit un beau code un peu plus propre.
Ensuite le même humain (ou un autre) à repris son code en C et la "upgradé" en C++.

C'est bien ça ?

Si oui --> Question !

Pourquoi alors que des PC sont capables d'optimiser le code, ils sont incapables de "nettoyer" un code un peu pourri pour en faire un code bien lisible ?
Serais ce là la barrière qui sépare l'esprit humain de l'ordi?
Et donc dans l'avenir avec les IA n'y aura t'il pas des systèmes capables de comprendre la "logique" d'un exe et de creer de toute pièce un code qui "ferait la même chose " ?

Citation:

---

Pourquoi alors que des PC sont capables d'optimiser le code

---

Rends à chacun sa responsabilité. Un pc n'est pas un logiciel. Un exécutable binaire n'est pas un texte de code. Un éditeur de code n'est pas un compilateur. C'est en mélangeant tout que les médias racontent n'importe quoi.
Et toi ? Comprends-tu les nuances entre toutes ces choses ?

Citation:

---

Et donc dans l'avenir avec les IA n'y aura t'il pas des systèmes capables de comprendre la "logique" d'un exe et de creer de toute pièce un code qui "ferait la même chose " ?

---

Bien sûr que si ! Peut-être même que cela existe déjà. Mais une fois de plus, tu oublies un paramètre primordial : le temps. Le temps, c'est de l'argent; et de l'argent, personne n'en donne. Libre à toi d'en fabriquer un.

Je crois que je comprends la différence entre un exe binaire et du code et aussi entre un éditeur et un compilateur.
Ce n'est pas à ce step que mon cerveau bug.

Là ou ça bug c'est que je comprends mal comment un cerveau humain peut "faire tourner" un programme d'interprétation, d'analyse et de réécriture et qu'une tâche aussi "primaire" soit impossible à un ordinateur.

Car en fin de compte exe binaire ou code, même si je vois bien les différences structurelles, ce sont des suite de commandes.
Des commandes soit données à un compilateur pour qu'il crée qq chose de compréhensible par un processeur.
Ou des commande données directement au processeur.

Si j'écris "va à la maison" et qu'on me compile ça en langage "à moi", le résultat sera toujours le même : je vais aller à la maison !

Ce que je ne comprends donc pas c'est pourquoi en observant le résultat "je vais à la maison", le PC n'est pas capable de recréer "va à la maison" ou "go to the house", ou "nenda kwenye Nyumba" ?

Le problème, c'est que (hormis certains langages qui gardent délibérément des infos) une partie de l'information disparait lors de la compilation, ne retenant que l'essentiel.
Si tu écris dans un langage donné AfficherNombre(2+2), le résultat sera un truc du genre:

Code:

---

1 2 3 4

MOV EAX, 2 ADD EAX, 2 PUSH EAX CALL AfficherNombre

---

En quel langage ce bout de code a-t-il été écrit? Un code aussi simple peut être décompilé en n'importe quel langage, sans savoir lequel était celui d'origine.

Hello,

Je vais essayer de répondre à ta question:

Citation:

---

Envoyé par Yepazix

Ce que je ne comprends donc pas c'est pourquoi en observant le résultat "je vais à la maison", le PC n'est pas capable de recréer "va à la maison" ou "go to the house", ou "nenda kwenye Nyumba" ?

---

Ce que tu considères comme simple est en fait très complexe. Je vais à la maison, c'est en fait énormément de sous-instructions qui s'enchaînent -- je ne prends même pas en compte le fait de traverser une route. Mais là c'est un autre problème.

Tout d'abord, il faut détailler l'algo. On va prendre un cas simple : je vais de là où je suis à la porte de la maison, c'est tout droit, aucun obstacle à éviter, route à traverser, ..., à pied. L'algo simpliste est donc :

Code:

---

1 2 3 4 5

se mettre dans la bonne direction Tant que 'pas arrivé' marcher fin Tant que fin

---

En code, je peux aussi écrire:

Code:

---

1 2 3 4 5 6

Tourner à gauche 90° je_suis_ici avancer 1 pas si je suis ici != arrivée goto je suis ici fin

---

Ces 2 codes peuvent produire le même code généré, alors que ce qu'a écrit le développeur est assez différent -- même si l'idée est identique. Et encore, je ne gère aucune erreur dans les cas ci-dessus.

Pourquoi n'essayes-tu pas de faire plusieurs programmes qui font la même chose, et regarder l'assembleur généré ?

Un autre très bon exemple, c'est les fonctions INLINE.
Il se complète très bien avec l'utilisation de constantes.

Dans un code, on peut spécifier (ou non, le compilateur peut faire le choix lui aussi) qu'une fonction doit être "inline", c'est à dire que lors de tous ses appels on va recopier son contenu plutôt que de l'appeler.
On peut aussi faire des calculs (inutiles pour l'ordinateur, mais vitaux pour comprendre l'algo) sur des constantes.

Ainsi, le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void main() { int a = ajoute(2, 2); int b = ajoute(3, 3); Affiche(ajoute(a, b)); }   int ajoute(int i, int j) { if (i != j) return i + j; else return i << 1; }

---

Peut être réécrit, au moment de la compilation en (passage de la fonction en inline) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

void main() { int a = 0; int ai = 2; int aj = 2; if (ai != aj) { a = ai + aj; } else { a = ai << 1; } int b = 0; int bi = 3; int bj = 3; if (bi != bj) { b = bi + bj; } else { b = bi << 1; } int c = 0; if (a != b) { c = a + b; } else { c = a << 1; }   Affiche(c); }

---

Ca commence à pas être simple pour s'y retrouver... difficile de déduire la fonction inline.

Mais surtout, le compilateur, il est pas bête, et quand il voit une valeur littérale constante, il sait optimiser... donc les if / else inutiles, il peut les faire sauter comme un grand :

Code:

---

1 2 3 4 5 6 7

void main() { int a = 2 << 1; int b = 3 << 1; Affiche(a + b); }

---

Et vu qu'il sait aussi généralement comprendre les calculs sur les constantes, il va produire :

Code:

---

1 2 3 4 5

void main() { Affiche(10); }

---

Et là, bah même la meilleure des IA ne pourra jamais reproduire le code d'origine !

Un autre exemple serait par exemple d'avoir des fonctions pour comparer la taille de rectangles (par rapport à leur périmètre).

Ainsi, tu auras une fonction qui vérifie si a * 2 + b * 2 est < ou > que x * 2 + y * 2

Sauf que le compilateur, il peut se dire "il sert à rien ce deux" :

a + b < ou > x + y

Et ainsi, l'algo lui-même est modifié, donc impossible de reproduire le code d'origine !
Et pire encore ! a + b dans un rectangle, c'est ce qu'on appelle la "distance de Manhattan".
Du coup, le décompilateur, il te sort une fonction ManhattanDistance de derrière les fagots et là tu n'y comprends plus rien !

Et ces cas que je décris, même si ça ne se passe pas exactement comme ça, ce sont des exemples "réels". Les compilateurs modernes savent réécrire des portions entière d'algorithme lors de la compilation.

Je comprends mieux et je vais suivre le conseil de Gangsoleil de faire des mini exe et de voir ce que ça donne en assembleur.
Par contre vous semblez tous dire que je souhaiterais récréer le code original sur base de l'assembleur...

Sisisisi, je vous vois venir, vous pensez que je veux faire du vilain piratage :lol::lol::lol::lol:

Mais en fait c'est tout l'inverse, ce que je me disais c'est que on à souvent des gueguerres tel langage est mieux, la compile est plus optimisée, il va plus vite, etc...
L'intérêt serait donc justement que "la finalité" (ce que fait le programme) puisse être recréé dans n'importe quel langage.

Mais pourquoi je pense à des trucs pareils... à part le fait que j'abuse de drogues et d'alcool bien sur :D:D:D:lol::lol::lol:

ET bien voilà jusqu'ou ça va... oui oui docteur je vais prendre mes médocs.

Si on partais du point de vue qu'on est capable de créer un système qui en regardant le fonctionnement puisse créer du code...
Alors on pourrait se dire qu'il serait possible "demander" à un système de ce genre de créer un système de code (un langage en fait) qui serait "mieux" que ceux qui existent.
Toujours en partant de là, ce qui est "mieux que ce qui existe" est un paramètre subjectif mais on pourrait imaginer que "mieux" ça soit "plus proche du fonctionnement de la communication humaine".

Et donc, entrons dans la philosophie informatique...
Ce que je me demande c'est si un jour on pourra simplement dire à a son PC :
Prends la valeur de mon prix.
ajoute la tva de 21%
crée une page.
met un entete en haut à droite
met le nom du client au milieu

etc...
Et que le PC puisse créer un programme de toute pièce.

En fait je me demande si on pourra un jour avoir une évolution "vocale" comme celle que Delphi à été au Pascal ?

Merci de participer à mon délire en tous cas, je sais que je suis bizarre avec mes questions surréalistes et ça ne s'est pas arrangé avec le confinement ;-)

Citation:

---

Envoyé par Yepazix

Et donc, entrons dans la philosophie informatique...
Ce que je me demande c'est si un jour on pourra simplement dire à a son PC :
Prends la valeur de mon prix.
ajoute la tva de 21%
crée une page.
met un entete en haut à droite
met le nom du client au milieu

etc...
Et que le PC puisse créer un programme de toute pièce.

En fait je me demande si on pourra un jour avoir une évolution "vocale" comme celle que Delphi à été au Pascal ?

Merci de participer à mon délire en tous cas, je sais que je suis bizarre avec mes questions surréalistes et ça ne s'est pas arrangé avec le confinement ;-)

---

C'est pas si abouti que ça, mais ça existe déjà.

Les assistants vocaux peuvent accomplir des tâches plus complexes qu'Alexa ou OK Google. Il en existe des libres de droit pour Linux qu'on peut enrichir soi-même.

Rien n'empêche de les coupler à une IA (ou plusieurs d'ailleurs) qui permette de résoudre des problèmes, voir de générer du code.

Il y avait un alternant dans ma boîte qui avait eu un projet de ce type, où il pouvait montrer une photo d'une partie d'échiquier à l'assistant, et ce dernier pouvait alors continuer la partie en donnant et recevant des ordres vocaux (du coup deux assistants pouvaient jouer l'un contre l'autre :D)

Citation:

---

Envoyé par Yepazix

Par contre vous semblez tous dire que je souhaiterais récréer le code original sur base de l'assembleur...

Sisisisi, je vous vois venir, vous pensez que je veux faire du vilain piratage

---

Clairement pas.
Recréer le code n'a absolument aucun intérêt pour une personne souhaitant modifier un logiciel -- le but (le plus souvent) va être de changer le comportement, pas de reprendre du code pour en faire autre chose.

Citation:

---

Mais en fait c'est tout l'inverse, ce que je me disais c'est que on à souvent des gueguerres tel langage est mieux, la compile est plus optimisée, il va plus vite, etc...
L'intérêt serait donc justement que "la finalité" (ce que fait le programme) puisse être recréé dans n'importe quel langage.

---

Ah mais tu peux faire n'importe quel programme dans n'importe quel langage, c'est juste plus ou moins fait pour, donc plus ou moins long (et donc cher), ou optimisé.
Rien ne t'empêche de faire un programme pour de l'embarqué avec un langage de haut niveau, qui intègrera plein de librairies à côté. Simplement ton programme va faire quelques Mo au lieu de quelque Ko, donc tu vas devoir soit augmenter l'espace dispo dans ton hardware (c'est cher), soit faire des cycles d'optimisation pour supprimer tout ce qui n'est pas nécessaire dans ton exe -- et ceci a un coût non négligeable.

On avait "joué" il y a longtemps à faire un "Hello World" en C, mais dans un environnement CORBA complet. L'exe produit, qui embarquait donc toutes les dépendances, faisait plus de 20 Mo -- pour un simple Hello World !

Pouvoir adapter le langage selon les besoins est, à mon sens, une grande force dont il ne faut pas se priver (enfin il faut savoir être raisonnable quand même, car si tu changes de langage à chaque exe la maintenance va être super complexe).