Comment Windows gère-t-il les dépendances de programme?

23

J'ai utilisé Linux pendant un certain temps et je me suis toujours demandé comment Windows pouvait gérer les dépendances de programmes comme apt-get , aptitude , Pacman , yum et d'autres gestionnaires de paquets. Parfois, mon gestionnaire de packages me disait que cette version de cette bibliothèque était nécessaire pour ce package ou qu'il y aurait un conflit.

Comment Windows gère-t-il tout cela?

windows package-management

— Nico
source

2

Windows ne gère pas les dépendances de version. La plupart des installateurs de versions le font. Si vous ne le connaissez pas déjà, consultez InnoSetup: jrsoftware.org/isinfo.php

— paulsm4

4

Il est probablement intéressant de noter que même dans vos exemples, ce n'est pas Linux en soi qui gère les dépendances - c'est le gestionnaire de paquets.

— GalacticCowboy

3

Comment Windows gère-t-il les dépendances de programme? Mal, selon mon expérience.

— rlms

29

Ce n'est pas le cas. Sauf si nous parlons de .NET qui vous demande d'installer la version X du framework en fonction du compilateur.

Tout le reste génère simplement une erreur. Avec de la chance, vous obtenez missing dll xxxx.dll. Cependant, la plupart des installateurs disposeront des bibliothèques requises pour exécuter le logiciel.

— Filipe YaBa Polido
source

6

C'est donc à l'installateur de chaque programme de vérifier les dépendances? Donc, si l'installateur est nul, vous ne pourrez peut-être pas du tout utiliser le programme ..

— Nico

Vous avez oublié de dire non, vous pouvez utiliser ensuite le programme, mais vous devez déterminer la DLL ou le framework dont il a besoin.

— Filipe YaBa Polido du

9

@Filipe Donc, le fait que vous deviez installer le runtime V C ++ est la raison pour laquelle vous détestez les logiciels .NET? Par défaut, Windows a déjà un framework .NET installé, donc si vous ciblez la bonne version, cela fonctionnera immédiatement. Et le fait que vous devez télécharger et installer des objets partagés manquants n'est vraiment pas limité à un logiciel / langage / framework particulier pour des raisons évidentes (vous pouvez également avoir le même "problème" dans * nix).

— Voo

2

@FilipeYaBaPolido: Votre haine est particulièrement déplacée puisque le runtime VC ++ 2008 est destiné aux applications C ++, pas aux applications .Net. Évidemment, les applications .Net ont besoin du framework .Net et les applications C ++ ont besoin du framework C ++ (runtime), assez simple en réalité. Maintenant, un progiciel particulier peut contenir à la fois des parties C ++ et .Net, de sorte que les deux ne sont pas exclusifs.

— MSalters

2

Les gars se détendent, je ne déteste pas .Net ou VC ++. Je code même en .Net / C # en cas de besoin, c'est un outil. Mais je travaille avec différents outils et je vois les différences. Désolé si j'ai mal expliqué.

— Filipe YaBa Polido

40

Edit 04/04/2014: Hey OP, regardez ce qui vient d'être publié aujourd'hui:

http://blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx

Je voulais juste développer un peu la réponse acceptée, parce que les détails sont un peu clairsemés. La réponse de Filipe ne fait aucune mention des stratégies que Windows fait ne utiliser pour résoudre ou atténuer les problèmes de dépendance du programme, comme le magasin composant (WinSxS,) le cache d'assemblage global, le système MSI, etc. Mais d'autre part , il est essentiellement en plein sentir qu'il est de la responsabilité du développeur d'inclure des bibliothèques personnalisées avec l'application et de vérifier l'existence de dépendances avant de s'engager dans la transaction d'installation.

Windows est moins modulaire que Linux, qui a des points positifs et négatifs. En revanche, Windows est plus monolithique, ce qui signifie que relativement moins de composants du système d'exploitation sont amovibles ou facultatifs comme sous Linux. (Bien que Windows s'améliore lentement à ce sujet.)

Mais du côté positif, cela signifie que les développeurs sont capables de faire beaucoup plus d'hypothèses sur les bibliothèques qu'un utilisateur aura déjà présentes sur sa machine. Et diverses versions de ces bibliothèques, une fois installées, seront stockées côte à côte dans le magasin de composants, de sorte que vous n'aurez plus les aboiements App1 à propos de besoin de crapDLL.dll et App2 aboiements à propos du besoin d'une version différente de crapDLL.dll en même temps. temps, etc.

— Ryan Ries
source

Merci Ryan. Je sais que je devrais élaborer ma réponse, mais comme l'anglais n'est pas ma langue principale, j'ai encore quelques difficultés à m'exprimer.

— Filipe YaBa Polido

Bien décrit. Cependant, je dirais que le système devient beaucoup plus modulaire côté serveur - options sans noyau / interface graphique, configuration basée sur les rôles et les fonctionnalités.

— EricB

J'ai lu cet article ce matin et cela m'a rappelé ce post. C'est une lecture divertissante, bien que tangentielle sur ce sujet: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries

9

Sous Windows, il appartient à l'auteur du logiciel de fournir les versions de ses bibliothèques. Windows dispose de quelques fonctionnalités pour vous aider.

Windows Installer et les services Trusted Installer qui interagissent avec les programmes d'installation (.msi). Il existe également des technologies de support appelées applications isolées et assemblages côte à côte qui aident à trier les conflits de version.

Pour les applications de framework .NET, il y a le Global Assembly Cache, les Strong-Named Assemblies et les principaux manifestes.

Dans Windows 8 et 8.1, il y a le Windows App Store avec la bibliothèque Windows Runtime (remplacement de l'API win32).

edit: Au cœur de la plupart de ces technologies se trouvent des manifestes d'assembly, des fichiers intégrés qui fournissent des numéros de version, des auteurs, des assemblys dépendants et leurs versions, entre autres données.

— Sandwich au poisson rouge
source

6

Les autres réponses ont correctement indiqué que la gestion des packages et le système d'exploitation sont des idées distinctes mais n'ont pas mentionné de solution.

Le système de gestion de paquets le plus similaire à apt-get ou yum sous Windows serait actuellement Chocolatey . Il permet aux gens d'installer / désinstaller des packages (msi, exe, scripts powershell,) et ces packages peuvent contenir des informations sur leurs dépendances qui peuvent être automatiquement résolues par Chocolatey.

Le package contient généralement un lien vers les fichiers binaires et les scripts pour gérer le processus d'installation. Le package peut également contenir les fichiers binaires ou tout autre fichier requis (les dépendances doivent être dans un package séparé). Chocolatey peut également utiliser des systèmes de gestion de packages externes comme le programme d'installation de la plate-forme Web de Microsoft , Ruby Gems, Python, etc.

— AllenSanborn
source

Absolument! Il existe une poignée de gestionnaires de packages tiers qui s'exécutent également sous Windows. Le seul que je peux nommer du haut de ma tête est NuGet, c'est un gestionnaire de packages / dépendances pour les développeurs d'applications intégré directement dans Visual Studio. Cela dit, je pense que la question était plutôt de savoir comment le système d'exploitation gère les packages, où ces solutions sont davantage axées sur la façon dont un utilisateur peut gérer les packages.

— Sandwich au poisson rouge

Désolé, je n'ai pas inclus d'informations sur Chocolatey. Chocolatey est basé au large de Nuget. Nuget et Nuspec ne sont qu'un paquet de «trucs» et une spécification de dépendances. Dans le cas d'un framework logiciel comme .Net (ruby, node, ...) les dépendances sont généralement des composants logiciels (dll, exe, js, ...). Ce sont tous des composants qu'une application utilise.

— AllenSanborn

Dans le cas de Chocolatey, le package est une application entière ou une dépendance d'application (framework d'application comme java, .net, ruby). Le package Nuget contient des scripts PowerShell (éventuellement le programme d'installation également) qui géreront l'installation de l'application et le fichier Nuspec décrit l'application et les dépendances dont elle dispose, par exemple Powershell dépend de .Net. Il existe également Boxstarter qui concentre un niveau supérieur en décrivant la configuration d'une machine et ce dont elle dépend. Des trucs assez soignés. Boxstarter entre dans le domaine de l'utilisation des chefs ou des marionnettes.

— AllenSanborn

0

D'après ce que je comprends, les seules dépendances gérées par Windows sont des bibliothèques spécifiques à Microsoft. Si vous installez, par exemple, un programme open source dans Windows comme Blender, il aura les bibliothèques libavcodec et ffmpeg dans ses propres fichiers dll séparés, et si vous installez ensuite, par exemple, OpenShot, il installera sa propre copie du libavcodec dans son propre répertoire, et il peut s'agir de versions complètement différentes. Cela peut être un cauchemar lors de la désinstallation de logiciels pour nettoyer les fichiers inutiles, et cela prend également beaucoup plus d'espace disque avec la redondance de la bibliothèque.

— Jeff
source