Perché è necessario il registro di Windows?

Dato che ho riscontrato problemi di debug in com, fianco a fianco, ho affrontato l'inferno dll, mentre odiavo il registro di Windows con passione, mi chiedevo perché fosse necessario.

Non mi sono mai sentito in dovere di leggere un intero libro sulle migliori pratiche del registro e poi semplicemente "ottenerlo".

Tuttavia, ho usato Linux e Mac OS e guardo ai modi in cui è possibile installare più versioni di Python e delle sue librerie sullo stesso computer * nix.

Poiché il registro ha in qualche modo un formato gratuito (anche se brutto) e viene utilizzato per tutti i tipi di scopi, non ho mai capito quale problema essenziale sta cercando di risolvere.

Ad esempio, Microsoft non vuole che tu abbia due diverse versioni di MS Office installate fianco a fianco. Usano il registro per imporre questo durante l'installazione. Questa limitazione è artificiale, secondo me. Se avessero davvero voluto consentire un comportamento diverso, avrebbero potuto adeguare la loro architettura di conseguenza.

In Mac OS è possibile installare e rimuovere app semplicemente rilasciandole in una cartella specifica.

Così,

A) Quale problema essenziale sta cercando di risolvere? B) Come lo risolvono altri sistemi operativi?

La maggior parte delle altre risposte sono più o meno corrette, ma (insieme alla domanda) in qualche modo mancano il punto.

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

I "difetti" che stai attribuendo al registro sono realmente indipendenti dal registro stesso. Sono semplicemente decisioni che vari fornitori hanno preso su cose come installare i loro programmi: se conservaste le informazioni in qualche altro modo / forma / contenitore, gli stessi problemi potrebbero rimanere.

Data la filosofia "tutto è un file" di Unix, non è (o dovrebbe essere) una sorpresa 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 immediatamente credere, 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 differenza evidente è che si accede al registro tramite un'API separata, in cui l'archiviazione dei dati di configurazione nei file consente di accedere, modificare, ecc. A tali file tramite la stessa API (e strumenti) di qualsiasi altro file.

È un repository delle impostazioni : una posizione centralizzata e in qualche modo standardizzata per preferenze, impostazioni, profili leggeri .

Diventa più facile capire quando si guarda il quadro generale di tutte le cose che un sistema operativo deve archiviare per i suoi utenti e applicazioni:

finestre

• Repository delle impostazioni
  • Sistema: registro di Windows HKEY_LOCAL_MACHINEe in particolare gran parte di esso\SOFTWARE\Microsoft
  • Sistema di terze parti: registro di WindowsHKEY_LOCAL_MACHINE
  • Centrato sull'utente di sistema: registro di Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Centrato sull'utente di terze parti: registro di WindowsHKEY_USERS\[user]\SOFTWARE
• I file dell'applicazione che un utente non dovrebbe aver bisogno di vedere C:\Users\[User]\AppData nelle cartelle nascoste
• File dell'applicazione che un utente può desiderare C:\Users\[User]\ in cartelle non nascoste create dall'app

Mac OS X

• Repository delle impostazioni
  • Sistema e terze parti: /Library/Preferences in com.apple...plistfile
  • Sistema /Library/Preferences di terze parti : in plistfile di terze parti
  • Sistema incentrato sull'utente: /Users/[user]/Library/Preferences come sopra
  • Centrato sull'utente di terze parti: /Users/[user]/Library/Preferences come sopra
• File dell'applicazione a livello di sistema che un utente non dovrebbe avere bisogno di vedere /Library/Application Support
• File dell'applicazione che un utente non dovrebbe aver bisogno di vedere /Users/[user]/Library/Application Support
• File dell'applicazione che un utente può desiderare /Users/[user]/ in cartelle non nascoste

In sostanza, il registro è identico alle cartelle di Mac OS X /Library/Preferences 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 applicazione dimostra 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 lasciano altri, 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 non appartengono realmente. Alcune applicazioni in realtà creano cartelle direttamente C:\o /senza chiedere. Questo mi fa davvero impazzire!

^{A proposito, mentre la natura del trascinamento della (maggior parte) delle applicazioni Mac OS è brillante, hai un problema simile con diverse versioni affiancate, anche se probabilmente non te ne accorgi, poiché le tue impostazioni non sono memorizzate nel .appfile stesso, ma in Application Supporto Preferences, ogni versione dell'applicazione sarà ancora possibile utilizzare le stesse impostazioni e influenzano l'un l'altro, a meno che la versione più recente decide esplicitamente di utilizzare una cartella con un nome diverso ( IntelliJIDEA70, IntelliJIDEA81, etc.)}

Non ho mai capito quale problema essenziale sta cercando di risolvere.

Prima del Registro di sistema, Windows utilizzava i 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 stavano cercando di essere risolti. Enumera inoltre i problemi che i file di configurazione XML condividono con i vecchi file .ini. Questo è probabilmente ciò che vale la pena guardare poiché è quello che molte applicazioni usano oggi.

... il pendolo è tornato ai file di configurazione del testo, ma questa volta sono XML. Questo riapre molti dei problemi che hanno avuto i file INI, ma hai il grande vantaggio che nessuno scrive nei file di configurazione XML; leggono solo da loro. I file di configurazione XML non vengono utilizzati per memorizzare le impostazioni dell'utente; contengono solo informazioni sul programma stesso. Diamo un'occhiata a questi problemi di nuovo.

• La sicurezza dei file XML non è abbastanza granulare. Ma poiché il file di configurazione XML è di sola lettura, l'obiezione principale viene evitata. (Ma se desideri che solo gli amministratori dispongano dell'autorizzazione per leggere parti specifiche dell'XML, allora sei nei guai.)
• Poiché i file di configurazione XML sono di sola lettura, non devi preoccuparti di più writer.
• I file di configurazione XML possono subire un diniego di servizio. Puoi comunque aprirli esclusivamente e bloccare altri processi.
• I file XML contengono solo stringhe. Se si desidera archiviare dati binari, è necessario codificarli in qualche modo.
• L'analisi di un file XML è relativamente lenta. Ma poiché sono di sola lettura, puoi tranquillamente memorizzare nella cache il risultato analizzato, quindi devi analizzare solo una volta.
• I programmi analizzano manualmente i file XML, ma il formato XML è già bloccato, quindi non è possibile estenderlo comunque, anche se lo si desidera. Speriamo che quei programmi utilizzino un parser XML conforme allo standard invece di lanciare il proprio, ma non sarei sorpreso se la gente scrivesse il proprio parser XML personalizzato che soffoca, diciamo, elaborando istruzioni o stringhe più lunghe di 70 caratteri.
• I file XML non hanno un limite di dimensioni.
• I file XML non hanno un percorso predefinito.

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

La mia teoria è che la forza trainante non è nessuna delle precedenti. Piuttosto, era una misura antipirateria. Nei giorni precedenti al registro, in genere si poteva semplicemente copiare un intero programma da una macchina all'altra. Trova i .DLL e sei stato bravo ad andare. Il registro rende questo molto più difficile da fare.

C'è ben poco che il registro compia e penso che non sarebbe meglio servito da un file di configurazione per scopo.

(2014) Per ampliare un po 'il mio ragionamento qui: vedo il registro come un oggetto divino. Sappiamo tutti che è un antipasto.

La mia rozza comprensione è che il registro è stato progettato per essere una sorta di repository di impostazioni, superando i file .ini che erano soliti usare.

(NB, una comprensione rozza, quindi potrebbe non essere corretta).

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

B) Altri sistemi operativi utilizzano altri metodi di memorizzazione delle impostazioni del programma, ad esempio, Unix solitamente posiziona 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 divertente)

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, antipirateria, ecc.

Tutte queste informazioni contenute in questa struttura le proteggono, pensano all'idea che gli animali si radunino insieme, più sicurezza nei numeri. Se ogni bit di informazione fosse il suo file ini, alcuni utenti potrebbero potenzialmente cancellarlo per un capriccio. Possono ancora farlo entrando nel registro, ma molti lo vedono come una specie di scatola nera e non lo toccano per paura di rompere il loro sistema.

B) Mac OS utilizza i singoli file in modo simile alle finestre dei file ini utilizzate prima dell'arrivo 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 è quello di memorizzare informazioni specifiche dell'applicazione (come i file di configurazione) in directory specifiche dell'applicazione nascoste 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 plistfile specifici dell'applicazione vengono archiviati (credo) nella Librarydirectory dell'utente o del sistema .

Il problema non è con la filosofia del registro ma con il suo design. Il registro viene utilizzato dal sistema operativo per cercare informazioni importanti relative al programma da caricare. Sebbene anziché caricare le informazioni quando e quando necessario, le carica tutte al momento dell'avvio, il che "può" influire sulle prestazioni del sistema. Il sistema viene anche completamente abusato poiché i fornitori lo caricano con un sacco di informazioni e molte volte non rimuovono le informazioni quando il software viene disinstallato.

A differenza di Unix dove tutto è archiviato in n file e caricato come e quando necessario. Il sistema operativo in questo modo non si basa sulle capacità di programmazione del fornitore per influire sulle sue prestazioni ...

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

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 ciò dipenda dal punto (storico) che il registro funge da tipo di interfaccia comune per le impostazioni dell'applicazione.

Hai una domanda? Vuoi memorizzare un'impostazione nell'ambito dell'utente? Inserito nel registro.

Non è necessario "garantire i profili utente", non è necessario accedere direttamente al file system. Win32 si occupa di tutto ciò.

Era un modo per creare qualcosa di nuovo, sconosciuto e tabù per la maggior parte degli utenti, in modo da lasciarlo da solo. I file .ini e autoexec.bat possono essere facilmente eliminati o modificati in peggio.

Modifica delle impostazioni di 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 tra migliaia di file di testo o xml.

Ad esempio, un componente che esegue, per esempio, gli effetti video si 'registra' nel registro, consentendo ad altre applicazioni video correlate di conoscerne l'esistenza e di usarlo. Avendo un sistema centralizzato per questo, evita quello che sarebbe un vero casino poiché migliaia di sistemi e applicazioni usano metodi diversi per raggiungere quel livello di integrazione.