Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en
pratique pas de limite de l'espace d'adressage).
64 bits d'espace d'adresse ou 64 bits sur le bus de données ?
Le premier. Le second n'a rien à voir avec le sujet, on s'en moque. Ainsi
les machines modernes x86-32 ont souvent des bus de données sur 36 bits
(actifs), mais cela est sans effet sur les processus.
D'ailleur en réalité les cpu amd64 n'ont que 48 ou 52 bits (je ne sais
Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en
pratique pas de limite de l'espace d'adressage).
64 bits d'espace d'adresse ou 64 bits sur le bus de données ?
Le premier. Le second n'a rien à voir avec le sujet, on s'en moque. Ainsi
les machines modernes x86-32 ont souvent des bus de données sur 36 bits
(actifs), mais cela est sans effet sur les processus.
D'ailleur en réalité les cpu amd64 n'ont que 48 ou 52 bits (je ne sais
Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en
pratique pas de limite de l'espace d'adressage).
64 bits d'espace d'adresse ou 64 bits sur le bus de données ?
Le premier. Le second n'a rien à voir avec le sujet, on s'en moque. Ainsi
les machines modernes x86-32 ont souvent des bus de données sur 36 bits
(actifs), mais cela est sans effet sur les processus.
D'ailleur en réalité les cpu amd64 n'ont que 48 ou 52 bits (je ne sais
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
Mais quel est le groupe adapté à cette discussion ?
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
Mais quel est le groupe adapté à cette discussion ?
Et cet espace est propre à chaque process qui en dispose à volonté
Non, mais entrer dans les détails n'est pas le sujet de ce groupe.
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
Mais quel est le groupe adapté à cette discussion ?
[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Cela dit, ils peuvent être partagés avec d'autres programes.
mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
En news:47b7103f$0$31947$, Papouille va escriure:[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Intel n'est pas à ma connaissance la bonne source pour le modèle de
programmation Win32. Le modèle défini par Intel est beaucoup plus basique,
Microsoft n'a retenu qu'une partie de ce qui est possible de faire avec
l'architecture x86 (dont l'espace d'adressage virtuel fait 45 bits pour
x86-32). Et par ailleurs Win32 fonctionne (fonctionnait) aussi avec d'autres
architectures non-Intel...
Par ailleurs, ce que je voulais dire (entre autres cas) est qu'il est
possible dans certaines implémentations de Win32 (en particulier Win32c)
d'avoir des parties de l'espace d'adressage partagées (cela se fait avec des
alias de PDE si vous lisez la doc. Intel). Dans cette catégorie
d'implémentation, une partie de l'espace est réservée pour que le système
permette l'accès automatique depuis tous les processus à certains objets.
Évidemment, ces objets sont convenablement protégés (ou devraient l'être).
En très très gros, c'est analogue à ce que Linus a implémenté dans le
système de fichiers /proc; ou la zone user dans Unix.
Autre cas, si vous chargez dans votre programme une bibliothèque dynamique
non relogeable (c'est pas complètement légal avec Win32, mais on peut le
faire, il « suffit » de supprimer les informations COFF de déménagement),
alors vous contraignez l'espace d'adressage du processus d'une manière qui
échappe au programme.
Par extension, si vous faites appel à des services fournis par des
bibliothèques dynamiques indépendantes (à commencer par la bibliothèque C si
vous la partagez, ce qui est la manière naturelle de faire), vous vous
obligez à suivre les règles (ou à utilisez des règles compatibles) du «
gestionnaire de mémoire » en ce qui concerne l'espace d'adressage. C'est
pour cela qu'il est difficile de faire communiquer entre elles des
bibliothèques écrites avec des langages différents, chacune assume les
règles de son propre gestionnaire de mémoire, qui se considère seul au
monde... et GetMem(p, 228) suivi de free(p), cela ne va pas marcher!Cela dit, ils peuvent être partagés avec d'autres programes.
Je crois qu'il y a une différence entre ce à quoi vous semblez faire
allusion, et ce que j'ai décrit ci-dessus.
Si je comprend votre idée, vous parlez des parties de l'espace qui sont
disponibles dans plusieurs processus (cela se fait avec des alias de PTE si
vous lisez la doc. Intel). En général, cela est la conséquence d'une action
du programme (VirtualAlloc ou MapViewOfFile avec les paramètres qui vont
bien).
Je parlais quant à moi de parties de l'espace indisponible pour les actions
volontaires du programme, mais qui peuvent être référencées et contenir
certaines données accessibles au programme.mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
Ma remarque visait le point particulier ci-dessus (le processus peut faire
libre usage de son espace d'adressage), qui n'a rien à voir avec le C à mon
avis.
Si vous voulez parlez de l'architecture des programmes Windows tels
qu'implémentés sur x86 (IA32 selon la nomenclature Intel), je pense que
fr.comp.ms-windows.programmation est la plus à même de couvrir ce sujet ; je
ne suis pas habituellement ce groupe, donc je n'ai pas d'avis sur le fait de
savoir si ce genre de questions seront ou pas discutées de manière adéquate
(par contre je sais qu'il y a des réguliers avec un bon niveau dans ce
groupe-là, car ils postent ou postaient parfois ici, par exemple sur des
questions analogues à la vôtre.)
fr.comp.sys.pc est l'autre alternative, mais je crains qu'une question trop
orientée Windows soit mal accueillie (c'est une litote, évidemment.)
Antoine
En news:47b7103f$0$31947$426a74cc@news.free.fr, Papouille va escriure:
[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Intel n'est pas à ma connaissance la bonne source pour le modèle de
programmation Win32. Le modèle défini par Intel est beaucoup plus basique,
Microsoft n'a retenu qu'une partie de ce qui est possible de faire avec
l'architecture x86 (dont l'espace d'adressage virtuel fait 45 bits pour
x86-32). Et par ailleurs Win32 fonctionne (fonctionnait) aussi avec d'autres
architectures non-Intel...
Par ailleurs, ce que je voulais dire (entre autres cas) est qu'il est
possible dans certaines implémentations de Win32 (en particulier Win32c)
d'avoir des parties de l'espace d'adressage partagées (cela se fait avec des
alias de PDE si vous lisez la doc. Intel). Dans cette catégorie
d'implémentation, une partie de l'espace est réservée pour que le système
permette l'accès automatique depuis tous les processus à certains objets.
Évidemment, ces objets sont convenablement protégés (ou devraient l'être).
En très très gros, c'est analogue à ce que Linus a implémenté dans le
système de fichiers /proc; ou la zone user dans Unix.
Autre cas, si vous chargez dans votre programme une bibliothèque dynamique
non relogeable (c'est pas complètement légal avec Win32, mais on peut le
faire, il « suffit » de supprimer les informations COFF de déménagement),
alors vous contraignez l'espace d'adressage du processus d'une manière qui
échappe au programme.
Par extension, si vous faites appel à des services fournis par des
bibliothèques dynamiques indépendantes (à commencer par la bibliothèque C si
vous la partagez, ce qui est la manière naturelle de faire), vous vous
obligez à suivre les règles (ou à utilisez des règles compatibles) du «
gestionnaire de mémoire » en ce qui concerne l'espace d'adressage. C'est
pour cela qu'il est difficile de faire communiquer entre elles des
bibliothèques écrites avec des langages différents, chacune assume les
règles de son propre gestionnaire de mémoire, qui se considère seul au
monde... et GetMem(p, 228) suivi de free(p), cela ne va pas marcher!
Cela dit, ils peuvent être partagés avec d'autres programes.
Je crois qu'il y a une différence entre ce à quoi vous semblez faire
allusion, et ce que j'ai décrit ci-dessus.
Si je comprend votre idée, vous parlez des parties de l'espace qui sont
disponibles dans plusieurs processus (cela se fait avec des alias de PTE si
vous lisez la doc. Intel). En général, cela est la conséquence d'une action
du programme (VirtualAlloc ou MapViewOfFile avec les paramètres qui vont
bien).
Je parlais quant à moi de parties de l'espace indisponible pour les actions
volontaires du programme, mais qui peuvent être référencées et contenir
certaines données accessibles au programme.
mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
Ma remarque visait le point particulier ci-dessus (le processus peut faire
libre usage de son espace d'adressage), qui n'a rien à voir avec le C à mon
avis.
Si vous voulez parlez de l'architecture des programmes Windows tels
qu'implémentés sur x86 (IA32 selon la nomenclature Intel), je pense que
fr.comp.ms-windows.programmation est la plus à même de couvrir ce sujet ; je
ne suis pas habituellement ce groupe, donc je n'ai pas d'avis sur le fait de
savoir si ce genre de questions seront ou pas discutées de manière adéquate
(par contre je sais qu'il y a des réguliers avec un bon niveau dans ce
groupe-là, car ils postent ou postaient parfois ici, par exemple sur des
questions analogues à la vôtre.)
fr.comp.sys.pc est l'autre alternative, mais je crains qu'une question trop
orientée Windows soit mal accueillie (c'est une litote, évidemment.)
Antoine
En news:47b7103f$0$31947$, Papouille va escriure:[ L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go ]
Et cet espace est propre à chaque process qui en dispose à volonté
Non,
D'après Intel, si : je cite "each program (or task) is given its own
table of segment descriptors and its own segments."
Intel n'est pas à ma connaissance la bonne source pour le modèle de
programmation Win32. Le modèle défini par Intel est beaucoup plus basique,
Microsoft n'a retenu qu'une partie de ce qui est possible de faire avec
l'architecture x86 (dont l'espace d'adressage virtuel fait 45 bits pour
x86-32). Et par ailleurs Win32 fonctionne (fonctionnait) aussi avec d'autres
architectures non-Intel...
Par ailleurs, ce que je voulais dire (entre autres cas) est qu'il est
possible dans certaines implémentations de Win32 (en particulier Win32c)
d'avoir des parties de l'espace d'adressage partagées (cela se fait avec des
alias de PDE si vous lisez la doc. Intel). Dans cette catégorie
d'implémentation, une partie de l'espace est réservée pour que le système
permette l'accès automatique depuis tous les processus à certains objets.
Évidemment, ces objets sont convenablement protégés (ou devraient l'être).
En très très gros, c'est analogue à ce que Linus a implémenté dans le
système de fichiers /proc; ou la zone user dans Unix.
Autre cas, si vous chargez dans votre programme une bibliothèque dynamique
non relogeable (c'est pas complètement légal avec Win32, mais on peut le
faire, il « suffit » de supprimer les informations COFF de déménagement),
alors vous contraignez l'espace d'adressage du processus d'une manière qui
échappe au programme.
Par extension, si vous faites appel à des services fournis par des
bibliothèques dynamiques indépendantes (à commencer par la bibliothèque C si
vous la partagez, ce qui est la manière naturelle de faire), vous vous
obligez à suivre les règles (ou à utilisez des règles compatibles) du «
gestionnaire de mémoire » en ce qui concerne l'espace d'adressage. C'est
pour cela qu'il est difficile de faire communiquer entre elles des
bibliothèques écrites avec des langages différents, chacune assume les
règles de son propre gestionnaire de mémoire, qui se considère seul au
monde... et GetMem(p, 228) suivi de free(p), cela ne va pas marcher!Cela dit, ils peuvent être partagés avec d'autres programes.
Je crois qu'il y a une différence entre ce à quoi vous semblez faire
allusion, et ce que j'ai décrit ci-dessus.
Si je comprend votre idée, vous parlez des parties de l'espace qui sont
disponibles dans plusieurs processus (cela se fait avec des alias de PTE si
vous lisez la doc. Intel). En général, cela est la conséquence d'une action
du programme (VirtualAlloc ou MapViewOfFile avec les paramètres qui vont
bien).
Je parlais quant à moi de parties de l'espace indisponible pour les actions
volontaires du programme, mais qui peuvent être référencées et contenir
certaines données accessibles au programme.mais entrer dans les détails n'est pas le sujet de ce groupe.
Mais quel est le groupe adapté à cette discussion ?
Ma remarque visait le point particulier ci-dessus (le processus peut faire
libre usage de son espace d'adressage), qui n'a rien à voir avec le C à mon
avis.
Si vous voulez parlez de l'architecture des programmes Windows tels
qu'implémentés sur x86 (IA32 selon la nomenclature Intel), je pense que
fr.comp.ms-windows.programmation est la plus à même de couvrir ce sujet ; je
ne suis pas habituellement ce groupe, donc je n'ai pas d'avis sur le fait de
savoir si ce genre de questions seront ou pas discutées de manière adéquate
(par contre je sais qu'il y a des réguliers avec un bon niveau dans ce
groupe-là, car ils postent ou postaient parfois ici, par exemple sur des
questions analogues à la vôtre.)
fr.comp.sys.pc est l'autre alternative, mais je crains qu'une question trop
orientée Windows soit mal accueillie (c'est une litote, évidemment.)
Antoine