Windows는 시스템의 IP 주소와 같은 작은 정보를 저장하기 위해 레지스트리에 많이 의존합니다. Unix, Linux 및 OS-X는 모든 것을 일반 파일에 저장합니다.
레지스트리와 관련하여 몇 가지 문제가 있습니다.
정보에 접근하는 것은 그리 쉽지 않습니다. 예를 들어, 머신이 부팅되지 않고 다른 OS(다른 Windows 또는 Linux)에서 디스크에 액세스하기 위해 다른 머신에 디스크를 마운트하여 문제를 해결하려고 하면 모든 파일에 쉽게 액세스할 수 있습니다( 권한 및 암호화는 제외). 그러나 레지스트리를 사용하면 이론적으로 읽기(및 아마도 변경)가 가능하지만 추가 애플리케이션이 필요합니다.
명령줄 액세스(머신이 더 이상 부팅되지 않는 상황에서)는 불가능합니다(해당 앱도 없는 한). 하지만 해당 앱을 설치하고 사용하는 것이 단순히 디스크에 있는 파일에 액세스하는 것보다 훨씬 어렵다고 확신합니다. ).
정보는 파일이나 레지스트리에 위치할 수 있으므로 두 위치를 혼합해야 합니다.
파일 작업 시 사용되는 일반적인 도구(예
findstr: Windows의 동생 인grep)는 레지스트리 키 작업 시 존재하지 않습니다.
Microsoft가 원래 레지스트리를 구현했다면 그럴 만한 이유가 있었으며 당시의 다른 운영 체제에 비해 Windows에 (약간이라도) 경쟁 우위를 제공했다고 확신합니다.
Windows가 탄생할 당시 특히 중요했던 성능 및 공간 제약에 대해 생각했지만 레지스트리에 무언가를 저장하면 어떻게 성능이 향상되거나 사용되는 공간이 줄어드는지(DWORD를 실제 DWORD로 레지스트리에 저장하는 것과 문자열 표현을 레지스트리에 저장하는 것) 알 수 없습니다. 파일을 저장하면 공간이 절약되지만 1985년에도 그게 그렇게 중요할까요?
보안 측면에서도 차이가 없는 것 같습니다. 1985년에도 그랬는지는 잘 모르겠지만 오늘날의 파일 기반 권한은 레지스트리 키에 대해 구현된 권한만큼 강력해 보입니다.
조직도 비슷합니다. 즉, 색인/검색 기능이 없는 트리 기반 구조입니다(Windows의 이후 버전에서는 파일에 대한 색인을 구현합니다).
그렇다면 모든 것을 파일에 저장하는 것과 비교하여 레지스트리의 원래 이점은 무엇입니까?
답변1
Microsoft가 레지스트리를 사용하기 전에는INI 파일(텍스트 파일). 그들은 다음과 같은 이유로 INI 파일만을 사용하여 좋은 플랫폼을 개발하는 것이 매우 어렵다는 것을 알았습니다.
- 유니코드를 지원하는 것은 쉽지 않습니다.
텍스트 파일이므로 키 수준이 아닌 파일 수준에서 권한이 설정됩니다. 파일에 액세스할 수 있는 사람은 누구나 해당 파일의 모든 매개변수에 액세스할 수 있습니다.
두 스레드가 동시에 INI 파일을 업데이트하려고 하면 다른 스레드의 변경 사항이 실수로 삭제될 수 있습니다.
- 프로그램은 단독 모드에서 INI 파일을 열고 다른 모든 사람을 잠글 수 있습니다.
- INI 파일에는 문자열만 포함됩니다. 바이너리 데이터를 저장하려면 어떻게든 문자열로 인코딩해야 합니다.
- INI 파일 구문 분석이 느립니다.
- INI 파일의 중앙 관리가 어렵습니다. 시스템 어디에나 있을 수 있기 때문에 네트워크 관리자는 애플리케이션 상태를 확인하고 오래된 애플리케이션을 업그레이드하는 스크립트를 작성할 수 없습니다.
- 시스템은 다중 사용자가 되기 시작했고 모든 사용자의 설정을 계속 제어하는 것이 부담스러워지기 시작했습니다. 이는 때때로 각 사용자에 대해 분리된 INI 파일을 의미했습니다.
이는 Microsot가 새로운 솔루션을 찾도록 영향을 준 주요 사항이며 레지스트리와 함께 제공됩니다. 레지스트리는 데이터베이스이므로 이전 문제를 해결하지만 새로 생성되었습니다.
- 단일 실패 지점입니다.
- 바이너리입니다. 손상된 경우 맨손으로 수리하기가 매우 어렵습니다.
- 설정을 레지스트리에 저장하는 응용 프로그램은 이식성이 떨어집니다.
- 복잡한 탐색.
중요한 출처에 대한 크레딧:http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx