DLL Surrogates는 정말이지... 본래(?) 목적했던 용도 이외에 다양하게 쓰이고 있는, 그것도 우회적인 수법으로 더없이 좋은 수단을 제공하고 있습니다.

처음에, DLL Surrogates 기법이 필요했던 것은 불안정한 DLL을 별도의 프로세스(Surrogate EXE Process)에 얹어서 실행시킴으로써 메인 응용 프로그램으로부터 프로세스 공간을 분리시켜 안정성을 보장받기 위해서였습니다. (물론, 이외에도 컴퓨터간 DCOM을 이용해서 DLL을 활성화 시키는 것을 가능하게 합니다.)

지난 IE 강의에서 잠시 설명을 드렸었는데.

마이크로소프트 IE 8 행사의 ActiveX 세션 PPT 
; https://www.sysnet.pe.kr/2/0/673

비스타 운영체제에서도 뜻하지 않은 용도로 DLL Surrogates 기법이 사용됩니다. 어디일까요? (이런 거 찾는 것도 SDIQ 테스트(Surrogate DLL Intelligence Quotient)같은 걸로 만들어서 하면 좋을까요? ^^)

바로 그 유명한 관리 코드를 실행시키기 위한 DLL 사용에 Surrogates 기법이 적용되었습니다. MIC 등급은 프로세스 단위로만 적용이 되기 때문에 "Low Level"로 시작되어 있는 인터넷 익스플로러에서는 관리자의 권한에 해당하는 코드를 실행할 수가 없습니다. IE에서는 그런 권한이 필요한 코드만을 담은 분리된 COM DLL을 "High Level"로 시작한 dllhost.exe(Surrogate Process)에 얹어서 실행시킴으로써 MIC로 인한 제약을 우회하게 된 것입니다. 아마도 DLL Surrogate를 처음 만든 사람도 이것이 MIC 우회 수단으로 적용되리라고는 꿈에도 예상치 못했을 것입니다.

그런데, 오늘 뜻하지 않게 또 다른 사용법을 알게 되었습니다. ^^

How to invoke 64bit native COM from 32bit .Net application 
; https://learn.microsoft.com/en-us/archive/blogs/asiatech/how-to-invoke-64bit-native-com-from-32bit-net-application 

대단하지요. 이젠 32비트와 64비트의 상호운용에 관한 해법으로 "DLL Surrogates" 기법을 사용하고 있는 것입니다.

물론, 이 방법으로 모든 COM 개체의 32비트/64비트 상호운용을 해결할 수는 없습니다. 예를 들어, UI로 활성화되는 ActiveX 컨트롤이나, COM 개체를 포인터를 직접 전달하는 식으로 같은 프로세스 공간이라는 가정으로 마샬링 고려없이 했다면 적용이 불가능합니다.

32비트와 64비트는 꽤나 긴 과도기를 거치고 있는 만큼, 이런 활용법은 어느 순간에 적절한 해법으로 써 먹을 수도 있겠지요.

---

[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[최초 등록일: 6/29/2009]
[최종 수정일: 4/26/2023]