작업하다보니 단축아이콘도 만들어야 겠네.. -_-;;
마우스로 드래그만 하면 되는데 플그램으로 짜려면 왤케 이것 저것 해야하는게 많은건지..
MSDN에서 권장하는 IShellLink 인터페이스를 이용하여 제작합니다.

클래스로 만들 이유는 없는데, 이것 저것 추가될깨 있어어 그냥 껍데기를 씌웠습니다.
참고로 일반적인 헤더 외에, 아래꺼 추가되야 할겁니다.
#include <atlbase.h>
#include <comdef.h>

VC++ 6.0 SP6, 및 Platfrom SDK 2004년 버전에서 테스트됨.

헤더파일
-----------------------------------------------------------------------------------
class CFileShell 
{
public:
 CFileShell();
 virtual ~CFileShell();

    // 지정한 파일로 주어진 특수 경로에 단축아이콘을 만든다.
    BOOL CreateShortCut(const char* filepath, int nFolder, const char* dispname = NULL, const char* description = NULL, const char* workdir = NULL);

    // 특수한 경로에 주어진 이름의 폴더를 만든다.
    CString CreateSpecialForder(int nFolder, const char* forder_name);
};

1. CreateShortCut
   filepath         전체경로를 가진 파일 이름
   nFolder         CSIDL Costants 를 지칭합니다. 참고 SHGetSpecialFolderPath
   dispname      단축아이콘의 이름, 설정하기 않으면 원본 파일이름으로 대체
   description   단축아이콘 설명
   workdir          아이콘이 실행될 경로, 설정하지 않으면 원본 파일의 경로로 대체

2. CreateSpecialForder
   nFolder          CSIDL Costants 를 지칭합니다. 참고 SHGetSpecialFolderPath  
   forder_name  생성할 폴더의 이름



소스 파일
-----------------------------------------------------------------------------------
BOOL CFileShell::CreateShortCut(const char* filepath, int nFolder, const char* dispname, const char* description, const char* workdir)
{
    char TargetPath[MAX_PATH];
    CString fromPath=filepath, fromName, fromExt, ShortCutName;

    if(!SHGetSpecialFolderPath(NULL, TargetPath, nFolder, FALSE))
        return FALSE;

    HRESULT hr;
     CComPtr<IShellLink>   pISL;

    hr = pISL.CoCreateInstance( CLSID_ShellLink );
     if(FAILED(hr))
        return FALSE;

    // 단축 아이콘의 대상이 되는 파일을 설정한다.
    hr = pISL->SetPath ( filepath );
     if(FAILED(hr))
        return FALSE;

    // 주어진 소스 파일의 경로를 이용하여, 전체 패스, 이름, 확장자를 나눈다.
    int find = fromPath.ReverseFind('\\');
    if(find == -1)
        return FALSE;

    fromName = fromPath.Right(fromPath.GetLength()-find-1);
    fromPath = fromPath.Left(find+1);

    find = fromName.ReverseFind('.');
    if(find != -1)
    {
        fromExt  = fromName.Right(fromName.GetLength()-find-1);
        fromName = fromName.Left(find);
    }

    // 별도로 디스플에이용 이름을 주면 그것을 사용한다.
    if(dispname)
        fromName = dispname;

    // 별도로 수행 경로를 주면 그것을 이용한다.
    if(workdir)
        fromPath = workdir;


    // 단축 아이콘에 대한 설명을 단다.
    if(description)
    {
        hr = pISL->SetDescription ( description );
        if(FAILED(hr))
            return FALSE;
    }
   
    // 워킹 폴더를 설정한다.
    hr = pISL->SetWorkingDirectory ( fromPath );
    if(FAILED(hr))
        return FALSE;

   
    WCHAR ShortCutNameW[256] = {0};
    ShortCutName = fromPath + fromName + ".lnk";

    MultiByteToWideChar(CP_ACP, MB_COMPOSITE, ShortCutName, ShortCutName.GetLength(), ShortCutNameW, 256*sizeof(WCHAR));

    CComQIPtr<IPersistFile> pIPF( pISL );
     hr = pIPF->Save ( ShortCutNameW, FALSE );
     if ( FAILED(hr) )
        return FALSE;

    return TRUE;
}

CString CFileShell::CreateSpecialForder(int nFolder, const char* forder_name)
{
    char TargetPath[MAX_PATH];
    if(!SHGetSpecialFolderPath(NULL, TargetPath, nFolder, FALSE))
        return "";

    CString FullName = TargetPath;
    FullName += "\\";
    FullName += forder_name;

    if(!CreateDirectory(FullName, NULL))
    {
        DWORD le = GetLastError();
        if(le != ERROR_ALREADY_EXISTS)
            return "";
    }

    return FullName;
}

이 장은 SHLoadInProc 라는 강력한 함수로 인하여
우리가 얼마나 쉽게 윈도우즈 쉘의 메모리안에 접근이 가능한지를 보여준다.

여기에 논의되는 대부분읜 코드는 Dll로 설계된 COM 파일이며,
기본적인 내용을 제외하고는 아주 간단한 코드가 추가될 뿐이다.

여러분들의 최소한의 COM 오브젝트를 만들기 위하여
다음과 같은 함수를 생서하여 주어야 한다.

프로젝트의 생성은 MFC에서 Win32 Dynamic Link Library로
생성하였으며, Blank로 만들면 된다.

여기에 적당한 헤더들을 연결하고..

DllGetClassObject()
DllCanUnloadNow()
DllRegigterServer()
DllUnregisterServer()

각각의 소스 구현은 첨부파일에 있으며.. 여기서는 위의
4개의 함수의 필요성과 구현에 대한 개념을 설명한다.

이글을 쓰고 있는 필자는 COM에 컴자도 모르고, ATL도 모른다.
단지 Shell Programming를 공부해가며 위의 개념이 나오므로 그냥 하나의 프로그램 코드로 이해하며 넘어가고 있다.

1. DllGetClassObject() 함수

STDAPI DllGetClassObject(
REFCLSID rclsid,
REFIID riid,
LPVOID* ppv)

COM객체의 클라이언트는 어떤 것이든지 먼저 COM 객체를 포함하고 있는 라이브러리를 로드시켜야 한다. 그리고 나서, DllGetClassObject() 통해 그것이 필요로 하는 인터페이스 포인터를 얻는다. 자세한 것은 필요없고 중요한 것은 이 함수가 항상 호출된다는 것이다. 그리고 바로 그 클래스 객체가 로드된다. 풀어서 설명하면 이 COM 객체를 로딩하는 놈이 있으면 그 로딩하는 클라이언트에 의해서
DllGetClassObject() 함수가 호출되어진다는 것이다.
그리고 내가 만든 이 COM 객체는 나를 호출하는 클라이언트의 메모리 않에서 동작하게 된다.

대게 모듈들이 객체를 읽어 들일경우 DllGetClassObject를 호출하면서 IClassFactory 인터페이스란걸 요청한다.
하지만 우리는 (혹은 나만) COM이 먼지 모르므로 그러한 요청에 응답할 수 없다고 답변하면 된다.

STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID* ppv)
{
return CLASS_E_CLASSNOTAVAILABLE;
}


2. DllCanUnloadNow의 역활

DllGetClassObject를 이용하여 COM 객체를 읽어들인 모듈은DllCanUnloadNow()를 호출하여 확실하게 그 DLL이 안전하게 메모리에서 사라지도록 해야한다.
즉 위의 함수가 S_OK를 리턴하면 메모리상에서 제거할 수 있는 것이다.

STDAPI DllCanUnloadNow()
{
return S_OK;
}

3. 그리고 나머지
DllRegigterServer()
DllUnregisterServer() 는 regsvr32.exe를 이용하여 이
COM 객체를 등록하고 해지하는 역활을 담당한다.

뭐 구지 사용하기 귀찬으면 REG파일을 만들어도 된다.

지금 까지가 설명한 중요한 것은 다 넘아갔다.
우스을지 모르지만 나머지 코딩은 그냥 APP 프로그램과
동일하다.

즉, COM으로 프로젝트를 만든다는 것과 위에서 설명한 두 함수의 대강의 용법만 깨우치면 우리는 쉘에 침략할 수 있다.

참고로 위에서 설계한 COM 객체를 등록는 것은 걍하고..
구동하는 것은

임의의 어플리케이션이나 머 아무거나 만들어서..
const CLSID clsid = {0x????????, 0x????, 0x????,
{0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??}};

SHLoadInProc(clsid);

이렇게 구동하면 된다...

코드가 쫌 길어서 짜증나지만.. 정말 도전해볼만한 프로그램이다.

지금 다루고 있는 SHLoadInProc() 함수를 이용한 쉘에 대한 도전과 생략한 기법중에 하나가 Hook 이다..
Hoo에 대한 설명은 앞으로도 생략할 것이고..

이 장을 넘어가면 Browser Helper Object (BHO)라는 것을
이용하여 좀더 용이하고 좀더 확장된 기능으로 쉘에 대한 침략을 할것이다. 이를 위하여 위에서 설명한 최소한의 COM 객체를 구혈할 수 있어야 하며, 그로 인한 동작을 직접 코딩하여 동작 시켜보아야할 필요가 있다.

^^;

Windows 95의 출현과 함께 문서의 개념이 중요성을 띠게 되었다. 이제는 실행파일이라는 개념이 좀더 복잡해 지고 단순히 구동한다는 의미를 떠나 아주 방대한 개념으로 자리 잡고 있다.
문서라고 하는 것은 시스템의 네임스페이스의 일부인 보다 일반적인 객체를 말하고자 하며, 이문서에 대하여 '열기(open)', '인쇄(print)', '탐색(explore)', '찾기(find)'를 하는 프로그램이 있다. 다시 말해서, 문서라는 것은 그것에 대해서 프로그램이 어떤 동사(Verb)를 실행할 수 있는 모든 아이템을 말한다.

지금의 프로그램 실행자의 모체였던 WinExec()에서 ShellExecuteEx()라는 함수로 그 진행이 옮겨가는 이유도 이해 따른다.

이 장에서는 다음과 같은 것들을 다룰 것이다.
1. WinExec()와 CreateProcess() 사이의 차이점
2. ShellEcecute()와 ShellExecuteEx()가 다른 함수보다 우수한점
3. 동사들(Verb), 문서들 그리고 정책들(Policy)
4. 훅킹을 사용하여 프로세스 실행을 내 마음대로

그리고 다음과 같은 몇가지 예제 코드를 살펴볼 것이다.
1. 디폴트 브라우져 감지법
2. 프로그램을 실행시키고 종료를 기다리는법
3. 어떤 파일에 대한 등록정보 대화상자를 나타내는법
4. 찾기 대화상자를 화면에 출력하는 법
5. 사용자가 특정 폴더를 액세스하지 못하게 하거나, 다른 특정 어플리케이션을 실행하지 못하게 막는법

=====================================================

1. WinExec()에서 CreateProcess()로...

UINT WinExec(LPCSTR lpCmdLine, UINT uCmdShow);
이 함수는 Windows 3.x에서는 외부 프로그램을 실행시키는 유일한 방법이었다. 그리고 가장 간단한 사용법을 가지기도 한다.
하지만 단점이라 불리울 수 있는 것이 일단 실행을 시켜 놓으면 실행이 되는지 에러가 났는지, 종료 되었는지 전혀 알수가 없다는 것이다.

다음은 CreateProcess()의 프로토 타입이다.
BOOL CreateProcess(
LPCTSTR lpApplicationName, // 실행파일 모듈의 이름에 대한 포인터
LPTSTR lpCommandLine, // 커맨드 문자열에 대한 포인터
LPSECURITY_ATTRIBUTES lpPA, // 프로세스 보안 속성 포인터
LPSECURITY_ATTRIBUTES lpTA, // 스레드 보안속성 포인터
BOOL bInheritHandles, // 핸들 상속 여부 플래그
DWORD dwCreationFlags, // 생성 플래그
LPVOID lpEnvironment, // 환경 블록에 대한 포인터
LPCTSTR lpCurrentDirectory, // 현재 디렉토리
LPSTARTUPINFO lpStartupInfo, // STARTUPINFO 포인터
LPPROCESS_INFORMATION lpPI // PROCESS_INFORMATION 포인터
);

보시다 시피 여기에는 많은 파라미터들이 있다 하지만.. 대부분의 내용이 MSDN에 잘 문서화가 되어 있으므로 그렇게 어렵다거나 하지는 않다.
일단 가장 간단한 호출을 한번 살펴보자.

STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(STARTUPINFO));

CreateProcess(NULL, szPrgName, NULL, NULL, TRUE, NORMAL_PRIORITY_CLSS, NULL, NULL, &si, &pi);

WinExec보다는 복잡하지만 여러가지 부가적인 정보를 줄 수도 있고 받을 수도 있으므로 상대적인 저비용이다.

만약 위의 프로그램을 실행시키고 종료하기를 기다린다고 하면..

BOOL b = CreateProcess(............);
if(!b)
return FALSE;

WaitForSingleObject(pi.hProcess, INFINITE);
return TRUE;

정말 간단하지 않는가? ^^;
위의 결과를 외견상으로 보면 WinExec의 문제점들의 CreateProcess() 함수로써 모두 해결했다는 생각을 할 수도 있겠지만 현재의 문서라는 개념은 좀더 일반화 되었다. 위에서 사용된 실행가능한 프로그램(exe, com ...etc)등은 문서의 한가지 유형일 뿐이다.


2. ShellExecute()와 ShellExecuteEx()가 다른 함수보다 우수한점

HINSTANCE ShellExecute(
HWND hwnd, // 부모 윈도우 핸들
LPCTSTR lpVerb, // 동사 혹은 작업
LPCTSTR lpFile, // 실행 대상 문서
LPCTSTR lpParameters, // 컴맨드 인자
LPCTSTR lpDirectory, // 현재 디렉토리
INT nShowCmd // 보여주기 옵션
);

일단 위의 함수를 살펴보면 CreateProcess() 함수보다 기능이 많이 떨어지는 것 처럼 보이지만 이 함수의 진정한 의미는 동사 연결이라는 점이다.
보통 우리가 말하는 [연결 프로그램]을 지칭한다.

위에서 [동사 혹은 작업] 부분의 LPCTSTR lpVerb 에 사용될 수 잇는 것은데 대한 나열이다.
===============================================
열기(open) - 프로그램/문서/폴더
탐색(explore) - 폴더
인쇄(print) - 문서
~~로 인쇄(printto) - 문서
찾기(find) - 폴더

------> 먼저 열기(open)에 대하여 살펴보자.

ShellExcute(hwnd, "open", "c:\\prog.exe", "/nologo", "d:\\", SW_SHOW);

ShellExcute(hwnd, "open", "c:\\file.txt", NULL, NULL, SW_SHOW);

만약 txt확장자를 가진 파일에 대한 연결이 존재하지 않으면 우리가 많이 보던 연결프로그램 대화상자가 나타날 것이다.

------> 탐색 작업

탐색 작업은 폴더에 대해서만 가능하고 open 인경우와 약간의 차이를 나타낸다.
open로 동사를 주면 pane이 하나로 된 창이 뜨고, explore로 주면 pane가 2개인 탐색기다 뜬다.

ShellExcute(hwnd, "expolre", "c:\\", NULL, NULL, SW_SHOW);

------> 인쇄 작업

인쇄작업은 문서를 인쇄하기 위한 것이지만, 지정된 문서를 인쇄할 수 있는 명령어 라인과 프로그램을 정확히 알나내기 위해 레지스트리에 저장된 정보에 의존한다.

ShellExcute(hwnd, "print", "c:\\file.txt", NULL, NULL, SW_SHOW);

이 함수는 텍스트 파일을 처리하기 위해 등록된 프로그램을 찾고, 그 프로그램에 인쇄를 위한 명령이 있는지 검사한다. 정상적이라면 이 프로그램은 notepad.exe가 될 것이고, 그 명령어 라인은 다음과 같다.

notepad.exe /p

디폴트 프린터로의 인쇄는 위에서 처럼 간단하게 사용이 가능하지만 만약 여러개의 프린터가 있거나 출력 포트를 설정하고 싶다면 printto를 사용해야 한다.

만약 printto가 문서에서 지원이 된다면 등록된 명령이 실행될것이고 그렇지 못하다면..
경고창이 뜨면서 디폴트 프린터로 출력할 것이지를 묻는다.

------> 찾기 작업

지정된 경로를 루트로 찾기 창이 생성된다.
예제는 생략한다. ^^;


그렇다면 파일을 열기 위해서 혹은 그 파일과 연결된 실행 프로그램은 어떻게 구할 수 있는가?
의외로 쉽게 구할 수 있다. SDK에서 API를 제공하니까 ^^;

HINSTANCE FindExecuteable(
LPCTSTR lpFile, // 알아볼 파일
LPCTSTR lpDir, // 경로
LPTSTR lpResult) // 찾은 결과값

하지만 위 함수에는 치명적인 결함이 있다.
1. 보통 연결 프로그램은 확장자를 기준으로 검색되지만 이 함수는 항상 파일이 존재하여야만 결과를 리턴한다.
2. 경로에 공백이 있어도 않된다.
3. 리턴하는 결과에도 공백이 있으면 잘린다.

한마디로 엉터리에 가까운 API라 말할 수 있다.
이렇듯 이 함수는 규칙없이 긴 이름을 가진 파일을 염두에 두지 않고 설계되었기 때문에 생기는 문제인데..
MS에서 알고 있지만 절대 고치지 않는다..
Windows 이후로 긴 이름의 파일을 지원하지만..
MS Windows에서 시스템 명령어 중에 8.3포멧을 지키지 않는 명령어는 아직까지도 존재하지 않는다.

이 문제를 바로잡기 위한 FindExecutableEx를 만들어보자.
HINSTANCE FindExecutableEx(... 인자는 동일하다 ...)
{
TCHAR drive[_MAX_DRIVE];
TCHAR dir[_MAX_DIR];
TCHAR dir1[_MAX_DIR];
TCHAR file[_MAX_FILE];
TCHAR ext[_MAX_EXT];

HINSTANCE hi = FindExecutable(file, dir, result);
result[lstrlen(result)] = 32;

_splitpath(result, deive, dir, file, ext);

LPTSTR p = strchr(dir, ':');
if(p != NULL)
{
--p;
dir[p-dir] = 0;
_splitpath(dir, NULL, dir1, file, ext);
p = strchr(ext, 32);
ext[p-ext] = 0;
_makepath(result, drive, dir1, file, ext);
}
return hi;
}
이전에 설명했듯이 SHLoadInProc를 사용해서 침략을 할경우는 먼저 이것을 로딩해주는 프로그램이 존재해야했다.

하지만 BHO를 이용해서 하면 우리가 만든 객체를 레지스트리에 등록해주고 나면 끝이다.
탐색기나 인터넷 익스프롤러의 인스턴스가 생성될때마다 레지스트리의 BHO 부분을 읽어서 객체를 로딩하고 인스턴스가 소멸될때 로딩한 객체도 소멸된다.

먼저 ATL Wirzard로 DLL 골격을 만든다.

그리고, 메뉴에서 Insert -> New ATL Object를 선택한다.

그리고 Simple Object를 선택한후 NewFolder로 심플 오브젝트를 만들고 샘플의 소스를 삽입한다.

일단 이러한 인련의 과정을 거쳐서 객체를 생성한다.

나머지는 소스를 참고하고..
실제 구동에서 Windows NT 환경과 Windows 9X 환경에서도
동작은 동일하지만..
문자열의 처리가 틀리므로..
9x 계열에서는 ANSI로
NT 계열에서는 Unicode 형태로 선택해야 한다.

그리고, 끝으로 RGS 파일을 수정하여 다음과 같은 스크립트를 추가해야 해서 마무리한다.
아래의 스크립트는 BHO를 등록하는 과정이다.

HKLM
{
SOFTWARE
{
Microsoft
{
Windows
{
CurrentVersion
{
Explorer
{
'Browser Helper Objects'
{
{FAFC718E-632B-11D6-B5D3-0050BF79AAF5}
}
}
}
}
}
}
}

VOID SHChangeNotify(
LONG wEventId,
UINT uFlags,
LPCVOID dwItem1,
LPCVOID dwItem2
);

wEventId ===========================================>
SHCNE_ALLEVENTS All events have occurred.
SHCNE_ASSOCCHANGED A file type association has changed. SHCNF_IDLIST must be specified in the uFlags parameter. dwItem1 and dwItem2 are not used and must be NULL.
SHCNE_ATTRIBUTES The attributes of an item or folder have changed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the item or folder that has changed. dwItem2 is not used and should be NULL.
SHCNE_CREATE A nonfolder item has been created. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the item that was created. dwItem2 is not used and should be NULL.
SHCNE_DELETE A nonfolder item has been deleted. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the item that was deleted. dwItem2 is not used and should be NULL.
SHCNE_DRIVEADD A drive has been added. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive that was added. dwItem2 is not used and should be NULL.
SHCNE_DRIVEADDGUI A drive has been added and the shell should create a new window for the drive. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive that was added. dwItem2 is not used and should be NULL.
SHCNE_DRIVEREMOVED A drive has been removed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive that was removed. dwItem2 is not used and should be NULL.
SHCNE_EXTENDED_EVENT Not currently used.
SHCNE_FREESPACE The amount of free space on a drive has changed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive on which the free space changed. dwItem2 is not used and should be NULL.
SHCNE_MEDIAINSERTED Storage media has been inserted into a drive. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive that contains the new media. dwItem2 is not used and should be NULL.
SHCNE_MEDIAREMOVED Storage media has been removed from a drive. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the root of the drive from which the media was removed. dwItem2 is not used and should be NULL.
SHCNE_MKDIR A folder has been created. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the folder that was created. dwItem2 is not used and should be NULL.
SHCNE_NETSHARE A folder on the local computer is being shared via the network. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the folder that is being shared. dwItem2 is not used and should be NULL.
SHCNE_NETUNSHARE A folder on the local computer is no longer being shared via the network. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the folder that is no longer being shared. dwItem2 is not used and should be NULL.
SHCNE_RENAMEFOLDER The name of a folder has changed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the previous PIDL or name of the folder. dwItem2 contains the new PIDL or name of the folder.
SHCNE_RENAMEITEM The name of a nonfolder item has changed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the previous PIDL or name of the item. dwItem2 contains the new PIDL or name of the item.
SHCNE_RMDIR A folder has been removed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the folder that was removed. dwItem2 is not used and should be NULL.
SHCNE_SERVERDISCONNECT The computer has disconnected from a server. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the server from which the computer was disconnected. dwItem2 is not used and should be NULL.
SHCNE_UPDATEDIR The contents of an existing folder have changed, but the folder still exists and has not been renamed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the folder that has changed. dwItem2 is not used and should be NULL. If a folder has been created, deleted, or renamed, use SHCNE_MKDIR, SHCNE_RMDIR, or SHCNE_RENAMEFOLDER, respectively, instead.
SHCNE_UPDATEIMAGE An image in the system image list has changed. SHCNF_DWORD must be specified in uFlags. dwItem1 contains the index in the system image list that has changed. dwItem2 is not used and should be NULL.
SHCNE_UPDATEITEM An existing nonfolder item has changed, but the item still exists and has not been renamed. SHCNF_IDLIST or SHCNF_PATH must be specified in uFlags. dwItem1 contains the item that has changed. dwItem2 is not used and should be NULL. If a nonfolder item has been created, deleted, or renamed, use SHCNE_CREATE, SHCNE_DELETE, or SHCNE_RENAMEITEM, respectively, instead.

The following values specify combinations of other events: SHCNE_DISKEVENTS Specifies a combination of all of the disk event identifiers.
SHCNE_GLOBALEVENT Specifies a combination of all of the global event identifiers.


The following value modifies other event values and cannot be used alone: SHCNE_INTERRUPT The specified event occurred as a result of a system interrupt.


uFlags ===========================================>
Flags that indicate the meaning of the dwItem1 and dwItem2 parameters. The uFlags parameter must be one of the following values: SHCNF_DWORD The dwItem1 and dwItem2 parameters are DWORD values.
SHCNF_IDLIST dwItem1 and dwItem2 are the addresses of ITEMIDLIST structures that represent the item(s) affected by the change. Each ITEMIDLIST must be relative to the desktop folder.
SHCNF_PATH dwItem1 and dwItem2 are the addresses of NULL-terminated strings that contain the full path names of the items affected by the change.
SHCNF_PRINTER dwItem1 and dwItem2 are the addresses of NULL-terminated strings that represent the friendly names of the printer(s) affected by the change.

The following flags modify other data-type flags and cannot be used by themselves: SHCNF_FLUSH The function should not return until the notification has been delivered to all affected components.
SHCNF_FLUSHNOWAIT The function should begin delivering notifications to all affected components but should return as soon as the notification process has begun.


dwItem1 ===========================================>
First event-dependent value.


dwItem2 ===========================================>
Second event-dependent value.

1. 위의 내용은 함수에 대한 프로토와 인자에 대한 설명이다.

시스템에 관한 것이 변경되면 탐색기는 스스로 그들 중 일부를 감지할 수 있다. 하지만 프로그램에서 변경한 것들은 다른 곳으로부터 통지를 받아야 한다.

조금 전에 다룬 내용과는 약간 반대되는 개념이기도 하다.
FindXXXChangeNotification() 함수들은 통지를 받아오는 역활이지만 SHChangeNotify()는 시스템에 사용자가 변경한 내용을 알려주는 역활이기 때문이다.

2. SHChangeNotify() 함수의 역활은 무엇인가?

위의 설명에서 처럼 어떤 객체(파일 시스템 혹은 그 이상의 다른 시스템)에 대하여 프로그램이 변경을 가하였을 경우 탐색기가 인지하도록 할 필요가 있다.
이러한 일련의 동작을 제대로 구성하지 않는 다면 사용자를 무시한 나만의 프로그램이 되지는 않을까?

어쨋든 좋다. 내가 시스템에서 파일시스템의 변화를 얻어 오듯 우리도 그들(시스템)에게 이러한 정보를 알려주는 것이 안정된 시스템 구성이라 할 수 있겠다.

예제는 아주 간단하므로 그냥 한 줄의 예제로 넘어간다.

SHChangeNotify(SHCNE_CREATE, SHCNF_IDLIST, pidl, NULL);
이전의 상황을 종합해보자.

실제적인 소스에 대한 주석은 더이상 달지 않는다.
이전의 내용에 다 설명이 되어있고, 소스 자체가 겨우 50줄 정도의 간단한 내용이기 때문이기도 하다.

실제로 동작을 시켜보면 여러가지 이상한 점을 발경할 수 있는데, 새로 폴더를 만든다든가 파일을 삭제한다든가 할경우 생각보다 많은 이벤트가 발생한다는 점이다.

이러한 것은 첨에 폴더를 만들고, 이름을 바꾸고등등의 이벤트를 가정하더라도 너무 많다.

파일을 삭제할 경우는 2번의 이벤트가 발생하는데 Shift+Del로 지울경우는 한번만 발생한다.
이유는 파일을 휴지통으로 옮길때 한번, 원본을 삭제할 때 한번 등등..
이러한 세부적인 내용은 윈98에서는 알길이 없다.
단지 이벤트가 발생한다는 정도만 알수 있다.

이후에 ICopyHook 라는 쉘 익스텐션을 이용하여 좀더 색다를 접근을 해볼것이지만 이것또한 Win98에서는 근본적인 해결책은 되지 못한다.

하지만 우리가 바라는 내용은 Windows NT 이상버전에서는 현실적으로 가능한 이야기다.

FindFirstChangeNotification 함수와 비슷한 함수인
ReadDirectoryChangeW()라는 함수가 있다.
이 함수는 발생한 사건에 대하여 야기시킨 발생자와 그에 관한 구체적인 정보로 버퍼를 채운다는 차이가 있다.

이에 관한 부분은 이후에 다루기로 한다.
. 통지객체

통지객체는 커널객체로, 이를 통하여 여러분의 스레드를 동기화할 수 있다. 개념을 설졍하자면 객체 하나를 생성하고 어던 벼화가 생길 경우에 스레드를 깨울 것인가 나타내는 속성들을 그 객체에 부여한다. 그리고 나서 여러분의 스레드를 멈추게하고, 객체의 통지를 기다리는 것이다. 원한다면 통지 객체를 파일시스템에 생기는 변화를 감지할 때 자동으로 신호 상태(signal)가 되는 아주특별하게 고안된 이벤트로 생각할 수 있다.

2. 통지객체의 내용

FindFirstChangeNotification()
FindNextChangeNotification()
FindCloseChangeNotification()

이렇게 3가지로 나누어지고 1번째는 생성 2번째는 변화가 감지되면 그 이벤트를 받는 역활을 하고 3번째는 생성된 객체를 해지한다.

물론 윈98에서는 이벤트로 받을 수 있는 정보가 한정적이기는 하지만 생각외로 요긴하게 쓰일 경우가 많다.


3. FindFirstChangeNotification() 함수

HANDLE FindFirstChangeNotification(
LPCTSTR lpPathName, // 감시할 경로
BOOL bWatchSubtree, // 서브 경로 감시 여부
DWORD dwNotifyFilter // 감시할 옵션
);

감시할 옵션으로는
FILE_NOTIFY_CHANGE_FILE_NAME 파일 이름 변경
FILE_NOTIFY_CHANGE_DIR_NAME 경로 이름 변경
FILE_NOTIFY_CHANGE_ATTRIBUTES 속성 변경 폴더/파일
FILE_NOTIFY_CHANGE_SIZE 파일 사이즈 변경
FILE_NOTIFY_CHANGE_LAST_WRITE 마지막 수정시간 변경 디렉토리/파일
FILE_NOTIFY_CHANGE_SECURITY 보안설정 변경 디렉토리/파일

위의 함수로 생성된 핸들을 루프안에서 WaitForSingleObject()를 이용하여 대기하다가
시그널이 들어오면..
FindNextChangeNotification() 를 이용하여 정보를 찾아낸다.

4. FindNextChangeNotification() 함수

BOOL FindNextChangeNotification(
HANDLE hChangeHandle // handle to change notification
);

간단한 예제를 들어보자...

while(g_bContinue)
{
WaitForSingleObject(hNotify, INFINITE);
PostMessage(ci.hwnd, WM_EX_CHANGENOTIFICATION, 0, 0);

FindNextChangeNotification(hNotify);
}
위에서 보다시피 루프안에는 루프를 끝낼 만한 이벤트가 없다. while문 안에 있는 부울린값 g_bContinue는 전역 변수로서 위 코드를 실행하는 스레드의 외부 에서 정해진다.
다시 말해 이 코드조작은 두개의 스레드가 있음을 암시하고 있다.

그리고, 마지막으로 감시를 중단할 경우는
BOOL FindCloseChangeNotification(
HANDLE hChangeHandle // handle to change notification
);
를 이용하여 감시를 해제할 수 있다.
이전에 g_bContinue를 FALSE상태로 바꾸고 위의 함수를 호출하는 형태로 해제가 가능하다.

그렇다면 위의 간단한 예제는 아래와 같이 변경되면 조금더 쓸모있는 코드가 될 수 있다.

while(g_bContinue)
{
WaitForSingleObject(hNotify, INFINITE);
if(!g_bContinue)
break;

PostMessage(ci.hwnd, WM_EX_CHANGENOTIFICATION, 0, 0);
FindNextChangeNotification(hNotify);
}
이건 아주 간단한 팁이지만 잘못사용하면..
가끔 망하는(?) 수가 있다..

HWND hwnd = FindWindow("Shell_TrayWnd", NULL);

if(IsWindow(hwnd))
{
if(IsVisible(hwnd))
ShowWindow(hwnd, SW_HIDE);
else
ShowWindow(hwnd, SW_SHOW);
}
A CSIDL is used in conjunction with one of four shell functions, SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and SHGetSpecialFolderPath, to retrieve a special folder's pathname or item ID list (PIDL).

If a special folder does not exist, you can force its creation by using the following special CSIDL:

CSIDL_FLAG_CREATE
Version 5.0. Combine this CSIDL with any of the CSIDLs listed below to force the creation of the associated folder.
The remaining CSIDLs correspond to either file system folders or virtual folders. Where the CSIDL identifies a file system folder, a commonly used path is given as an example. Other paths may be used. Some CSIDLs can be mapped to an equivalent %VariableName% environment variable. CSIDLs are more reliable, however, and should be used if possible.

CSIDL_ADMINTOOLS
Version 5.0. File system directory that is used to store administrative tools for an individual user. The Microsoft Management Console will save customized consoles to this directory, and it will roam with the user.
CSIDL_ALTSTARTUP
File system directory that corresponds to the user's nonlocalized Startup program group.
CSIDL_APPDATA
Version 4.71. File system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data. This CSIDL is supported by the redistributable ShFolder.dll for systems that do not have the Internet Explorer 4.0 integrated shell installed.
CSIDL_BITBUCKET
Virtual folder containing the objects in the user's Recycle Bin.
CSIDL_COMMON_ADMINTOOLS
Version 5.0. File system directory containing containing administrative tools for all users of the computer.
CSIDL_COMMON_ALTSTARTUP
File system directory that corresponds to the nonlocalized Startup program group for all users. Valid only for Windows NT® systems.
CSIDL_COMMON_APPDATA
Version 5.0. Application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data.
CSIDL_COMMON_DESKTOPDIRECTORY
File system directory that contains files and folders that appear on the desktop for all users. A typical path is C:\Documents and Settings\All Users\Desktop. Valid only for Windows NT® systems.
CSIDL_COMMON_DOCUMENTS
File system directory that contains documents that are common to all users. Typical paths are C:\Documents and Settings\All Users\Documents. Valid for Windows NT® systems and Windows 95 and Windows 98 systems with Shfolder.dll installed.
CSIDL_COMMON_FAVORITES
File system directory that serves as a common repository for all users' favorite items. Valid only for Windows NT® systems.
CSIDL_COMMON_PROGRAMS
File system directory that contains the directories for the common program groups that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs. Valid only for Windows NT® systems.
CSIDL_COMMON_STARTMENU
File system directory that contains the programs and folders that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu. Valid only for Windows NT® systems.
CSIDL_COMMON_STARTUP
File system directory that contains the programs that appear in the Startup folder for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. Valid only for Windows NT® systems.
CSIDL_COMMON_TEMPLATES
File system directory that contains the templates that are available to all users. A typical path is C:\Documents and Settings\All Users\Templates. Valid only for Windows NT® systems.
CSIDL_CONTROLS
Virtual folder containing icons for the Control Panel applications.
CSIDL_COOKIES
File system directory that serves as a common repository for Internet cookies. A typical path is C:\Documents and Settings\username\Cookies.
CSIDL_DESKTOP
Windows Desktop—virtual folder that is the root of the namespace.
CSIDL_DESKTOPDIRECTORY
File system directory used to physically store file objects on the desktop (not to be confused with the desktop folder itself). A typical path is C:\Documents and Settings\username\Desktop
CSIDL_DRIVES
My Computer—virtual folder containing everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.
CSIDL_FAVORITES
File system directory that serves as a common repository for the user's favorite items. A typical path is C:\Documents and Settings\username\Favorites.
CSIDL_FONTS
Virtual folder containing fonts. A typical path is C:\WINNT\Fonts.
CSIDL_HISTORY
File system directory that serves as a common repository for Internet history items.
CSIDL_INTERNET
Virtual folder representing the Internet.
CSIDL_INTERNET_CACHE
Version 4.72. File system directory that serves as a common repository for temporary Internet files. A typical path is C:\Documents and Settings\username\Temporary Internet Files.
CSIDL_LOCAL_APPDATA
Version 5.0. File system directory that serves as a data repository for local (non-roaming) applications. A typical path is C:\Documents and Settings\username\Local Settings\Application Data.
CSIDL_MYPICTURES
Version 5.0. My Pictures folder. A typical path is C:\Documents and Settings\username\My Documents\My Pictures.
CSIDL_NETHOOD
A file system folder containing the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Documents and Settings\username\NetHood.
CSIDL_NETWORK
Network Neighborhood—virtual folder representing the root of the network namespace hierarchy.
CSIDL_PERSONAL
File system directory that serves as a common repository for documents. A typical path is C:\Documents and Settings\username\My Documents.
CSIDL_PRINTERS
Virtual folder containing installed printers.
CSIDL_PRINTHOOD
File system directory that contains the link objects that may exist in the Printers virtual folder. A typical path is C:\Documents and Settings\username\PrintHood.
CSIDL_PROFILE
Version 5.0. User's profile folder.
CSIDL_PROGRAM_FILES
Version 5.0. Program Files folder. A typical path is C:\Program Files.
CSIDL_PROGRAM_FILES_COMMON
Version 5.0. A folder for components that are shared across applications. A typical path is C:\Program Files\Common. Valid only for Windows NT® and Windows® 2000 systems.
CSIDL_PROGRAMS
File system directory that contains the user's program groups (which are also file system directories). A typical path is C:\Documents and Settings\username\Start Menu\Programs.
CSIDL_RECENT
File system directory that contains the user's most recently used documents. A typical path is C:\Documents and Settings\username\Recent. To create a shortcut in this folder, use SHAddToRecentDocs. In addition to creating the shortcut, this function updates the shell's list of recent documents and adds the shortcut to the Documents submenu of the Start menu.
CSIDL_SENDTO
File system directory that contains Send To menu items. A typical path is C:\Documents and Settings\username\SendTo.
CSIDL_STARTMENU
File system directory containing Start menu items. A typical path is C:\Documents and Settings\username\Start Menu.
CSIDL_STARTUP
File system directory that corresponds to the user's Startup program group. The system starts these programs whenever any user logs onto Windows NT® or starts Windows® 95. A typical path is C:\Documents and Settings\username\Start Menu\Programs\Startup.
CSIDL_SYSTEM
Version 5.0. System folder. A typical path is C:\WINNT\SYSTEM32.
CSIDL_TEMPLATES
File system directory that serves as a common repository for document templates.
CSIDL_WINDOWS
Version 5.0. Windows directory or SYSROOT. This corresponds to the %windir% or %SYSTEMROOT% environment variables. A typical path is C:\WINNT.
위의 두 함수는 상당히 유사하다.

BOOL SHGetSpecialFolderPath(
HWND hwndOwner,
LPTSTR lpszPath,
int nFolder,
BOOL fCreate
);

HRESULT SHGetSpecialFolderLocation(
HWND hwndOwner,
int nFolder,
LPITEMIDLIST *ppidl
);

두개의 함수가 물리적인(?) 경로를 반환하거나
혹은
경로를 PIDL로 반환 한다.

차이점은 SHGetSpecialFolderPath 함수에서 4번째 인자를
TRUE로 줄경우.. 찾고자 하는 경로가 없으면 그 경로를 생성한다는 점이다.

+ Recent posts