Windows 레지스트리가 필요한 이유는 무엇입니까?

com에서 Windows 나란히 dll 지옥을 처리하면서 문제를 디버그하면서 열정으로 Windows 레지스트리를 싫어하면서 왜 그것이 필요한지 궁금했습니다.

나는 레지스트리 베스트 프랙티스에 관한 책 전체를 읽은 다음에 그것을 "강력하게"강요받지 않았다.

그러나 Linux와 Mac OS를 사용했으며 동일한 * nix 컴퓨터에 여러 버전의 Python과 그 라이브러리를 설치할 수있는 방법을 살펴 보았습니다.

레지스트리는 다소 자유롭지 만 (거의 있지만) 모든 종류의 목적으로 사용되기 때문에 해결하려는 근본적인 문제를 결코 이해하지 못했습니다.

예를 들어, Microsoft는 두 가지 버전의 MS Office를 나란히 설치하지 않기를 원합니다. 설치하는 동안 레지스트리를 사용하여이를 시행합니다. 이 의견은 제 생각에 인공적인 것입니다. 그들이 실제로 다른 행동을 허용하기를 원한다면, 그에 따라 아키텍처를 조정할 수 있었을 것입니다.

Mac OS에서는 특정 폴더에 놓기 만하면 앱을 설치하고 제거 할 수 있습니다.

그래서,

A) 해결하려는 근본적인 문제는 무엇입니까? B) 다른 운영 체제는 어떻게 그것을 해결합니까?

다른 대답의 대부분은 다소 정확하지만 (질문과 함께) 요점을 놓칩니다.

레지스트리는 계층 적 데이터베이스 관리자입니다.

레지스트리에 귀속되는 "결함"은 실제로 레지스트리 자체와 무관합니다. 이들은 단순히 여러 가지 벤더가 프로그램 설치 방법과 같은 것에 대해 결정한 것입니다. 정보를 다른 패션 / 폼 / 컨테이너에 저장하면 동일한 문제가 남아있을 수 있습니다.

유닉스의 "모든 것이 파일이다"라는 철학을 감안할 때 유닉스 (및 Linux 및 MacOS와 같은) 시스템이 정보를 파일 시스템에 개별 파일로 저장한다는 것은 놀라운 일이 아닙니다. 유닉스 파일 시스템 자체는 계층 적 데이터베이스 (심지어 심볼릭 링크를 고려하면 네트워크 데이터베이스)이기 때문에 많은 사람들이 즉시 믿을 수있는만큼 다르지 않습니다. 가장 큰 차이점은 레지스트리가 별도의 API를 통해 액세스된다는 점입니다. 파일에 구성 데이터를 저장하면 다른 파일과 동일한 API (및 도구)를 통해 해당 파일에 액세스하고 편집 할 수 있습니다.

그것은 A의 설정 저장소 - 환경 설정, 설정, 경량 프로필에 대한 중앙 집중식 다소 표준화 된 위치 .

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]\ 앱에서 만든 숨김 폴더가 아닌 응용 프로그램 파일

맥 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가 조직의 시스템 및 응용 프로그램 데이터 그룹과 거의 일대일로 일치한다는 사실은 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 파일 구문 분석이 비교적 느립니다. 그러나 읽기 전용이므로 구문 분석 결과를 안전하게 캐시 할 수 있으므로 한 번만 구문 분석하면됩니다.
• 프로그램은 XML 파일을 수동으로 구문 분석하지만 XML 형식은 이미 잠겨 있으므로 원하는 경우에도 확장 할 수 없습니다. 이러한 프로그램이 자체적으로 롤링하는 대신 표준을 준수하는 XML 파서를 사용하길 바랍니다. 그러나 사람들이 명령 또는 문자열을 70 자보다 긴 문자열로 처리하는 고유 한 사용자 정의 XML 파서를 작성해도 놀라지 않을 것입니다.
• XML 파일에는 크기 제한이 없습니다.
• XML 파일에는 기본 위치가 없습니다.

이 모든 것은 응용 프로그램이 실제로 동의하지 않은 구성 파일에 절대 쓰지 않는다고 가정하지만 상황이 나빠지지는 않습니다.

나의 이론은 원동력이 위의 어느 것도 아니다. 오히려 불법 복제 방지 조치였습니다. 사전 등록 기간에는 일반적으로 한 프로그램에서 다른 시스템으로 전체 프로그램을 복사 할 수 있습니다. .DLL을 찾으십시오. 레지스트리는이 MUCH를 더 어렵게 만듭니다 .

목적마다 하나의 구성 파일로 더 잘 제공되지 않는다고 생각하는 레지스트리가 거의 없습니다.

(2014) 여기에서 나의 추론을 조금 확장하려면 : 레지스트리를 신의 대상으로 본다. 우리는 그것이 반 패턴이라는 것을 알고 있습니다.

내 이해는 레지스트리가 일종의 설정 저장소로 설계되어 사용되는 .ini 파일을 대체한다는 것입니다.

(NB, 이해하기 어려우므로 잘못되었을 수도 있습니다).

A) 팀 답변에 동의합니다.

B) 다른 운영 체제는 프로그램 설정을 저장하는 다른 방법을 사용합니다. 예를 들어 Unix는 일반적으로 / etc (글로벌 파일)에 파일을 저장하고 다양한 숨겨진 폴더 (사용자 설정)에있는 사용자 폴더에 파일을 저장합니다. 따라서 어떤 경우에는 배포되는 것을 제외하고는 모두 어떤 형태의 레지스트리를 사용합니다.

내가 이해할 때 (반드시 즐길 필요는 없음)

A) 프로그램이 설치 또는 설정에 대한 정보를 저장할 수있는 "중앙 위치"를 제공합니다. 그런 다음이 정보는 프로그램이 결정한 방식으로 사용될 수 있습니다. 사용자 정의, 불법 복제 방지 등

이 구조에있는 모든 정보는 그것을 보호하고 동물들이 서로 모여서 더 안전하다는 생각을 생각합니다. 정보의 각 비트가 고유 한 ini 파일 인 경우 일부 사용자는 변덕스럽게 삭제할 수 있습니다. 그들은 여전히 ​​레지스트리에 들어가서 그렇게 할 수 있지만 많은 사람들이 그것을 블랙 박스라고 생각하고 시스템을 무너 뜨릴 까봐 두려워하지 않을 것입니다.

B) Mac OS는 레지스트리가 나오기 전에 사용 된 ini 파일 창과 매우 유사한 개별 파일을 사용합니다.

레지스트리의 명백한 목적은 모든 구성 및 설정 데이터를위한 단일 저장소로 작동하고 구성 파일에 대한 의존을 제거하는 것입니다.

다른 운영 체제에서 modus 피연산자 는 구성 파일과 같은 응용 프로그램 특정 정보를 사용자의 홈 디렉토리에있는 숨겨진 응용 프로그램 특정 디렉토리에 저장합니다. 예를 들어 Aquaria 게임은 구성 정보를에 저장합니다 $HOME/.Aquaria. 전역 설정 파일은에 저장됩니다 /etc/.

Mac은 자신의 일을합니다. 응용 프로그램 특정 plist파일은 사용자 또는 시스템 Library디렉토리에 저장됩니다 (믿습니다) .

문제는 레지스트리의 철학이 아니라 디자인입니다. OS에서 레지스트리를 사용하여로드중인 프로그램과 관련된 중요한 정보를 찾습니다. 필요할 때 정보를로드하지 않고 부팅시 모든 정보를로드하므로 시스템 성능에 "영향을 줄 수 있습니다". 공급 업체가 많은 정보를로드하고 소프트웨어를 제거 할 때 정보를 제거하지 않는 경우가 많으므로 시스템도 철저하게 악용됩니다.

모든 파일이 n 개의 파일로 저장되고 필요할 때로드되는 Unix와는 다릅니다. 이 방법으로 OS는 벤더 프로그래밍 기술에 의존하여 성능에 영향을 미치지 않습니다 ...

다른 운영 체제에 대해서는 언급 할 수 없지만 레지스트리는 업그레이드 또는 제거 / 재설치 프로세스 중에 응용 프로그램 구성을 유지하는 데 도움이됩니다. 기능을 추가 한 업그레이드로 인해 모든 구성이 .ini 파일로 교체 된 경우 구성 데이터를 들어오는 ini 파일로 병합하기 위해 어려움이 있거나 사용자 정의 된 프로세스를 작성해야합니다.

그러나 레지스트리의 데이터와 함께 응용 프로그램 설정을 건드리지 않고 파일의 제거 / 재설치를 처리 할 수있는 공통 설치 프로그램 패키지 (WIX, InstallShield 등)를 사용할 수 있습니다.

(모두 A. B에 대해 확실하지 않음)

나는 이것이 레지스트리가 응용 프로그램 설정에 대한 일종의 공통 인터페이스 역할을한다는 사실 (역사적)에 달려 있다고 생각합니다.

신청서가 있습니까? 사용자 범위 설정을 저장하고 싶습니까? 레지스트리에 넣습니다.

"사용자 프로파일을 보장"할 필요가 없으며 파일 시스템에 직접 액세스 할 필요가 없습니다. Win32는 그 모든 것을 돌 봅니다.

그것은 대부분의 사용자들에게 새롭고 친숙하지 않은 금기를 만들 수있는 방법 이었으므로 혼자 남겨 두었습니다. .ini 및 autoexec.bat 파일을 더 쉽게 삭제하거나 변경할 수 있습니다.

등록 설정 변경, 오 마이!

단순히 응용 프로그램 설정을 저장하는 것 외에도 레지스트리는 프로그램 및 구성 요소가 다른 프로그램 및 구성 요소를 찾는 수단 입니다. 궁극적으로 이것이 수천 개의 텍스트 또는 xml 파일에 분산되는 것이 아니라 단일 데이터베이스로 중앙 집중화 된 이유라고 생각합니다.

예를 들어, 비디오 효과를 수행하는 구성 요소는 레지스트리에 '등록'되어 다른 비디오 관련 응용 프로그램이 그 존재를 알고 사용할 수있게합니다. 이를 위해 중앙 집중식 시스템을 사용하면 수천 개의 시스템과 응용 프로그램이 서로 다른 방법을 사용하여 통합 수준을 달성 할 때 심각한 혼란을 피할 수 있습니다.