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...
"Alain Gaillard" wrote in message news:450156cb$0$5106$ > 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"
Ha ouai, chaque process à ses donnée propres de ses DLL, ca devrait suffire effectivement...
J'espère que c'est pareil sous Unix aussi:-).
-- 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 wrote:
"Alain Gaillard" <alain_gaillard28@hotmail.fr> wrote in message
news:450156cb$0$5106$ba4acef3@news.orange.fr...
> 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"
Ha ouai, chaque process à ses donnée propres de ses DLL, ca
devrait suffire effectivement...
J'espère que c'est pareil sous Unix aussi:-).
--
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 in message news:450156cb$0$5106$ > 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"
Ha ouai, chaque process à ses donnée propres de ses DLL, ca devrait suffire effectivement...
J'espère que c'est pareil sous Unix aussi:-).
-- 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\)
kanze wrote:
Aucun processus utilisateur n'a même directement accès au noyau. Heureusement, d'ailleurs.
Tu m'offres combien si j'y arrive ?
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
kanze wrote:
Aucun processus utilisateur n'a même directement accès au noyau.
Heureusement, d'ailleurs.
Aucun processus utilisateur n'a même directement accès au noyau. Heureusement, d'ailleurs.
Tu m'offres combien si j'y arrive ?
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Alain Gaillard
kanze a écrit :
montre environ 1 Mo pour Notepad, et Kernel32.dll n'est pas si
mais il y a toutes les autres dll, regarde les dépendances que j'ai citées plus haut.
gros que ça. Et la taille du fichier Notepad.exe n'est que 50Ko.
Il va falloir que tu upgrade ton notepad; la dernière version en date fait 69 k
Il lui faut aussi un tas Et il y a les tables de saut dont j'ai parlé plus haut.
Aucun processus utilisateur n'a même directement accès au noyau.
Je n'ai rien dit de tel
Heureusement, d'ailleurs.
Oui.
Reste à savoir comment il s'arrange pour rétrouver ces données sans imposer qu'il soit liées à la même adresse dans dans tous les processus.. Comment fait VC++ pour résoudre ce problème.
VC++ ne fait rien. C'est le système qui le fait. Dans l'exécutable qui est un format baptisé PE et documenté par Kro$oft. Il y des des sections décrivant les dépendances. Soit telles dlls et telles fonctions. L'éditeur de liens (disosn VC globalement) crée ces sectiosn et son rôle s'arrête là C'est ensuite le système qui fait tout. Quand un exécutable est chargé, ces sections sont analysées. Si une dll requise est déjà chargée, comme c'est toujours le cas de kernel32 par exemple, la table de sauts est construite. Sinon la dll est chargée puis la table de saut est construite. Cette dernière dll ne sera pas chargée si une deuxième application s'en sert. Seule une table de saut est construite dans les 2 Go supérieurs de l'appli.
Tout ce mécanisme je le connais très très bien. A une époque j'avais écrit un outil pour modifier les table de saut et garder une trace des appel à certaines fonctions des dll systèmes dans un log. Et puis tout ce que je dis est documenté par Kro$oft. Chacun peut vérifer.
-- Alain
kanze a écrit :
montre environ 1 Mo pour Notepad, et Kernel32.dll n'est pas si
mais il y a toutes les autres dll, regarde les dépendances que j'ai
citées plus haut.
gros que ça. Et la taille du fichier Notepad.exe n'est que 50Ko.
Il va falloir que tu upgrade ton notepad; la dernière version en date
fait 69 k
Il lui faut aussi un tas
Et il y a les tables de saut dont j'ai parlé plus haut.
Aucun processus utilisateur n'a même directement accès au noyau.
Je n'ai rien dit de tel
Heureusement, d'ailleurs.
Oui.
Reste à savoir comment il s'arrange pour rétrouver ces données
sans imposer qu'il soit liées à la même adresse dans dans tous
les processus.. Comment fait VC++ pour résoudre ce problème.
VC++ ne fait rien. C'est le système qui le fait.
Dans l'exécutable qui est un format baptisé PE et documenté par Kro$oft.
Il y des des sections décrivant les dépendances. Soit telles dlls et
telles fonctions. L'éditeur de liens (disosn VC globalement) crée ces
sectiosn et son rôle s'arrête là
C'est ensuite le système qui fait tout. Quand un exécutable est chargé,
ces sections sont analysées. Si une dll requise est déjà chargée, comme
c'est toujours le cas de kernel32 par exemple, la table de sauts est
construite. Sinon la dll est chargée puis la table de saut est
construite. Cette dernière dll ne sera pas chargée si une deuxième
application s'en sert. Seule une table de saut est construite dans les 2
Go supérieurs de l'appli.
Tout ce mécanisme je le connais très très bien. A une époque j'avais
écrit un outil pour modifier les table de saut et garder une trace des
appel à certaines fonctions des dll systèmes dans un log. Et puis tout
ce que je dis est documenté par Kro$oft. Chacun peut vérifer.
montre environ 1 Mo pour Notepad, et Kernel32.dll n'est pas si
mais il y a toutes les autres dll, regarde les dépendances que j'ai citées plus haut.
gros que ça. Et la taille du fichier Notepad.exe n'est que 50Ko.
Il va falloir que tu upgrade ton notepad; la dernière version en date fait 69 k
Il lui faut aussi un tas Et il y a les tables de saut dont j'ai parlé plus haut.
Aucun processus utilisateur n'a même directement accès au noyau.
Je n'ai rien dit de tel
Heureusement, d'ailleurs.
Oui.
Reste à savoir comment il s'arrange pour rétrouver ces données sans imposer qu'il soit liées à la même adresse dans dans tous les processus.. Comment fait VC++ pour résoudre ce problème.
VC++ ne fait rien. C'est le système qui le fait. Dans l'exécutable qui est un format baptisé PE et documenté par Kro$oft. Il y des des sections décrivant les dépendances. Soit telles dlls et telles fonctions. L'éditeur de liens (disosn VC globalement) crée ces sectiosn et son rôle s'arrête là C'est ensuite le système qui fait tout. Quand un exécutable est chargé, ces sections sont analysées. Si une dll requise est déjà chargée, comme c'est toujours le cas de kernel32 par exemple, la table de sauts est construite. Sinon la dll est chargée puis la table de saut est construite. Cette dernière dll ne sera pas chargée si une deuxième application s'en sert. Seule une table de saut est construite dans les 2 Go supérieurs de l'appli.
Tout ce mécanisme je le connais très très bien. A une époque j'avais écrit un outil pour modifier les table de saut et garder une trace des appel à certaines fonctions des dll systèmes dans un log. Et puis tout ce que je dis est documenté par Kro$oft. Chacun peut vérifer.
-- Alain
Alain Gaillard
Arnold McDonald (AMcD) a écrit :
kanze wrote:
Aucun processus utilisateur n'a même directement accès au noyau. Heureusement, d'ailleurs.
Tu m'offres combien si j'y arrive ?
Oui en plus sous Windows, on peut bricoler
-- Alain
Arnold McDonald (AMcD) a écrit :
kanze wrote:
Aucun processus utilisateur n'a même directement accès au noyau.
Heureusement, d'ailleurs.
Aucun processus utilisateur n'a même directement accès au noyau. Heureusement, d'ailleurs.
Tu m'offres combien si j'y arrive ?
Oui en plus sous Windows, on peut bricoler
-- Alain
Alain Gaillard
kanze a écrit :
J'aurais imaginé que ces DLL ne contient que le mapping de l'API C aux véritables appels systèmes (qui n'était pas des call dans le temps, parce qu'il fallait passer en mode superuser, masquer les interruptions, etc.).
Le mécanisme de la table de saut est complexe. Il y a effectivment un basculement en mode superuser lors des appels systèmes. II y a table de saut, mais l'adresse où on saute est telle que le basculement se produit. C'est un peu compliéqué à expliquer, mais encore une fois c'ets documentée chez kro$oft
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.
Il lui faut 2 Go pour ça ?
Non je n'ai pas dit ça. Il lui faut les octets *physiques* qu'il lui faut. Mais chaque sous Windows chaque appli se voit octroyer tout l'espace d'adressage systèmatiquement mais virtuellement. Sois 4 Go en 32 bits. Et les tables de sauts sont installées dans les 2 Go supérieurs, justement parce qu'être là participe au mécanisme de basculement mentionné plus haut.
Pour les sauts dans le code, je comprends bien comment ça marche, bien que j'ai du mal à croire que tout le monde soit d'accord pour le prix de l'indirection supplémentaire.
Microsoft ne te demand pas d'être d'accord. c'ets comme ça et c'est tout.
Je ne trouve pas d'option pareil dans VC++
Mon bon James, tu manques d'expérience dans le domaine ;) Il n'y a pas d'option dans VC++ pour la bonne raison que ce n'est pas son rôle. Lis mon autre poste dans cette discussion.
-- Alain
kanze a écrit :
J'aurais imaginé que ces DLL ne contient que le mapping de l'API
C aux véritables appels systèmes (qui n'était pas des call dans
le temps, parce qu'il fallait passer en mode superuser, masquer
les interruptions, etc.).
Le mécanisme de la table de saut est complexe. Il y a effectivment un
basculement en mode superuser lors des appels systèmes. II y a table de
saut, mais l'adresse où on saute est telle que le basculement se
produit. C'est un peu compliéqué à expliquer, mais encore une fois c'ets
documentée chez kro$oft
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.
Il lui faut 2 Go pour ça ?
Non je n'ai pas dit ça.
Il lui faut les octets *physiques* qu'il lui faut.
Mais chaque sous Windows chaque appli se voit octroyer tout l'espace
d'adressage systèmatiquement mais virtuellement. Sois 4 Go en 32 bits.
Et les tables de sauts sont installées dans les 2 Go supérieurs,
justement parce qu'être là participe au mécanisme de basculement
mentionné plus haut.
Pour les sauts dans le code, je comprends bien comment ça
marche, bien que j'ai du mal à croire que tout le monde soit
d'accord pour le prix de l'indirection supplémentaire.
Microsoft ne te demand pas d'être d'accord. c'ets comme ça et c'est tout.
Je ne trouve pas d'option pareil dans VC++
Mon bon James, tu manques d'expérience dans le domaine ;)
Il n'y a pas d'option dans VC++ pour la bonne raison que ce n'est pas
son rôle. Lis mon autre poste dans cette discussion.
J'aurais imaginé que ces DLL ne contient que le mapping de l'API C aux véritables appels systèmes (qui n'était pas des call dans le temps, parce qu'il fallait passer en mode superuser, masquer les interruptions, etc.).
Le mécanisme de la table de saut est complexe. Il y a effectivment un basculement en mode superuser lors des appels systèmes. II y a table de saut, mais l'adresse où on saute est telle que le basculement se produit. C'est un peu compliéqué à expliquer, mais encore une fois c'ets documentée chez kro$oft
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.
Il lui faut 2 Go pour ça ?
Non je n'ai pas dit ça. Il lui faut les octets *physiques* qu'il lui faut. Mais chaque sous Windows chaque appli se voit octroyer tout l'espace d'adressage systèmatiquement mais virtuellement. Sois 4 Go en 32 bits. Et les tables de sauts sont installées dans les 2 Go supérieurs, justement parce qu'être là participe au mécanisme de basculement mentionné plus haut.
Pour les sauts dans le code, je comprends bien comment ça marche, bien que j'ai du mal à croire que tout le monde soit d'accord pour le prix de l'indirection supplémentaire.
Microsoft ne te demand pas d'être d'accord. c'ets comme ça et c'est tout.
Je ne trouve pas d'option pareil dans VC++
Mon bon James, tu manques d'expérience dans le domaine ;) Il n'y a pas d'option dans VC++ pour la bonne raison que ce n'est pas son rôle. Lis mon autre poste dans cette discussion.
-- Alain
Cyrille Szymanski
"Korchkidu" wrote in news:1157620977.812153.128320 @i3g2000cwc.googlegroups.com:
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
-- Cyrille Szymanski
"Korchkidu" <korchkidu@gmail.com> wrote in news:1157620977.812153.128320
@i3g2000cwc.googlegroups.com:
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque
statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
"Korchkidu" wrote in news:1157620977.812153.128320 @i3g2000cwc.googlegroups.com:
> programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de > petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
ha ! j'y crois pas du tout . VB
Alain Gaillard
Cyrille Szymanski a écrit :
"Korchkidu" wrote in news:1157620977.812153.128320 @i3g2000cwc.googlegroups.com:
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
"pourrait": le conditionnel est vraiment ce qui convient. En ce qui concerne l'inlining le compilateur à le droit de faire exactement ce qu'il veut. Et quand on désassemble du code, on a souvent des surprises à ce niveau...
-- Alain
Cyrille Szymanski a écrit :
"Korchkidu" <korchkidu@gmail.com> wrote in news:1157620977.812153.128320
@i3g2000cwc.googlegroups.com:
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque
statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
"pourrait": le conditionnel est vraiment ce qui convient. En ce qui
concerne l'inlining le compilateur à le droit de faire exactement ce
qu'il veut. Et quand on désassemble du code, on a souvent des surprises
à ce niveau...
"Korchkidu" wrote in news:1157620977.812153.128320 @i3g2000cwc.googlegroups.com:
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de petite taille n'est pas forcement une bonne idee...
Un export de DLL ne pourra jamais être mis "inline". Pour une bibliothèque statique je n'en sais rien, mais je me dis que ça pourrait être le cas ?
"pourrait": le conditionnel est vraiment ce qui convient. En ce qui concerne l'inlining le compilateur à le droit de faire exactement ce qu'il veut. Et quand on désassemble du code, on a souvent des surprises à ce niveau...
-- Alain
Loïc Joly
Alain Gaillard a écrit :
C'est ensuite le système qui fait tout. Quand un exécutable est chargé, ces sections sont analysées.
Est-ce que le mécanisme est identique pour les DLL chargées dynamiquement ?
-- Loïc
Alain Gaillard a écrit :
C'est ensuite le système qui fait tout. Quand un exécutable est chargé,
ces sections sont analysées.
Est-ce que le mécanisme est identique pour les DLL chargées dynamiquement ?
