En effet tu lis en diagonale, car d'abord je ne vois pas en quoi cette
discussion est une engueulo.
Ne serait-ce que ton ton "je suis le best je sais tout", ça donen une vague
idée de franche camaraderie.
PS : garde ton ton doct
En effet tu lis en diagonale, car d'abord je ne vois pas en quoi cette
discussion est une engueulo.
Ne serait-ce que ton ton "je suis le best je sais tout", ça donen une vague
idée de franche camaraderie.
PS : garde ton ton doct
En effet tu lis en diagonale, car d'abord je ne vois pas en quoi cette
discussion est une engueulo.
Ne serait-ce que ton ton "je suis le best je sais tout", ça donen une vague
idée de franche camaraderie.
PS : garde ton ton doct
Alors, comment fait-il si cette fonction fait partie d'une
DLL ? Est-ce qu'il y a une option que je n'ai pas vue ?
Je pense surtout que ce que tu n'as pas encore vu, c'est qu'un
Windows ce n'est pas un Unix. Et ce que tu t'attends à trouver
d'un Unix à un autre tu ne vas pas le trouver forcément sous
Windows.
Je ne voudrais pas trop faire de off-topic. Je pense que tu
devrais lire les docs Kro$oft relatives aux dll et aux édition
de liens, non pas au sens du compilateur, mais au sens de
l'OS.
Alors, comment fait-il si cette fonction fait partie d'une
DLL ? Est-ce qu'il y a une option que je n'ai pas vue ?
Je pense surtout que ce que tu n'as pas encore vu, c'est qu'un
Windows ce n'est pas un Unix. Et ce que tu t'attends à trouver
d'un Unix à un autre tu ne vas pas le trouver forcément sous
Windows.
Je ne voudrais pas trop faire de off-topic. Je pense que tu
devrais lire les docs Kro$oft relatives aux dll et aux édition
de liens, non pas au sens du compilateur, mais au sens de
l'OS.
Alors, comment fait-il si cette fonction fait partie d'une
DLL ? Est-ce qu'il y a une option que je n'ai pas vue ?
Je pense surtout que ce que tu n'as pas encore vu, c'est qu'un
Windows ce n'est pas un Unix. Et ce que tu t'attends à trouver
d'un Unix à un autre tu ne vas pas le trouver forcément sous
Windows.
Je ne voudrais pas trop faire de off-topic. Je pense que tu
devrais lire les docs Kro$oft relatives aux dll et aux édition
de liens, non pas au sens du compilateur, mais au sens de
l'OS.
N'importe quoi...
Prends un debugguer et scrute quelques applis. Ne confond pas chargé et
mappé, ne confonds pas en mémoire et sur disque. Et ne confond pas données
et code...
Eh ! Les vacances sont finies, faut se reconcentrer man :-).
N'importe quoi...
Prends un debugguer et scrute quelques applis. Ne confond pas chargé et
mappé, ne confonds pas en mémoire et sur disque. Et ne confond pas données
et code...
Eh ! Les vacances sont finies, faut se reconcentrer man :-).
N'importe quoi...
Prends un debugguer et scrute quelques applis. Ne confond pas chargé et
mappé, ne confonds pas en mémoire et sur disque. Et ne confond pas données
et code...
Eh ! Les vacances sont finies, faut se reconcentrer man :-).
Si l'OS s'amuse à jouer avec les règistres de segmentation.
En fait, il s'agit toujours de la fonction :
int
f()
{
static int i = 0 ;
return i ++ ;
}
Dans le code généré par VC++, les instructions d'accès à i
utilise un offset constant (à l'encontre de ce qui se passe avec
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS. Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ? S'il
partage l'image du code entre plusieurs processus, il ne peut
pas « corriger » l'offset dans le code. Si on ne se sert pas
des pointeurs 48 bits (avec chaque fois un segment, et un
segment par DLL), il ne peut pas s'assurer que l'offset soit
identique dans chaque processus. Alors, que fait-il ? (Il doit
bien y avoir quelque chose que je ne vois pas, parce
qu'indubitablement, ça marche.)
Si l'OS s'amuse à jouer avec les règistres de segmentation.
En fait, il s'agit toujours de la fonction :
int
f()
{
static int i = 0 ;
return i ++ ;
}
Dans le code généré par VC++, les instructions d'accès à i
utilise un offset constant (à l'encontre de ce qui se passe avec
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS. Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ? S'il
partage l'image du code entre plusieurs processus, il ne peut
pas « corriger » l'offset dans le code. Si on ne se sert pas
des pointeurs 48 bits (avec chaque fois un segment, et un
segment par DLL), il ne peut pas s'assurer que l'offset soit
identique dans chaque processus. Alors, que fait-il ? (Il doit
bien y avoir quelque chose que je ne vois pas, parce
qu'indubitablement, ça marche.)
Si l'OS s'amuse à jouer avec les règistres de segmentation.
En fait, il s'agit toujours de la fonction :
int
f()
{
static int i = 0 ;
return i ++ ;
}
Dans le code généré par VC++, les instructions d'accès à i
utilise un offset constant (à l'encontre de ce qui se passe avec
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS. Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ? S'il
partage l'image du code entre plusieurs processus, il ne peut
pas « corriger » l'offset dans le code. Si on ne se sert pas
des pointeurs 48 bits (avec chaque fois un segment, et un
segment par DLL), il ne peut pas s'assurer que l'offset soit
identique dans chaque processus. Alors, que fait-il ? (Il doit
bien y avoir quelque chose que je ne vois pas, parce
qu'indubitablement, ça marche.)
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS, en
tout cas).
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui ne
le connais pas.
Et je constate également qu'à l'intérieur d'un processus, on ne touche
normalement pas à DS -- si la fonction renvoie l'adresse, par exemple, il
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157956613.844273.280450@d34g2000cwd.googlegroups.com...
Vincent Burel wrote:
"James Kanze" <kanze.james@neuf.fr> wrote in message
news:1157885071.765095.141990@m79g2000cwm.googlegroups.com...
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS, en
tout cas).
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui ne
le connais pas.
Et je constate également qu'à l'intérieur d'un processus, on ne touche
normalement pas à DS -- si la fonction renvoie l'adresse, par exemple, il
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS, en
tout cas).
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui ne
le connais pas.
Et je constate également qu'à l'intérieur d'un processus, on ne touche
normalement pas à DS -- si la fonction renvoie l'adresse, par exemple, il
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
Je sais que le 80386 introduisait un mechanisme pour
supporter ce genre de chose -- un appel FAR pouvait passer
par un espèce de portail qui faisait qu'on ne pourrait
arriver qu'à des adresses bien définies, mais qu'on ce
faisant, on passait en mode super-user.
Encore ce terme de FAR.... :-S
Mais globalement c'ets comme ce que tu décris.
règistre, et puis d'utiliser un « trap » -- sur une 80x86,
une instruction INT -- qui passe par une table
d'interruptions (que le code utilisateur ne peut pas
modifier, au moins en mode protégée du processeur).
Certes mais sous Windows ce n'est pa scomme ça.
machine. Même aujourd'hui, je vois mal un système qui mappe
l'OS et l'application utilisateur dans le même espace
virtuel.
Tu le vois mal ? Alors change de lunettes, puisque c'est comme
ça :)
J'avais oublié le :-). L'idée qu'un processus utilisateur ne
peut se servir de 2 Go, à la place de 4,
A mais je n'ai jamais dis ça. Faut lire....
J'ai dit:
4go adressables pour un processus.
Le code est dans les 2 go inférieurs. Pour être plus complet,
tout en bas de cette zone, il y a un cache (PATH, clé de
registre, etc...) qui est réservé par le système, dans le sens
où l'appli ne peut pas écrire dedans Les tables de saut sont
dans les é Go supérieurs. Ainsi que les données, ça je ne l'ai
aps précisé.
En gros, une appli dispose d'environ 3 go vraiment pour elle.
sur un processeur moderne 32 bits avec mémoire virtuelle, me
faisait en fait penser au commentaire « 564 [ou quelque
chose comme ça] mémoire serait assez grande pour n'importe
qui », attribué à Bill Gates (faussement, je crois).
Je ne sais pas. Mais je sais qu'il a dit "Si vous ne pouvez
pas le faire bien, faites le beau" LOL
Je sais que le 80386 introduisait un mechanisme pour
supporter ce genre de chose -- un appel FAR pouvait passer
par un espèce de portail qui faisait qu'on ne pourrait
arriver qu'à des adresses bien définies, mais qu'on ce
faisant, on passait en mode super-user.
Encore ce terme de FAR.... :-S
Mais globalement c'ets comme ce que tu décris.
règistre, et puis d'utiliser un « trap » -- sur une 80x86,
une instruction INT -- qui passe par une table
d'interruptions (que le code utilisateur ne peut pas
modifier, au moins en mode protégée du processeur).
Certes mais sous Windows ce n'est pa scomme ça.
machine. Même aujourd'hui, je vois mal un système qui mappe
l'OS et l'application utilisateur dans le même espace
virtuel.
Tu le vois mal ? Alors change de lunettes, puisque c'est comme
ça :)
J'avais oublié le :-). L'idée qu'un processus utilisateur ne
peut se servir de 2 Go, à la place de 4,
A mais je n'ai jamais dis ça. Faut lire....
J'ai dit:
4go adressables pour un processus.
Le code est dans les 2 go inférieurs. Pour être plus complet,
tout en bas de cette zone, il y a un cache (PATH, clé de
registre, etc...) qui est réservé par le système, dans le sens
où l'appli ne peut pas écrire dedans Les tables de saut sont
dans les é Go supérieurs. Ainsi que les données, ça je ne l'ai
aps précisé.
En gros, une appli dispose d'environ 3 go vraiment pour elle.
sur un processeur moderne 32 bits avec mémoire virtuelle, me
faisait en fait penser au commentaire « 564 [ou quelque
chose comme ça] mémoire serait assez grande pour n'importe
qui », attribué à Bill Gates (faussement, je crois).
Je ne sais pas. Mais je sais qu'il a dit "Si vous ne pouvez
pas le faire bien, faites le beau" LOL
Je sais que le 80386 introduisait un mechanisme pour
supporter ce genre de chose -- un appel FAR pouvait passer
par un espèce de portail qui faisait qu'on ne pourrait
arriver qu'à des adresses bien définies, mais qu'on ce
faisant, on passait en mode super-user.
Encore ce terme de FAR.... :-S
Mais globalement c'ets comme ce que tu décris.
règistre, et puis d'utiliser un « trap » -- sur une 80x86,
une instruction INT -- qui passe par une table
d'interruptions (que le code utilisateur ne peut pas
modifier, au moins en mode protégée du processeur).
Certes mais sous Windows ce n'est pa scomme ça.
machine. Même aujourd'hui, je vois mal un système qui mappe
l'OS et l'application utilisateur dans le même espace
virtuel.
Tu le vois mal ? Alors change de lunettes, puisque c'est comme
ça :)
J'avais oublié le :-). L'idée qu'un processus utilisateur ne
peut se servir de 2 Go, à la place de 4,
A mais je n'ai jamais dis ça. Faut lire....
J'ai dit:
4go adressables pour un processus.
Le code est dans les 2 go inférieurs. Pour être plus complet,
tout en bas de cette zone, il y a un cache (PATH, clé de
registre, etc...) qui est réservé par le système, dans le sens
où l'appli ne peut pas écrire dedans Les tables de saut sont
dans les é Go supérieurs. Ainsi que les données, ça je ne l'ai
aps précisé.
En gros, une appli dispose d'environ 3 go vraiment pour elle.
sur un processeur moderne 32 bits avec mémoire virtuelle, me
faisait en fait penser au commentaire « 564 [ou quelque
chose comme ça] mémoire serait assez grande pour n'importe
qui », attribué à Bill Gates (faussement, je crois).
Je ne sais pas. Mais je sais qu'il a dit "Si vous ne pouvez
pas le faire bien, faites le beau" LOL
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça non ?Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll autour de ta
fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans la zone des 2
go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le fichier PE y
trouve une section "données" contenant au moins ta variable static et que
lors du chargement il crée une zone en mémoire (une par process si
plusieurs utilisent la dll) contenant cette variable. Je dis je suppose
parce que pour être certain à 100% il faudrait examiner le fichier binaire
PE, mais je ne pense pas me tromper toutefois.
Quand l'appli va lire la valeur elle le fait avec un pointeur qui vaut
10017198h dans l'exemple. Mais cette adresse est toute virtuelle. Quand
elle est lue le système fait ce qu'il faut pour que la variable appartenant
au process soit lue effectivement en mémoire physique.
Et chaque process à sa propre copie de la variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise
tant.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça non ?
Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll autour de ta
fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans la zone des 2
go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le fichier PE y
trouve une section "données" contenant au moins ta variable static et que
lors du chargement il crée une zone en mémoire (une par process si
plusieurs utilisent la dll) contenant cette variable. Je dis je suppose
parce que pour être certain à 100% il faudrait examiner le fichier binaire
PE, mais je ne pense pas me tromper toutefois.
Quand l'appli va lire la valeur elle le fait avec un pointeur qui vaut
10017198h dans l'exemple. Mais cette adresse est toute virtuelle. Quand
elle est lue le système fait ce qu'il faut pour que la variable appartenant
au process soit lue effectivement en mémoire physique.
Et chaque process à sa propre copie de la variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise
tant.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça non ?Alors, je compile cette fonction, et je le lie
dans une DLL. Je charge la DLL dans deux processus différents,
dont les données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll autour de ta
fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans la zone des 2
go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le fichier PE y
trouve une section "données" contenant au moins ta variable static et que
lors du chargement il crée une zone en mémoire (une par process si
plusieurs utilisent la dll) contenant cette variable. Je dis je suppose
parce que pour être certain à 100% il faudrait examiner le fichier binaire
PE, mais je ne pense pas me tromper toutefois.
Quand l'appli va lire la valeur elle le fait avec un pointeur qui vaut
10017198h dans l'exemple. Mais cette adresse est toute virtuelle. Quand
elle est lue le système fait ce qu'il faut pour que la variable appartenant
au process soit lue effectivement en mémoire physique.
Et chaque process à sa propre copie de la variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise
tant.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
C'est vrai que ça date:-). Mais la dernière fois que j'ai
travaillé professionnellement sur l'architecture Intel, le
processeur était un 80386, et l'OS MS-DOS 3.2.
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
compilateur ne fait entrer en jeu aucun régistre ou d'autre
aspect variable -- ce que renvoie la fonction, c'est bien une
constante qui fait partie variable (régistre, etc.). Je suppose
donc que si j'appelle cette fonction depuis la partie principale
(non-DLL) de mon programme, j'ai toujours la même valeur,
quelque soit le processus. Et c'est ça que je ne comprends
pas : comment est-ce que je pourrais avoir toujours la même
valeur ? Qu'est-ce qui se passe, par exemple, si mon code a
déjà quelque chose d'autre (mettons d'une autre DLL) à cette
adresse ?
Ça l'était sous MS-DOS. Ça l'est à peu près partout ailleurs.
Pourquoi est-ce que Windows ferait quelque chose de différent ?
C'est vrai que ça date:-). Mais la dernière fois que j'ai
travaillé professionnellement sur l'architecture Intel, le
processeur était un 80386, et l'OS MS-DOS 3.2.
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
compilateur ne fait entrer en jeu aucun régistre ou d'autre
aspect variable -- ce que renvoie la fonction, c'est bien une
constante qui fait partie variable (régistre, etc.). Je suppose
donc que si j'appelle cette fonction depuis la partie principale
(non-DLL) de mon programme, j'ai toujours la même valeur,
quelque soit le processus. Et c'est ça que je ne comprends
pas : comment est-ce que je pourrais avoir toujours la même
valeur ? Qu'est-ce qui se passe, par exemple, si mon code a
déjà quelque chose d'autre (mettons d'une autre DLL) à cette
adresse ?
Ça l'était sous MS-DOS. Ça l'est à peu près partout ailleurs.
Pourquoi est-ce que Windows ferait quelque chose de différent ?
C'est vrai que ça date:-). Mais la dernière fois que j'ai
travaillé professionnellement sur l'architecture Intel, le
processeur était un 80386, et l'OS MS-DOS 3.2.
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
compilateur ne fait entrer en jeu aucun régistre ou d'autre
aspect variable -- ce que renvoie la fonction, c'est bien une
constante qui fait partie variable (régistre, etc.). Je suppose
donc que si j'appelle cette fonction depuis la partie principale
(non-DLL) de mon programme, j'ai toujours la même valeur,
quelque soit le processus. Et c'est ça que je ne comprends
pas : comment est-ce que je pourrais avoir toujours la même
valeur ? Qu'est-ce qui se passe, par exemple, si mon code a
déjà quelque chose d'autre (mettons d'une autre DLL) à cette
adresse ?
Ça l'était sous MS-DOS. Ça l'est à peu près partout ailleurs.
Pourquoi est-ce que Windows ferait quelque chose de différent ?
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
Non non, pas en Windows 32 bits
Parce que pour chaque processus c'est la même adresse
*virtuelle* mais cette adresse désigne un emplacement en
mémoire physique différent pour chaque processus.
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
Non non, pas en Windows 32 bits
Parce que pour chaque processus c'est la même adresse
*virtuelle* mais cette adresse désigne un emplacement en
mémoire physique différent pour chaque processus.
Cette fonction se trouve linkée dans une DLL. L'adresse (c-à-d
l'offset par rapport à DS)
Non non, pas en Windows 32 bits
Parce que pour chaque processus c'est la même adresse
*virtuelle* mais cette adresse désigne un emplacement en
mémoire physique différent pour chaque processus.
