contrairement à, par exemple, Windows, où chaque logiciel embarque justement ses propres versions de chaque librairie
Ben, c'est factuellement faux.
Beaucoup de logiciels utilisent le .NET Framework (2.0, 4.0, 4.5, 4.6, 4.7, à ce jour), DirectX (1/2/4/5/6/7/8/9/10/11/12), le runtime MSVC (beaucoup trop de versions), les API du kernel (kernel32, ...), les API de User32.dll (du genre LoadIcon, ou pour lire/écrire dans le presse-papier, parmi beaucoup d'autres fonctions), et j'en passe.
Il y a-t-il une copie des bibliothèques de ces composants dans le dossier d'installation de l'application ?
Euh, non. Jamais.
Donc dire "chaque logiciel embarque justement ses propres versions de chaque librairie", c'est méconnaître Windows.
Dans le dossier d'installation, on met les bibliothèques qu'on ne veut pas partager avec le système, c'tout.
Mais celles qui font partie de Windows et que tout le monde utilise, on ne les met pas dans le dossier du programme (Runtime MSVC, kernel, ... voir plus haut), ce serait la folie.
On pourrait en mettre certaines dans le dossier système, mais pour 7 Mo de bibliothèque (donc 4 pour la libxml, et 1,2 Mo pour libiconv), on va pas se rajouter des problèmes de partage/mise à jour de bibliothèques partagées, tout ça pour économiser trois fois rien et termes d'espace disque.
Si on a un besoin absolu de partager des bibliothèques au niveau du système, il y a :
- .NET, où ce problème est réglé depuis le début (on met ça dans le GAC et c'est marre)
- OU (pour le code natif), on peut utiliser le Side-by-Side Assemblies : https://msdn.microsoft.com/fr-fr/library/windows/desktop/ff951640(v=vs.85).aspx
Il faut aussi distinguer les installeurs embarquant un programme d'installation d'une variante de DirectX / MSVC / .NET, qui selon la version de Windows cible, ne sont pas forcément installés.
Ces installeurs sont des exécutables librement distribuables fournies par Microsoft, qui ne font que d'installer ces éléments au niveau du système, pas du programme.
Windows XP par exemple n'inclut pas par défaut aucun élément .NET.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .
Posté par xcomcmdr . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 3. Dernière modification le 15 février 2018 à 17:39.
Ben, c'est factuellement faux.
Beaucoup de logiciels utilisent le .NET Framework (2.0, 4.0, 4.5, 4.6, 4.7, à ce jour), DirectX (1/2/4/5/6/7/8/9/10/11/12), le runtime MSVC (beaucoup trop de versions), les API du kernel (kernel32, ...), les API de User32.dll (du genre LoadIcon, ou pour lire/écrire dans le presse-papier, parmi beaucoup d'autres fonctions), et j'en passe.
Il y a-t-il une copie des bibliothèques de ces composants dans le dossier d'installation de l'application ?
Euh, non. Jamais.
Donc dire "chaque logiciel embarque justement ses propres versions de chaque librairie", c'est méconnaître Windows.
Dans le dossier d'installation, on met les bibliothèques qu'on ne veut pas partager avec le système, c'tout.
Mais celles qui font partie de Windows et que tout le monde utilise, on ne les met pas dans le dossier du programme (Runtime MSVC, kernel, ... voir plus haut), ce serait la folie.
Regardons par exemple Notepad++ :
Que des DLL qui lui sont propre, et c'est normal.
On pourrait en mettre certaines dans le dossier système, mais pour 7 Mo de bibliothèque (donc 4 pour la libxml, et 1,2 Mo pour libiconv), on va pas se rajouter des problèmes de partage/mise à jour de bibliothèques partagées, tout ça pour économiser trois fois rien et termes d'espace disque.
Si on a un besoin absolu de partager des bibliothèques au niveau du système, il y a :
- .NET, où ce problème est réglé depuis le début (on met ça dans le GAC et c'est marre)
- OU (pour le code natif), on peut utiliser le Side-by-Side Assemblies :
https://msdn.microsoft.com/fr-fr/library/windows/desktop/ff951640(v=vs.85).aspx
Comme l'a fait Microsoft pour assurer la rétrocompatibilité :
https://blogs.msdn.microsoft.com/oldnewthing/20080129-00/?p=23663/
Il faut aussi distinguer les installeurs embarquant un programme d'installation d'une variante de DirectX / MSVC / .NET, qui selon la version de Windows cible, ne sont pas forcément installés.
Ces installeurs sont des exécutables librement distribuables fournies par Microsoft, qui ne font que d'installer ces éléments au niveau du système, pas du programme.
Windows XP par exemple n'inclut pas par défaut aucun élément .NET.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)