Windowsレジストリが必要な理由

私はcomの問題を横並びでデバッグし、dllの地獄に対処しましたが、Windowsレジストリを情熱的に嫌っていましたが、なぜそれが必要なのか疑問に思っていました。

レジストリのベストプラクティスに関する本全体を読んで、それを「取得」することを余儀なくされたわけではありません。

しかし、LinuxとMac OSを使用し、同じ* nixコンピューターに複数のバージョンのPythonとそのライブラリーをインストールする方法を調べました。

レジストリはいくぶんfreeい（しかしalい）形式であり、あらゆる種類の目的に使用されるため、レジストリが解決しようとしている本質的な問題を理解したことはありません。

たとえば、Microsoftは、2つの異なるバージョンのMS Officeを並べてインストールすることを望んでいません。彼らはインストール中にこれを強制するためにレジストリを使用します。私の意見では、この制限は人為的なものです。異なる動作を許可することに本当に気を配っていれば、それに応じてアーキテクチャを調整できたはずです。

Mac OSでは、特定のフォルダーにアプリをドロップするだけで、アプリをインストールおよび削除できます。

そう、

A）解決しようとしている本質的な問題は何ですか？B）他のオペレーティングシステムはどのようにそれを解決しますか？

他の回答のほとんどは多かれ少なかれ正しいですが、（質問に加えて）ポイントを逃しています。

レジストリは階層型のデータベースマネージャーです。これ以上でもそれ以下でもありません。

レジストリに起因する「障害」は、レジストリ自体とはまったく無関係です。彼らは単に、プログラムのインストール方法など、さまざまなベンダーが決定したことです。他の方法/フォーム/コンテナに情報を保存すると、同じ問題が残る可能性があります。

Unixの「すべてがファイルである」という哲学を考えると、Unix（およびLinuxやMacOSなどの同様の）システムがファイルシステム内の個々のファイルとして情報を保存することは驚くことではありません。ただし、Unixファイルシステム自体が階層型データベース（または、シンボリックリンクを考慮するとネットワークデータベース）であるため、これは多くの人がすぐに信じるほど大きな違いはありません。明らかな違いは、レジストリに別のAPIを介してアクセスすることです。構成データをファイルに保存すると、他のファイルと同じAPI（およびツール）を介してこれらのファイルにアクセス、編集などができます。

それはだ設定リポジトリ - 好み、設定、軽量プロファイルのための集中とやや標準化された場所。

OSがユーザーとアプリケーションのために保存しなければならないすべてのものの全体像を見ると、理解しやすくなります。

窓

• 設定リポジトリ
  • システム： WindowsレジストリHKEY_LOCAL_MACHINEと特にその多くは\SOFTWARE\Microsoft
  • サードパーティのシステム全体： WindowsレジストリHKEY_LOCAL_MACHINE
  • システムユーザー中心： WindowsレジストリHKEY_USERS、[user]\SOFTWARE\Microsoft
  • サードパーティのユーザー中心： WindowsレジストリHKEY_USERS\[user]\SOFTWARE
• ユーザーが C:\Users\[User]\AppData非表示フォルダーに表示する必要のないアプリケーションファイル
• ユーザーが C:\Users\[User]\アプリで作成された非表示フォルダーに必要なアプリケーションファイル

Mac OS X

• 設定リポジトリ
  • システムおよびサードパーティ： /Library/Preferences内com.apple...plistのファイル
  • サードパーティのシステム全体： /Library/Preferencesサードパーティのplistファイル内
  • システムユーザー中心： /Users/[user]/Library/Preferences、上記と同じ
  • サードパーティのユーザー中心： /Users/[user]/Library/Preferences、上記と同じ
• ユーザーが見る必要のないシステム全体のアプリケーションファイル /Library/Application Support
• ユーザーが見る必要のないアプリケーションファイル /Users/[user]/Library/Application Support
• ユーザーが /Users/[user]/非表示フォルダーに入れたいアプリケーションファイル

基本的に、レジストリはMac OS Xの フォルダーと同一であり、大体同じです/Library/Preferences 。

Mac OSがシステムおよびアプリケーションデータの組織グループに対してほぼ1対1の一致を持っているという事実は、Windowsレジストリが物事を行うためのまったく異なる方法である完全に正当化されたシステムであることを示しています

レジストリのファイルシステム以外の性質により、一部をバックアップ、復元、または移行することは難しくなります。そのため、私はMacシステムを好みますが、目的はほぼ同じです。

どちらのOSにも、通常はグローバルコンテキストを奪って実際にはそこに属さないファイルやフォルダーを作成することにより、これらの構造にさまざまな程度で違反することを選択するアプリケーションがあります。一部のアプリケーションは、実際にフォルダを直接、C:\または確認/せずに作成します。それは本当に私を夢中にさせます！

^{ちなみに、（ほとんどの）Mac OSアプリケーションのドラッグアンドドロップの性質は優れていますが、設定が保存されていないため、おそらく気づかないかもしれませんが、異なるバージョンで同じような問題がありますで.app、ファイルそのものではなく、中Application SupportまたはPreferences、新しいバージョンが明示的に（別の名前でフォルダを使用することを決定しない限り、アプリケーションのすべてのバージョンはまだ、同じ設定を使用し、お互いに影響を与えるIntelliJIDEA70、IntelliJIDEA81など、）}

私はそれが解決しようとしている本質的な問題を理解したことがありません。

レジストリの前にWindowsは.INIファイルを使用していました。ブログの投稿で、なぜINIファイルはレジストリを支持して廃止されるのですか？Raymond Chenは、解決しようとしていた.INIファイルに存在する問題を列挙しています。また、XML構成ファイルが古い.iniファイルと共有する問題を列挙しています。多くのアプリケーションが今日使用しているものであるため、これはおそらく検討する価値があります。

...振り子はテキスト構成ファイルに戻りましたが、今回はXMLです。これにより、INIファイルにあった問題の多くが再び開きますが、XML構成ファイルに誰も書き込まないという大きな利点があります。彼らは彼らから読むだけです。XML構成ファイルは、ユーザー設定の保存には使用されません。プログラム自体に関する情報のみが含まれています。これらの問題をもう一度見てみましょう。

• XMLファイルのセキュリティは十分な粒度ではありません。ただし、XML構成ファイルは読み取り専用であるため、主な異論は回避されます。（ただし、管理者のみにXMLの特定の部分を読み取る権限を付与する場合は、問題が発生します。）
• XML構成ファイルは読み取り専用なので、複数のライターについて心配する必要はありません。
• XML構成ファイルは、サービス拒否を受ける可能性があります。引き続き排他的に開き、他のプロセスをロックアウトできます。
• XMLファイルには文字列のみが含まれます。バイナリデータを保存する場合は、何らかの方法でエンコードする必要があります。
• XMLファイルの解析は比較的遅いです。ただし、これらは読み取り専用であるため、解析結果を安全にキャッシュできます。したがって、解析する必要があるのは1回だけです。
• プログラムはXMLファイルを手動で解析しますが、XML形式は既にロックされているため、必要な場合でも拡張することはできません。願わくば、これらのプログラムは独自のXMLパーサーを使用するのではなく、標準に準拠したXMLパーサーを使用することを望みますが、70文字を超える命令や文字列を処理するなど、ユーザーが独自のカスタムXMLパーサーを作成しても驚かないでしょう。
• XMLファイルにはサイズ制限がありません。
• XMLファイルにはデフォルトの場所はありません。

これらはすべて、アプリケーションが実際に構成ファイルに書き込むことはないと想定していますが、これは同意していませんが、事態が悪化することはありません。

私の理論は、原動力は上記のどれでもないということです。むしろ、それは海賊版対策でした。登録前の日には、通常、プログラム全体をあるマシンから別のマシンにコピーするだけでした。.DLLを見つければ、準備完了です。レジストリにより、この処理は非常に難しくなります。

レジストリが達成することはほとんどなく、目的ごとに1つの構成ファイルで処理するほうが良いとは思いません。

（2014）私のここでの推論を少し拡張するために、レジストリを神のオブジェクトとして見ています。私たちは皆、それがアンチパターンであることを知っています。

私の大雑把な理解は、レジストリが設定リポジトリのようなものとして設計され、使用されていた.iniファイルに優先することです。

（NB、粗雑な理解、これはおそらく間違っているかもしれません）。

A）ティムの答えに同意します。

B）他のオペレーティングシステムは、プログラム設定を保存する他の方法を使用します。たとえば、Unixは通常、/ etc（グローバルファイル）およびさまざまな隠しフォルダー（ユーザー設定）のユーザーフォルダーにファイルを配置します。したがって、それらはすべて、何らかの形でレジストリを使用しますが、場合によっては配布されます。

私が理解したように（必ずしもそれを楽しんでいるわけではない）

A）プログラムがインストールまたはセットアップに関する情報を保存できる「中央の場所」を提供する。この情報は、プログラムが決定した方法で使用できます。カスタマイズ、著作権侵害対策など

この構造内にあるこれらすべての情報はそれを保護します。動物が一緒に群がるという考えを考えてください。情報の各ビットが独自のiniファイルである場合、一部のユーザーは気まぐれにそれを削除する可能性があります。彼らはまだレジストリにアクセスすることでそれを行うことができますが、多くの人はそれを一種のブラックボックスと見なし、システムを破壊する恐れがあるためにそれに触れません。

B）Mac OSは、レジストリが登場する前に使用されていたiniファイルウィンドウと同様に、個々のファイルを使用します。

レジストリの明白な目的は、すべての構成および設定データの単一のリポジトリとして機能し、構成ファイルへの依存を削除することです。

他のオペレーティングシステムでは、方法は、アプリケーション固有の情報（構成ファイルなど）をユーザーのホームディレクトリ内の非表示のアプリケーション固有のディレクトリに保存することです。（たとえば、ゲームAquariaは構成情報をに$HOME/.Aquaria保存します。）グローバル設定ファイルはに保存され/etc/ます。

Macは独自の処理を行いplistます。アプリケーション固有のファイルは、ユーザーまたはシステムのLibraryディレクトリに保存されます（私は信じています）。

問題はレジストリの哲学ではなく、その設計にあります。OSは、レジストリを使用して、ロードされるプログラムに関する重要な情報を検索します。ただし、必要なときに情報をロードするのではなく、ブート時にすべてロードするため、システムのパフォーマンスに影響を与える可能性があります。ベンダーが大量の情報をシステムにロードし、多くの場合、ソフトウェアがアンインストールされても情報を削除しないため、システムは徹底的に悪用されます。

すべてがn個のファイルに保存され、必要に応じてロードされるUnixとは異なります。このようにOSは、ベンダーのプログラミングスキルに依存してパフォーマンスに影響を与えません...

他のオペレーティングシステムについてコメントすることはできませんが、レジストリは、アップグレードまたはアンインストール/再インストールプロセス中にアプリケーションの構成を維持するのにも役立ちます。機能を追加したアップグレードのためにすべての構成が.iniファイルにある場合、問題が発生するか、構成データを着信iniファイルにマージするためにカスタマイズされたプロセスを作成する必要があります。

ただし、レジストリ内のデータを使用すると、アプリケーション設定に触れることなくファイルのアンインストール/再インストールを処理する一般的なインストーラーパッケージ（WIX、InstallShieldなど）を使用できます。

（すべてA. Bについて不明）

これは実際には、レジストリがアプリケーション設定の一種の共通インターフェースとして機能するという（歴史的な）ポイントまでだと思います。

アプリケーションをお持ちですか？ユーザースコープの設定を保存しますか？レジストリに入れてください。

「ユーザープロファイルを確保する」必要も、ファイルシステムに直接アクセスする必要もありません。Win32はすべてのことを考慮しています。

それは、ほとんどのユーザーにとって新しい、なじみのない、タブーなものを作成する方法でした。.iniファイルとautoexec.batファイルは、簡単に削除または変更できます。

登録設定の変更、ああ！

レジストリは、アプリケーションの設定を保存するだけでなく、プログラムとコンポーネントが他のプログラムとコンポーネントを見つけるための手段です。最終的に、これが何千ものテキストまたはxmlファイルに広がるのではなく、単一のデータベースに集中する理由だと思います。

たとえば、ビデオ効果を実行するコンポーネントは、レジストリに自分自身を「登録」し、他のビデオ関連アプリケーションがその存在を認識して使用できるようにします。このために集中システムを使用することにより、数千のシステムとアプリケーションが異なるレベルの統合を達成するために異なる方法を使用するため、深刻な混乱を避けることができます。