Pour avoir bossé en intégration/déploiement (donc côté pas dev), j'ai compris que les utilisateurs (ceux qui compte donc) ont exactement l'avis inverse.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
J'ai comme l'impression que la toute puissance du développeur est de plus en plus néfaste pour l'utilisateur. Je me suis bien trouvé con le jour où j'ai dû expliquer l'intérêt de corba à un utilisateur : il n'en a rien à foutre des avantages de l'intégration multi-langages, de la visionunifiée des objets, et comme la configuration des ORB n'est pas unifiée, ben lui il a que des inconvénients.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.
[^] # Re: En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.