Por que o registro do Windows é necessário?

Como eu depurei problemas no com, lado a lado, lidei com o dll hell, enquanto odiava o registro do Windows com paixão, fiquei me perguntando por que é necessário.

Eu nunca me senti obrigado a ler um livro inteiro sobre as melhores práticas de registro e, em seguida, apenas "entendi".

No entanto, usei o Linux e o Mac OS e observe como é possível instalar várias versões do Python e suas bibliotecas no mesmo computador * nix.

Como o registro tem um formato livre (embora feio) e é usado para todos os tipos de finalidades, nunca entendi o problema essencial que ele está tentando resolver.

Por exemplo, a Microsoft não deseja que você tenha duas versões diferentes do MS Office instaladas lado a lado. Eles usam o registro para impor isso durante a instalação. Essa limitação é artificial, na minha opinião. Se eles realmente se importassem em permitir um comportamento diferente, poderiam ter ajustado sua arquitetura de acordo.

No Mac OS, você pode instalar e remover aplicativos apenas colocando-os em uma pasta específica.

Assim,

A) Que problema essencial ele está tentando resolver? B) Como outros sistemas operacionais resolvem isso?

A maioria das outras respostas é mais ou menos correta, mas (junto com a pergunta) elas meio que não entendem.

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. Elas são simplesmente decisões que vários fornecedores tomaram sobre coisas como instalar seus programas - se você armazenou as informações de alguma outra forma / formulário / contêiner, os mesmos problemas poderiam permanecer.

Dada a filosofia "tudo é um arquivo" do Unix, não é 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 quanto muitas pessoas podem acreditar imediatamente, já que o sistema de arquivos Unix é em si um banco de dados hierárquico (ou, sem dúvida, um banco de dados de rede se você levar em consideração os links simbólicos). A grande diferença é que o registro é acessado por meio de uma API separada, onde o armazenamento de 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 tanto padronizado para preferências, configurações e perfis leves .

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

janelas

• Repositório de configurações
  • Sistema: Registro do Windows HKEY_LOCAL_MACHINEe especificamente grande parte dele está\SOFTWARE\Microsoft
  • Terceiros em todo o sistema: Registro do WindowsHKEY_LOCAL_MACHINE
  • Sistema centrado no usuário: Registro do Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Centrado no usuário de terceiros: Registro do WindowsHKEY_USERS\[user]\SOFTWARE
• Arquivos de aplicativo que um usuário não precisa ver C:\Users\[User]\AppData em pastas ocultas
• Arquivos de aplicativo que um usuário pode desejar 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...plistarquivos
  • Terceiros em todo o sistema: /Library/Preferences em plistarquivos de terceiros
  • Sistema centrado no usuário:, o /Users/[user]/Library/Preferences mesmo que acima
  • Centrado no usuário de terceiros:, o /Users/[user]/Library/Preferences mesmo que acima
• Arquivos de aplicativos em todo o sistema que um usuário não precisa ver /Library/Application Support
• Arquivos de aplicativo que um usuário não precisa ver /Users/[user]/Library/Application Support
• Arquivos de aplicativo que um usuário pode desejar /Users/[user]/ em pastas não ocultas

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

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

A natureza que não é do sistema de arquivos do registro dificulta o backup, a restauração ou a migração de partes dele, deixando outras, por isso 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 do usurpando um contexto mais global para criar arquivos ou pastas que realmente não pertencem a esse local. Alguns aplicativos realmente criam pastas diretamente C:\ou /sem perguntar. Isso realmente me deixa louco!

^{A propósito, embora a natureza de arrastar e soltar dos aplicativos da maioria dos Mac OS seja brilhante, você tem um problema semelhante com versões diferentes lado a lado, embora provavelmente não perceba - já que suas configurações não são armazenadas na .appprópria, mas em arquivo Application Supportou Preferences, cada versão do aplicativo ainda usará as mesmas configurações e afetam uns aos outros, a menos que a versão mais recente decide explicitamente usar uma pasta com um nome diferente ( IntelliJIDEA70, IntelliJIDEA81, etc.)}

Eu nunca entendi que problema essencial ele está tentando resolver.

Antes do registro, o Windows usava arquivos .INI. Na postagem do blog Por que os arquivos INI foram preteridos em favor do registro? Raymond Chen enumera os problemas que existiam com os arquivos .INI que estavam tentando ser resolvidos. Ele também enumera os problemas que os arquivos de configuração XML compartilham com os arquivos .ini antigos. Provavelmente é isso que vale a pena analisar, já que é o que muitos aplicativos usam hoje.

... o pêndulo voltou aos arquivos de configuração de texto, mas desta vez são XML. Isso reabre muitos dos problemas que os arquivos INI tiveram, mas você tem a grande vantagem de que ninguém grava nos arquivos de configuração XML; eles apenas leem deles. Os arquivos de configuração XML não são usados ​​para armazenar configurações do usuário; eles apenas contêm informações sobre o próprio programa. Vejamos esses problemas novamente.

• A segurança do arquivo XML não é granular o suficiente. Mas como o arquivo de configuração XML é somente leitura, a principal objeção é evitada. (Mas se você deseja que apenas administradores tenham permissão para ler partes específicas do XML, estará com problemas.)
• Como os arquivos de configuração XML são somente leitura, você não precisa se preocupar com vários gravadores.
• Os arquivos de configuração XML podem sofrer uma negação de serviço. Você ainda pode abri-los exclusivamente e bloquear outros processos.
• Arquivos XML contêm apenas cadeias de caracteres. Se você deseja armazenar dados binários, é necessário codificá-los de alguma forma.
• A análise de um arquivo XML é comparativamente lenta. Mas, como são somente leitura, você pode armazenar em cache com segurança o resultado analisado, portanto, é necessário analisar apenas uma vez.
• Os programas analisam arquivos XML manualmente, mas o formato XML já está bloqueado, portanto você não pode estendê-lo de qualquer maneira, mesmo que deseje. Felizmente, esses programas usam um analisador XML em conformidade com o padrão em vez de criar o seu próprio, mas eu não ficaria surpreso se as pessoas escrevessem seu próprio analisador XML personalizado que se engasga com, digamos, instruções de processamento ou cadeias com mais de 70 caracteres.
• Os arquivos XML não têm um limite de tamanho.
• Os arquivos XML não têm um local padrão.

Tudo isso pressupõe que o aplicativo nunca grave nos arquivos de configuração com os quais não concordo, mas isso tornaria as coisas piores e não melhores.

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

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

(2014) Para expandir um pouco meu raciocínio aqui: vejo o registro como um objeto divino. Todos sabemos que isso é um antipadrão.

Meu entendimento é que o registro foi projetado para ser uma espécie de repositório de configurações, supercerding os arquivos .ini que costumavam ser usados.

(NB, um entendimento grosseiro, portanto, isso pode estar incorreto).

A) Eu concordo com a resposta de Tim.

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

Pelo que entendi (não necessariamente gostando)

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

Toda essa informação que está nessa estrutura meio que a protege, pense na idéia de animais reunidos, mais segurança em números. Se cada bit de informação fosse seu próprio arquivo ini, algum usuário poderia excluí-lo por capricho. Eles ainda podem fazer isso entrando no registro, mas muitos o veem 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 os arquivos ini usados ​​antes do registro.

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 $HOME/.Aquaria.) Os arquivos de configurações globais são armazenados /etc/.

Os Macs fazem suas próprias coisas: plistarquivos específicos de aplicativos são armazenados (acredito) no Librarydiretório do usuário ou do sistema .

O problema 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 as informações como e quando necessário, carregue tudo no momento da inicialização, o que "pode" afetar o desempenho do sistema. O sistema também é abusado completamente, pois os fornecedores o carregam com várias informações e muitas vezes eles não as removem quando o software é desinstalado.

Diferente do Unix, onde tudo é armazenado em 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 precisava ser substituída devido a uma atualização que incluía recursos, você pode ter dificuldades ou ter que criar um processo personalizado para mesclar os dados de configuração no arquivo ini de entrada.

No entanto, com os dados no registro, você pode usar um pacote instalador 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 se deve ao ponto (histórico) de que o registro atua como um tipo de interface comum para configurações de aplicativos.

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

Não é necessário "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 deixassem em paz. Os arquivos .ini e autoexec.bat podem ser facilmente excluídos ou alterados para pior.

Alterando as configurações Registgry, oh meu!

Além de simplesmente armazenar as configurações do aplicativo, o registro é o meio pelo qual programas e componentes localizam outros programas e componentes . Por fim, 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 executa, por exemplo, efeitos de vídeo 'se registra' no registro, permitindo que outros aplicativos relacionados a vídeos saibam de sua existência e o usem. Por ter um sistema centralizado para isso, evita o que seria uma bagunça séria, pois milhares de sistemas e aplicativos usam métodos diferentes para atingir esse nível de integração.