Le mécanisme de gestion de mémoire virtuelle est assez particulier. En
quelques mots disons que toute application se voit attribuer les 4 Go
adressables, mais toute cette zone est une zone de mémoire virtuelle,
pas physique évidemment. Les 2 go de mémoire basse sont à son usage.
Dans les 2 Go de mémoire haute sont installée les tables de saut vers
les dll utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne réside
qu'une fois en mémoire physique.
Le mécanisme de gestion de mémoire virtuelle est assez particulier. En
quelques mots disons que toute application se voit attribuer les 4 Go
adressables, mais toute cette zone est une zone de mémoire virtuelle,
pas physique évidemment. Les 2 go de mémoire basse sont à son usage.
Dans les 2 Go de mémoire haute sont installée les tables de saut vers
les dll utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne réside
qu'une fois en mémoire physique.
Le mécanisme de gestion de mémoire virtuelle est assez particulier. En
quelques mots disons que toute application se voit attribuer les 4 Go
adressables, mais toute cette zone est une zone de mémoire virtuelle,
pas physique évidemment. Les 2 go de mémoire basse sont à son usage.
Dans les 2 Go de mémoire haute sont installée les tables de saut vers
les dll utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne réside
qu'une fois en mémoire physique.
"Alain Gaillard" wrote in message[...]
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne
réside qu'une fois en mémoire physique.
Pour un process donné oui... Pour deux process utilisant la meme DLL,
je ne suis pas certain que cette DLL ne soit pas physiquement chargé
2 fois...
"Alain Gaillard" <alain_gaillard28@hotmail.fr> wrote in message
[...]
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne
réside qu'une fois en mémoire physique.
Pour un process donné oui... Pour deux process utilisant la meme DLL,
je ne suis pas certain que cette DLL ne soit pas physiquement chargé
2 fois...
"Alain Gaillard" wrote in message[...]
Quand une appli appelle une fonction de dll, elle saute quelque part
dans ces deux Go de mémoire haute puis de là saute dans la mémoire
*physique* où est effectivement chargée la dll. Et cette dll ne
réside qu'une fois en mémoire physique.
Pour un process donné oui... Pour deux process utilisant la meme DLL,
je ne suis pas certain que cette DLL ne soit pas physiquement chargé
2 fois...
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Jean-Claude BELLAMY a écrit :
"DLLs provide a way to modularize applications so that functionality can
be updated and reused more easily. They also help reduce memory overhead
when several applications use the same functionality at the same time,
because although each application gets its own copy of the data, they
can share the code"
Jean-Claude BELLAMY a écrit :
"DLLs provide a way to modularize applications so that functionality can
be updated and reused more easily. They also help reduce memory overhead
when several applications use the same functionality at the same time,
because although each application gets its own copy of the data, they
can share the code"
Jean-Claude BELLAMY a écrit :
"DLLs provide a way to modularize applications so that functionality can
be updated and reused more easily. They also help reduce memory overhead
when several applications use the same functionality at the same time,
because although each application gets its own copy of the data, they
can share the code"
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Exact !!!
Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui concerne
l'encombrement mémoire.
Jean-Claude BELLAMY wrote:
[...]
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 :-).
Jean-Claude BELLAMY wrote:
[...]
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 :-).
Jean-Claude BELLAMY wrote:
[...]
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 :-).
"kanze" a écrit dans le message de news:
Rémy wrote:
>> Nous utilisons des DLL (en fait des .so) pour les modules
>> communs d'applications composées de plusieurs (dizaines) de
>> processus. Ca n'apporte rien fonctionnellement par rapport
>> à l'édition de liens statique, mais ça économise
>> considérablement la mémoire car le code n'est présent
>> qu'une fois en mémoire.
> En es-tu certain ? Ce n'est pas ce que j'ai compris
> jusqu'ici, et ça ne correspond pas au nom. Au moins sous
> Windows : je sais que la taille était bien la motivation
> principale des « shared objects » sous Sun OS, dans le
> temps, mais je croyais qu'il s'agissait principalement de la
> taille sur disque (à une époque où la taille des disques se
> mesurait en Mo, et non Go, et que la taille de la
> bibliothèque graphique était bien plusieurs Mo).
Oui (en tout cas sur les OS sur lesquels je travaille
habituellement : Sun OS, HP-UX, Tru 64 et Linux.
> C'est possible que l'image en mémoire soit partagé ; c'est
> même l'idée derrière le PIC (« position independant code »,
> mais ça augmente aussi la vitesse de chargement de façon
> notable, même si l'image n'est pas partagé).
Oui, aussi.
> Mais ça suppose aussi que l'objet
> partagé ne réfère jamais à rien dans le main,
Effectivement, il vaut mieux que le .so ne réfère rien dans le main...
Mais pour des composants communs, il vaut mieux ne pas
dépendre de l'utilisateur. Seulement d'autres composants
communs et encore, en évitant les dépendances circulaires...
> et que s'il réfère à quelque chose dans un autre objet
> partagé (libc, par exemple), que cet autre objet soit lié à
> la même adresse dans tous les exécutables (rélative à
> l'adresse de mon objet partagé, au moins).
Ma foi, je pense que c'est le boulot de l'édition de lien dynamique
d'assurer que ça marche.
Je ne sais pas s'il est nécessaire que les objets soient à la
même adresse dans tous les exécutables ?
>> Par ailleurs, ça permet de livrer les corrections des
>> modules communs sans que le programme les utilisant n'ait à
>> être relinké.
> C'est justement le gros problème. L'utilisateur finit très
> vite avec un melange de versions incompatibles.
Il y a un travail sérieux pour s'assurer de la compatibilité
ascendante. Il n'y a pas de "mélange" de version car (dans
notre cas) une nouvelle version remplace la précédente (les
composants communs sont installés une seule fois sur la
machine et pas avec chaque exécutable).
> Ici, ils avaient fait à peu près pareil, avec l'idée
> qu'effectivement, la plupart des bibliothèques servaient à
> plusieurs exécutables. Seulement, juste au moment où j'y
> suis arrivé, on a eu des crashs en production parce que
> $LD_LIBRARY_PATH ne désignait pas le chemin vers la bonne
> version de la bibliothèque
Problème effectivement si on installe plusieurs versions sur
la même machine
> -- un peu de récherche a montré
> qu'en fait, les versions des exécutables (livrées par des
> équipes différentes) étaient telles que chaque exécutable avait
> besoin d'une version différente des bibliothèques.
Si chacun fait évoluer les composants communs de façon
incompatible... Eh bien, ils ne sont plus communs...
Je pense que ce n'est faisable qu'avec une organisation
adaptée. Dans notre cas, il y a une équipe chargée de toutes
les livraisons qui réceptionne les sources de tous les
produits (communs ou pas), recompile tout sur une machine
dédiée et génère les produits à installer.
> Les bibliothèques étaient donc présentes autant de fois
> qu'il y avait d'exécutables, dans de versions différentes.
> Pas de gain de place, donc, et une risque réele de chopper
> la mauvaise version.
C'est comme beaucoup d'outils, si on s'en sert mal (ou sans
les contrôler), on peut faire de gros dégâts ;-)
"kanze" <kanze@gabi-soft.fr> a écrit dans le message de news:
1157698028.830708.257320@m79g2000cwm.googlegroups.com...
Rémy wrote:
>> Nous utilisons des DLL (en fait des .so) pour les modules
>> communs d'applications composées de plusieurs (dizaines) de
>> processus. Ca n'apporte rien fonctionnellement par rapport
>> à l'édition de liens statique, mais ça économise
>> considérablement la mémoire car le code n'est présent
>> qu'une fois en mémoire.
> En es-tu certain ? Ce n'est pas ce que j'ai compris
> jusqu'ici, et ça ne correspond pas au nom. Au moins sous
> Windows : je sais que la taille était bien la motivation
> principale des « shared objects » sous Sun OS, dans le
> temps, mais je croyais qu'il s'agissait principalement de la
> taille sur disque (à une époque où la taille des disques se
> mesurait en Mo, et non Go, et que la taille de la
> bibliothèque graphique était bien plusieurs Mo).
Oui (en tout cas sur les OS sur lesquels je travaille
habituellement : Sun OS, HP-UX, Tru 64 et Linux.
> C'est possible que l'image en mémoire soit partagé ; c'est
> même l'idée derrière le PIC (« position independant code »,
> mais ça augmente aussi la vitesse de chargement de façon
> notable, même si l'image n'est pas partagé).
Oui, aussi.
> Mais ça suppose aussi que l'objet
> partagé ne réfère jamais à rien dans le main,
Effectivement, il vaut mieux que le .so ne réfère rien dans le main...
Mais pour des composants communs, il vaut mieux ne pas
dépendre de l'utilisateur. Seulement d'autres composants
communs et encore, en évitant les dépendances circulaires...
> et que s'il réfère à quelque chose dans un autre objet
> partagé (libc, par exemple), que cet autre objet soit lié à
> la même adresse dans tous les exécutables (rélative à
> l'adresse de mon objet partagé, au moins).
Ma foi, je pense que c'est le boulot de l'édition de lien dynamique
d'assurer que ça marche.
Je ne sais pas s'il est nécessaire que les objets soient à la
même adresse dans tous les exécutables ?
>> Par ailleurs, ça permet de livrer les corrections des
>> modules communs sans que le programme les utilisant n'ait à
>> être relinké.
> C'est justement le gros problème. L'utilisateur finit très
> vite avec un melange de versions incompatibles.
Il y a un travail sérieux pour s'assurer de la compatibilité
ascendante. Il n'y a pas de "mélange" de version car (dans
notre cas) une nouvelle version remplace la précédente (les
composants communs sont installés une seule fois sur la
machine et pas avec chaque exécutable).
> Ici, ils avaient fait à peu près pareil, avec l'idée
> qu'effectivement, la plupart des bibliothèques servaient à
> plusieurs exécutables. Seulement, juste au moment où j'y
> suis arrivé, on a eu des crashs en production parce que
> $LD_LIBRARY_PATH ne désignait pas le chemin vers la bonne
> version de la bibliothèque
Problème effectivement si on installe plusieurs versions sur
la même machine
> -- un peu de récherche a montré
> qu'en fait, les versions des exécutables (livrées par des
> équipes différentes) étaient telles que chaque exécutable avait
> besoin d'une version différente des bibliothèques.
Si chacun fait évoluer les composants communs de façon
incompatible... Eh bien, ils ne sont plus communs...
Je pense que ce n'est faisable qu'avec une organisation
adaptée. Dans notre cas, il y a une équipe chargée de toutes
les livraisons qui réceptionne les sources de tous les
produits (communs ou pas), recompile tout sur une machine
dédiée et génère les produits à installer.
> Les bibliothèques étaient donc présentes autant de fois
> qu'il y avait d'exécutables, dans de versions différentes.
> Pas de gain de place, donc, et une risque réele de chopper
> la mauvaise version.
C'est comme beaucoup d'outils, si on s'en sert mal (ou sans
les contrôler), on peut faire de gros dégâts ;-)
"kanze" a écrit dans le message de news:
Rémy wrote:
>> Nous utilisons des DLL (en fait des .so) pour les modules
>> communs d'applications composées de plusieurs (dizaines) de
>> processus. Ca n'apporte rien fonctionnellement par rapport
>> à l'édition de liens statique, mais ça économise
>> considérablement la mémoire car le code n'est présent
>> qu'une fois en mémoire.
> En es-tu certain ? Ce n'est pas ce que j'ai compris
> jusqu'ici, et ça ne correspond pas au nom. Au moins sous
> Windows : je sais que la taille était bien la motivation
> principale des « shared objects » sous Sun OS, dans le
> temps, mais je croyais qu'il s'agissait principalement de la
> taille sur disque (à une époque où la taille des disques se
> mesurait en Mo, et non Go, et que la taille de la
> bibliothèque graphique était bien plusieurs Mo).
Oui (en tout cas sur les OS sur lesquels je travaille
habituellement : Sun OS, HP-UX, Tru 64 et Linux.
> C'est possible que l'image en mémoire soit partagé ; c'est
> même l'idée derrière le PIC (« position independant code »,
> mais ça augmente aussi la vitesse de chargement de façon
> notable, même si l'image n'est pas partagé).
Oui, aussi.
> Mais ça suppose aussi que l'objet
> partagé ne réfère jamais à rien dans le main,
Effectivement, il vaut mieux que le .so ne réfère rien dans le main...
Mais pour des composants communs, il vaut mieux ne pas
dépendre de l'utilisateur. Seulement d'autres composants
communs et encore, en évitant les dépendances circulaires...
> et que s'il réfère à quelque chose dans un autre objet
> partagé (libc, par exemple), que cet autre objet soit lié à
> la même adresse dans tous les exécutables (rélative à
> l'adresse de mon objet partagé, au moins).
Ma foi, je pense que c'est le boulot de l'édition de lien dynamique
d'assurer que ça marche.
Je ne sais pas s'il est nécessaire que les objets soient à la
même adresse dans tous les exécutables ?
>> Par ailleurs, ça permet de livrer les corrections des
>> modules communs sans que le programme les utilisant n'ait à
>> être relinké.
> C'est justement le gros problème. L'utilisateur finit très
> vite avec un melange de versions incompatibles.
Il y a un travail sérieux pour s'assurer de la compatibilité
ascendante. Il n'y a pas de "mélange" de version car (dans
notre cas) une nouvelle version remplace la précédente (les
composants communs sont installés une seule fois sur la
machine et pas avec chaque exécutable).
> Ici, ils avaient fait à peu près pareil, avec l'idée
> qu'effectivement, la plupart des bibliothèques servaient à
> plusieurs exécutables. Seulement, juste au moment où j'y
> suis arrivé, on a eu des crashs en production parce que
> $LD_LIBRARY_PATH ne désignait pas le chemin vers la bonne
> version de la bibliothèque
Problème effectivement si on installe plusieurs versions sur
la même machine
> -- un peu de récherche a montré
> qu'en fait, les versions des exécutables (livrées par des
> équipes différentes) étaient telles que chaque exécutable avait
> besoin d'une version différente des bibliothèques.
Si chacun fait évoluer les composants communs de façon
incompatible... Eh bien, ils ne sont plus communs...
Je pense que ce n'est faisable qu'avec une organisation
adaptée. Dans notre cas, il y a une équipe chargée de toutes
les livraisons qui réceptionne les sources de tous les
produits (communs ou pas), recompile tout sur une machine
dédiée et génère les produits à installer.
> Les bibliothèques étaient donc présentes autant de fois
> qu'il y avait d'exécutables, dans de versions différentes.
> Pas de gain de place, donc, et une risque réele de chopper
> la mauvaise version.
C'est comme beaucoup d'outils, si on s'en sert mal (ou sans
les contrôler), on peut faire de gros dégâts ;-)
kanze a écrit :
> En es-tu certain ?
Il peut l'être sous Windows.
> Ce n'est pas ce que j'ai compris jusqu'ici, et ça ne
> correspond pas au nom. Au moins sous Windows
Mon bon James, tu manques un peu d'expérience dans le domaine
;) (pardonne moi mais je n'ai pas pu m'en empêcher:) )
Sous Windows les dll ne sont chargées qu'une fois en mémoire,
ce qui est heureux car sinon tout le système, qui est
constitué uniquement de dll serait chargé par chaque
application. kernel32.dll, user32.dll. Tu imagines ?
Le mécanisme de gestion de mémoire virtuelle est assez
particulier. En quelques mots disons que toute application se
voit attribuer les 4 Go adressables, mais toute cette zone est
une zone de mémoire virtuelle, pas physique évidemment. Les 2
go de mémoire basse sont à son usage. Dans les 2 Go de
mémoire haute sont installée les tables de saut vers les dll
utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute
quelque part dans ces deux Go de mémoire haute puis de là
saute dans la mémoire *physique* où est effectivement chargée
la dll. Et cette dll ne réside qu'une fois en mémoire
physique.
kanze a écrit :
> En es-tu certain ?
Il peut l'être sous Windows.
> Ce n'est pas ce que j'ai compris jusqu'ici, et ça ne
> correspond pas au nom. Au moins sous Windows
Mon bon James, tu manques un peu d'expérience dans le domaine
;) (pardonne moi mais je n'ai pas pu m'en empêcher:) )
Sous Windows les dll ne sont chargées qu'une fois en mémoire,
ce qui est heureux car sinon tout le système, qui est
constitué uniquement de dll serait chargé par chaque
application. kernel32.dll, user32.dll. Tu imagines ?
Le mécanisme de gestion de mémoire virtuelle est assez
particulier. En quelques mots disons que toute application se
voit attribuer les 4 Go adressables, mais toute cette zone est
une zone de mémoire virtuelle, pas physique évidemment. Les 2
go de mémoire basse sont à son usage. Dans les 2 Go de
mémoire haute sont installée les tables de saut vers les dll
utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute
quelque part dans ces deux Go de mémoire haute puis de là
saute dans la mémoire *physique* où est effectivement chargée
la dll. Et cette dll ne réside qu'une fois en mémoire
physique.
kanze a écrit :
> En es-tu certain ?
Il peut l'être sous Windows.
> Ce n'est pas ce que j'ai compris jusqu'ici, et ça ne
> correspond pas au nom. Au moins sous Windows
Mon bon James, tu manques un peu d'expérience dans le domaine
;) (pardonne moi mais je n'ai pas pu m'en empêcher:) )
Sous Windows les dll ne sont chargées qu'une fois en mémoire,
ce qui est heureux car sinon tout le système, qui est
constitué uniquement de dll serait chargé par chaque
application. kernel32.dll, user32.dll. Tu imagines ?
Le mécanisme de gestion de mémoire virtuelle est assez
particulier. En quelques mots disons que toute application se
voit attribuer les 4 Go adressables, mais toute cette zone est
une zone de mémoire virtuelle, pas physique évidemment. Les 2
go de mémoire basse sont à son usage. Dans les 2 Go de
mémoire haute sont installée les tables de saut vers les dll
utilisées par l'application, comme par exemple kernel32.dll,
user32.dll, madll.dll. Je parle bien ici de mémoire virtuelle.
Quand une appli appelle une fonction de dll, elle saute
quelque part dans ces deux Go de mémoire haute puis de là
saute dans la mémoire *physique* où est effectivement chargée
la dll. Et cette dll ne réside qu'une fois en mémoire
physique.
Justement, je n'ai pas encore pris de vacances ! (il faut je j'attende
dimanche 17)
Oui, j'ai répondu trop vite et j'ai dit une conceté !
(d'ailleurs au moment où j'ai posté j'avais un pressentiment!)
Mais je n'ai jamais confondu mémoire et sur disque, ni données et
code, quand même !
Si bien que j'ai extrapolé un peu trop rapidement et me suis mélangé
les octets...
Désolé ..
Justement, je n'ai pas encore pris de vacances ! (il faut je j'attende
dimanche 17)
Oui, j'ai répondu trop vite et j'ai dit une conceté !
(d'ailleurs au moment où j'ai posté j'avais un pressentiment!)
Mais je n'ai jamais confondu mémoire et sur disque, ni données et
code, quand même !
Si bien que j'ai extrapolé un peu trop rapidement et me suis mélangé
les octets...
Désolé ..
Justement, je n'ai pas encore pris de vacances ! (il faut je j'attende
dimanche 17)
Oui, j'ai répondu trop vite et j'ai dit une conceté !
(d'ailleurs au moment où j'ai posté j'avais un pressentiment!)
Mais je n'ai jamais confondu mémoire et sur disque, ni données et
code, quand même !
Si bien que j'ai extrapolé un peu trop rapidement et me suis mélangé
les octets...
Désolé ..
Jean-Claude BELLAMY a écrit :
> Exact !!!
FAUX!!!
> Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui
> concerne l'encombrement mémoire.
Regardez par exemple les dépendances du Notepad. Il utilise
Kernel32.dll, gdi32.dll, user32.dll, comctl32.dll,
shell32.dll, msvcrt.dll, pour ne citer que ça et tout son
processus n'occupe que 600k environ. Si toutes ces dll étaient
chargées en mémoire au lancement du notepad, ça ferait
beaucoup plus.
Vous imaginez un peu le notepad chargeant le noyau de windows
?? (kernel32.dll) Une application qui chargeait le noyau de
son OS c'est quand même le monde à l'envers. Assez
psychédélique ;-) :-)
La MSDN est tout à fait claire au sujet des dll:
"DLLs provide a way to modularize applications so that
functionality can be updated and reused more easily. They also
help reduce memory overhead when several applications use the
same functionality at the same time, because although each
application gets its own copy of the data, they can share the
code"
Jean-Claude BELLAMY a écrit :
> Exact !!!
FAUX!!!
> Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui
> concerne l'encombrement mémoire.
Regardez par exemple les dépendances du Notepad. Il utilise
Kernel32.dll, gdi32.dll, user32.dll, comctl32.dll,
shell32.dll, msvcrt.dll, pour ne citer que ça et tout son
processus n'occupe que 600k environ. Si toutes ces dll étaient
chargées en mémoire au lancement du notepad, ça ferait
beaucoup plus.
Vous imaginez un peu le notepad chargeant le noyau de windows
?? (kernel32.dll) Une application qui chargeait le noyau de
son OS c'est quand même le monde à l'envers. Assez
psychédélique ;-) :-)
La MSDN est tout à fait claire au sujet des dll:
"DLLs provide a way to modularize applications so that
functionality can be updated and reused more easily. They also
help reduce memory overhead when several applications use the
same functionality at the same time, because although each
application gets its own copy of the data, they can share the
code"
Jean-Claude BELLAMY a écrit :
> Exact !!!
FAUX!!!
> Ce qui retire d'ailleurs pas mal d'intérêt aux DLL en ce qui
> concerne l'encombrement mémoire.
Regardez par exemple les dépendances du Notepad. Il utilise
Kernel32.dll, gdi32.dll, user32.dll, comctl32.dll,
shell32.dll, msvcrt.dll, pour ne citer que ça et tout son
processus n'occupe que 600k environ. Si toutes ces dll étaient
chargées en mémoire au lancement du notepad, ça ferait
beaucoup plus.
Vous imaginez un peu le notepad chargeant le noyau de windows
?? (kernel32.dll) Une application qui chargeait le noyau de
son OS c'est quand même le monde à l'envers. Assez
psychédélique ;-) :-)
La MSDN est tout à fait claire au sujet des dll:
"DLLs provide a way to modularize applications so that
functionality can be updated and reused more easily. They also
help reduce memory overhead when several applications use the
same functionality at the same time, because although each
application gets its own copy of the data, they can share the
code"
