[F] [mOved] Mon langage est mieux que le tien - Page 36

Je m'en fous j'utilise Bitbucket
Aaaaouch, ça fait mal. J'ignorais qu'un AWS perdu pouvait être utilisé, indirectement, dans l'équivalent d'un vol d'informations bancaires.

Très intéressant. Effectivement les url générées ne sont pas très propres, mais ça change de la classique exploitation des x% de perte possible pour en faire un logo central.

http://danstonchat.com/16795.html
Un peu violent, ce rateau.

ouch

Comme d'habitude, CommitStrip est très bon :

GT Pas fan du C++

1 point Godwin

http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967
Ca, ça poutre !
Bon, j'étais en train de bricoler un "compilateur de ressources", enfin plus exactement un archiveur, avec une api pour récupérer les fichiers facilement depuis le programme utilisateur.
Mais son truc, c'est tentant, même si ça fait un peu bricolage ^^

À l'époque j'avais tout simplement ajouté mes ressources à la fin de l'exe après compilation, et à la toute fin la taille des données ajoutées.
Comme ça le programme lisait argv[0] et trouvait ses données tout seul.

Et c'est suffisant, le format d'exécutable supporte ça ?

Le format d'exécutable n'y voit rien, il n'a pas besoin de le savoir (sauf si par malchance il se base sur la fin du fichier, mais dans mon cas, sur windows, ça fonctionnait — et je l'avais proposé à un collègue il y a seulement quelques années, ça marchait très bien sur Win 7)

Il y a plus simple: cette macro d'une ligne marche avec n'importe quel target GCC qui utilise GNU as (en une version pas totalement antique, ça a été rajouté il y a une dizaine d'années).

en gros :
- compilation qui génère mon exe sans les données
- patch :
fopen(exe)
fsseek à la fin
fwrite mes données
fwrite la taille des données
fclose()

- exe principal
main()
{
fopen(argv[0])
fseek(à la fin - sizeof(int))
int size
fread(&size, sizeof(int))
fseek(depuis la fin - size - sizeof(int))
byte[] data
fread(data,size)
}

Kevin > C'est pas portable
De toute façon, JAR marche bien pour les vrais langages

Tu roxes Kevin, c'est exactement ça qu'il me faut \o/
Je vais juste faire un wrapper pour embarquer aussi le nom du fichier et connaitre sa taille, histoire de pouvoir le reconstituer. Certaines libs peuvent en avoir besoin.
Mais sinon c'est parfait ton truc

Pen^2 -> j'avais bien compris comment ça marchait, mais c'est quand même une méthode un peu moins orthodoxe ^^

Pen^2 ta methode est celle utilise par 99% des app qui embarquent des donnes, et c'est d'ailleurs la methode la plus propre a vrai dire car ne demande pas de modifier l'executable/code en lui meme.

C'est comme ca que marche les zip et autre rar auto extractable, les fichier .bin qu'on trouve sous linux qui sont un script shell avec un payload binaire etc...

À noter qu'il existe un moyen "propre" d'intégrer ce genre de données dans un exécutable Windows, et de les utiliser à la demande sans devoir aller lire le fichier exécutable et allouer la mémoire soi-même :
https://en.wikipedia.org/wiki/Resource_%28Windows%29

Mais évidemment ce n'est pas portable.

C'est vrai, on peux aussi utiliser des section du format ELF d'une maniere assez proche, mais ce n'est pas portable non plus

Pen^2 (./1067) :
Kevin > C'est pas portable

Ta méthode n'est pas portable non plus:

• Elle présuppose que le format tolère les octets poubelle à la fin. Contre-exemple: le format des TI-68k.
• Elle présuppose que argv[0] contient un chemin absolu ou du moins relatif au dossier courant (et aussi l'extension implicite comme .EXE s'il y en a une), ce qui n'est pas garanti non plus. Sous *nix, argv[0] est le nom tel qu'il a été rentré en la ligne de commande, donc généralement (exécutable dans le PATH), fopen(argv[0]) ne fonctionnera pas! (Le noyau Linux propose /proc/self/exe, mais ce n'est évidemment pas portable non plus.)

Mouais, mouais, mouais
fopen(system(
#if win32
where
#elif unix
which
#else
# error gtfo
#endif
argv[0])) ?

Ça spawne un process pour rien, et y'a une race condition potentielle si PATH/$PATH change entre le moment le programme est lancé et le moment où tu exécutes ce code
(comment ça, "c'est pas réaliste" ?)

Si tu veux vraiment faire ça, autant le faire proprement avec GetModuleFileName sous Windows, ou /proc/self/exe sous Linux.

Tiens d'ailleurs, en parlant de Linux, il va se passer quoi si l'utilisateur n'a pas le droit "r" sur le fichier exécutable ?

EDIT : Et ton ./1067 est potentiellement foireux si tu crosscompiles, je te laisse chercher pourquoi ^^

J'aime spawnwer des process

Les questions d'endianness sont laissées en exercice au lecteur

Mouais

Zerosquare (./1074) :
Tiens d'ailleurs, en parlant de Linux, il va se passer quoi si l'utilisateur n'a pas le droit "r" sur le fichier exécutable ?

fopen va renvoyer NULL, et tu vas te taper une erreur si ton code a prévu l'erreur ou un SIGSEGV si tu n'y as pas pensé.

Je considère cette idée de concaténer les ressources à la fin de l'exécutable comme un hack totalement crade, non-portable et bogué.

Bref, t'es jaloux.

Je n'ai aucune raison de l'être, parce que Folco a aussi préféré ma solution, beaucoup plus fiable.

le sizeof(int) ?