Perché è necessario il registro di Windows?

La maggior parte delle altre risposte sono più o meno corrette, ma (insieme alla domanda) hanno perso il punto.

Il registro è un gestore di database gerarchico - niente di più e niente di meno.

Gli "errori" che stai attribuendo al registro sono in realtà indipendenti dal registro stesso. Sono semplicemente decisioni prese da vari fornitori su cose come installare i loro programmi - se le informazioni sono state archiviate in qualche altro modo / forma / contenitore, gli stessi problemi potrebbero rimanere.

Vista la filosofia "tutto è un file" di Unix, è (o dovrebbe essere) non sorprende che i sistemi Unix (e simili, come Linux e MacOS) memorizzino le informazioni come singoli file nel file system. Questo non è così diverso come molte persone potrebbero crederci subito, dal momento che il file system Unix è esso stesso un database gerarchico (o, probabilmente, un database di rete se si prendono in considerazione collegamenti simbolici). La clamorosa differenza è che al registro si accede tramite un'API separata, dove l'archiviazione dei dati di configurazione nei file consente l'accesso, la modifica e così via a tali file tramite la stessa API (e strumenti) di qualsiasi altro file.

È un repository delle impostazioni - una posizione centralizzata e un po 'standardizzata per preferenze, impostazioni, profili leggeri .

Diventa più facile capire quando guardi l'immagine grande per tutto ciò che un sistema operativo deve memorizzare per i suoi utenti e le sue applicazioni:

di Windows

• Deposito delle impostazioni
  • Sistema: Registro di Windows HKEY_LOCAL_MACHINE e in particolare gran parte di esso è in \SOFTWARE\Microsoft
  • Sistema di terze parti: Registro di Windows HKEY_LOCAL_MACHINE
  • Sistema incentrato sull'utente: Registro di Windows HKEY_USERS , [user]\SOFTWARE\Microsoft
  • Terzo utente incentrato sull'utente: Registro di Windows HKEY_USERS\[user]\SOFTWARE
• File di applicazioni che un utente non dovrebbe aver bisogno di vedere C:\Users\[User]\AppData nelle cartelle nascoste
• File di applicazione che un utente potrebbe volere C:\Users\[User]\ in cartelle non nascoste create dall'app

Mac OS X

• Deposito delle impostazioni
  • Sistema e di terze parti: /Library/Preferences in com.apple...plist file
  • Di tutto il sistema di terze parti: /Library/Preferences in file di terze parti plist
  • Sistema incentrato sull'utente: /Users/[user]/Library/Preferences , come sopra
  • User-centric di terze parti: /Users/[user]/Library/Preferences , come sopra
• File di applicazione a livello di sistema che un utente non dovrebbe vedere /Library/Application Support
• File di applicazioni che un utente non dovrebbe aver bisogno di vedere /Users/[user]/Library/Application Support
• I file di applicazione che un utente potrebbe volere /Users/[user]/ in cartelle non nascoste

In sostanza, il registro è identico alle cartelle /Library/Preferences di Mac OS X e non molto più o meno.

Il fatto che Mac OS abbia una corrispondenza quasi uno a uno per gruppi organizzativi di dati di sistema e di applicazioni mostra che il registro di Windows è un sistema completamente giustificato che è solo un modo diverso di fare le cose

La natura non del file system del registro rende più difficile il backup, il ripristino o la migrazione di parti di esso mentre ne escono altre, quindi preferisco il sistema Mac, ma lo scopo è quasi identico.

Entrambi i sistemi operativi hanno applicazioni che scelgono di violare queste strutture a diversi livelli, di solito attraverso l'usurpazione di un contesto più globale per creare file o cartelle in cui in realtà non ci appartengono. Alcune applicazioni creano effettivamente cartelle direttamente in C:\ o / senza chiedere. Questo mi fa davvero impazzire!

^{A proposito, mentre la natura del trascinamento della (più) delle applicazioni Mac OS è brillante, si ha un problema simile con diverse versioni affiancate, anche se probabilmente non si notano - poiché le tue impostazioni non sono memorizzate nel file .app stesso, ma in Application Support o Preferences , ogni versione dell'applicazione utilizzerà comunque le stesse impostazioni e si influenzeranno a vicenda, a meno che la versione più recente non decida esplicitamente di utilizzare una cartella con un nome diverso ( IntelliJIDEA70 , IntelliJIDEA81 , ecc.)}

I have never understood what essential problem it is trying to solve.

Prima del registro Windows utilizzava file .INI. Nel post del blog Perché i file INI sono deprecati a favore del registro? Raymond Chen enumera i problemi che esistevano con i file .INI che cercavano di essere risolti. Egli enumera inoltre i problemi che i file di configurazione XML condividono con i vecchi file .ini. Questo è probabilmente ciò che vale la pena di vedere poiché è quello che molte applicazioni usano oggi.

...the pendulum has swung back to text configuration files, but this time, they're XML. This reopens many of the problems that INI files had, but you have the major advantage that nobody writes to XML configuration files; they only read from them. XML configuration files are not used to store user settings; they just contain information about the program itself. Let's look at those issues again.

• XML file security is not granular enough. But since the XML configuration file is read-only, the primary objection is sidestepped. (But if you want only administrators to have permission to read specific parts of the XML, then you're in trouble.)
• Since XML configuration files are read-only, you don't have to worry about multiple writers.
• XML configuration files can suffer a denial of service. You can still open them exclusively and lock out other processes.
• XML files contain only strings. If you want to store binary data, you have to encode it somehow.
• Parsing an XML file is comparatively slow. But since they're read-only, you can safely cache the parsed result, so you only need to parse once.
• Programs parse XML files manually, but the XML format is already locked, so you couldn't extend it anyway even if you wanted to. Hopefully, those programs use a standard-conforming XML parser instead of rolling their own, but I wouldn't be surprised if people wrote their own custom XML parser that chokes on, say, processing instructions or strings longer than 70 characters.
• XML files do not have a size limit.
• XML files do not have a default location.

Tutto ciò presuppone che l'applicazione non scriva mai nei propri file di configurazione su cui non sono d'accordo ma che peggiorerebbe le cose non meglio.

La mia teoria è la forza trainante non è nessuno dei precedenti. Piuttosto, era una misura antipirateria. Nei giorni precedenti al Registro di sistema, in genere è sufficiente copiare un intero programma da una macchina all'altra. Trova le DLL e sei stato bravo ad andare. Il registro rende questo MUCH più difficile da fare.

C'è pochissimo che il registro comporti ciò che penso non sarebbe servito meglio da un file di configurazione per scopo.

(2014) Espandere un po 'il mio ragionamento: vedo il registro come un oggetto divino. Sappiamo tutti che è un antipattern.

La mia comprensione cruda è che il registro è stato progettato per essere una sorta di repository delle impostazioni, con la supercerding dei file .ini che erano utilizzati in precedenza.

(NB, una comprensione cruda, quindi potrebbe essere errata).

A) Sono d'accordo con la risposta di Tim.

B) Altri sistemi operativi utilizzano altri metodi di memorizzazione delle impostazioni del programma, ad esempio, i file di Unix solitamente collocano i file in / etc (file globali) e nella cartella utente in varie cartelle nascoste (impostazioni utente). Quindi usano tutti una qualche forma di registro, tranne che in alcuni casi è distribuito.

A quanto ho capito (non necessariamente godendolo)

A) Fornire una "posizione centralizzata" in cui qualsiasi programma può memorizzare informazioni sulla sua installazione o configurazione. Queste informazioni possono quindi essere utilizzate dai programmi in qualsiasi modo decidano. Personalizzazione, anti-pirateria, ecc.

Tutte queste informazioni in questa struttura lo proteggono, pensano all'idea che gli animali si affollino insieme, più sicurezza nei numeri. Se ogni bit di informazioni fosse il proprio file ini, qualche utente potrebbe potenzialmente eliminarlo per un capriccio. Possono ancora farlo entrando nel registro, ma molti lo vedono come una sorta di scatola nera e non lo toccheranno per paura di rompere il loro sistema.

B) Mac OS utilizza singoli file in modo molto simile ai file ini Windows utilizzati prima del registro.

Lo scopo ovvio del Registro è di agire come un unico repository per tutti i dati di configurazione e impostazione e rimuovere la dipendenza dai file di configurazione.

Su altri sistemi operativi, il modus operandi è di memorizzare le informazioni specifiche dell'applicazione (come i file di configurazione) in directory nascoste specifiche dell'applicazione nella home directory degli utenti. (Ad esempio, il gioco Aquaria memorizza le informazioni di configurazione in $HOME/.Aquaria .) I file delle impostazioni globali sono memorizzati in /etc/ .

I Mac fanno le loro cose: i file plist specifici dell'applicazione sono memorizzati (credo) nella directory Library dell'utente o del sistema.

Il problema non è legato alla filosofia del registro ma al suo design. Il registro viene utilizzato dal sistema operativo per cercare informazioni importanti sul programma da caricare. Sebbene piuttosto che caricare le informazioni come e quando necessario, carica tutto al momento dell'avvio, che "può" influire sulle prestazioni del sistema. Il sistema viene inoltre abusato a fondo dai venditori che lo caricano con un sacco di informazioni e molte volte non rimuovono le informazioni quando il software viene disinstallato.

Diversamente da Unix, dove tutto è archiviato e caricato e caricato quando necessario. In questo modo il sistema operativo non si basa sulle competenze di programmazione del fornitore per influenzare le sue prestazioni ...

Anche se non posso commentare altri sistemi operativi, il registro aiuta anche a mantenere la configurazione di un'applicazione durante un aggiornamento o un processo di disinstallazione / reinstallazione. Se tutta la configurazione era in un file .ini che doveva essere sostituito a causa di un aggiornamento che aggiungeva funzionalità, potresti incontrare delle difficoltà o dover creare un processo personalizzato per unire i dati di configurazione nel file ini in arrivo.

Tuttavia, con i dati nel registro, è possibile utilizzare un pacchetto di installazione comune (WIX, InstallShield, ecc.) che gestirà la disinstallazione / reinstallazione dei file senza toccare le impostazioni dell'applicazione.

(tutto A. Non sono sicuro di B)

Credo che questo sia in realtà fino al punto (storico) che il registro agisce come una sorta di interfaccia comune per le impostazioni dell'applicazione.

Hai un'applicazione? Vuoi archiviare un'impostazione per ambito utente? Inseriscilo nel registro.

Non è necessario "garantire i profili utente", non è necessario accedere direttamente al file system. Win32 si prende cura di tutto questo.

Era un modo per creare qualcosa di nuovo, non familiare e tabù per la maggior parte degli utenti, in modo da lasciarli da soli. I file .ini e autoexec.bat possono essere facilmente cancellati o modificati in peggio.

Modifica delle impostazioni Registgry, oh mio!

Oltre a memorizzare semplicemente le impostazioni dell'applicazione, il registro è il mezzo con cui programmi e componenti individuano altri programmi e componenti . In definitiva, penso che questo sia il motivo per cui è centralizzato in un unico database anziché diffondersi su migliaia di file di testo o xml.

Ad esempio, un componente che esegue, ad esempio, "registri" di effetti video nel registro, consentendo a altre applicazioni video correlate di conoscerne l'esistenza e utilizzarla. Avendo un sistema centralizzato per questo, evita quello che sarebbe un disastro serio dato che migliaia di sistemi e applicazioni usano metodi diversi per raggiungere quel livello di integrazione.