예전에 만들어놨던 라이브러리의 기능 추가에 대한 문의가 있어서 최근에 SHBrowseForFolder를 이용한 폴더 선택 추가 메서드를 구현해 주었습니다. 또한 그 기능에, "최초 폴더 선택" 가능한 경로를 지정할 수 있도록 해달라는 요청에 그렇게 해주었습니다.
SHBrowseForFolder의 함수 원형이 다음과 같지요.
LPITEMIDLIST SHBrowseForFolder( LPBROWSEINFO lpbi );
유일한 인자인 BROWSEINFO 구조체는 다음과 같이 정의되어 있습니다.
typedef struct _browseinfo {
HWND hwndOwner;
LPCITEMIDLIST pidlRoot;
LPTSTR pszDisplayName;
LPCTSTR lpszTitle;
UINT ulFlags;
BFFCALLBACK lpfn;
LPARAM lParam;
int iImage;
} BROWSEINFO, *PBROWSEINFO, *LPBROWSEINFO;
여기서, pidlRoot 값이 바로 폴더 선택창을 띄웠을 때 루트로 지정되는 경로의 PIDL 값입니다. PIDL은 Windows Shell 에서 Shell 개체에 대한 유일한 값을 나타내는 ID라고 보시면 편할 것 같습니다. 혹시나, 파일 경로가 ID로 될 수 있지 않느냐 하시는 분들도 계시겠지만, 파일 경로로 표현이 안되는 Shell 개체도 있을 수 있다는 것을 아셔야 합니다. 예를 들어, 탐색기의 "내 컴퓨터" 노드는 파일 시스템이 아닌 데도 탐색기에 표시되어 있습니다. 그것을 구별하기 위해서 "파일 경로"를 사용할 수는 없기 때문에, 바로 이런 때 해당 노드를 구분해 줄 수 있는 것이 PIDL입니다.
그렇다면, 위의 값에 대해 PIDL을 어떻게 줄 수 있을까요? PIDL은 직접 사용자가 구할 수는 없습니다. 만약 임의의 경로를 지정하고 싶다면, 그 경로에 대한 PIDL 값을 구해서 pidlRoot 인자에 넣어주어야 합니다.
바로 이런 때 사용되는 메서드가 SHParseDisplayName 함수입니다.
이 함수의 원형은 다음과 같습니다.
HRESULT SHParseDisplayName( LPCWSTR pszName, IBindCtx *pbc,
LPITEMIDLIST *ppidl, SFGAOF sfgaoIn, SFGAOF *psfgaoOut
);
pszName 인자에 우리가 알고 있는 경로를 넘겨주면 ppidl 값이 [out] 파라미터 형식으로 해서 반환이 됩니다.
이렇게 해서, 구현을 마치고 해당 COM 개체를 고객에게 넘겨 주었는데, 얼마 안 가서 바로 문제 보고가 들어왔습니다. Windows 2000에서 COM 개체 등록이 안된다는 것입니다.
이런 경우, 거의 99.999%는 새로 추가한 메서드의 의존성 때문에 그런 경우일 것입니다.
가만히 살펴보면, SHParseDisplayName 함수 추가로 인해 문제가 발생했음을 알 수 있습니다. 해당 메서드는 Shell32.dll에 구현되어 있고, 그로 인해 만들어진 DLL에 대한 Depends.exe로 살펴보면 다음 화면과 같이 "SHParseDisplayName" 항목이 "빨간색 C" 모양으로 나오는 것을 볼 수 있습니다. 즉, 구현 함수가 포함 안되어져 있다는 것이지요. (물론, MSDN 도움말을 찾아보면 Minimum operating systems 요구 사항에 Windows XP라고 나와 있습니다.)
위의 함수 때문에 Windows 2000에서는 등록 자체가 거부되고 있는 것입니다.
저는 이것을 해결해야만 했으며, 결국 위의 하면에서 왼쪽의 파란색 상자에 둘러쳐진 것과 같이 delayed-load DLL로 shell32.dll을 명시를 했습니다. 왜냐하면, RegisterServer 등록 API가 실행되는 동안에는 SHParseDisplayName API 로 인해 등록을 방해받아야 할 이유가 없기 때문입니다.
그런데, 이렇게만 해놓으면 문제가 되겠지요. 틀림없이 해당 기능을 사용하는 메서드를 호출하게 되면 여지없이 프로그램은 crash 되어집니다. 따라서, 현재의 운영체제가 Windows XP 이상인지 검사하는 코드를 추가해야 합니다.
위와 같은 해결 방법 이외에도, SHParseDisplayName API 자체를 GetProcAddress로 처리하는 방법도 있을 수 있습니다.
그나저나, 그리 대단해 보이지 않는 SHParseDisplayName API가 Internet Explorer 관련 업데이트에 포함시키지 않는 이유를 이해할 수가 없군요.