KR20070050091A - 소프트웨어 애플리케이션의 실행을 분리하는 방법 및 장치 - Google Patents

Abstract

운영 시스템에의해 제공되는 본래 리소스에 대한 애플리케이션 프로그램의 액세스를 분리하기 위한 방법은 유저를 대신하여 실행중인 애플리케이션 프로그램에 의해 만들어지는 본래 리소스로의 요청을 분리 환경으로 재지정한다. 분리 환경은 유저 분리 범위 및 애플리케이션 분리 범위를 포함한다. 요청된 본래 리소스의 인스턴스는 유저에 대응하는 유저 분리 범위에 배치된다. 본래 리소스에 대한 요청은 유저 분리 범위에 배치된 리소스의 버전을 이용하여 이뤄진다. 요청된 본래 리소스의 인스턴스가 유저 분리 범위에 없으면, 요청은 애플리케이션 분리 범위로 재지정된다. 본래 리소스에 대한 요청은 애플리케이션 분리 범위에 배치된 리소스의 버전을 이용하여 이뤄진다. 요청된 본래 리소스의 인스턴스가 애플리케이션 분리 범위에 없으면, 요청은 시스템 범위로 재지정된다.

운영 시스템, 본래 리소스, 유저 분리 범위, 애플리케이션 분리 범위

Description

소프트웨어 애플리케이션의 실행을 분리하는 방법 및 장치{METHOD AND APPARATUS FOR ISOLATING EXECUTION OF SOFTWARE APPLICATION}

본 발명은 컴퓨터에 의한 소프트웨어 애플리케이션의 실행을 관리하는 것에 관한 것이고, 특히, 서로 다른 애플리케이션 프로그램들간에 그리고 동일한 컴퓨터 시스템에 의해 실행되는 동일한 애플리케이션의 개개의 유저들간의 호환성 및 공존성 문제(compatibility and sociablity problems)를 감소시키기 위한 방법 및 장치에 관한 것이다.

실행 및 설치 중에 컴퓨터 소프트웨어 애플리케이션 프로그램은 컴퓨터의 운영 시스템이 제공하는 다양한 본래 리소스(native resources)를 사용한다. 통상의 단일 유저 컴퓨터가 도 1a에 도시되어 있다. 도 1a에 도시하는 바와 같이, 운영 시스템(100)이 제공하는 본래 리소스는 파일 시스템(102), 레지스트리 데이터베이스(104) 및 오브젝트(106)를 포함할 수 있다. 파일 시스템(102)은 애플리케이션 프로그램이 데이터 파일(150, 152)에 오픈, 생성, 읽기, 카피, 변경 및 삭제하는 메카니즘을 제공한다. 데이터 파일(150, 152)은 디렉토리(160, 162)의 로컬 계층으로 함께 그룹화될 수 있다. 레지스트리 데이터베이스(104)는 컴퓨터에 물리적으로 부착되는 하드웨어에 관한 정보, 어느 시스템 옵션이 선택되었는 지, 컴 퓨터 메모리가 설치되는 방법, 각종 애플리케이션 전용 데이터 아이템 및 운영 시스템(100)이 시작될 때 무슨 애플리케이션 프로그램이 표시되어야 하는 지를 저장한다. 도 1a에 도시하는 바와 같이, 레지스트리 데이터베이스(104)는 레지스트리 값을 위한 컨테이너인 "키"(170, 172)의 로컬 계층으로 일반적으로 조직화된다. 운영 시스템(100)은 또한 세마포어(semaphores), 섹션, 뮤텍스(mutexes), 타이머, 뮤턴트(mutants) 및 파이프를 포함하는 다수의 통신 및 동기화 오브젝트(106)를 포함할 수도 있다. 이와 함께, 파일 시스템(102), 레지스트리 데이터베이스(104), 오브젝트(106) 및 운영 시스템(100)에 의해 이용 가능하게 되는 임의의 다른 본래 리소스들을 본 문서 전체에 걸쳐서 "시스템 계층"(108)이라 한다. 시스템 계층(108)에 의해 제공되는 리소스들은 임의의 애플리케이션 또는 시스템 프로그램(112, 114)에게 이용 가능하다.

그러나, 2개의 호환 불가능한 애플리케이션 프로그램(112, 114)을 실행 또는 설치하려면 문제가 발생한다. 도 1a에 도시하는 바와 같이, 2개의 애플리케이션 프로그램(APP1(112), APP2(114))은 운영 시스템(100) "의 상부에서" 실행하고, 즉, 그 애플리케이션 프로그램은 운영 시스템에 의해 제공되는 본래 리소스를 액세스하기 위한 기능을 사용한다. 애플리케이션 프로그램이 실행 중에 또는 설치 처리 중에 상호 배타적으로 본래 리소스(102, 104, 106)를 사용하는 경우, 이 애플리케이션 프로그램들은 서로 호환 불가능하다라 한다. APPP1(112)는 경로명 c:＼windows＼system32＼msvcrt.dll에 의해 위치하는 파일을 요구하거나 설치하려 할 수도 있고, APP2(114)는 그 동일한 경로명에 의해 위치하는 제 2의 다른 파일을 요 구하거나 설치하려 할 수도 있다. 이러한 경우에, APP1(112) 및 APP2(114)는 동일한 컴퓨터 상에서 실행될 수 있고, 서로 호환 불가능하다라 한다. 다른 본래 리소스들에 대해서 유사한 문제에 봉착할 수도 있다. 즉, 가장 대표적인 것으로, APP1(112) 및 APP2(114)를 동일한 운영 시스템(100)에 함께 설치하거나 실행하기를 요하는 컴퓨터의 유저의 불편함이다.

도 1b는 여러 유저들을 대신하여 애플리케이션 프로그램(112, 114, 112′, 114′)의 동시 실행을 지원하는 복수 유저 컴퓨터 시스템(multi-user computer system)을 도시한다. 도 1b에 도시하는 바와 같이, APP1의 제 1 인스턴스(112) 및 APP2의 제 1 인스턴스(114)는 제 1 유저 세션(110)의 컨텍스트에서 실행되고, APP1의 제 2 인스턴스(112′)는 제 2 유저 세션(120)의 컨텍스트에서 실행되고, APP2의 제 2 인스턴스(114′)는 제 3 유저 세션(130)의 컨텍스트에서 실행된다. 이러한 환경에서, APP1의 양 인스턴스들(112, 112′)과 APP2의 양 인스턴스들(114, 114′)이 본래 리소스(102, 104, 106)를 단일 유저가 그 애플리케이션을 실행한 것처럼 사용하면 문제가 발생한다. 예를 들어, APP1의 제 1 인스턴스(112)가 애플리케이션 특정 데이터를 레지스트리 키(170)에 저장할 수도 있다. 제 1 유저 컨텍스트(110)에서 실행 중인 APP1의 제 1 인스턴스(112)와 제 2 유저 컨텍스트(120)에서 실행 중인 APP1의 제 2 인스턴스(112′)가 둘 다 동일한 레지스트리 키(170)에 구성 데이터를 저장하려 하면, 이 유저들 중 일 유저에게는 부정확한 구성 데이터가 저장될 것이다. 본래 리소스에 대한 이와 유사한 기타의 문제들이 발생할 수 있다.

본 발명은 이들 애플리케이션 호환성 및 공존성 문제를 해결한다.

본 발명은 서로 호환 불가능한 애플리케이션 프로그램들, 및 동일한 애플리케이션 프로그램의 호환 불가능한 버전들이 단일 컴퓨터 상에서 설치 및 실행될 수 있게 한다. 또한, 단일 유저 컴퓨터용으로 생성되었거나 또는 복수 유저 컴퓨터 상에서 실행되었을 발생하는 문제들에 대한 고려사항 없이 생성된 프로그램들이 복수 유저 컴퓨터 상에서 설치 및 실행될 수 있게 한다. 설명하는 방법 및 장치들은 단일 유저 컴퓨팅 환경에 적용될 수 있으며, 이 환경에는 복수의 유저들이 동일한 컴퓨터를 동시에 사용할 수 있는 환경뿐만 아니라 복수의 유저들이 단일의 컴퓨터를 순차적으로 사용할 수 있는 환경이 포함된다. 본 발명은 애플리케이션 프로그램 또는 기초가 되는 운영 시스템의 변경 없이, 본래 리소스, 예컨대 파일 시스템, 레지스트리 데이터베이스, 시스템 오브젝트, 윈도우 클래스 및 윈도우 네임에 대한 애플리케이션 액세스 및 유저를 가상화한다. 또한, 가상화된 본래 리소스들은 본래의 포맷으로 저장될 수도 있어(즉, 가상화된 파일들은 파일 시스템에 저장되고, 가상화된 레지스트리 엔트리는 레지스트리 데이터베이스에 저장되는 등) 가상화된 리소스의 보기 및 관리가 표준 도구 및 기술을 사용하여 수행될 수 있게 한다.

일 측면에서, 본 발명은 운영 시스템에 의해 제공되는 본래 리소스들에 대한 애플리케이션 프로그램에 의한 액세스를 분리(isolate)하는 방법에 관한 것이다. 제 1 유저를 대신하여 실행 중인 프로세스에 의해 이루어지는 본래 리소스에 대한 요청은 유저 분리 범위(user isolation scope) 및 애플리케이션 분리 범위(application isolation scope)를 포함하는 분리 환경으로 재지정(redirect)된다. 요청된 리소스의 일 인스턴스는 유저 분리 범위에 위치하고, 본래 리소스에 대한 요청은 유저 분리 범위에 위치하는 그 리소스의 인스턴스를 사용하는 것에 대응된다. 어떤 실시예에서, 요청되는 리소스의 일 인스턴스는 유저 분리 범위에 위치하지 않는다. 이러한 실시예에서, 요청은 애플리케이션 분리 범위로 재지정된다. 이러한 실시예들 중 어떤 실시예에서, 요청되는 리소스의 일 인스턴스는 애플리케이션 분리 범위에 위치하고, 본래 리소스에 대한 요청은 애플리케이션 분리 범위에 위치하는 그 리소스의 인스턴스를 사용하는 것에 대응된다.

또 다른 측면에서, 본 발명은 운영 시스템에 의해 제공되는, 애플리케이션 프로그램에 의한 본래 리소스에 대한 액세스를 분리하는 분리 환경에 관한 것이다. 분리 환경에는, 본래 리소스의 일 예를 저장하는 유저에 대응하는 유저 분리 범위, 및 그 유저를 대신하여 실행 중인 프로세스에 의해 이루어지는 본래 리소스에 대한 요청을 인터셉트(intercept)하여 그 요청을 유저 분리 범위로 재지정(redirect)시키는 재지정자(redirector)가 포함된다. 어떤 실시예에서, 고립 환경은 또한 본래 리소스의 일 인스턴스를 저장하는 애플리케이션 분리 범위를 포함한다.

일 측면에서, 본 발명은 본래 리소스들의 집합적인 뷰(an aggregate view of native resources)를 나타내는 방법에 관한 것이다. 본 방법은 시스템 범위에 의해 제공되는 복수의 시스템 범위 본래 리소스들을 열거하는 단계, 및 애플리케이션 분리 범위에 의해 제공되는 복수의 애플리케이션 범위 본래 리소스를 열거하는 단계를 포함한다. 복수의 애플리케이션 범위 리소스들 중 어떤 애플리케이션 범위 리소스는 복수의 시스템 범위 리소스들 중 어떤 시스템 범위 리소스에 대응한다. 본 방법은 또한 복수의 시스템 범위 리소스 중 하나에 대해 복수의 애플리케이션 범위 리소스 중 대응하는 하나의 존재를 결정하고 본래 리소스들의 집합적인 뷰 내에 복수의 애플리케이션 범위 리소스들 중 대응하는 하나를 포함하는 단계를 포함한다.

일 실시예에서, 본 방법은 복수의 시스템 범위 리소스들 중 하나에 대하여, 복수의 애플리케이션 범위 리소스들 중 대응하는 하나의 애플리케이션 범위 리소스가 존재하지 않는다는 것을 판정하는 단계를 포함한다. 또 다른 실시예에서, 본 방법은 본래 리소스들의 집합적인 뷰 내에 복수의 시스템 범위 리소스들 중 하나를 포함하는 단계를 포함한다.

다른 실시예에서, 본 방법은 유저 분리 범위에 의해 제공되는 복수의 유저 범위 본래 리소스들을 열거하는 단계들을 포함한다. 복수의 유저 범위 리소스들 중 어떤 유저 범위의 리소스들은 복수의 시스템 범위 리소스들 중 어떤 시스템 범위 리소스들에 대응된다. 본 방법은 또한, 복수의 시스템 범위 리소스들 중 하나에 대하여 복수의 유저 범위 리소스들 중 하나에 대응하는 존재를 판정하는 것과, 복수의 유저 범위 리소스들 중 대응하는 하나를 본래 리소스들의 집합적인 뷰 내에 포함하는 것을 포함한다.

또 다른 실시예에서, 본 방법은 복수의 시스템 범위 리소스들 중 하나에 대하여 복수의 유저 범위 리소스들 중 대응되는 하나가 존재하지 않는다는 것을 판정하는 것을 포함한다. 일 실시예에서, 본 방법은 시스템 범위 리소스들의 집합적인 뷰 내에 복수의 시스템 범위 리소스들 중 하나를 포함하는 것을 포함한다. 또 다른 실시예에서, 본 방법은 복수의 시스템 범위 리소스들 중 하나에 대하여, 복수의 애플리케이션 범위 리소스들 중 대응되는 하나는 그 리소스가 삭제된다는 것을 나타낸다고 판정하는 것을 포함한다.

일 실시예에서, 본 방법은 시스템 범위 리소소들의 집합적인 뷰로부터 그 시스템 범위 리소스를 제거하는 단계를 포함한다. 또 다른 실시예에서, 본 방법은 복수의 시스템 범위 리소스들 중 하나의 리소스에 대하여 복수의 유저 범위 리소스들 중 대응되는 하나가 그 리소스가 삭제된다는 것을 나타낸다고 판정하는 단계를 포함한다. 또 다른 실시예에서, 본 방법은 시스템 범위 리소스들의 집합적인 뷰로부터 그 시스템 범위 자원을 제거하는 단계를 포함한다.

또 다른 실시예에서, 본 방법은 파일 시스템 드라이버, 미니 드라이버, 유저 모드 후킹 메카니즘(a user mode hooking mechanism) 및 커널 모드 후킹 메카니즘(a kernel mode hooking mechanism) 중 하나에 의해서, 시스템 범위 자원들을 포함하는 파일 시스템을 열거하는 것에 대한 요청을 수신한다. 또 다른 실시예에서, 본 방법은 복수의 레지스트리 엔트리를 열거하기에 대한 요청을 인터셉트하는 단계를 포함한다.

일 측면에서, 본 발명은 유저 분리 범위의 컨텍스트에서 실행 중인 프로세스로부터 시스템 오브젝트로의 액세스 요청을 수신하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하는 방법에 관한 것이다. 요청은 시스템 오브젝트의 가상의 네임을 포함한다. 요청과 연관된 룰이 결정되고, 시스템 오브젝트에 대한 리터럴 네임은 그 결정된 룰에 응답하여 형성된다. 시스템 오브젝트로의 액세스 요청이 운영 시스템에게 이슈된다. 요청은 시스템 오브젝트에 대한 리터럴 네임(literal name)을 포함한다.

또 다른 측면에서 본 발명은 명명된 시스템 오브젝트에 대한 액세스를 가상화하는 장치에 관한 것이다. 후킹 메카니즘은 유저 분리 범위의 컨텍스트에서 실행 중인 프로세스로부터 시스템 오브젝트를 액세스하기 위한 요청을 수신한다. 수신된 요청은 시스템 오브젝트의 가상의 네임을 포함한다. 네임 가상화 엔진은 시스템 오브젝트에 대한 리터럴 네임을 형성한다. 운영 시스템 인터페이스는 리터럴 네임을 사용하여 그 시스템 오브젝트에 대한 액세스를 요청한다.

일 측면에서 본 발명은 본래 리소스에 대한 액세스를 가상화하는 방법에 관한 것이다. 분리 환경의 컨텍스트에서 실행 중인 프로세스로부터 본래 리소스에 대한 액세스에 대한 요청이 수신되며, 그 요청은 본래 리소스의 가상의 네임을 포함한다. 리매핑(remap)의 룰 동작이, 수신된 요청에 포함되어 있는 가시적인 네임과 연관되어 있다는 판정이 이루어진다. 본래 리소스의 리터럴 네임이 형성되며, 리터럴 네임은 동일한 타입의 리터럴의 본래 리소스를 요청된 리소스로서 식별한다. 본래 리소스를 액세스하기 위한 요청이 운영 시스템에 이슈되며, 그 요청은 본래 리소스에 대해 결정된 리터럴 네임을 포함한다.

일 실시예에서, 분리 환경의 컨텍스트에서 실행 중인 프로세스로부터 수신한 요청은 명명된 시스템 오브젝트에 대한 액세스를 위한 것이며, 요청은 시스템 오브젝트에 대한 가상의 네임을 포함한다. 또 다른 실시예에서, 리터럴 시스템 오브젝트를 식별하는 시스템 오브젝트의 리터럴 네임을 형성하는 데 사용하기 위한 룰이 결정된다. 어떤 실시예에서, 시스템 오브젝트는 파일 시스템 엘리먼트이다. 다른 실시예에서, 시스템 오브젝트는 레지스트리 키이다.

또 다른 측면에서, 본 발명은 본래 리소스에 대한 액세스를 가상화하는 장치에 관한 것이다. 후킹 메카니즘은 분리 환경의 컨텍스트에서 실행 중인 프로세스로부터 본래 리소스를 액세스하기 위한 요청을 수신하며, 요청은 본래 리소스의 가상의 네임을 포함한다. 네임 가상화 엔진은 본래 리소스로의 리터럴 네임을 형성하며, 형성된 리터럴 네임은 동일한 타입을 갖는 리터럴 본래 리소스를 요청된 리소스로서 식별한다. 운영 시스템 인터페이스는 식별된 리터럴 본래 리소스에 대한 액세스를 요청한다.

일 실시예에서, 후킹 메카니즘은 본래 리소스를 액세스하기 위한 요청을 인터셉트한다. 또 다른 실시예에서, 룰 엔진은 수신된 요청에 포함되어 있는 가상의 네임과 연관되어 있는 룰을 저장한다.

본 발명은 첨부 청구의 범위에서 상세히 나타나 있다. 상술한 본 발명의 이점 및 본 발명의 다른 이점들은 첨부 도면과 연결하여 다음 상세한 설명을 참조함으로써 보다 잘 이해할 수 있을 것이다. 첨부 도면에서,

도 1a는 일 유저를 대신하여 2개의 애플리케이션 프로그램의 실행을 지원하 는 종래의 운영 시스템 환경의 블록도.

도 1b는 다수의 유저를 대신하여 복수 애플리케이션들의 공동 실행을 지원하는 종래의 운영 시스템 환경의 블록도.

도 2a는 애플리케이션 프로그램의 호환성 및 공존성 문제가 감소된 컴퓨터 시스템의 일 실시예의 블록도.

도 2b는 애플리케이션 프로그램 호환성 및 공존성 문제가 감소된 컴퓨터 시스템의 일 실시예의 도면.

도 2c는 프로세스를 분리 범위와 연관시키기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 3a는 컴퓨터 시스템 내의 본래 리소스에 대한 액세스를 가상화(virtualize)하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 3b는 실행 모드에서 대체 인스턴스를 식별하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 3c는 본래 리소스가 변경하려는 의도로 열리는 중이라는 것을 나타내는 본래 리소스 오픈 요청이 수신되면, 리터럴 리소스(a literal resource)를 식별하기 위해 설치 모드에서 행하는 단계들의 일 실시예를 나타내는 순서도.

도 3d는 가상 리소스 생성 요청이 수신되면 설치 모드에서 리터럴 리소스를 식별하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 4는 설명한 가상화된 환경에서 파일 시스템 내의 엔트리를 오픈 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 5는 설명한 가상화된 환경에서 파일 시스템 내에서 엔트리를 삭제하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 6은 설명한 가상화된 환경에서 파일 시스템 내의 엔트리를 열거하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 7은 설명한 가상화된 환경에서 파일 시스템 내에 엔트리를 생성하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 7a는 신규 파일을 생성한 후 고유의 짧은 파일 네임을 할당하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 8은 설명한 가상화된 환경에서 레지스트리 키를 오픈하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 9는 설명한 가상화된 환경에서 레지스트리 키를 삭제하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 10은 설명한 가상화된 환경에서 레지스트리 데이터베이스 내의 키의 서브키들(subkeys)을 열거하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 11은 설명한 가상화된 환경에서 레지스트리 키를 생성하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 12는 명명된 오브젝트에 대한 액세스를 가상화하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도

도 13은 설명한 환경에서 윈도우 네임 및 윈도우 클래스를 가상화하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 13a는 리터럴 윈도우 네임 및 윈도우 클래스 네임을 결정하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 14는 설명한 가상화된 환경에서 외부 프로세스 COM 서버(out-of-process COM server)를 호출하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 15는 파일 타입 결합(file-type association)을 사용하여 애플리케이션 호출을 가상화하기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

도 16은 소스 분리 범위로부터 타겟 분리 범위로 프로세스를 이동시키기 위해 행하는 단계들의 일 실시예를 나타내는 순서도.

인덱스

인덱스는 독자가 본 발명의 상세한 설명을 따라가기 쉽게 하기 위한 것이다.

1.0 분리 환경의 구성 개요

1.1 애플리케이션 분리

1.2 유저 분리

1.3 본래 리소스들의 집합적인 뷰

1.4 프로세스들과 분리 범위들의 결합

1.4.1. 범위를 벗어난 프로세스들과 분리 범위들의 결합

2.0 가상화 메카니즘 개요

3.0 분리 환경 내로 설치

4.0 분리 환경에서의 실행

4.1. 파일 시스템 가상화

4.1.1 파일 시스템 오픈 동작

4.1.2 파일 시스템 삭제 동작

4.1.3 파일 시스템 열거 동작

4.1.4 파일 시스템 생성 동작

4.1.5 짧은 파일 네임 관리

4.2 레지스트리 가상화

4.2.1 레지스트리 오픈 동작

4.2.2 레지스트리 삭제 동작

4.2.3 레지스트리 열거 동작

4.2.4 레지스트리 생성 동작

4.3 명명된 오브젝트 가상화

4.4 윈도우 네임 가상화

4.5 외부 프로세스 Com 서버 가상화

4.6 가상화된 파일 타입 결합

4.7 분리 환경들간에서 프로세스들의 동적 이동

1.0 분리 환경의 구성 개요

1.1 애플리케이션 분리

이제 도 2a를 참조하면, 애플리케이션 호환성 및 애플리케이션 공존성 문제를 감소시킨 운영 시스템(100)의 제어 하에서 실행 중인 컴퓨터의 일 실시예가 도시되어 있다. 운영 시스템(100)은 그 시스템 계층(108)을 통해서 애플리케이션 프로그램(112, 114)에게 이용 가능한 각종 본래 리소스들을 마련한다. 시스템 계층(108)에 의해서 구현되는 리소스의 뷰를 "시스템 범위"라 할 것이다. 애플리케이션 프로그램들(112, 114)에 의해 본래 리소스(102, 104, 106, 107)에 대한 액세스가 충돌하는 것을 방지하기 위하여, 분리 환경(200)이 제공된다. 도 2a에 도시하는 바와 같이, 분리 환경(200)은 애플리케이션 분리 계층(220) 및 유저 분리 계층(240)을 포함한다. 개념적으로, 분리 환경(200)은 애플리케이션 분리 계층(220)을 통해 애플리케이션 프로그램(112, 114)에게 본래 리소스, 예컨대 파일 시스템(102), 레지스트리(104), 오브젝트(106) 및 윈도우 네임(107)의 고유한 뷰를 제공한다. 각각의 분리 계층은 애플리케이션에게 제공되는 본래 리소스의 뷰를 변경한다(modifies). 일 계층에 의해 제공되는 본래 리소스의 변경된 뷰를 그 계층의 "분리 범위"라 할 것이다. 도 2a에 도시하는 바와 같이, 애플리케이션 분리 계층은 2개의 애플리케이션 분리 범위(222, 224)를 포함한다. 범위(222)는 애플리케이션(112)에게 제공되는 본래 리소스의 뷰를 나타내고, 범위(224)는 애플리케이션(114)에게 제공되는 본래 리소스의 뷰를 나타낸다. 따라서, 도 2a에 도시하는 실시예에서, APP1(112)에는 파일 시스템의 특정한 뷰(102′)가 제공되지만, APP2(114)에는 APP2(114)에게 특정한 파일 시스템의 또 다른 뷰가(102′′)가 제공된다. 어떤 실시예에서, 애플리케이션 분리 계층(220)은 운영 시스템(100)의 최 상부에서 실행 중인 각각의 개별 애플리케이션 프로그램에게 본래 리소스(102, 104, 106, 107)의 특정한 뷰를 제공한다. 다른 실시예에서, 애플리케이션 프로그램(112, 114)은 세트로 그룹화될 수도 있고, 이러한 실시예에서, 애플리케이션 분리 계층(220)은 애플리케이션 프로그램의 각 세트에 본래 리소스의 특정한 뷰를 제공한다. 충돌하는 애플리케이션 프로그램들은 애플리케이션의 호환성 및 공존성을 향상시키기 위하여 별도의 그룹에 포함될 수도 있다. 또 다른 실시예에서, 일 세트에 속하는 애플리케이션들은 관리자에 의해 구성될 수도 있다. 어떤 실시예에서, 시스템 범위에 정확하게 대응하는 "통과 지점(passthrough)" 분리 범위가 정의될 수 있다. 즉, 통과 지점 분리 범위 내에서 실행 중인 애플리케이션은 시스템 범위 상에서 직접 동작한다.

어떤 실시예에서, 애플리케이션 분리 범위는 계층형 부-범위(layered sub-scopes)로 더 나뉜다. 메인 부-범위(main sub-scope)는 기초 애플리케이션 분리 범위를 포함하고, 추가 부-범위는 애플리케이션의 복수의 실행 중인 인스턴스들에게 가시적일 수도 있는, 이 범위에 대한 각종 변형들을 포함한다. 예를 들어, 부-범위는 애플리케이션의 패치 레벨에서의 변화 또는 추가 피쳐들의 설치 또는 제거를 구현하는, 범위에 대한 변경들을 포함할 수도 있다. 어떤 실시예에서, 실행 중인 애플리케이션의 인스턴스에게 가시적으로 되는 추가 부-범위들의 세트가 구성 가능하다. 어떤 실시예에서, 애플리케이션이 실행 중인 유저와 무관하게 실행 중인 애플리케이션의 모든 인스턴스들에게 가시적인 그 부-범위의 세트는 동일하다. 다른 실시예에서, 가시적인 부-범위의 세트는 그 애플리케이션을 실행 중인 유저 마다 다양할 수도 있다. 또 다른 실시예에서, 부-범위의 여러 가지 세트가 정의될 수 있고, 유저가 어느 세트를 사용할 것인 지를 선택할 수도 있다. 어떤 실시예에서, 부-범위는 더 이상 필요하지 않으면 폐기될 수도 있다. 어떤 실시예에서, 부-범위의 세트에 포함되는 변경예들은 단일의 부-범위를 형성하기 위해 함께 병합될 수도 있다.

1.2 유저 분리

이제 도 2b를 참조하면, 애플리케이션 호환성 및 애플리케이션 공존성 문제가 감소된 복수 유저 컴퓨터가 도시되어 있다. 복수 유저 컴퓨터는 위에서 논한 분리 환경(200)에서뿐만 아니라 시스템 계층(108)에 본래 리소스(102, 104, 106, 107)를 포함한다. 애플리케이션 분리 계층(220)은 위에서 논한 바와 같이 기능하며, 일 애플리케이션 또는 애플리케이션의 그룹에 본래 리소스의 변형된 뷰를 제공한다. 유저 분리 계층(240)은 개념적으로 애플리케이션 프로그램(112, 114)에게, 그 애플리케이션을 실행시키는 유저의 유저 ID를 기초로 하여 더 변경되는, 본래 리소스의 뷰를 제공한다. 도 2b에 도시하는 바와 같이, 유저 분리 계층(240)은 다수의 유저 분리 범위(242′, 242′′, 242′′′, 242′′′′, 242′′′′′, 242′′′′′′: 통칭 242)를 포함하는 것으로 간주될 수도 있다. 유저 분리 범위(242)는 본래 리소스의 애플리케이션 특정 뷰의 유저 특정 뷰를 제공한다. 예를 들어, 유저 "a"를 대신하여 유저 세션(110)에서 실행 중인 APP1(112)에는 유저 분리 범위(242′) 및 애플리케이션 분리 범위(222) 둘 다에 의해 변경 또는 변형되는 파일 시스템 뷰(102′(a))가 제공된다.

다른 방법으로, 유저 분리 계층(240)은 애플리케이션 분리 범위(222)에 의해 제공되는 애플리케이션 특정 뷰 변경예의 "상부에" 유저 분리 범위(242′)에 의해 제공되는 유저 특정 뷰 변경예를 "적층함(layering)"으로써 각 개별 유저를 위해 본래 리소스의 뷰를 변경하며, 애플리케이션 특정 뷰 변경예는 차례로 시스템 계층에 의해 제공되는 본래 리소스의 시스템 범위 뷰의 "위에" 적층된다. 예를 들어, 제 1 인스턴스인 APP1(112)가 레지스트리 데이터베이스(104) 내의 엔트리를 액세스할 때, 제 1 유저 세션 및 애플리케이션에 특정적인 레지스트리 데이터베이스의 뷰(104′(a))가 참조된다. 요청되는 레지스트리 키가 레지스트리의 유저 특정 뷰(104′(a)) 내에서 발견되면, 그 레지스트리 키는 APP1(112)로 리턴된다. 요청되는 레지스트리 키가 레지스트리의 유저 특정 뷰(104′(a)) 내에서 발견되지 않으면, 일 애플리케이션에 특정적인 레지스트리 데이터베이스의 뷰(104')가 참조된다. 요청되는 레지스트리 키가 레지스트리의 애플리케이션 특정 뷰(104′) 내에서 발견되면, 그 레지스트리 키는 APP1(112)로 리턴된다. 요청되는 레지스트리 키가 레지스트리의 애플리케이션 특정 뷰(104′) 내에서 발견되지 않으면, 시스템 계층(108) 내의 레지스트리 데이터베이스(104) 내에 저장되어 있는 레지스트리 키(즉, 본래의 레지스트리 키)가 APP1(112)로 리턴된다.

어떤 실시예에서, 유저 분리 계층(240)은 각각의 개별 유저에게 분리 범위를 제공한다. 다른 실시예에서, 유저 분리 계층(240)은 조직 내에서의 역할에 의해 정의될 수도 있고, 또는 관리자에 의해서 사전 결정될 수도 있는 유저의 그룹에게 분리 계층을 제공한다. 또 다른 실시예에서, 어떠한 유저 분리 계층(240)도 제공 되지 않는다. 이러한 실시예에서, 애플리케이션 프로그램이 보는 본래 리소스의 뷰는 애플리케이션 분리 계층(220)에 의해 제공되는 뷰이다. 여러 유저들에 의한 애플리케이션 프로그램의 공동 실행을 지원하는 복수 유저 컴퓨터에 관하여 설명하였으나, 분리 환경(200)은 또한 단일 유저 컴퓨터 상에서, 서로 다른 유저가 동일한 컴퓨터 시스템 상에서 애플리케이션 프로그램을 순차적으로 실행함으로써 생기는 애플리케이션 호환성 및 공존성 문제, 및 동일한 유저가 호환 불가능한 프로그램들을 설치하고 실행함으로써 생기는 문제들을 해결하기 위해서 사용될 수 있다.

어떤 실시예에서, 유저 분리 범위는 부-범위로 더 나뉜다. 유저 분리 범위에 의하여, 유저 분리 범위에서 실행 중인 일 애플리케이션에게 표시되는 뷰에 대한 변경예는 그 범위 내 각각의 부-범위 내에 포함되는 변경예의 집합체이다. 부-범위들은 서로의 위에 적층되고, 그 뷰 집합체에서, 상위 부-범위 내 리소스에 대한 변경예는 하위 계층 내 동일한 리소스에 대한 변경예를 오버라이드(override)한다.

이러한 실시예들 중 어떤 실시예에서, 하나 이상의 이들 부-범위는 유저에게 특정적인 뷰에 대한 변경예를 포함할 수도 있다. 이러한 실시예들 중 어떤 실시예에서, 하나 이상의 부-범위는 시스템 관리자에 의해 정의되거나 운영 시스템에서 유저의 그룹으로서 정의될 수도 있는 유저의 세트에게 특정적인, 그 뷰에 대한 변경예를 포함할 수도 있다. 이러한 실시예들 중 어떤 실시예에서, 이들 부-범위들 중 하나는 특정 로긴 세션에게 특정적이고, 따라서, 세션이 종료되면 폐기되는, 뷰 에 대한 변경예를 포함할 수도 있다. 이러한 실시예들 중 어떤 실시예에서, 유저 분리 범위와 연관되어 있는 애플리케이션 인스턴스에 의한 본래 리소스의 변경은 이들 부-범위들 중 하나에 영향을 미치고, 다른 실시예에서, 본래 리소스의 변경은 변경된 특정 리소스에 따라 서로 다른 부-범위에 영향을 미칠 수도 있다.

1.3 본래 리소스들의 집합적인 뷰

상술한 개념적 구성은, 유저를 대신하여 실행 중인 애플리케이션이 그 애플리케이션 및 유저의 결합에 특정적인 본래 리소스들의 집합적인 또는 단일화되어 가상화되는 뷰로 표시될 수 있게 한다. 이러한 집합화된 뷰를 "가상의 범위"라 할 수도 있다. 유저를 대신하여 실행 중인 애플리케이션 인스턴스는 본래 리소스의 모든 동작하는 가상화된 인스턴스들을 반영하는 본래 리소스의 단일 뷰로 표시된다. 개념적으로, 이러한 집합화된 뷰는 먼저 시스템 범위에서 운영 시스템이 제공하는 본래 리소스의 세트로 이루어지고, 본래 리소스의 세트는 실행 중인 애플리케이션에 적절한 애플리케이션 분리 범위에서 구현되는 변경예로 오버라이드되고, 유저를 대신하여 실행 중인 애플리케이션에 적절한 유저 분리 범위에서 구현되는 변경예로 더 오버라이드된다. 시스템 범위에서의 본래 리소스는 운영 시스템 허가가 특정 유저 또는 애플리케이션에 대한 액세스를 거부하는 경우를 제외하고, 시스템 상의 모든 유저 및 애플리케이션에 공통인 것을 특징으로 한다. 애플리케이션 분리 범위에서 구현되는 본래 리소스에 대한 변경예는, 그 애플리케이션 분리 범위와 연관되어 있는 애플리케이션의 모든 인스턴스에 공통인 것을 특징으로 한다. 유저 분리 범위에서 구현되는 리소스 뷰의 변경예는, 유저 분리 범위와 연관 되어 있는 유저를 대신하여 실행 중인 적절한 애플리케이션 분리 범위와 연관되어 있는 모든 애플리케이션에 공통인 것을 특징으로 한다.

이러한 개념은 부-범위로까지 확장될 수 있다. 유저 부-범위에서 구현되는 리소스 뷰에 대한 변경예는, 유저 분리 부-범위와 연관되어 있는 일 유저 또는 유저의 그룹을 대신하여 실행 중인 적절한 분리 부-범위와 연관되어 있는 모든 애플리케이션에 공통이다. 본 상세한 설명 전체에 걸쳐, 일반적으로 "범위"라는 용어는, 부-범위의 존재 시 부-범위도 지칭하는 것이다.

애플리케이션이 본래 리소스의 목록, 예컨대 파일 시스템 또는 레지스트리 데이터베이스의 일부를 요청하면, 먼저 본래 리소스의 "시스템 범위의" 인스턴스, 즉, 시스템 계층에서 발견되는 인스턴스가 있으면 이를 열거하는 것에 의해 가상화된 목록이 구성된다. 다음으로, 요청된 리소스의 "애플리케이션 범위의" 인스턴스, 즉, 적절한(applicable) 애플리케이션 분리 범위에서 발견되는 인스턴스가 있으면 열거된다. 애플리케이션 분리 범위에서 마주치는 열거된 리소스들은 뷰에 추가된다. (열거된 리소스가 시스템 범위에도 존재했기 때문에) 열거된 리소스가 이미 뷰에 존재하면, 애플리케이션 분리 범위에서 마주치는 리소스의 인스턴스로 대체된다. 이와 유사하게, "요청된 리소스의 "유저-범위" 인스턴스, 즉, 적절한 유저 분리 범위에서 마주치는 인스턴스가 있으면 열거된다. 또, 유저 분리 범위에서 마주치는 임의의 열거된 리소스들은 뷰에 추가된다. (본래 리소스가 시스템 범위에 또는 적절한 애플리케이션 분리 범위에 존재했기 때문에) 본래 리소스가 뷰 내에 이미 존재하면, 본래 리소스는 유저 분리 범위에서 마주치는 리소스의 인스턴 스로 대체된다. 이러한 방식으로, 본래 리소스의 임의의 목록은 열거된 본래 리소스의 가상화를 적절히 반영할 것이다. 개념적으로, 복수의 부-범위를 포함하는 분리 범위를 열거하는 것에 본 접근 방법을 적용한다. 개별 부-범위가 열거되며, 집합적인 뷰에서 상위 부-범위로부터의 리소스는 하위 부-범위에서 매칭되는 인스턴스를 대체한다.

다른 실시예에서, 열거는 시스템 계층으로부터 유저 분리 범위 계층으로가 아니라, 유저 분리 범위 계층으로부터 아래로 시스템 계층으로 수행될 수 있다. 이들 실시예에서, 유저 분리 범위가 열거된다. 그 후, 애플리케이션 분리 범위가 열거되고, 유저 분리 범위에서 열거되지 않은 애플리케이션 분리 범위에 나타나는 임의의 리소스 인스턴스는 구성되는 집합적인 뷰에 추가된다. 시스템 범위에서만 나타나는 리소스에 대해서 이와 유사한 프로세스가 반복될 수 있다.

다른 실시예에서, 모든 분리 범위가 동시에 열거되고 각각의 목록들이 결합될 수도 있다.

일 애플리케이션이, 그 리소스를 변경하려는 의도 없이 본래 리소스의 기존 인스턴스를 열려고 하면, 그 애플리케이션으로 리턴된는 특정 인스턴스는 가상의 범위에서 발견되는 인스턴스이거나, 또는 동등하게, 요청된 리소스의 부모의 가상화된 목록에서 나타날 인스턴스이다. 분리 환경의 관점에서, 애플리케이션은 "가상 리소스"를 오픈 위한 요청 중이라 하고, 그 요청을 충족시키기 위해 사용되는 본래 리소스의 특정 인스턴스는 요청된 리소스에 대응하는 "리터럴 리소스"라 한다.

유저를 대신하여 실행 중인 애플리케이션이 리소스를 열려고 시도하고 그 리소스를 변경하려는 의도로 리소스를 열려고 시도한다고 나타내면, 그 애플리케이션 인스턴스는 다른 유저들을 대신하여 실행 중인 애플리케이션들에게 애플리케이션 분리 범위 및 시스템 범위 내의 리소스들이 공통이므로, 변경하기 위해 그 리소스의 사유 카피(private copy)가 보통 제공된다. 전형적으로, 유저 범위 인스턴스가 이미 존재하지 않으면, 리소스의 유저 범위 카피가 생성된다. 가상 범위에 의해 제공되는 집합적인 뷰의 정의는, 유저 분리 범위로 애플리케이션 범위 또는 시스템 범위 리소스를 카피하는 동작에 의해서 요청되는 유저 및 애플리케이션에 대한 가상 범위에 의해서 제공되는 집합적인 뷰를 변경하지 않는다는 것을 의미한다. 유저를 대신하여 실행 중인 애플리케이션 인스턴스에 의해서 카피된 리소스에 대한 그 후의 변경은 동일한 유저 분리 범위를 공유하지 않는 임의의 다른 애플리케이션 인스턴스의 집합적인 뷰에 영향을 미치지 않는다. 즉, 이러한 변경예는 서로 다른 유저들, 또는 동일한 애플리케이션 분리 범위와 연관되어 있지 않은 애플리케이션 인스턴스들에 대한 본래 리소스들의 집합적인 뷰는 변경하지 않는다.

1.4 프로세스들과 분리 범위들의 결합

애플리케이션은 특정 분리 범위(아래에서 보다 상세히 설명함)로 설치될 수도 있다. 분리 범위 내로 설치되는 애플리케이션은 항상 그 범위와 연관되어 있다. 다른 방법으로, 애플리케이션은 특정 분리 범위 또는 다수의 분리 범위 내로 론치(launched)될 수도 있다. 결과적으로, 일 애프리케이션은 하나 이상의 분리 범위 내로 론치되며 연관된다. 연관된 분리 범위 또는 범위들은 그 프로세스에 본래 리소스들의 특정 뷰를 제공한다. 애플리케이션은 또한 시스템 범위 내로 론치될 수도 있고, 즉, 애플리케이션은 어떤 분리 범위와도 연관되지 않을 수도 있다. 이로써, 일 분리 환경 내에서, 인터넷 익스플로러와 같은 운영 시스템 애플리케이션뿐만 아니라 제 3 자 애플리케이션의 선택적인 실행이 가능하게 된다.

애플리케이션이 설치되는 장소와 무관하게 일 분리 범위 내에서 애플리케이션을 론치시키는 이러한 기능에 의해, 그 분리 범위 내에 애플리케이션의 별도의 설치를 필요로 하지 않으며 애플리케이션 호환성 및 공존성 문제가 완화된다. 서로 다른 분리 범위 내에 설치된 애플리케이션을 선택적으로 론치시키는 기능은, 헬퍼 애플리케이션을 필요로 하는 애플리케이션(예컨대, 워드, 노트 패드 등)을 가지는 기능을 제공하며, 이들 헬퍼 애플리케이션들은 동일한 룰 세트로 론치된다.

나아가, 복수의 분리 환경 내에 애플리케이션을 론치시키는 기능은, 분리형 애플리케이션들과 공통 애플리케이션간에 보다 나은 통합이 가능하게 한다. 이제, 도 2c를 참조하며 간단한 개요로, 프로세스를 분리 범위와 연관시키는 방법은 중지된 상태로 프로세스를 론치시키는 단계들을 포함한다(단계 282). 원하는 분리 범위와 연관되어 있는 룰이 검색되고(단계 284) 프로세스에 대한 식별자 및 검색된 룰이 메모리 소자에 저장되고(단계 286)중지된 프로세스가 다시 계속된다(단계 288). 본래 리소스를 액세스하기 위해 그 프로세스에 의해 이루어지는 후속 호출이 인터셉트 또는 후킹되고(단계 290) 그 프로세스 식별자와 연관되어 있는 룰이 있으면 요청된 리소스에 대한 액세스를 가상화하기 위해 사용된다(단계 292).

계속 도 2c를 참조하며 보다 상세히, 프로세스는 중지된 상태로 론치된다(단계 282). 어떤 실시예에서, 이러한 작업을 수행하기 위해 관례적인 런쳐 프로그램(a custom launcher program)이 사용된다. 이러한 실시예들 중 어떤 실시예에서, 런쳐는 선택된 분리 범위 내로 프로세스를 론치시키도록 특정적으로 설계된다. 다른 실시예에서, 런쳐는 원하는 분리 범위의 사양을 예컨대 명령 라인 옵션에 의해 입력으로서 수신한다.

원하는 분리 범위와 연관되어 있는 룰이 검색된다(단계 284). 어떤 실시예에서, 하드 디스크 드라이브 등 고체 메모리 소자와 같은 영구 스토리지 엘리먼트에서 룰이 검색된다. 룰들은 관계형 데이터베이스로서, 단층 파일 데이터베이스, 트리 구조형 데이터베이스, 2진 트리 구조 등 영구 데이터 구조로서 저장될 수도 있다. 다른 실시예에서, 이들을 저장하기 위해 특정적으로 구성되는 데이터 구조에 룰들이 저장될 수도 있다.

프로세스 ID(PID)와 같은 프로세스에 대한 식별자 및 검색된 룰들은 메모리 소자에 저장된다(단계 286). 어떤 실시예에서, 신규 프로세스 생성에 관한 운영 시스템 메세지를 수신하는 커널 모드 드라이버가 제공된다. 이들 실시예에서, PID 및 검색된 룰이 드라이버의 컨텍스트에서 저장될 수도 있다. 다른 실시예에서, 본래 리소스 요청을 인터셉트하는 파일 시스템 필터 드라이버 또는 미니 필터가 제공된다. 이들 실시예에서, PID 및 검색된 룰은 필터에 저장될 수도 있다. 또 다른 실시예에서, 모든 인터센트는 유저 모드 후킹에 의해서 수행되고, 어떠한 PID도 저장되지 않는다. 룰들은 프로세스 초기화 동안에 유저 모드 후킹 장치에 의해 로딩되고, 어떠한 다른 구성요소들도 PID에 적용하는 룰을 알 필요가 없는데, 그 이유는 룰 연관은 전적으로 프로세스 내에서 수행되기 때문이다.

중지된 프로세스가 다시 계속되고(단계 288), 본래 리소스를 액세스하기 위해 그 프로세스에 의해 이루어지는 그 후의 호출이 인터셉트되거나 후킹되고(단계 290), 그 프로세스 식별자와 연관되어 있는 룰이 있으면 요청된 리소스에 대한 액세스를 가상화하기 위해 사용된다(단계 292). 어떤 실시예에서, 파일 시스템 필터 드라이버 또는 미니 필터는 본래 리소스 액세스에 대한 요청을 인터셉트하고, 인터셉트된 요청과 연관되어 있는 프로세스 식별자가 룰 세트와 연관되어 있었는 지를 판정한다. 수신된 요청과 연관되어 있는 프로세스 식별자가 룰 세트와 연관되어 있으면, 저장되어 있는 프로세스 식별자와 연관되어 있는 룰을, 본래 리소스 액세스에 대한 요청을 가상화하기 위해 사용한다. 수신된 요청과 연관되어 있는 프로세스 식별자가 룰 세트와 연관되어 있지 않으면, 본래 리소스 액세스에 대한 요청은 변경되지 않고 통과된다. 다른 실시예에서, 동적 링크된 라이브러리는 신규 생성된 프로세스 내로 로딩되고, 라이브러리는 분리 룰을 로딩한다. 또 다른 실시예에서, 커널 모드 기술(후킹, 필터 드라이버 미니 필터) 및 유저 모드 기술은 둘 다, 본래 리소스 액세스를 위한 호출을 인터셉트하기 위해 사용된다. 파일 시스템 필터 드라이버가 룰을 저장하는 실시예에서, 라이브러리는 파일 시스템 필터 드라이버로부터 룰을 로딩할 수도 있다.

분리 범위와 연관되어 있는 프로세스의 "자손"인 프로세스는 그들의 "부모" 프로세스의 분리 범위와 연관되어 있다. 어떤 실시예에서, 이는 자손 프로세스가 생성되면, 커널 모드 드라이버가 파일 시스템 필터 드라이버에게 통지하는 것에 의해 수행된다. 이들 실시예에서, 파일 시스템 필터 드라이버는, 부모 프로세스의 프로세스 식별자가 분리 범위와 연관되어 있는 지를 판정한다. 그렇다고 판정하면, 파일 시스템 필터 드라이버는 신규 생성된 자손 프로세스에 대한 프로세스 식별자와 부모 프로세스의 분리 범위들간의 결합을 저장한다. 다른 실시예에서, 파일 시스템 필터 드라이버는 커널 모드 드라이버를 사용하지 않고서 시스템으로부터 직접 호출될 수 있다. 다른 실시예에서, 분리 범위와 연관되어 있는 프로세스에서, 신규 프로세스들을 생성하는 운영 시스템 기능들이 후킹 또는 인터셉트된다. 신규 프로세스를 생성하기 위한 요청이 이러한 프로세스로부터 수신되면, 부모의 분리 범위와 신규 자손 프로세스들간의 결합이 저장된다.

어떤 실시예에서, 범위 또는 부-범위는 전체 프로세스 대신에 개개의 스레드와 연관될 수도 있어, 분리가 스레드별 기반으로 수행될 수 있게 한다. 어떤 실시예에서, 스레드별 분리는 서비스와 COM+ 서버를 위해 사용될 수도 있다.

1.4.1 범위를 벗어난 프로세스들과 분리 범위들의 결합

이러한 발명의 또 다른 측면은, 애플리케이션이 그 애플리케이션 분리 범위 또는 또 다른 애플리케이션 분리 범위 내로 설치되었는 지, 또는 어떠한 애플리케이션 분리 범위 내로도 설치되지 않았는 지와 상관없이, 임의의 애플리케이션 인스턴스를 임의의 애플리케이션 분리 범위와 연관시키는 기능이다. 특정한 애플리케이션 범위 내로 설치되지 않은 애플리케이션은 애플리케이션 분리 범위 및 이에 대응하는 유저 분리 범위의 컨텍스트에서 유저를 대신하여 실행될 수 있는데, 이는 본래 리소스들이 유저 분리 범위, 애플리케이션 분리 범위 및 시스템 범위에 의해 생성되는 집합화된 가상의 범위를 통해서 이들에게 이용 가능하기 때문이다. 분리 범위로 애플리케이션을 실행하는 것이 바람직하면, 이는, 시스템 범위 내로 직접 설치되는 애플리케이션이 분리 범위 내에 애플리케이션을 별도로 설치할 필요 없이 그 분리 범위 내에서 실행될 수 있게 한다. 이는 또한, 시스템 범위 내로 직접 설치되는 애플리케이션들이 임의의 분리 범위의 컨텍스트에서 헬퍼 애플리케이션으로서 사용될 수 있게 한다.

실행 중인 애플리케이션을 형성하는 모든 프로세스들을 포함하여 각각의 애플리케이션 인스턴스는 0개 또는 하나의 애플리케이션 분리 범위와, 확장하여 정확히 0개 또는 하나의 대응하는 유저 분리 범위와 연관된다. 이러한 결합은 리소스 요청에 적용하기 위한 룰이 있으면 결정할 때 룰 엔진에 의해 사용된다. 결합은 애플리케이션이 설치된 애플리케이션 분리 범위로일 필요는 없다. 분리 범위 내로 설치되는 다수의 애플리케이션들이 서로 다른 분리 범위에서 실행되거나 어떠한 분리 범위에서도 실행되지 않으면 필요한 본래 리소스를 이들 애플리케이션이 찾을 수 없기 때문에 정확하게 기능하지 않을 것이다. 그러나, 분리 범위는 시스템 범위를 포함하는 본래 뷰들의 집합체이므로, 시스템 범위에 설치되는 애플리케이션은 일반적으로 임의의 애플리케이션 분리 범위 내부에서 정확하게 기능할 수 있다. 이는, 헬퍼 프로그램 및 외부 프로세스 COM 서버가 특정 분리 범위 내의 유저를 대신하여 실행 중인 애플리케이션에 의해 호출 및 실행될 수 있다.

어떤 실시예에서, 시스템 범위 내에 설치되는 애플리케이션은 이러한 실행의 결과로서 컴퓨터의 파일 및 구성 설정에 무슨 변경이 이루어지는 지를 식별하기 위해 분리 범위에서 실행된다. 모든 영향을 받는 파일 및 구성 설정이 유저 분리 범위 내에서 분리되기 때문에, 이들 파일 및 구성 설정이 용이하게 식별 가능하다. 이러한 실시예들 중 어떤 실시예에서, 이는, 애플리케이션에 의해 파일 및 구성 설정에 이루어지는 변경에 관하여 보고하기 위하여 사용된다. 어떤 실시예에서, 파일 및 구성 설정은 애플리케이션 실행의 종료시에 삭제되며, 이는 컴퓨터의 파일 및 구성 설정에 변경이 없음이 애플리케이션 실행의 결과로서 저장된다는 것을 효과적으로 보장한다. 또 다른 실시예에서, 파일 및 구성 설정은 애플리케이션 실행의 종료 시 선택적으로 삭제되거나 삭제되지 않고, 이는 컴퓨터의 파일 및 구성 설정에 대한 어떤 변경만 애플리케이션의 실행의 결과로서 저장된다는 것을 유효하게 보장한다.

2.0 가상화 메카니즘 개요

이제 도 3a를 참조하면, 아래의 설치 모드와 구분되는 실행 모드에서 본래 리소스에 대한 액세스를 가상화하기 위해 행하는 단계들의 일 실시예가 도시되어 있다. 간략한 개요로, 본래 리소스에 대한 액세스 요청이 인터셉트되거나 수신된다(단계 302). 요청은 액세스를 구하려는 본래 리소스를 식별한다. 수신된 액세스 요청을 처리하는 방법에 관해서 적절한 룰을 결정한다(단계 304). 룰이, 그 요청이 무시되어야 한다고 나타내면, 액세스 요청은 시스템 계층에 대한 변경 없이 전달되고(단계 306) 결과가 요청자(requestor)에게 리턴된다(단계 310). 룰이, 그 액세스 요청이 재지정(redirect)되거나 분리(isolate)되어야 한다고 나타내면, 그 요청을 충족시키는 리소스의 리터럴 인스턴스가 식별되고(단계 308), 리터럴 리소스에 대해 변경된 요청 또는 대체 요청이 시스템 계층으로 전달되고(단계 306), 결과가 요청자에게 리턴된다(단계 310).

계속 도 3을 참조하며, 보다 상세하게, 본래 리소스를 식별하는 요청이 인터셉트되거나 수신된다(단게 302). 어떤 실시예에서, 애플리케이션이 본래 리소스 요청을 하기 위해 운영 시스템이 제공하는 "후킹(hooking)" 기능에 의해 본래 리소스에 대한 요청이 인터셉트된다. 특정 실시예에서, 이는, 운영 시스템에 의해 생성되는 모든 신규 프로세스의 어드레스 공간으로 로딩되고 그 초기화 루틴 동안에 후킹을 수행하는 동적으로 링크되는 라이브러리로서 구현된다. 모든 프로세스 내로 DLL을 로딩하는 것은, 운영 시스템에 의해 제공되는 설비(facility)를 통해 또는 다른 방법으로 프로세스에 대한 실행 가능한 이미지가 디스크로부터 로딩될 때 디스크 파일 내 또는 메모리 내에 개입시키도록 DLL의 실행 가능한 이미지의 리스트를 변경함으로써 달성될 수도 있다. 다른 실시예에서, 후킹 기능, 드라이버 또는 데몬(daemon)에 의해 수행된다. 다른 실시예에서, 운영 시스템에 의해 제공되는 공유형 라이브러리 및 실행 가능한 파일을 포함하는 실행 가능한 이미지들은 후크 기능을 제공하기 위해 또는 본 발명의 로직을 직접 구현하기 위해 변경되거나 패치될 수도 있다. 운영 시스템이 Microsoft WINDOWS 계열의 운영 시스템의 일종인 특정 실시예에서, 인터셉션은 SSDT(System Service Dispatch Table)을 후킹하는 커널 모드 드라이버에 의해 수행될 수도 있다. 또 다른 실시예에서, 운영 시스템은 제 3 자가 본래 리소스에 대한 액세스를 요청하는 후크 기능을 가능하게 하는 시설을 제공할 수도 있다. 이러한 실시예들 중 어떤 실시예에서 운영 시스템이 애플리케이션 프로그래밍 인터페이스(API) 또는 디버그 시설을 통해 이러한 시설을 제공할 수도 있다.

다른 실시예에서, 본래 리소스 요청은 본래 리소스와 연관되어 있는 드라이버 스택 또는핸들러 스택에서 필터에 의해 인터셉트된다. 예를 들어, Microsoft WINDOWS 운영 시스템 계열의 어떤 종류는 제 3 자 필터 드라이버 또는 미니 필터를 파일 시스템 드라이버 스택 내로 플러그하는 기능을 제공하고, 파일 시스템 필터 드라이버 또는 미니 필터는 아래에서 설명하는 분리 기능을 제공하기 위해사용될 수 있다. 또 다른 실시예에서, 본 발명은 이러한 발명의 로직을 직접 합체하는 파일 시스템 구현을 포함한다. 다른 방법으로, 운영 시스템은 아래에서 설명하는 기능을 직접 제공하기 위해 개정될 수도 있다. 어떤 실시예에서, 리소스에 대한 요청을 인터셉트하거나 수신하기 위해 위에서 열거하는 방법들의 일부 또는 전체의 결합이 동시에 사용될 수도 있다.

다수의 실시예에서, 기존 본래 리소스를 오픈 위한 요청 또는 신규 본래 리소스를 생성하기 위한 요청만 후킹되거나 인터셉트된다. 이들 실시예에서, 본래 리소스에 대한 초기 액세스는 리소스가 가상화되게 하는 액세스이다. 초기 액세스 후에, 요청하는 애플리케이션 프로그램은 핸들이나 포인터 또는 리터럴 리소스를 직접 식별하는 운영 시스템에 의해 제공되는 다른 식별자를 사용하여 가상화된 리소스에 관해 운영 시스템와 통신할 수 있다. 다른 실시예에서, 가상화된 본래 리소스 상에서 동작을 위한 다른 타입의 요청들도 후킹되거나 인터셉트된다. 이 러한 실시예들 중 어떤 실시예에서, 애플리케이션에 의해서 가상의 리소스를 열거나 생성하기 위한 요청은 리터럴 리소스를 직접 식별하지 않는 가상의 핸들을 리턴하고, 분리 환경은 가상의 핸들에 대해서 후속 요청을 대응되는 리터럴 리소스로 번역하는 담당을 한다. 예를 들어, 리소스의 사유의 변경 가능한 카피를 분리 범위에 제공하는 동작은, 리소스가 후속 변경을 가능하게 하는 모드에서 열릴 때가 아니라 리소스를 변경하기 위한 요청이 이루어질 때까지 연기될 수 있다. 일단 본래 리소스 요청이 인터셉트되거나 수신되면, 특정 요청을 처리하는 방법을 결정하는 적절한 룰이 결정된다(단계 304). 가장 적절한 룰은 리스트나 트리 구조와 같은 적합한 데이터 구조를 사용하여 구조화되는 룰을 포함하는 단층 파일, 룰 데이터베이스 또는 룰 엔진을 참조함으로써 결정될 수도 있다. 어떤 실시예에서, 2개 이상의 룰들이 적용되면 룰들은 어느 룰이 가장 적절한 것으로 간주되는 지를 판정하는 우선권에 따른다. 이러한 실시예들 중 어떤 실시예에서, 룰 우선권은 룰 자체 내에 포함되거나, 또는 다른 방법으로 룰 우선권은 룰을 저장하기 위해 사용되는 데이터 구조에 내장될 수 있고, 예를 들어, 룰 우선권은 트리 구조에서 룰의 위치로써 표시될 수도 있다. 결정된 룰은 예를 들어, 요청을 재지정시키기 위해 어느 리터럴 리소스로와 같이 가상화된 리소스 요청을 처리하는 방법에 관한 추가 정보를 포함할 수도 있다. 특정 실시예에서, 룰은 필터 필드, 동작 필드 및 데이터 필드를 포함하는 3부분이다. 이러한 실시예에서, 필터 필드는 수신된 본래 리소스 요청을 매칭하여 그 룰이 요청된 리소스 네임에 대해 유효한 지를 판정하기 위해 사용되는 필터를 포함한다. 동작 필드는 "무시", "재지정" 또는 "분 리"일 수 있다. 데이터 필드는 그 룰이 유효하면 사용되는 기능 등의 그 룰이 유효하면 행하게 되는 동작에 관한 임의의 추가 정보일 수도 있다.

"무시"라는 룰 동작은, 요청이 요청된 본래 리소스에 관해 시스템 범위에서 직접 조작한다는 것을 의미한다. 즉, 요청은 변경되지 않고서 시스템 계층(108)으로 전달되고(단계 306), 어떠한 분리 환경(200)도 존재하지 않은 것처럼 요청이 수행된다. 이러한 경우에, 분리 환경은 "홀(hole)"을 가진다고 하거나, 또는 그 요청을 "통과(passthrough)" 요청이라 할 수도 있다.

룰 동작이, 본래 리소스 요청이 재지정되거나 분리되어야 한다고 나타내면, 그 요청을 충족시키는 리터럴 리소스가 식별된다(단계 308).

"재지정"라는 룰 동작은, 요청이 그 요청에서 지정된 것이 아닌 다른 리소스이지만 시스템 범위 본래 리소스에 관해 직접 동작한다는 것을 의미한다. 리터럴 리소스는 지정된 매핑 함수를 적용함으로써 식별되거나, 또는 결정된 룰의 데이터 필드에 의해 요청된 본래 리소스의 네임으로 내포된다. 가장 일반적인 경우에, 리터럴의 본래 리소스는 시스템 범위 내 어느 곳에서나 위치할 수도 있다. 간단한 예로서, 룰{prefix_match("c:＼temp＼", resource name, REDIRECT, replace_prefix("c:＼temp＼", "d:＼wutemp＼", resource name)}은 파일 c:＼temp＼examples＼d1.txt에 대한 액세스 요청을 리터럴 파일 d:＼wutemp＼examples＼d1.txt로 재지정시킬 것이다. 룰의 데이터 필드 및 매칭 함수 내에 포함되는 매칭 함수는 예를 들어, 정규 표현식(regular expressions)을 사용함으로써 복잡한 동작을 지원하도록 더 일반화될 수도 있다. 어떤 실시예는, 유저를 대신하여 실 행 중인 애플리케이션에 적절한 유저 분리 범위 또는 부-범위, 또는 애플리케이션에 적절한 애플리케이션 분리 범위 또는 부-범위 내에서 리터럴 리소스를 로케이팅하는 매핑 함수를 지정하는 기능을 제공할 수도 있다. 다른 실시예는, 분리된 애플리케이션들간에 제어된 형태의 상호작용을 제공하기 위해서, 상이한 애플리케이션에 적절한 애플리케이션 분리 범위 내에서 리터럴 리소스를 로케이팅하는 매핑 함수를 지정하는 기능을 제공할 수도 있다. 어떤 특정한 실시예에서, 재지정 동작은 "무시" 룰 동작과 동일한 동작을 제공하도록 구성될 수 있다. 이들 실시예에서, 리터럴 리소스는 정확하게 요청되는 본래 리소스이다. 이러한 조건이 구성되면, 분리 환경은 "홀"을 갖는다 할 수도 있고, 또는 그 요청을 "통과" 요청이라 할 수도 있다.

"분리"라는 룰 동작은 그 요청이, 적합한 유저 분리 범위 및 애플리케이션 분리 범위를 사용하여 식별되는 리터럴 리소스에 관해 동작한다는 것을 의미한다. 즉, 리터럴 리소스에 대한 식별자는, 유저 분리 범위, 애플리케이션 분리 범위, 유저 분리 범위와 애플리케이션 분리 범위 둘 다를 사용하며, 또는 이들 둘 다를 사용하지 않으며 요청된 본래 리소스에 대한 식별자를 변경함으로써 결정된다. 식별되는 특정 리터럴 리소스는 요청되는 액세스의 타입과, 요청되는 본래 리소스의 인스턴스가 적절한 유저 분리 범위, 적절한 애플리케이션 분리 범위 및 시스템 범위에 이미 존재하는 지에 의존한다.

도 3b는, 본래 리소스 오픈 요청이 수신되면, 리소스가 그것을 변경하려는 의도로 열리는 중임을 나타내는 리터럴 리소스를 식별하기 위해 행하는 단계들의 일 실시예를 도시한다. 간단히, 유저 범위 인스턴스, 즉, 요청된 본래 리소스의 적절한 유저 범위 또는 유저 부-범위에 존재하는 인스턴스가 존재하는 지를 판정한다(단계 354). 존재하면, 유저 범위 인스턴스는 그 요청에 대한 리터럴 리소스로서 식별되고(단계 372), 그 인스턴스는 열려서 요청자에게 리턴된다. 유저 범위 인스턴스가 존재하지 않으면, 요청된 본래 리소스의 애플리케이션 범위 인스턴스가 존재하는 지를 판정한다(단계 356). 애플리케이션 범위 인스턴스가 존재하면, 그 인스턴스는 "후보" 리소스 인스턴스로서 식별되고(단계 359), 그 인스턴스의 변경이 허용되는 지를 판단하기 위해서 후보 인스턴스와 연관되어 있는 승인 데이터(permission data)를 검사한다(단계 362). 어떠한 애플리케이션 범위 인스턴스도 존재하지 않으면, 요청된 본래 리소스의 시스템 범위 인스턴스가 있는 지를 판정한다(단계 358). 요청된 본래 리소스의 시스템 범위 인스턴스가 없으면, 요청된 가상화된 리소스가 가상 범위 내에 존재하지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 360). 그러나, 시스템 범위 리소스가 존재하면, 시스템 범위 리소스는 후보 리소스 인스턴스로서 식별되고(단계 361), 그 인스턴스의 변경이 허용되는 지를 판정하기 위하여 그 후보 인스턴스와 연관되어 있는 승인 데이터를 검사한다(단계 362). 허용되지 않으면, 가상화된 리소스의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 364). 승인 데이터가, 그 후보 리소스가 변경될 수도 있다고 나타내면, 본래 리소스의 후보 인스턴스의 유저 범위 카피가 생성되고(단계 370), 유저 범위 인스턴스는 그 요청에 대한 리터럴 인스턴스로서 식별되고(단계 372), 열려서 요청자에게 리턴된다.

계속 도 3b를 참조하며, 보다 상세하게, 유저 범위 리소스가 존재하는 지, 즉, 요청된 리소스가 적절한 유저 범위 또는 부-범위 내에 존재하는 지를 판정한다(단계 354). 적절한 유저 범위 또는 부-범위가 요청을 하는 애플리케이션과 연관되어 있는 애플리케이션 분리 범위 상에서 층을 이루는 유저와 연관되어 있는 범위이다. 파일 시스템 경우에 유저 분리 범위 또는 부-범위는 유저 분리 범위에 존재하는 모든 파일이 저장되는 디렉토리일 수도 있다. 이러한 실시예들 중 어떤 실시예에서, 유저 분리 디렉토리 아래의 디렉토리 트리 구조는 요청된 리소스의 경로를 반영한다. 예를 들어, 요청된 파일이 c:＼temp＼test.txt이고 유저 분리 범위 디렉토리가 d:＼user1＼app1＼이면, 유저 범위 리터럴 파일로의 경로는 d:＼user1＼app1＼c＼temp＼test.txt이다. 다른 실시예에서, 유저 범위의 리터럴로의 경로는 본래 네임 부여 방식(native naming convention)으로 정의될 수도 있다. 예를 들어, 유저 범위 리터럴 파일로의 경로가 d:＼user1＼app1＼device＼harddisk1＼temp＼test.txt일 수도 있다. 또 다른 실시예에서, 유저 범위 파일은 고유하게 선택되는 네임들로 모두 단일 디렉토리에 저장될 수도 있고, 요청된 파일 네임과 디렉토리 내에 저장되어 있는 대응하는 리터럴 파일의 네임간의 매핑을 저장하기 위해 데이터베이스가 사용될 수도 있다. 또 다른 실시예에서, 리터럴 파일의 컨텍스트는 데이터베이스 내에 저장될 수도 있다. 또 다른 실시예에서, 본래 파일 시스템은 복수의 독립적인 명명의 "스트림"들을 포함하기 위해 단일 파일에 설비를 제공하고, 유저 범위 파일의 콘텐츠는 연관되어 있는 파일들의 추가 스트림으로서 시스템 범위에 저장된다. 다른 방법으로, 리터럴 파일은 디스크 사용 또는 기타 관심 있는 기준을 최적화하도록 설계될 수 있는 커스텀 파일 시스템에 저장될 수도 있다.

유저 범위 리소스 인스턴스가 존재하지 않으면, 애플리케이션 범위 리소스가 존재하는 지, 또는 즉, 요청된 리소스가 애플리케이션 분리 범위에 존재하는지를 판정한다(단계 356). 상술한 방법은 이러한 판정을 하기 위해 사용된다. 예를 들어, 요청된 파일이 c:＼temp＼test.txt이고 애플리케이션 분리 범위 디렉토리가 e:＼app1＼이면, 애플리케이션 범위 파일로의 경로는 e:＼app1＼c＼temp＼test.txt일 수 있다. 위와 마찬가지로, 애플리케이션 범위 파일로의 경로는 본래 네임 부여 방식으로 저장될 수도 있다. 상술한 실시예는 또한 애플리케이션 분리 범위에 적용될 수도 있다.

애플리케이션 범위 리소스가 존재하지 않으면, 시스템 범위 리소스가 존재하는지, 즉, 요청된 리소스가 시스템 범위에 존재하는 지를 판정한다(단계 358). 예를 들어, 요청된 파일이 c:＼temp＼test.txt이면, 시스템 범위 파일로의 경로는 c:＼temp＼test.txt이다. 요청된 리소스가 시스템 범위에 존재하지 않으면, 요청된 리소스가 가상 범위 내에 존재하지 않는다는 표시가 요청자에게 리턴된다(단계 360).

요청된 리소스에 대한 후보 리소스 인스턴스가 애플리케이션 분리 범위 또는 시스템 범위에 위치하면, 후보 리소스 인스턴스의 변경이 허용되는 지를 판정한다(단계 362). 예를 들어, 후보 본래 리소스 인스턴스는, 후보 인스턴스의 변경이 그 유저에 의해 허용되지 않는다는 것을 나타내는 연관되어 있는 본래의 승인 데이 터(associated native permission data)를 가질 수도 있다. 나아가, 룰 엔진은 분리 환경이 리소스의 가상화된 카피에 대한 본래 승인 데이터를 따르거나 오버라이드(override)하도록 지시하는 구성 설정을 포함할 수도 있다. 어떤 실시예에서, 룰은 어떤 가상의 리소스에 대해서, 변경이 발생되는 범위, 예를 들어, 시스템 범위 또는 애플리케이션 분리 범위 또는 부-범위, 또는 유저 분리 범위 또는 부-범위를 지정할 수도 있다. 어떤 실시예에서, 룰 엔진은 액세스되는 리소스의 계층 또는 타입을 기초로 하여 가상화된 본래 리소스들의 서브세트에 적용하는 구성 설정을 지정할 수도 있다. 이러한 실시예들 중 어떤 실시예에서, 구성 설정은 각각의 일 본래 리소스에 특정적일 수도 있다. 또 다른 예에서, 룰 엔진은 파일의 어떤 클래스, 예컨대 실행 가능한 코드 또는 MIME 타입 또는 운영 시스템에 의해서 정의되는 파일 타입과 같은 파일의 어떤 클래스의 변경을 금지하거나 허용하는 구성 데이터를 포함할 수도 있다.

단계(362)에서 후보 리소스 인스턴스의 변경이 허용되지 않는다는 판정이 이루어지면, 가상의 리소스에게 쓰기 액세스(write access)가 허용되지 않는다고 나타내는 에러 상태가 요청자에게 리턴된다(단계 364). 단계(362)에서 후보 리소스 인스턴스의 변경이 허용된다는 판정이 이루어지면, 후보 인스턴스는 적합한 유저 분리 범위 또는 부-범위로 카피된다(단계 370). 요청된 본래 리소스의 논리 계층 구조가 분리 범위 내에 유지되는 실시예에서, 유저 분리 범위에 리소스의 후보 인스턴스를 카피하는 것은 계층 플레이스홀더(hierarchy placeholder)의 분리 범위 내에서의 생성을 요할 수도 있다. 계층 플레이스홀더는, 분리 범위 내에서 카피 되는 자원을 정확하게 로케이팅하기 위해 계층 내에 배치되는 노드이다. 계층 플레이스홀더는 어떠한 데이터도 저장하지 않고, 플레이스홀더 노드로서 식별되며, 그것이 요청자에 리턴되는 리터럴 리소스일 수 없다는 의미로, "존재하지 않는다". 어떤 실시예에서, 플레이스홀더 노드로서의 노드는, 노드, 또는 그 노드의 부모, 또는 시스템 계층에서 어떤 다른 관련된 개체에 부착되는 메타데이터에 그 사실을 기록함으로써 식별이 이루어진다. 다른 실시예에서, 플레이스홀더 노드 네임의 별도의 저장소가 유지된다.

어떤 실시에에서, 룰은, 특정 리소스에 대한 변경이 애플리케이션 분리 범위와 같은 특정 범위에서 이루어질 수도 있다는 것을 지정할 수도 있다. 이러한 경우에, 단계(370)에서의 카피 동작은, 후보 리소스가 발견되는 범위 또는 부-범위에서 후보 리소스에 대한 변경이 허용되는 지를 판정하는 것까지 확장된다. 후보 리소스에 대한 변경이 허용되지 않으면, 후보 리소스 인스턴스는 변경이 허용되며 항상은 유저 범위가 아닐 수 있는 범위 또는 부-범위로 카피되고, 새로운 카피는 리터럴 리소스 인스턴스로서 식별된다(단계 372). 후보 리소스에 대한 변경이 허용되면, 후보 리소스 인스턴스는 리터럴 인스턴스로서 식별되고(단계 372), 열려서 요청자에게 결과가 리턴된다(단계 306).

다시 도 3a를 참조하면, 단계(354)에서 로케이팅되거나 또는 단계(370)에서 생성되는 리터럴 리소스 인스턴스는 열려서(단계 306) 요청자에게 리턴된다(단계 310). 어떤 실시예에서, 이는 운영 시스템에게 "오픈" 명령을 내리고 운영 시스템로부터 "오픈" 명령으로의 응답을 요청자에게 리턴하는 것에 의해 수행된다.

유저를 대신하여 실행 중인 애플리케이션이 본래 리소스를 삭제하면, 가상의 범위로서 그 애플리케이션에게 표시되는 본래 리소스의 집합적인 뷰는 그 삭제를 반영해야 한다. 리소스 삭제 요청은, 리소스 존재 전체를 제거함으로써 리소스를 변경하는 요청이지만, 특별한 타입의 변경 요청이다. 개념적으로, 도 3a에서 개요되는 것과 유사한 방식으로 도 3b에서 개괄한 리터럴 리소스의 판정을 포함하여 리소스 삭제 요청이 진행된다. 그러나, 단계(306)는 분리된 리소스들에 대해서, 그리고 재지정되거나 무시되는 리소스들에 대해서 다르게 동작한다. 재지정 및 무시에서, 리터럴 리소스는 시스템 범위에서 삭제된다. 분리에서, 리터럴 리소스는 "가상으로" 삭제되거나, 즉, 리터럴 소스가 삭제되었다는 사실이 유저 분리 범위에 기록된다. 삭제된 노드는 어떠한 데이터도 포함하지 않고, 삭제된 것으로 식별되며, 그 노드와 그 자손 노드들 전체가 "존재하지 않는다". 즉, 삭제된 노드가 삭제되지 않았을 때 리소스 요청을 충족시키는 리소스이거나 또는 그 부모 노드이면, "리소스가 발견되지 않음"이라는 에러가 요청자에게 리턴된다. 다른 세부사항들은 4절에서 개괄한다. 어떤 실시예에서, 노드에, 또는 그 노드의 부모에, 또는 시스템 계층에서 어떤 다른 관련된 개체에 부착되는 메타데이터에 그 사실을 기록함으로써 노드가 삭제된 로드로서 식별된다. 다른 실시예에서, 삭제된 노드 네임들의 별도의 저장소는 예컨대 별도의 부-범위에서 유지된다.

3.0 분리 환경 내로의 설치

상술한 애플리케이션 분리 범위는, 연관되어 있는 애플리케이션 인스턴스들이 임의의 유저에 독립적으로, 또는 동등하게 모든 가능한 유저들을 대신하여 이러 한 애플리케이션 인스턴스가 생성하는 리소스들을 포함하는 리소스들을 공유하는 범위로서 간주될 수 있다. 이러한 리소스들의 메인 클래스는 애플리케이션이 운영 시스템 상으로 설치될 때 생성되는 세트이다. 도 1a에 도시하는 바와 같이, 2개의 호환 불가능한 애플리케이션들이 둘 다 동일한 시스템 범위 내로는 설치될 수 없지만, 이러한 문제는 이들 애플리케이션들 중 최소한 하나를 분리 환경 내로 설치함으로써 해결될 수 있다.

분리 범위, 또는 분리 범위와 연관되어 있는 애플리케이션 인스턴스는 애플리케이션의 설치를 지원하기 위해 "설치 모드"로 동작할 수 있다. 이는, 도 4 내지 16을 참조하여 아래에서 설명할 "실행 모드"와 반대이다. 설치 모드에서, 애플리케이션 설치 프로그램은 애플리케이션 분리 범위와 연관되고 모든 유저를 대신하여 실행 중인 것으로 가정된다. 애플리케이션 분리 범위는 그 애플리케이션 인스턴스에 대하여, 그 애플리케이션 분리 범위가 "모든 유저"에 대한 유저 분리 범위인 것처럼 동작하며, 어떠한 유저 분리 범위도 그 애플리케이션 인스턴스에 대하여 활성이 아니다.

도 3c는, 그 리소스를 변경하려는 의도로 리소스가 열리는 중이라는 것을 나타내는 본래 리소스 오픈 요청이 수신되면, 리터럴 리소스를 식별하기 위해 설치 모드에서 행하는 단계들의 일 실시예를 도시한다. 간단히, 어떠한 유저 분리 범위도 활성이 아니기 때문에, 요청된 본래 리소스의 애플리케이션 범위 인스턴스가 존재하는 지를 먼저 판정한다(단계 374). 애플리케이션 범위 인스턴스가 존재하면, 이는 리터럴 리소스 인스턴스로서 식별된다(단계 384). 어떠한 애플리케이션 범위의 인스턴스도 존재하지 않으면, 요청된 본래 리소스의 시스템 범위 인스턴스가 존재하는 지를 판정한다(단계 376). 시스템 범위 인스턴스가 존재하지 않으면, 요청된 가상화된 리소스가 가상 범위에 존재하지 않는다고 나타내는 에러 상태를 요청자에게 리턴한다(단계 377). 그러나, 시스템 범위 리소스가 존재하면, 이는 후보 리소스 인스턴스로서 식별되고(단계 378), 그 인스턴스의 변경이 허용되는 지를 판정하기 위해 그 후보 인스턴스와 연관되어 있는 승인 데이터를 검사한다(단계 380). 허용되지 않으면, 가상화된 리소스의 변경이 허용되지 않는다고 나타내는 에러 상태를 요청자에게 리턴한다(단계 381). 승인 데이터가, 그 후보 리소스가 변경될 수도 있다고 나타내면, 어떠한 유저 분리 범위도 활성이 아니므로, 본래 리소스의 후보 인스턴스의 애플리케이션 범위 카피가 생성되고(단계 382), 그 애플리케이션 범위 인스턴스는 그 요청에 대한 리터럴 인스턴스로서 식별된다(단계 384). 어떤 실시예에서, 후보 파일은 룰 엔진에 의해 정의되는 위치에 카피된다. 예를 들어, 룰은, 그 파일이 애플리케이션 분리 범위에 카피된다는 것을 지정할 수도 있다. 다른 실시예에서, 룰은 파일이 카피되어야 하는 특정한 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수도 있다. 카피된 인스턴스를 계층에서 정확히 로케이팅하기 위해, 파일이 카피되는 분리 범위에서 나타나지 않는 요청된 파일의 임의의 부모는 분리 범위에서 플레이스홀더(placeholder)로서 생성된다.

도 3d는 본래 리소스 생성에 대한 요청이 수신되면 리터럴 리소스를 식별하기 위해 설치 모드에서 행하는 단계들의 일 실시예를 도시한다. 간단히, 어떠한 유저 분리 범위도 활성이 아니므로, 요청된 본래 리소스의 애플리케이션 범위 인스턴스가 존재하는 지를 먼저 판정한다(단계 390). 애플리케이션 범위 인스턴스가 존재하면, 리소스가 이미 존재하기 때문에 생성될 수 없다고 나타내는 에러 상태가 요청자에게 리턴될 수도 있다(단계 392). 어떠한 애플리케이션 범위 인스턴스도 존재하지 않으면, 요청된 본래 리소스의 시스템 범위 인스턴스가 존재하는 지를 판정할 수도 있다(단계 394). 시스템 범위 인스턴스가 존재하면, 리소스가 이미 존재하기 때문에 생성될 수 없다고 나타내는 에러 상태가 요청자에게 리턴될 수도 있다(단계 392). 어떤 실시예에서, 리소스를 오픈 위해 사용되는 요청은 리소스의 임의의 범위 시스템 범위 인스턴스가 오버라이트(overwritten)될 수도 있다고 지정할 수도 있다. 시스템 범위 리소스 인스턴스가 존재하지 않으면, 애플리케이션 범위 리소스 인스턴스는 그 요청을 수행하기 위해 생성될 리터럴 인스턴스로서 식별될 수도 있다(단계 396).

도 3b를 도 3c 및 3d와 비교하면, 애플리케이션 분리 범위가 유저 분리 범위를 대체하며 설치 모드가 실행 모드와 유사한 방식으로 동작한다는 것을 알 수 있다. 즉, 신규 리소스의 생성을 포함하여, 지속하는 리소스에 대한 변경은 애플리케이션 유저 분리 범위 대신에 적합한 애플리케이션 분리 범위에서 이루어진다. 또한, 기존의 분리된 리소스에 대한 액세스의 가상화는 또한 적합한 유저 분리 범위를 무시하고 애플리케이션 분리 범위에서 후보 리터럴 리소스를 탐색하기 시작한다.

애플리케이션 분리 범위가 기존 리소스에 대한 변경 및 신규 리소스의 생성 을 포함하기 위해 이러한 방식으로 동작하는 경우가 두 가지 있다. 첫 째, 유저 분리 계층 없이 동작하도록 구성되는 분리 환경, 또는 유저 분리 범위 없이 동작하도록 구성되는 가상 범위가 있을 수 있다. 이러한 경우에, 애플리케이션 분리 범위는 변경되어 신규 생성된 리소스들을 분리할 수 있는 분리 범위뿐이다. 둘째, 특정한 세트의 가상 리소스들을 통제하는 룰은, 특정한 세트의 가상 리소스들이 적절한 유저 분리 범위로가 아니라 적절한 애플리케이션 분리 범위로 분리된다고 지정할 수도 있다. 또, 이는, 그 룰에 적용되는 리소스들의 생성 및 이에 대한 변경예들이, 이들 애플리케이션 인스턴스를 실행 중인 유저에게만 가시적인 유저 분리 범위가 아니라, 그 범위를 공유하는 모든 애플리케이션 인스턴스에게 가시적인 적절한 애플리케이션 분리 범위로 분리될 것이라는 것을 의미한다.

또 다른 실시예에서, 분리 환경은, 어떤 리소스들이 시스템 범위에서 공유될 수 있게 하도록 구성될 수도 있고, 즉, 분리 환경은 하나 이상의 시스템 리소스들에 대하여, 어떠한 유저 분리 범위 및 어떠한 애플리케이션 분리 범위도 존재하지 않은 것처럼 동작할 수도 있다. 시스템 범위에서 공유되는 시스템 리소스들은, 이들이 모든 애플리케이션 및 모든 유저들에 의해서 공유되기 때문에, 즉, 이들이 전역 오브젝트이기 때문에, 변경하려는 의도로 액세스되면 카피되지 않는다.

4.0 분리 환경에서의 실행

상술한 방법 및 장치는 광범위하게 다양한 본래 리소스(108)들을 가상화하기 위해 사용될 수도 있다. 이들 리소스들 중 다수는 아래에 상세히 기술한다.

4.1 파일 시스템 가상화

상술한 방법 및 장치는 파일 시스템에 대한 액세스를 가상화하기 위해 사용될 수도 있다. 상술한 바와 같이, 파일 시스템은 일반적으로 디렉토리의 논리 계층으로 구성되며, 이들 디렉토리는 자체 파일이며, 다른 디렉토리들 및 데이터 파일들을 포함할 수도 있다.

4.1.1 파일 시스템 오픈 동작(file system open operations)

도 4는 전술한 가상 환경에서 파일을 오픈하는 일실시예에 대한 단계들을 도시한다. 파일 오픈에 대한 요청이 수신 또는 인터셉트된다(단계402). 요청은 분리 환경에 의해 가상 파일 네임으로 처리되는 파일 네임을 포함한다. 파일 시스템 오픈 요청의 타겟에 적용할 수 있는 프로세싱 룰이 결정된다(단계 404). 룰 동작이 "재지정(redirect)" 이면(단계406), 요청에서 제공되는 가상 파일 네임은 적용가능 룰에 따른 리터럴 파일 네임에 매핑된다(단계 408). 리터럴 파일 네임을 이용하는 리터럴 파일을 오픈하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계 410). 룰 동작이 "무시(ignore)"이면(단계 406), 리터럴 파일 네임은 가상 파일 네임이 되는 것으로 결정되고(단계 412), 리터럴 파일을 오픈하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터 결과가 요청자에게 리턴된다(단계 410). 단계 406 에서 룰 동작이 "분리(isolate)"이면, 유저 분리 범위내의 가상 파일 네임에 대응하는 파일 네임이 후보 파일 네임으로 식별된다(단계 414). 다시 말하면, 후보 파일 네임은 가상 파일 네임을 유저 분리 범위에 특정되는 대응 본래 파일 네임에 매핑함으로써 형성된다. 후보 파일의 존재 카테고리는 유저 분리 범위 및 후보 파일과 결합된 임의의 메타데이터를 검사 함으로써 결정된다(단계416). 유저 분리 범위내의 후보 파일 또는 그 조상(ancestor) 디렉토리 중 하나가 삭제된 것으로 표시되었기 때문에, 후보 파일이 "존재 부정(negative existence)"을 갖는 것으로 결정되면, 이것은 요청된 가상 파일이 존재하지 않는다는 것을 의미한다. 이러한 경우, 요청된 파일이 검색되지 않는다고 표시하는 에러 상태(error condition)가 요청자에게 리턴된다(단계 422). 후보 파일이 유저 분리 범위에 존재하고 플레이스홀더 노드로서 표시되지 않았기 때문에, 후보 파일이 " 존재 긍정(positive existence)"을 갖는 것으로 결정되면, 요청된 가상 파일은 존재하는 것으로 알려진다. 후보 파일이 요청에 대한 리터럴 파일로 식별되고(단계 418), 요청이 리터럴 파일을 열도록 명령하고 그 결과가 요청자에게 리턴된다(단계 420). 그러나, 단계 416에서, 후보 파일이 존재하지 않거나 후보 파일이 존재하나 플레이스홀더 노드로 표시되기 때문에, 후보 파일이 "존재 불분명(neutral existence)"을 가지면, 가상 파일의 존재 여부를 아직까지 알 수 없다. 이러한 경우, 가상 파일 네임에 대응하는 애플리케이션-범위 파일 네임이 후보 파일 네임으로서 식별된다(단계424). 다시 말하자면, 후보 파일 네임은 가상 파일 네임을 적용가능 애플리케이션 분리 범위에 특정되는 대응 본래 파일 네임에 매핑함으로써 형성된다. 후보 파일의 존재 카테고리는 애플리케이션 분리 범위 및 후보 파일과 결합된 메타데이터를 검사함으로써 결정된다(단계426). 애플리케이션 분리 범위내에서 후보 파일 또는 그 조상 디렉토리들중 하나가 삭제된 것으로 표시되기 때문에, 후보 파일이 "존재 부정"을 갖는 것으로 결정되면, 이것은 요청된 가상 파일이 존재하지 않는 것으로 알려진다. 이러한 경우, 요청된 파일이 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 422). 후보 파일이 애플리케이션 분리 범위에 존재하고 플레이스홀더 노드로 표시되지 않기 때문에, 후보 파일이 "존재 긍정"을 갖는 것으로 결정되면, 요청된 가상 파일은 존재하는 것으로 알려진다. 오픈 요청이 파일을 변경하려는 의도임을 나타내는지를 결정하기 위해 요청이 체크된다(단계 428). 그렇지 않다면, 후보 파일은 요청에 대한 리터럴 파일로서 식별되고(단계 418), 요청은 리터럴 파일을 오픈 위해 명령을 내리고 그 결과는 요청자에게 리턴된다(단계 420). 단계 428에서, 오픈 요청이 파일을 변경하려는 의도임을 나타내면, 파일과 결합된 승인 데이터(permission data)가 파일 변경이 허용되는지를 결정하기 위해 체크된다(단계436). 그렇지 않다면, 파일 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계438). 승인 데이터가 파일이 변경될 수 있다는 것을 나타내면, 후보 파일은 룰 엔진에 의해 정의되는 영역에 카피된다(단계 440). 일부 실시예에서, 후보 파일은 룰 엔진에 의해 정의된 영역에 카피된다. 예를 들면, 룰은 파일이 애플리케이션 분리 범위에 카피되는 것을 지정할 수 있다. 다른 실시예에서, 룰은 파일이 카피되어야 하는, 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 카피된 인스턴스를 계층에 정확히 배치하기 위해, 분리 범위에서 나타나지 않는 요청된 파일의 조상(ancestors)들은 분리 범위에서 플레이스홀더로서 생성된다. 범위내의 인스턴스는 리터럴 파일로서 식별되고(단계 442) 요청은 리터럴 파일을 오픈하도록 명령을 내리고 그 결과는 요청자에게 리턴된다(단계420). 단계 426으로 돌아와서, 후보 파일이 존재하지 않거나 또는 후보 파일이 검색되나 플레이스홀더 노드로서 표시되기 때문에, 후보 파일이 존재 불분명을 갖는다면, 가상 파일이 존재하는지 여부를 아직까지 알 수 없다. 이러한 경우, 가상 파일 네임에 대응하는 시스템-범위 파일 네임이 후보 파일 네임으로서 식별된다(단계 430). 다시 말하자면, 후보 파일 네임이 바로 가상 파일 네임이다. 후보 파일이 존재하지 않는다면(단계 432), 가상 파일이 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계434). 이와 달리 후보 파일이 존재한다면(단계 432), 오픈 요청이 파일을 변경하려는 의도임을 나타내는지 여부를 결정하기 위해 체크된다(단계428). 그렇지 않다면, 후보 파일은 요청에 대한 리터럴 파일로서 식별되고(단계 418), 요청은 리터럴 파일을 오픈 위해 명령을 내리고 그 결과는 요청자에게 리턴된다(단계 420). 단계 428에서, 오픈 요청이 파일을 변경하려는 의도임을 나타내는 것으로 결정되면, 파일과 결합된 승인 데이터(permission data)가 파일 변경이 허용되는지를 결정하기 위해 체크된다(단계436). 그렇지 않다면, 파일 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계438). 승인 데이터가 파일이 변경될 수 있다는 것을 나타내면, 후보 파일은 유저 분리 범위에 카피된다(단계 440). 일부 실시예에서, 후보 파일은 룰 엔진에 의해 정의되는 영역에 카피된다. 예를 들면, 룰은 파일이 애플리케이션 분리 범위에 카피되는 것을 지정할 수 있다. 다른 실시예에서, 룰은 파일이 카피되어야 하는, 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 카피된 인스턴스를 계층에 정확히 배치하기 위해, 분리 범위에서 나타나지 않는 요청된 파일의 조상(ancestors)들은 분리 범위에서 플레이스홀더로서 생성된다. 범위내의 인스턴스는 리터럴 파일로서 식별 되고(단계 442) 요청은 리터럴 파일을 오픈하도록 명령을 내리고 그 결과는 요청자에게 리턴된다(단계420).

이 실시예는 파일을 오픈하는 것보다는 파일 존재를 체크하는 것을 수행하기 위해 간단히 변경될 수 있다. 단계420에서 리터럴 파일을 오픈하기 위한 시도는 리터럴 파일의 존재를 체크하는 것으로 대체되어 그 상태가 요청자에게 리턴된다.

도 4를 계속 참조하여 더욱 상세히 설명하면, 가상 파일을 오픈하기 위한 요청이 수신 또는 인터셉트된다(단계402). 대응하는 리터럴 파일은 유저 분리 범위, 애플리케이션 분리 범위 또는 시스템 범위일 수 있으며, 또는 애플리케이션 분리 부-범위 또는 유저 분리 부-범위일 수 있다. 일 실시예에서, 운영 시스템 함수 또는 파일 오픈을 위한 함수들을 대체하는 함수에 의해 요청이 후킹된다(hooked). 또 다른 실시예에서는 후킹 라이브러리(a hooking dynamically linked library)가 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 파일에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 파일 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 파일 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

요청은 분리 환경에 의해 가상 화일 네임으로 처리되는 파일 네임을 포함한 다. 파일 시스템 오픈 요청에 적용할 수 있는 프로세싱 룰이 룰 엔진을 참고하여 결정된다(단계 404). 일 실시예에서, 오픈 요청에 적용할 수 있는 프로세싱 룰은 오픈 요청에 포함되는 가상 네임을 이용하여 결정된다. 일 실시예에서, 룰 엔진이 관계형 데이터베이스(relational database)로서 제공될 수 있다. 또 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 파일 데이터베이스(flat file database)일 수 있다. 일 실시예에서, 요청된 파일을 위해 제공되는 가상 파일 네임은 요청에 적용하는 하나 이상의 룰을 배치시키기 위해 룰 엔진에 인덱스로서 이용된다. 이러한 실시예들에서, 다수의 룰이 특정 파일에 대해 룰 엔진내에 존재할 수 있고, 가상 파일 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 다른 실시예에서, 프로세스 식별자가 요청에 대해 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 또는 요청을 분리할 수 있다. 도 4에는 파일로 단일 데이터베이스 트랜잭션 또는 단일 룩업(lookup)이 도시되었지만, 룰 룩업은 룰 룩업들의 시리즈로서 수행될 수 있다.

룰 동작이 "재지정"이면(단계 406), 요청에 제공되는 가상 파일 네임은 적용할 수 있는 룰에 따른 리터럴 파일 네임에 매핑된다(단계 408). 리터럴 파일 네임에 의해 식별된 리터럴 파일을 오픈하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터의 결과는 요청자에게 리턴된다(단계 410). 예를 들면, "file_1"이라는 파일 네임을 오픈하기 위한 요청은 "Different_file_1"이라는 리터럴 파일의 오픈을 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하 고, 형성된 리터럴 네임을 인수(argument)로서 함수에 전달함으로써 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 오픈하기 위해 가상 파일 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 오픈 요청을 재명령한다.

룰 동작이 "무시"이면(단계406), 리터럴 파일 네임이 바로 가상 파일 네임이 되는 것으로 결정되고(단계 412), 리터럴 파일을 오픈시키는 요청은 운영 시스템으로 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계410). 예를 들면, "file_1"이라는 파일을 오픈하기 위한 요청은 "file_1"이라는 실제 파일의 오픈을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 함수에 인수로서 전달하는 것에 의해 이뤄진다.

단계 406에서 룰 동작이 "분리"면, 가상 파일 네임에 대응하는 유저-범위 파일 네임이 후보 파일 네임으로서 식별된다(단계414). 다시 말하면, 후보 파일 네임은 가상 파일 네임을 유저 분리 범위에 특정되는 대응 본래 파일 네임에 매핑함으로써 형성된다. 예를 들면, "file_1"이라는 파일을 오픈하기 위한 요청은 "Isolated_file_1"이라는 실제 파일의 오픈을 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 함수에 인수로서 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 오픈하기 위해 가상 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 오픈 요청을 재명령한다.

일 실시예에서, 요청된 시스템 파일을 분리하기 위해 형성된 리터럴 네임은 수신된 가상 파일 네임 및 범위-지정 식별자(scope-specific identifier)에 근거한다. 범위-지정 식별자는 애플리케이션 분리 범위, 유저 분리 범위, 세션 분리 범위, 애플리케이션 분리 부-범위, 유저 분리 부-범위, 또는 이들의 결합과 결합된 식별자일 수 있다. 범위-지정 식별자는 요청에 수신된 가상 네임을 "맹글(mangle)"하기 위해 이용된다.

다른 실시예에서, 유저 분리 범위 또는 부-범위는 유저 분리 범위에 존재하는 모든 파일이 저장되는 디렉토리일 수 있다. 이러한 실시예에서, 유저 분리 디렉토리 아래의 디렉토리 트리 구조는 요청된 리소스의 경로를 반영한다. 다시 말하면, 리터럴 파일 경로는 가상 파일 경로를 유저 분리 범위에 매핑함으로써 형성된다. 예를 들면, 요청된 파일이 c:＼temp＼test.txt 이고 유저 분리 범위 디렉토리가 d:＼user1＼app1＼ 이면, 유저-범위 리터럴 파일에 대한 경로는 d:＼user1＼app1＼c＼temp＼test.txt 일 수 있다. 다른 실시예에서, 유저-범위 리터럴에 대한 경로는 본래 명명 룰(native naming convention)에서 정의될 수 있다. 예를 들면, 유저-범위 리터럴 파일로의 경로는 d:＼user1＼app1＼device＼harddisk1＼temp＼test.txt 일 수 있다. 유저-범위 파일 모두는 유일하게 선택된 네임을 갖는 단일 디렉토리에 저장될 수 있고 데이터베이스는 요청된 파일 네임과 디렉토리에 저장된 대응 리터럴 파일의 네임 사이의 매핑을 저장하는데 이용될 수 있다. 리터럴 파일 의 컨텐츠는 데이터베이스에 저장될 수 있다. 본래 파일 시스템은 단일 파일이 다수의 독립적 "스트림(streams)" 을 포함하도록 하는 기능을 제공하고, 유저-범위 파일의 컨텐츠는 시스템 범위내에서 결합된 파일들의 추가적인 스트림으로서 저장된다. 선택적으로, 리터럴 파일은 디스크 사용을 최적화하거나 또 다른 조건을 위해 설계될 수 있는 커스텀 파일 시스템에 저장될 수 있다.

후보 파일의 존재 카테고리는 유저 분리 범위 및 후보 파일과 결합된 메타데이터를 검사함으로써 결정된다(단계416). 유저 분리 범위내의 후보 파일 또는 조상 디렉토리들중 하나가 삭제된 것으로 표시되기 때문에, 후보 파일이 "존재 부정"을 갖는 것으로 결정되면, 이것은 요청된 가상 파일이 존재하지 않는다는 것을 의미한다. 이러한 경우, 요청된 파일이 검색되지 않는다고 표시하는 에러 상태(error condition)가 요청자에게 리턴된다(단계 422).

일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 파일에 관한 소량의 메타데이터가 바로 리터럴 파일 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이터 지시자는 하나 또는 여러개의 메타데이터 비트를 나타내거나 또는 인코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 파일 네임의 가변에 대한 가상 파일 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 파일 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 파일에 대한 하나 이상의 다른 네임이 가상 파일 네임 및 메타데이터 지시자로부터 형성될 수 있으며, 파일 시스템에 의 해 제공되는 하드 링크(hard link) 또는 소프트 링크(soft link) 기능을 이용하여 생성될 수 있다. 요청이 링크의 네임을 이용하여 파일에 액세스하도록 주어진 경우, 이러한 링크의 존재는 파일이 검색되지 않는다는 것을 나타내는 것으로 분리 환경에 의해 애플리케이션들로부터 숨겨질 수 있다. 특정 링크의 존재 또는 부존재는 각각의 메타데이터 지시자에 대한 메타데이터의 하나의 비트를 나타낼 수 있으며, 또는 메타데이터의 여러 비트를 나타내기 위해 다수의 상태를 취할 수 있는 메타데이터 지시자를 갖는 링크가 될 수 있다. 다른 실시예에서, 파일 시스템이 선택적 파일 스트림(alternate file stream)을 지원하는 경우, 메타데이터의 여러 비트를 나타내는 스트림 크기를 갖는, 선택적 파일 스트림이 메타데이터를 구현하기 위해 생성될 수 있다. 다른 실시예에서, 파일 시스템은 파일 시스템내의 각각의 파일에 대한 일부 3rd 파티 메타데이터를 저장할 수 있는 능력을 직접 제공할 수 있다.

일 실시예에서, 삭제된 파일에 대한 체크를 최적화하기 위해 삭제된 파일 또는 파일 시스템 요소의 리스트가 유지되고 참조될 수 있다. 이러한 실시예에서, 삭제된 파일이 재생성되면 파일 네임은 삭제된 파일들의 리스트로부터 제거될 수 있다. 리스트가 특정 크기를 넘어서면 리스트로부터 파일 네임이 제거될 수도 있다.

단계 416에서, 후보 파일이 유저 분리 범위에 존재하고 플레이스홀더 노드로서 표시되지 않기 때문에, 후보 파일이 "존재 긍정"을 갖는 것으로 결정되면, 요청된 가상 파일이 존재하는 것으로 알려진다. 후보 파일은 요청에 대한 리터럴 파일로서 식별되고(단계418), 요청은 리터럴 파일을 오픈하도록 명령하고 그 결과는 요청자에게 리턴된다(단계 420).

그러나, 단계 416에서, 후보 파일이 존재하지 않거나 또는 후보 파일이 존재하나 플레이스홀더 노드로서 표시되기 때문에, 후보 파일이 "존재 불분명"을 가지면, 가상 파일의 존재 여부를 아직까지 알 수 없다. 이러한 경우, 가상 파일 네임에 대응하는 애플리케이션-범위 파일 네임이 후보 파일 네임으로서 식별된다(단계424). 다시 말하자면, 후보 파일 네임은 가상 파일 네임을 적용가능 애플리케이션 분리 범위에 특정되는 대응 본래 파일 네임에 매핑함으로써 형성된다. 후보 파일의 존재 카테고리는 애플리케이션 분리 범위 및 후보 파일과 결합된 메타데이터를 검사함으로써 결정된다(단계426).

애플리케이션 분리 범위내의 후보 파일 또는 조상 디렉토리들중 하나가 삭제된 것으로 표시되기 때문에, 애플리케이션-범위 후보 파일이 "존재 부정"을 갖는 것으로 결정되면, 이것은 요청된 가상 파일이 존재하지 않는다는 것을 의미한다. 이러한 경우, 요청된 파일이 검색되지 않는다고 표시하는 에러 상태(error condition)가 요청자에게 리턴된다(단계 422).

단계 426에서, 후보 파일이 애플리케이션 분리 범위내에 존재하고 플레이스홀더 노드로서 표시되지 않기 때문에, 후보 파일이 "존재 긍정"을 갖는 것으로 결정되면, 요청된 가상 파일이 존재하는 것으로 알려진다. 오픈 요청이 파일을 변경하려는 의도임을 나타내는지를 결정하기 위해 요청이 체크된다(단계 428). 그렇지 않다면, 후보 파일은 요청에 대한 리터럴 파일로서 식별되고(단계 418), 요청은 리터럴 파일을 오픈 위해 명령을 내리고 그 결과는 요청자에게 리턴된다(단계 420).

단계 428에서, 오픈 요청이 파일을 변경하려는 의도임을 나타내는 것으로 결 정되면, 파일과 결합된 승인 데이터(permission data)가 파일 변경이 허용되는지를 결정하기 위해 체크된다(단계436). 일 실시예에서, 승인 데이터는 애플리케이션-범위 후보 파일과 결합된다. 일 실시예에서, 승인 데이터는 룰 엔진내에 또는 후보 파일과 결합된 메타데이터내에 저장된다. 다른 실시예에서, 후보 파일과 결합된 승인 데이터는 운영 시스템에 의해 제공된다. 또한, 룰 엔진은 분리 환경에 가상화된 리소스 카피들에 대해 본래 승인 데이터를 따르거나(obey) 또는 우선하도록(override) 명령하는 구성 셋팅을 포함할 수 있다. 일실시예에서, 룰은 시스템 범위 또는 애플리케이션 분리 범위 또는 부-범위, 또는 유저 분리 범위 또는 부-범위와 같이 변경이 일어나는 범위내에서 일부 가상 리소스들을 지정할 수 있다. 일 실시예에서, 룰 엔진은 계층 또는 액세스된 리소스의 타입에 근거하여 가상화된 본래 리소스의 부집합(subsets)에 적용하는 구성 셋팅을 지정할 수 있다. 이러한 실시예에서, 구성 셋팅은 각각의 본래 리소스에 대해 지정될 수 있다. 다른 예로서, 룰 엔진은 특정 클래스의 파일의 변경을 금지 또는 허용하는 실행 코드(executable code), 또는 MIME 타입 또는 운영 시스템에 의해 정의되는 파일 타입과 같은 구성 데이터를 포함할 수 있다.

후보 파일과 결합된 승인 데이터가 변경되지 않을 것이라고 나타내는 경우, 파일의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 438). 승인 데이터가 파일이 변경될 수 있다는 것을 나타내는 경우, 후보 파일은 유저 분리 범위에 카피된다(단계440). 일 실시예에서, 후보 파일은 룰 엔진에 의해 정의되는 영역에 카피된다. 예를 들면, 룰은 파일이 다른 애플리케이션 분 리 범위에 카피되는 것을 지정할 수 있다. 다른 실시예에서, 룰은 파일이 카피되어야 하는 특정 애플리케이션 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 파일이 카피되는 분리 범위내에서 나타나지 않는 요청된 파일의 조상들(ancestors)은 계층에 카피된 인스턴스를 정확히 배치하기 위해 분리 범위내에서 플레이스홀더로서 생성된다.

일 실시예에서, 메타데이터는 분리 범위에 카피된 파일과 결합되며 파일이 카피된 날짜 및 시간을 식별한다. 이러한 정보는 파일의 카피된 인스턴스와 결합된 시간 스탬프(stamp)와 파일의 오리지널 인스턴스 또는 하위 분리 범위에 배치된 파일의 다른 인스턴스의 가장 최근 변경에 대한 시간 스탬프와 비교하는데 이용될 수 있다. 이 실시예에서, 파일의 오리지널 인스턴스, 또는 하위 분리 범위에 배치된 파일의 인스턴스가 카피된 파일의 시간 스탬프보다 최근의 시간 스탬프와 결합된 경우, 그 파일은 후보 파일을 업데이트하기 위해 분리 범위에 카피될 수 있다. 다른 실시예에서, 분리 범위내의 파일 카피는 카피된 오리지널 파일을 포함하는 범위를 식별하는 메타데이터와 결합될 수 있다.

또 다른 실시예에서, 변경할 의도로 오픈되었기 때문에 분리 범위에 카피된 파일은 실제로 변경되었는지를 결정하기 위해 모니터될 수 있다. 일 실시예에서, 카피된 파일은 파일이 실제로 변경된 때 정해지는 플래그(flag)와 결합될 수 있다. 이 실시예에서, 카피된 파일이 실제로 변경되지 않은 경우, 카피된 파일과 결합된 임의의 플레이스홀더 노드가 될 수 있을뿐 아니라, 그것이 닫힌 이후 그것이 카피된 범위로부터 제거될 수도 있다.

범위 인스턴스는 리터럴 파일로서 식별되고(단계 442) 요청은 리터럴 파일을 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계 420).

단계 426으로 돌아가서, 후보 파일이 존재하지 않거나 또는 후보 파일이 검색되었으나 플레이스홀더 노드로서 표시되었기 때문에, 후보 파일이 존재 불분명을 갖는 경우, 가상 파일의 존재 여부는 아직까지 알 수 없다. 이러한 경우, 가상 파일 네임에 대응하는 시스템-범위 파일 네임이 후보 파일 네임으로서 식별된다(단계430). 다시 말하면, 후보 파일 네임이 바로 가상 파일 네임이다.

후보 파일이 존재하지 않으면(단계 432), 가상 파일이 검색되지 않았다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 434). 이와 달리 후보 파일이 존재하는 경우(단계432), 오픈 요청이 파일을 변경하려는 의도인지 여부를 결정하기 위해 요청이 체크된다(단계 428).

후보 파일이 그것을 변경하려는 의도없이 오픈된 경우, 시스템-범위 후보 파일이 요청에 대한 리터럴 파일로서 식별되고(단계 418), 요청은 리터럴 파일을 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계 420). 단계 428에서, 오픈 요청이 파일을 변경하려는 의도인 것으로 결정되는 경우, 파일 변경이 허용되는지 여부를 결정하기 위해 파일과 결합된 승인 데이터가 체크된다(단계 436). 일 실시예에서, 승인 데이터는 시스템-범위 후보 파일과 결합된다. 일 실시예에서, 승인 데이터는 룰 엔진에 또는 후보 파일과 결합된 메타데이터에 저장된다. 다른 실시예에서, 후보 파일과 결합된 승인 데이터는 운영 시스템에 의해 제공된다.

시스템-범위 후보 파일과 결합된 승인 데이터가 파일이 변경되지 않을 것이 라는 것을 나타내는 경우, 파일의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계 438). 승인 데이터가 파일이 변경될 수 있다는 것을 나타내는 경우, 후보 파일은 유저 분리 범위에 카피된다(단계 440). 일 실시예에서, 후보 파일은 룰 엔진에 의해 정의되는 영역에 카피된다. 예를 들면, 룰은 파일이 애플리케이션 분리 범위에 카피되도록 하거나 또는 시스템 범위에 남아있도록 지정할 수 있다. 다른 실시예에서, 룰은 파일이 카피되어야 하는 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 파일이 카피되는 분리 범위내에서 나타나지 않는 요청된 파일의 조상들은 계층에 카피된 인스턴스를 정확히 배치하기 위해 분리 범위내에서 플레이스홀더로서 생성된다.

일 실시예에서, 메타데이터는 분리 범위에 카피되는 파일과 결합되며 파일이 카피된 날짜 및 시간을 식별한다. 이 정보는 파일의 카피된 인스턴스와 결합된 시간 스탬프와 파일의 오리지널 인스턴스의 가장 최근 변경에 대한 시간 스탬프를 비교하는데 이용될 수 있다. 이 실시예에서, 파일의 오리지널 인스턴스가 카피된 파일의 시간 스탬프보다 최근인 시간 스탬프와 결합된다면, 오리지널 파일은 후보 파일을 업데이트하기 위해 분리 범위에 카피될 수 있다. 다른 실시예에서, 분리 범위에 카피된 후보 파일은 오리지널 파일이 카피된 범위를 식별하는 메타데이터와 결합될 수 있다.

다른 실시예에서, 변경할 의도로 오픈되었기 때문에 분리 범위에 카피된 파일은 실제로 변경되었는지를 결정하기 위해 모니터될 수 있다. 일 실시예에서, 카피된 파일은 파일이 실제로 변경된 때 정해지는 플래그(flag)와 결합될 수 있다. 이 실시예에서, 카피된 파일이 실제로 변경되지 않은 경우, 카피된 파일과 결합된 임의의 플레이스홀더 노드가 될 수 있을뿐 아니라, 그것이 닫힌 이후 그것이 카피된 범위로부터 제거될 수도 있다. 또 다른 실시예에서, 파일이 실제로 변경된 때, 파일은 오직 적절한 분리 범위에만 카피된다.

범위 인스턴스는 리터럴 파일로서 식별되고(단계442) 요청은 리터럴 파일 오픈을 명령하고 그 결과가 요청자에게 리턴된다(단계420).

4.1.2 파일 시스템 삭제 동작(file system delete operations)

도 5를 참조하면, 파일을 삭제하기 위한 실시예의 단계들이 도시된다. 파일을 삭제하기 위한 요청이 수신 또는 인터셉트된다(단계 502). 요청은 분리 환경에서 가상 파일 네임으로 처리되는 파일 네임을 포함한다. 룰은 어떻게 파일 동작이 처리되는지를 결정한다(단계 504). 룰 동작이 "재지정"인 경우(단계506), 가상 파일 네임은 바로 룰에 따른 리터럴 파일 네임으로 매핑된다(단계 508). 리터럴 파일을 삭제하기 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계510). 룰 동작이 "무시"인 경우(단계506), 리터럴 파일 네임이 가상 파일 네임으로서 식별되고(단계513), 리터럴 파일을 삭제하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계510). 룰 동작이 "분리"인 경우(단계506), 가상 파일의 존재가 결정된다(단계514). 가상 파일이 존재하지 않는 경우, 가상 파일이 존재하지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계516). 가상 파일이 존재하는 경우, 가상화된 파일이 일반적인 파일과 달리 디렉토리를 지정한다면, 가상 디렉토리는 그 것이 임의 가상 파일 또는 가상 서브디렉토리를 포함하는지 여부를 결정하기 위해 참조된다(단계518). 요청된 가상화된 파일이 임의의 가상 파일 또는 가상 서브디렉토리를 포함하는 가상 디렉토리인 경우, 가상 디렉토리는 삭제될 수 없으며 에러 메시지가 리턴된다(단계520). 요청된 가상화된 파일이 일반적인 파일 또는 가상 화일 및 가상 서브디렉토리를 포함하지 않는 가상 디렉토리인 경우, 가상 파일에 대응하는 리터럴 파일이 식별된다(단계 522). 삭제가 허용되는지 여부를 결정하기 위해 파일과 결합된 승인 데이터가 체크된다(단계 524). 그렇지 않다면, 승인 에러 메시지가 리턴된다(단계 526). 파일의 삭제가 허용되고, 리터럴 파일이 적절한 유저 분리 범위에 있다면(단계 528), 리터럴 파일이 삭제되고(단계534) 삭제된 가상 파일을 표현하는 "삭제된(deleted)" 노드가 적절한 유저 분리 범위에 생성된다(단계536). 단계 528에서, 리터럴 파일이 유저 분리 범위에 있지 않고 적절한 애플리케이션 분리 범위 또는 시스템 범위에 있는 경우, 요청된 파일의 유저-범위 인스턴스의 모든 유저-범위 조상의 인스턴스(아직 존재하지 않은)가 생성되고 플레이스홀더로서 표시된다(단계532). 이것은 유저 분리 범위내의 디렉토리 구조의 논리적 계층을 유지하기 위해 이뤄진다. 그 다음, 삭제된 가상 파일을 표현하는 유저-범위 "삭제된" 노드가 적절한 유저 분리 범위에 생성된다(단계536).

도 5를 계속 참조하여, 파일을 삭제하기 위한 요청이 수신 또는 인터셉트된다(단계 502). 파일은 유저 분리 범위, 애플리케이션 분리 범위, 시스템 범위 또는 일부 적용가능한 분리 부-범위에 속할 수 있다. 일 실시예에서, 운영 시스템 함수 또는 파일을 삭제하기 위한 함수를 대체하는 함수에 의해 요청이 후킹된다. 다른 실시예에서, 후킹 라이브러리(hooking dynamically linked library)가 요청을 인터셉트하기 위해 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 파일에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 파일 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 파일 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

요청은 분리 환경에 의해 가상 파일 네임으로서 처리되는 파일 네임을 포함한다. 삭제 동작에 적용할 수 있는 프로세싱 룰이 룰 엔진을 참조하여 결정된다(단계 504). 일 실시예에서, 요청된 파일에 대해 제공되는 가상 파일 네임은 요청에 적용되는 룰을 룰 엔진에 배치시키는데 이용된다. 이러한 실시예에서, 특정 파일에 대해 다수의 룰이 룰 엔진에 존재할 수 있고, 가상 파일 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블, 또는 단층 파일 데이터베이스일 수 있다. 일 실시예에서, 요청된 파일을 위해 제공되는 가상 파일 네임은 요청에 적용하는 하나 이상의 룰을 배치시키기 위해 룰 엔진에 인덱스로서 이용된다. 다른 실시예에서, 프로세스 식별자가 요청에 적용하는 룰을 룰 엔진에 배치시키기 위하여 이용된다. 요 청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나 요청을 분리할 수 있다. 도 5에는 결정의 시리즈로 도시되었지만, 룰 룩업은 단일 데이터베이스 트랜잭션으로서 발생할 수 있다.

룰 동작이 "재지정"인 경우(단계 506), 가상 파일 네임이 적용할 수 있는 룰에 따라 리터럴 파일 네임에 바로 매핑된다(단계 508). 리터럴 파일을 삭제하기 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계510). 예를 들면, "file_1"이라는 파일을 삭제하기 위한 요청은 "Different_file_1"이라는 실제 파일의 삭제를 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 함수에 인수로서 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 삭제하기 위해 가상 파일 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 삭제 요청을 재명령한다.

일 실시예에서, 리터럴 파일 "Different_file_1" 과 결합된 운영 시스템 승인은 리터럴 파일의 삭제를 방지할 수 있다. 이 실시예에서, 파일이 삭제될 수 없다는 에러 메시지가 리턴된다.

룰 동작이 "무시"인 경우(단계 506), 리터럴 파일 네임이 바로 가상 파일 네임으로서 식별되고(단계513), 리터럴 파일을 삭제하는 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계510). 예를 들면, "file_1"이라는 파일을 삭제하는 요청은 "file_1"이라는 실제 파일의 삭제를 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 삭제하기 위해 가상 파일 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 삭제 요청을 재명령한다.

일 실시예에서, 리터럴 파일 "file_1" 과 결합된 운영 시스템 승인은 리터럴 파일의 삭제를 방지할 수 있다. 이 실시예에서, 파일이 삭제될 수 없다는 에러 메시지가 리턴된다.

룰 동작이 "분리"인 경우(단계506), 가상 파일의 존재가 결정된다(단계514). 파일이 존재하지 않으면, 파일이 검색되지 않는다는 것을 나타내는 에러가 리턴된다(단계516).

단계518에서, 파일이 존재하나 그것이 일반적인 파일이 아니고 비어있는 가상 디렉토리가 아닌 경우, 즉 가상 파일 또는 가상 서브디렉토리를 포함하는 경우, 파일이 삭제될 수 없다는 것을 나타내는 에러 메시지가 리턴된다(단계520).

파일이 존재하고 요청된 가상화된 파일이 일반적인 파일 또는 빈 가상 디렉토리인 경우, 즉 가상 파일 및 가상 서브디렉토리를 포함하지 않는 경우(단계 518), 가상 파일에 따른 리터럴 파일이 식별된다(단계 522). 리터럴 파일 네임은 분리 룰에 의해 지정되는 것에 따라 가상 파일 네임으로부터 결정된다. 예를 들면, "file_1"이라는 파일을 삭제하기 위한 요청은 "Isolated_file_1"이라는 실제 파일의 삭제를 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 삭제하기 위해 가상 파일 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 삭제 요청을 재명령한다.

가상 파일에 따른 리터럴 파일이 식별되면, 리터럴 파일이 삭제될 수 있는지 여부가 결정된다(단계524). 파일이 삭제될 수 없으면, 파일이 삭제될 수 없다는 것을 나타내는 에러가 리턴된다(단계524). 일 실시예에서, 승인 데이터는 시스템-범위 후보 파일과 결합된다. 이 실시예에서, 승인 데이터는 룰 엔진 또는 후보 파일과 결합된 메타데이터에 저장된다. 다른 실시예에서, 후보 파일과 결합된 승인 데이터는 운영 시스템에 의해 제공된다.

파일 삭제가 허용되는 경우, 그리고 리터럴 파일이 적절한 유저 분리 범위에 있는 경우(단계 528), 리터럴 파일은 삭제되고(단계 534) 삭제된 가상 파일을 표현하는 "삭제된" 노드가 적절한 유저 분리 범위에 생성된다(단계536).

단계 528에서, 리터럴 파일이 유저 분리 범위에 없지만 적절한 애플리케이션 분리 범위 또는 시스템 범위에 있는 경우, 요청된 파일의 유저-범위 인스턴스의 모든 유저-범위 조상의 인스턴스(아직 존재하지 않은)가 생성되고 플레이스홀더로서 표시된다(단계532). 이것은 유저 분리 범위내의 디렉토리 구조의 논리적 계층을 유 지하기 위해 이뤄진다. 그 다음, 삭제된 가상 파일을 표현하는 유저-범위 "삭제된" 노드가 적절한 유저 분리 범위에 생성된다(단계536). 일 실시예에서, 삭제된 파일의 아이덴티티가 삭제된 파일에 대한 체크를 최적화하기 위해 파일 또는 다른 캐쉬 메모리에 저장된다.

일 실시예에서, 배치된 가상화 파일은 가상화된 파일이 이미 삭제되었다는 것을 나타내는 메타데이터와 결합될 수 있다. 일 실시예에서, 가상화된 파일의 조상(예를 들면, 파일을 포함하는 더 높은 디렉토리)는 그것이 삭제되었다는 것을 나타내는 메타데이터와 결합된다. 이 실시예에서, 가상화된 파일이 존재하지 않는다는 것을 나타내는 에러 메시지가 리턴될 수 있다. 특정 실시예에서, 삭제된 파일 또는 파일 시스템 요소의 리스트가 삭제된 파일에 대한 체크를 최적화하기 위해 유지되고 참조될 수 있다.

4.1.3 파일 시스템 열거 동작(file system enumeration operations)

도 6을 참조하면, 가상화된 환경에서 디렉토리를 열거(enumerate)하기 위한 실시예의 단계가 도시되어 있다. 열거 요청이 수신 또는 인터셉트된다(단계602). 요청은 분리 환경에 의해 가상 디렉토리 네임으로 처리되는 디렉토리 네임을 포함한다. 개념적으로, 가상 디렉토리의 존재는 4.1.1 섹션에 설명된 것과 같이 결정된다(단계603). 가상 디렉토리가 존재하지 않는 경우, 가상 디렉토리가 검색되지 않는다는 것을 나타내는 결과가 요청자에게 리턴된다(단계620). 가상 디렉토리가 존재하는 경우, 열거 요청에 지정된 디렉토리에 대한 룰을 결정하기 위해 룰 엔진이 참조된다(단계604). 룰이 "재지정" 동작을 지정하면(단계606), 가상 디렉토리 네임 에 대응하는 리터럴 디렉토리 네임이 룰에 의해 지정되는 것으로 결정되고(단계608) 리터럴 네임에 의해 식별된 리터럴 디렉토리가 열거되고, 열거 결과는 작업 데이터 저장소(working data store)에 저장되고(단계612), 그 이후 단계630은 이후에 설명된다. 룰 동작이 "재지정"이 아니고 "무시"인 경우(단계610), 리터럴 디렉토리 네임이 바로 가상 디렉토리 네임이며(단계613) 리터럴 디렉토리가 열거되며, 열거 결과가 작업 데이터 저장소에 저장되고(단계612) 그 이후 단계630은 이후에 설명된다. 룰 동작이 "무시"를 지정하는 경우, 먼저 시스템 범위가 열거된다;즉, 후보 디렉토리 네임이 바로 가상 디렉토리 네임이며 후보 디렉토리가 존재하면 그것이 열거된다. 열거 결과는 작업 데이터 저장소에 저장된다. 후보 디렉토리가 존재하지 않으면, 작업 데이터 저장소는 현재 스테이지에서는 비어있다(단계614). 다음으로, 후보 디렉토리가 가상 디렉토리의 애플리케이션-범위 인스턴스로서 식별되고, 후보 디렉토리의 존재 카테고리가 결정된다(단계615). 후보 디렉토리가 "존재 부정", 즉 범위내의 그것 또는 그것의 조상이 삭제된 것으로 표시되면, 이 범위내에서 그것은 삭제된 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱(flushing)하는 것에 의해 나타난다(단계642). 후보 디렉토리가 존재 부정을 갖지 않으면, 후보 디렉토리가 열거되고 임의의 열거 결과는 작업 데이터 저장소에 합쳐진다(merged). 특히, 열거에서 각각의 파일 시스템 요소에 대해, 그것의 존재 카테고리가 결정된다. 존재 부정을 갖는 요소는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는, 즉 존재하면서 플레이스홀더로서 표시되지 않고 삭제되지 않은, 요소는 작업 데이터 저장소에 추가되고, 작업 데이터 저장소에 이미 존재하 는 것은 대응하는 요소로 대체한다(단계616).

두 가지 경우에 있어서, 후보 디렉토리는 가상 디렉토리의 유저-범위 인스턴스로서 식별되고, 후보 디렉토리의 존재 카테고리가 결정된다(단계617). 후보 디렉토리가 "존재 부정"을 갖는다면, 즉 범위내의 그것 또는 그것의 조상이 삭제된 것으로 표시되면, 이 범위내에서 그것은 삭제된 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계644). 후보 디렉토리가 존재 부정을 갖지 않는다면, 후보 디렉토리가 열거되고 얻어진 열거 결과는 작업 데이터 저장소에 합쳐진다. 특히, 열거에서 각각의 파일 시스템 요소에 대해, 그것의 존재 카테고리가 결정된다. 존재 부정을 갖는 요소는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는, 즉 존재하면서 플레이스홀더로서 표시되지 않고 삭제되지 않은, 요소는 작업 데이터 저장소에 추가되고, 작업 데이터 저장소에 이미 존재하는 것은 대응하는 요소로 대체하고(단계618), 단계 630은 이하에서 설명된다.

그 다음, 룰의 세가지 타입 모두에 대해, 단계 630이 실행된다. 요청된 디렉토리의 직접적인 자손(children)과 매치하나 요청된 디렉토리 자체와는 매치하지 않는 것을 걸러내는 룰의 집합을 검색하기 위해 룰 엔진에게 질의한다(queried). 집합내의 각각의 룰에 대해, 그 네임이 룰의 네임과 매치하는 가상 자손의 존재가 4.1.1 세션에서 요약된 로직을 이용하여 질의된다. 자손이 존재 긍정을 갖는 경우, 이것은 작업 데이터 저장소에 추가되고, 이미 존재하는 동일한 네임의 자손을 대체한다. 자손이 존재 부정을 갖는 경우, 자손에 대응하는 작업 데이터 저장소내의 엔트리는 제거된다(단계632). 마지막으로, 구성된 열거는 작업 데이터 저장소로부터 요청자로 리턴된다(단계620).

도 6을 계속 참조하여, 디렉토리 열거를 위한 요청이 수신 또는 인터셉트된다(단계602). 일 실시예에서, 요청은 운영 시스템 함수 또는 디렉토리를 열거하기 위한 함수를 대체하는 함수에 의해 후킹된다. 다른 실시예에서, 후킹 라이브러리가 요청을 인터셉트하기 위해 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 파일에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 파일 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 파일 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

가상 디렉토리의 존재가 결정된다(단계603). 이것은 4.1.1 세션에 설명된 것에 의해 이뤄진다. 가상 디렉토리가 존재하지 않는 경우, 이것은 열거될 수 없고, 가상 디렉토리가 존재하지 않는다는 것을 나타내는 결과가 요청자에게 리턴된다(단계620).

요청은 분리 환경에 의해 가상 디렉토리 네임으로서 처리되는 디렉토리 네임을 포함한다. 가상 디렉토리가 존재하는 경우, 어떻게 열거 동작이 처리되는지 결정하는 룰은 룰 엔진을 참조하는 것에 의해 배치된다(단계604). 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공된다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블, 또는 단층 파일 데이터베이스일 수 있다. 일 실시예에서, 요청된 디렉토리에 대해 제공된 가상 디렉토리 네임은 요청에 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 이 실시예에서, 특정 디렉토리에 대한 다수의 룰이 룰 엔진에 존재할 수 있고, 가상 디렉토리 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 다른 실시예에서, 프로세스 식별자가 요청에 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 요청을 분리시킨다. 도 6에는 단일 데이터베이스 트랜잭션 또는 단일 룩업이 도시되었지만, 룰 룩업은 룰 룩업들의 시리즈로서 수행될 수 있다.

룰 동작이 "재지정"인 경우(단계606), 가상 디렉토리 네임이 룰에 따른 리터럴 디렉토리 네임에 바로 매핑된다(단계608). 리터럴 디렉토리를 열거하기 위한 요청은 운영 시스템에 전해지고(단계612) 단계630이 실행되는데 이는 이후에 설명된다. 예를 들면, "directory_1"이라는 디렉토리를 열거하기 위한 요청은 "Different_directory_1"이라는 리터럴 디렉토리의 열거를 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 열거를 위해 디렉토리를 오픈하기 위해 가상 네임을 이용하는 제 1 요청은 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 디렉토리 오픈 요청을 재명령한다.

룰 동작이 "재지정"이 아니고 "무시"인 경우(단계610), 리터럴 디렉토리 네임은 바로 가상 디렉토리 네임으로서 식별되고(단계613), 리터럴 디렉토리를 열거하기 위한 요청은 운영 시스템으로 전해지고(단계612) 단계630이 실행되는데 이것은 이후에 설명된다. 예를 들면, "directory_1"이라는 디렉토리를 열거하기 위한 요청은 "directory_1"이라는 실제 디렉토리의 열거를 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 파일 시스템 필터 드라이버를 이용하는 실시예에서, 디렉토리를 열거하기 위해 가상 네임을 이용하는 제 1 요청은 필터 드라이버에 의해 변경되지 않고 전달된다.

단계610에서 결정된 룰 동작이 "무시"가 아니고 "분리"인 경우, 시스템 범위가 열거된다, 즉 요청에서 제공된 가상 네임이 열거된 디렉토리를 식별하기 위해 이용된다(단계614). 열거의 결과는 작업 데이터 저장소에 저장된다. 일 실시예에서, 작업 데이터 저장소는 메모리 요소들로 구성된다. 다른 실시예에서, 작업 데이터 저장소는 데이터베이스 또는 파일 또는 고체-상태 메모리 요소 또는 영구적 데이터 저장소를 포함한다.

다음으로, 후보 디렉토리가 가상 디렉토리의 애플리케이션-범위 인스턴스로서 식별되고, 후보 디렉토리의 존재 카테고리가 결정된다(단계615). 후보 디렉토리가 "존재 부정"을 갖는 경우, 즉 범위내의 그것 또는 그것의 조상중 하나가 삭제된 것으로 표시되면, 범위내에서 그것은 삭제된 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계642).

일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 파일에 관한 소량의 메타데이터가 바로 리터럴 파일 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이터 지시자는 하나 또는 여러개의 메타데이터 비트를 나타내거나 또는 코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 파일 네임의 가변에 대한 가상 파일 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 파일 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 파일에 대한 하나 이상의 다른 네임이 가상 파일 네임 및 메타데이터 지시자로부터 형성될 수 있으며, 파일 시스템에 의해 제공되는 하드 링크(hard link) 또는 소프트 링크(soft link) 기능을 이용하여 생성될 수 있다. 요청이 링크의 네임을 이용하여 파일에 액세스하도록 주어진 경우, 이러한 링크의 존재는 파일이 검색되지 않는다는 것을 나타내는 것으로 분리 환경에 의해 애플리케이션들로부터 숨겨질 수 있다. 특정 링크의 존재 또는 부존재는 각각의 메타데이터 지시자에 대한 메타데이터의 하나의 비트를 나타낼 수 있으며, 또는 메타데이터의 여러 비트를 나타내기 위해 다수의 상태를 취할 수 있는 메타데이터 지시자를 갖는 링크가 될 수 있다. 다른 실시예에서, 파일 시스템이 선택적 파일 스트림(alternate file stream)을 지원하는 경우, 메타데이터의 여러 비트를 나타내는 스트림 크기를 갖는, 선택적 파일 스트림이 메타데이터를 구현하기 위해 생성될 수 있다. 다른 실시예에서, 파일 시스템은 파일 시스템내의 각각의 파일에 대한 일부 3rd 파티 메타데이터를 저장할 수 있는 능력을 직접 제공할 수 있다. 다른 실 시예에서, 개별적 부-범위는 삭제된 파일을 기록하는데 이용될 수 있으며, 그 부-범위내 파일의 존재(플레이스홀더로서 표시되지 않음)는 파일이 삭제되었다는 것을 의미하기 위한 것이다.

후보 디렉토리가 존재 긍정을 갖지 않으면, 호보 디렉토리가 열거되고 얻어진 열거 결과는 작업 데이터 저장소에 합쳐진다. 특히, 열거에서의 각각의 파일 시스템 요소에 대해, 그 존재 카테고리가 결정된다. 존재 부정을 갖는 요소는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 요소, 즉 플레이스홀더로서 표시되지 않고 삭제된 것으로 표시되지 않고 존재하는 것은 작업 데이터 저장소에 추가되고, 작업 데이터 저장소에 이미 존재하는 것은 대응하는 요소로 대체한다(단계616).

두가지 경우에서, 후보 디렉토리가 가상 디렉토리의 유저-범위 인스턴스로서 식별되고, 후보 디렉토리의 존재 카테고리가 결정된다(단계617). 후보 디렉토리가 "존재 부정"을 가지면, 즉, 범위내의 그것 또는 그 조상이 삭제된 것으로 표시되면, 이 범위내에서 삭제된 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계644). 후보 디렉토리가 존재 부정을 갖지 않으면, 후보 디렉토리가 열거되고 얻어진 열거 결과는 작업 데이터 저장소에 합쳐진다. 특히, 열거에서의 각각의 파일 시스템 요소에 대해, 그 존재 카테고리가 결정된다. 존재 부정을 갖는 요소는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 요소, 즉 플레이스홀더로서 표시되지 않고 삭제된 것으로 표시되지 않고 존재하는 것은 작업 데이터 저장소에 추가되고, 작업 데이터 저장소에 이미 존재하는 것은 대응하는 요소로 대체하며(단계618), 그 이후 단계630은 이후에 설명된다.

그 다음, 룰의 세가지 타입 모두에 대해, 단계 630이 실행된다. 요청된 디렉토리의 직접적인 자손(children)과 매치하나 요청된 디렉토리 자체와는 매치하지 않는 것을 걸러내는 룰의 집합을 검색하기 위해 룰 엔진에게 질의한다(queried). 집합내의 각각의 룰에 대해, 그 네임이 룰의 네임과 매치하는 가상 자손의 존재가 4.1.1 세션에서 요약된 로직을 이용하여 질의된다. 자손이 존재 긍정을 갖는 경우, 이것은 작업 데이터 저장소에 추가되고, 이미 존재하는 동일한 네임의 자손을 대체한다. 자손이 존재 부정을 갖는 경우, 자손에 대응하는 작업 데이터 저장소내의 엔트리는 제거된다(단계632). 마지막으로, 구성된 열거는 작업 데이터 저장소로부터 요청자로 리턴된다(단계620).

당업자라면 전술한 레이어화된 열거 프로세스는 다수의 분리 부-범위를 포함하는 단일 분리 범위를 열거하는 동작에 대한 작은 변경으로 적용할 수 있다는 것을 이해할 수 있을 것이다. 작업 데이터 저장소가 생성되고, 성공적인 부-범위가 열거되고 그 결과가 분리 범위의 통합된 열거를 형성하기 위해 작업 데이터 저장소에 합쳐진다.

4.1.4 파일 시스템 생성 동작(file system create operations)

도 7을 참조하여, 분리 환경내의 파일을 생성하는 실시예에 대한 단계들이 도시된다. 파일을 생성하는 요청이 수신 또는 인터셉트된다(단계702). 요청은 분리 환경에 의해 가상 파일 네임으로서 처리되는 파일 네임을 포함한다. 적용할 수 있는 룰을 이용하는 가상화를 이용하여 즉, 적절한 유저 및 애플리케이션 분리 범위 를 이용하여 섹션 4.1.1에 전술한 것과 같이 요청된 파일을 오픈하려는 시도가 이뤄진다(단계704). 액세스가 거부되면(단계706), 액세스 거부 에러가 요청자에게 리턴된다(단계709). 액세스가 허용되면(단계706), 그리고 요청된 파일이 성공적으로 오픈되면(단계710), 요청된 파일이 요청자에게 리턴된다(712). 그러나, 액세스가 허용되었으나(단계706) 요청된 파일이 성공적을 오픈되지 않고 요청된 파일의 부모(parent) 또한 존재하지 않으면(단계714), 요청에 적절한 에러가 요청자에게 보내진다(단계716). 반면에, 요청된 파일의 부보가 적절한 유저 및 애플리케이션 범위를 이용하는 가상화된 뷰에서 검색되면(단계714), 룰은 어떻게 파일 동작이 처리되는지를 결정한다(단계718). 룰 동작이 "재지정" 또는 "무시"인 경우(단계720), 가상 파일 네임이 룰에 따른 리터럴 파일 네임으로 바로 매핑된다. 특히, 룰 동작이 "무시"인 경우, 리터럴 파일 네임이 바로 가상 파일 네임으로서 식별된다. 룰 동작이 "재지정"인 경우, 룰에 의해 지정되는 것으로서, 리터럴 파일 네임은 가상 파일 네임으로부터 결정된다. 그 다음 리터럴 파일을 생성하는 요청이 운영 시스템에 전해지고, 그 결과가 요청자에게 리턴된다(단계724). 단계720에서 룰 동작이 "분리"인 경우, 리터럴 파일 네임은 유저 분리 범위내에서 가상 파일 네임의 인스턴스로서 식별된다. 리터럴 파일이 이미 존재하나 플레이스홀더임을 나타내는 메타데이터와 결합되거나 그것이 삭제된 경우, 결합된 메타데이터는 이러한 표시를 제거하기 위해 변경되고, 파일이 비었는지가 확인된다. 두 경우에서, 리터럴 파일을 오픈하기 위한 요청이 운영 시스템으로 전해진다(단계726). 리터럴 파일이 성공적으로 오픈된 경우(단계728), 리터럴 파일이 요청자에게 리턴된다(단계730). 단계 728 에서, 요청된 파일이 유저-분리 범위에 현재 존재하지 않는 리터럴 파일의 각각의 조상에 대한 플레이스홀더를 오픈하는데 실패하면(단계732), 리터럴 네임을 이용하는 리터럴 파일을 생성하기 위한 요청은 운영 시스템에 전해지고 그 결과가 요청자에게 리턴된다(단계734).

도 7을 계속 참조하여, 파일을 생성하기 위한 요청이 수신 또는 인터셉트된다(단계702). 일 실시예에서, 운영 시스템 함수 또는 파일을 생성하는 함수를 대체하는 함수에 의해 요청이 후킹된다. 다른 실시예에서, 후킹 라이브러리가 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 파일에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 파일 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 파일 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

요청은 분리 환경에 의해 가상 파일 네임으로서 처리되는 파일 네임을 포함한다. 요청자는 적용할 수 있는 룰을 이용하는 가상화를 이용하여 요청된 파일을 오픈하려고 시도한다. 적용할 수 있는 룰을 이용하는 가상화를 이용하여 즉, 적절한 유저 및 애플리케이션 분리 범위를 이용하여 섹션 4.1.1에 전술한 것과 같이 요청된 파일을 오픈하려는 시도가 이뤄진다(단계704). 가상화된 오픈 동작중에 액세 스가 거부되면(단계706), 액세스 거부 에러가 요청자에게 리턴된다(단계709). 액세스가 허용되고(단계706), 요청된 가상 파일이 성공적으로 오픈되면(단계710), 대응하는 리터럴 파일이 요청자에게 리턴된다(단계712). 그러나, 액세스는 허용되었으나(단계706), 요청된 파일이 성공적으로 오픈되지 않으면(단계710) 가상 파일은 존재하지 않는 것으로 결정된다. 섹션 4.1.1의 과정에 의해 결정되는 것과 같이, 요청된 가상 파일의 가상 부보 역시 존재하지 않는 경우, 요청에 적절한 에러가 요청자에게 내려진다(단계716). 적절한 유저 및 애플리케이션 범위를 이용하는 가상화된 뷰에 요청된 가상 파일의 가상 부보가 검색되는 경우, 어떻게 생성 동작이 처리되는지 결정하는 룰이 룰 엔진을 참조하여 배치된다. 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 파일 데이터베이스(flat file database)일 수 있다. 일 실시예에서, 요청된 파일에 대해 제공되는 가상 파일 네임은 요청에 대해 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 이 실시예에서, 다수의 룰이 특정 파일에 대해 룰 엔진내에 존재할 수 있고, 가상 파일 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 다른 실시예에서, 프로세스 식별자가 요청에 대해 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 또는 요청을 분리할 수 있다. 도 7에는 파일로 단일 데이터베이스 트랜잭션 또는 단일 룩업(lookup)이 도시되었지만, 룰 룩업은 룰 룩업들의 시리즈로서 수행될 수 있다.

룰 동작이 "재지정" 또는 "무시"인 경우(단계720), 가상 파일 네임이 룰에 따라 리터럴 파일 네임으로 바로 매핑된다. 룰 동작이 "재지정"인 경우(단계720), 리터럴 파일 네임은 룰에 의해 지정되는 것으로, 가상 파일 네임으로부터 결정된다(단계724). 룰 동작이 "무시"인 경우(단계720), 리터럴 파일 네임은 정확히 가상 파일 네임이 되는 것으로 결정된다(단계724). 룰 동작이 "무시" 또는 룰 동작이 "재지정"인 경우, 결정된 리터럴 파일 네임을 이용하는 리터럴 파일을 생성하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에 리턴된다(단계724). 예를 들면, "file_1"이라는 가상 파일을 생성하기 위한 요청은 "Different_file_1"이라는 리터럴 파일의 생성을 초래할 수 있다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다(단계724). 파일 시스템 필터 드라이버를 이용하는 실시예에서, 파일을 오픈하기 위해 가상 파일 네임을 이용하는 제 1 요청은 파일 시스템 필터 드라이버로부터 결정된 리터럴 네임을 나타내는 STATUS_REPARSE 응답의 리턴을 초래한다. 그 다음 I/O 관리자는 STATUS_REPARSE 응답에 포함된 리터럴 네임으로 파일 오픈 요청을 재명령한다.

단계720에서 결정된 룰 동작이 "무시"와 "재지정"이 아니고 "분리"인 경우, 리터럴 파일 네임은 유저 분리 범위내의 가상 파일 네임의 인스턴스로서 식별된다. 리터럴 파일이 이미 존재하나 그것이 플레이스홀더 또는 삭제되었다는 것을 나타내는 메타데이터와 결합된 경우, 결합된 메타데이터는 이러한 표시를 제거하기 위해 변경되고 파일이 비었는지 확인된다.

일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 파일에 관한 소량의 메타데이터가 바로 리터럴 파일 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이터 지시자는 하나 또는 여러개의 메타데이터 비트를 나타내거나 또는 코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 파일 네임의 가변에 대한 가상 파일 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 파일 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 파일에 대한 하나 이상의 다른 네임이 가상 파일 네임 및 메타데이터 지시자로부터 형성될 수 있으며, 파일 시스템에 의해 제공되는 하드 링크(hard link) 또는 소프트 링크(soft link) 기능을 이용하여 생성될 수 있다. 요청이 링크의 네임을 이용하여 파일에 액세스하도록 주어진 경우, 이러한 링크의 존재는 파일이 검색되지 않는다는 것을 나타내는 것으로 분리 환경에 의해 애플리케이션들로부터 숨겨질 수 있다. 특정 링크의 존재 또는 부존재는 각각의 메타데이터 지시자에 대한 메타데이터의 하나의 비트를 나타낼 수 있으며, 또는 메타데이터의 여러 비트를 나타내기 위해 다수의 상태를 취할 수 있는 메타데이터 지시자를 갖는 링크가 될 수 있다. 다른 실시예에서, 파일 시스템이 선택적 파일 스트림(alternate file stream)을 지원하는 경우, 메타데이터의 여러 비트를 나타내는 스트림 크기를 갖는, 선택적 파일 스트림이 메타데이터를 구현하기 위해 생성될 수 있다. 다른 실시예에서, 파일 시스템은 파일 시스템내의 각각의 파일에 대한 일부 3rd 파티 메타데이터를 저장할 수 있는 능력을 직접 제공할 수 있다.

일 실시예에서, 삭제된 파일에 대한 체크를 최적화하기 위해 삭제된 파일 또 는 파일 시스템 요소의 리스트가 유지되고 참조될 수 있다. 이러한 실시예에서, 삭제된 파일이 재생성되면 파일 네임은 삭제된 파일들의 리스트로부터 제거될 수 있다. 리스트가 특정 크기를 넘어서면 리스트로부터 파일 네임이 제거될 수도 있다.

두 가지 경우에서, 유저-범위 리터럴 파일을 오픈하기 위한 요청이 운영 시스템에 전해진다(단계726). 일 실시예에서, 룰은 가상 파일에 대응하는 리터럴 파일이 유저 분리 범위가 아닌 애플리케이션 분리 범위, 시스템 범위, 유저 분리 부-범위 또는 애플리케이션 부-범위와 같은 범위안에 생성되어야만 하는 것을 지정할 수 있다.

리터럴 파일이 성공적으로 오픈되면(단계728), 리터럴 파일이 요청자에게 리턴된다(단계730). 단계 728에서, 요청된 파일이 유저-분리 범위에 현재 존재하지 않는 리터럴 파일의 각각의 조상에 대한 플레이스홀더를 오픈하는데 실패하면(단계732), 리터럴 네임을 이용하는 리터럴 파일을 생성하기 위한 요청은 운영 시스템에 전해지고 그 결과가 요청자에게 리턴된다(단계734).

이러한 실시예는 APIs 또는 오직 호출 당 하나의 레벨의 생성만을 지원하는 기능을 갖는 운영 시스템에 대한 것이다. 호출 당 다수의 레벨에 대한 확장은 당업자에게는 자명할 것이다.

4.1.5 짧은 파일 네임 관리(short filename management)

일부 파일 시스템에서, 각각의 파일에 대해 짧거나 긴 파일 네임들이 주어질 수 있다. 이러한 네임은 전술한 임의의 파일 동작에서 파일에 액세스하는데 이용될 수 있다. 짧고 긴 파일 네임을 갖는 각각의 파일에 대해, 이것은 그 파일에 할당된 짧고 긴 파일 네임 사이의 결합을 불명료하게 생성한다. 이러한 파일 시스템중 일부에서, 짧은 네임들은 파일 시스템에 의해 긴 파일 네임들을 이용하여 생성된 파일들에 자동적으로 할당된다. 짧고 긴 파일 네임 사이의 결합이 분리 환경에 의해 유지되지 않는 경우, 동일한 디렉토리내에서 다른 긴 파일 네임들을 가지나 다른 범위 레벨에 있는 파일들은 동일한 짧은 파일 네임을 가질 수 있고, 그 짧은 네임이 가상 파일에 액세스하는데 이용된다면 불명료함을 초래한다. 선택적으로, 가상 파일이 더 이상 오리지널 짧은 네임을 이용하여 액세스될 수 없다는 것을 의미하는 변경을 위해, 파일이 유저 분리 범위로 카피될 때 짧은 파일 네임이 변화할 수 있다.

이러한 문제점을 방지하기 위해, 변경할 의도로 오픈된 파일 인스턴스를 "높은" 범위에 카피하는 파일 시스템 동작은 먼저 카피된 인스턴스와 결합된 짧고 긴 파일 네임들간의 결합성을 보존한다. 두번째로, 운영 시스템에 의해 할당된 파일 네임들 대신에, 새롭게 생성된 분리 파일들을 위해 유일한(unique) 짧은 네임들이 생성된다. 생성된 짧은 파일 네임들은 동일한 분리 범위내의 동일한 디렉토리내에 또는 "낮은" 분리 범위내의 동일한 디렉토리내에 존재하는 임의의 짧은 파일 네임들과 매치하지 않아야 한다는 조건을 만족해야 한다. 예를 들면, 유저 분리 범위내에 배치된 파일의 인스턴스에 대해 생성된 짧은 파일 네임은 디렉토리의 애플리케이션-범위 인스턴스내에 또는 디렉토리의 시스템-범위 인스턴스내에 존재하는 짧은 파일 네임들과 매치하지 않아야 한다.

도 7A를 참조하면, 새로운 파일을 생성한 이후에 유일한 짧은 파일 네임을 할당하는 실시예의 단계들이 도시된다. 짧은 파일 네임들이 생성되어야만 하는지를 결정하기 위해 체크가 이뤄진다(단계752). 그렇지 않다면, 아무런 짧은 파일 네임도 생성되지 않을 것이라는 것을 나타내는 상태가 리턴된다(단계754). 파일 네임이 파일 시스템에 따른 적법한(legal) 짧은 파일네임인지 여부를 결정하기 위해 체크된다(단계756). 이미 적법한 짧은 파일네임인 경우, 아무런 짧은 네임도 생성되지 않을 것이라는 것을 나타내는 상태가 리턴된다(단계754). 그렇지 않으면, 적절한 짧은 파일네임이 구성된다(단계758).

도 7A를 계속 참조하여, 짧은 파일네임이 생성되어야 하는지 여부를 결정하기 위한 체크가 이뤄진다(단계752). 일 실시예에서, 이 결정은 파일네임이 언급하는 파일을 저장하는 디바이스에 근거하여 이뤄질 수 있다. 다른 실시예에서, 짧은 파일네임의 생성은 특정 범위 또는 부-범위, 또는 전체 분리 환경에 대해 이뤄질 수 있다. 이러한 실시예에서, 레지스트리 설정이 특정 파일네임에 대해 짧은 파일네임이 생성될지 여부를 지정할 수 있다. 생성되어야 하는 짧은 파일네임이 없다면, 짧은 파일네임이 생성되지 않을 것이라는 상태가 리턴된다(단계754).

파일네임이 이미 적법한 짧은 파일네임인지 여부를 결정하기 위해 체크된다(단계756). 일 실시예에서, 적법한 짧은 파일네임은 파일네임에 8 문자(character)까지 그리고 선택적 확장(optional extension)에 3 문자까지를 포함한다. 일 실시예에서, 적법한 짧은 네임은 A-Z, a-z, 0-9, `, ~, !, @, #, $, %, ^, *, (, ), -, _, ', {, 그리고 } 와 같은 적법한 문자들만을 포함한다. 일 실시예에서 리딩 스페이스(leading space), 또는 "." 또는 "."이 하나 이상 내재된 것은 부적법하다. 제 공된 파일네임이 이미 적법한 짧은 파일네임인 경우, 아무런 짧은 파일네임도 생성되지 않을 것이라는 상태가 리턴된다(단계754).

단계756에서, 파일네임이 부적법한 짧은 파일네임이라고 결정되면, 알맞은 짧은 파일네임이 구성된다(단계758). 일 실시예에서, 이것은 짧은 파일네임에 사용하기에 적법하고, 후보 짧은 파일네임을 형성하기 위해 인코딩된 반복 카운트(encoded iteration count)와 결합된, 긴 파일네임의 일부분을 이용하는 것에 의해 이뤄진다. 반복 카운트는 결합된 후보 짧은 파일네임이 알맞을때까지, 즉 동일한 범위내의 동일한 디렉토리내의 또는 낮은 범위내의 동일한 디렉토리내의 임의의 다른 파일에 의해 이용되지 않는 적법한 짧은 파일네임일 때까지 증가된다. 다른 실시예에서, 긴 파일네임은 맹글(mangled)되거나 해시되고 코딩되며, 후보 짧은 파일네임을 형성하기 위해 인코딩된 반복 카운트와 결합된다. 반복 카운트는 결합된 후보 짧은 파일네임이 알맞을때까지, 즉 동일한 범위내의 동일한 디렉토리내의 또는 낮은 범위내의 동일한 디렉토리내의 임의의 다른 파일에 의해 이용되지 않는 적법한 짧은 파일네임일 때까지 증가된다. 이들 실시예에서, 알맞은 후보 짧은 파일네임이 낮은 반복 카운트에서 검색될 가능성을 증가시키기 위해, 범위-지정 스트링이 후보 짧은 파일네임에 합쳐질 수 있다.

4.2 레지스트리 가상화(Registry Virtualization)

전술한 방법 및 장치는 레지스트리 데이터베이스에 대한 액세스를 가상화하는데 이용될 수 있다. 전술한 레지스트리 데이터베이스는 컴퓨터에 물리적으로 부착된 하드웨어에 관한 정보, 즉 선택된 시스템 옵션, 어떻게 컴퓨터 메모리가 설정 되었는지, 애플리케이션-특정 데이터의 다양한 아이템, 그리고 운영 시스템이 시작될때 무슨 애플리케이션 프로그램이 존재하여야 하는지에 대한 정보를 저장한다. 레지스트리 데이터베이스는 일반적으로 레지스트리 값을 위한 장소인 "키(keys)"(170, 172)의 논리적 계층에 조직된다.

4.2.1 레지스트리 오픈 동작

도 8을 참조하면, 전술한 분리 환경에서 레지스트리 키를 오픈하기 위한 실시예의 단계들이 도시되어 있다. 레지스트리 키를 오픈하기 위한 요청이 수신 또는 인터셉트되고, 요청은 분리 환경에 의해 가상 키 네임으로서 처리되는 레지스트리 키 네임을 포함한다(단계802). 요청에서 가상 네임에 적용할 수 있는 프로세싱 룰이 어떻게 레지스트리 키 동작이 처리되는지를 결정한다(단계804). 룰 동작이 "재지정"인 경우(단계806), 요청에서 제공되는 가상 키 네임이 적용할 수 있는 룰에 의해 지정된 리터럴 키 네임으로 매핑된다(단계808). 리터럴 키 네임을 이용하는 리터럴 레지스트리 키를 오픈하기 위한 요청은 운영 시스템에 전해지고 운영 시스템으로부터 결과가 요청자에게 리턴된다(단계810). 룰 동작이 "재지정"이 아니고 "무시"인 경우(단계806), 가상 키 네임이 리터럴 키 네임으로서 식별되고(단계812), 리터럴 레지스트리 키를 오픈하기 위한 요청이 운영시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계810). 단계806에서 룰 동작이 "재지정" 및 "무시"가 아니고 "분리"인 경우, 요청에서 제공되는 가상 키 네임이 유저-범위 후보 키 네임, 즉 적용할 수 있는 유저 분리 범위에 지정되는 가상 키 네임에 대응하는 키 네임에 매핑된다(단계814). 유저-범위 후보 키의 존재 카테고리는 유 저 분리 범위 및 후보 키와 결합된 임의의 메타데이터를 검사하여 결정된다(단계816). 유저 분리 범위내의 후보 키 또는 그 조상 키들 중 하나가 삭제된 것으로 표시되기 때문에, 후보 키가 "존재 부정"을 갖는 경우, 이것은 요청된 가상 키가 존재하지 않는 것으로 알려진다는 것을 의미한다. 이 경우, 요청된 파일이 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계822). 단계816에서 후보 키가 유저 분리 범위에 존재하고 플레이스홀더로서 표시되지 않기 때문에, 후보 키가 "존재 긍정"을 갖는 경우, 요청된 가상 키가 존재하는 것으로 알려진다. 후보 키는 요청에 대한 리터럴 키로 식별되고(단계818), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820). 단계816에서, 후보 키가 존재않거나 또는 후보 키가 존재하나 플레이스홀더 노드로서 표시되기 때문에, 후보 키가 "존재 불분명"을 갖는 경우, 가상 키의 존재 여부를 아직까지 알 수 없다. 이 경우 가상 키 네임에 대응하는 애플리케이션-범위 키 네임이 후보 키 네임으로서 식별된다(단계824). 다시 말하면, 후보 키 네임은 적용할 수 있는 애플리케이션 분리 범위에 특정되는 대응 본래 키 네임에 가상 키 네임을 매핑하는 것에 의해 형성된다. 후보 키의 존재 카테고리는 애플리케이션 분리 범위 및 후보 키와 결합된 임의의 메타데이터를 검사함으로써 결정된다(단계826). 애플리케이션 분리 범위내의 후보 키 또는 그 조상 키의 하나가 삭제된 것으로 표시되기 때문에, 후보 키가 "존재 부정"을 갖는 경우, 이것은 요청된 가상 키가 존재하지 않는 것으로 알려진다는 것을 의미한다. 이 경우, 요청된 파일이 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계822). 단계816에서 후보 키가 유저 분리 범위에 존재하고 플레이스홀더로서 표시되지 않기 때문에, 후보 키가 "존재 긍정"을 갖는 경우, 요청된 가상 키가 존재하는 것으로 알려진다. 이 경우, 요청된 키가 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계822). 단계826에서 후보 키가 유저 분리 범위에 존재하고 플레이스홀더로서 표시되지 않기 때문에, 후보 키가 "존재 긍정"을 갖는 경우, 요청된 가상 키가 존재하는 것으로 알려진다. 오픈 요청이 키를 변경할 의도임을 나타내는지 여부를 결정하기 위해 요청이 체크된다(단계828). 그렇지 않다면, 후보 키는 요청에 대한 리터럴 키로서 식별되고(단계818), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820). 단계828에서, 오픈 요청이 키를 변경할 의도라는 것이 결정되면, 키의 변경이 허용되는지 여부를 결정하기 위해 키와 결합된 승인 데이터가 체크된다(단계836). 그렇지 않다면, 키의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계838). 승인 데이터가 키가 변경될 수 있다는 것을 나타내면, 후보 기는 유저 분리 범위에 카피된다(단계840). 일 실시예에서, 후보 키는 룰 엔진에 의해 정의된 영역에 카피된다. 예를 들면, 룰은 키가 애플리케이션 분리 범위에 카피되도록 지정할 수 있다. 다른 실시예에서, 룰은 키가 카피되어야 하는 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 카피된 인스턴스를 계층에 정확히 배치하기 위해, 분리 범위에서 나타나지 않는 요청된 키의 조상(ancestors)들은 분리 범위에서 플레이스홀더로서 생성된다. 새롭게 카피된 범위의 인스턴스는 리터럴 키로서 식별되고(단계842) 요청은 리터럴 키를 오픈할 것을 명령하고 그 결과는 요청자에게 리턴된다(단계820). 단계826으로 돌아가서, 후보 키가 존재하지 않거나 또는 후보 키가 검색되었으나 플레이스홀더 노드로서 표시되었기 때문에, 후보 키가 존재 불분명을 갖는 경우, 가상 키의 존재 여부는 아직까지 알 수 없다. 이 경우, 가상 키 네임에 대응하는 시스템-범위 키 네임이 후보 키 네임으로서 식별된다(단계830). 다시 말하면, 후보 키 네임이 바로 가상 키 네임이다. 후보 키가 존재하지 않는 경우(단계832), 가상 키가 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계834). 반면에 후보 키가 존재하는 경우(단계832), 오픈 요청이 키를 변경할 의도인지를 결정하기 위해 요청이 체크된다(단계828). 그렇지 않다면, 후보 키는 요청에 대한 리터럴 키로서 식별되고(단계818), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820). 그러나, 단계828에서, 오픈 요청이 키를 변경할 의도인 것으로 결정되면, 키와 결합된 승인 데이터가 키의 변경이 허용되는지를 결정하기 위해 체크된다(단계836). 그렇지 않다면, 키의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계838). 승인 데이터가 키가 변경될 수 있다는 것을 나타내는 경우, 후보 키는 유저 분리 범위로 카피된다(단계840). 일 실시예에서, 후보 키는 룰 엔진에 의해 정의된 영역에 카피된다. 예를 들면, 룰은 키가 애플리케이션 분리 범위에 카피되도록 지정할 수 있다. 다른 실시예에서, 룰은 키가 카피되어야 하는 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 카피된 인스턴스를 계층에 정확히 배치하기 위해, 분리 범위에서 나타나지 않는 요청된 키의 조상(ancestors)들은 분리 범위에서 플레이스홀더로서 생성된다. 새롭게 카피된 범위의 인스턴스는 리터럴 키로서 식별되고(단계842) 요청은 리터럴 키를 오픈할 것을 명령하고 그 결과는 요청자에게 리턴된다(단계820).

도 8을 계속 참조하여, 가상 레지스트리 키를 오픈하기 위한 요청이 수신 또는 인터셉트된다(단계802). 대응하는 리터럴 레지스트리 키는 유저 분리 범위, 애플리케이션 분리 범위 또는 시스템 범위일 수 있으며, 또는 애플리케이션 분리 부-범위 또는 유저 분리 부-범위일 수 있다. 일 실시예에서, 운영 시스템 함수 또는 레지스트리 키를 오픈하기 위한 함수들을 대체하는 함수에 의해 요청이 후킹된다(hooked). 또 다른 실시예에서는 후킹 라이브러리(a hooking dynamically linked library)가 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 레지스트리 키에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 레지스트리 키 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 레지스트리 키 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

요청은 분리 환경에 의해 가상 레지스트리 키 네임으로서 처리되는 레지스트리 키 네임을 포함한다. 레지스트리 키 오픈 요청에 적용할 수 있는 프로세싱 룰이 룰 엔진을 참조하여 결정된다(단계804). 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 레지스트리 키 데이터베이스(flat registry key database)일 수 있다. 일 실시예에서, 요청된 레지스트리 키에 대해 제공된 가상 레지스트리 키 네임은 요청에 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 이 실시예에서, 특정 레지스트리 키에 대해 다수의 룰이 룰 엔진에 존재할 수 있고, 가상 레지스트리 키 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 다른 실시예에서, 프로세스 식별자가 요청에 대해 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 또는 요청을 분리할 수 있다. 도 8에는 파일로 단일 데이터베이스 트랜잭션 또는 단일 룩업(lookup)이 도시되었지만, 룰 룩업은 룰 룩업들의 시리즈로서 수행될 수 있다.

룰 동작이 "재지정"인 경우(단계806), 요청에서 제공되는 가상 레지스트리 키 네임이 적용할 수 있는 룰에 따라 리터럴 레지스트리 키 네임으로 매핑된다(단계808). 리터럴 레지스트리 키 네임을 이용하여 레지스트리 키를 오픈하기 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계810). 예를 들면, "registry_key_1"이라는 레지스트리 키를 오픈하는 요청은 "Different_registry_1"이라흔 리터럴 레지스트리 키의 오픈을 초래할 수 있다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 다른 실시예에서, 파일 시스템 필터 드라이버 기능과 개념적으로 유사한 레지스트리 필터 드라이버 기능이 운영 시스템에 의해 제공될 수 있다. 이 실시예에서, 리터럴 레지스트리 키를 오픈하 는 것은, 결정된 리터럴 키 네임을 이용하는 요청을 리파스(reparse)하기 위해 레지스트리 필터 관리자에게 신호를 보내는 것으로서 가상 키를 오픈하기 위한 오리지널 요청에 응답하는 것에 의해 이뤄진다. 룰 동작이 "무시"인 경우(단계806), 리터럴 레지스트리 키 네임이 바로 가상 레지스트리 키 네임으로 결정되고(단계812) 리터럴 레지스트리 키를 오픈하기 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계810). 예를 들면, "registry_key_1"이라는 레지스트리 키를 오픈하기 위한 요청은 "registry_key_1"이라는 리터럴 레지스트리 키의 오픈을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 다른 실시예에서, 이것은 일반적인 방식으로 변경되지 않은 오리지널 요청을 계속 처리하도록 레지스트리 필터 관리자에게 신호를 보내는 것에 의해 이뤄진다.

단계806에서, 룰 동작이 "분리"인 경우, 가상 레지스트리 키 네임에 대응하는 유저-범위 레지스트리 키 네임이 후보 레지스트리 키 네임으로서 식별된다(단계814). 다시 말하면, 후보 레지스트리 키 네임은 적용할 수 있는 유저 분리 범위에 특정되는 대응 본래 레지스트리 키 네임에 가상 레지스트리 키 네임을 매핑하는 것에 의해 형성된다. 예를 들면, "registry_key_1"이라는 레지스트리 키를 오픈하기 위한 요청은 "Isolated_UserScope_UserA_registry_key_1"이라는 리터럴 레지스트리 키의 오픈을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진 다. 다른 실시예에서, 리터럴 레지스트리 키를 오픈하는 것은, 결정된 리터럴 키 네임을 이용하는 요청을 리파스(reparse)하기 위해 레지스트리 필터 관리자에게 신호를 보내는 것으로서 가상 키를 오픈하기 위한 오리지널 요청에 응답하는 것에 의해 이뤄진다.

일 실시예에서, 요청된 가상 레지스트리 키를 분리하기 위하여 형성된 리터럴 네임은 수신된 가상 레지스트리 키 네임과 범위-지정 식별자(scope-specific identifier)에 근거할 수 있다. 범위-지정 식별자는 애플리케이션 분리 범위, 유저 분리 범위, 세션 분리 범위, 애플리케이션 분리 부-범위, 유저 분리 부-범위, 또는 이들의 결합과 결합된 식별자일 수 있다. 범위-지정 식별자는 요청에 수신된 가상 네임을 "맹글(mangle)"하기 위해 이용된다.

다른 실시예에서, 유저 분리 범위 또는 부-범위는 그 아래 유저 분리 범위내에 존재하는 모든 키가 저장되는 레지스트리 키일 수 있다. 이 실시예에서, 유저 분리 키 아래의 키 계층은 요청된 리소스의 경로를 반영한다. 다시 말하면, 리터럴 키 경로는 가상 키 경로를 유저 분리 범위에 매핑함으로써 형성된다. 예를 들면, 요청된 키가 HKLM＼Software＼Citrix＼MyKey 이고 유저 분리 범위 키가 HKCU＼Software＼UserScope＼인 경우, 유저-범위 리터럴 키 네임으로의 경로는 HKCU＼Software＼UserScope＼HKLM＼Software＼Citrix＼MyKey 일 수 있다. 다른 실시예에서, 유저-범위 리터럴에 대한 경로는 본래 명명 룰에 정의될 수 있다. 예를 들면, 유저-범위 리터럴 키 네임으로의 경로는 HKCU＼Software＼UserScope＼Registry＼Machine＼Software＼Citrix＼MyKey 일 수 있다. 유저-범위 키 모두는 유일하게 선 택된 네임을 갖는 하나의 키 아래에 저장될 수 있고 데이터베이스가 요청된 키 네임과 유저 분리 키에 저장된 대응 리터럴 키의 네임 사이의 매핑을 저장하는데 이용될 수 있다. 리터럴 키의 컨텐츠는 데이터베이스 또는 파일 저장소에 저장될 수 있다.

후보 키의 존재 카테고리는 유저 분리 범위 및 후보 키와 결합된 메타데이터를 검사함으로써 결정된다(단계816). 유저 분리 범위내의 후보 키 또는 그 조상 키중 하나가 삭제된 것으로 표시되기 때문에, 후보 키가 "존재 부정"을 갖는 경우, 이것은 요청된 가상 키가 존재하지 않는 것으로 알려진다는 것을 의미한다. 이 경우, 요청된 키가 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계822).

일 실시예에서, 리터럴 레지스트리 키 네임은 가상화된 레지스트리 키가 이미 삭제되었다는 것을 나타내는 메타데이터와 결합될 수 있다. 일 실시예에서, 레지스트리 APIs의 오리지널 애플리케이션 사용으로부터 숨겨진 값의 존재를 가지고, 레지스트리 키에 관한 메타데이터는 그 키에 의해 유지되는 특정 값(distinguished value)에 저장될 수 있다. 일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 레지스트리 키에 관한 소량의 메타데이터가 바로 리터럴 키 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이더 지시자는 메타데이터의 하나 또는 여러개의 비트를 나타내거나 또는 인코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 키 네임의 가변에 대한 가상 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 키 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 메타데이터 지시자는 서브키(subkey) 네임에 인코딩되거나 또는 키 네임 그 자체 대신에 레지스트리 값 네임으로 인코딩될 수 있다. 레지스트리 키 시스템은 각각의 키에 대한 일부 3rd 파티 메타데이터를 저장하는 능력을 직접 제공할 수 있다. 일 실시예에서, 메타데이터는 데이터베이스 또는 레지스트리 데이터베이스와 분리된 다른 저장소에 저장된다. 일 실시예에서, 개별적 부-범위는 삭제된 것으로 표시된 키들을 저장하는데 이용될 수 있다. 부-범위내의 키의 존재는 그 키가 삭제된 것으로 표시된 것을 나타낸다.

이러한 실시예들에서, 삭제된 키 또는 키 시스템 요소의 리스트는 삭제된 키에 대한 체크를 최적화하기 위해 유지되고 참조된다. 삭제된 키가 재생성된 경우 삭제된 키의 리스트로부터 그 키 네임은 제거된다. 다른 실시예에서, 리스트가 특정 크기를 넘어서면 리스트로부터 키 네임이 제거될 수도 있다.

단계816에서, 후보 키가 유저 분리 범위내에 존재하고 플레이스홀더 노드로서 표시되지 않기 때문에, 후보 키가 "존재 긍정"을 갖는 경우, 요청된 가상 키가 존재하는 것으로 알려진다. 후보 키는 요청에 대한 리터럴 키로서 식별되고(단계818), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820).

단계 816에서, 후보 키가 존재하지 않거나, 또는 후보 키가 존재하나 플레이스홀더 노드로서 표시되기 때문에, 후보 키가 "존재 불분명"을 갖는 경우, 가상 키 의 존재 여부를 아직까지는 알 수 없다. 이 경우, 가상 키 네임에 대응하는 애플리케이션-범위 키 네임이 후보 키 네임으로서 식별된다(단계824). 다시 말하면, 후보 키 네임은 적용할 수 있는 애플리케이션 분리 범위에 특정하는 대응 본래 키 네임에 가상 키 네임을 매핑하는 것에 의해 형성된다. 후보 키의 존재 카테고리는 애플리케이션 분리 범위 및 후보 키와 결합된 임의의 메타데이터를 검사함으로써 결정된다(단계826).

애플리케이션 분리 범위내의 후보 키 또는 그 조상 키중 하나가 삭제된 것으로 표시되기 때문에, 애플리케이션-범위 후보 키가 "존재 부정"을 갖는 경우, 이것은 요청된 가상 키가 존재하지 않는 것으로 알려진다는 것을 의미한다. 이 경우, 요청된 키가 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계822).

단계826에서, 후보 키가 애플리케이션 분리 범위에 존재하고 플레이스홀더 노드로서 표시된지 않기 때문에, 후보 키가 "존재 긍정"을 갖는 것으로 결정되면, 요청된 가상 키가 존재하는 것으로 알려진다. 오픈 요청이 키를 변경할 의도임을 나타내는지 결정하기 위해 요청이 체크되고(단계828), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820).

단계828에서, 오픈 요청이 키를 변경할 의도인 것으로 결정되면, 키의 변경이 허용되는지 결정하기 위해 키와 결합된 승인 데이터가 체크된다(단계836). 일 실시예에서, 승인 데이터는 애플리케이션-범위 후보 키와 결합된다. 이러한 실시예에서, 승인 데이터는 룰 엔진에 또는 후보 키와 결합된 메타데이터에 저장된다. 다 른 실시예에서, 후보 키와 결합된 승인 데이터는 운영 시스템에 의해 제공된다. 또한, 룰 엔진은 분리 환경에 가상화된 리소스 카피에 대해 본래 승인 데이터를 따르거나(obey) 또는 우선하도록(override) 명령하는 구성 셋팅을 포함할 수 있다. 일실시예에서, 룰은 시스템 범위 또는 애플리케이션 분리 범위 또는 부-범위, 또는 유저 분리 범위 또는 부-범위와 같이 변경이 일어나는 범위내에서 일부 가상 리소스들을 지정할 수 있다. 일 실시예에서, 룰 엔진은 계층 또는 액세스된 리소스의 타입에 근거하여 가상화된 본래 리소스의 부집합(subsets)에 적용하는 구성 셋팅을 지정할 수 있다. 이러한 실시예에서, 구성 셋팅은 각각의 본래 리소스에 대해 지정될 수 있다.

후보 키와 결합된 승인 데이터가 변경되지 않을 것임을 나타내는 경우, 키의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계838). 승인 데이터가 키가 변경될 것임을 나타내는 경우, 후보 키는 유저 분리 범위로 카피된다(단계840). 일 실시예에서, 후보 키는 룰 엔진에 의해 정의되는 영역에 카피된다. 예를 들면, 룰은 키가 다른 애플리케이션 분리 범위로 카피되도록 지정할 수 있다. 다른 실시예에서, 룰 키가 카피되어야 하는 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 키가 카피되는 분리 범위에 나타나지 않는 요청된 키의 임의의 조상은 카피된 인스턴스를 계층에 정확히 배치시키기 위하여 분리 범위에서 플레이스홀더로서 생성된다.

일 실시예에서, 분리 범위에 카피되는 키와 결합된 메타데이터는 키가 카피된 날짜와 시간을 식별한다. 이러한 정보는 카피된 키의 인스턴스와 결합된 시간 스탬프(stamp)와 키의 오리지널 인스턴스 또는 낮은 분리 범위에 배치된 키의 다른 인스턴스의 가장 최근 변경에 대한 시간 스탬프와 비교하는데 이용될 수 있다. 이 실시예에서, 키의 오리지널 인스턴스, 또는 낮은 분리 범위에 배치된 키의 인스턴스가 카피된 키의 시간 스탬프보다 최근의 시간 스탬프와 결합된 경우, 그 키는 후보 키를 업데이트하기 위해 분리 범위에 카피될 수 있다. 다른 실시예에서, 분리 범위내의 키 카피는 카피된 오리지널 키를 포함하는 범위를 식별하는 메타데이터와 결합될 수 있다.

또 다른 실시예에서, 변경할 의도로 오픈되었기 때문에 분리 범위에 카피된 키는 실제로 변경되었는지를 결정하기 위해 모니터될 수 있다. 일 실시예에서, 카피된 키는 키가 실제로 변경된 때 정해지는 플래그(flag)와 결합될 수 있다. 이 실시예에서, 카피된 키가 실제로 변경되지 않은 경우, 카피된 키와 결합된 임의의 플레이스홀더 노드가 될 수 있을뿐 아니라, 그것이 닫힌 이후 그것이 카피된 범위로부터 제거될 수도 있다.

범위 인스턴스는 리터럴 키로서 식별되고(단계842) 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820).

단계826으로 돌아가서, 후보 키가 존재하지 않거나 또는 후보 키가 검새되나 플레이스홀더 노드로서 표시되기 때문에, 후보 키가 존재 불분명을 갖는 경우, 가상 키의 존재 여부를 아직까지는 알 수 없다. 이 경우, 가상 키 네임에 대응하는 시스템-범위 키 네임이 후보 키 네임으로서 식별된다(단계830). 다시 말하면, 후보 키 네임이 바로 가상 키 네임이다.

후보 키가 존재하지 않는 경우(단계832), 카상 키가 검색되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계834). 후보 키가 존재하는 경우(단계832), 오픈 요청이 키를 변경할 의도임을 나타내는지를 결정하기 위하여 요청이 체크된다(단계828).

상기에서, 후보 키가 그것을 변경할 의도없이 오픈된 경우, 시스템-범위 후보 키가 요청에대한 리터럴 키소서 식별되며(단계818), 요청은 리터럴 키를 오픈하도록 명령하고 그 결과가 요청자에게 리턴된다(단계820). 그러나, 단계828에서, 요픈 요청이 키를 변경할 의도로 결정된 경우, 키의 변경이 허용되는지를 결정하기 위해 키와 결합된 승인 데이터가 체크된다(단계836). 일 실시예에서, 승인 데이터는 애플리케이션-범위 후보 키와 결합된다. 이 실시예에서, 승인 데이터는 룰 엔진에 또는 후보 키와 결합된 메타데이터에 저장된다. 다른 실시예에서, 후보 키와 결합된 승인 데이터는 운영 시스템에 의해 제공된다. 또한, 룰 엔진은 분리 환경에 가상화된 리소스 카피들에 대해 본래 승인 데이터를 따르거나(obey) 또는 우선하도록(override) 명령하는 구성 셋팅을 포함할 수 있다. 일실시예에서, 룰은 시스템 범위 또는 애플리케이션 분리 범위 또는 부-범위, 또는 유저 분리 범위 또는 부-범위와 같이 변경이 일어나는 범위내에서 일부 가상 리소스들을 지정할 수 있다. 일 실시예에서, 룰 엔진은 계층 또는 액세스된 리소스의 타입에 근거하여 가상화된 본래 리소스의 부집합(subsets)에 적용하는 구성 셋팅을 지정할 수 있다. 이러한 실시예에서, 구성 셋팅은 각각의 본래 리소스에 대해 지정될 수 있다.

시스템-범위 후보 키와 결합된 승인 데이터가 키가 변경되지 않을 것임을 나 타내는 경우, 키의 변경이 허용되지 않는다는 것을 나타내는 에러 상태가 요청자에게 리턴된다(단계838). 승인 데이터가 키가 변경될 것임을 나타내는 경우, 후보 키가 유저 분리 범위로 카피된다(단계840). 일 실시예에서, 후보 키는 룰 엔진에 의해 정의되는 영역으로 카피된다. 예를 들면, 룰은 키가 애플리케이션 분리 범위로 카피되도록 또는 시스템 범위에 남도록 지정할 수 있다. 다른 실시예에서, 룰은 키가 카피되어야 하는 특정 애플리케이션 분리 부-범위 또는 유저 분리 부-범위를 지정할 수 있다. 분리 범위에 나타나지 않는 요청된 키의 임의의 조상들은 계층에 카피된 인스턴스를 정확히 배치시키기 위하여 분리 범위에서 플레이스홀더로서 생성된다.

일 실시예에서, 키와 결합된 메타데이터가 분리 범위에 카피되고 키가 카피된 날짜 및 시간을 식별한다. 이러한 정보는 카피된 키의 인스턴스와 결합된 시간 스탬프(stamp)와 키의 오리지널 인스턴스 또는 낮은 분리 범위에 배치된 키의 다른 인스턴스의 가장 최근 변경에 대한 시간 스탬프와 비교하는데 이용될 수 있다. 이 실시예에서, 키의 오리지널 인스턴스, 또는 낮은 분리 범위에 배치된 키의 인스턴스가 카피된 키의 시간 스탬프보다 최근의 시간 스탬프와 결합된 경우, 그 키는 후보 키를 업데이트하기 위해 분리 범위에 카피될 수 있다. 다른 실시예에서, 분리 범위내의 키 카피는 카피된 오리지널 키를 포함하는 범위를 식별하는 메타데이터와 결합될 수 있다.

또 다른 실시예에서, 변경할 의도로 오픈되었기 때문에 분리 범위에 카피된 키는 실제로 변경되었는지를 결정하기 위해 모니터될 수 있다. 일 실시예에서, 카 피된 키는 키가 실제로 변경된 때 정해지는 플래그(flag)와 결합될 수 있다. 이 실시예에서, 카피된 키가 실제로 변경되지 않은 경우, 카피된 키와 결합된 임의의 플레이스홀더 노드가 될 수 있을뿐 아니라, 그것이 닫힌 이후 그것이 카피된 범위로부터 제거될 수도 있다. 이 실시예에서, 키가 실제로 변경된 때에만 키가 적절한 분리 범위에 카피된다.

범위 인스턴스는 리터럴 키로서 식별되고(단계842) 요청은 리터럴 키를 오픈하도록 명령하고 그 결과는 요청자에게 리턴된다(단계820).

4.2.4 레지스트리 삭제 동작(registry delete operations)

도 9를 참조하면, 레지스트리 키를 삭제하는 실시예의 단계들이 도시되어 있다. 키가 삭제되기 이전에, 키는 먼저 삭제 액세스에 의해 성공적으로 오픈되어야만 한다(단계901). 키가 성공적으로 오픈되지 않으면, 에러가 리턴된다(단계916). 가상 키가 성공적으로 오픈된 경우, 가상화된 레지스트리 키를 삭제하는 요청이 수신 또는 인터셉트되고, 요청은 가상 키에 대응하는 리터럴 키를 처리하는 것을 포함한다(단계902). 룰은 어떻게 레지스트리 키 동작이 처리되는지 결정한다(단계904). 삭제될 키에 적용할 수 있는 룰 외에 직접 서브키(immediate subkey)에 적용할 수 있는 임의의 다른 룰도 검사된다(단계905). 검색된 직접 서브키에 적용할 수 있는 각각의 룰에 따라, 가상 서브키를 오픈하기 위한 시도가 이뤄지며, 가상 서브키의 네임은 단계905에서 검색된 룰에서 주어진 네임에 의해 지정된다. 단계905에서 검색된 룰중 하나에 대응하는 네임을 갖는 서브키가 성공적으로 오픈된 경우(단계906), 가상 키는 서브키를 갖는 것으로 고려되며, 이것은 삭제될 수 없다는 것을 의미하고, 따라서 에러가 리턴된다(단계907).

단계905에서 추출된 모든 가상 키 네임을 오픈하려는 시도가 이뤄진 이후에, 가상 키가 존재하는 것으로 검색되지 않은 경우, 또 다른 검사가 요구된다. 룰 동작이 "분리"가 아니고, "재지정" 또는 "무시"인 경우(단계908), 리터럴 레지스트리 키를 삭제하기 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계911). 단계908에서 결정된 룰 동작이 "분리"인 경우, 가상화된 레지스트리 키가 임의의 가상 서브키를 포함하는지 결정한다(단계914). 가상화된 키가 가상 서브키를 갖는 경우, 삭제는 계속될 수 없고, 키가 삭제되지 않았다는 것을 나타내는 에러가 리턴된다(단계920). 가상화된 키가 가상 서브키를 갖지 않는 경우, 다른 범위 레벨내의 동일한 가상 네임으로 범위 키(scoped key)를 마스크(mask)하는지 여부를 결정하기 위해 가상 키에 대응하는 리터럴 키가 검사된다(단계922). 동일한 가상 네임을 가지며 다른 범위에 있는 키를 가상 키에 대응하는 리터럴 키가 마스크하지 않는 경우, 가상 키에 대응하는 리터럴 키가 삭제되고, 그 결과가 리턴된다(단계926). 동일한 가상 네임을 가지며 다른 범위에 있는 키를 가상 키에 대응하는 리터럴 키가 마스크하는 경우, 가상 키에 대응하는 리터럴 키는 그것이 삭제되었다는 것을 나타내는 값으로 표시되며, 그 결과가 호출자에게 리턴된다(단계924).

도 9를 계속 참조하여, 키를 삭제하기 위해서는 먼저 삭제 액세스로 그것이 오픈되어야만 한다(단계901). 키를 오픈하는 요청은 분리 환경에 의해 가상 네임으로서 처리되는 키의 네임을 포함한다. 가상화된 키의 오픈은 4.2.1 섹션에 상술된 바와 같이 이뤄진다. 가상화된 오픈 동작이 실패하면, 에러가 요청자에게 리턴된다(단계916). 가상화된 오픈 동작이 성공되면, 가상 키에 대응하는 리터럴 키의 핸들(handle)이 요청자에게 리턴된다. 다음으로, 단계901에서 오픈된 레지스트리 키를 삭제하는 요청이 수신 또는 인터셉트된다(단계902). 오픈된 리터럴 레지스트리 키는 유저 분리 범위, 애플리케이션 분리 범위, 시스템 범위 또는 일부 적용할 수 있는 분리 부-범위일 수 있다. 일 실시예에서, 운영 시스템 함수 또는 레지스트리 키를 삭제하기 위한 함수들을 대체하는 함수에 의해 삭제 요청이 후킹된다. 다른 실시예에서, 후킹 라이브러리가 삭제 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 레지스트리 키에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 다른 실시예에서, 파일 시스템 필터 드라이버 기능과 개념적으로 유사한 레지스트리 필터 드라이버 기능이 운영 시스템에 의해 제공될 수 있다. 당업자라면 레지스트리 동작을 수행하기 위해 운영 시스템이 요청을 전하도록 레지스트리 필터 드라이버를 생성할 수 있고 따라서 레지스트리 동작 요청을 인터셉트하는 메카니즘을 제공한다. 개별적 운영 시스템 함수가 각각의 레지스트리 키 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 레지스트리 키 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

삭제 요청은 리터럴 키 핸들을 포함한다. 핸들과 결합된 가상 키 네임은 핸들과 결합된 리터럴 네임에 대한 운영 시스템으로의 질의(query)에 의해 결정된다. 룰 엔진이 리터럴 네임과 결합된 가상 네임을 결정하는데 참조된다. 어떻게 레지스트리 키 동작이 처리되는지 결정하는 룰은 룰 엔진을 참조하여 얻어진다. 일 실시예에서, 삭제될 가상 레지스트리 키의 가상 키 네임은 요청에 적용할 수 있는 룰을 룰 엔진에 배치시키는데 이용된다. 이러한 실시예에서, 특정 레지스트리 키에 대해 룰 엔진에 다수의 룰이 존재할 수 있고, 가상 가상 키 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 레지스트리 키 데이터베이스일 수 있다. 일 실시예에서, 요청에서의 가상 키에 대응하는 가상 키 네임은 그 요청에 적용하는 하나 이상의 룰을 배치시키기 위해 룰 엔진의 인덱스로서 이용된다. 일 실시예에서, 프로세스 식별자가 요청에 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나 요청을 분리할 수 있다. 룰 룩업은 결정의 시리즈로서 발생할 수 있으며, 또는 룰 룩업은 단일 데이터베이스 트랜잭션으로서 발생할 수도 있다.

삭제될 키의 가상 네임은 가상 키의 임의의 직접적인 자손 키에 적용할 수 있는(그러나 삭제될 가상 키에는 적용할 수 없는) 룰의 집합을 배치시키기 위해 룰 엔진을 참조하는데 이용된다. 이러한 룰의 집합은 자손 키의 존재 여부에 관계없이 배치된다(단계905). 직접적인 자손 키에 적용할 수 있는 이러한 룰의 집합이 비어 있지 않은 경우, 이들 룰 각각의 가상 네임이 차례로 추출된다(extracted)(단계906). 임의의 가상 네임에 대응하는 임의의 가상 키가 성공적으로 오픈된 경우, 이것은 가상 서브키가 존재한다는 것을 의미한다. 이것은 가상 자손이 존재함에 따라 가상 키가 삭제될 수 없다는 것을 의미하며, 따라서 에러가 리턴된다(단계907). 가상 키의 직접 자손에 적용할 수 있는 룰 집합의 모두를 검사한 이후(단계905), 아무런 가상 서브키도 존재하지 않는 것으로 검색되면, 삭제가 계속될 수 있다. 예를 들면, "key_1"이라는 가상 네임을 갖는 키는 자손 "key1＼subkey_1" 및 "key1＼subkey_2"을 가질 수 있다. 이 단계에서, "key1＼subkey_1" 및 "key1＼subkey_2"의 가상화된 오픈을 하려는 시도가 이뤄진다. 이들 가상 서브키들이 성공적으로 오픈된 경우, 삭제는 실패할 것이고 에러가 리턴된다(단계907). 이들 가상 서브키들이 모두 존재하지 않을 경우에만 삭제가 계속된다.

룰 동작이 "분리"가 아니고 "재지정" 또는 "무시"인 경우(단계908), 리터럴 키 핸들을 이용하는 리터럴 레지스트리 키 삭제를 위한 요청이 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계911). 리터럴 키가 리터럴 서브키를 포함하는 경우에는 이러한 요청은 실패할 것이다. 일 실시예에서, 리터럴 레지스트리 키 삭제 요청은 후킹된 함수의 오리지널 버전을 호출하고 리터럴 키 핸들을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 레지스트리 필터 드라이버를 이용하는 실시예에서, 이것은 요청에 대해 일반적인 프로세싱을 수행하도록 운영 시스템에 신호를 보내는 완성 상태(completion status)로 요청에 응답하는 것으로 이뤄진다. 일 실시예에서, 리터럴 레지스트리 키와 결합된 운영 시스템 승인은 그 삭제를 방지할 수 있다. 이 실시예에서, 가상 레지스트리 키가 삭제될 수 없다는 에러 메시지가 리턴된다.

단계908에서 결정된 룰 동작이 "분리"인 경우, 가상화된 레지스트리 키가 임의의 가상 서브키를 갖는지 여부가 결정된다(단계914). 요청된 가상 레지스트리 키가 가상 서브키를 갖는 경우, 가상 키는 삭제될 수 없고, 에러가 호출자에게 리턴된다(단계920).

요청된 가상 레지스트리 키가 가상 서브키를 포함하지 않는 경우, 가상 기는 삭제될 수 있다. 다음 동작은 삭제될 리터럴 키를 포함하는 범위에 따라 다르다. 예를 들면, 가상 레지스트리 키를 삭제하는 요청은 애플리케이션-범위 리터럴 키의 삭제를 초래할 수 있다. 리터럴 키를 포함하는 범위는 리터럴 키에 대한 전체 경로를 갖는 룰 엔진을 참조하여 결정될 수 있다.

삭제될 리터럴 키가 특정 범위에서 검색되고, 그 리터럴 키가 다른 범위내의 동일한 가상 네임의 다른 키를 마스크하면, 삭제될 리터럴 키는 삭제되는 것으로 표시되고, 그 결과가 요청자에게 리턴된다(단계924). 예를 들면, 동일한 가상 네임을 갖는 대응 애플리케이션-범위 키 또는 동일한 가상 네임을 갖는 대응 시스템-범위 키가 "존재 긍정"을 갖는 경우, 즉 그 범위내에 존재하고 플레이스홀더로서 표시되지 않는 경우, 유저-범위 리터럴 키에 대응하는 가상 키는 다른 범위의 키를 마스크하는 것으로 고려된다. 이와 유사하게, 시스템-범위 키가 존재하고 삭제되는 것으로 고려되지 않는 경우, 애플리케이션-범위 키는 동일한 가상 네임에 대응하는 시스템-범위 키를 마스크하는 것으로 고려된다.

삭제될 리터럴 키가 다른 범위내의 동일한 가상 네임의 다른 키를 마스크하지 않는 경우, 삭제될 리터럴 키는 실제로 삭제되고 그 결과가 리턴된다(단계926).

일 실시예에서, 리터럴 레지스트리 키와 결합된 운영 시스템 승인은 리터럴 레지스트리 키의 삭제를 방지할 수 있다. 이 실시예에서, 가상 레지스트리 키가 삭제될 수 없다는 에러 메시지가 리턴된다.

일 실시예에서, 리터럴 레지스트리 키는 가상화된 레지스트리 키가 이미 삭제되었다는 것을 나타내는 메타데이터와 결합될 수 있다. 일 실시예에서, 레지스트리 APIs의 오리지널 애플리케이션 사용으로부터 숨겨진 값의 존재를 가지고, 레지스트리 키에 관한 메타데이터는 그 키에 의해 유지되는 특정 값(distinguished value)에 저장될 수 있다. 일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 레지스트리 키에 관한 소량의 메타데이터가 바로 리터럴 키 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이더 지시자는 메타데이터의 하나 또는 여러개의 비트를 나타내거나 또는 인코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 키 네임의 가변에 대한 가상 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 키 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 메타데이터 지시자는 서브키(subkey) 네임에 인코딩되거나 또는 키 네임 그 자체 대신에 레지스트리 값 네임으로 인코딩될 수 있다. 레지스트리 키 시스템은 각각의 키에 대한 일부 3rd 파티 메타데이터를 저장하는 능력을 직접 제공할 수 있다. 일 실시예에서, 메 타데이터는 데이터베이스 또는 레지스트리 데이터베이스와 분리된 다른 저장소에 저장된다. 일 실시예에서, 개별적 부-범위는 삭제된 것으로 표시된 키들을 저장하는데 이용될 수 있다. 부-범위내의 키의 존재는 그 키가 삭제된 것으로 표시된 것을 나타낸다.

이러한 실시예들에서, 삭제된 키 또는 키 시스템 요소의 리스트는 삭제된 키에 대한 체크를 최적화하기 위해 유지되고 참조된다. 삭제된 키가 재생성된 경우 삭제된 키의 리스트로부터 그 키 네임은 제거된다. 다른 실시예에서, 리스트가 특정 크기를 넘어서면 리스트로부터 키 네임이 제거될 수도 있다.

일 실시예에서, 동일한 범위내의 리터럴 레지스트리 키의 조상은 그것이 삭제되었다는 것을 또는 삭제될 것임을 나타내는 메타데이터와 결합된다. 이 실시예에서, 가상화된 레지스트리 키가 존재하지 않는다는 것을 나타내는 에러 메시지가 리턴된다. 이 실시예에서, 삭제된 레지스트리 키 또는 레지스트리 키 시스템 요소의 리스트는 삭제된 레지스트리 키에 대한 체크를 최적화 하기 위해 유지되고 참조될 수 있다.

4.2.3 레지스트리 열거 동작(registry enumerate operations)

도 10을 참조하면, 가상화된 환경에서 키를 열거하는 실시예의 단계들이 도시되어 있다. 키가 열거되기 이전에, 먼저 열거 액세스로 키가 성공적으로 오픈되어야만 한다(단계1001). 키가 성공적으로 오픈되지 않으면, 에러가 리턴된다(단계1040). 가상 키가 성공적으로 오픈되면, 열거에 대한 요청이 수신 또는 인터셉트되고, 요청은 가상 키에 대응하는 리터럴 키에 대한 핸들을 포함한다(단계1002).

핸들에 대응하는 가상 키 네임이 결정되고, 열거 요청에서 지정된 키에 대한 룰을 결정하기 위해 룰 엔진이 참조된다(단계1004). 룰 동작이 "분리" 동작을 지정하지 않고 "무시" 또는 "재지정"을 지정하는 경우, 리터럴 키 핸들에 의해 식별된 리터럴 키가 열거되고, 열거 결과가 작업 데이터 저장소에 저장되며(단계1012), 이후의 단계1030은 이하에서 설명된다.

룰 동작이 "분리"를 지정하는 경우, 먼저 시스템 범위가 열거된다; 즉, 후보 키 네임이 바로 가상 키 네임이며, 후보 키가 존재하면 그것이 열거된다. 열거 결과는 작업 데이터 저장소에 저장된다. 후보 키가 존재하지 않는 경우, 이 단계에서 작업 데이터 저장소는 비어있다(단계1014). 다음으로, 후보 키가 가상 키의 애플리케이션-범위 인스턴스로서 식별되고, 후보 키의 존재 카테고리가 결정된다(단계1015). 후보 키가 "존재 부정"을 갖는 경우, 즉 범위내에서 그것 또는 그 조상중 하나가 삭제된 것으로 표시된 경우, 이 범위내에서 그것은 삭제될 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계1042). 후보 키가 존재 부정을 갖지 않는 경우, 후보 키가 열거되고 얻어진 임의의 열거 결과기 작업 데이터 저장소로 합쳐진다. 특히, 열거에서 각각의 서브키에 대해, 그것의 존재 카테고리가 결정된다. 존재 부정을 갖는 서브키는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 서브키, 즉 존재하며 플레이스홀더로서 표시되지 않고 삭제된 것으로 표시되지 않은 서브키가 작업 데이터 저장소에 추가되며, 작업 데이터 저장소에 이미 대응하는 서브키가 존재하는 경우 이를 대체한다(단계1016).

두 경우에서, 후보 키는 가상 키의 유저-범위 인스턴스로서 식별되며, 후보 키의 존재 카테고리가 결정된다(단계1017). 후보 키가 "존재 부정"을 갖는 경우, 즉 범위내의 그것 또는 그 조상중 하나가 삭제된 것으로 표시된 경우, 이 범위내에서 그것은 삭제될 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계1044). 후보 키가 존재 부정을 갖지 않는 경우, 후보 키가 열거되고 얻어진 임의의 열거 결과가 작업 데이터 저장소로 합쳐진다. 특히, 열거에서 각각의 서브키에 대해, 그 존재 카테고리가 결정된다. 존재 부정을 갖는 서브키는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 서브키, 즉 존재하며 플레이스홀더로서 표시되지 않고 삭제된 것으로 표시되지 않은 서브키가 작업 데이터 저장소에 추가되며, 작업 데이터 저장소에 이미 대응하는 서브키가 존재하는 경우 이를 대체하며(단계1016), 이후의 단계1030은 이하에서 설명된다.

세가지 모든 룰의 타입에 대해서, 단계1030이 실행된다. 요청된 가상 키 네임의 직접적인 자손과는 매치하나 요청된 가상 키 네임 자체와는 매치하지 않는 룰의 집합을 검색하기 위해 룰 엔진에 질의한다(단계1030). 집합내의 각각의 룰에 대해, 룰에서의 네임과 매치하는 가상 자손의 존재가 결정된다. 자손이 존재 긍정을 갖는 경우, 그것은 작업 데이터 저장소에 추가되며, 이미 동일한 네임의 자손을 대체한다. 자손이 존재 부정을 갖는 경우, 자손에 대응하는 작업 데이터 저장소내의 엔트리가 제거된다(단계1032). 마지막으로, 구성된 열거가 작업 데이터 저장소로부터 요청자에게 리턴된다(단계1020).

도 10을 계속 참조하면, 키를 열거하기 위해서는 먼저 열거 액세스로 오픈되어야만 한다(1001). 키를 오픈하기 위한 요청은 분리 환경에 의해 가상 네임으로서 처리되는 키의 네임을 포함한다. 가상화된 키 오픈은 섹션 4.2.1에서 상술된 바와 같이 수행된다. 가상화된 오픈 동작이 실패하면, 에러가 요청자에게 리턴된다(단계1040). 가상화된 오픈 동작이 성공하면, 가상 키에 대응하는 리터럴 키의 핸들이 요청자에게 리턴된다. 단계1001에서 오픈된 레지스트리 키를 열거하는 요청이 수신 또는 인터셉트된다(단계1002). 오픈된 리터럴 레지스트리 키는 유저 분리 범위, 애플리케이션 분리 범위, 시스템 범위, 또는 적용할 수 있는 분리 부-범위일 수 있다. 일 실시예에서, 운영 시스템 함수 또는 레지스트리 키를 열거하기 위한 함수들을 대체하는 함수에 의해 열거 요청이 후킹된다. 다른 실시예에서, 후킹 라이브러리가 열거 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 레지스트리 키에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 다른 실시예에서, 파일 시스템 필터 드라이버 기능과 개념적으로 유사한 레지스트리 필터 드라이버 기능이 운영 시스템에 의해 제공될 수 있다. 당업자라면 레지스트리 동작을 수행하기 위해 운영 시스템이 요청을 전하도록 레지스트리 필터 드라이버를 생성할 수 있고 따라서 레지스트리 동작 요청을 인터셉트하는 메카니즘을 제공한다. 개별적 운영 시스템 함수가 각각의 레지스트리 키 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 레지스트리 키 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

열거 요청은 리터럴 키 핸들을 포함한다. 핸들과 결합된 가상 키 네임은 핸들과 결합된 리터럴 네임에 대해 운영 시스템에 질의하는 것에 의해 결정된다. 룰 엔진이 리터럴 네임과 결합된 가상 네임을 결정하기 위해 참조된다.

어떻게 레지스트리 키 동작이 처리되는지 결정하는 룰이 룰 엔진을 참조하여 얻어진다. 일 실시예에서, 열거될 가상 레지스트리 키의 가상 키 네임이 요청에 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 이 실시예에서, 특정 레지스트리 키에 대해 다수의 룰이 룰 엔진에 존재할 수 있고, 가상 레지스트리 키 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 또 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 레지스트리 키 데이터베이스일 수 있다. 일 실시예에서, 요청에서의 가상 키에 대응하는 가상 키 네임은 그 요청에 적용하는 하나 이상의 룰을 배치시키기 위해 룰 엔진의 인덱스로서 이용된다. 일 실시예에서, 프로세스 식별자가 요청에 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나 요청을 분리할 수 있다. 룰 룩업은 결정의 시리즈로서 발생할 수 있으며, 또는 룰 룩업은 단일 데이터베이스 트랜잭션으로서 발생할 수도 있다.

룰 동작이 "분리"가 아니고 "무시" 또는 "재지정"인 경우, 리터럴 키 열거에 대한 요청은 운영 시스템에 전해지고, 열거 결과는 작업 데이터 저장소에 저장되고(단계1012), 이후의 단계1030은 이하에서 설명되는 것과 같이 실행된다.

일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다. 다른 실시예에서, 파일 시스템 필터 드라이버 기능과 개념적으로 유사한 레지스트리 필터 드라이버 기능이 운영 시스템에 의해 제공될 수 있다. 이 실시예에서, 리터럴 레지스트리 키를 열거하는 것은 일반적인 방식으로 변경되지 않은 요청을 처리하도록 레지스트리 필터 관리자에게 신호를 보내는 것으로 키를 열거하기 위한 오리지널 요청에 응답하는 것에 의해 이뤄질 수 있다.

단계1010에서 룰 동작이 "분리"로 결정되면, 시스템 범위가 열거된다. 이것을 이루기 위해, 열거될 가상 키에 대응하는 시스템-범위 키로서 후보 키가 식별된다. 후보 키가 열거되고, 그 열거의 결과가 작업 데이터 저장소에 저장된다(단계1014). 일 실시예에서, 작업 데이터 저장소는 메모리 요소로 구성된다. 일 실시예에서, 작업 데이터 저장소는 데이터베이스 또는 키 또는 고체-상태 메모리 요소 또는 영구적 데이터 저장장치를 포함한다.

다음으로, 후보 키가 가상 키의 애플리케이션-범위 인스턴스로서 식별되고, 후보 키의 존재 카테고리가 결정된다(단계1015). 후보 키가 "존재 부정", 즉 그것 또는 그 조상중 하나가 삭제된 것으로 표시되는 경우, 이 범위내에서 삭제된 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것으로 나타난다(단계1042).

일 실시예에서, 후보 레지스트리 키는 후보 레지스트리 키가 삭제되었다는 것을 나타내는 메타데이터와 결합될 수 있다. 일 실시예에서, 레지스트리 APIs의 오리지널 애플리케이션 사용으로부터 숨겨진 값의 존재를 가지고, 레지스트리 키에 관한 메타데이터는 그 키에 의해 유지되는 특정 값(distinguished value)에 저장될 수 있다. 일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 레지스트리 키에 관한 소량의 메타데이터가 바로 리터럴 키 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이더 지시자는 메타데이터의 하나 또는 여러개의 비트를 나타내거나 또는 인코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 키 네임의 가변에 대한 가상 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 키 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 메타데이터 지시자는 서브키(subkey) 네임에 인코딩되거나 또는 키 네임 그 자체 대신에 레지스트리 값 네임으로 인코딩될 수 있다. 레지스트리 키 시스템은 각각의 키에 대한 일부 3rd 파티 메타데이터를 저장하는 능력을 직접 제공할 수 있다. 일 실시예에서, 메타데이터는 데이터베이스 또는 레지스트리 데이터베이스와 분리된 다른 저장소에 저장된다. 일 실시예에서, 개별적 부-범위는 삭제된 것으로 표시된 키들을 저장하는데 이용될 수 있다. 부-범위내의 키의 존재는 그 키가 삭제된 것으로 표시된 것을 나타낸다.

단계1015에서, 후보 키가 존재 부정을 갖지 않는 경우, 후보 키가 열거되고 얻어진 열거 결과는 작업 데이터 저장소에 합쳐진다. 특히, 열거에서 각각의 서브키에 대해, 그것의 존재 카테고리가 결정된다. 존재 부정을 갖는 서브키는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 서브키, 즉 존재하며 플레이스홀더 로서 표시되지 않고 삭제된 것으로 표시되지 않은 서브키가 작업 데이터 저장소에 추가되며, 작업 데이터 저장소에 이미 대응하는 서브키가 존재하는 경우 이를 대체한다(단계1016).

두 경우에서, 후보 키는 가상 키의 유저-범위 인스턴스로서 식별되며, 후보 키의 존재 카테고리가 결정된다(단계1017). 후보 키가 "존재 부정"을 갖는 경우, 즉 범위내의 그것 또는 그 조상중 하나가 삭제된 것으로 표시된 경우, 이 범위내에서 그것은 삭제될 것으로 알려지고, 이것은 작업 데이터 저장소를 플러싱하는 것에 의해 나타난다(단계1044). 후보 키가 존재 부정을 갖지 않는 경우, 후보 키가 열거되고 얻어진 임의의 열거 결과가 작업 데이터 저장소로 합쳐진다. 특히, 열거에서 각각의 서브키에 대해, 그 존재 카테고리가 결정된다. 존재 부정을 갖는 서브키는 작업 데이터 저장소로부터 제거되고, 존재 긍정을 갖는 서브키, 즉 존재하며 플레이스홀더로서 표시되지 않고 삭제된 것으로 표시되지 않은 서브키가 작업 데이터 저장소에 추가되며, 작업 데이터 저장소에 이미 대응하는 서브키가 존재하는 경우 이를 대체하며(단계1016), 이후의 단계1030은 이하에서 설명된다.

세가지 모든 룰의 타입에 대해서, 단계1030이 실행된다. 요청된 가상 키 네임의 직접적인 자손과는 매치하나 요청된 가상 키 네임 자체와는 매치하지 않는 룰의 집합을 검색하기 위해 룰 엔진에 질의한다(단계1030). 집합내의 각각의 룰에 대해, 룰에서의 네임과 매치하는 가상 자손의 존재가 결정된다. 일 실시예에서, 이것은 적절한 분리 범위 및 가상 자손과 결합된 메타데이터를 검사하는 것에 의해 결정된다. 다른 실시예에서, 이것은 키를 오픈하려는 시도에 의해 결정된다. 오픈 요 청이 성공하면, 가상 자손은 존재 긍정을 갖는다. 가상 자손이 존재하지 않는다는 표시로 오픈 요청이 실패하면, 가상 자손은 존재 부정을 갖는다.

자손이 존재 긍정을 갖는 경우, 이것은 작업 데이터 저장소에 추가되고, 이미 존재하는 동일한 네임의 자손을 대체한다. 자손이 존재 부정을 갖는 경우, 가상 자손에 대응하는 작업 데이터 저장소의 자손은 제거된다(단계1032). 마지막으로, 구성된 열거가 작업 데이터 저장소로부터 요청자로 리턴된다(단계1020).

당업자라면 전술한 레이어화된 열거 프로세스는 다수의 분리 부-범위를 포함하는 단일 분리 범위를 열거하는 동작에 대한 작은 변경으로 적용할 수 있다는 것을 이해할 수 있을 것이다. 작업 데이터 저장소가 생성되고, 성공적인 부-범위가 열거되고 그 결과가 분리 범위의 통합된 열거를 형성하기 위해 작업 데이터 저장소에 합쳐진다.

4.2.4 레지스트리 생성 동작(registry create operations)

도 11을 참조하면, 분리 환경에서 키를 생성하는 실시예의 단계들이 도시되어 있다. 키를 생성하는 요청은 수신 또는 인터셉트된다(단계1102). 요청은 분리 환경에 의해 가상 키 네임으로서 처리되는 키 네임을 포함한다. 섹션 4.2.1에 상술된 바와 같이, 적용할 수 있는 룰을 이용하는 전체 가상화, 즉 적절한 유저 및 애플리케이션 분리 범위를 이용하여 요청된 키를 오픈하려는 시도가 이뤄진다(단계1104). 액세스가 거부되면(단계1106), 액세스 거부 에러가 요청자에게 리턴된다(단계1109). 액세스가 허용되고(단계1106) 요청된 키가 성공적으로 오픈되면(단계1110), 요청된 키가 요청자에게 리턴된다(단계1112). 액세스는 허용되나 요청된 키 가 성공적으로 오픈되지 않고 요청된 키의 부보 또한 존재하지 않으면(단계1114), 요청 의미에 적절한 에러가 요청자에게 내려진다(단계1116). 적절한 유저 및 애플리케이션 범위를 이용하는 전체 가상화 뷰에서 요청된 키의 부보가 검색되면, 룰은 어떻게 키 동작이 처리되는지를 결정한다(단계1118). 룰 동작이 "재지정" 또는 "무시"인 경우(단계1120), 가상 키 네임이 룰에 따라 리터럴 키 네임으로 바로 매핑된다. 특히, 룰 동작이 "무시"인 경우, 리터럴 키 네임은 정확히 가상 키 네임으로서 식별된다. 룰 동작이 "재지정"인 경우, 리터럴 키 네임은 룰에 의해 지정되는 것과 같이 가상 키 네임으로부터 결정된다. 그리고 리터럴 키를 생성하는 요청이 운영 시스템으로 전해지고, 그 결과가 요청자에게 리턴된다(단계1124). 단계1120에서 결정된 룰 동작이 "분리"인 경우, 리터럴 키 네임은 유저 분리 범위의 가상 키 네임의 인스턴스로서 식별된다. 리터럴 키가 이미 존재하나 그것이 플레이스홀더임을 나타내거나 그것이 삭제되었다는 것을 나타내는 메타데이터와 결합된 경우, 결합된 메타데이터는 이러한 지시를 제거하기 위해 변경되고, 키가 비었는지 확인된다. 두 경우에서, 리터럴 키를 오픈하는 요청은 운영 시스템으로 전해진다(단계1126). 리터럴 키가 성공적으로 오픈된 경우(단계1128), 리터럴 키는 요청자에게 리턴된다(단계1130). 반면에 단계1128에서, 요청된 파일이 유저-분리 범위에 현재 존재하지 않는 리터럴 파일의 각각의 조상에 대한 플레이스홀더를 오픈하는데 실패하면(단계1132), 리터럴 네임을 이용하는 리터럴 파일을 생성하기 위한 요청은 운영 시스템에 전해지고 그 결과가 요청자에게 리턴된다(단계1134).

도 11을 계속 참조하여, 키를 생성하는 요청이 수신 또는 인터셉트된다(단계 1102). 일 실시예에서, 운영 시스템 함수 또는 레지스트리 키를 생성하기 위한 함수들을 대체하는 함수에 의해 열거 요청이 후킹된다. 다른 실시예에서, 후킹 라이브러리가 생성 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 본래 레지스트리 키에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 개별적 운영 시스템 함수가 각각의 레지스트리 키 동작 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 레지스트리 키 동작 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

요청은 분리 환경에 의해 가상 키 네임으로 처리되는 키 네임을 포함한다. 일 실시예에서, 가상 키 네임은 부모 키(parent key)에 대한 핸들, 그리고 후손 키(descendant key)로의 상대적 경로 네임의 결합으로서 표현될 수 있다. 부모 키 핸들은 그 자체가 가상 키 네임과 결합된 리터럴 키 네임과 결합된다. 섹션 4.2.1에 상술된 바와 같이, 요청자는 적용할 수 있는 룰을 이용하는 전체 가상화, 즉 적절한 유저 및 애플리케이션 분리 범위를 이용하여 가상 키를 오픈하려고 시도한다(단계1104). 전제 가상화된 오픈 동작중에 액세스가 거부되면(단계1106), 액세스 거부 에러가 요청자에게 리턴된다(단계1109). 액세스가 허용되고(단계1106), 요청된 가상 키가 성공적으로 오픈되면(단계1110), 대응하는 리터럴 키가 요청자에게 리턴된다(단계1112). 그러나, 액세스가 허용되나(단계1106) 가상 키는 성공적으로 오픈되지 않으면(단계1110) 가상 키는 존재하지 않는 것으로 결정된다. 섹션 4.2.1의 과정에 의해 결정되는 것과 같이, 요청된 가상 키의 가상 부모 또한 존재하지 않는 경우, 요청 의미에 적절한 에러가 요청자에게 내려진다(단계1116). 적절한 유저 및 애플리케이션 범위를 이용하는 전체 가상화된 뷰에 요청된 가상 키의 가상 부모가 검색되면(단계1114), 어떻게 생성 동작이 처리되는지 결정하는 룰이 룰 엔진을 참조하여 배치된다. 일 실시예에서, 일 실시예에서, 룰 엔진은 관계형 데이터베이스로서 제공될 수 있다. 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 키 데이터베이스일 수 있다. 일 실시예에서, 요청된 키에 대해 제공되는 가상 키 네임은 요청에 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 이 실시예에서, 특정 키에 대해 다수의 룰이 룰 엔진에 존재할 수 있고, 가상 키 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이다. 일 실시예에서, 프로세스 식별자가 요청에 대해 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 또는 요청을 분리할 수 있다. 도 11에는 파일로 단일 데이터베이스 트랜잭션 또는 단일 룩업(lookup)이 도시되었지만, 룰 룩업은 룰 룩업들의 시리즈로서 수행될 수 있다.

룰 동작이 "재지정" 또는 "무시"인 경우(단계1120), 가상 키 네임이 룰에 따라 리터럴 키 네임으로 바로 매핑된다(단계1124). 룰 동작이 "재지정"인 경우(단계1120), 리터럴 키 네임은 룰에 의해 지정되는 것과 같이 가상 키 네임으로부터 결 정된다(단계1124). 룰 동작이 "무시"인 경우(단계1120), 리터럴 키 네임은 정확히 가상 키 네임으로 결정된다(단계1124). 룰 동작이 "무시" 또는 룰 동작이 "재지정"인 경우, 결정된 리터럴 키 네임을 이용하여 리터럴 키를 생성하는 요청은 운영 시스템에 전해지고 운영 시스템으로부터의 결과가 요청자에게 리턴된다(단계1124). 예를 들면, "key_1"이라는 가상 키를 생성하는 요청은 "Different_key_1"이라는 리터럴 키의 생성을 초래한다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고, 형성된 리터럴 네임을 인수(argument)로서 함수에 전달함으로써 이뤄진다. 다른 실시예에서, 파일 시스템 필터 드라이버 기능과 개념적으로 유사한 레지스트리 필터 드라이버 기능이 운영 시스템에 의해 제공될 수 있다. 이 실시예에서, 리터럴 레지스트리 키를 생성하는 것은, 결정된 리터럴 키 네임을 이용하는 요청을 리파스(reparse)하기 위해 레지스트리 필터 관리자에게 신호를 보내는 것으로서 가상 키를 생성하기 위한 오리지널 요청에 응답하는 것에 의해 이뤄진다.

단계1120에서 결정된 룰 동작이 "무시" 또는 "재지정"이 아니고 "분리"인 경우, 리터럴 키 네임은 유저 분리 범위에서 가상 키 네임의 인스턴스로서 식별된다. 리터럴 키가 이미 존재하나 그것이 플레이스홀더임을 나타내거나 그것이 삭제되었다는 것을 나타내는 메타데이터와 결합되면, 결합된 메타데이터는 이러한 표시를 제거하기 위해 변경되고, 키가 비었는지 확인된다.

일 실시예에서, 레지스트리 APIs의 오리지널 애플리케이션 사용으로부터 숨겨진 값의 존재를 가지고, 레지스트리 키에 관한 메타데이터는 그 키에 의해 유지되는 특정 값(distinguished value)에 저장될 수 있다. 일 실시예에서, 메타데이터 지시자(metadata indicator)를 가상 네임 끝에 붙이는 것(suffixing)과 같이, 레지스트리 키에 관한 소량의 메타데이터가 바로 리터럴 키 네임에 저장될 수 있으며, 메타데이터 지시자는 특정 메타데이터 상태와 유일하게 결합된 스트링(string)이다. 메타데이더 지시자는 메타데이터의 하나 또는 여러개의 비트를 나타내거나 또는 인코딩할 수 있다. 메타데이터 지시자의 존재때문에 리터럴 키 네임의 가변에 대한 가상 네임 체크에 의한 파일 액세스를 위한 요청, 그리고 키 자체의 네임 검색을 위한 요청은 리터럴 네임에 응답하기 위해 후킹되거나 인터셉트된다. 다른 실시예에서, 메타데이터 지시자는 서브키(subkey) 네임에 인코딩되거나 또는 키 네임 그 자체 대신에 레지스트리 값 네임으로 인코딩될 수 있다. 레지스트리 키 시스템은 각각의 키에 대한 일부 3rd 파티 메타데이터를 저장하는 능력을 직접 제공할 수 있다. 일 실시예에서, 메타데이터는 데이터베이스 또는 레지스트리 데이터베이스와 분리된 다른 저장소에 저장된다. 일 실시예에서, 개별적 부-범위는 삭제된 것으로 표시된 키들을 저장하는데 이용될 수 있다. 부-범위내의 키의 존재는 그 키가 삭제된 것으로 표시된 것을 나타낸다.

이 실시예에서, 삭제된 키 또는 키 시스템 요소의 리스트는 삭제된 키에 대한 체크를 최적화 하기 위해 유지되고 참조될 수 있다. 삭제된 키가 재생성되면 키 네임은 삭제된 키 리스트에서 제거된다. 다른 실시예에서, 리스트가 특정 크기를 넘어서면 리스트로부터 키 네임이 제거될 수도 있다.

두 경우에서, 유저-범위 리터럴 키를 오픈하는 요청은 운영 시스템으로 전해진다(단계1126). 일 실시예에서, 룰은 가상 키에 대응하는 리터럴 키가 유저 분리 범위가 아닌 범위, 즉 애플리케이션 분리 범위, 시스템 범위, 유저 분리 부-범위 또는 애플리케이션 부-범위와 같은 범위에 생성되도록 지정할 수 있다.

리터럴 키가 성공적으로 오픈되면(단계1128), 리터럴 키는 요청자에게 리턴된다(단계1130). 단계1128에서, 요청된 키를 오픈하는데 실패하면, 유저-분리 범위에 현재는 존재하지 않는 리터럴 키의 각각의 조상에 대해 플레이스홀더가 생성되고(단계1132) 리터럴 네임을 이용하는 리터럴 키 생성 요청은 운영 시스템에 전해지고 그 결과가 요청자에게 리턴된다(단계1134).

이러한 실시예는 APIs 또는 오직 호출 당 하나의 레벨의 생성만을 지원하는 기능을 갖는 운영 시스템에 대한 것이다. 호출 당 다수의 레벨에 대한 확장은 당업자에게는 자명할 것이다.

4.3 명명된 오브젝트 가상화(named object virtualization)

전술한 기술을 이용하여 가상화될 수 있는 시스템-범위 리소스들의 다른 클래스는 명명된 오브젝트(named object)이며, 이는 세마포어(semaphores), 뮤텍스(mutexes), 뮤턴트(mutants), 웨이터블 타이머(waitable timers), 이벤트(events), 잡 오브젝트(job object), 섹션(sections), 명명된 파이프(named pipes), 그리고 메일슬럿(mailslots)을 포함한다. 이들 오브젝트에 대한 네임 공간은 전체 컴퓨터(전체 범위:global scope)에서 유효할 수 있으며 또는 오직 개인적 유저 세션(세션 범위: session scope)에서 유효할 수 있다.

도 12을 참조하면, 명명된 오브젝트를 생성 또는 오픈하기 위한 요청이 수신 또는 인터셉트된다(단계1202). 요청은 분리 환경에 의해 가상 네임으로 처리되는 오브젝트 네임을 포함한다. 어떻게 요청이 처리되는지 결정하는 룰이 결정된다(단계1204). 룰이 요청이 무시되어야 한다고 나타내는 경우(단계1206), 리터럴 오브젝트 네임이 가상 네임으로 결정되며(단계1207), 리터럴 오브젝트를 생성 또는 오픈하기 위한 요청이 운영 시스템에 내려진다(단계1214). 결정된 룰이 요청을 무시하지 않고 요청이 재지정되어야 한다고 나타내는 경우(단계1208), 리터럴 오브젝트 네임이 재지정 룰에 의해 지정되는 것과 같이 가상 네임으로부터 결정되고(단계1210), 리터럴 오브젝트에 대한 생성 또는 오픈 요청이 운영 시스템에 내려진다(단계1214). 룰이 요청이 재지정되어야 함을 나타내지 않고(단계1208) 요청이 분리되어야 한다고 나타내는 경우, 분리 룰에 의해 지정되는 것과 같이 가상 네임으로부터 리터럴 오브젝트 네임이 결정되고(단계1212) 리터럴 오브젝트에 대한 생성 또는 오픈 명령이 운영 시스템에 내려진다(단계1214). 생성 또는 오픈 명령에 응답하여 운영 시스템에서 리턴되는 리터럴 오브젝트의 핸들은 가상 오브젝트의 생성 또는 오픈을 요청하는 프로그램에 리턴된다(단계1216).

도 12를 계속 참조하여, 프로세스로부터 명명된 오브젝트를 생성 또는 오픈하기 위한 요청이 인터셉트된다(단계1202). 명명된 오브젝트는 세션 범위 또는 전체 범위일 수 있다. 일 실시예에서, 운영 시스템 함수 또는 명명된 오브젝트를 생성하거나 오픈하기 위한 함수를 대체하는 함수에 의해 요청이 후킹된다. 또 다른 실시예에서는 후킹 라이브러리(a hooking dynamically linked library)가 요청을 인터셉트하는데 이용된다. 후킹 함수는 유저 모드 또는 커널 모드에서 실행될 수 있다. 유저 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 프로세스가 생성된 때 프로세스의 어드레스 공간에 로딩될 수 있다. 커널 모드에서 후킹 함수가 실행되는 실시예에서, 후킹 함수는 시스템 오브젝트에 대한 요청을 분산시키는데 이용되는 운영 시스템 리소스와 결합될 수 있다. 명명된 오브젝트를 생성 또는 오픈하기 위한 요청은 광범위한 시스템-범위 리소스들중 하나를 참조할 수 있으며, 상기 리소스들은 내부프로세스 통신 및 동기화(interprocess communication and synchronization)를 위해 이용되며, 유일한 식별자(세마포어, 뮤텍스, 뮤턴트, 웨이터블 타이머, 이벤트, 잡 오브젝트, 섹션, 명명된 파이프, 그리고 메일슬럿을 포함함)에 의해 식별된다. 개별적 운영 시스템 함수가 각각의 오브젝트 타입에 제공되는 실시예에서, 각각의 함수는 개별적으로 후킹될 수 있다. 선택적으로, 다양한 오브젝트 타입에 대한 생성 또는 오픈 호출을 인터셉트하는 하나의 후킹 함수가 제공될 수 있다.

인터셉트된 요청은 분리 환경에 의해 가상 네임으로서 처리되는 오브젝트 네임을 포함한다. 어떻게 오브젝트에 대한 요청을 처리할지 결정하는 룰이 룰 엔진을 참조하여 결정된다(단계1205). 일 실시예에서, 룰 엔진이 관계형 데이터베이스(relational database)로서 제공될 수 있다. 또 다른 실시예에서, 룰 엔진은 트리-구조 데이터베이스, 해시 테이블(hash table), 또는 단층 파일 데이터베이스(flat file database)일 수 있다. 일 실시예에서, 요청된 오브젝트에 대해 제공되는 가상 네임은 요청에 적용하는 룰을 룰 엔진에 배치시키는데 이용된다. 이러한 실시예들에서, 다수의 룰이 특정 오브젝트에 대해 룰 엔진내에 존재할 수 있고, 가상 네임과 가장 많이 매치되는(longest prefix match) 룰이 요청에 적용되는 룰이 다. 다른 실시예에서, 프로세스 식별자가 요청에 대해 적용하는 룰을 룰 엔진에 배치시키기 위해 이용된다. 요청과 결합된 룰은 요청을 무시하거나, 요청을 재지정하거나, 또는 요청을 분리할 수 있다. 도 12에서는 결정의 시리즈로 도시되었지만, 룰 룩업은 단일 데이터베이스 트랜잭션으로서 발생할 수 있다.

룰이 요청이 무시되어야 한다고 나타내는 경우(단계1206), 리터럴 오브젝트 네임이 가상 네임이 되는 것으로 결정되고, 리터럴 오브젝트를 생성 또는 오픈하는 요청이 운영 시스템에 내려진다(단계1214). 예를 들면, "Object_1"이라는 명명된 오브젝트를 생성 또는 오픈하기 위한 요청은 "Object_1"이라는 실제 오브젝트의 생성을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다.

룰 엔진에 액세스하여 얻어진 룰이 요청을 무시하지 않고 재지정되어야 한다고 나타내는 경우(단계1208), 재지정 룰에 의해 지정되는 것과 같이 가상 네임으로부터 리터럴 오브젝트 네임이 결정되고(단계1210) 리터럴 오브젝트에 대한 생성 또는 오픈 요청이 운영 시스템에 내려진다(단계1214). 예를 들면, "Object_1"이라는 명명된 오브젝트을 생성 또는 오픈하기 위한 요청은 "Different_Object_1"이라는 실제 오브젝트의 생성을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다.

룰이 요청이 재지정이 아니라 분리되어야 한다고 나타내는 경우, 분리 룰에 의해 지정되는 것과 같이 가상 네임으로부터 리터럴 오브젝트 네임이 결정되고(단계 1212) 리터럴 오브젝트에 대한 생성 또는 오픈 명령이 운영 시스템에 내려진다(단계1214). 예를 들면, "Object_1"이라는 명명된 오브젝트를 생성 또는 오픈하기 위한 요청은 "Isolated_Object_1"이라흔 실제 오브젝트의 생성을 초래할 것이다. 일 실시예에서, 이것은 후킹된 함수의 오리지널 버전을 호출하고 형성된 리터럴 네임을 인수로서 그 함수에 전달하는 것에 의해 이뤄진다.

요청된 시스템 오브젝트를 분리하기 위하여 형성된 리터럴 네임은 수신된 가상 네임 및 범위-지정 식별자에 근거할 수 있다. 범위-지정 식별자는 애플리케이션 분리 범위, 유저 분리 범위, 세션 분리 범위, 또는 이 세가지 범위의 결합과 결합된 식별자일 수 있다. 범위-지정 식별자는 요청에서 수신된 가상 네임을 "맹글(mangle)" 하는데 이용된다. 예를 들면, "Object_1" 명명된 오브젝트에 대한 요청이 "SA1"이라는 식별자와 결합된 애플리케이션-분리 범위에 대해 분리된 경우, 리터럴 네임은 "Isolated_AppScope_SA1_Object_1"이 될 수 있다. 이하의 테이블은 오브젝트의 네임을 세션 분리 범위, 또는 유저 분리 범위 그리고 애플리케이션 분리 범위로 맹글링한 효과를 나타낸다. 범위들의 결합을 맹글링하는 것은 제한을 가지며 이것은 테이블에 나와있다.

	세션-지정 식별자	유저-지정 식별자	애플리케이션-지정 식별자
전체 오브젝트	유저 세션의 컨텍스 에서 실행하는 모든 분리된 애플리케이션 에 가능한 오브젝트	유저를 위해 실행하는 모든 분리된 애플리케이션에 가능한 오브젝트	애플리케이션 분리 범위내에서 실행하는 모든 분리된 애플리케이션에 가능한 오브젝트
세션 오브젝트	유저 세션의 컨텍스트에서 실행하는 모든 분리된 애플리케이션에 가능한 오브젝트	유저를 위해 실행하는 세션에서 실행하는 모든 분리된 애플리케이션에 가능한 오브젝트	세션내의 애플리케이션 분리 범위에서 실행하는 모든 분리된 애플리케이션에 가능한 오브젝트

운영 시스템이 WINDOWS 운영 시스템중 하나인 실시예에서, 오브젝트와 결합된 전체/부분 네임 프리픽스(prefix)를 토글링(toggling)하는 것에 의해 변경될 수 있는 오브젝트 범위는 오브젝트 네임을 세션-지정 식별자로 맹글링하는 것과 동일한 효과를 갖는다. 그러나, 전체/부분 네임 프리픽스를 토글링하는 것 역시 분리된 애플리케이션에 대한 오브젝트 범위에 영향을 미친다.

단계1214에서 명명된 오브젝트를 생성 또는 오픈하기 위해 내려진 명령에 응답하여 운영 시스템에 의해 리턴된 리터럴 오브젝트의 핸들은 가상 오브젝트의 생성 또는 오픈을 요청하는 프로그램에 리턴된다(단계1216).

4.4 윈도우 네임 가상화(window name virtualization)

전술한 기술을 이용하여 가상화될 수 있는 시스템-범위 리소스의 다른 클래스는 윈도우 네임과 윈도우 클래스 네임이다. 그래픽 소프트웨어 애플리케이션은 애플리케이션 프로그램이 이미 실행하고 있는 경우 식별을 위해 그리고 다른 형태와의 동기화를 위한 방식으로 윈도우 또는 윈도우 클래스의 네임을 이용한다. 도 13을 참조하면, 윈도우 네임 또는 윈도우 클래스에 관한 요청이 수신 또는 인터셉트된다(단계1302). 요청은 Win32 API 호출의 형태 또는 윈도우 메시지 형성로 될 수 있다. 두 가지 타입의 요청 모두 다루어진다(handled). 이러한 요청은 분리 환경에 의해 가상 네임으로서 처리되는 윈도우 네임 및/또는 윈도우 클래스 네임을 포함한다. 요청이 핸들(handle)에 의해 식별되는 윈도우에 대해 윈도우 네임 또는 윈도우 클래스를 검색하면(단계1304), 윈도우에 관한 핸들 및 요청된 정보가 알려 져 있는지 여부를 결정하기 위해 윈도우 매핑 테이블이 참조된다(단계1306). 그렇다면, 윈도우 매핑 테이블로부터의 요청된 정보가 요청자에게 리턴된다(단계1308). 그렇지 않다면, 요청은 운영 시스템에 전해지고(단계1310), 그 결과가 요청자에게 리턴된다(단계1314). 단계1304에서, 요청이 윈도우 네임 또는 윈도우 클래스를 제공하는 경우, 운영시스템에 의해 정의되는 윈도우 클래스 중 하나를 지정하는지를 결정하기 위해 요청이 체크된다(단계1320). 그렇다면, 요청은 운영 시스템으로 내려지고 운영 시스템으로부터 리턴된 결과가 요청자에게 리턴된다(단계1322). 요청이 운영 시스템에 의해 정의되는 윈도우 클래스중 하나를 지정하지 않는 경우, 리터럴 클래스 네임이 가상 클래스 네임 및 룰에 근거하여 결정되고(단계1324) 리터럴 윈도우 네임이 가상 윈도우 네임 및 룰에 근거하여 결정된다(단계1326). 그 다음 리터럴 윈도우 및 리터럴 클래스 네임을 이용하여 운영 시스템으로 전해진다(단계1328). 단계1324 및 단계1326에서 결정된 리터럴 윈도우 네임 또는 리터럴 윈도우 클래스 네임이 대응하는 가상 네임과 다른 경우, 윈도우 핸들에 대한 윈도우 매핑 테이블 엔트리가 요청에서 제공되는 가상 윈도우 네임 또는 가상 클래스 네임을 기록하기 위해 업데이트된다(단계1330). 운영 시스템으로부터의 응답이 본래 윈도우 네임 또는 본래 클래스 확인(identification)을 포함하는 경우, 이들은 요청에서 제공되는 가상 윈도우 네임 또는 가상 클래스 네임으로 대체되고 그 결과가 요청자에게 리턴된다(단계1314).

도 13을 계속 참조하여, 윈도우 네임 또는 윈도우 클래스에 관한 요청이 수신 또는 인터셉트된다(단계1302). 이러한 요청은 분리 환경에 의해 가상 네임으로 서 처리되는 윈도우 네임 및/또는 윈도우 클래스 네임을 포함 또는 검색을 요청한다.

요청이 핸들에 의해 식별되는 윈도우에 대해 윈도우 네임 또는 윈도우 클래스를 검색하면, 윈도우에 관한 핸들 및 요청된 정보가 알려졌는지 여부를 결정하기 위해 윈도우 매핑 테이블이 참조된다(단계1306). 일 실시예에서, 매핑 테이블 대신에, 운영 시스템에 의해 제공되는 기능을 이용하여 각각의 윈도우 및 윈도우 클래스에 대한 추가적인 데이터가 저장된다.

그렇다면, 윈도우 매핑 테이블로부터의 요청된 정보가 요청자에게 리턴된다(단계1308). 그렇지 않다면, 요청은 운영 시스템에 전해지고(단계1310), 그 결과가 요청자에게 리턴된다(단계1314).

단계1304에서, 요청이 윈도우 네임 또는 윈도우 클래스를 제공하는 경우, 운영시스템에 의해 정의되는 윈도우 클래스 중 하나를 지정하는지를 결정하기 위해 요청이 체크된다(단계1320). 그렇다면, 요청은 운영 시스템으로 내려지고 운영 시스템으로부터 리턴된 결과가 요청자에게 리턴된다(단계1322).

요청이 운영 시스템에 의해 정의되는 윈도우 클래스중 하나를 지정하지 않는 경우, 리터럴 클래스 네임이 가상 클래스 네임 및 룰에 근거하여 결정되고(단계1324) 리터럴 윈도우 네임이 가상 윈도우 네임 및 룰에 근거하여 결정된다(단계1326). 그 다음 리터럴 윈도우 및 리터럴 클래스 네임을 이용하여 운영 시스템으로 전해진다(단계1328). 일 실시예에서, 윈도우 네임 및 윈도우 클래스 네임은 문자 스트링 그대로이기 보다는 아톰(atoms)일 수 있다. 전형적으로 애플리케이션은 스 트링을 아톰 테이블에 배치하고 아톰으로 불리며 스트링에 액세스하는데 이용되는 16-비트 정수를 수신한다.

단계1324 및 단계1326에서 결정된 리터럴 윈도우 네임 또는 리터럴 윈도우 클래스 네임이 대응하는 가상 네임과 다른 경우, 윈도우 핸들에 대한 윈도우 매핑 테이블 엔트리가 요청에서 제공되는 가상 윈도우 네임 또는 가상 클래스 네임을 기록하기 위해 업데이트된다(단계1330).

운영 시스템으로부터의 응답이 본래 윈도우 네임 또는 본래 클래스 확인(identification)을 포함하는 경우, 이들은 요청에서 제공되는 가상 윈도우 네임 또는 가상 클래스 네임으로 대체되고 그 결과가 요청자에게 리턴된다(단계1314).

도 13A를 참조하면, 도 13A에 도시된 바와 같이 리터럴 윈도우 네임 또는 윈도우 클래스 네임이 결정된다. 요청에 적용하는 룰을 결정하기 위해 룰 엔진이 참조된다(단계1352). 룰 동작이 "무시"인 경우(단계1354), 리터럴 네임은 가상 네임과 같다(단계1356). 룰 동작이 "무시"가 아니고 "재지정"인 경우(단계1358), 재지정 룰에 의해 지정되는 것과 같이 리터럴 네임은 가상 네임으로부터 결정된다(단계1360). 룰 동작이 "재지정"이 아니고 "분리"인 경우, 리터럴 네임은 범위-지정 식별자를 이용하여 가상 네임으로부터 결정된다(단계1362).

일 실시예에서, 특정 범위-지정 식별자가 룰에 지정된다. 다른 실시예에서, 범위-지정 식별자는 요청 프로세스가 결합된 애플리케이션 분리 범위와 결합된 것중 하나다. 이것은 윈도우 또는 윈도우 클래스가 동일한 애플리케이션 분리 범위와 결합된 임의의 다른 애플리케이션에 의해 이용되는 것을 허용한다. Microsoft WINDOWS 운영 시스템과 같은 운영 시스템에서, 윈도우 네임 및 클래스는 이미 세션에서 분리된다, 이것은 동일한 세션에서 실행하고 동일한 애플리케이션 분리 범위와 결합된 애플리케이션만이 윈도우 네임 또는 클래스를 이용할 수 있다는 것을 의미한다.

Microsoft WINDOWS 운영 시스템에서, 윈도우 네임은 타이틀 바(title bar)에 윈도우의 타이틀로서 이용된다. 윈도우 타이틀 바에 디스플레이된 윈도우 타이틀이 특정 윈도우에 대한 리터럴 네임이 아닌 가상 네임을 반영하는지 확인하기 위해 비-클라이언트 영역 페이트 윈도우 메시지(non-client area paint window message)를 핸들하는 것이 바람직하다. 비-클라이언트 영역 페인트 메시지가 인터셉트되면, 윈도우와 결합된 가상 네임이 매핑 테이블로부터 검색된다. 가상 네임이 검색되면, 비-클라이언트 영역이 윈도우 타이틀로서 가상 네임을 이용하여 페인트되며, 이것은 요청 메시지가 핸들링된 것을 나타낸다. 가상 네임이 검색되지 않으면, 요청은 핸들링되지 않은 것으로 나타나고, 윈도우의 리터럴 네임을 이용하여 타이틀 바를 페인트하는 오리지널 함수에 요청을 전한다.

4.5 외부 프로세스 컴 서버 가상화(out-of-process com server virtualization)

개별적 유닛(discrete units)으로서 COM, CORBA, .NET 과 같은 소프트웨어 구성요소 기술과 다른 소프트웨어 구성요소가 개발되고, 채택되고, 등록되고, 발견되고, 활성화되고 또는 예시되고 이용된다. 대부분의 구성요소 모델에서, 구성요소는 호출 프로세스 또는 동일한 컴퓨터상의 개별적 프로세스 또는 전체적으로 분리 된 컴퓨터상에서 실행된다(비록 일부 구성요소는 이들의 부분만을 지원할 지라도).

하나 이상의 유일한 식별자가 이들 구성요소들을 식별한다. 전형적으로 구성요소 기반(component infrastructure)은 활성화 요청을 중개하는(brokers) 서비스 또는 데몬(daemon)을 제공한다. 구성요소를 이용하여 시작되길 원하는 소프트웨어 프로세스는 구성요소 식별자에 의해 지정된 구성요소를 활성화하기 위해 요청을 중개자(broker)에게 전한다. 중개자는 요청된 구성요소를 활성화하고, 레퍼런스(reference)를 활성화된 인스턴스에 리턴한다. 이러한 구성요소 기반에서, 구성요소 식별자는 버전에서 버전까지 동일하게 유지하기 때문에, 동일한 구성요소의 다수의 버전은 동시-존재(co-exist)할 수 없다.

WINDOWS 운영 시스템의 일부 멤버는 COM으로 불리는 구성요소 기반을 제공한다. COM 구성요소("COM servers")는 클래스 식별자(CLSID)로 불리는 GUID에 의해 식별되고, 각각의 구성요소는 하나 이상의 인터페이스를 제공하고 그 각각은 자신의 유일한 인터페이스 식별자(UIID)를 갖는다. COM Service Control Manager(CSCM)이 외부 프로세스 활성화 요청에 대한 중개자이고, 이것은 호출자가 CLSID를 통해 COM 서버의 활성화를 요청하는 것을 허용하는 인터페이스를 제공한다. 이하의 설명은 COM 서버와 COM 클라이언트의 용어로 표현되지만, 당업자라면 이것이 CORBA, .NET 와, 소프트웨어 구성요소의 다이내믹 활성화를 제공하는 다른 소프트웨어 아키텍처에도 적용할 수 있다는 것을 명확히 이해할 수 있을 것이다.

COM 구성요소들이 컴퓨터상에 설치되면, COM 서버의 새로운 인스턴스를 론치(launch)하기 위해 CSCM에 의해 요구되는 정보와 함께, COM 구성요소들은 그들의 CLSID를 레지스트리 데이터베이스의 공지된 부분에 등록(register)한다. 외부 프로세스 COM 서버에서, 이것은 런(run)에 실행할 수 있는 경로 및 명령 라인 파라메터를 포함한다. 동일한 COM 서버의 다수의 버전은 동일한 CLSID를 공유하고, 따라서 오직 하나의 버전만이 동시에 컴퓨터상에 설치될 수 있다.

특정 실시예에서, 애플리케이션(COM 클라이언트로서 행동하는)은 COM API(예를 들면, CoCreateInstance() 또는 CoCreateInstanceEx())를 호출하여 COM 서버를 예시한다. 이러한 호출에 대한 파라메터는 바람직한 활성화 컨텍스트: 동일 컴퓨터상의 내부 프로세스(in-process); 외부 프로세스(out-of-process); 원격 컴퓨터상의 외부 프로세스를 지정하고 또는 COM 서브시스템이 이들 세가지 경우중 어느 것을 이용할지 결정하도록 허용한다. 외부 프로세스 활성화가 요구되는 것으로 결정되면, CLSID를 포함하는 요청이 CSCM에 전해진다. CSCM은 COM 서버를 호스트하는 실행(executable)을 론치하는데 필요한 경로 및 파라메터를 배치시키기 위해 레지스트리 데이터베이스를 이용한다. 그 실행(executable)이 론치되면, 이것은 COM API CoRegisterClassObject()를 이용하여 CSCM를 지원하는 모든 COM 서버의 모든 CLSID를 등록한다. 요청된 CLSID가 등록되면, CSCM은 그 COM 서버에 대한 레퍼런스를 호출자에게 리턴한다. COM 클라이언트와 COM 서버간의 모든 후속 대화(interaction)는 CSCM과는 독립적으로 이뤄진다.

전술한 분리 환경(200)은 컴퓨터상에서 설치되는 동일한 CLSID를 갖는 COM 서버의 다수의 인스턴스를 허용하며, 각각이 다른 분리 범위(그 중 하나는 시스템 범위일 수 있다)에 있다. 그러나, 이것이 COM 서버를 COM 클라이언트에 가능하게 만들지는 않을 것이다.

도 14는 COM 서버로의 가상화 액세스에 대한 실시예의 단계들을 도시하고 있다. 분리 범위로 론치되는 각각의 외부 프로세스 COM 서버에 대해 새로운 CLSID(이하에서는 분리된 CLSID 또는 ICLSID 로 불림)가 생성된다(단계1402). 이것을 CLSID로 정의하고, 따라서 모든 다른 CLSID중에서 유일해야만 한다, 다시 말하면 이것은 GUID 특성을 가져야 한다. 페어(CLSID, 애플리케이션 분리 범위)를 ICLSID에 매핑하는 매핑 테이블이 생성된다. 적절한 애플리케이션 분리 범위에서 실행가능한 COM 서버를 시작하는 론치 파라메터를 가지고, 어떻게 COM 서버를 론치할지 기술하는 COM 서버 레지스트리 엔트리가 ICLSID에 대해 생성된다(단계1404). COM 클라이언에 의한 CoCreateInstance() 와 CoCreateInstanceEx()와 같은 COM API의 호출은 후킹되거나 인터셉트된다(단계1406). (a)요청이 내부-프로세스 COM 서버에 의해 만족될 수 있거나 (b) COM 클라이언트 및 COM 서버 모두 임의의 분리 범위와 결합되지 않은 경우, 요청은 오리지널 COM API로 변경되지 않고 전해지고 그 결과가 호출자에게 리턴된다(단계1408). 이용하기 위한 COM 서버의 적절한 인스턴스가 식별된다(단계1410). 선택된 COM 서버 인스턴스가 애플리케이션 분리 환경에 있으면 그것의 ICLSID는 전술한 데이터 구조를 이용하는 것으로 결정된다. 그렇지 않으면, 요청의 CLSID가 이용된다(단계1412). 단계1412에서 하나가 식별되면 ICLSID로, 오리지널 CoCreateInstance() 또는 CoCreateInstanceEx() 함수가 호출된다. 이것은 요청을 CSCM에 전한다(단계1414). CSCM은 론치 파라메터를 결정하기 위해 레지스트리에서 요청된 CLSID를 룩업하는, 일반적인 방식에서 실행가능한 COM 서버를 찾고 론치한 다. ICLSID가 요청되면, 단계1404에서 기술된 ICLSID 시스템 범위 레지스트리 엔트리가 검색되고 COM 서버가 적절한 애플리케이션 분리 범위에서 론치된다(단계1416). 론치된 COM 실행은 COM 서버의 CLSID로 후킹된 CoRegisterClassObject() API를 호출하고 이들은 오리지널 CoRegisterClassObject() API로 전해지는 적절한 ICLSID로 번역된다(translated). 예상된(expected) ICLSID를 가지고, CSCM이 CoRegisterClassObject() 호출로부터 응답을 수신하면, 이것은 COM 서버 인스턴스에 대한 레퍼런스를 호출자에게 리턴한다(단계1420).

도 14를 계속 참조하여, 분리 범위로 론치되는 각각의 외부 프로세스 COM 서버에 대한 ICLSID 가 생성된다(단계1402). 일 실시예에서, ICLSID는 COM 서버의 설치중에 생성된다. 다른 실시예에서, ICLSID는 설치 이후 즉시 생성된다. 이 실시예에서, ICLSID는 COM 서버가 분리 범위로 론치되기 이전에 생성된다. 이러한 모든 실시예에서, ICLSID는 레지스트리 데이터베이스의 CLSID 엔트리를 생성 또는 질의하는 시스템 호출을 후킹 또는 인터셉트하여 생성될 수 있다. 선택적으로, ICLSID는 COM 서버 인스턴스를 생성하는 CoCreateInstance() 와 CoCreateInstanceEx() 같은 COM API 호출을 후킹 또는 인터셉트하여 생성될 수 있다. 선택적으로, 레지스트리 데이터베이스의 CLSID-특정 부분에 대한 변화가 설치 발생 이후에 관찰될 수 있다.

페어(CLSID, 애플리케이션 분리 범위)를 ICLSID에 매핑하는 매핑 테이블이 생성된다. 적절한 애플리케이션 분리 범위에서 실행가능한 COM 서버를 시작하는 론치 파라메터를 가지고, 어떻게 COM 서버를 론치할지 기술하는 COM 서버 레지스트리 엔트리가 ICLSID에 대해 생성된다(단계1404). 많은 실시예에서, 이 테이블은 하드 디스크 드라이브 또는 고체-상태 메모리 장치와 같은 영구적 메모리 장치에 저장된다. 다른 실시예에서, 테이블은 레지스트리, 단층 파일, 데이터베이스 또는 휘발성 메모리 장치에 저장될 수 있다. 테이블은 레지스트리 데이터베이스의 COM-특정 부분들 전부에 분배된다(예를 들면 새로운 특정 서브키를 CLSID에 의해 식별된 각각의 적절한 COM 서버 엔트리에 추가하는 것에 의해). 레지스트리 데이터베이스에 CLSID 엔트리를 생성하는 호출을 후킹하거나 인터셉트함으로써, 또는 설치 이후 레지스트리 데이터베이스의 CLSID-특정 부분에 대한 변화를 관찰함으로써, 또는 COM 서버 인스턴스를 생성하는 CoCreateInstance()와 CoCreateInstanceEx()와 같은 COM API 호출을 후킹 또는 인터셉트함으로써, 테이블내의 엔트리는 설치 과정중에 또는 설치 이후 즉시 생성될 수 있다. 특정 분리 범위로의 COM 서버의 설치는 계속적으로 기록될 수 있다. 선택적으로, 특정 COM 서버의 매핑과 ICLSID에 대한 분리 범위가 가변(non-persistent) 데이터베이스, 또는 레지스트리 데이터베이스에 엔트리로서 생성되고 저장될 수 있다.

CoCreateInstance() 와 CoCreateInstanceEx()와 같은 COM API에 대한 COM 클라이언트의 호출은 후킹되거나 인터셉트된다(단계1406). (a)요청이 내부-프로세스 COM 서버에 의해 만족될 수 있거나 (b) COM 클라이언트 및 COM 서버 모두 임의의 분리 범위와 결합되지 않은 경우, 요청은 오리지널 COM API로 변경되지 않고 전해지고 그 결과가 호출자에게 리턴된다(단계1408).

요청이 내부-프로세스 COM 서버에 의해 만족될 수 없고 COM 클라이언트 또는 COM 서버가 시스템 범위에 존재하지 않는 경우(단계1407), 이용하기 위한 COM 서버의 적절한 인스턴스가 식별된다(단계1410). COM 클라이언트가 특정 분리 범위에서 실행되는 실시예에서, 동일한 애플리케이션 분리 범위로 설치되는 COM 서버에 우선권(preference)이 주어질 수 있으며, 이어서 이것이 시스템 범위로 설치되고(클라이언트의 애플리케이션 분리 범위에서 실행이 가능), 이어서 COM 서버가 다른 애플리케이션 범위에 설치된다. 이러한 실시예에서, 시스템 범위로 설치되는 COM 서버는 COM 클라이언트와 같이 동일한 애플리케이션 분리 범위에서 실행될 수 있다. 이것은 COM 서버가 정확히 실행하도록 하는 룰 엔진과 관리 설정(administrative settings)에 의해 제어될 수 있다. COM 클라이언트가 시스템 범위에서 실행되는 실시예에서, 시스템 범위 COM 서버에 우선권이 주어질 수 있고, 이어서 분리 범위내의 COM 서버에 주어진다. COM 클라이언트는 COM 서버의 인스턴스를 생성하는 호출에서 이용되는 COM 서버를 지정할 수 있다. 선택적으로, 구성 저장소(configuration store)는 예시될 COM 서버를 식별하는 정보를 저장할 수 있다. 일 실시예에서, 지정된 COM 서버는 분리된 물리적 머신 또는 가상 머신일 수 있는 다른 컴퓨터에 의해 호스팅된다. 단계1404와 함께 설명된 매핑 테이블이 적용할 수 있는 COM 서버의 집합을 검색하고 룰에 근거한 우선권 계산을 하는데 이용될 수 있다.

적용할 수 있는 COM 서버가 다른 컴퓨터상에 존재하는 실시예에서, 원격 컴퓨터상에서 실행되는 서비스 또는 데몬이 ICLSID에 대해 질의될 수 있다. 원격 COM 서버가 요구되는 것으로 결정된 경우, COM 클라이언트는 CLSID/ICLSID를 결정하기 위해 서비스 또는 데몬에 질의한다. 서비스 또는 데몬은 요청에서 주어진 CLSID에 대응하는 ICLSID를 결정한다. 일 실시예에서, 서비스 또는 데몬에 의해 리턴된 ICLSID는 관리자-정의 구성 데이터, 룰 엔진에 포함된 룰, 빌트-인 하드-코딩된 로직에 근거하여 선택 또는 생성될 수 있다. 다른 실시예에서, 요청은 이용될 분리 범위를 서버상에서 지정할 수 있다. 요청된 COM 서버는 서버의 시스템 범위와 결합될 수 있으며, 이 경우 COM 서버와 결합된 CLSID 가 리턴된다. 요청된 COM 서버는 서버의 분리 범위들중 하나와 결합될 수 있으며, 이 경우 COM 서버의 인스턴스와 분리 범위에 결합된 ICLSID를 리턴한다.

선택된 COM 서버 인스턴스가 로컬 컴퓨터상의 애플리케이션 분리 환경에 있는 경우, 그것의 ICLSID는 단계1404와 함께 설명된 데이터 구조를 이용하여 결정된다. 선택된 COM 서버 인스턴스가 로컬 컴퓨터상의 시스템 범위에 있는 경우, 요청의 CLSID가 이용된다(단계1412). 이러한 실시예에서, ICLSID를 이용하는 COM 서버에 대한 엔트리가 생성될 수 있다.

ICLSID가 리턴되면, 이것은 오리지널 CLSID 대신에 오리지널 COM API로 전해진다. 예를 들면, 결정된 ICLSID는 요청을 CSCM에 전달하는, 오리지널 CoCreateInstance() 또는 CoCreateInstanceEx() 함수에 전해질 수 있다(단계1414). COM 서버가 다른 컴퓨터에 의해 호스팅되는 실시예에서, CSCM은 ICLSID를 COM 서버를 호스팅하는 컴퓨터에 전하고, 그 컴퓨터의 CSCM은 COM 서버 론치를 핸들한다.

론치 파라메터를 결정하기 위해 레지스트리에서 요청된 CLSID 또는 ICLSID를 룩업하는 것에 의해 일반적인 방식에서 실행가능한 COM 서버를 검색하고 론치한다. ICLSID가 요청되는 경우, 단계1404에서 설명된 ICLSID 시스템 범위 레지스트리 엔트리가 검색되고 COM 서버가 적절한 애플리케이션 분리 범위에서 론치된다(단계1416).

론치된 COM 서버 인스턴스가 애플리케이션 분리 범위에서 실행하는 경우(그 범위로 설치된 경우 또는 시스템 범위에 설치되더라도), COM 서버 인스턴스의 COM API 함수 CoRegisterClassObject()가 후킹 또는 인터셉트된다. CoRegisterClassObject()에 전해지는 각각의 CLSID는 단계1404에서 정의된 매핑 테이블을 이용하여 대응하는 ICLSID에 매핑된다. 오리지널 CoRegisterClassObject() API는 ICLSID로 호출된다(단계1418).

CSCM이 CoRegisterClassObject() 로부터 응답을 수신하면, 그 COM 서버 인스턴스에 대한 레퍼런스를 호출자에게 리턴한다(단계1420).

COM 클라이언트 및 COM 서버가 애플리케이션 분리 범위들(다른 범위들을 포함)과 시스템 범위의 임의의 결합에서 실행될 때 이러한 기술은 COM 서버 실행을 지원한다. ICLSID는 서버(CLSID에 의해 식별된)와 바람직한 분리 범위의 결합에 특정된다. 클라이언트는 오직 올바른 ICLSID(또는 서버가 시스템 범위에 설치되고 실행하는 경우에는 오리지널 CLSID) 를 결정하는 것만 요구한다.

4.6 가상화된 파일-타입 결합(virtualized file-type association)

파일 타입 결합(file type association)은 애플리케이션 프로그램의 실행을 야기하기 위한 그래픽 유저 인터페이스 기술이다. 데이터 파일을 표현하는 그래픽적 아이콘이 유저에게 보여진다. 유저는 키보드 명령 또는 마우스와 같은 포인팅 디바이스를 이용하여 데이터 파일을 선택하고 파일을 오픈하기 위해 아이콘을 클릭 또는 더블클릭한다. 선택적으로, 일부 컴퓨팅 환경에서, 유저는 명령 대신에 명령 라인 프롬프트에서 파일에 대한 경로를 입력한다. 일반적으로 파일은 파일을 오픈할때 이용되는 애플리케이션 프로그램을 결정하는데 이용되는 파일 타입 표시를 갖는다. 이것은 일반적으로 파일 타입 표시를 특정 애플리케이션에 매핑하는 테이블을 이용하여 이루어진다. Microsoft WINDOWS 운영 시스템의 대부분에서, 이러한 매핑은 파일 타입 표시자 및 실행될 애플리케이션을 식별하는 전체 경로명을 포함하는 터플(tuple)내의 레지스트리 데이터베이스에 저장되며, 오직 하나의 애플리케이션 프로그램이 특정 파일 타입과 결합될 수 있다.

전술된 분리 환경에서, 애플리케이션의 다수의 버전이 하나의 컴퓨터상에 설치되고 실행될 수 있다. 따라서, 이러한 환경에서, 파일 타입과 애플리케이션 프로그램 사이의 결합은 더이상 일대일(one-to-one) 결합 아니며, 일 대 다수(one-to-many) 결합이 된다. 유사한 문제점이 MIME 부가 타입에 존재한다. 이러한 환경에서, 이 문제점은 주어진 파일 타입이 선택될 때, 론치될 애플리케이션 프로그램을 식별하는 경로명을 대체하는 것에 의해 해결된다. 경로명은 론치하는 애플리케이션 프로그램의 선택을 유저에게 주는 선택 도구의 경로명으로 대체된다.

도 15를 참조하여, 파일 타입 결합 데이터를 구성 저장소(configuration store)에 기록하기 위한 요청이 인터셉트된다(단계1502). 요청이 구성 저장소내의 파일 타입 결합 정보를 업데이트하는지 여부를 결정한다(단계1504). 그렇지 않다면, 즉 엔트리가 이미 존재하는 경우, 업데이트가 일어나지 않는다(단계1506). 이 와 다르다면, 새로운 엔트리가 섹션 4.1.4 또는 4.2.4에서 설명된 가상화 기술을 이용하여 생성되거나 또는 존재하는 엔트리가 업데이트된다(단계1508). 적절한 분리 범위에 대해 가상화된, 새로운 또는 업데이트된 엔트리는 유저가 파일을 보거나 또는 편집할 때 이용되는 다수의 애플리케이션 프로그램중에서 선택하는 것을 허용하는 선택 도구에 파일 타입을 매핑한다.

도 15를 계속 참조하여, 파일 타입 결합 데이터를 구성 저장소에 기록하기 위한 요청이 인터셉트된다(단계1502). 일 실시예에서, 구성 저장소는 WINDOWS 레지스트리 데이터베이스이다. 구성 저장소에 데이터를 기록하는 요청은 유저 모드 후킹 함수, 커널 모드 후킹 함수, 파일 시스템 필터 드라이버, 또는 미니-드라이버에 의해 인터셉트될 수 있다.

요청이 구성 저장소내의 파일 타입 결합 정보를 업데이트하려는지 여부를 결정한다(단계1504). 일 실시예에서, 이것은 인터셉트된 요청이 구성 저장소를 변경하려는 의도임을 나타내는지를 검출하는 것에 의해 이뤄진다. 다른 실시예에서, 요청이 구성 저장소를 변경하려는지를 결정하기 위해 요청의 타겟이 요청에 포함된 정보와 비교된다. 구성 저장소가 레지스트리 데이터베이스인 실시예에서, 섹션 4.2에서 설명된 것과 같이, 레지스트리를 변경하려는 요청이 인터셉트된다.

요청이 구성 저장소를 업데이트하지 않는 것으로 결정되면 업데이트는 발생하지 않는다(단계1506). 일 실시예에서, 인터셉트된 요청이 판독(read) 요청이므로, 요청이 구성 저장소를 업데이트하려는 시도가 아닌 것으로 결정된다. 다른 실시예에서, 구성 저장소내의 타겟 엔트리와 인터셉트된 요청에 포함된 정보가 동일 또는 실질적으로 동일한 경우 이러한 결정이 내려진다.

단계1504에서 요청이 구성 저장소를 업데이트하려는 의도인 것으로 결정되면, 새로운 엔트리가 구성 저장소에 생성되거나 또는 존재하는 엔트리가 업데이트된다(단계1508). 일 실시예에서, 룰은 어떤 분리 범위에서 엔트리가 생성 또는 업데이트되는지 결정한다. 일 실시예에서, 시스템 범위 또는 애플리케이션 분리 범위에서 새로운 엔트리가 생성되거나 또는 존재하는 엔트리가 업데이트된다. 대부분의 실시예에서, 적절한 유저 분리 범위에서 새로운 엔트리가 생성되거나 또는 존재하는 엔트리가 업데이트된다. 새로운 엔트리가 생성되는 경우, 인터셉트된 요청에서 식별된 애플리케이션 프로그램을 식별하는 것보다는, 특정 타입의 파일이 액세스될 때 이용될 애플리케이션으로서 선택 애플리케이션을 기입한다(list). 일 실시예에서, 애플리케이션 프로그램의 새로운 버전이 설치된때, 또는 동일한 파일 타입을 처리하는 다른 애플리케이션이 설치된때, 또는 특정 타입의 파일을 처리하기위해 애플리케이션이 그 자신을 등록 또는 등록취소하는 때, 선택 도구가 자동적으로 업데이트된다. 일 실시예에서, 선택 도구는 다른 범위(선택 도구가 유저 범위에서 실행되는 경우에는 시스템 범위와 애플리케이션 범위)에서 유지되는 구성 저장소의 부분에서 동일한 파일 타입을 처리하기 위해 등록된 임의의 애플리케이션을 애플리케이션 리스트에 넣을 수 있다. 존재하는 엔트리가 업데이트되고 또한 존재하는 엔트리가 이미 특정 파일 타입의 파일이 이용될 때 이용되는 애플리케이션으로서 선택 애플리케이션을 기입하고 있는 경우, 그 파일 타입에 대해 선택자에 보여지는 애플리케이션 리스트는 업데이팅된 애플리케이션을 포함하기 위해 업데이트될 수 있다. 존재하는 엔트리가 업데이트되나 선택 애플리케이션을 기입하고 있지는 않은 경우, 특정 파일 타입의 파일이 이용될 때 이용될 애플리케이션으로서 선택 애플리케이션을 기입하도록 업데이트된 엔트리가 만들어진다. 이런 실시예에서, 애플리케이션과 결합된 정보가 구성 파일(configuration file)에 저장되거나 또는 레지스트리 데이터베이스에 엔트리로서 저장된다.

선택 애플리케이션은 선택된 파일 타입과 결합된 애플리케이션들의 리스트로 유저에게 보여질 수 있다. 애플리케이션은 유저에게 파일을 처리할 때 이용하고 싶어하는 애플리케이션 프로그램을 선택하도록 허용할 수 있다. 선택자는 적절한 범위(시스템 범위, 애플리케이션 분리 범위, 또는 유저 분리 범위)에서 애플리케이션 프로그램을 론치한다. 일 실시예에서, 선택 도구는 파일 타입과 결합된 디폴트 애플리케이션 프로그램의 아이덴티티를 유지한다. 이 실시예에서, 디폴트 애플리케이션은 데스크탑으로의 액세스를 갖지 않는 프로세스 또는 유저에게 선택권을 보여주지 않는 디폴트 처리기를 이용하도록 구성된 프로세스에 의해 이용될 수 있다.

4.7 분리 환경들간의 프로세스 동적 이동(dynamic movement of processes between isolation environments)

본 발명의 추가적인 측면은 다른 가상 범위들간에 실행 프로세스를 이동시키는 기능이다. 다시 말하면, 분리 환경(200)에 의해 애플리케이션 인스턴스에 대해 존재하는 본래 리소스의 통합된 뷰는 애플리케이션이 실행중에 다른 통합된 뷰로 변경될 수 있다. 이것은 특정 분리 범위내에서 분리된 프로세스가 프로세스 실행중에 다른 분리 범위로 "이동(moved)" 될 수 있게 한다. 이것은 특히 WINDOWS 운영 시스템에서 MSI 서비스와 같이, 동시에 오직 하나의 인스턴스가 실행되는 시스템 서비스 또는 프로세스에 대해 유용하다. 본 발명의 이런 측면은 유저가 다수의 분리 범위에서 순차적으로 작업하는 것을 허용하기 위해 이용될 수 있다.

도 16을 참조하면, 제 1 분리 범위와 제 2 분리 범위 사이 또는 시스템 범위와 분리 범위 사이의 프로세스를 이동시키는 실시예가 도시되어 있다. 본 명세서에서 "타겟 분리 범위(target isolation scope)"는 프로세스가 이동될 분리 범위(시스템 범위 포함)를 언급하기 위해 이용될 것이며, "소스 분리 범위(source isolation scope)"는 프로세스가 그로부터 이동되는 분리 범위(시스템 범위 포함)를 언급하기 위해 이용될 것이다. 도 16에 도시된 바와 같이, 타겟 분리 범위로 프로세스를 이동시키기 위한 방법은: 프로세스가 안정 상태에 있는지 확인하는 단계(단계1602); 룰 엔진에서 프로세스의 결합을 소스 분리 범위로부터 타겟 분리 범위로 변경하는 단계(단계1604); 임의의 필터 드라이버 또는 후크에 대해 프로세스의 결합을 소스 분리 범위로부터 타겟 분리 범위로 변경하는 단계(단계1606); 그리고 프로세스가 실행을 재개하도록 허용하는 단계를 포함한다(단계1608).

도 16을 계속 참조하면, 프로세스는 다른 분리 범위로 이동될 때 "안전(safe)" 상태에 있어야만 한다(단계1602). 일 실시예에서, 프로세스는 언제 요청을 처리하지 않는지 결정하기 위해 모니터링된다. 이러한 실시예에서, 프로세스에 의해 아무런 요청도 처리되지 않는 때, 프로세스는 이동을 위한 "안전" 상태에 있는 것으로 여겨진다. 한번 프로세스가 "안전" 상대에 있는 것으로 여겨지면, 프로세스에 대한 새로운 요청은 프로세스가 이동될때까지 지연된다. 진단 애플리케이 션(diagnostic application)과 결합된 다른 실시예에서, 분리 범위내의 변화를 트리거(trigger)하기 위해 유저 인터페이스가 제공될 수 있다. 이 실시예에서, 유저 인터페이스는 이동될 프로세스를 "안전" 상태로 놓는 코드를 실행할 수 있다. 관리 프로그램은 프로세스에 대한 모든 인입 요청을 지연시키고 활성 요청의 실행 완성을 대기시킴으로서 프로세스가 "안전" 상태로 가게 할 수 있다.

룰이 룰 엔진에 존재하지 않는 경우, 타겟 분리 범위와 결합된 룰이 룰 엔진으로 로딩된다(단계1603).

소스 분리 범위와의 프로세스 결합(association of process)이 룰 엔진에서 변화된다(단계1604). 전술한 바와 같이, 프로세스는 임의의 분리 범위와 결합될 수 있다. 요청에 적용하는 룰을 결정하기 위해 가상 본래 리소스에 대한 모든 요청에 따라 룰 엔진이 그 결합을 이용한다. 애플리케이션 인스턴스는 룰 엔진내의 적절한 데이터 구조를 변경함으로써 타겟 분리 범위와 결합될 수 있다. 일 실시예에서, 프로세스와 새로운 분리 범위를 결합시키는 새로운 데이터베이스 엔트리가 기록된다. 다른 실시예에서, 프로세스와 결합된 분리 범위에 대한 식별자를 저장하는 트리 노드(tree node)가 새로운 분리 범위를 식별하기 위해 겹쳐진다(overwritten). 운영 시스템 요청은 타겟 분리 범위와 결합된 룰 또는 룰의 식별자를 저장하도록 프로세스에 대한 추가적인 저장소를 할당할 수 있다.

결합 또는 룰이 필터 드라이버, 커널 모드 훅(kernel mode hooks), 또는 유저 모드 훅(user mode hooks)과 같은 룰 엔진의 외부에 저장되는 경우에는 언제나, 소스 분리 범위와의 프로세스 결합이 변경된다. 프로세스와 분리 범위 룰의 결합이 PID에 근거하여 유지되는 실시예에서, 프로세스 PID와 룰 집합 사이의 결합이 변경된다. 프로세스와 적용할 수 있는 룰 사이의 결합을 유지하는데 PID가 이용되지 않는 실시예에서, 유저 모드 후킹 함수가 타겟 분리 범위와 결합된 룰 집합에 액세스하기 위하여 변경될 수 있다. 프로세스와 분리 범위에 대한 룰 집합과의 결합이 룰 엔진에서 유지되는 실시예에서, 전술한 단계1604에서 룰 엔진에 저장된 결합을 변경하는 것으로 충분하다.

새로운 분리 범위에서 프로세스는 실행을 재개하도록 허용된다(단계1610). 새로운 요청이 지연되었거나 또는 금지되었던 실시예에서, 이러한 요청은 프로세스에 내려지고 새로운 요청도 허용된다.

유용한 한가지 측면은, Microsoft WINDOWS 운영 시스템에서 이용가능한 그리고 Microsoft에서 제작된 설치 패키징 및 설치 기술, MSI를 가상화하는데 전술한 방법이 이용될 수 있다. 설치를 위해 이러한 기술로 패키지된 애플리케이션을 MSI 패키지라 불린다. 이 기술을 지원하는 운영 시스템은 MSI 패키지 설치에서 보조하는 MSI 서비스라 불리는 WINDOWS 서비스를 갖는다. 시스템상에서 이 서비스의 하나의 인스턴스가 존재한다. MSI 패키지를 설치하기 원하는 프로세스들은 MSI 서비스에 대한 COM 호출을 만드는 그 세션에서 MSI 프로세스를 실행한다.

MSI 설치는 애플리케이션 분리 환경에서 MSI 패키지를 설치하는 것으로 가상화될 수 있다. 개념적으로, 이것은 MSI 서비스에 대한 설치 세션에 MSI API를 만드는 호출을 후킹 또는 인터셉팅하는 것으로 이뤄질 수 있다. 뮤텍스가 오직 하나의 설치만이 동시에 발생하는지 확인하는데 이용될 수 있다. 새로운 인스토를 시작하 는 MSI API 요청에 대한 호출이 수신 또는 인터셉트되고, 호출 프로세스가 특정 애플리케이션 분리 범위와 결합되는 때, 호출이 진행되기 이전에 MSI 서비스가 그 분리 범위의 컨텍스트로 배치된다. MSI 서비스에 의해 본래 리소스 요청이 애플리케이션 분리 범위에 따라 가상화되더라도, MSI 서비스로서의 설치 진행은 통상적인 설치 동작을 수행한다. 설치 프로세스의 끝이 검출되면, MSI 서비스와 분리 범위 사이의 결합이 제거된다. 상기에서는 MSI에 대해 설명했지만, 이러한 기술은 다른 설치 기술들에도 적용할 수 있다.

본 발명은 하나 이상의 제조물안에 구현되는 하나 이상의 컴퓨터 판독가능 프로그램으로 제공될 수 있다. 제조물은 플로피 디스크, 하드 디스크, CD-ROM, 플레시 메모리 카드, PROM, RAM, ROM 또는 자기 테이프이다. 일반적으로, 컴퓨터 판독가능 프로그램은 프로그래밍 언어, LISP, PERL, C, C++, PROLOG, 또는 JAVA와 같은 임의의 바이트 코드 언어로 구현될 수 있다. 소프트웨어 프로그램은 오브젝트 코드로 하나 이상의 제조물에 저장될 수 있다.

본 발명의 특정 실시예를 설명함에 있어서, 당업자라면 본 발명의 개념에 따른 다른 실시예가 이용될 수 있다는 것을 명확히 알 수 있을 것이다. 따라서, 본 발명은 특정 실시예들에 한정되지 않으며, 본 발명의 범위와 의도는 특허청구범위에 의해서만 제한된다.

Claims (100)

1. 운영 시스템에 의해 제공되는 본래 리소스(native resources)에 대한 애플리케이션 프로그램의 액세스를 분리하기 위한 방법에 있어서,

   제 1 유저를 대신하여 실행중인 프로세스에 의해 만들어진 본래 리소스에 대한 요청을 유저 분리 범위(user isolation scope) 및 애플리케이션 분리 범위(application isolation scope)를 포함하는 분리 환경(isolation environment)에 재지정하는(redirect) 단계와,

   제 1 유저를 대신하여 상기 유저 분리 범위에 요청된 리소스의 인스턴스(instance)를 배치시키는 단계와,

   상기 유저 분리 범위에 배치된 상기 리소스의 인스턴스를 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계

   를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
2. 제1항에 있어서,

   단계(b)는 요청된 리소스의 인스턴스를 상기 유저 분리 범위에 배치시키지 않는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
3. 제2항에 있어서,

   단계(c)는 상기 요청을 애플리케이션 분리 범위로 재지정하는 단계를 포함하 는, 애플리케이션 프로그램의 액세스 분리 방법.
4. 제3항에 있어서,

   요청된 리소스의 인스턴스를 상기 애플리케이션 분리 범위에 배치시키는 단계와,

   상기 애플리케이션 분리 범위에 배치된 상기 요청의 인스턴스를 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계

   를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
5. 제4항에 있어서,

   단계(e)는 상기 애플리케이션 분리 범위에 배치된 상기 요청된 리소스의 인스턴스에 대응하는 요청된 리소스의 인스턴스를 상기 유저 분리 범위에 생성하고 상기 유저 분리 범위에 생성된 리소스의 인스턴스를 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
6. 제4항에 있어서,

   단계(d)는 상기 요청된 본래 리소스의 인스턴스를 상기 애플리케이션 분리 범위에 배치시키지 않는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
7. 제6항에 있어서,

   단계(e)는 시스템-범위 본래 리소스(system-scoped native resource)를 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
8. 제6항에 있어서,

   단계(e)는 시스템 범위에 배치된 상기 요청된 리소스의 인스턴스에 대응하는 상기 요청된 리소스의 인스턴스를 상기 유저 분리 범위에 생성하고 상기 유저 분리 범위에 생성된 상기 리소스의 인스턴스를 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
9. 제1항에 있어서,

   제 1 유저 를 대신하여 실행중인 프로세스에 의해 만들어진 본래 리소스에 대한 요청을 후킹(hooking)하는 단계를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
10. 제1항에 있어서,

    제 1 유저 대신하여 실행중인 본래 리소스에 대한 요청을 인터셉트하는 단계를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
11. 제1항에 있어서,

    제 1 유저를 대신하여 실행중인 파일 시스템 본래 리소스(file system native resource)에 대한 요청을 파일 시스템 필터 드라이버(file system filter driver)로 인터셉트하는 단계를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
12. 제1항에 있어서,

    단계(a)는 제 1 유저를 대신하여 실행중인 프로세스에 의해 만들어진 파일에 대한 요청을 유저 분리 범위 및 애플리케이션 분리 범위를 포함하는 분리 환경에 재지정하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
13. 제1항에 있어서,

    단계(a)는 제 1 유저를 대신하여 실행중인 프로세스에 의해 만들어진 레지스트리 데이터베이스 엔트리(registry database entry)에 대한 요청을 유저 분리 범위 및 애플리케이션 분리 범위를 포함하는 분리 환경에 재지정하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
14. 제1항에 있어서,

    제 2 유저를 대신하여 실행중인 제 2 프로세스에 의해 만들어진 본래 리소스 에 대한 요청을 상기 분리 환경에 재지정하는 단계와,

    상기 요청된 리소스의 인스턴스를 제 2 유저 분리 범위에 배치시키는 단계와,

    상기 제 2 유저 분리 범위에 배치된 상기 본래 리소스의 버전을 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
15. 제14항에 있어서,

    상기 프로세스는 제 1 유저 및 제 2 유저를 대신하여 동시에 실행하는, 애플리케이션 프로그램의 액세스 분리 방법.
16. 제14항에 있어서,

    단계(e)는 상기 요청된 리소스의 인스턴스를 상기 제 2 유저 분리 범위에 배치시키지 않는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
17. 제16항에 있어서,

    단계(f)는 상기 요청을 상기 애플리케이션 분리 범위로 재지정하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
18. 제17항에 있어서,

    상기 요청된 리소스의 인스턴스를 상기 애플리케이션 분리 범위에 배치시키는 단계와,

    상기 애플리케이션 분리 범위에 배치된 상기 본래 리소스의 버전을 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계

    를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
19. 제1항에 있어서,

    제 1 유저를 대신하여 실행중인 제 2 프로세스에 의해 만들어진 본래 리소스에 대한 요청을 상기 분리 환경에 재지정하는 단계와,

    상기 요청된 본래 리소스의 인스턴스를 상기 유저 분리 범위에 배치시키는 단계와,

    상기 유저 분리 범위에 배치된 상기 리소스의 버전을 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계

    를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
20. 제19항에 있어서,

    단계(e)는 상기 요청된 리소스의 인스턴스를 상기 유저 분리 범위에 배치시키는 않는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
21. 제20항에 있어서,

    단계(f)는 상기 요청을 제 2 애플리케이션 분리 범위에 재지정하는 단계를 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
22. 제21항에 있어서,

    상기 요청된 리소스의 인스턴스를 상기 제 2 애플리케이션 분리 범위에 배치시키는 단계와,

    상기 제 2 애플리케이션 분리 범위에 배치된 상기 본래 리소스의 버전을 이용하여 상기 본래 리소스에 대한 요청에 응답하는 단계

    를 더 포함하는, 애플리케이션 프로그램의 액세스 분리 방법.
23. 운영 시스템에 의해 제공된 본래 리소스에 대한 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경에 있어서,

    상기 분리 환경은,

    본래 리소스의 인스턴스를 저장하는 유저 분리 범위 -상기 유저 분리 범위는 유저에 대응함- 와,

    상기 유저를 대신하여 실행중인 프로세스에 의해 만들어진 본래 리소스에 대한 요청을 인터셉트하고 상기 요청을 상기 유저 분리 범위에 재지정하는 재지정자(redirector)

    를 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
24. 제23항에 있어서,

    상기 분리 환경은 상기 본래 리소스의 인스턴스를 저장하는 애플리케이션 분리 범위를 더 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
25. 제24항에 있어서,

    상기 분리 환경은 상기 본래 리소스의 인스턴스를 저장하는 제 2 애플케이션 분리 범위를 더 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
26. 제23항에 있어서,

    상기 재지정자는 상기 본래 리소스를 식별하는 핸들(a handle)을 상기 요청중인 애플리케이션에 리턴하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
27. 제23항에 있어서,

    상기 요청을 재지정할 때 상기 재지정자의 행동을 지정하는 룰 엔진(rules engine)을 더 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
28. 제23항에 있어서,

    상기 재지정자는 파일 시스템 필터 드라이버를 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
29. 제23항에 있어서,

    상기 재지정자는 후킹 메카니즘 함수(a function hooking mechanism)를 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
30. 제29항에 있어서,

    상기 후킹 함수 장치는 파일 시스템 운영, 레지스트리 운영, WINDOWS 서비스, MSI 서비스, 명명된 오브젝트 운영, 윈도우 운영, 파일-타입 결합 운영 그리고 COM 버서 운영의 그룹으로부터 선택된 운영을 인터셉트하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
31. 제23항에 있어서,

    상기 애플리케이션 분리 환경은 상기 본래 리소스의 제 2 인스턴스를 저장하는 제 2 유저 분리 범위를 더 포함하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
32. 제23항에 있어서,

    상기 애플리케이션 분리 환경은 상기 본래 리소스의 인스턴스를 저장하는 제 2 유저 분리 범위를 더 포함하며, 상기 제 2 유저 분리 범위는 제 2 유저에 대응하는, 애플리케이션 프로그램의 액세스를 분리하기 위한 분리 환경.
33. 본래 리소스의 집합적인 뷰(aggregate view of native resources)를 표현하기 위한 방법에 있어서,

    시스템 범위에 의해 제공되는 다수의 시스템-범위 본래 리소스를 열거하는 단계와,

    애플리케이션 분리 범위에 의해 제공되는 다수의 애플리케이션-범위 본래 리소스를 열거하는 단계 -상기 다수의 애플리케이션-범위 리소스중 일부는 상기 다수의 시스템-범위 리소스중 일부에 대응함- 와,

    상기 다수의 시스템-범위 리소스중 하나에 대해, 대응하는 상기 다수의 애플리케이션-범위 리소스중 하나의 존재를 결정하는 단계와,

    상기 다수의 애플리케이션-범위 리소스중 대응하는 하나를 본래 리소스의 집합적인 뷰에 포함시키는 단계

    를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
34. 제33항에 있어서,

    단계(c)는 상기 다수의 시스템-범위 리소스중 하나에 대해 대응하는 상기 다수의 애플리케이션-범위 리소스중 하나가 존재하지 않는것으로 결정하는 단계를 포 함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
35. 제34항에 있어서,

    단계(d)는 상기 다수의 시스템-범위 리소스중 하나를 본래 리소스의 집합적인 뷰에 포함시키는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
36. 제33항에 있어서,

    (e) 유저 분리 범위에 의해 제공되는 다수의 유저-범위 본래 리소스를 열거하는 단계 -상기 다수의 유저-범위 리소스중 일부는 상기 다수의 시스템-범위 리소스중 일부에 대응함- 와,

    (f) 상기 다수의 시스템-범위 리소스중 하나에 대해, 대응하는 상기 다수의 유저-범위 리소스중 하나가 존재하는지 결정하는 단계와,

    (g) 상기 대응하는 다수의 유저-범위 리소스중 하나를 본래 리소스의 집합적인 뷰에 포함시키는 단계를 더 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
37. 제36항에 있어서,

    단계(f)는 상기 다수의 시스템-범위 리소스중 하나에 대해, 대응하는 상기 다수의 유저-범위 리소스중 하나가 존재하지 않는 것으로 결정하는 단계를 포함하 는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
38. 제37항에 있어서,

    단계(g)는 상기 다수의 시스템-범위 리소스중 하나를 시스템-범위 리소스의 집합적인 뷰에 포함시키는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
39. 제33항에 있어서,

    단계(c)는 상기 다수의 시스템-범위 리소스중 하나에 대해, 대응하는 상기 다수의 애플리케이션-범위 리소스중 하나가 상기 리소스가 삭제되었다는 것을 나타내는 것으로 결정하는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
40. 제39항에 있어서,

    단계(d)는 상기 시스템-범위 리소스의 집합적인 뷰로부터 상기 다수의 시스템-범위 리소스를 제거하는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
41. 제36항에 있어서,

    단계(f)는 상기 다수의 시스템-범위 리소스중 하나에 대해, 대응하는 상기 다수의 유저-범위 리소스중 하나가 상기 리소스가 삭제되었음을 나타내는 것으로 결정하는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
42. 제41항에 있어서,

    단계(g)는 상기 시스템-범위 리소스의 집합적인 뷰로부터 상기 시스템-범위 리소스를 제거하는 단계를 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
43. 제33항에 있어서,

    파일 시스템 드라이버, 미니-드라이버, 유저 모드 후킹 메카니즘, 커널 모드 후킹 메커니즘중 하나에 의해, 시스템-범위 리소스를 포함하는 파일 시스템을 열거하기 위한 요청을 인터셉트하는 단계를 더 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
44. 제33항에 있어서,

    다수의 레지스트리 엔트리를 열거하기 위한 요청을 인터셉트하는 단계를 더 포함하는, 본래 리소스의 집합적인 뷰를 표현하기 위한 방법.
45. 명명된 시스템 오브젝트에 대한 액세스를 가상화(virtualizing)하기 위한 방법,

    유저 분리 범위의 컨텍스트(context)에서 실행하는 프로세스로부터 시스템 오브젝트에 액세스하기 위한 요청을 수신하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 와,

    상기 요청과 연관된 룰(rule)을 결정하는 단계와,

    결정된 룰에 대응하여 상기 시스템 오브젝트에 대한 리터럴 네임(literal name)을 형성하는 단계와,

    상기 시스템 오브젝트에 액세스하기 위한 요청을 운영 시스템에 명령하는(issue) 단계 -상기 요청은 상기 시스템 오브젝트에 대한 리터럴 네임을 포함함-

    를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
46. 제45항에 있어서,

    단계(a)는 유저 분리 범위의 컨텍스트에서 실행하는 프로세스로부터 세마포어(semaphore), 뮤텍스(mutex), 뮤턴트(mutant), 타이머(timer), 이벤트(event), 잡 오프젝트(job object), 파일-매핑 오브젝트(file-mapping object), 섹션(section), 명명된 파이프(named pipe) 그리고 메일슬럿(mailslot)으로 구성되는 그룹으로부터 선택된 시스템 오브젝트에 액세스하기 위한 요청을 수신하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임(virtual name)을 포함함- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
47. 제45항에 있어서,

    단계(a)는 유저 분리 범위의 컨텍스트에서 실행하는 프로세스로부터 시스템 오브젝트에 액세스하기 위한 요청을 인터셉트하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
48. 제45항에 있어서,

    단계(a)는 유저 분리 범위의 컨텍스트에서 실행하는 프로세스로부터 시스템 오브젝트를 오픈하기 위한 요청을 수신하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
49. 제45항에 있어서,

    단계(a)는 유저 분리 범위의 컨텍스트에서 실행하는 프로세스로부터 시스템 오브젝트를 생성하기 위한 요청을 수신하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
50. 제45항에 있어서,

    단계(b)는 무시(ignore), 재지정(redirect) 그리고 분리(isolate)로 구성된 그룹으로부터 선택되는 룰 동작(rule action)이 상기 요청과 연관되었다고 결정하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
51. 제45항에 있어서,

    단계(b)는 수신된 요청에 포함된 상기 가상 네임과 연관된 룰 동작을 결정하기 위해 룰 엔진에 액세스하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
52. 제45항에 있어서,

    단계(c)는 상기 요청에 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
53. 제52항에 있어서,

    단계(c)는 상기 요청에 제공된 상기 가상 네임과 범위 지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계 -애플리케이션 분리 범위와 연관된 상기 범위-지정 식별자는 상기 요청을 만든 프로세스와 연관됨- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
54. 제52항에 있어서,

    단계(c)는 요청에서 제공된 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
55. 제45항에 있어서,

    단계(c)는 글로벌 가시성(global visibility)을 갖는 시스템 오브젝트를 식별하는 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
56. 제45항에 있어서,

    단계(c)는 세션 가시성(session visibility)을 갖는 시스템 오브젝트를 식별하는 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
57. 제45항에 있어서,

    단계(c)는 상기 요청에서 제공되는 상기 가상 네임과 실질적으로 동일한 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
58. 제45항에 있어서,

    상기 운영 시스템으로부터 액세스된 오브젝트를 식별하는 핸들(handle)을 수신하는 단계를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
59. 제58항에 있어서,

    상기 핸들을 상기 프로세스에 전달하는 단계를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
60. 제45항에 있어서,

    제 2 유저 분리 범위의 컨텍스트에서 실행하는 제 2 프로세스로부터 상기 시스템 오브젝트로 액세스하기 위한 요청을 수신하는 단계 -상기 요청은 상기 오브젝트에 대한 상기 가상 네임을 포함함- 를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
61. 제60항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
62. 제61항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계 -애플리케이션 분리 범위와 연관된 상기 범위-지정 식별자는 상기 프로세스가 만드는 상기 요청과 연관됨- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
63. 제61항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계 -상기 범위-지정 식별자는 상기 프로세스가 상기 요청을 실행하는 제 2 유저 분리 범위와 연관됨- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
64. 제60항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 실질적으로 동일한 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
65. 제45항에 있어서,

    상기 유저 분리 범위의 컨텍스트에서 실행하는 제 2 프로세스로부터 상기 시 스템 오브젝트에 액세스하기 위한 요청을 수신하는 단계 -상기 요청은 상기 오브젝트에 대한 가상 네임을 포함함- 를 더 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
66. 제65항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
67. 제66항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계 -애플리케이션 분리 범위와 연관된 상기 범위-지정 식별자는 상기 요청을 만드는 상기 제 2 프로세스와 연관됨- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
68. 제66항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계 -상기 범위-지정 식별자는 제 2 프로세스가 상기 요청을 실행하는 상기 유저 분리 범위와 연관됨- 를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
69. 제65항에 있어서,

    단계(c)는 상기 요청에서 제공된 상기 가상 네임과 실질적으로 동일한 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 단계를 포함하는, 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 방법.
70. 명명된 시스템 오브젝트에 대한 액세스를 가상화하기 위한 장치에 있어서,

    유저 분리 범위의 컨텍스트에서 실행하는 프로세스로부터 시스템 오브젝트로의 액세스하기 위한 요청을 수신하는 후킹 메카니즘(hooking mechanism) -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 과,

    상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는 네임 가상화 엔진(name virtualization engine)과,

    상기 리터럴 네임을 이용하여 상기 시스템 오브젝트에 액세스를 요청하는 운영 시스템 인터페이스

    를 포함하는, 가상화 장치.
71. 제70항에 있어서,

    상기 후킹 메카니즘은 시스템 오브젝트를 오픈하기 위한 요청을 인터셉트하는, 가상화 장치.
72. 제70항에 있어서,

    상기 후킹 메카니즘은 시스템 오브젝트를 생성하기 위한 요청을 인터셉트하는 , 가상화 장치.
73. 제70항에 있어서,

    상기 요청과 연관된 룰을 저장하는 룰 엔진을 더 포함하는, 가상화 장치.
74. 제73항에 있어서,

    상기 룰 엔진은 데이터베이스를 포함하는, 가상화 장치.
75. 제70항에 있어서,

    상기 네임 가상화 엔진은 상기 가상 네임과 실질적으로 동일한 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는, 가상화 장치.
76. 제70항에 있어서,

    상기 네임 가상화 엔진은 상기 가상 네임과 범위-지정 식별자를 이용하여 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하는, 가상화 장치.
77. 제76항에 있어서,

    상기 범위-지정 식별자는 상기 요청을 만드는 상기 프로세스와 연관된 애플리케이션 분리 범위와 연관되는, 가상화 장치.
78. 제76항에 있어서,

    상기 범위-지정 식별자는 상기 요청을 만드는 프로세스가 실행되는 상기 유저 분리 범위와 연관되는, 가상화 장치.
79. 본래 리소스로의 액세스를 가상화하기 위한 방법에 있어서,

    분리 환경의 컨텍스트에서 실행하는 프로세스로부터 본래 리소스에 액세스하기 위한 요청을 수신하는 단계 -상기 요청은 상기 본래 리소스에 대한 가상 네임을 포함함- 와,

    리매핑(remap)의 룰 동작이 상기 수신된 요청에 포함된 상기 가상 네임과 연관되었는지 결정하는 단계와,

    상기 본래 리소스에 대한 리터럴 네임을 형성하는 단계 -상기 리터럴 네임은 상기 요청된 리소스와 동일한 타입의 리터럴 본래 리소스를 식별함- 와,

    상기 본래 리소스에 액세스하기 위한 요청을 운영 시스템에 명령하는 단계 -상기 요청은 상기 본래 리소스에 대해 결정된 리터럴 네임을 포함함-

    를 포함하는, 가상화 방법.
80. 제79항에 있어서,

    단계(a)는 명명된 시스템 오브젝트에 액세스하기 위한 요청을 분리 환경의 컨텍스트에서 실행하는 프로세스로부터 수신하는 단계 -상기 요청은 상기 시스템 오브젝트에 대한 가상 네임을 포함함- 를 포함하는, 가상화 방법.
81. 제80항에 있어서,

    단계(c)는,

    (c-1)상기 수신된 요청에 포함된 상기 가상 네임과 연관된 룰을 결정하는 단계와,

    (c-2) 리터럴 시스템 오브젝트를 식별하는, 상기 시스템 오브젝트에 대한 리터럴 네임을 형성하기 위해 상기 결정된 룰을 이용하는 단계

    를 포함하는, 가상화 방법.
82. 제79항에 있어서,

    단계(a)는 파일 시스템 요소(file system element)에 액세스하기 위한 요청을 분리 환경의 컨텍스트에서 실행하는 프로세스로부터 수신하는 단계 -상기 요청은 상기 파일 시스템 요소에 대한 가상 네임을 포함함- 를 포함하는, 가상화 방법.
83. 제82항에 있어서,

    단계(c)는,

    (c-1) 상기 수신된 요청에 포함된 상기 가상 네임과 연관된 룰을 결정하는 단계와,

    (c-2) 리터럴 파일 시스템 요소를 식별하는, 상기 파일 시스템 요소에 대한 리터럴 네임을 형성하기 위하여 상기 결정된 룰을 이용하는 단계를 포함하는, 가상화 방법.
84. 제79항에 있어서,

    단계(a)는 레지스트리 키(registry key)로 액세스하기 위한 요청을 분리 환경의 컨텍스트에서 실행하는 프로세스로부터 수신하는 단계 -상기 요청은 상기 레지스트리 키에 대한 가상 네임을 포함함- 를 포함하는, 가상화 방법.
85. 제84항에 있어서,

    단계(c)는,

    (c-1) 상기 수신된 요청에 포함된 상기 가상 네임과 연관된 룰을 결정하는 단계와,

    (c-2) 리터럴 레지스트리 키를 식별하는, 상기 레지스트리 키에 대한 리터럴 네임을 형성하기 위하여 상기 결정된 룰을 이용하는 단계를 포함하는, 가상화 방법.
86. 제79항에 있어서,

    단계(a)는 윈도우와 윈도우 클래스중 하나에 액세스하기 위한 요청을 분리 환경의 컨텍스트에서 실행하는 프로세스로부터 수신하는 단계 -상기 요청은 상기 윈도우에 대한 가상 네임과 상기 윈도우 클래스에 대한 가상 네임중 하나를 포함함- 를 포함하는, 가상화 방법.
87. 제86항에 있어서,

    단계(c)는,

    (c-1) 상기 수신된 요청에 포함된 상기 가상 네임과 연관된 룰을 결정하는 단계와,

    (c-2) 리터럴 윈도우와 리터럴 윈도우 클래스중 하나를 식별하는, 상기 윈도우에 대한 가상 네임과 상기 윈도우 클래스에 대한 가상 네임중 하나에 대한 리터럴 네임을 형성하기 위해 상기 결정된 룰을 이용하는 단계를 포함하는, 가상화 방법.
88. 제79항에 있어서,

    단계(c)는,

    (c-1) 상기 요청에 수신된 상기 가상 네임과 연관된 룰을 결정하기 위해 룰 엔진에 액세스하는 단계와,

    (c-2) 상기 결정된 룰에 대응하여 본래 리소스에 대한 리터럴 네임을 형성하는 단계 -형성된 상기 리터럴 네임은 상기 요청된 리소스와 동일한 타입의 리터럴 본래 리소스를 식별함- 를 포함하는, 가상화 방법.
89. 제79항에 있어서,

    액세스된 오브젝트를 식별하는, 운영 시스템으로부터 핸들을 수신하는 단계를 더 포함하는, 가상화 방법.
90. 제89항에 있어서,

    상기 핸들을 상기 프로세스에 전달하는 단계를 더 포함하는, 가상화 방법.
91. 제79항에 있어서,

    단계(c)는 리매핑 룰에 의해, 상기 본래 리소스의 상기 가상 네임에 대한 상기 본래 리소스의 상기 리터럴 네임을 결정하는 단계를 더 포함하는, 가상화 방법.
92. 본래 리소스로의 액세스를 가상화하기 위한 장치에 있어서,

    분리 환경의 컨텍스트에서 실행하는 프로세스로부터 본래 리소스에 액세스하기 위한 요청을 수신하는 후킹 메카니즘 -상기 요청은 상기 본래 리소스에 대한 가상 네임을 포함함- 과,

    상기 본래 리소스에 대한 리터럴 네임을 형성하는 네임 가상화 엔진 -형성된 리터럴 네임은 요청된 리소스와 동일한 타입의 리터럴 본래 리소스를 식별함- 과,

    식별된 리터럴 본래 리소스에 대한 액세스를 요청하는 운영 시스템 인터페이스

    를 포함하는, 가상화 장치.
93. 제92항에 있어서,

    상기 후킹 메카니즘은 본래 리소스를 오픈하기 위한 요청을 인터셉트하는, 가상화 장치.
94. 제92항에 있어서,

    상기 후킹 메카니즘은 본래 리소스를 생성하기 위한 요청을 인터셉트하는, 가상화 장치.
95. 제92항에 있어서,

    수신된 요청에 포함된 상기 가상 네임과 연관된 룰을 저장하는 룰 엔진을 더 포함하는, 가상화 장치.
96. 제95항에 있어서,

    상기 룰 엔진은 데이터베이스를 포함하는, 가상화 장치.
97. 제95항에 있어서,

    상기 룰 엔진은 상기 본래 리소스의 가상 네임으로부터 상기 본래 리소스의 리터럴 네임을 결정하기 위한 룰을 포함하는, 가상화 장치.
98. 제92항에 있어서,

    상기 후킹 메카니즘은 파일 시스템 필터 드라이버를 포함하는, 가상화 장치.
99. 제92항에 있어서,

    상기 후킹 메카니즘은 미니-필터를 포함하는, 가상화 장치.
100. 제92항에 있어서,

     본래 파일 시스템이 상기 후킹 메카니즘을 포함하는, 가상화 장치.

Images