Loïc Joly writes:
|> wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
|> Pouvoir modifier le programme sans l'arrêter (dynamique)
C-à-d que je veux avoir accès à la version la plus récente
disponible dans l'environnement, c-à-d que je veux que la
bibliothèque chargée dépend de l'environnement.
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Sans doute s'agit-il de "langage" au sens de la localisation des
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
|> kanze@gabi-soft.fr wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
|> Pouvoir modifier le programme sans l'arrêter (dynamique)
C-à-d que je veux avoir accès à la version la plus récente
disponible dans l'environnement, c-à-d que je veux que la
bibliothèque chargée dépend de l'environnement.
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Sans doute s'agit-il de "langage" au sens de la localisation des
Loïc Joly writes:
|> wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
|> Pouvoir modifier le programme sans l'arrêter (dynamique)
C-à-d que je veux avoir accès à la version la plus récente
disponible dans l'environnement, c-à-d que je veux que la
bibliothèque chargée dépend de l'environnement.
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Sans doute s'agit-il de "langage" au sens de la localisation des
Loïc Joly writes:
|> wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
[...]
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Par exemple, windows fourni une spécification de ses DLL qui permet à
|> Travailler à plusieur entreprises sur un projet sans qu'une seule
|> soit un point de passage obligé pour de la recompilation
|> (statique)
??
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
|> kanze@gabi-soft.fr wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
[...]
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Par exemple, windows fourni une spécification de ses DLL qui permet à
|> Travailler à plusieur entreprises sur un projet sans qu'une seule
|> soit un point de passage obligé pour de la recompilation
|> (statique)
??
Loïc Joly writes:
|> wrote:
|> > En ce qui concerne les objets dynamiques que tu développes
|> > toi-même, au moins d'écire des bibliothèques avec un API
|> > importante (systèmes d'exploitation, bases de données,
|> > bibliothèques graphiques, etc.), à peu près la seule
|> > raison que je vois pour utiliser le chargement dynamique, c'est
|> > qu'on veut pouvoir choisir entre plusieurs bibliothèques lors
|> > de l'execution, pour que le comportement réel dépend de
|> > l'environement, les paramètres de la ligne de commande, les
|> > droits de l'utilisateur, etc. Ce qui suppose un chargement
|> > explicit de la bibliothèque.
|> D'autres utilisations existent :
[...]
|> Profiter d'une standardisation des bibliothèques dynamiques sur
|> un OS pour faire des programmes multi-langages (statique)
??
Par exemple, windows fourni une spécification de ses DLL qui permet à
|> Travailler à plusieur entreprises sur un projet sans qu'une seule
|> soit un point de passage obligé pour de la recompilation
|> (statique)
??
|> Certaines fonctionalités pas si rares que ça imposent sous
|> Windows de transmettre une fonction écrite dans une DLL (filtrage
|> global E/S par exemple, voir SetWindowsHookEx).
Il est aussi assez traditionnel de se servir d'un objet dynamique pour
libc sous Unix. Et alors ? On peut arguementer que c'est en fait ce
qu'on veut -- on veut la version de libc qui correspond à la version
de l'OS qui tourne sur la machine, et non celui qui tournait sur la
machine où on a fait l'édition de liens.
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux bien.
Qu'on livre une application sauscissonnée en dix DLL qui ne servent
qu'à cette application, je me démande bien pourquoi. En fin de
compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est la
possibilité à l'utilisateur d'avoir un mélange de versions qui
ne fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
|> Certaines fonctionalités pas si rares que ça imposent sous
|> Windows de transmettre une fonction écrite dans une DLL (filtrage
|> global E/S par exemple, voir SetWindowsHookEx).
Il est aussi assez traditionnel de se servir d'un objet dynamique pour
libc sous Unix. Et alors ? On peut arguementer que c'est en fait ce
qu'on veut -- on veut la version de libc qui correspond à la version
de l'OS qui tourne sur la machine, et non celui qui tournait sur la
machine où on a fait l'édition de liens.
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux bien.
Qu'on livre une application sauscissonnée en dix DLL qui ne servent
qu'à cette application, je me démande bien pourquoi. En fin de
compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est la
possibilité à l'utilisateur d'avoir un mélange de versions qui
ne fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
|> Certaines fonctionalités pas si rares que ça imposent sous
|> Windows de transmettre une fonction écrite dans une DLL (filtrage
|> global E/S par exemple, voir SetWindowsHookEx).
Il est aussi assez traditionnel de se servir d'un objet dynamique pour
libc sous Unix. Et alors ? On peut arguementer que c'est en fait ce
qu'on veut -- on veut la version de libc qui correspond à la version
de l'OS qui tourne sur la machine, et non celui qui tournait sur la
machine où on a fait l'édition de liens.
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux bien.
Qu'on livre une application sauscissonnée en dix DLL qui ne servent
qu'à cette application, je me démande bien pourquoi. En fin de
compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est la
possibilité à l'utilisateur d'avoir un mélange de versions qui
ne fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
James Kanze wrote in message
news:...
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux
bien. Qu'on livre une application sauscissonnée en dix DLL qui ne
servent qu'à cette application, je me démande bien pourquoi. En fin
de compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est
la possibilité à l'utilisateur d'avoir un mélange de versions qui ne
fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
C'est vrai. Ceci dit, sur des systèmes complexes, les librairies
dynamiques peuvent simplifier le déploiement et la mise à jour
(patchs), avec évidemment les risques de mélange de versions que cela
implique.
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
James Kanze <kanze@gabi-soft.fr> wrote in message
news:<86eku69q79.fsf@alex.gabi-soft.fr>...
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux
bien. Qu'on livre une application sauscissonnée en dix DLL qui ne
servent qu'à cette application, je me démande bien pourquoi. En fin
de compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est
la possibilité à l'utilisateur d'avoir un mélange de versions qui ne
fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
C'est vrai. Ceci dit, sur des systèmes complexes, les librairies
dynamiques peuvent simplifier le déploiement et la mise à jour
(patchs), avec évidemment les risques de mélange de versions que cela
implique.
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
James Kanze wrote in message
news:...
Qu'on le fasse une fois pour des raisons d'apprentissage, je veux
bien. Qu'on livre une application sauscissonnée en dix DLL qui ne
servent qu'à cette application, je me démande bien pourquoi. En fin
de compte, la seule chose qu'apportent les DLL dans ce cas-là, c'est
la possibilité à l'utilisateur d'avoir un mélange de versions qui ne
fonctionne pas correctement, et que tu ne peux pas dupliqué chez
toi.
C'est vrai. Ceci dit, sur des systèmes complexes, les librairies
dynamiques peuvent simplifier le déploiement et la mise à jour
(patchs), avec évidemment les risques de mélange de versions que cela
implique.
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
wrote:A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
.NET utilise le CRC du module, ce qui évite ce genre "d'oublis".
kanze@gabi-soft.fr wrote:
A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
.NET utilise le CRC du module, ce qui évite ce genre "d'oublis".
wrote:A noter que .NET offre un mécanisme intéressant de ce point de vue :
Par défaut (c'est modifiable par fichier de configuration), un
executable n'accepte de fonctionner qu'avec les DLL exactes contre
lesquelles il a été construit (numéro de version, CRC et
éventuellement signature).
Il y a quelque chose de semblable sous Unix, ou au moins sous Solaris.
Mais pour qu'il fonctionne, il faut qu'il y a une bonne gestion des
versions -- en fin de compte, c'est bien le programmeur qui determine,
explicitement ou implicitement, le numéro de version de la
bibliothèque. Et j'en ai vu plus d'une fois où le programmeur a
décidé à ne pas incrémenter la version après une modification.
.NET utilise le CRC du module, ce qui évite ce genre "d'oublis".
Jean-Marc Bourguet writes:
|> "Arnaud Debaene" writes:
|> > wrote:
|> > >> A noter que .NET offre un mécanisme intéressant de ce
|> > >> point de vue : Par défaut (c'est modifiable par fichier de
|> > >> configuration), un executable n'accepte de fonctionner qu'avec
|> > >> les DLL exactes contre lesquelles il a été construit
|> > >> (numéro de version, CRC et éventuellement signature).
|> > > Il y a quelque chose de semblable sous Unix, ou au moins sous
|> > > Solaris. Mais pour qu'il fonctionne, il faut qu'il y a une bonne
|> > > gestion des versions -- en fin de compte, c'est bien le
|> > > programmeur qui determine, explicitement ou implicitement, le
|> > > numéro de version de la bibliothèque. Et j'en ai vu plus
|> > > d'une fois où le programmeur a décidé à ne pas
|> > > incrémenter la version après une modification.
|> > .NET utilise le CRC du module, ce qui évite ce genre
|> > "d'oublis".
|> Vu que pour moi la version est une affaire de semantique, je ne
|> vois pas comment un CRC peut verifier la semantique. Meme si on
|> se contente d'un CRC sur l'interface, il faut etre plus sioux
|> parce qu'on peut fournir une bibliotheque qui a une interface
|> plus etendue.
Je ne connais pas le .net, mais au moins en C++ classique, un CRC
sur des définitions de classe pourrait être bien utile.
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> "Arnaud Debaene" <adebaene@club-internet.fr> writes:
|> > kanze@gabi-soft.fr wrote:
|> > >> A noter que .NET offre un mécanisme intéressant de ce
|> > >> point de vue : Par défaut (c'est modifiable par fichier de
|> > >> configuration), un executable n'accepte de fonctionner qu'avec
|> > >> les DLL exactes contre lesquelles il a été construit
|> > >> (numéro de version, CRC et éventuellement signature).
|> > > Il y a quelque chose de semblable sous Unix, ou au moins sous
|> > > Solaris. Mais pour qu'il fonctionne, il faut qu'il y a une bonne
|> > > gestion des versions -- en fin de compte, c'est bien le
|> > > programmeur qui determine, explicitement ou implicitement, le
|> > > numéro de version de la bibliothèque. Et j'en ai vu plus
|> > > d'une fois où le programmeur a décidé à ne pas
|> > > incrémenter la version après une modification.
|> > .NET utilise le CRC du module, ce qui évite ce genre
|> > "d'oublis".
|> Vu que pour moi la version est une affaire de semantique, je ne
|> vois pas comment un CRC peut verifier la semantique. Meme si on
|> se contente d'un CRC sur l'interface, il faut etre plus sioux
|> parce qu'on peut fournir une bibliotheque qui a une interface
|> plus etendue.
Je ne connais pas le .net, mais au moins en C++ classique, un CRC
sur des définitions de classe pourrait être bien utile.
Jean-Marc Bourguet writes:
|> "Arnaud Debaene" writes:
|> > wrote:
|> > >> A noter que .NET offre un mécanisme intéressant de ce
|> > >> point de vue : Par défaut (c'est modifiable par fichier de
|> > >> configuration), un executable n'accepte de fonctionner qu'avec
|> > >> les DLL exactes contre lesquelles il a été construit
|> > >> (numéro de version, CRC et éventuellement signature).
|> > > Il y a quelque chose de semblable sous Unix, ou au moins sous
|> > > Solaris. Mais pour qu'il fonctionne, il faut qu'il y a une bonne
|> > > gestion des versions -- en fin de compte, c'est bien le
|> > > programmeur qui determine, explicitement ou implicitement, le
|> > > numéro de version de la bibliothèque. Et j'en ai vu plus
|> > > d'une fois où le programmeur a décidé à ne pas
|> > > incrémenter la version après une modification.
|> > .NET utilise le CRC du module, ce qui évite ce genre
|> > "d'oublis".
|> Vu que pour moi la version est une affaire de semantique, je ne
|> vois pas comment un CRC peut verifier la semantique. Meme si on
|> se contente d'un CRC sur l'interface, il faut etre plus sioux
|> parce qu'on peut fournir une bibliotheque qui a une interface
|> plus etendue.
Je ne connais pas le .net, mais au moins en C++ classique, un CRC
sur des définitions de classe pourrait être bien utile.
