J'avoue que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
[...] pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.
sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.
Encore, tu m'as perdu. C'est quoi, un tag ID3 ?
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
ça m'étonnerait fort que je ne pourrais pas ouvrir deux
ifstream distincts sur le même fichier.
J'avoue que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
[...] pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.
sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.
Encore, tu m'as perdu. C'est quoi, un tag ID3 ?
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
ça m'étonnerait fort que je ne pourrais pas ouvrir deux
ifstream distincts sur le même fichier.
J'avoue que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
[...] pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.
sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.
Encore, tu m'as perdu. C'est quoi, un tag ID3 ?
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
ça m'étonnerait fort que je ne pourrais pas ouvrir deux
ifstream distincts sur le même fichier.
James Kanze wrote on 31/12/2006 00:32:
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
on désigne généralement par ressources, une donnée structurée,
généralement énumérable, présente dans un ensemble lui aussi st ructuré,
supportant donc les recherches / accès / lecture / écriture par type de
ressource et par identifiant dans chaque type.
pour plein de mauvaises raisons, dont historiques, un fichier quelconque
n'a généralement pas les moyens de stocker des ressources en plus de son
contenu de données - où les "données" sont le texte d'un fichier te xte,
l'image d'un fichier image, etc.
MacOS, à ma connaissance, est le seul OS a disposer d'un file system
permettant la création d'un "resource fork" (cette partie structurée
contenant les rtessources) en plus du "data fork" usuel.
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
ce mode est applicable pour les fichiers clairement structurés, un .exe
contient son bloc d'init, de dépendances (.lib externes), etc, un .mp3
commence par une description de son encodage, le nombre de 'trames',
etc; ainsi on peut coller un peu n'importe quoi à la fin de ces fichiers
(à la fin des 'données' de ces fichiers) sans que cela ne les gène.
l'approche ne peut être identique avec la plupart des fichiers type
document utilisateur, à la fin d'un doc. texte il y a la fin du texte de
ce doc. pas quelque chose d'autre ayant un autre sens, dans un JPG il
n'y a que des blocs taggés et aucune données arbitraires non
correctement taggée ne peut être insérée à la fin; donc ces fic hiers
(hormi sous MacOS) ne peuvent pas fournir de ressources.
sous Java, on part du même principe (seul un stream est généralement
présent et il est soit données, soit ressources) pour définir des
fichiers qui ne contiendront que des ressources (par exemple le dump
d'un java.util.Properties).
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
la plupart font cela pour la même raison (l'absence de ressource qui
permet de typer les données); ainsi un .txt sera toujours ouvert par la
même appli enregistrée pour gérer cette extension - pour comparaiso n,
MacOS enregistre le type (text, jpeg, etc, y compris propriétaire) et un
identifiant d'application, on peut dès lors avoir des fichiers texte A
ouverts par l'application bloc-notes A et des fichiers texte B ouverts
par une autre application B (tandis que les extensions ne servent à
rien; ne servaient MacOS X a du les hériter de BSD).
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permet tre
un traitement systématique du contenu du fichier;
mais même dans ce cas
il peut être simple de générer à la volée les informations sp écifiques
d'un fichier (extraire le tag FFFEh d'un JPEG ou les infos plus riches
d'un JP2) ou impossible de déduire quoique ce soit, quelles infos tirer
d'un fichier texte mis à part le nombre de mots ?
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
2 sources de contenu; faire comme si le fichier était 2 sous-fichiers,
les 2 étant distincts, on peut ouvrir / modifier l'un sans toucher l'au tre.
toutes ces considérations nous amènent largement hors chartre,
James Kanze wrote on 31/12/2006 00:32:
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
on désigne généralement par ressources, une donnée structurée,
généralement énumérable, présente dans un ensemble lui aussi st ructuré,
supportant donc les recherches / accès / lecture / écriture par type de
ressource et par identifiant dans chaque type.
pour plein de mauvaises raisons, dont historiques, un fichier quelconque
n'a généralement pas les moyens de stocker des ressources en plus de son
contenu de données - où les "données" sont le texte d'un fichier te xte,
l'image d'un fichier image, etc.
MacOS, à ma connaissance, est le seul OS a disposer d'un file system
permettant la création d'un "resource fork" (cette partie structurée
contenant les rtessources) en plus du "data fork" usuel.
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
ce mode est applicable pour les fichiers clairement structurés, un .exe
contient son bloc d'init, de dépendances (.lib externes), etc, un .mp3
commence par une description de son encodage, le nombre de 'trames',
etc; ainsi on peut coller un peu n'importe quoi à la fin de ces fichiers
(à la fin des 'données' de ces fichiers) sans que cela ne les gène.
l'approche ne peut être identique avec la plupart des fichiers type
document utilisateur, à la fin d'un doc. texte il y a la fin du texte de
ce doc. pas quelque chose d'autre ayant un autre sens, dans un JPG il
n'y a que des blocs taggés et aucune données arbitraires non
correctement taggée ne peut être insérée à la fin; donc ces fic hiers
(hormi sous MacOS) ne peuvent pas fournir de ressources.
sous Java, on part du même principe (seul un stream est généralement
présent et il est soit données, soit ressources) pour définir des
fichiers qui ne contiendront que des ressources (par exemple le dump
d'un java.util.Properties).
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
la plupart font cela pour la même raison (l'absence de ressource qui
permet de typer les données); ainsi un .txt sera toujours ouvert par la
même appli enregistrée pour gérer cette extension - pour comparaiso n,
MacOS enregistre le type (text, jpeg, etc, y compris propriétaire) et un
identifiant d'application, on peut dès lors avoir des fichiers texte A
ouverts par l'application bloc-notes A et des fichiers texte B ouverts
par une autre application B (tandis que les extensions ne servent à
rien; ne servaient MacOS X a du les hériter de BSD).
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permet tre
un traitement systématique du contenu du fichier;
mais même dans ce cas
il peut être simple de générer à la volée les informations sp écifiques
d'un fichier (extraire le tag FFFEh d'un JPEG ou les infos plus riches
d'un JP2) ou impossible de déduire quoique ce soit, quelles infos tirer
d'un fichier texte mis à part le nombre de mots ?
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
2 sources de contenu; faire comme si le fichier était 2 sous-fichiers,
les 2 étant distincts, on peut ouvrir / modifier l'un sans toucher l'au tre.
toutes ces considérations nous amènent largement hors chartre,
James Kanze wrote on 31/12/2006 00:32:
C'est quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances.
on désigne généralement par ressources, une donnée structurée,
généralement énumérable, présente dans un ensemble lui aussi st ructuré,
supportant donc les recherches / accès / lecture / écriture par type de
ressource et par identifiant dans chaque type.
pour plein de mauvaises raisons, dont historiques, un fichier quelconque
n'a généralement pas les moyens de stocker des ressources en plus de son
contenu de données - où les "données" sont le texte d'un fichier te xte,
l'image d'un fichier image, etc.
MacOS, à ma connaissance, est le seul OS a disposer d'un file system
permettant la création d'un "resource fork" (cette partie structurée
contenant les rtessources) en plus du "data fork" usuel.
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
ce mode est applicable pour les fichiers clairement structurés, un .exe
contient son bloc d'init, de dépendances (.lib externes), etc, un .mp3
commence par une description de son encodage, le nombre de 'trames',
etc; ainsi on peut coller un peu n'importe quoi à la fin de ces fichiers
(à la fin des 'données' de ces fichiers) sans que cela ne les gène.
l'approche ne peut être identique avec la plupart des fichiers type
document utilisateur, à la fin d'un doc. texte il y a la fin du texte de
ce doc. pas quelque chose d'autre ayant un autre sens, dans un JPG il
n'y a que des blocs taggés et aucune données arbitraires non
correctement taggée ne peut être insérée à la fin; donc ces fic hiers
(hormi sous MacOS) ne peuvent pas fournir de ressources.
sous Java, on part du même principe (seul un stream est généralement
présent et il est soit données, soit ressources) pour définir des
fichiers qui ne contiendront que des ressources (par exemple le dump
d'un java.util.Properties).
Je sais aussi que la plupart des gestionnaires de fenêtres,
aussi bien Windows que KDE, CDE, etc. sous X, ont un système
d'associer des actions à des types de fichiers, où en général
le « type », c'est déterminé par le suffixe du nom du fichier.
la plupart font cela pour la même raison (l'absence de ressource qui
permet de typer les données); ainsi un .txt sera toujours ouvert par la
même appli enregistrée pour gérer cette extension - pour comparaiso n,
MacOS enregistre le type (text, jpeg, etc, y compris propriétaire) et un
identifiant d'application, on peut dès lors avoir des fichiers texte A
ouverts par l'application bloc-notes A et des fichiers texte B ouverts
par une autre application B (tandis que les extensions ne servent à
rien; ne servaient MacOS X a du les hériter de BSD).
Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permet tre
un traitement systématique du contenu du fichier;
mais même dans ce cas
il peut être simple de générer à la volée les informations sp écifiques
d'un fichier (extraire le tag FFFEh d'un JPEG ou les infos plus riches
d'un JP2) ou impossible de déduire quoique ce soit, quelles infos tirer
d'un fichier texte mis à part le nombre de mots ?
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ?
2 sources de contenu; faire comme si le fichier était 2 sous-fichiers,
les 2 étant distincts, on peut ouvrir / modifier l'un sans toucher l'au tre.
toutes ces considérations nous amènent largement hors chartre,
Tu as dis dans ton message news:458c5b81$0$25929$
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
À partir de là, ça ne sert à rien d'écrire 3 pages pour tenter une
pirouette, parce qu'au lieu de sauver ta fierté, tu te ridicules
publiquement encore davantage.
Et personnellement, ce genre de joutes stériles ne m'intéressent pas.
Tu as dis dans ton message news:458c5b81$0$25929$ba4acef3@news.orange.fr
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
À partir de là, ça ne sert à rien d'écrire 3 pages pour tenter une
pirouette, parce qu'au lieu de sauver ta fierté, tu te ridicules
publiquement encore davantage.
Et personnellement, ce genre de joutes stériles ne m'intéressent pas.
Tu as dis dans ton message news:458c5b81$0$25929$
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
À partir de là, ça ne sert à rien d'écrire 3 pages pour tenter une
pirouette, parce qu'au lieu de sauver ta fierté, tu te ridicules
publiquement encore davantage.
Et personnellement, ce genre de joutes stériles ne m'intéressent pas.
Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
Et évidemment, ça se laisse facilement *simuler* sous Windows ou
sous Unix [...]
[...] chaque programme fait à sa guise, et les
programmes généralistes (genre copy) n'y voit rien, et ne savent
pas traiter les informations supplémentaires.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
Et évidemment, ça se laisse facilement *simuler* sous Windows ou
sous Unix [...]
[...] chaque programme fait à sa guise, et les
programmes généralistes (genre copy) n'y voit rien, et ne savent
pas traiter les informations supplémentaires.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
Et évidemment, ça se laisse facilement *simuler* sous Windows ou
sous Unix [...]
[...] chaque programme fait à sa guise, et les
programmes généralistes (genre copy) n'y voit rien, et ne savent
pas traiter les informations supplémentaires.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour permettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
John Deuf wrote on 01/01/2007 19:47:Tu as dis dans ton message news:458c5b81$0$25929$
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
en effet.
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
le système NTFS (pas le "fs windows", pour ton info, il y a, au moins,
sous windows FAT12, FAT16, FAT32, NTFS, sans parler de tous les systèmes
pour CD/DVD) gère des pseudo-flux (pas **2** clairement définis, auta nt
de merdiers que tu en veux!)
John Deuf wrote on 01/01/2007 19:47:
Tu as dis dans ton message news:458c5b81$0$25929$ba4acef3@news.orange.fr
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
en effet.
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
le système NTFS (pas le "fs windows", pour ton info, il y a, au moins,
sous windows FAT12, FAT16, FAT32, NTFS, sans parler de tous les systèmes
pour CD/DVD) gère des pseudo-flux (pas **2** clairement définis, auta nt
de merdiers que tu en veux!)
John Deuf wrote on 01/01/2007 19:47:Tu as dis dans ton message news:458c5b81$0$25929$
"le file system windows ne sait pas (nativement) gérer 2 flux pour un
fichier."
en effet.
C'est faux.
Le file system windows sait nativement gérer 2 flux pour un fichier.
le système NTFS (pas le "fs windows", pour ton info, il y a, au moins,
sous windows FAT12, FAT16, FAT32, NTFS, sans parler de tous les systèmes
pour CD/DVD) gère des pseudo-flux (pas **2** clairement définis, auta nt
de merdiers que tu en veux!)
James Kanze wrote on 01/01/2007 17:36:Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
c'est en effet une caractéristique, car c'est généralement pas du c ode
exécutable (la aussi seul - à ma connaissance - Mac OS définisait d es
resource code, une extension (grahique par exemple) du système pouvant
se présenter comme un fichier contenant, par exemple, une resource de
type 'WDEF' lorsqu'elle contient un code dessinant une fenêtre (une
"window definition"), le système s'auto-patchant avec le code de cette
resource.
hormi cette anecdote, les resources d'aujourd'hui sont des quasi-POD,
elles sont stockées comme dumpées sans description explicite de la
structure hormi le type de la resource (eg 'MENU', 'STRING', ...).
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
oui pour un (vrai) resource fork, comme pour le BLOB de ressources
attachées à un binaire. une meta-information évidente est par exemp le
l'icone sous lequel le fichier est représenté par un gestionnaire de
fichiers.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
windows a inventé le registre pour ces besoins propres; des développe urs
ont trouvé génial d'aller y même tout et n'importe quoi pour s'év iter la
peine de gérer leurs fichiers de paramètres; je ne me rappelle pas d' une
évangélisation forcenée de MS pour faire cela (même si les classe s MFC,
squelette d'applications codées à la souris, stockent justement les
paramètres dans le registre).
tout développeur a encore la possibilité et le droit (s'il s'en donne la
peine) de gérer son propre .parameters (ou autre).
note que MS encourage maintenant de stocker les paramètres applicatifs
dans un dossier prévu pour; cela ne change pas grand chose si les
développeurs ne se disciplinent pas.
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
ce type de gestion n'est pas confusante pour l'utilisateur, un fichier a
pour attribut son type (généralement constant) et un créateur, ce
créateur correspond à l'appli initialement créé pour la créatio n (et si
j'utilise telle appli pour créer un document, je voudrais surement
l'utiliser aussi pour le modifier) ou celui d'une autre appli ayant
réengistré le fichier après modif., dans ce cas j'ai explicitement
ouvert le fichier avec cette 2nd appli (je n'ai pas pu double-cliquer
dessus).
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour per mettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
j'entendais pour déterminer quel type de traitement est réalisable,
parce que en phase avec les questions / attentes types de l'utilisateur,
par exemple "quelle est la taille en pixels de cette image".
tu as raison de souligner que même en terrain a priori balisé il exis te
toujours des pièges et exceptions diverses.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
là c'est la face nord!
tu peux très facilement débugger un code construit depuis l'IDE via un
projet créé par cet IDE, par contre partir d'un make (et j'imagine un
'make' gnu-like, pas le nmake MS) sera bcp plus ardu; à défaut du
débuggeur de l'IDE tu pourras utiliser 'windbg.exe', dans les 2 cas
(celui de Studio reste utilisable en s'attachant au process) il te
faudra renseigner moultes path vers les src, libs etc et bien sur que
des infos de debug au bon format (COFF ou propriétaire MS) aient ét é
générées.
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
il peut être plus simple de lancer d'abord le débuggeur puis l'appli
sous son contrôle (avec windbg par exemple) ainsi si l'appli crashe le
debuggeur prendra la contrôle permettant d'auditer (la encore sous
réserve de fournir tous les path et de disposer d'info de débug, sinon
c'est dump asm strict).
j'essayerais bien le manip, mais moi c'est pour l'install propre de gcc
que je coince :)
James Kanze wrote on 01/01/2007 17:36:
Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
c'est en effet une caractéristique, car c'est généralement pas du c ode
exécutable (la aussi seul - à ma connaissance - Mac OS définisait d es
resource code, une extension (grahique par exemple) du système pouvant
se présenter comme un fichier contenant, par exemple, une resource de
type 'WDEF' lorsqu'elle contient un code dessinant une fenêtre (une
"window definition"), le système s'auto-patchant avec le code de cette
resource.
hormi cette anecdote, les resources d'aujourd'hui sont des quasi-POD,
elles sont stockées comme dumpées sans description explicite de la
structure hormi le type de la resource (eg 'MENU', 'STRING', ...).
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
oui pour un (vrai) resource fork, comme pour le BLOB de ressources
attachées à un binaire. une meta-information évidente est par exemp le
l'icone sous lequel le fichier est représenté par un gestionnaire de
fichiers.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
windows a inventé le registre pour ces besoins propres; des développe urs
ont trouvé génial d'aller y même tout et n'importe quoi pour s'év iter la
peine de gérer leurs fichiers de paramètres; je ne me rappelle pas d' une
évangélisation forcenée de MS pour faire cela (même si les classe s MFC,
squelette d'applications codées à la souris, stockent justement les
paramètres dans le registre).
tout développeur a encore la possibilité et le droit (s'il s'en donne la
peine) de gérer son propre .parameters (ou autre).
note que MS encourage maintenant de stocker les paramètres applicatifs
dans un dossier prévu pour; cela ne change pas grand chose si les
développeurs ne se disciplinent pas.
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
ce type de gestion n'est pas confusante pour l'utilisateur, un fichier a
pour attribut son type (généralement constant) et un créateur, ce
créateur correspond à l'appli initialement créé pour la créatio n (et si
j'utilise telle appli pour créer un document, je voudrais surement
l'utiliser aussi pour le modifier) ou celui d'une autre appli ayant
réengistré le fichier après modif., dans ce cas j'ai explicitement
ouvert le fichier avec cette 2nd appli (je n'ai pas pu double-cliquer
dessus).
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour per mettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
j'entendais pour déterminer quel type de traitement est réalisable,
parce que en phase avec les questions / attentes types de l'utilisateur,
par exemple "quelle est la taille en pixels de cette image".
tu as raison de souligner que même en terrain a priori balisé il exis te
toujours des pièges et exceptions diverses.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
là c'est la face nord!
tu peux très facilement débugger un code construit depuis l'IDE via un
projet créé par cet IDE, par contre partir d'un make (et j'imagine un
'make' gnu-like, pas le nmake MS) sera bcp plus ardu; à défaut du
débuggeur de l'IDE tu pourras utiliser 'windbg.exe', dans les 2 cas
(celui de Studio reste utilisable en s'attachant au process) il te
faudra renseigner moultes path vers les src, libs etc et bien sur que
des infos de debug au bon format (COFF ou propriétaire MS) aient ét é
générées.
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
il peut être plus simple de lancer d'abord le débuggeur puis l'appli
sous son contrôle (avec windbg par exemple) ainsi si l'appli crashe le
debuggeur prendra la contrôle permettant d'auditer (la encore sous
réserve de fournir tous les path et de disposer d'info de débug, sinon
c'est dump asm strict).
j'essayerais bien le manip, mais moi c'est pour l'install propre de gcc
que je coince :)
James Kanze wrote on 01/01/2007 17:36:Voilà ce qui m'explique aussi le nom. J'avais entendu parler de
cette possibilité pour les fichiers .exe sous Windows, mais je
ne le voyais pas réelement comme quelque chose de généralisable.
Au fond, je le concevais comme une partie du programme, mais une
partie qui n'a pas été traduite en langage machine.
c'est en effet une caractéristique, car c'est généralement pas du c ode
exécutable (la aussi seul - à ma connaissance - Mac OS définisait d es
resource code, une extension (grahique par exemple) du système pouvant
se présenter comme un fichier contenant, par exemple, une resource de
type 'WDEF' lorsqu'elle contient un code dessinant une fenêtre (une
"window definition"), le système s'auto-patchant avec le code de cette
resource.
hormi cette anecdote, les resources d'aujourd'hui sont des quasi-POD,
elles sont stockées comme dumpées sans description explicite de la
structure hormi le type de la resource (eg 'MENU', 'STRING', ...).
Mais je ne l'envisagais qu'étant des données qu'utilisent le
programme même. Si j'ai bien compris, ces « resource fork »
peuvent aussi contenir des méta-informations, qui n'intéressent
pas le programme même (surtout qu'elles s'attachent à des
fichiers qui ne sont pas des programmes), mais plutôt aux
programmes qui manipulent le fichier.
oui pour un (vrai) resource fork, comme pour le BLOB de ressources
attachées à un binaire. une meta-information évidente est par exemp le
l'icone sous lequel le fichier est représenté par un gestionnaire de
fichiers.
Et plus, Windows
a ajouté le « register », qui éloigne les informations encore
plus d'où on veut les avoir.)
windows a inventé le registre pour ces besoins propres; des développe urs
ont trouvé génial d'aller y même tout et n'importe quoi pour s'év iter la
peine de gérer leurs fichiers de paramètres; je ne me rappelle pas d' une
évangélisation forcenée de MS pour faire cela (même si les classe s MFC,
squelette d'applications codées à la souris, stockent justement les
paramètres dans le registre).
tout développeur a encore la possibilité et le droit (s'il s'en donne la
peine) de gérer son propre .parameters (ou autre).
note que MS encourage maintenant de stocker les paramètres applicatifs
dans un dossier prévu pour; cela ne change pas grand chose si les
développeurs ne se disciplinent pas.
[...]
Je me démande si MacOS n'y va pas trop loin. Je veux bien que le
fichier enregistre le type d'application dont il a besoin, par
exemple, un éditeur de texte. Mais je veux bien que ce soit moi
qui le choisi ; actuellement, sur ma machine Windows, les
fichiers .html sont ouverts avec Firefox et non IE, et les
fichiers .cc/.cpp/etc. avec gvim, et non Visual Studios.
ce type de gestion n'est pas confusante pour l'utilisateur, un fichier a
pour attribut son type (généralement constant) et un créateur, ce
créateur correspond à l'appli initialement créé pour la créatio n (et si
j'utilise telle appli pour créer un document, je voudrais surement
l'utiliser aussi pour le modifier) ou celui d'une autre appli ayant
réengistré le fichier après modif., dans ce cas j'ai explicitement
ouvert le fichier avec cette 2nd appli (je n'ai pas pu double-cliquer
dessus).
oui et non; cette extension (sur WinXXX, certains linux, ...) sert
d'identifiant unique du type de fichier, certaines de ces extensions
sont assez répandues, quasi-normalisées (.txt, .jpg, ...) pour per mettre
un traitement systématique du contenu du fichier;
Oui et non. Une information si le .txt contient du UTF-8 ou du
ISO 8859-1 ne serait pas mal, par exemple.
j'entendais pour déterminer quel type de traitement est réalisable,
parce que en phase avec les questions / attentes types de l'utilisateur,
par exemple "quelle est la taille en pixels de cette image".
tu as raison de souligner que même en terrain a priori balisé il exis te
toujours des pièges et exceptions diverses.
[...] Et bien que je me sers du compilateur VC++, je ne
sais pas encore comment invoquer le débogueur.
F5 pour lancer l'appli sous controle debug (si le project est en mode
debug); puis F10 / F11 pour tracer.
Quel « project » ? J'ai un répertoire avec un tas de fichiers
..cc, et un fichier make. Un fichier make qui exige GNU make,
d'ailleurs. [...]
là c'est la face nord!
tu peux très facilement débugger un code construit depuis l'IDE via un
projet créé par cet IDE, par contre partir d'un make (et j'imagine un
'make' gnu-like, pas le nmake MS) sera bcp plus ardu; à défaut du
débuggeur de l'IDE tu pourras utiliser 'windbg.exe', dans les 2 cas
(celui de Studio reste utilisable en s'attachant au process) il te
faudra renseigner moultes path vers les src, libs etc et bien sur que
des infos de debug au bon format (COFF ou propriétaire MS) aient ét é
générées.
Quand j'ai un crash du programme, le système me donne bien
l'option d'entrer dans le débogueur. Mais là, je n'ai que du hex
et de l'assembleur, et je ne sais pas entrer dans le débogueur
sans que le programme crashe. [...]
il peut être plus simple de lancer d'abord le débuggeur puis l'appli
sous son contrôle (avec windbg par exemple) ainsi si l'appli crashe le
debuggeur prendra la contrôle permettant d'auditer (la encore sous
réserve de fournir tous les path et de disposer d'info de débug, sinon
c'est dump asm strict).
j'essayerais bien le manip, mais moi c'est pour l'install propre de gcc
que je coince :)
Et pour ne pas être hors chartre ici : les flux C++ ne savent
pas accéder à des « sous-fichiers », branches, forks ou
quoiqu'ils s'appellent.
(Je n'aime pas trop la façon que tu as
formulé l'énoncée. Pour un naïf comme moi, quand je lis le mot
« flux » dans ce forum, j'entends automatiquement un istream
ou un ostream -- ou vraiment à la rigueur, un FILE*.)
Plus intéressant, dans une contexte professionnelle, les
systèmes de fichiers sont souvent montés depuis une autre
machine.
Donc, au travail, la plupart des fichiers sur ma
machine Windows sont en fait des fichiers montés NFS, et chez
moi, je fais énormement utilisation des fichiers montés SMB (à
partir d'une machine Linux).
A priori, quand j'entends
« le file system windows », j'entends SMB, de même quand
j'entends « le file system Unix », j'entends NFS (et non le
système local sous Solaris ou sous Linux). La question est donc,
est-ce que SMB supporte c'est méta-informations ?
Et pour ne pas être hors chartre ici : les flux C++ ne savent
pas accéder à des « sous-fichiers », branches, forks ou
quoiqu'ils s'appellent.
(Je n'aime pas trop la façon que tu as
formulé l'énoncée. Pour un naïf comme moi, quand je lis le mot
« flux » dans ce forum, j'entends automatiquement un istream
ou un ostream -- ou vraiment à la rigueur, un FILE*.)
Plus intéressant, dans une contexte professionnelle, les
systèmes de fichiers sont souvent montés depuis une autre
machine.
Donc, au travail, la plupart des fichiers sur ma
machine Windows sont en fait des fichiers montés NFS, et chez
moi, je fais énormement utilisation des fichiers montés SMB (à
partir d'une machine Linux).
A priori, quand j'entends
« le file system windows », j'entends SMB, de même quand
j'entends « le file system Unix », j'entends NFS (et non le
système local sous Solaris ou sous Linux). La question est donc,
est-ce que SMB supporte c'est méta-informations ?
Et pour ne pas être hors chartre ici : les flux C++ ne savent
pas accéder à des « sous-fichiers », branches, forks ou
quoiqu'ils s'appellent.
(Je n'aime pas trop la façon que tu as
formulé l'énoncée. Pour un naïf comme moi, quand je lis le mot
« flux » dans ce forum, j'entends automatiquement un istream
ou un ostream -- ou vraiment à la rigueur, un FILE*.)
Plus intéressant, dans une contexte professionnelle, les
systèmes de fichiers sont souvent montés depuis une autre
machine.
Donc, au travail, la plupart des fichiers sur ma
machine Windows sont en fait des fichiers montés NFS, et chez
moi, je fais énormement utilisation des fichiers montés SMB (à
partir d'une machine Linux).
A priori, quand j'entends
« le file system windows », j'entends SMB, de même quand
j'entends « le file system Unix », j'entends NFS (et non le
système local sous Solaris ou sous Linux). La question est donc,
est-ce que SMB supporte c'est méta-informations ?
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
Le dimanche 31 décembre 2006 à 21:08:24, Sylvain a écrit dans
fr.comp.lang.c++ :pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
Non. Les ressources d'un exé sont dans une section de cet exé dûment
déclarée (.rsrc), parmi les autres sections (.code, .edata, .idata,
..bss, etc.)
Le dimanche 31 décembre 2006 à 21:08:24, Sylvain a écrit dans
fr.comp.lang.c++ :
pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
Non. Les ressources d'un exé sont dans une section de cet exé dûment
déclarée (.rsrc), parmi les autres sections (.code, .edata, .idata,
..bss, etc.)
Le dimanche 31 décembre 2006 à 21:08:24, Sylvain a écrit dans
fr.comp.lang.c++ :pour la majorité des OS, dont WinXXX, les ressources sont simplement
collées à la fin des données. pour un exec. tjrs sous WinXXX les
ressources d'IHM telles menus, fenetres, dialogues et 'version' sont
ainsi collées au bout du fichier.
Non. Les ressources d'un exé sont dans une section de cet exé dûment
déclarée (.rsrc), parmi les autres sections (.code, .edata, .idata,
..bss, etc.)
