Por que o registro do Windows é necessário?

A maioria das outras respostas são mais ou menos corretas, mas (juntamente com a pergunta) elas perdem o sentido.

O registro é um gerenciador de banco de dados hierárquico - nada mais e nada menos.

As "falhas" que você está atribuindo ao registro são realmente independentes do próprio registro. Eles são simplesmente decisões que vários fornecedores fizeram sobre coisas como instalar seus programas - se você armazenou as informações em alguma outra forma / recipiente, os mesmos problemas poderiam permanecer.

Dada a filosofia "tudo é um arquivo" do Unix, é (ou deveria ser) nenhuma surpresa que os sistemas Unix (e similares, como Linux e MacOS) armazenem as informações como arquivos individuais no sistema de arquivos. Isso não é tão diferente como muitas pessoas podem acreditar imediatamente, já que o sistema de arquivos Unix é, ele mesmo, um banco de dados hierárquico (ou, possivelmente, um banco de dados de rede se você levar em consideração links simbólicos). A diferença gritante é que o registro é acessado através de uma API separada, onde armazenar dados de configuração em arquivos permite que esses arquivos sejam acessados, editados, etc., através da mesma API (e ferramentas) que qualquer outro arquivo.

É um repositório de configurações - um local centralizado e um pouco padronizado para preferências, configurações, perfis leves .

Torna-se mais fácil entender quando você olha para o quadro geral de todas as coisas que um sistema operacional precisa armazenar para seus usuários e aplicativos:

Windows

• Repositório de configurações
  • Sistema: Registro do Windows HKEY_LOCAL_MACHINE e, especificamente, grande parte dele está em \SOFTWARE\Microsoft
  • Todo o sistema de terceiros: Registro do Windows HKEY_LOCAL_MACHINE
  • Sistema centrado no usuário: Registro do Windows HKEY_USERS , [user]\SOFTWARE\Microsoft
  • Centrado no usuário de terceiros: Registro do Windows HKEY_USERS\[user]\SOFTWARE
• Arquivos de aplicativos que um usuário não precisa ver C:\Users\[User]\AppData em pastas ocultas
• Arquivos de aplicativos que um usuário pode querer C:\Users\[User]\ em pastas não ocultas criadas pelo aplicativo

Mac OS X

• Repositório de configurações
  • Sistema e terceiros: /Library/Preferences em com.apple...plist arquivos
  • Todo o sistema de terceiros: /Library/Preferences em terceiros plist files
  • Sistema centrado no usuário: /Users/[user]/Library/Preferences , o mesmo que acima
  • Terceiro centrado no usuário: /Users/[user]/Library/Preferences , o mesmo que acima
• Arquivos de aplicativos de todo o sistema que um usuário não precisa ver /Library/Application Support
• Arquivos de aplicativos que um usuário não precisa ver /Users/[user]/Library/Application Support
• Arquivos de aplicativos que um usuário pode querer /Users/[user]/ em pastas não ocultas

Essencialmente, o registro é idêntico às pastas /Library/Preferences do Mac OS X, e não muito mais ou menos.

O fato de o Mac OS ter uma correspondência próxima de um para um para grupos organizacionais de dados de sistema e aplicativos ilustra que o Registro do Windows é um sistema completamente justificado que é apenas uma maneira diferente de fazer as coisas

A natureza do sistema que não é de arquivos do registro dificulta o backup, a restauração ou a migração de partes dele, deixando outros usuários, então prefiro o sistema Mac, mas o objetivo é quase idêntico.

Ambos os sistemas operacionais têm aplicativos que optam por violar essas estruturas em diferentes graus, geralmente através da usurpação de mais contexto global para criar arquivos ou pastas que realmente não pertencem a eles. Alguns aplicativos realmente criam pastas diretamente em C:\ ou / sem perguntar. Isso realmente me deixa louco!

^{A propósito, embora a natureza de arrastar e soltar de (mais) aplicativos do Mac OS seja brilhante, você tem um problema semelhante com versões diferentes lado a lado, embora você provavelmente não perceba - já que suas configurações não são armazenadas no arquivo .app , mas em Application Support ou Preferences , todas as versões do aplicativo continuarão usando as mesmas configurações e afetando umas às outras, a menos que a versão mais nova decida explicitamente usar uma pasta por um nome diferente ( IntelliJIDEA70 , IntelliJIDEA81 , etc.)}

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

Antes do Registro, o Windows usava arquivos .INI. Na postagem do blog Por que os arquivos INI são preteridos em favor do registro? Raymond Chen enumera os problemas que existiam com arquivos .ini que tentavam ser resolvidos. Ele também enumera os problemas que os arquivos de configuração XML compartilham com os arquivos .ini antigos. Isto é provavelmente o que vale a pena olhar uma vez que é o que muitos aplicativos usam hoje.

...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.

Tudo isso pressupõe que o aplicativo realmente nunca grava em seus arquivos de configuração com os quais não estou de acordo, mas que pioraria as coisas não melhor.

Minha teoria é a força motriz é nenhuma das opções acima. Pelo contrário, era uma medida anti-pirataria. Nos dias de pré-registro, você poderia simplesmente copiar um programa inteiro de uma máquina para outra. Encontre os .DLLs e você estava pronto para ir. O registro torna isso MUCH mais difícil de fazer.

Há muito pouco que o registro realiza que eu acho que não seria melhor servido por um arquivo de configuração por finalidade.

(2014) Para expandir meu raciocínio aqui um pouco: vejo o registro como um objeto deus. Nós todos sabemos que é um antipadrão.

Minha compreensão crua é que o registro foi projetado para ser uma espécie de repositório de configurações, supercendendo os arquivos .ini que costumavam ser usados.

(NB, uma compreensão crua, então isso pode estar incorreto).

A) Concordo com a resposta de Tim.

B) Outros sistemas operacionais usam outros métodos de armazenar configurações de programa, por exemplo, os arquivos de lugar geralmente do Unix em / etc (arquivos globais) e na pasta do usuário em várias pastas ocultas (configurações do usuário). Então todos eles usam alguma forma de registro, exceto que em alguns casos ele é distribuído.

Pelo que entendi (não necessariamente gostando disso)

A) Para fornecer um "local centralizado" onde qualquer programa pode armazenar informações sobre sua instalação ou configuração. Esta informação pode então ser usada pelos programas da maneira que eles decidirem. Personalização, anti-pirataria, etc.

Toda esta informação que está nesta estrutura protege-a, pensa na ideia de animais reunidos, mais segurança nos números. Se cada bit de informação fosse seu próprio arquivo ini, algum usuário poderia potencialmente deletá-lo por um capricho. Eles ainda podem fazer isso entrando no registro, mas muitos o vêem como uma espécie de caixa preta e não o tocam por medo de quebrar o sistema.

B) O Mac OS usa arquivos individuais muito parecidos com as janelas de arquivos ini usadas antes do registro aparecer.

O objetivo óbvio do Registro é atuar como um repositório único para todos os dados de configuração e configuração e remover a dependência dos arquivos de configuração.

Em outros sistemas operacionais, o modus operandi é armazenar informações específicas de aplicativos (como arquivos de configuração) em diretórios específicos de aplicativos ocultos no diretório inicial dos usuários. (Por exemplo, o jogo Aquaria armazena informações de configuração em $HOME/.Aquaria .) Arquivos de configurações globais são armazenados em /etc/ .

Os Macs fazem suas próprias coisas: arquivos plist específicos do aplicativo são armazenados (acredito) no diretório Library do usuário ou do sistema.

A questão não está na filosofia do registro, mas no design. O registro é usado pelo sistema operacional para procurar informações importantes sobre o programa que está sendo carregado. Embora em vez de carregar a informação como e quando necessário, ela carrega tudo no momento da inicialização, o que "pode" afetar o desempenho do sistema. O sistema também é amplamente abusado, pois os fornecedores o carregam com um monte de informações e, muitas vezes, não removem as informações quando o software é desinstalado.

Ao contrário do Unix, onde tudo é armazenado n arquivos e carregado como e quando necessário. O sistema operacional dessa maneira não depende das habilidades de programação do fornecedor para afetar seu desempenho ...

Embora eu não possa comentar sobre outros sistemas operacionais, o registro também ajuda a manter a configuração de um aplicativo durante um processo de atualização ou desinstalação / reinstalação. Se toda a configuração estava em um arquivo .ini que precisou ser substituído devido a uma atualização que adicionou recursos, você pode encontrar dificuldades ou criar um processo personalizado para mesclar dados de configuração no arquivo ini de entrada.

No entanto, com os dados no registro, você pode usar um pacote de instalação comum (WIX, InstallShield, etc.) que manipulará a desinstalação / reinstalação de arquivos sem tocar nas configurações do aplicativo.

(todos A. Não tenho certeza sobre B)

Acredito que isso esteja relacionado ao ponto (histórico) de que o registro funciona como um tipo de interface comum para configurações de aplicativos.

Tem uma aplicação? Deseja armazenar uma configuração do escopo do usuário? Bung no registro.

Não há necessidade de "garantir perfis de usuário", não é necessário acessar diretamente o sistema de arquivos. O Win32 cuida de tudo isso.

Era uma maneira de criar algo novo, desconhecido e tabu para a maioria dos usuários, para que eles deixassem isso de lado. Os arquivos .ini e autoexec.bat podem ser facilmente excluídos ou alterados para pior.

Alterando as configurações de Registgry, oh meu!

Além de simplesmente armazenar as configurações do aplicativo, o registro é o meio pelo qual os programas e componentes localizam outros programas e componentes . Em última análise, acho que é por isso que é centralizado em um único banco de dados, em vez de se espalhar por milhares de arquivos de texto ou xml.

Por exemplo, um componente que realiza, digamos, os efeitos de vídeo 'registra-se' no registro, permitindo que outros aplicativos relacionados a vídeo saibam de sua existência e o usem. Por ter um sistema centralizado para isso, evita o que seria uma bagunça séria, já que milhares de sistemas e aplicativos usam métodos diferentes para atingir esse nível de integração.