MSVCRT sous Windows ressemble-t-il à glibc (libc) sous * nix?

Question

Je rencontre fréquemment des programmes Windows intégrés dans MSVCRT (ou leurs équivalents plus récents) avec les exécutables du programme. Sur un PC typique, je trouverais de nombreuses copies du même fichier .DLL. D'après ce que je comprends, MSVCRT est la bibliothèque d'exécution C, un peu analogue à glibc / libc.so sous * nix.

Pourquoi les programmes Windows doivent-ils emporter leurs bibliothèques C avec eux au lieu de simplement partager la libc à l'échelle du système?

Mise à jour: grâce à Shog9, j'ai commencé à lire des informations sur SxS, ce qui m'a ouvert les yeux sur les problèmes de liaison de DLL (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx est une introduction utile à la question ...

Answer 1

[Je suis le responsable actuel de la technologie Native SxS chez Microsoft]

Les nouvelles versions de MSVCRT sont publiées avec les nouvelles versions de Visual Studio et reflètent les modifications apportées au jeu d'outils C ++. Pour que les programmes compilés avec les versions de VS publiées après le maintien d’une version particulière de Windows puissent fonctionner au niveau inférieur (tels que les projets VS 2008 sous Windows XP), le MSVCRT est redistribuable, il peut donc être installé à cet emplacement.

L'installation de CRT place les bibliothèques dans% windir% \ winsxs \, qui est un emplacement système global, nécessitant des privilèges d'administrateur pour le faire.

Certains programmes ne souhaitant pas être livrés avec un programme d'installation ou ne voulant pas que l'utilisateur ait besoin de privilèges d'administrateur sur la machine pour exécuter leur programme d'installation, ils regroupent le CRT directement dans le même répertoire que l'application, pour un usage privé. Donc, sur une machine typique, vous trouverez de nombreux programmes qui ont opté pour cette solution.

Answer 2

Il n’existe pas vraiment de "libc à l’échelle du système". sous Windows.

Dans * nix, il existe généralement un compilateur, un éditeur de liens et, avec eux, un format de fichier objet bien défini, une convention d’appel et une spécification de gestion de nom. Ce genre de choses vient généralement avec le système d'exploitation. Le statut semi-spécial du compilateur (plus l'accent mis sur la portabilité entre différents * noms) signifie que certains éléments peuvent être attendus , et doivent être nommés et / ou versionnés de manière à ce que les programmes puissent trouvez et utilisez-le facilement.

Sous Windows, les choses sont plus fragmentées. Un compilateur n’est pas fourni avec le système d’exploitation, les utilisateurs doivent donc se procurer le leur. Chaque compilateur fournit son propre tube cathodique, qui peut ou non avoir les mêmes fonctions que MSVCRT. Il n’existe pas non plus de convention unique sur les conventions d’appel ni sur la manière dont les noms doivent apparaître dans les bibliothèques. Par conséquent, différents compilateurs (avec différentes façons de faire les choses) risquent de ne pas pouvoir trouver des fonctions dans la bibliothèque.

BTW, le nom devrait être un indice ici; MSVCRT est l'abréviation de "MicroSoft Visual C ++ RunTime". Ce n'est pas vraiment un " system-wide " La bibliothèque de la même manière que, par exemple, kernel32 est simplement la bibliothèque d’exécution utilisée par les compilateurs de MS, qu’ils ont vraisemblablement utilisée lors de la construction de Windows. Il est concevable que d’autres compilateurs s’y rattachent, mais 1) des problèmes de licence pourraient se poser; et (2) les compilateurs lieraient leur code à MS - ce qui signifie (2a) ils n'auraient plus aucun moyen d'ajouter à l'exécution ou de corriger des bogues, à moins d'espérer que MS les corrigera; et (2b) si MS décide de modifier le contenu de la RTL (ce qu’elle peut faire à sa guise et probablement dans chaque nouvelle version de VC ++) ou la façon dont les noms apparaissent, ces autres programmes risquent de ne pas fonctionner correctement.

Answer 3

Réponse courte? Jusqu'à la création de SxS, MSVCRT n'était pas versionné de manière fiable ! Pouvez-vous imaginer la folie qui se produirait si les programmes compilés et testés avec libc 5 commençaient silencieusement à utiliser libc 6? C’est la situation dans laquelle nous nous trouvons depuis de nombreuses années sous Windows. La plupart d’entre nous voudraient tout aussi vite ne plus jamais faire confiance à MS pour conserver les changements d’une

Answer 4

Les programmes sont liés à une version spécifique du moteur d’exécution, et cette version requise n'est pas assurée sur la machine cible. De plus, la mise en correspondance de versions était problématique auparavant.

Dans le monde Windows, il est très malhonnête de demander à vos utilisateurs de rechercher et d'installer une bibliothèque distincte pour utiliser votre application. Vous vous assurez que les dépendances ne faisant pas partie du système hôte sont incluses dans votre application.

Dans le monde Linux, cela n’est pas toujours aussi simple, car il existe une variation beaucoup plus grande de l’apparence du système hôte.