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:
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:
Jean-Marc Bourguet a écrit :
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$
Vincent Burel a écrit :
> 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...
Vincent Burel a écrit :
> 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$
Vincent Burel a écrit :
> 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:
kanze a écrit :
> 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:
kanze a écrit :
> 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
kanze a écrit :
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
kanze a écrit :
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
Vincent Burel a écrit :
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
Vincent Burel a écrit :
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
Jean-Marc Bourguet
Alain Gaillard writes:
Jean-Marc Bourguet a écrit :
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à. Je pense que le mode d'adressage virtuel des Intel 32 bits t'échappe
Je crois que tu me sous-estimes. J'ai fait pas mal d'assembleur x86 dont un DOS extender, qui utilisait la mémoire virtuelle pour imiter la mémoire paginée (donc je partais du DOS, j'activais le mode protégé, j'activais la pagination et je retournais sous DOS en mode virtuel, et j'avais implémenté les interuptions LM? pour modifier le mapping), je doute que ça ait fonctionné si je n'avais pas compris les différents mode de fonctionnement de la machine. A ma connaissance il n'y a pas eu de changement depuis cette époque si on excepte le mode 64 bits.
Voilà pourquoi une adresse virtuelle donnée va pointer vers des adresses physiques différentes selon le processus. Quand Windows charge un exe il construit cette table (table qui n'est pas la table de saut en mémoire haute dont j'ai parlé avant, ça tombe sous le sens), donc à priori différentes pour chaque processus, même si elle peuvent avoir des points communs, comme le code partagé des dll.
Bon, on va faire un exemple simple: J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C. A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle $80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle $80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à l'adresse virtuelle $80000000 de C, donc comme il y a des références absolues il doit modifier le code et ne plus le partager.
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:
Je reviens sur la question. Donc oui ici.
donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs.
Mais non là.
Je pense que le mode d'adressage virtuel des Intel 32 bits
t'échappe
Je crois que tu me sous-estimes. J'ai fait pas mal
d'assembleur x86 dont un DOS extender, qui utilisait la
mémoire virtuelle pour imiter la mémoire paginée (donc je
partais du DOS, j'activais le mode protégé, j'activais la
pagination et je retournais sous DOS en mode virtuel, et
j'avais implémenté les interuptions LM? pour modifier le
mapping), je doute que ça ait fonctionné si je n'avais pas
compris les différents mode de fonctionnement de la machine.
A ma connaissance il n'y a pas eu de changement depuis cette
époque si on excepte le mode 64 bits.
Voilà pourquoi une adresse virtuelle donnée va pointer
vers des adresses physiques différentes selon le
processus. Quand Windows charge un exe il construit cette
table (table qui n'est pas la table de saut en mémoire
haute dont j'ai parlé avant, ça tombe sous le sens), donc
à priori différentes pour chaque processus, même si elle
peuvent avoir des points communs, comme le code partagé
des dll.
Bon, on va faire un exemple simple:
J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C.
A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle
$80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle
$80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à
l'adresse virtuelle $80000000 de C, donc comme il y a des
références absolues il doit modifier le code et ne plus le
partager.
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:
Je reviens sur la question. Donc oui ici.
donc le code sait qu'i est à l'adresse 10017168h et pas ailleurs.
Mais non là. Je pense que le mode d'adressage virtuel des Intel 32 bits t'échappe
Je crois que tu me sous-estimes. J'ai fait pas mal d'assembleur x86 dont un DOS extender, qui utilisait la mémoire virtuelle pour imiter la mémoire paginée (donc je partais du DOS, j'activais le mode protégé, j'activais la pagination et je retournais sous DOS en mode virtuel, et j'avais implémenté les interuptions LM? pour modifier le mapping), je doute que ça ait fonctionné si je n'avais pas compris les différents mode de fonctionnement de la machine. A ma connaissance il n'y a pas eu de changement depuis cette époque si on excepte le mode 64 bits.
Voilà pourquoi une adresse virtuelle donnée va pointer vers des adresses physiques différentes selon le processus. Quand Windows charge un exe il construit cette table (table qui n'est pas la table de saut en mémoire haute dont j'ai parlé avant, ça tombe sous le sens), donc à priori différentes pour chaque processus, même si elle peuvent avoir des points communs, comme le code partagé des dll.
Bon, on va faire un exemple simple: J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C. A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle $80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle $80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à l'adresse virtuelle $80000000 de C, donc comme il y a des références absolues il doit modifier le code et ne plus le partager.
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
Alain Gaillard
kanze a écrit :
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 ?
Mais en quoi est-ce un problème ?
-- Alain
kanze a écrit :
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 ?
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 ?
