Format de fichiers - Page 1

J'aimerais connaître, en octets, la structure précise d'un peu tous les fichiers, surtout sous Windows.

Quels octets signifiants quoi se trouvent dans un fichier .exe, qu'est-ce qui le différencie d'un fichier .com,
même chose pour les fichiers .jpg, .bmp et tout, comment est organisée une DLL, un fichier zip,
un fichier personnalisé avec une extension spéciale bref tout.

Je voudrais aussi connaître les fonctions de Windows permettant de récupérer les données d'un fichier, sous Visual C++ par ex. (Utile )

(Je ne veux pas qu'on le dise ici , simplement j'aimerais des références, des sites, bouquins, etc.

google & rtff

les com n'ont pas d'en-tête, les exe si - ou qqch comme ça -

Pour le format BMP, JPG, et autres, tu fais comme tout le monde, tu cherches sur le net...

Et pour lire dans un fichier, tu utilises les fonctions C qui vont bien :
fopen, tu connais ?
fclose ?

bien sur si qqun a trouvé un bon site la dessus, ya pas de raison qu'il ne le mette pas, mais je pense qu'il vaut mieux que tu cherches, et si tu trouves des bons, sites, pkoi ne pas les mettre ici

OK, mais j'ai une chance sur 1000 que ce putain de Google me donne les bonnes infos.
On devrait vraiment concevoir de meilleurs moteurs de recherche, fonctionnant différemment,
et qui trouvent l'info au lieu de la chercher.

si tu t'y connais en théorie des graphs et recherche optimisée, tu devrais savoir que google fait a peu pres ce qu'il y a de mieux pour trouver, le probleme vient pas forcement du moteur mais aussi des pages et de l'utilisateur

Non, le problème c'est la vie.
La théorie de l'emmerdement maximal, si quelquechose peut aller mal,
ça va forcément aller mal.

Bon, j'arrête, je vais me renommer tout de suite en SorrOw^2.

lol
Plus sérieusement, j'ai une fois dû chercher des infos sur le format BMP pour un projet de l'école, j'ai pas mis trop de temps à trouver ce qu'il me fallait...
Seulement, un site te présentera un format, en général pas plusieurs...
Mais un site avec la description de tous les formats, ça peut être un bon challenge

Pour Google (ou AllTheWeb), il suffit de chercher avec comme mots-clés header et l'extension voulue (sauf pour COM qui n'a aucun header).
Tu devrais trouver ton bonheur sans trop de problème, à condition d'avoir tout de même un peu de patience, puisqu'il y aura sans doute beaucoup de page à propos de programmes de lecture ou de conversion.
C'est comme ça que j'ai trouvé il y a 2 ans plein de docs sur le header BMP afin de faire un programme d'affichage en Asm (header que j'avais quasiment totalement décodé tout seul, d'ailleurs ...).

@++

Kevin Kofler :
http://www.wotsit.org/

zut!!
Ca existe, en fait

Ah, ben j'ai bien fait de faire ce topic, ce site est vraiment classe.
Kevin >

Autre chose: j'aimerais TOUT savoir de la programmation Windows, en C/C++ et
en assembleur. Ca ne me fait rien d'avoir des milliards de lignes à lire, ce qui compte
c'est que je veux TOUT.
Quelle solution me proposez-vous ? Avec VB .Net 2002 j'ai la MSDN, je pourrais lire
les parties sur l'utilisation des fonctions pour C++, et faire des listings sous Visual C++ 6.
Qu'en pensez-vous ? SI vous avez mieux j'aimerais que vous me le disiez svp.

-

Ah ça...
Non, bien sûr, mais un peu (beaucoup) de doc pourrait se révéler utile.

Bordel mais apprend à chercher. C'est pas en fonctionnant comme ça que tu vas avancer. J'ai vraiment du mal à m'imaginer que quelqu'un de plus âgé que moi puisse être à ce point . Tu pourrais au moins prendre exemple sur naPO. Lui, au moins, il s'est amélioré.
Et puis tu peux toujours me kicker, ça ne fera que prouver que j'ai (enfin avais puisque je ne pourai plus poster ) raison. Comme le dit le proverbe: "Il n'y a que la vérité qui blesse"...

Si tu répondais au ./13 ?

Ben je répondais au 12
EDIT: D'ailleurs, j'ajouterai que la doc MSDN 2003 est on-line sur le site de M$ et pour l'assembleur tu cherches PC, assembly, etc... idem pour le C/C++

-

Je sais programmer.
Je sais pas chercher.
C'est comme ça, faut pas chercher. (Rime parfaite, un peu reloo, mais...)
Très poétique. #poètpoèt#

-

Bé... faudra bien que j'apprenne, donc.
(Mais gogole me prends vraiment le chou.)

MSDN ne te donnera rien ou presque sur l'assembleur. Ensuite, l'assembleur PC est inutile, il est compliqué, et tu ferais bien mieux d'apprendre à programmer en ASM sur des microcontrôleurs ou des DSPs où c'est utile - dans le cas du PC, ça ne l'est définitivement pas... -
Sinon le C/C++ de la MSDN est orienté... Microsoft, et pas Linux, il y aura des choses qui ne seront pas portables - par exemple la gestion des threads et des sémaphores ainsi que les interfaces qui existent sous MS mais pas sous GCC par ex, pour autant que Kevin m'ait dit la dernière fois que je me posais des questions à ce sujet -

En effet, MSDN est une bonne ressource pour la programmation Win32, mais pour tout le reste, c'est à jeter.

Cela dit, il n'y a malheureusement pas de spécification vraiment portable pour certaines choses (threads et sémaphores en sont de bons exemples). Si on utilise du POSIX, ça tournera au contraire partout sauf sur Windows (sauf avec Cygwin). Donc souvent, il faut du:

#ifdef __WIN32__
// solution Win32 trouvable sur MSDN
#else
// solution POSIX trouvable ailleurs
#endif

(Et s'il vous plaît, utilisez #ifdef __WIN32__ et pas #ifndef __GNUC__ si c'est une histoire de système d'exploitation, et au contraire #ifndef __GNUC__ et pas #ifdef __WIN32__ s'il s'agit d'extensions du compilateur. Les logiciels qui présupposent que __WIN32__==!__GNUC__ (c'est-à-dire que Win32=M$VC) sont très embêtants si on veut les compiler avec MinGW.)

C'est quand qu'ils mettent les semaphores en builtin dans GCC ?

Kevin> C'est pas _WIN32 plutôt que __WIN32__ ?

MinGW définit les 2:

$ gcc -v empty.c
Reading specs from e:/mingw32/bin/../lib/gcc-lib/mingw32/3.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=f77,c++,objc,ada --disable-win32-registry --disable-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1) e:\mingw32\bin\..\lib\gcc-lib\mingw32\3.2\cc1.exe -lang-c -v -iprefix e:\mingw32\bin\../lib/gcc-lib/mingw32/3.2/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__attribute__((x)) empty.c -quiet -dumpbase empty.c -version -o C:\TEMP/ccfE7ggb.s

Je ne crois pas que Visual C++ définisse les deux... Il n'y a pas que GNU/MinGW/GCC et GNU/Linux/GCC sur terre

En tout cas, l'identificateur de plateforme standard sous GCC est __plateforme__ (où plateforme peut être en majuscule ou minuscule malheureusement , la standardisation même à l'intérieur de GCC n'est pas parfaite, mais ce n'est pas étonnant vu le nombre de targets et les conventions différentes utilisés par les compilateurs "concurrents" sur lesquels beaucoup de targets s'orientent), donc __WIN32__ est plus naturel que _WIN32.

Mais le but est justement de distinguer la plateforme par autre chose que le fait que c'est non-GNU, donc si tu utilises une convention interne à GCC, t'es mal barré _WIN32 n'a pas à être plus naturel ou moins naturel, c'est le truc standard pour savoir si on est sous Windows ou pas...

(et d'ailleurs du point de vue de MSVC où c'est _FOOBAR et pas __FOOBAR__, __WIN32__ est tout aussi illogique, alors ça va pas faire avancer les choses )