최근 Microsoft 제품군이 새롭게 발표되면서, IIS 6.0과 같이 오래된 웹 서버에는 등록되지 않은 새로운 유형의 MIME Type으로 인해서 호환성에 문제가 발생하는 경우가 자주 있습니다. 특히 IIS 6.0의 경우는 의도된 동작 (By Design)임을 설명하는 기술 문서 (http://support.microsoft.com/kb/326965/ko)로 이에 대한 해명을 하기도 하였습니다.
IIS 6.0 뿐만 아니라, 최근에는 실버라이트 컨텐츠를 개인 웹 호스팅 계정에 올려서 테스트하시는 분들도 많이 계신데요, 단순히 실버라이트 컨텐츠를 재생하기 위함이라면 필요가 없겠지만, 실버라이트 컨텐츠와 상호작용하는 기능을 구현할 때에는 반드시 MIME 설정이 웹 서버에 올바르게 구현되어있어야 합니다.
아래는 Microsoft가 근래에 들어서 발표한 최신 기술에서 사용하는 파일 형식들의 MIME Type 목록들을 정리한 것입니다. 아래의 목록을 참조하여 IIS 6.0이나 Apache 등의 웹 서버에서 설정을 변경할 수 있습니다.
아래는 Apache 기반의 웹 호스팅에서 서버의 설정을 변경하지 않고 손쉽게 MIME 형식을 추가할 수 있는 .htaccess 파일입니다. 다른 .htaccess 파일이 있을 경우 적당한 위치에 파일을 병합하시고, 다른 응용프로그램을 사용하지 않고 있는 경우 이 파일을 그대로 업로드하면 곧바로 반영됩니다.
IIS 7.x (Windows Vista 및 Server 2008 이상)에서는 위의 형식들 중 상당수가 이미 기본으로 등록되어있으므로 IIS 7.x 이상의 웹 응용프로그램 서버를 사용하고 있을 경우에는 문제가 되지 않습니다. 자체적인 웹 서버를 구현하고 있을 경우 (예를 들어 WCF나 .NET Framework based HTTP Listener 같은 경우) MIME Type에 대해서 올바른 처리가 추가 구현되어있어야 합니다.
최근 고객사의 요청으로 ActiveX 컨트롤 하나를 유지보수하고 있습니다. ActiveX 컨트롤에서 탈피하려는 추세가 있지만, 별 다른 대안이 없어서 ActiveX 컨트롤을 유지보수해야 하는 경우도 아직 우리나라에서는 상당히 많은것 같습니다.
Internet Explorer 7.0부터는 보호 모드라는 개념이 새로 소개되었습니다. 보호 모드란, 일종의 Sand-box 개념으로 기존과 같이 현재 로그온한 사용자의 권한을 그대로 물려받아 무분별하게 실행되는 것을 방어하는 안전 장치입니다. Windows XP와는 달리 Windows Vista부터는 일반 사용자를 단순히 관리자로 분류하지 않고, UAC를 통하여 작업에 대해 허가/거절 여부를 정할 수 있게 하였습니다.
우리가 권한 상승이라고 이야기하는 기능은 사실 권한 상승을 사용자에게 요청하는 것입니다. 이러한 권한 상승 요청을 구현하기 위하여 이제까지 참고할 수 있는 보편적인 리소스는 EXE 파일과 함께 매니페스트 파일을 배포하는 것이 대표적인 것이었습니다. 그리고 ActiveX 컨트롤의 경우 Elevation Moniker를 통하여 권한 할당을 받는 것이 대표적입니다.
놀랍게도, 그리고 안타깝게도, Visual C++ 6.0 개발 도구를 업그레이드하지 못하는 이슈는 도처에 널려있습니다. 기존에 개발되어있던 소프트웨어나 라이브러리가 특정 문자 세트에 완벽하게 맞추어져있지만, 업그레이드할 수 없을만한 이슈 (개발 업체의 부도 - 또는 - 계약 해지 / 담당자의 연락 두절과 같은)로 인하여, 올해부터는 더 이상 일체의 기술 지원을 받을 수 없는 (서비스 팩 다운로드도 MS 공식 홈페이지에서는 더이상 받으실 수 없습니다.) 그런 개발 플랫폼위에서 고군분투해야 하는 상황은 생각보다 자주 있습니다.
사실 권한 상승을 제대로 프로그래밍하려면 Windows Vista나 Windows 7 SDK가 필요합니다. 하지만 이들 SDK의 코드를 가져다 사용하려면 개발 도구를 Visual C++ 2005나 2008로 업그레이드할 필요가 있습니다. 하지만 개발 도구나 Windows SDK를 설치하지 않고 간단히 적용할 수 있다고 소개된 방법은 다행히 Visual C++ 6.0에서 온전하게 동작합니다.
위의 코드를 자주 사용하는 헤더에 선언해두면 권한 상승을 위하여 호출하는 CoGetObject에 정확히 바인딩할 수 있습니다. 그리고, 아래의 두 함수를 이용하여, 권한 상승을 지원하는 운영 체제 (Windows Vista 이상의 운영 체제)를 식별하고 실제로 객체를 생성할 수 있습니다.
if (GetVersionEx(&sInfo)) { if( sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT && sInfo.dwMajorVersion >= 6 && sInfo.dwMinorVersion >= 0) { // Windows VISTA or Higher bIsUACRequired = TRUE; } }
return bIsUACRequired; }
Visual C++ 6.0 기반의 프로젝트들은 거의 대부분 ANSI나 Multibyte Character Set 기반의 문자 세트를 기준으로 프로그램이 구성되어있습니다. 확장성을 위하여 Transition이 가능한 데이터 타입 (LPTSTR, LPCTSTR, TCHAR 등)은 거의 고려하지 않았을 확률이 높습니다. 하지만 우리가 호출해야 할 API들은 유니코드 문자열을 필요로 하기 때문에 직접 유니코드를 사용하도록 기존 코드를 수정하였습니다. 그리고 더불어서, StringCchPrintf 함수를 대신하여 sprintf 계열의 함수를 직접 이용하였습니다.
2. 실제 ActiveX 컨트롤에 권한 상승을 적용하는 또 다른 방법
권용휘 MVP님의 아티클에서 설명하는 방법은, 특정 메서드나 프로퍼티의 호출 과정에서 필요로하는 권한 상승을, 권한 상승을 외부에서 요구하고 결과를 받기 위한 프록시 멤버와, 실제 처리하는 멤버로 이원화하여 구현하는 방식입니다. 대부분의 경우 이 방법으로 해결할 수 있다고 생각합니다. 하지만 간혹, ActiveX 컨트롤의 동작이나 상태, 속성을 정의하는 작업 전체가 시스템에 종속적으로 구성된 경우도 있을 수 있습니다. 이 경우에는, 격리모드에서 실행되는 ActiveX 컨트롤과는 별도로 새로운 인스턴스를 노출시켜야 할 필요가 있습니다.
이에 대한 솔루션은 인터넷 검색중에 발견한 어떤 블로그의 아티클에서 찾을 수 있었습니다. (http://hbesthee.tistory.com/620) 이 아티클은 델파이 기반의 솔루션을 제시하고 있었으며 저는 이것을 Visual C++ 기반의 코드로 옮겼습니다.
if (::IsUACRequiredOperatingSystem()) ret->boolVal = VARIANT_TRUE; else ret->boolVal = VARIANT_FALSE;
return S_OK; }
위의 코드에서는 trusNeedElevate를 이용하여 권한 상승이 지원되는 운영 체제인지 파악하는 부분과, trusElevate를 이용하여 권한 상승이 적용될 개체를 반환하는 방법 두 가지를 보여주고 있습니다. 그리고 아래의 코드는 자바스크립트에서의 실제 사용 예시입니다.
var obj = new ActiveXObject("EBANK.trusEBANK");
if (obj.trusNeedElevate()) { var result = obj.trusElevate(); if (result) { obj = result; } }
// 여기서부터 obj 객체 사용
이와 같은 방법을 통하여, 권한 상승이 온전하게 ActiveX 컨트롤에 적용될 수 있도록 하여, 원활한 동작 환경을 구현할 수 있을 것입니다.
3. Internet Explorer Host Window를 Elevation하는 방법 [업데이트]
그리고 최근에 저는 여러가지 방법을 적용해보던 중에 가장 현실적인 타협안 하나를 발견하였습니다. 바로, Internet Explorer Host Window 자체를 Runtime 도중에 Elevation 처리하는 방법으로, 기존의 응용프로그램 기반 매니페스트와 유사하게 작동합니다. 그리고 이 방법은, Host Window를 Elevation하는 데에 사용할 수 있는것 뿐만 아니라, 대리 실행해야 하는 응용프로그램의 Manifest 보유 여부에 관계없이 Elevation에도 사용될 수 있습니다.
위의 구조체는 Elevation 상태를 점검하기 위하여 필요한 구조체로 이미 Elevation 처리가 되어있는 호스트 위에서 실행되는 경우 Elevation을 다시 실행하지 않도록 하기 위하여 필요합니다. 이 구조체는 Visual C++ 6.0 기반에서 프로그램을 업데이트할 때 수동으로 지정해야 합니다.
이미 여러 블로그 아티클로도 잘 다뤄진 내용이지만 몇 가지 부수적인 내용을 덧붙여서 ActiveX 패키징 및 배포에 관한 내용을 총 정리해보았습니다. 실무에서는 아직도 ActiveX 컨트롤에 관한 유지보수를 틈틈이 수행할 필요가 있다보니 이런 문서를 작성하게 되는 것 같습니다. :-)
1. INF 파일에 대한 이해
INF 파일은 ActiveX 패키지 배포 시 내장되는 설치 정보 파일로 보통 배포되는 CAB 파일의 이름과 동일하게 맞추어서 배포합니다. 예를 들어 MyControl.cab을 배포한다면 MyControl.inf 파일을 내장하고 있어야 하는 것입니다.
그리고 INF 파일의 문법적인 구조에 대한 상세한 설명이 없어서 상당히 답답한 때가 많습니다만 간략하게 두 가지 사례를 짚어서 설명해보도록 하겠습니다.
a. Hooking 없이 설치하는 경우
Hooking이란 설치 도중에 별도의 외부 프로세스를 이용하여 설치 자체를 자동화하거나 설치 전/후 과정을 제어하기 위한 일종의 옵션 기능입니다. ActiveX에 수많은 보안 결함이 존재하지만 디자인적으로 보았을 때에도 충분히 문제가 드러납니다. 대부분 간단한 유형의 ActiveX 컨트롤은 Hooking 기능 없이 배포가 되는 편입니다. 다음의 샘플 INF 코드를 살펴보기로 합니다.
흔히 볼 수 있는 형태의 INF 파일입니다. 제일 상단에 있는 것이 INF 파일의 형식에 관한 기본 정보이고 Windows 95 이후로부터는 대체로 Advanced INF 2.0 규격을 따르는 것 같네요. (시그니처에 Windows 95의 코드 네임인 Chicago가 적혀있는 것으로 보았을 때도 그러합니다.)
하단의 [Add.Code] 섹션에서는 이 CAB 파일을 통해서 배포될 파일들을 기술합니다. 편의 상 파일 이름과 엔트리 이름을 일치시켜두는 것도 좋습니다. 그리고 각각의 파일명으로 기술된 섹션이 해당 파일을 어떤 식으로 복사되고 관리되어야 하는지를 서술하는 부분으로 이후에 설치 제거를 할 때 근거 정보가 됩니다.
각 섹션 별로 file-win32-x86 이라는 엔트리 명이 보이는데 파일의 플랫폼과 대상 아키텍처를 지정하는 부분입니다. 옛날 (NT 시절)에는 Alpha나 MIPS 계열 프로세서를 위하여, 요즈음에는 x64 (AMD64) 프로세서를 위하여 이 부분이 달리 할당될 수도 있을 것입니다. 그리고 thiscab 이라는 값은 이 CAB 파일 내에 파일이 있음을 뜻하는 부분입니다.
DestDir 엔트리는 이 파일이 어느 위치로 복사되어야 하는지를 나타내는 부분으로 많은 옵션이 있을것 처럼 보이지만 실제로 알려진 것은 세 종류인듯 합니다. 값을 10으로 지정하면 %windir% 경로 (흔히 C:\Windows)에, 11로 지정하면 %windir%\system32 (Windows 9x 계열 운영체제에서는 %windir%\system)에, 비워두면 OCCACHE 디렉터리 (%windir%\Downloaded Program Files)에 복사됩니다.
그리고 이제 OCX 파일 섹션의 내용을 살펴보기로 합니다. OCX 파일의 내용에서 꼭 확인해야 할 것은 RegisterServer=yes 항목과 Version 항목, 그리고 clsid 항목입니다. Version은 OCX 파일을 빌드할 때 추가되는 Win32 리소스의 버전 테이블 정보와 일치할 필요가 있으며, clsid 항목은 실제로 브라우저에서 인스턴스화되어 실행되어야 하는 COCLASS의 CLSID와 일치해야 합니다.
ActiveX를 이용하여 대리 설치 프로그램을 기동시키기 위하여 위와 같이 작성할 수도 있지만, 컴포넌트별로 Hook을 다르게 지정할 수도 있으니 참고하시기 바랍니다. Hook을 실행하기 위하여 %EXTRACT_DIR% 라는 지역 환경 변수를 지정한 것을 볼 수 있고 프로그램 매개 변수까지 지정이 가능한 것을 보실 수 있습니다.
Hook에서 지정한 프로그램의 경우 주의 사항이 한 가지 있다면, 프로그램의 실행 종료 코드가 0으로 끝날 필요가 있다는 것입니다. 그렇지 않으면 설치가 중간에 실패한 것으로 인지되어 브라우저에는 아무것도 표시되지 않는다고 합니다. 이를 미리 확인해보려면 패키징 하기 전에 Hook을 통해서 구동하려는 프로그램을 똑같이 명령 프롬프트에서 아래와 같이 실행하면 알 수 있습니다.
START /WAIT "실행할 프로그램 및 매개 변수들"
ECHO %ERRORLEVEL%
%ERRORLEVEL% 환경 변수의 값이 0이 아닌 것으로 나타나면 Hook 프로그램으로는 사용할 수 없을 것입니다.
2. PVK 파일과 SPC 인증서 파일을 PFX 파일로 변환하기
SIGNCODE 도구에서 SIGNTOOL 도구로 새롭게 바뀐 이후부터, ActiveX CAB 파일에 서명을 하거나 EXE 파일 위에 서명을 하는 방법이 조금 바뀌었습니다. 바로 PFX 파일을 생성하는 작업이 추가 된 것인데, 기존에 가지고 있는 인증서 파일 형식이 PVK 파일과 SPC 파일 두 가지로 구성된 경우 아래와 같이 변환해야 합니다.
PVK2PFX -PVK "PVK 파일의 경로" -SPC "SPC 파일의 경로" -PFX "PFX 파일을 만들 경로" -PI "기존 인증서의 Password" -F
PVK2PFX 유틸리티는 .NET Framework SDK v2.0 혹은 Windows SDK v6.0 이상을 설치하면 같이 따라오는 유틸리티입니다. 여기서 -PVK 스위치 다음에 PVK 파일의 경로를, -SPC 스위치 다음에 SPC 파일의 경로를 서술해주어야 하고, 그 다음 -PFX 스위치 다음에 새로 만들 PFX 파일의 경로를 서술해야 합니다. 추가적으로 인증서로부터 암호를 해독하고 PFX 파일에 암호를 새로 설정하기 위하여 -PI 스위치 뒤에 인증서 암호를 기술합니다. 기본 동작이 기존 파일이 있을 경우 실패로 처리되는데 편의상 -F 스위치를 지정하여 PFX 파일을 덮어쓰도록 실행합니다.
3. CAB 파일에 서명을 할 때에는 반드시 Spanning Space를 확보할 것
CAB 파일에 서명을 추가하기 위해서는 별도의 Spanning Space를 확보해야 하는데 이를 위해서는 CABARC 유틸리티로 압축해야 합니다. (다른 압축 유틸리티에서는 지원하지 않을 수도 있습니다.)
CABARC -S 6144 N "생성할 CAB 파일의 경로" "파일1" "파일2" ... "파일n"
-S 스위치가 Spanning Space 확보를 지시하는 스위치로 이 뒤에 Magic Constant 값 6144를 지정합니다. 이것이 인증서 크기에 관한 Magic Constant로 문서화된 수치이므로 그대로 사용하면 됩니다. 새로운 파일을 만들어야 하므로 N 스위치를 지정하여 모드를 변경하고, 그 다음에는 CAB 파일이 생성될 경로, 그리고 그 다음부터는 CAB 파일에 포함할 파일들을 하나씩 서술하면 됩니다. 와일드 카드도 지원하므로 편리합니다.
4. 실제로 서명하고 확인하기
SIGNCODE 프로그램보다 기능이 다양하고 정교해진 SIGNTOOL을 이용해서 서명을 하려면 다음의 스위치 설정을 활용합니다.
SIGNTOOL SIGN /F "PFX 파일 경로" /P "PFX 파일 암호" /T "타임스탬프 URL" "대상 파일 1" "대상 파일 2" ... "대상 파일 n"
SIGNTOOL 프로그램을 서명 모드로 실행하기 위하여 SIGN 스위치를 지정하고, /F 스위치에는 2단계에서 만든 PFX 파일, 그리고 /P 스위치에는 2단계에서 지정한 인증서 암호를 입력합니다. /T 스위치 뒤에는 실제로 접속 가능한 타임스탬프 URL을 지정해야 하는데 이는 인증서 발행 업체가 제공하는 고유 URL을 이용하면 됩니다. 마지막으로 대상 파일들을 지정하면 한꺼번에 동일한 인증서로 서명할 수 있습니다.
CAB 파일을 제외한 보통의 EXE, DLL, OCX 등에 직접 서명하는 것은 별도로 빌드할 때 설정해주어야 할 특별 옵션같은것들은 존재하지 않습니다.
Out of Process 자동화 서버와 같이 스스로 메모리 관리에 책임이 있는 형태의 COM 서버들은 메모리 충돌 오류를 일으킬 가능성이 상대적으로 적다고 볼 수 있습니다. 하지만, In Process 자동화 서버의 경우, 특히 ActiveX들은 기능이 복잡할 수록 이러한 문제를 일으킬 가능성이 큽니다. 이번에 작업한 프로그램 중 하나인 HwpCtrl을 호스팅하는 닷넷 기반 응용프로그램에서도 예외는 아니었는데, 두 가지 문제점이 있었습니다.
첫 번째: 트레이 아이콘이 정리되지 않고 잔상이 남는 문제
아래아한글 소프트웨어 연구실 (http://swlab.haansoft.com) 에도 같은 문제에 관한 FAQ가 있었습니다만 "해결할 수 없다" 는 것이 답이었습니다. 그러나, 이 답에 만족하지 못해서 인터넷 이곳저곳을 찾아다니다가 문제에 매우 훌륭하게 접근하는 소스 코드 하나를 발견하였습니다.
위의 아티클에서 제공한 Visual C++ 소스 코드를 C#으로 이식한 후, 정리되지 않은 아이콘이 대부분 제거가 잘 된다는 것을 확인하였습니다. 하지만 제가 해결하고자 하는 문제였던 HwpCtrl ActiveX 컨트롤의 아이콘 제거는 여전히 이루어지지 않았습니다. 단순히 프로세스 ID 값을 얻어오지 못한 경우에는 속하지 않았기 때문에 이 코드가 기대하는대로 동작해주지는 않았습니다. 따라서, 프로세스를 열도록 시도하여 존재하지 않는 프로세스임을 재 확인하는 코드를 추가해야 했습니다.
위의 소스 코드 파일은 C#을 기준으로 프로그래밍된 것이지만 기본적인 컨셉은 다른 프로그래밍 언어에서도 참고할 수 있을 것입니다. 위의 코드를 컴파일 시에는 /unsafe 스위치를 지정하여 Unsafe Code를 컴파일할 수 있도록 허용해야 합니다.
위의 코드를 호출하기 위해서는, 프로세스가 한 번 이상 종료된 상태여야 했기 때문에 진입점 메서드를 이중으로 프로그래밍했습니다. 특정한 명령줄 스위치가 전달된 경우와 그렇지 않은 경우를 구분 지어 정상 모드에서 종료한 경우 프로세스를 연이어 다시 시작하게 만들고 그 자신은 종료하게 두면, 나중에 Cleanup 모드로 시작된 프로세스에 의해 실제 트레이 아이콘 정리 작업이 발생하게 됩니다.
두 번째: 프로그램 종료 직후 발생하는 알 수 없는 메모리 위반 오류
HwpCtrl을 호스팅하는 프로세스를 종료한 직후에 발생하는 알 수 없는 메모리 위반 오류 때문에 고민이 많았습니다. 이 현상은, VSHOST.EXE에서 실행되는 Visual Studio Hosting Process 모드에서는 문제가 되지 않지만, 단독으로 응용프로그램을 실행할 때 발생하는 문제였습니다.
이 문제의 해결을 위하여 Internet Explorer Control 위에서 호스팅하도록 접근 방법을 변경해 보았습니다. 참조 대상 어셈블리의 수를 줄이고 프로그램의 크기를 줄이는 효과는 있었지만 문제는 여전히 그대로였습니다. 적당한 해결 방법이 없는 상태에서 생각해낸 최종 방법은 강제 프로세스 종료였는데 문제는 시점이었습니다.
System.Windows.Forms.Application.Run 메서드가 폼 이외에 컨텍스트 개체를 통해서 GUI 메시지 루프를 시작할 수 있다는 것을 알았고, 이 컨텍스트 개체가 제공하는 메시지 루프 이탈 시점에 발생하는 이벤트를 이용하여 프로그램을 종료하도록 하였습니다. 그리고 Main 메서드 전체에 SEH 구성을 두어 catch, finally 절 이후에 강제 종료가 일어나도록 하였습니다.
결론
위의 두 가지 방법 모두 정상적인 방법이 아니지만, 문제의 해결을 위하여 적용할 수 있었던 최선의 방법이었다고 생각합니다. 또한, 위의 방법을 적용한 경우 적용된 프로그램이 Windows Vista에서 관리자 권한을 필요로 할 수도 있습니다.
4. patch.js에는 docWrite 함수 하나만 들어있으며 단지 document.write를 대신 써주는 일 뿐이다. 하지만 이 HTML 페이지에서 직접 document.write를 호출하는 것과는 차이가 있다.
5. 이제 ActiveX 컨트롤이 삽입된 곳으로 가서 <OBJECT> ~ </OBJECT> 섹션의 내용을 모두 복사한다.
6. docWrite 함수를 호출하되 문자열 인수를 넘겨주면된다. 그러나 다음의 사항을 지킬 필요가 있다.
6-1. 편의상 문자열 인수의 시작과 끝을 작은 따옴표로 할 것을 권장한다. Well-Formed XHTML Document의 경우 모든 Property를 쌍 따옴표로 열고 닫는 관습이 있는데 여기에 일일이 Escape Sequence 처리를 하는것은 비효율적이기 때문이다.
6-2. 가독성을 위하여 String Concatenation을 사용할 것을 권장한다. 물론 한 줄로 이어서 쓰더라도 별 문제는 없겠으나 한 번만 쓰고 말 것은 아니지 않겠는가. 잘 모르는 사람들을 위해서 설명하자면 Enter키로 입력한 줄 띄우기 부분이 JavaScript 문자열에서는 자동으로 이어지는 것이 아니기 때문에 곧 이어 나올 예제와 같이 표기하는 방식을 말하는 것이다.
Visual Basic Extension, Object Linking Embedded, Component Object Model, Binary Behavior, Distributed Component Object Model, Component Object Model Plus, Windows DNA 등 Microsoft가 C++과 객체 지향 기술을 이용하여 개발해왔던 다양한 프레임워크들 중 하나인 ActiveX가 이제는 그 수명을 다하려는듯한 결정적인 루머를 내고 있다.
당장 내년 1월에 새롭게 출시될 Windows Vista에 포함된 IE7에서는 ActiveX 컨트롤 자체가 완벽하게 Sand-Box 처리가 될 것이라고 한다. ActiveX 인스턴스는 어차피 Internet Explorer와 함께 그 수명을 같이하는 것이므로 이상할 것이 없지만 Sand-Box 라는 것은 다소 생소하실 분들이 많겠다.
요약하자면, ActiveX 컨트롤을 PC에 다운로드하여 Install하는 작업을 하지 않고 마치 Java Applet이나 Flash Content 또는 Script 처럼 동작하게 만들겠다는 의미가 된다. 보안 상으로는 틀림없이 이득이 될테지만 ActiveX를 개발하여 배포해왔던 업체들에게는 정말 큰 일인셈이다.
퍼블릭 릴리즈로 나온 IE7을 먼저 써본 사람들은 새로운 모드인 "안전 모드"에 대하여 궁금해 했을 것이라 생각한다. 이 "안전 모드"가 바로 이 루머와도 관련이 있겠다. 단순히 설치된 ActiveX 컨트롤 전체를 사용하지 않는 것으로 시작해서 유입되는 모든 ActiveX 컨트롤이 하드 디스크에 저장되거나 설치되는 것을 통제하고, 퍼미션 조절을 통하여 작업에 제약을 걸어놓는 모드이다. 정식으로 나올 Windows Vista의 IE7에서는 아마도 이 "안전 모드"를 기본 모드로 사용하도록 권하기 때문에 이런 루머가 나온 것이 아닐까 싶다.
더 재미있는 사실은, Windows Vista가 이제는 .NET Framework 3.0을 기본으로 내장하고 있다는 사실이다. 이것이 의미하는 바는 ActiveX의 운명을 더욱 확실하게 만들어주고 있다. .NET Framework 2.0부터 강화된 ClickOnce는 Windows Forms로 개발된 .NET Application을 Internet Explorer와 연동할 수 있도록 도울 것이며, Windows Presentation Framework의 XAML은 Internet Explorer 7.0이 직접 렌더링하는 것도 가능하다. 또한 Windows Presentation Framework Everywhere는 경량화된 응용프로그램을 지원할 것이다. 지금 언급한 이 세 가지 기술을 적극 유치하고 유도하는 것이 MS의 실제 목표다. ActiveX는 보안 상의 문제가 많다는 점을 이용하여 오히려 뒤로 빼려는 셈이다.
또한 이제는 ActiveX보다는 Flash, Java를 이용한 개발을 더욱 선호하는 추세이다. 컨텐츠 프로바이더의 입장에서도 ActiveX는 메리트가 없는 셈이다. 그리고 기억하는 사람들도 아직 있으리라 생각되는 이올라스社의 소송 승리도 ActiveX의 숨통을 조르고 있다.
.htaccess
patch.zip
