A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit
int=E9ressant. En effet, utiliser des DLL fait des programmes plus
petits (entre autres) mais induit d'enormes contraintes au niveau de la
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...
Cela fait longtemps que j'ai fait de l'assembleur avec la syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de 10017198h est *virtuelle* et *PAS* physique.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que Jean-Marc le sait aussi.)
Chaque processus qui lira cette adresse virtuelle accédera à sa copie de la variable en mémoire physique et désignée par cette adresse absolue virtuelle.
Oui, mais chaque processus accédera bien à la même adresse à l'intérieur de son espace d'adressage.
Il faut donc que i ait la même adresse dans tous les process si le code est réellement partagé.
Et bien non.
À l'intérieur de son espace d'adressage, oui. Si l'adresse est 0x10017168, il faut bien s'arranger que cette adresse soit disponible dans l'espace d'adressage de tous les processus qui se servent de la DLL. Chose qui est loin d'être évidente.
Comment Windows fait pour s'assurer que toutes les DLL sont bien mappées pour où elles ont été compilées?
Mais justement pas.
Si tu as lu la discussion depuis le début, tu as vu que le fichier exécutable PE comporte de sections qui servent au chargement. Lors de ce chargement l'OS lit ces sections et fait une éditien de liens dynamique (au sens Windows du terme, pas au sens compilateur du terme). Autrement dit il charge en mémoire physique où il veut et il s'arrange pour que la mémoire virtuelle pointe au bon endroi phyqoue pour chaque processus. Tout ça c'ext expliqué dans la base de conaissaaise de Kro$oft. Malheureusement je ne me rapelle plus où, mais je vais essayer de retrouver des liens.
Mais ça ne change rien au problème. Que ce soit l'éditeur de liens classiques qui fasse la rélocation, ou la fonction LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL en mémoire, l'adresse doit être 0x10017168. Et que si cette adresse est déjà prise lorsque le processus charge la DLL, il y a un petit problème.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard wrote:
Je crains que tu ne comprennes pas la question.
Ah ...
Cela fait longtemps que j'ai fait de l'assembleur avec la
syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à l'adresse 10017168h et pas
ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de
10017198h est *virtuelle* et *PAS* physique.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que
Jean-Marc le sait aussi.)
Chaque processus qui lira cette adresse virtuelle accédera à
sa copie de la variable en mémoire physique et désignée par
cette adresse absolue virtuelle.
Oui, mais chaque processus accédera bien à la même adresse à
l'intérieur de son espace d'adressage.
Il faut donc que i ait la même adresse dans tous les process
si le code est réellement partagé.
Et bien non.
À l'intérieur de son espace d'adressage, oui. Si l'adresse est
0x10017168, il faut bien s'arranger que cette adresse soit
disponible dans l'espace d'adressage de tous les processus qui
se servent de la DLL. Chose qui est loin d'être évidente.
Comment Windows fait pour s'assurer que
toutes les DLL sont bien mappées pour où elles ont été
compilées?
Mais justement pas.
Si tu as lu la discussion depuis le début, tu as vu que le
fichier exécutable PE comporte de sections qui servent au
chargement. Lors de ce chargement l'OS lit ces sections et
fait une éditien de liens dynamique (au sens Windows du terme,
pas au sens compilateur du terme). Autrement dit il charge en
mémoire physique où il veut et il s'arrange pour que la
mémoire virtuelle pointe au bon endroi phyqoue pour chaque
processus. Tout ça c'ext expliqué dans la base de
conaissaaise de Kro$oft. Malheureusement je ne me rapelle
plus où, mais je vais essayer de retrouver des liens.
Mais ça ne change rien au problème. Que ce soit l'éditeur de
liens classiques qui fasse la rélocation, ou la fonction
LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL
en mémoire, l'adresse doit être 0x10017168. Et que si cette
adresse est déjà prise lorsque le processus charge la DLL, il y
a un petit problème.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Cela fait longtemps que j'ai fait de l'assembleur avec la syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de 10017198h est *virtuelle* et *PAS* physique.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que Jean-Marc le sait aussi.)
Chaque processus qui lira cette adresse virtuelle accédera à sa copie de la variable en mémoire physique et désignée par cette adresse absolue virtuelle.
Oui, mais chaque processus accédera bien à la même adresse à l'intérieur de son espace d'adressage.
Il faut donc que i ait la même adresse dans tous les process si le code est réellement partagé.
Et bien non.
À l'intérieur de son espace d'adressage, oui. Si l'adresse est 0x10017168, il faut bien s'arranger que cette adresse soit disponible dans l'espace d'adressage de tous les processus qui se servent de la DLL. Chose qui est loin d'être évidente.
Comment Windows fait pour s'assurer que toutes les DLL sont bien mappées pour où elles ont été compilées?
Mais justement pas.
Si tu as lu la discussion depuis le début, tu as vu que le fichier exécutable PE comporte de sections qui servent au chargement. Lors de ce chargement l'OS lit ces sections et fait une éditien de liens dynamique (au sens Windows du terme, pas au sens compilateur du terme). Autrement dit il charge en mémoire physique où il veut et il s'arrange pour que la mémoire virtuelle pointe au bon endroi phyqoue pour chaque processus. Tout ça c'ext expliqué dans la base de conaissaaise de Kro$oft. Malheureusement je ne me rapelle plus où, mais je vais essayer de retrouver des liens.
Mais ça ne change rien au problème. Que ce soit l'éditeur de liens classiques qui fasse la rélocation, ou la fonction LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL en mémoire, l'adresse doit être 0x10017168. Et que si cette adresse est déjà prise lorsque le processus charge la DLL, il y a un petit problème.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnold McDonald \(AMcD\)
Vincent Burel wrote:
ha mais les DLL sont completement relogés dynamiquement au chargement... faut demander à AMCD, mais le système est obligé de de le faire...
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Vincent Burel wrote:
ha mais les DLL sont completement relogés dynamiquement au
chargement... faut demander à AMCD, mais le système est obligé de de
le faire...
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
Cela fait longtemps que j'ai fait de l'assembleur avec la syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu:
Je reviens sur la question. Donc oui ici.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
Mais non là.
Mais si. À l'intérieur de l'espace d'adressage du processus, c'est bien à l'adresse 0x10017168.
Je pense que le mode d'adressage virtuel des Intel 32 bits t'échappe et c'est ce mode qu'utilise Windows.
C'est aussi le mode qu'utilise tous les Unix depuis la version de Berkley, 1978, environ. Je suis sûr que Jean-Marc le connaît pertinemment bien.
[Déscription simplifiée de la mémoire virtuelle supprimée...]
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
Alain Gaillard writes:
Je crains que tu ne comprennes pas la question.
Ah ...
Cela fait longtemps que j'ai fait de l'assembleur avec la syntaxe MS -- mais il me semble que mov eax,dword ptr [i (10017168h)] c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de 10017198h est *virtuelle* et *PAS* physique.
On s'en doute qu'on cause d'adresse virtuelle, les adresses physiques, c'est l'affaire des OS depuis les années 70.
Il faut donc que i ait la même adresse dans tous les process si le code est réellement partagé.
Et bien non.
Comment Windows fait pour s'assurer que toutes les DLL sont bien mappées pour où elles ont été compilées?
Mais justement pas. Si tu as lu la discussion depuis le début, tu as vu que le fichier exécutable PE comporte de sections qui servent au chargement.
Ca n'a donc pas changé depuis Windows 3.1 (le dernier que j'ai programmé).
Lors de ce chargement l'OS lit ces sections et fait une éditien de liens dynamique (au sens Windows du terme, pas au sens compilateur du terme). Autrement dit il charge en mémoire physique où il veut et il s'arrange pour que la mémoire virtuelle pointe au bon endroi phyqoue pour chaque processus.
Nous sommes d'accord. Le problème c'est les adresses virtuelles: comment fait Windows si deux DLL veulent utiliser les mêmes adresses virtuelles. Modifier DS et CS est une possibilité, faire de la relocation -- et donc ne plus pouvoir partager -- une autre. Avec un espace virtuel plus grand on pourrait mapper chaque DLL à une adresse unique et partagée entre process (et faire une relocation une fois au chargement, mais partager après), mais avec 32 bits, on manquerait de place.
Les segments sont toujours sur un x86
Ils y sont toujours en effet, mais windows 32 bits n'utilise pas ce mode d'adressage.
Il n'y a pas de mode 32 bits qui n'utilise pas les segments. Je suppose donc que tu veux dire que Windows place les segments de manière à ce qu'ils se recouvrent et occupent tout l'espace virtuel, ce que font à peu près tous les OS 32 bits sur x86 (j'ai entendu parlé d'exceptions dans les OS temps réels, mais je suis incapable d'en cité une).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Cela fait longtemps que j'ai fait de l'assembleur avec la
syntaxe MS -- mais il me semble que mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de
10017198h est *virtuelle* et *PAS* physique.
On s'en doute qu'on cause d'adresse virtuelle, les adresses
physiques, c'est l'affaire des OS depuis les années 70.
Il faut donc que i ait
la même adresse dans tous les process si le code est
réellement partagé.
Et bien non.
Comment Windows fait pour s'assurer que
toutes les DLL sont bien mappées pour où elles ont été
compilées?
Mais justement pas.
Si tu as lu la discussion depuis le début, tu as vu que le fichier
exécutable PE comporte de sections qui servent au
chargement.
Ca n'a donc pas changé depuis Windows 3.1 (le dernier que
j'ai programmé).
Lors de ce chargement l'OS lit ces sections et fait une
éditien de liens dynamique (au sens Windows du terme, pas
au sens compilateur du terme). Autrement dit il charge en
mémoire physique où il veut et il s'arrange pour que la
mémoire virtuelle pointe au bon endroi phyqoue pour chaque
processus.
Nous sommes d'accord. Le problème c'est les adresses
virtuelles: comment fait Windows si deux DLL veulent
utiliser les mêmes adresses virtuelles. Modifier DS et CS
est une possibilité, faire de la relocation -- et donc ne
plus pouvoir partager -- une autre. Avec un espace virtuel
plus grand on pourrait mapper chaque DLL à une adresse
unique et partagée entre process (et faire une relocation
une fois au chargement, mais partager après), mais avec 32
bits, on manquerait de place.
Les segments sont toujours sur un x86
Ils y sont toujours en effet, mais windows 32 bits
n'utilise pas ce mode d'adressage.
Il n'y a pas de mode 32 bits qui n'utilise pas les segments.
Je suppose donc que tu veux dire que Windows place les
segments de manière à ce qu'ils se recouvrent et occupent
tout l'espace virtuel, ce que font à peu près tous les OS 32
bits sur x86 (j'ai entendu parlé d'exceptions dans les OS
temps réels, mais je suis incapable d'en cité une).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Cela fait longtemps que j'ai fait de l'assembleur avec la syntaxe MS -- mais il me semble que mov eax,dword ptr [i (10017168h)] c'est de l'adressage absolu:
En effet.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
NOOONNN!
Mais non. Je n'arrête pas de le répêter, cette adresse de 10017198h est *virtuelle* et *PAS* physique.
On s'en doute qu'on cause d'adresse virtuelle, les adresses physiques, c'est l'affaire des OS depuis les années 70.
Il faut donc que i ait la même adresse dans tous les process si le code est réellement partagé.
Et bien non.
Comment Windows fait pour s'assurer que toutes les DLL sont bien mappées pour où elles ont été compilées?
Mais justement pas. Si tu as lu la discussion depuis le début, tu as vu que le fichier exécutable PE comporte de sections qui servent au chargement.
Ca n'a donc pas changé depuis Windows 3.1 (le dernier que j'ai programmé).
Lors de ce chargement l'OS lit ces sections et fait une éditien de liens dynamique (au sens Windows du terme, pas au sens compilateur du terme). Autrement dit il charge en mémoire physique où il veut et il s'arrange pour que la mémoire virtuelle pointe au bon endroi phyqoue pour chaque processus.
Nous sommes d'accord. Le problème c'est les adresses virtuelles: comment fait Windows si deux DLL veulent utiliser les mêmes adresses virtuelles. Modifier DS et CS est une possibilité, faire de la relocation -- et donc ne plus pouvoir partager -- une autre. Avec un espace virtuel plus grand on pourrait mapper chaque DLL à une adresse unique et partagée entre process (et faire une relocation une fois au chargement, mais partager après), mais avec 32 bits, on manquerait de place.
Les segments sont toujours sur un x86
Ils y sont toujours en effet, mais windows 32 bits n'utilise pas ce mode d'adressage.
Il n'y a pas de mode 32 bits qui n'utilise pas les segments. Je suppose donc que tu veux dire que Windows place les segments de manière à ce qu'ils se recouvrent et occupent tout l'espace virtuel, ce que font à peu près tous les OS 32 bits sur x86 (j'ai entendu parlé d'exceptions dans les OS temps réels, mais je suis incapable d'en cité une).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Burel
"Alain Gaillard" wrote in message news:45058350$0$25920$
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux process utilisant la meme DLL, je ne suis pas certain que cette DLL ne soit pas physiquement chargé 2 fois..."
:-)
Ben on l'a dit dès le départ non ? Elle n'est pas chargée physiquemenbt deux fois en ce qui concerne le code.
Et bien c'est pas évidents, puisqu'une DLL peut etre relogée différemment selon le process dans lequel elle est linké... suivant ce qu'implique ce relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à une application... auquel cas elle ne saurait reservir dans un autre process...
VB
"Alain Gaillard" <alain_gaillard28@hotmail.fr> wrote in message
news:45058350$0$25920$ba4acef3@news.orange.fr...
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux
process utilisant la meme DLL, je ne
suis pas certain que cette DLL ne soit pas physiquement chargé 2
fois..."
:-)
Ben on l'a dit dès le départ non ? Elle n'est pas chargée physiquemenbt
deux fois en ce qui concerne le code.
Et bien c'est pas évidents, puisqu'une DLL peut etre relogée différemment
selon le process dans lequel elle est linké... suivant ce qu'implique ce
relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à
une application... auquel cas elle ne saurait reservir dans un autre
process...
"Alain Gaillard" wrote in message news:45058350$0$25920$
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux process utilisant la meme DLL, je ne suis pas certain que cette DLL ne soit pas physiquement chargé 2 fois..."
:-)
Ben on l'a dit dès le départ non ? Elle n'est pas chargée physiquemenbt deux fois en ce qui concerne le code.
Et bien c'est pas évidents, puisqu'une DLL peut etre relogée différemment selon le process dans lequel elle est linké... suivant ce qu'implique ce relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à une application... auquel cas elle ne saurait reservir dans un autre process...
VB
kanze
Alain Gaillard wrote:
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre 1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.
Ce n'est pas grave. Le problème en est ailleurs.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le problème, si tu veux, c'est ce qui se passe si je démarre processus A, qui utilise cette DLL, et qu'on mappe bien la variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite si un processus B démande la même DLL, et qu'il a déjà quelque chose mappée à cette adresse (toujours, dans son espace d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse physique à laquelle elle correspond devrait elle être la me^me pour chaque proc.
Mais qui parle donc des adresses physiques. C'est évident que les adresses physiques sont différentes pour chaque processus (et qu'elles évolvent pendant l'exécution du processus, au fur et à mesure que des pages passent sur disque et reviennent).
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors ce sera la même adresse physique et alors le code est partagé. Si l'adresse pointe sur des données, alors l'adresse physique correspondante est différente pour chaque processus qui a sa copie en mémoire physique des données.
On répète. Le problème n'a rien à voir avec les adresses physiques en mémoire réele. C'est un problème de l'adresse dans l'espace d'adressage du processus. Une fois que la variable positionnée bien à 0x100217C0, comment est-ce que tu peux garantir que cette adresse ne sert pas déjà dans d'autres processus qui veulent utiliser la DLL ?
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard wrote:
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est
pas dans les 2Go supérieur, mais dans le deuxième banc de
1Go, entre 1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.
Ce n'est pas grave. Le problème en est ailleurs.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse
physique à laquelle elle correspond devrait elle être la me^me
pour chaque proc.
Mais qui parle donc des adresses physiques. C'est évident que
les adresses physiques sont différentes pour chaque processus
(et qu'elles évolvent pendant l'exécution du processus, au fur
et à mesure que des pages passent sur disque et reviennent).
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors
ce sera la même adresse physique et alors le code est partagé.
Si l'adresse pointe sur des données, alors l'adresse physique
correspondante est différente pour chaque processus qui a sa
copie en mémoire physique des données.
On répète. Le problème n'a rien à voir avec les adresses
physiques en mémoire réele. C'est un problème de l'adresse dans
l'espace d'adressage du processus. Une fois que la variable
positionnée bien à 0x100217C0, comment est-ce que tu peux
garantir que cette adresse ne sert pas déjà dans d'autres
processus qui veulent utiliser la DLL ?
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre 1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.
Ce n'est pas grave. Le problème en est ailleurs.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le problème, si tu veux, c'est ce qui se passe si je démarre processus A, qui utilise cette DLL, et qu'on mappe bien la variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite si un processus B démande la même DLL, et qu'il a déjà quelque chose mappée à cette adresse (toujours, dans son espace d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse physique à laquelle elle correspond devrait elle être la me^me pour chaque proc.
Mais qui parle donc des adresses physiques. C'est évident que les adresses physiques sont différentes pour chaque processus (et qu'elles évolvent pendant l'exécution du processus, au fur et à mesure que des pages passent sur disque et reviennent).
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors ce sera la même adresse physique et alors le code est partagé. Si l'adresse pointe sur des données, alors l'adresse physique correspondante est différente pour chaque processus qui a sa copie en mémoire physique des données.
On répète. Le problème n'a rien à voir avec les adresses physiques en mémoire réele. C'est un problème de l'adresse dans l'espace d'adressage du processus. Une fois que la variable positionnée bien à 0x100217C0, comment est-ce que tu peux garantir que cette adresse ne sert pas déjà dans d'autres processus qui veulent utiliser la DLL ?
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Vincent Burel
"Arnold McDonald (AMcD)" wrote in message news:450583c8$0$287$
Vincent Burel wrote:
ha mais les DLL sont completement relogés dynamiquement au chargement... faut demander à AMCD, mais le système est obligé de de le faire...
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
t'es syndiqué toi ? :-)
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in message
news:450583c8$0$287$626a54ce@news.free.fr...
Vincent Burel wrote:
ha mais les DLL sont completement relogés dynamiquement au
chargement... faut demander à AMCD, mais le système est obligé de de
le faire...
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
"Arnold McDonald (AMcD)" wrote in message news:450583c8$0$287$
Vincent Burel wrote:
ha mais les DLL sont completement relogés dynamiquement au chargement... faut demander à AMCD, mais le système est obligé de de le faire...
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
t'es syndiqué toi ? :-)
Alain Gaillard
Et alors. On le sait. (Je le sais très bien, et je suis sûr que Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout le monde corresponde à la même adresse physique pour tout le monde ? Ca dépend de la table de descripteur propre à chaque processus et que le système constitue losqu'il lance un exe.
-- Alain
Et alors. On le sait. (Je le sais très bien, et je suis sûr que
Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à
l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout
le monde corresponde à la même adresse physique pour tout le monde ? Ca
dépend de la table de descripteur propre à chaque processus et que le
système constitue losqu'il lance un exe.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout le monde corresponde à la même adresse physique pour tout le monde ? Ca dépend de la table de descripteur propre à chaque processus et que le système constitue losqu'il lance un exe.
-- Alain
Alain Gaillard
relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à une application... auquel cas elle ne saurait reservir dans un autre process...
C'est vrai que cette possibilité ne semble pas exclue non plus :) -- Alain
relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à
une application... auquel cas elle ne saurait reservir dans un autre
process...
C'est vrai que cette possibilité ne semble pas exclue non plus :)
--
Alain
relogeage, l'image de la DLL peut sensiblement changer et devenir spécique à une application... auquel cas elle ne saurait reservir dans un autre process...
C'est vrai que cette possibilité ne semble pas exclue non plus :) -- Alain
kanze
Arnold McDonald (AMcD) wrote:
Alain Gaillard wrote:
Tiens au fait toi qui parle volontiers "d'engueulo, de franche camaraderie, de docte". Que dirais tu toi même de ta propre intervention là ? LOL
Je connais la plupart des intervenants ici depuis des années. Eux aussi...
Attention ! Il y a un cross-posting. Je suis un reguilier de fr.comp.lang.c++, où je lis ces postings, et je ne t'y aie jamais vu.
C'est d'ailleurs sans doute pour ça que Alain et moi ont tant de problèmes à se faire comprendre. S'il avait fréquenté fr.comp.lang.c++ avant, je suis assez sûr qu'il se serait rendu compte que ce n'était pas nécessaire à m'expliquer la mémoire virtuelle, et qu'il devait avoir quelque chose d'autre derrière ma question. (Et que n'étant pas francophone d'origine, j'ai parfois du mal à m'exprimer bien comme il faut.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnold McDonald (AMcD) wrote:
Alain Gaillard wrote:
Tiens au fait toi qui parle volontiers "d'engueulo, de franche
camaraderie, de docte". Que dirais tu toi même de ta propre
intervention là ? LOL
Je connais la plupart des intervenants ici depuis des années.
Eux aussi...
Attention ! Il y a un cross-posting. Je suis un reguilier de
fr.comp.lang.c++, où je lis ces postings, et je ne t'y aie
jamais vu.
C'est d'ailleurs sans doute pour ça que Alain et moi ont tant de
problèmes à se faire comprendre. S'il avait fréquenté
fr.comp.lang.c++ avant, je suis assez sûr qu'il se serait rendu
compte que ce n'était pas nécessaire à m'expliquer la mémoire
virtuelle, et qu'il devait avoir quelque chose d'autre derrière
ma question. (Et que n'étant pas francophone d'origine, j'ai
parfois du mal à m'exprimer bien comme il faut.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Tiens au fait toi qui parle volontiers "d'engueulo, de franche camaraderie, de docte". Que dirais tu toi même de ta propre intervention là ? LOL
Je connais la plupart des intervenants ici depuis des années. Eux aussi...
Attention ! Il y a un cross-posting. Je suis un reguilier de fr.comp.lang.c++, où je lis ces postings, et je ne t'y aie jamais vu.
C'est d'ailleurs sans doute pour ça que Alain et moi ont tant de problèmes à se faire comprendre. S'il avait fréquenté fr.comp.lang.c++ avant, je suis assez sûr qu'il se serait rendu compte que ce n'était pas nécessaire à m'expliquer la mémoire virtuelle, et qu'il devait avoir quelque chose d'autre derrière ma question. (Et que n'étant pas francophone d'origine, j'ai parfois du mal à m'exprimer bien comme il faut.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
