MSVCRT in Windows è come glibc (libc) in * nix?

Question

Mi capita spesso di imbattermi in programmi Windows raggruppati in MSVCRT (o nei loro equivalenti più attuali) con gli eseguibili del programma. Su un tipico PC, troverei molte copie degli stessi .DLL. La mia comprensione è che MSVCRT è la libreria di runtime C, in qualche modo analoga a glibc / libc.so in * nix.

Perché i programmi Windows devono portare con sé le loro librerie C, invece di condividere semplicemente la libc a livello di sistema?

---

Aggiornamento: grazie a Shog9, ho iniziato a leggere su SxS, che mi ha ulteriormente aperto gli occhi sui problemi di collegamento DLL (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx è un'introduzione utile al problema ...

Answer 1

[Sono l'attuale manutentore della tecnologia Native SxS di Microsoft]

Le nuove versioni di MSVCRT vengono rilasciate con le nuove versioni di Visual Studio e riflettono le modifiche al set di strumenti C ++. Affinché i programmi compilati con le versioni di VS rilasciate dopo che una particolare versione di Windows continui possa funzionare a livelli bassi (come i progetti VS 2008 su Windows XP), MSVCRT è ridistribuibile, quindi può essere installato lì.

L'installazione di CRT inserisce le librerie in% windir% \ winsxs \, che è un percorso di sistema globale, che richiede i privilegi di amministratore per farlo.

Poiché alcuni programmi non vogliono essere forniti con un programma di installazione o non desiderano che l'utente abbia bisogno dei privilegi di amministratore sulla macchina per eseguire il proprio programma di installazione, raggruppano il CRT direttamente nella stessa directory dell'applicazione, per uso privato. Quindi su una macchina tipica, troverai molti programmi che hanno optato per questa soluzione.

Answer 2

In realtà non esiste un sistema "libc a livello di sistema" in Windows.

In * nix, in genere c'è un compilatore, un linker e con essi un formato file oggetto ben definito, convenzione di chiamata e specifiche di modifica del nome. Questa roba di solito viene fornita con il sistema operativo. Lo stato semi-speciale del compilatore (più un'enfasi sulla portabilità attraverso diversi * nix) significa che certe cose possono essere previste essere lì, e essere nominate e / o versionate in modo tale che i programmi possano facilmente trovarlo e usarlo.

In Windows, le cose sono più frammentate. Un compilatore non viene fornito con il sistema operativo, quindi le persone devono ottenere il proprio. Ogni compilatore fornisce il proprio CRT, che può avere o meno le stesse funzioni di MSVCRT. Non c'è nemmeno una vera specifica sulle convenzioni di chiamata o sul modo in cui i nomi dovrebbero apparire nelle librerie, quindi compilatori diversi (con modi diversi di fare cose) potrebbero avere difficoltà a trovare le funzioni nella libreria.

A proposito, il nome dovrebbe essere un indizio qui; MSVCRT è l'abbreviazione di "MicroSoft Visual C ++ RunTime". Non è davvero un "sistema" " libreria allo stesso modo, per esempio, kernel32 - è solo la libreria di runtime utilizzata dai compilatori di MS, che presumibilmente hanno usato durante la creazione di Windows. Altri compilatori potrebbero concepibilmente collegarsi contro di esso, ma (1) potrebbero esserci problemi di licenza; e (2) i compilatori legerebbero il loro codice a quello di MS - il che significa che (2a) non avrebbero più alcun modo di aggiungersi al runtime o correggere i bug, senza sperare che MS li risolva; e (2b) se MS decide di cambiare ciò che è in RTL (cosa che può fare a piacimento, e probabilmente lo ha in ogni nuova versione di VC ++), o come appaiono i nomi, quegli altri programmi potrebbero rompersi.

Answer 3

Risposta breve? Perché, fino a SxS, MSVCRT non aveva una versione affidabile ! Riesci a immaginare la follia che ne deriverebbe se i programmi compilati e testati contro libc 5 iniziassero silenziosamente a usare libc 6? Questa è la situazione in cui ci troviamo da molti anni su Windows. La maggior parte di noi non si fiderebbe mai più della SM per mantenere le modifiche di una versione

Answer 4

I programmi sono collegati a una versione specifica del runtime e la versione richiesta non è non garantita sul computer di destinazione. Inoltre, abbinare le versioni era problematico.

Nel mondo Windows, è molto male aspettarsi che i tuoi utenti escano e trovino e installino una libreria separata per usare la tua applicazione. Assicurati che eventuali dipendenze che non fanno parte del sistema host siano incluse nella tua app.

Nel mondo di Linux questo non è sempre così semplice, poiché esiste una variazione molto più ampia di come potrebbe apparire il sistema host.