: 알려주신 방법대로 해보니까 잘되는데요. 저도 궁금한게 있습니다.
:
: Progman -> SHELLDLL_DefView -> SysListView32
: WorkerW -> SHELLDLL_DefView -> SysListView32
:
: 제가 궁금한 것은 SysListView32 를 패런트로 해주면 왜 윈도우가 바탕화면 윈도우 계층으로
: 동작할 수 있는가 하는 부분입니다. ListView 윈도우를 패런트로 해주는 것으로 어떻게 바탕화면
: 윈도우 계층하고 같은 레벨에서 동작하게되는지 이해가 되질 않습니다????




두분께 부연해서 말씀 드리면....

바탕화면에 바로가기 아이콘을 생성하고, 익스텐션 모듈들과 연계를 취하는 등...
윈도우즈 환경에서 탐색기(explore.exe)는 파일처리, 프로세스 실행 등 다양한 작업을
수행하는 쉘(Shell) 역할을 하게 되는데... 내부적으로는 COM(Component Object Model)
으로 구현되어 있는 코드의 총체적인 집합체라고 볼수 있습니다.

외연적으로 볼때... 우리는 탐색기(explore.exe)를 실행할 때 나타나는 창을 볼뿐 이지만
(탐색기 프로세스에 의해서 생성되는 유저 인터페이스 스레드).. ... 
데스크탑 화면에 탐색기(explore.exe) 가 하나도 열려있지 않은 상태에서도 explore.exe 는
메모리에 남아있으면서 Active 프로세스 상태로 활동하게 됩니다.

위에서 Progman, WorkerW 같은 클래스 윈도우도 실상은 explore.exe 프로세스에 의해서
생성된 클래스 윈도우에 불과하고요. 탐색기(explore.exe) 프로세스가 내부적으로는
데스크탑 윈도우에도 관련이 되어있다는 거죠.

지금은 탐색기(explorer.exe)가 윈도우즈에서 쉘 역할을 하지만, 윈도우즈가 처음 나왔을 때 초창기
때는 쉘을 "Program Manager" 라고 불렀습니다. Windows 7 이 나오기 까지도 MS 사의 프로그래머
들은 예전의 쉘 명칭을 바꾸지 않고 내부적으로는 소스코드에서 아직 까지도 예전 명칭을 사용하고
있나 봅니다.

Aero 기능이 사용되면서 화려한 그래픽 효과를 갖는 데스크탑 윈도우를 처리하기 위해서 MS 사의
프로그래머들이 선택한 방식은 기존의 Progman 클래스 윈도우는 이전 방식과의 호환을 유지하기 위해
그대로 두고, 새로 WorkerW 라는 클래스 윈도우를 도입했다는 거고요.

WorkerW -> SHELLDLL_DefView -> SysListView32

위와 같이 계층 구조로 데스탑 관련 윈도우 클래스를 나누어 놓은 것은 바탕화면에 바로가기 생성 등의
쉘 메세지도 처리 해야겠고, 마우스 키보드 등의 이벤트도 처리해야 겠고... 계층 구조로 프로그래밍 모델을
설계하는 게 구현하기에도 편리해서 였겠죠.

그리고...

SysListView32 클래스 윈도는 리스트 뷰로 구현된 윈도우  입니다. 바탕화면에 놓여있는 아이콘들을
크게/작게 보거나, 정렬 하는 등 리스트 뷰 콘트롤의 기능을 활용하기 위해서 사용 했다고 볼수 있겠죠.
바탕화면에 깔려있는 배경이미지를 지우지 않는 속성으로 구현되어 있기 때문에, SysListView32 를 패런트
로 지정하면 결과적으로 윈도우가 데스트탑 레이어에서 동작하게 되는 효과를 얻게 되는 것도 이 때문이고요.

덧붙여서 Desktop Window Manager(dwm.exe)는 그래픽 카드 프로세서인 GPU 리소스를 관리 하는데
Direct X 를 이용하는 프로그램에 의해서 Direct X 코어가 Initilalize 될 때 dwm.exe 에서 제공하는 펑션을
호출하기도 하더군요.