GetObject progids는 어떻게 유지 관리됩니까?

Question

윈도우 쉘 스크립트 (VBS) has the following method :

object.GetObject(strPathname [,strProgID], [strPrefix]) 

지금 나는 다음과 같은 코드가 있다고 가정

set myval = getObject("myObjectRef:myObjectArgs") 

이 하나의 시스템에서 작동

-가 아닌 다른합니다.

내가 원하는 것은 모든 myObjectRef/progIds가 유지되는 최종 목록을 찾는 것입니다.

내 질문 : GetObject progids는 어떻게 유지 관리됩니까?

가정 :

• 나는 내가보고 갈 수있는 특별한 장소를 찾을 찾고 있어요
• "레지스트리에서 검색을 할"것을 더 정교한 대답을 찾고 있어요 내 progid 그것이 존재 여부를 볼 수 있습니다. 그 정말 모든 걸리는 때문에

Answer 1

내가

"글쎄 레지스트리에서 검색을 할"것을 더 정교한 대답을 찾고 있어요, 그것은 조금 어렵습니다. 정확히 "검색"할 필요는 없지만 찾고자하는 곳을 살펴보십시오. regedit.exe의 HKEY_CLASSES_ROOT 하이브 바로 아래에있는 키는 사전 순으로 정렬되므로 키보드에 "m"키를 입력하면 찾고있는 progid를 이미 닫을 수 있습니다. "myObjectRef.myObjectArgs"키가 보이지 않으면 COM에서 찾을 수 없을 때 런타임에 kaboom을 사용할 수 있습니다.

고유 한 것을 보장하기 위해 progids를 유지 관리하는 엔티티와 "명확한 목록"이 없습니다. 이 목록은 각 컴퓨터마다 고유하며 해당 컴퓨터에 설치된 항목에 따라 Regedit.exe에서 찾을 수있는 항목이 결정됩니다. GUID는 단순한 사람 친화적 인 버전이며 값인은 COM 구성 요소를 찾는 데 중요합니다. 서버를 모호하지 않게 식별하는 Globally Unique ID. progid 키의 CLSID 하위 키는 해당 GUID를 제공합니다. 그것은 큰 숫자이며 인간에게 친숙하지 않습니다.

구성 요소가 자체적으로 설치되면 progid 키가 레지스트리에 기록됩니다. 누락 된 키는 단순히 설치되지 않았 음을 의미합니다.

64 비트 버전의 Windows를 부팅하는 컴퓨터에서 흔히 발생하는 문제는 COM 서버가 32 비트 구성 요소로만 사용할 수 있지만 클라이언트는 64 비트 프로세스라는 것입니다. 레지스트리에서도이 문제가 해결되며 CLSID 키는 HKLM \ Software \ Wow6432Node \ Classes에만 있습니다. Wow6432Node 섹션은 ​​32 비트 클라이언트가 보는 것입니다. 따라서 64 비트 클라이언트는 HKLM \ Software \ Classes를보고 키를 찾지 않습니다. 실제로 존재하지 않더라도 "설치되지 않은"문제처럼 보입니다. 64 비트 버전이 아닙니다. SysInternals의 프로세스 모니터는 이와 같은 문제를 진단하는 훌륭한 도구입니다. 레지스트리를 통해 검색하는 실패한 클라이언트 프로그램을 볼 수 있습니다.