Ist MSVCRT unter Windows wie glibc (libc) unter * nix?

Question

Ich stoße häufig auf Windows-Programme, die in MSVCRT (oder ihre aktuelleren Äquivalente) mit den ausführbaren Programmdateien bündeln. Auf einem typischen PC würde ich viele Kopien derselben .DLLs finden. Nach meinem Verständnis ist MSVCRT die C-Laufzeitbibliothek, etwas analog zu glibc/libc.so unter * nix.

Warum müssen Windows-Programme ihre C-Bibliotheken mitbringen, anstatt nur die systemweite libc zu teilen?

---

Update: dank Shog9, begann ich über SxS zu lesen, die weiter meine Augen zu den DLL-Verknüpfung Probleme (DLL Hölle) hat sich geöffnet - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx ist eine nützliche Einführung in das Thema ...

Answer 1

[Ich bin der aktuelle Betreuer der Native SxS-Technologie bei Microsoft]

Neue Versionen von MSVCRT mit neuen freigegeben werden Versionen von Visual Studio und spiegeln Änderungen am C++ - Toolset wider. Damit Programme, die mit Versionen von VS kompiliert wurden, die nach einer bestimmten Windows-Version veröffentlicht wurden, weiter unten arbeiten können (z. B. VS 2008-Projekte unter Windows XP), kann MSVCRT weiterverteilt werden, sodass es dort installiert werden kann.

Die CRT-Installation löscht die Bibliotheken in% windir% \ winsxs \, einem globalen Systemspeicherort, für den Administratorrechte erforderlich sind.

Da einige Programme nicht mit einem Installationsprogramm geliefert werden sollen oder nicht möchten, dass der Benutzer Administratorrechte auf dem Computer zum Ausführen des Installationsprogramms benötigt, bündeln sie das CRT direkt im selben Verzeichnis wie die Anwendung für die private Verwendung . Auf einer typischen Maschine finden Sie also viele Programme, die sich für diese Lösung entschieden haben.

Answer 2

Programme sind mit einer bestimmten Version der Laufzeit verknüpft, und die erforderliche Version ist nicht garantiert auf dem Zielcomputer vorhanden. Auch die Anpassung von Versionen war problematisch.

In der Windows-Welt ist es sehr schlecht zu erwarten, dass Ihre Benutzer eine separate Bibliothek suchen und installieren, um Ihre Anwendung zu verwenden. Sie stellen sicher, dass alle Abhängigkeiten, die nicht Teil des Host-Systems sind, in Ihrer App enthalten sind.

In der Linux-Welt ist dies nicht immer so einfach, da es eine viel größere Variation gibt, wie das Host-System aussehen könnte.

Answer 3

Kurze Antwort? Denn bis SxS wurde MSVCRT nicht zuverlässig versioniert! Kannst du dir den Wahnsinn vorstellen, der sich ergeben würde, wenn Programme, die gegen libc 5 kompiliert und getestet würden, lautlos libc 6 benutzen würden? Das war die Situation, in der wir uns viele Jahre auf Windows befanden. Die meisten von uns würden so bald nur nie wieder MS vertrauen mit dem Halten brechen Änderungen von einer Version

Answer 4

Es gibt nicht wirklich eine "systemweite libc" in Windows.

In * nix gibt es im Allgemeinen einen Compiler, einen Linker und mit ihnen ein wohldefiniertes Objektdateiformat, Aufrufkonvention und Name mangling spec. Dieses Zeug kommt normalerweise mit dem Betriebssystem. Der semi-spezielle Status des Compilers (plus eine Betonung der Portabilität über verschiedene * nixes) bedeutet, dass bestimmte Sachen erwartet sein können, und so benannt und/oder versioniert werden, dass Programme es leicht finden und verwenden können .

In Windows sind die Dinge mehr fragmentiert. Ein Compiler kommt nicht mit dem Betriebssystem, also müssen die Leute ihre eigenen bekommen.Jeder Compiler stellt seine eigene CRT bereit, die dieselben Funktionen wie MSVCRT haben kann oder nicht. Es gibt auch keine One True Spec für das Aufrufen von Konventionen oder wie Namen in den Bibliotheken angezeigt werden sollen. Daher können verschiedene Compiler (mit unterschiedlichen Methoden) Schwierigkeiten haben, Funktionen in der Bibliothek zu finden.

BTW, der Name sollte hier ein Hinweis sein; MSVCRT ist die Abkürzung für "MicroSoft Visual C++ RunTime". Es ist nicht wirklich eine "systemweite" Bibliothek in der gleichen Art und Weise wie beispielsweise kernel32 - es ist nur die Laufzeitbibliothek, die von MS-Compilern verwendet wird, die sie vermutlich beim Erstellen von Windows verwendet haben. Andere Compiler könnten sich möglicherweise dagegen verbünden, aber (1) könnte es Lizenzprobleme geben; und (2) die Compiler würden ihren Code an MS binden - was bedeutet, dass (2a) sie keine Möglichkeit mehr hätten, die Laufzeit zu verbessern oder Fehler zu beheben, ohne zu hoffen, dass MS sie beheben wird; und (2b) wenn MS entscheidet, was in der RTL geändert wird (was sie nach Belieben tun können und wahrscheinlich in jeder neuen Version von VC++ haben) oder wie die Namen erscheinen, können diese anderen Programme brechen.