KR101359126B1 - 운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리 - Google Patents

운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리 Download PDF

Info

Publication number
KR101359126B1
KR101359126B1 KR1020117012070A KR20117012070A KR101359126B1 KR 101359126 B1 KR101359126 B1 KR 101359126B1 KR 1020117012070 A KR1020117012070 A KR 1020117012070A KR 20117012070 A KR20117012070 A KR 20117012070A KR 101359126 B1 KR101359126 B1 KR 101359126B1
Authority
KR
South Korea
Prior art keywords
native
setting
registry
node
setting data
Prior art date
Application number
KR1020117012070A
Other languages
English (en)
Other versions
KR20110079762A (ko
Inventor
마이클 메이저
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20110079762A publication Critical patent/KR20110079762A/ko
Application granted granted Critical
Publication of KR101359126B1 publication Critical patent/KR101359126B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

다양한 실시형태들은 애플리케이션 개발자들에 의해 정의될 수 있는 액세스 보호를 갖는 분산된 세팅 레지스트리를 제공하는 방법 및 장치를 포함한다. 분산된 세팅 레지스트리는, 상이한 노드들을 레지스트리 트리에 플로그인하기 위한 커스터마이징 가능한 특권 및 동적 능력을 갖는 상이한 기술들에 걸쳐 구현될 수도 있다. 세팅 레지스트리는 레지스트리 인터페이스 하에 존재하여, 레지스트리를 호출하는 애플리케이션은 세팅 데이터가 어디에 저장될지 또는 어떻게 저장될지를 인식할 필요가 없다. 레지스트리의 트리 내의 각각의 노드는 고유의 특권 요건 및 저장 기술을 정의할 수도 있다. 노드들은 "네이티브" 일 수도 있고 (즉, 세팅 레지스트리 시스템 소프트웨어 내에서 완전히 지원될 수도 있고), "넌-네이티브" 일 수도 있다 (즉, 특정 애플리케이션에 대한 개발자에 의해 정의될 수도 있다).

Description

운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리{FLEXIBLE HIERARCHICAL SETTINGS REGISTRY FOR OPERATING SYSTEMS}
관련 출원
본 출원은, 2008 년 10 월 29 일 출원되고, 그 전체 내용이 본 명세서에 참조로 통합되었으며, 발명의 명칭이 "Flexible Hierarchical Settings Registry for Operating Systems" 인 미국 가특허출원 제 61/109,380 호에 대해 우선권의 이익을 주장한다.
기술분야
본 발명은 일반적으로 컴퓨터 운영 시스템에 관한 것이고, 더 상세하게는, 이동 컴퓨팅 디바이스를 위한 운영 시스템에서 구현되는 레지스트리 시스템에 관한 것이다.
레지스트리는 운영 시스템 내에서 운영되는 소프트웨어의 세팅 및 옵션을 저장하기 위한 디렉토리이다. 예를 들어, 마이크로소프트사의 Windows® 운영 시스템은, 하드웨어, 운영 시스템 소프트웨어 및 애플리케이션 소프트웨어에 의해 요구되는 정보 및 세팅을 포함하고 사용자 선호도 및 세팅을 저장하는 윈도우즈 레지스트리로 공지된 디렉토리 파일을 포함한다. 레지스트리 파일은 모든 프로그램 및 하드웨어 세팅 및 상수값을 단일한 파일 구조에 위치시키도록 기능한다.
윈도우즈 레지스트리는 2 개의 기본 엘리먼트: 키 및 값을 포함한다. 레지스트리 키는 파일 폴더와 유사하다. 값에 부가하여, 각각의 키는, 추가적 서브키를 포함할 수도 있는 서브키를 포함한다. 키는, 계층의 레벨을 나타내기 위해 백슬래시를 이용하는 윈도우즈 경로 명칭과 유사한 신택스에서 참조된다. 레지스트리 값은 키 내에 저장된 명칭/데이터 쌍이다. 값은 키로부터 별도로 참조된다. 윈도우즈 레지스트리에서, 값은, 스트링 값, 2 진 데이터, 부호 미표시 32 비트 정수, UNICODE 값, 멀티-스트링 값, 리스트 및 (윈도우즈 2000 이후에서는) 64 비트 정수 값일 수 있다. 윈도우즈 레지스트리는 데이터베이스 타입의 기능을 제공하는 데이터베이스로서 구성된다.
여기에 통합되어 본 명세서의 일부를 구성하는 첨부된 도면들은 본 발명의 예시적인 실시형태를 설명하고, 전술한 일반적 설명 및 후술하는 상세한 설명과 함께 본 발명의 특성을 설명하도록 기능한다.
도 1 은 일 실시형태에서 세팅 오브젝트를 구현하는 예시적인 코드 블록을 제공한다.
도 2 는 일 실시형태에서 네이티브 세팅 오브젝트를 구현하는 추가적인 예시적 코드 블록을 제공한다.
도 3 은 2 개의 애플리케이션에 의한 네이티브 세팅 오브젝트에 대한 프로세스 호출을 도시하는 프로세스 호출 도면이다.
도 4 는 일 실시형태에서 넌-네이티브 세팅 오브젝트를 구현하는 예시적인 코드 블록을 제공한다.
도 5 는 2 개의 애플리케이션에 의한 넌-네이티브 세팅에 대한 프로세스 호출을 도시하는 프로세스 호출 도면이다.
도 6 은 일 실시형태에서 오브젝트 호출을 설정하는 프로세싱을 도시하는 프로세스 흐름도이다.
도 7 은 다양한 실시형태를 구현하기에 적합한 이동 핸드셋의 컴포넌트 블록도이다.
다양한 실시형태들을 첨부된 도면을 참조하여 상세히 설명한다. 가능한 경우, 동일한 참조번호는 도면 전체에 걸쳐 동일하거나 유사한 부분을 참조하도록 사용된다. 특정한 실시예 및 구현예는 예시적 목적으로 참조되며 본 발명 또는 청구항의 범주를 제한하려는 의도가 아니다.
용어 "예시적인" 은 "예, 예시, 또는 예증으로 기능하는" 의미로 사용된다. 본 명세서에서 "예" 또는 "예시적인" 것으로 기술된 임의의 구현예가 다른 구현예들에 비해 선호되거나 바람직한 것으로 해석될 필요는 없다.
본 명세서에서 사용되는 바와 같이, 용어 "이동 핸드셋" 및 "이동 디바이스" 는 상호교환가능하게 사용되고, 다양한 셀룰러 전화, 개인 휴대 정보 단말기 (PDA), 팜탑 컴퓨터, 무선 모뎀을 갖는 랩탑 컴퓨터, 무선 전자 메일 수신기 (예를 들어, Blackberry® 및 Treo® 디바이스), 셀룰러 전화, 멀티미디어 인터넷 가능 셀룰러 전화 (예를 들어, Blackberry Storm®) 및 유사한 개인 전자 디바이스 중 하나를 지칭한다. 이동 디바이스는 도 7 을 참조하여 더 상세히 후술하는 바와 같이 프로그래머블 프로세서 및 메모리를 포함할 수도 있다.
현대의 이동 디바이스는 방대한 양의 디지털 정보를 저장하고, 사용자들은 통상적으로 자신들의 이동 디바이스를 정보 및 오락 기기로 이용한다. 그 결과, 현대의 디바이스용으로 개발되는 애플리케이션의 복잡성 및 정교함은 이제 개인용 컴퓨터용으로 개발되는 애플리케이션과 경쟁하고 있다. 다양한 실시형태들은, 정의될 수 있는 액세스 보호를 갖는 플렉서블 세팅 레지스트리를 제공함으로써 이동 디바이스 애플리케이션의 개발을 용이하게 한다.
다양한 실시형태들은, 애플리케이션 개발자들에 의해 정의될 수 있는 액세스 보호를 갖는 분산된 세팅 레지스트리를 제공한다. 분산된 세팅 레지스트리는 상이한 기술들에 걸쳐 커스터마이징될 수 있는 특권 및 동적 능력을 제공하여, 상이한 노드들을 레지스트리 트리에 플러그시킨다. 세팅 레지스트리가 레지스트리 인터페이스 하에서 존재하여, 레지스트리를 인보크하는 애플리케이션은 세팅 값들이 어디에 또는 어떻게 저장되어 있는지에 대해 인식할 필요가 없다. 레지스트리의 트리 내의 각각의 노드는 고유의 특권 요건들 및 저장 기술을 정의할 수도 있다. 노드들은 "네이티브" 일 수도 있고 (즉, 세팅 레지스트리 시스템 소프트웨어 내에서 완전하게 지원될 수도 있고), 또는 "넌-네이티브" 일 수도 있다 (즉, 특정한 애플리케이션에 대한 개발자에 의해 정의될 수도 있다). 세팅 오브젝트는, 여기서는 .mif 파일로 지칭되는 모듈 정보 파일 (mif) 을 통해 자신을 세팅 레지스트리에 등록한다.
주지된 바와 같이, 이동 디바이스 상에 상주하는 애플리케이션들은 2 개의 파일, 즉, 확장자 .mif 를 갖는 모듈 정보 파일 및 확장자 .mod 를 갖는 모듈 파일에 의해 정의될 수도 있다. 애플리케이션이 세팅 정보를 요구하면, 이러한 세팅 값들은 시작되거나 실행될 때 애플리케이션에 의해 액세스되도록 세팅 레지스트리 내에 저장될 수도 있다. 일예로, 세팅은 파일 확장자 .ini 를 갖는 초기화 파일에 저장될 수도 있다. 이러한 구현에서, 개발자는 컴파일된 애플리케이션 코드를 포함하는 .mod 파일, (세팅 등록 정보를 포함하는) 컴파일된 모듈 정보를 포함하는 .mif 파일 및 세팅 값들을 포함하는 .ini 파일을 제공해야 한다.
다양한 실시형태들은, 여기서는 때때로 ISettings 로 지칭되는 애플리케이션 프로그래밍 인터페이스 (API), 및 여기서는 때때로 "SettingsReg" 로 지칭되는 API 의 세팅 레지스트리 구현을 제공하며, 이들은 스트링 값들을 갖는 명명된 키를 획득/세팅할 수 있게 하고, 계층적 키 구조를 지원하고, 키의 트리에 걸친 열거를 허용하고, 값들이 변경되는 경우의 통지를 지원한다. 데이터는, 판독, 기록 및 열거 동작을 단순화시키는 텍스트 파일로서 세팅 레지스트리에 저장될 수도 있다. SettingsReg 의 실시형태는 2 가지 타입의 기능, 즉, 공개 세팅 및 비밀 세팅을 제공한다. 공개 세팅은, 애플리케이션 또는 컴포넌트가 글로벌 세팅 레지스트리를 통해 시스템의 나머지에서 이용하기를 원하는 세팅 파일들이다. 공개 세팅은 일반적으로 운영 시스템 내에서 실행되는 모든 애플리케이션에서 이용가능하다. 비밀 세팅은, 선택적으로 식별되는 애플리케이션 또는 애플리케이션의 타입이나 분류에 대해 이용가능한 세팅 파일들이다.
다양한 실시형태들의 세팅 레지스트리는 URI 기반 세팅 트리, 예를 들어, "/path/to/a/setting" 을 이용한다. 윈도우즈 레지스트리의 경우에서와 같은 대형의 일체식 레지스트리 대신에, 다양한 실시형태들의 세팅 레지스트리는, 최상위 레지스트리에 단순히 "플러그인" 하는 임의의 수의 모듈들에 의해 제공되는 다수의 더 작은 서브-레지스트리로 구성되고, 각각의 서브-레지스트리는 트리의 특정 부분을 "소유한다". 이러한 구조는, 각각의 서브-레지스트리가 고유의 데이터 저장부를 커스터마이징 가능한 방식으로 관리하기 때문에, 세팅 레지스트리를 유지하기 용이하게 한다. 이 구조는 또한, 새로운 서브-레지스트리를 추가하는 것이 용이하기 때문에, 다양한 타입의 데이터 저장 메커니즘을 확장가능하게 할 수 있다. 이 구조는 또한, 각각의 서브-레지스트리가 고유의 특권 컨벤션을 관리할 수 있기 때문에, 정의될 수 있는 보안을 제공한다. 또한, 이 구조는 애플리케이션/도메인에 걸친 통지의 변경을 지원한다.
이 세팅 레지스트리는 네이티브 및 넌-네이티브 데이터 저장부의 개념을 갖는다. 네이티브 저장부는, ISetings 레지스트리가 빌트인 지원을 갖는 저장부이다. 예를 들어, 일 실시형태에서, 세팅 레지스트리는, .ini 파일에 존재하고 확장된 파일 시스템 (EFS) 에서 지속되는 세팅인 .ini 파일 기반 데이터 저장부, 및 힙 (heap) 메모리에 존재하고 전력 (즉, 시스템 온/오프) 사이클에 걸쳐 지속되지는 않는 힙 기반 데이터 저장부를 지원한다. 넌-네이티브 저장부는, 네이티브 세팅 오브젝트 데이터 저장부에 의해 지원되는 것과는 다른 저장 기술 또는 파일 타입을 이용하는 독립형 구현이다. 개발자는 이 오브젝트에 대한 특권의 강화를 포함하는 넌-네이티브 세팅 오브젝트를 자유롭게 정의한다.
네이티브 저장부에 있어서, 컴포넌트들은 자신들의 .mif 파일 내의 트리의 특정 노드에 대한 소유권을 주장하고, 컴포넌트들은 또한 자신의 저장부에 대한 몇몇 정보를 레지스트리에 제공한다 (예를 들어, .ini 파일 기반 저장부에 있어서, 컴포넌트는, 이 경우는 .ini 기반인 저장 타입 및 그 .ini 파일로의 EFS 경로를 특정할 것이다). 레지스트리는 데이터 저장부 상의 모든 동작을 관리하여, 세팅 액세스 제어 리스트 (ACL) 와 같은 별도의 메커니즘이 존재할 것이고, 컴포넌트는 세팅 액세스 제어 리스트에 의해 자신의 저장부로의 액세스를 허용 또는 거부할 특권을 정의할 수도 있다. 세팅 ACL (액세스 제어 리스트) 은 파일 시스템 (FS) ACL 과 정확히 동일하게 동작한다.
네이티브 저장부에 있어서, 그 저장부를 정의/관리하기 위해 기록할 코드가 존재하지 않는다. 네이티브 저장부에서는, 레지스트리 프로세스가 저장부를 생성하고 그와 상호작용할 능력을 갖는다. 개발자는 단순히 저장부를 .mif 파일에 등록하고, 저장 매체 (예를 들어, .ini 파일) 를 제공한다. 즉, 모듈들은 .mif 파일을 통해 자신을 세팅 레지스트리에 "등록한다". 그 후, 그 저장부를 이용하는 애플리케이션은 정의된 키에 따라 ISettings 인터페이스를 이용하여, (그 애플리케이션이 액세스할 특권을 갖는다면) 데이터에 액세스할 수 있다. 그 후, 개별적인 네이티브 세팅 오브젝트로의 모든 액세스는 싱글톤 서비스 (18; 도 3) 에 의해 수행된다. 즉, 모든 네이티브 세팅 오브젝트 (20) 로의 동일한 서비스 액세스는, 애플리케이션 (10, 14) 으로부터의 프로세스 경계 및 정보를 획득하기 위해 호출된 API (12, 16) 에 의해 분리되는 프로세스에서 동일한 서비스에 의해 액세스된다.
세팅 데이터는 세팅 오브젝트로서 저장된다. 여기서는 세팅 저장 팩토리로 지칭되는 API 를 발생시키는 오브젝트가 이용되어, 특정한 저장 기술 주위에서 네이티브 세팅 레지스트 오브젝트를 생성할 수도 있다. 예를 들어, 제 1 실시형태에서는, 2 개의 세팅 저장 팩토리가 제공되며, 하나는 .ini 파일 세팅 오브젝트를 발생시키기 위한 것이고, 하나는 힙 저장 세팅 오브젝트를 발생시키기 위한 것이다. 주지된 바와 같이, .ini 파일들은 프로그램이 시작될 때 판독되는 구성 데이터를 저장하기 위해 애플리케이션에 의해 이용되는 초기화 파일들이고, 힙 저장은 이동 디바이스가 파워다운되는 경우에는 언제나 삭제되는 일시적 메모리에 저장되는 파일들이다.
세팅 저장 팩토리는, 특히, 저장될 정보에 소정의 제한된 액세스가 주어지는 경우, 즉, 명명된 애플리케이션 또는 애플리케이션의 타입이나 종류에 제한된 액세스를 갖는 "비밀" 인 경우 이용될 수도 있다. 여기서 사용되는 바와 같이, 용어 "공개" 는 액세스 특권과 무관하게 세팅 레지스트리에서 이용가능한 임의의 세팅이 공개로 고려되는 것을 지칭하고, 용어 "비밀" 은 팩토리를 이용하여 애플리케이션에 생성되는 세팅 또는 오브젝트를 지칭한다. 이와 관련하여, "비밀" 세팅은, 단일 애플리케이션의 상황에서 생성되는 오브젝트의 인스턴스를 지칭하고, 이것은 그 애플리케이션에 대한 "비밀" 인스턴스이다. 따라서, 2 개의 애플리케이션 모두가 세팅 .ini 팩토리를 이용하여 동일한 .ini 파일을 오픈하면, 각각의 애플리케이션은 그 오브젝트의 비밀 인스턴스를 갖는다 (이 경우, 그 파일로의 액세스를 갖는 애플리케이션은 세팅 레지스트리 이외에, 예를 들어, 파일 시스템 ACL 과 같은 몇몇 메커니즘에 의해 정의될 수도 있다). 하나의 애플리케이션이 변경되는 경우, 변경이 발생한 것을 다른 애플리케이션에 통지할 방법이 존재하지 않을 수도 있다. 한편, 그 .ini 파일이 세팅 레지스트리에 등록되면, 그 파일은 "공개" 가 되고, 2 개의 애플리케이션 모두는 세팅 레지스트리를 통해 그 .ini 파일 내의 데이터에 액세스할 수 있고, 하나의 애플리케이션이 변경되는 경우, 다른 애플리케이션은 통지받을 수 있다. 따라서, 3 가지 분류의 세팅 오브젝트, 즉, 모두에게 이용가능한 공개, 제한된 액세스를 갖는 공개 및 비밀이 존재할 수도 있다.
도 1 은 프로그램 "foo" 에 대해 .ini 파일을 구현하는데 이용될 수 있는 예시적인 코드의 샘플을 도시한다. 이 예에서, 트리에서 foo.ini 에 저장될 정보 및 파일 fs:/~0xdeadbeef/foo.ini 는 "명칭" 노드에 저장될 명칭 "Mike" 이다 (코드 2 참조). 이 foo.ini 세팅 파일을 발생시키기 위한 세팅 저장 팩토리를 구현하는데 이용되는 스크립트는 코드 블록 4 에 도시되어 있다. "ISettingsStoreFactory_Create" 로 시작하는 라인에서, 개발자는 이용될 노드 명칭을 특정한다 (이 예에서는 "foo.ini").
네이티브 세팅 오브젝트의 발생 동안, 개발자는 또한 전술한 바와 같이 오브젝트가 비밀인지 또는 공개인지 여부를 지정할 수 있다. 개발자가 그 오브젝트를 비밀로 지정하면, 개발자는 또한 오브젝트의 액세스 특권, 즉, 세팅 오브젝트에 액세스할 수도 있는 특정한 애플리케이션 또는 애플리케이션 타입을 지정할 수도 있다. 도 2 에 도시된 예시적인 코드에서, 코드의 라인 "ISettings_Get(pSettings, 'Genera/name', buf, sizeof (buf), NULL)" 은, 이 예에서는 "Mike" 인 노드 "명칭" 에서 foo.ini 에 저장된 데이터를 리턴할 것이다. 이러한 .ini 파일은, 레지스트리 시스템이 세팅 값으로의 액세스를 허용할 수 있는 애플리케이션의 리스트의 형태로 세팅 오브젝트에 특정된 특권인 FS ACL 에 종속될 수도 있다. 오브젝트 내의 몇몇 세팅 값들이 공개 (즉, 임의의 애플리케이션에 의해 액세스가능) 인 한편 동일한 오브젝트 내의 다른 세팅 값들은 비밀이 되어 대응 ACL 에서 식별된 애플리케이션 또는 애플리케이션 타입에 의해서만 액세스가능하도록 특권이 특정될 수 있다.
도 1 에 도시된 스크립트를 이용하여 네이티브 노드 세팅 오브젝트를 발생시키면, 개발자는 도 2 의 .cif 파일 블록 (6) 에 도시된 스크립트를 구현함으로써 세팅 레지스트리에 오브젝트 (2) 를 등록할 수 있다. .cif 파일은 컴파일되어 애플리케이션에 대한 .mif 파일을 발생시킨다. 따라서, 블록 (6) 의 코드는, "명칭" 코드에서 워드 "Mike" 를 포함하는 초기화 세팅을 유지할 세팅 오브젝트 "foo.ini" 를 정의하는 애플리케이션 "fooApp" 에 대해 .mif 파일에 존재할 정보를 정의한다. 이 시스템은 이동 디바이스에 저장된 .mif 파일을 열거하여 그 세팅 파일에 대한 키를 결정할 수 있다. 더 상세하게는, (.cif 파일 (6) 의 코드에 의해 정의된) .mif 파일은 소유자, 키, 파일을 정의할 필요가 있다 (블록 (6) 의 제 3 내지 제 5 라인 참조). 오브젝트가 등록되면, 도 2 의 블록 (8) 에 도시된 스크립트를 구현함으로써 정보가 애플리케이션에 의해 액세스될 수 있다.
전술하고 도 3 에 도시된 바와 같이, 세팅 레지스트리는 모든 네이티브 세팅 오브젝트 (20) 에 액세스하기 위한 싱글톤 서비스 (18) 를 구현한다. 이것은, (점선 위의) 애플리케이션 (10, 14) 및 레지스트리 (12, 16) 의 프로세싱과 세팅 오브젝트 (20) 로의 액세스 사이에서 프로세스 경계 (점선으로 도시됨) 의 확립을 가능하게 한다. 애플리케이션 (10, 14) 에 의해 호출되는 네이티브 세팅 액세스 API (12, 16) 는 파일 위치를 특정하거나 또는 세팅 오브젝트에 의해 구현된 파일 구조와 관련된 상세를 포함할 필요가 없으며, 이러한 상세는 싱글톤 서비스 (18) 에 의해 처리된다.
넌-네이티브 저장부는, 레지스트리가 네이티브 지원을 갖지 않는 데이터 저장 메커니즘이다 (즉, 제공된 세팅 팩토리가 없고, 싱글톤 서비스 (18) 는 세팅 오브젝트 파일 타입에 액세스하도록 구성되지 않는다). 세팅 레지스트리의 다양한 실시형태는, 넌-네이티브 저장부가 자신을 트리로 인스톨하고 그 트리 내의 노드에서 발생한 임의의 동작을 처리하도록 허용한다. 넌-네이티브 저장부 구현에 따라, 저장부에서의 동작은 인-프로세스로 수행될 수도 있고 또는 프로세스 경계에 걸쳐 수행될 수도 있다.
네이티브 저장부와 유사하게, 넌-네이티브 저장부는 자신의 .mif 에 등록하여, 트리의 특정 노드를 "소유한다". 차이점은, 넌-네이티브 저장부가 커스텀 ISettings 클래스에 대한 클래스 ID 를 제공한다는 점이다. 넌-네이티브 저장부에 있어서, 호출자는 먼저 레지스트리 클래스를 인스턴스화한다. 넌-네이티브 저장부에 의해 소유된 트리에서 키에 대해 동작이 수행되는 경우, (호출자가 적절한 특권을 갖는다고 가정하면) 커스텀 클래스가 인스턴스화되고, 동작이 그에 위임된다. 이 경우, 레지스트리는 본질적으로 "통과 (pass-through)" 로서 동작한다. 기술적으로, 호출자는 레지스트리 대신에 커스텀 클래스를 직접 인스턴스화함으로써 동일한 기능을 획득할 수 있지만, 특히 호출자가 네이티브 및 넌-네이티브 저장부 모두에 관심이 있는 경우, 레지스트리를 이용하는 것이 이용을 단순화한다.
개발자는 넌-네이티브 "BMPSettings" 에 대해 도 4 에 도시된 예와 같이 스크립트를 구현함으로써 넌-네이티브 노드를 등록할 수 있다. 넌-네이티브 세팅 오브젝트는 블록 (22) 의 코드에 도시된 바와 같은 .cif 파일에서 정의될 수 있다. 정의된 넌-네이티브 세팅 오브젝트에 대한 프로세싱은 블록 (24) 에 도시된 바와 같은 코드를 포함함으로써 구현될 수도 있다. 인스턴스화되면, 일 실시형태의 레지스트리 프로세스 (예를 들어, SettingsReg) 는 시스템에서 등록된 넌-네이티브 노드들의 리스트를 확립한다. 정의되고 구현되면, 넌-네이티브 세팅 오브젝트는 블록 (26) 에 도시된 것과 유사한 코드를 포함함으로써 애플리케이션 내에서 액세스될 수 있다. 넌-네이티브 노드로의 액세스 호출 시에, 구현이 생성되고, 동작은 그 구현에 위임된다.
넌-네이티브 세팅 오브젝트가 개발자에 의해 정의되고, 따라서 세팅 레지스트리에 의해 처리될 수 없기 때문에, 액세스 호출은 넌-네이티브 저장부 구현에 따라 인-프로세스로 처리될 수도 있고, 프로세스 경계에 걸쳐 처리될 수도 있다. 이것은 도 5 에 도시되어 있다. 임의의 애플리케이션 (30, 38) 이 넌-네이티브 세팅 오브젝트 (36, 42; 예를 들어, BMPSettings) 에 대한 세팅 API (32, 40) 를 호출하는 경우, API 는 넌-네이티브 오브젝트 액세스 코드 (36, 42) 를 구현하여, 요청된 정보를 인-프로세스로 (즉, 레지스트리의 싱글톤 서비스 (18) 를 구현하지 않고 동일한 프로세스 경계 내에서) 획득한다. 이 방식으로, 개발자는 새로운 세팅 오브젝트를, 특정한 애플리케이션에 대해 소망되는 어떠한 방식 및 파일 타입으로도 정의할 수 있는 완전한 자유를 갖는다.
다양한 실시형태 하에서 세팅 정보에 대한 애플리케이션 호출의 프로세싱이 도 6 에 도시되어 있다. 초기화 (또는 임의의 다른 시간) 동안, 애플리케이션은 단계 60 에서, ISettings API 를 통해 세팅 레지스트리 상에서 동작을 수행함으로써 세팅 정보를 요청할 수도 있다. 예를 들어, 도 3 및 도 5 에 도시된 바와 같이, 애플리케이션은 도 2 의 코드 블록 (8) 및 도 4 의 코드 블록 (26) 에 도시된 ISettings API 를 통해 "SettingsReg" 에 액세스할 수도 있다. 테스트 62 에서, SettingsReg 는, 요청된 세팅 오브젝트가 네이티브 노드인지 넌-네이티브 노드인지 여부를 결정한다. 요청이 네이티브 노드에서의 정보에 대한 것이면 (즉, 테스트 62 = "예"), SettingsReg 는 단계 64 에서 싱글톤 서비스로 동작을 전달하고, 단계 66 에서, 표시된 세팅 오브젝트에 액세스하고 그 데이터를 SettingsReg 에 리턴한다. 일 실시형태에서, 싱글톤 서비스는 단계 65 에서, 호출 애플리케이션이 세팅 정보에 액세스하도록 인가되었는지 여부를 결정하기 위해 그 호출된 세팅 오브젝트에서 특정된 액세스 특권을 비교할 수도 있다. 호출 애플리케이션이 세팅 오브젝트 특권 리스트를 충족하지 않으면 (즉, 애플리케이션 또는 애플리케이션 타입이 세팅 오브젝트에서 특정된 특권에 매칭하지 않아서 테스트 65 = "아니오"), 싱글톤 서비스는 단계 67 에서, '액세스 거부' 또는 유사한 메시지를 호출자에게 리턴할 수도 있다. 호출 애플리케이션이 세팅 오브젝트 특권 리스트를 충족하면 (즉, 테스트 65 = "예"), SettingsReg 는 단계 68 에서 그 요청된 데이터를 애플리케이션에 리턴한다. 그러나, 요청이 넌-네이티브 노드에서의 정보에 대한 것이면 (즉, 테스트 62 = "아니오"), SettingsReg 는 단계 72 에서, 호출된 넌-네이티브 노드에 대한 세팅 오브젝트를 인-프로세스로 생성하여 그 요청된 데이터를 리턴한다. SettingsReg 는 단계 74 에서 그 요청된 데이터를 애플리케이션에 리턴한다.
개발자는 다양한 실시형태를 이용하여 애플리케이션의 개발을 단순화할 수 있다. 다음의 단락들은, 개발자들이 애플리케이션에 포함시켜 세팅 레지스트리의 다양한 실시형태를 구현할 수 있는 단계들 및 예시적인 코드를 설명한다.
레지스트리의 루트 레벨에서의 서브-레지스트리를 구별하기 위해, 각각은 고유한 스트링 식별자를 가져야 한다. 이를 달성하는 가장 단순한 방법은, 예를 들어,
"/~0x12345678/foo/..." <--- 컴포넌트 1 에 대한 세팅 서브-레지스트리
"/~0xdeadbeef/bar/..." <--- 컴포넌트 2 에 대한 세팅 서브-레지스트리
와 같은 클래스 ID 를 요구하는 것이다.
그러나, 클래스 ID 가 요구되지 않으면, 중복을 회피하기 위해 주의가 요구되지만, 인간이 판독할 수 있는 균일한 리소스 식별자 (URI) 가 또한 허용된다. 중복이 발생하면, 동작은 정의되지 못할 수도 있다.
"/component1/foo/..."
"/component2/bar/..."
비밀 세팅은, 인스턴스 기반으로 애플리케이션 또는 컴포넌트에 이용될 수 있는 세팅이다. 이 세팅은 시스템 내의 임의의 다른 컴포넌트에 노출되지 않는다. 비밀 세팅에 대한 ISettings 지원은 세팅을 조직화하기 위한 편리한 메커니즘을 단순히 제공한다.
비밀 세팅은 팩토리를 이용하여 생성된다. 호출자는 세팅을 생성하기 위한 매체에 대한 몇몇 정보를 특정하고, 팩토리는 그 세팅에 액세스하는데 이용될 수 있는 ISettings 오브젝트를 리턴한다.
비밀 세팅에 있어서, .mif 파일에 대한 변형은 요구되지 않는다. 컴포넌트는 단순히 팩토리를 이용하여 실행시에 해당하는 ISettings 오브젝트를 생성한다.
일 실시형태에서, 세팅 레지스트리는, ISettings_OnChange() 방법을 지원하지 않는 ISettings 오브젝트를 리턴하는 팩토리를 포함한다.
공개 .ini 파일 개발자의 공개 저장부를 추가하는 것은 공개 .ini 파일 기반 세팅 저장부를 자신의 컴포넌트에 추가하고 액세스하기 위해 다음의 단계들을 수행할 수 있다. 먼저, 개발자는 다음을 파일 호출된 mysettings.ini 에 카피하고, 이를 EFS 에 있는 자신의 컴포넌트의 모듈 디렉토리에 배치할 수 있다:
[섹션 1]
setting1=value1
두번째로, 개발자는 다음과 같은 스크립트를 이용하여 컴포넌트의 .cif 파일에:
local s = require 'SettingsCIFHelpers'
-- "/myApp/myIniSettings/..." 에서 세팅을 등록함
s:RegisterIniFile {
owner = 0x12345678, -- 컴포넌트의 클래스 ID
key = "/myApp/myIniSettings",
file = "mysettings.ini",
acls = { . . . } -- 옵션
}
을 추가함으로써 저장부를 시스템에 등록할 수 있다.
세째로, 개발자는, 선택적으로, 다른 애플리케이션의 세팅으로의 액세스를 허용하기 위해 ACL 을 정의할 수 있다:
acls = {
{ -- 마이 세팅으로의 모든 판독 액세스를 승인하지만 0xdeadd00d
-- 그룹에 속하는 모듈에 대해서만 기록 액세스를 승인함
{
groups = { 0},
perms = "r/r",
},
{
groups = { 0xdeadd00d},
perms = "rw/rw",
},
path = "/myApp/myIniSettings"
},
}
네째로, 개발자는, 애플리케이션 내의 다음의 코드를 이용하여 세팅으로 액세스할 수 있다:
{
ISettings *piSettings = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, AEECLSID_SettingsReg, (void**) &piSettings)) {
char outbuf[ 32];
int result;
result = ISettings_Get(
piSettings,
"/myApp/myIniSettings/section1/setting1",
outbuf,
sizeof(buf),
NULL
);
if (SUCCESS == result) {
// outbuf will contain "value1"
}
ISettings_Release (piSettings);
pSettings = NULL;
}
}
개발자가 컴포넌트에 공개 힙 기반 세팅 저장부를 추가하고 액세스하기 위해 택하는 단계들은 .ini 파일 기반 저장부와 매우 유사하다. 주요한 차이는 .ini 파일의 부재이다. 대신에, 힙 기반 세팅은, 저장부에 의해 이용될 수도 있는 힙의 최대량을 결정하는 쿼터 (quota) 값을 요구한다. 먼저, 개발자는 컴포넌트의 .cif 파일에 다음을 추가함으로써 저장부를 시스템에 등록할 수도 있다:
local s = require 'SettingsCIFHelpers'
-- "/myApp/myHeapSettings/..." 에서 마이 세팅을 등록함
s:RegisterHeap {
owner = 0x12345678, -- 마이 컴포넌트의 클래스 ID
key = "/myApp/myHeapSettings",
quota = 0x1000,
acls = { ... }
}
선택적으로 개발자는 다음과 같이 자신의 세팅에 다른 애플리케이션의 액세스를 허용하도록 ACL 을 정의할 수도 있다:
acls = {
{ -- 마이 세팅으로의 모든 판독 액세스를 승인하지만 0xdeadd00d
-- 그룹에 속하는 모듈에 대해서만 기록 액세스를 승인함
{
groups = { 0},
perms = "r/r",
},
{
groups = { 0xdeadd00d},
perms = "rw/rw",
},
path = "/myApp/myHeapSettings"
}
}
세째로, 개발자는 애플리케이션 내의 다음의 코드를 이용하여 세팅에 액세스할 수 있다. 힙 기반 세팅은 그에 대해 ISettings_Set() 이 호출될 때까지 존재하지 않는다.
{
ISettings *piSettings = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, AEECLSID_SettingsReg, (void**) &piSettings)) {
char outbuf[ 32];
int result;
(void) ISettings_Set(piSettings, "/myApp/myIniSettings/foo", "bar");
result = ISettings_Get(
piSettings,
"/myApp/myIniSettings/foo",
outbuf,
sizeof(buf),
NULL
);
if (SUCCESS == result) {
// outbuf will contain "bar"
}
ISettings_Release (piSettings);
pSettings = NULL;
}
}
일 실시형태에서, 개발자는, 커스텀 ISettings 구현을 세팅 레지스트리에 추가하기 위해 다음을 수행함으로써 공개인 (즉, 모든 할당에 의해 액세스가능한) 애플리케이션에 대한 커스텀 세팅을 정의할 수 있다: 먼저, 개발자는, 실시형태 레지스트리를 구현하는 컴포넌트를 기록한다. 둘째로, 개발자는 다음을 컴포넌트의 .cif 파일에 추가함으로써 컴포넌트를 시스템에 등록한다:
local s = require 'SettingsCIFHelpers'
s:RegisterClass {
class = 0xdeadbeef,
key = "/myApp/myCustomSettings",
}
다음으로, 개발자는 애플리케이션의 다음의 코드를 이용하여 세팅을 액세스한다. 레지스트리 클래스 상에서 수행되는 임의의 ISettings 동작들은 커스텀 클래스에 위임될 것이다.
{
ISettings *piSettings = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, AEECLSID_SettingsReg, (void**) &piSettings)) {
int nChildren = 0; int result;
result = ISettings_GetNumChildren(piSettings, "/myApp/myCustomSettings", &nChildren);
if (SUCCESS == result) {
// do something
}
ISettings_Release (piSettings);
pSettings = NULL;
}
}
일 실시형태에서, 개발자는 다음을 수행함으로써 애플리케이션에 대한 비밀 (즉, 파일에 액세스하기 위해 허가가 특히 부여된 할당에 의해서만 액세스가능한) .ini 파일 세팅 저장부를 정의할 수 있다. 먼저, 개발자는 다음을 파일 호출된 mysettings.ini 에 카피하고, 이를 EFS 내의 컴포넌트의 모듈 디렉토리에 배치한다.
[섹션 1]
setting1=value1
둘째로, 개발자는 애플리케이션 내에 다음 코드를 포함시켜, 세팅에 액세스하기 위해 이를 인에이블한다:
{
ISettingsStoreFactory *piSSF = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, AEECLSID_SettingsIniFactory, (void**) &piSSF)) {
ISettings *piSettings = NULL;
int result;
result = ISettingsStoreFactory_Create(
piSSF,
"owner=0x12345678,path=mysettings.ini",
&piSettings
);
if (SUCCESS == result) {
char outbuf[ 32];
result = ISettings_Get(
piSettings,
"section1/setting1",
outbuf,
sizeof(buf),
NULL
);
if (SUCCESS == result) {
// outbuf will contain "value1"
}
ISettings_Release (piSettings);
pSettings = NULL;
}
ISettingsStoreFactory_Release (piSSF);
piSSF = NULL;
}
}
공개 세팅과는 달리, 비밀 저장부로의 액세스는 프레픽스 "/myApp/myIniSettings" 를 요구하지 않는다는 것에 주목한다.
애플리케이션 컴포넌트에서 비밀 힙 기반 세팅 저장부를 구현하기 위해 개발자가 택하는 단계들은, .ini 파일에 대한 참조가 없다는 점을 제외하고는 .ini 파일 기반 저장부와 매우 유사하다. 대신에, 힙 기반 세팅은 저장부에 의해 이용될 수도 있는 힙 저장부의 최대량을 결정하는 쿼터 값을 요구한다. 개발자는 애플리케이션 내의 다음 코드를 이용하여 세팅에 액세스할 수 있다. 힙 기반 세팅은 그에 대해 ISettings_Set() 가 호출될 때까지 존재하지 않는다.
{
ISettingsStoreFactory *piSSF = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, AEECLSID_SettingsHeapFactory, (void**) &piSSF)) {
ISettings *piSettings = NULL;
int result;
result = ISettingsStoreFactory_Create(
piSSF,
"quota=0x1000",
&piSettings
);
if (SUCCESS == result) {
char outbuf[ 32];
(void) ISettings_Set(piSettings, "foo/bar", "Hello world");
result = ISettings_Get(piSettings, "foo/bar", outbuf, sizeof(buf), NULL);
if (SUCCESS == result) {
// outbuf will contain "Hello world"
}
ISettings_Release (piSettings);
pSettings = NULL;
}
ISettingsStoreFactory_Release (piSSF);
piSSF = NULL;
}
}
일 실시형태에서, 개발자는 커스텀 ISettings 구현에 액세스하기 위해 다음을 수행함으로써 비밀 커스텀 세팅 저장부를 정의할 수 있다. 먼저, 개발자는 ISettings 을 구현하는 컴포넌트를 기록한다. 둘째로, 개발자는 애플리케이션 내에 다음 코드를 포함시켜 비밀 커스텀 세팅에 액세스한다.
{
ISettings *piSettings = NULL;
if (SUCCESS == IEnv_CreateInstance(piEnv, <classid>, (void**) &piSettings)) {
int nChildren = 0;
int result;
result = ISettings_GetNumChildren(piSettings, "/path/to/my/settings", &nChildren);
if (SUCCESS == result) {
// do something }
ISettings_Release (piSettings);
pSettings = NULL;
}
}
전술한 실시형태들은, 예를 들어, 셀룰러 전화, 셀룰러 전화를 갖는 개인 휴대 정보 단말기 (PDA), 이동 전자 메일 수신기, 이동 웹 액세스 디바이스, 및 장래에 개발될 수도 있는 다른 프로세서 장착 디바이스와 같은 다양한 임의의 이동 디바이스 상에서 구현될 수도 있다. 또한, 전술한 실시형태는 데스크탑 및 랩탑 컴퓨터를 포함하지만 이에 한정되지는 않는 다양한 임의의 컴퓨팅 디바이스 상에서 구현될 수도 있다. 도 7 은 여기서 설명하는 다양한 실시형태를 지원할 수 있는 이동 디바이스 (200) 의 다양한 컴포넌트들을 도시한다. 통상적인 이동 핸드셋 (200) 은 내부 메모리 (202) 및 사용자 인터페이스 디스플레이 (203) 에 커플링된 프로세서 (201) 를 포함한다. 이동 핸드셋 (10) 은, 프로세서 (201) 에 커플링된 무선 데이터 링크 및/또는 셀룰러 전화 트랜시버 (205) 에 접속되는 전자기 방사를 송신 및 수신하기 위한 안테나 (204) 를 포함할 수도 있다. 몇몇 구현예에서, 트랜시버 (205), 및 프로세서 (201) 와 메모리 (202) 중 셀룰러 전화 통신에 이용되는 부분은, 그 조합이 무선 데이터 링크를 통한 데이터 인터페이스를 제공하기 때문에 공중 인터페이스로 지칭된다. 이동 핸드셋은 통상적으로 키 패드 (206) 및 사용자 입력을 수신하는 메뉴 선택 버튼 또는 락커 스위치 (207) 를 포함한다.
프로세서 (201) 는, 전술한 다양한 실시형태들의 기능을 포함하는 다양한 기능들을 수행하는 소프트웨어 명령들 (애플리케이션) 로 구성될 수 있는 임의의 프로그래머블 마이크로프로세서, 마이크로컴퓨터 또는 다수의 프로세서 칩 또는 칩들일 수도 있다. 몇몇 모바일 디바이스에서, 다수의 프로세서 (201) 는, 하나의 프로세서는 무선 통신 기능에 전용되고, 하나의 프로세서는 다른 애플리케이션을 실행하는데 전용되는 것과 같이 제공될 수도 있다. 통상적으로, 소프트웨어 애플리케이션들은, 프로세서 (201) 로 액세스되고 로딩되기 이전에 내부 메모리 (202) 에 저장될 수도 있다. 몇몇 모바일 디바이스에서, 프로세서 (201) 는 애플리케이션 소프트웨어 명령들을 저장하기에 충분한 내부 메모리를 포함할 수도 있다. 이 설명을 위해, 용어, 메모리는 내부 메모리 (202) 및 프로세서 (201) 내부의 메모리 자체를 포함하는, 프로세서 (201) 에 의해 액세스될 수 있는 모든 메모리를 지칭한다. 메모리 (202) 는 휘발성 메모리일 수도 있고, 플래시 메모리와 같은 비휘발성 메모리일 수도 있고, 또는 이 둘의 혼합일 수도 있다.
전술한 실시형태들을 구현하기 위해 이용되는 하드웨어는 일 세트의 명령들을 실행하도록 구성된 프로세싱 엘리먼트 및 메모리 엘리먼트일 수도 있고, 일 세트의 명령들은 전술한 방법에 대응하는 방법 단계들을 수행하기 위한 것이다. 대안적으로, 몇몇 단계 또는 방법은 소정의 기능에 특정된 회로에 의해 수행될 수도 있다.
또한, 당업자는 여기에서 개시된 실시형태들과 관련하여 설명된 다양한 예시적인 논리 블록들, 모듈들, 회로들, 및 알고리즘 단계들을 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이들의 조합으로 구현할 수도 있음을 알 수 있다. 하드웨어와 소프트웨어의 이러한 교환가능성을 분명히 설명하기 위하여, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 단계들을 주로 그들의 기능의 관점에서 상술하였다. 그러한 기능이 하드웨어로 구현될지 소프트웨어로 구현될지는 전체 시스템에 부과된 특정한 애플리케이션 및 설계 제약조건들에 의존한다. 당업자는 설명된 기능을 각각의 특정한 애플리케이션에 대하여 다양한 방식으로 구현할 수도 있지만, 그러한 구현의 결정이 본 발명의 범위를 벗어나는 것으로 해석하지는 않아야 한다.
여기에 개시된 실시형태들과 관련하여 설명된 방법 또는 알고리즘의 단계는 하드웨어에 의해 직접 구현될 수도 있고, 프로세서에 의해 실행되는 소프트웨어 모듈로 구현될 수도 있고, 또는 그 2 개의 결합으로 구현될 수도 있다. 소프트웨어 모듈은 프로세서 판독가능 저장 매체 및/또는 프로셋서 판독가능 메모리에 상주할 수도 있고, 둘 모두는 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터, 하드 디스크, 착탈형 디스크, CD-ROM, 또는 당업계에 알려진 임의의 다른 형태의 저장 매체일 수도 있다. 또한, 프로세서 판독가능 메모리는, 2 이상의 메모리 칩, 프로세서 칩 내부의 메모리를 별도의 메모리 칩으로 포함할 수도 있고, 플래시 메모리 및 RAM 메모리와 같은 상이한 타입의 메모리의 조합을 포함할 수도 있다. 여기서, 이동 핸드셋의 메모리에 대한 참조는 특정한 구성, 타입 또는 패키징에 한정하지 않고 이동 핸드셋 내의 임의의 하나 또는 모든 메모리 모듈을 포함하도록 의도된다. 예시적인 저장 매체는, 프로세서가 그 저장 매체로부터 정보를 판독하고 그 저장 매체에 정보를 기록할 수 있도록 이동 핸드셋 또는 테마 서버 내의 프로세서에 커플링된다. 대안적으로, 저장 매체는 프로세서에 통합될 수도 있다. 프로세서 및 저장 매체는 ASIC 내에 상주할 수도 있다.
다양한 실시형태들에 대한 이전의 설명은 당업자로 하여금 본 발명을 제조 또는 이용할 수 있도록 제공된다. 당업자는 이들 실시형태에 대한 다양한 변형들을 명백히 알 수 있으며, 여기에서 정의된 일반적인 원리들은 본 발명의 사상 또는 범위를 벗어나지 않고도 다른 실시형태들에 적용될 수도 있다. 따라서, 본 발명은 여기에서 설명된 실시형태들에 제한되는 것이 아니라, 여기에서 개시된 원리 및 신규한 특징들과 부합하는 최광의 범위를 부여하려는 것이다.

Claims (20)

  1. 레지스트리 내에 소프트웨어 세팅을 저장하고 상기 소프트웨어 세팅에 액세스하는 방법으로서,
    세팅 값을 포함하는 네이티브 세팅 오브젝트를 발생시킴으로써, 네이티브 데이터 저장부의 네이티브 노드를 생성하는 단계;
    제 1 파일 타입을 이용하여 키로 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 단계로서, 상기 네이티브 데이터 저장부는 상기 제 1 파일 타입과 연관되고, 상기 제 1 파일 타입은 상기 레지스트리에 의해 지원되는, 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 단계;
    상기 네이티브 노드를 상기 레지스트리에 등록시키는 단계;
    넌-네이티브 데이터 저장부의 넌-네이티브 노드를 수신하는 단계로서, 상기 넌-네이티브 데이터 저장부는 상기 레지스트리에 의해 지원되지 않는 제 2 파일 타입과 연관되는, 상기 넌-네이티브 노드를 수신하는 단계;
    커스텀 레지스트리 클래스에 대한 클래스 식별자를 이용하여 상기 레지스트리에 상기 넌-네이티브 노드를 등록시키는 단계;
    세팅 데이터에 대한 요청을 애플리케이션 프로그래밍 인터페이스 (API) 호출의 형태로 애플리케이션으로부터 수신하는 단계;
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는지 또는 넌-네이티브 노드 내에 있는지 결정하는 단계; 및
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터를 획득하기 위해 상기 레지스트리와 연관된 싱글톤 서비스를 구현하는 단계를 포함하고,
    상기 싱글톤 서비스는 상기 네이티브 세팅 오브젝트로부터 상기 요청된 세팅 데이터를 획득하고,
    상기 싱글톤 서비스는 상기 API 로 상기 획득된 세팅 데이터를 리턴하며,
    상기 획득된 세팅 데이터는 상기 API 로부터 상기 애플리케이션으로 리턴되는, 소프트웨어 세팅을 저장하고 소프트웨어 세팅에 액세스하는 방법.
  2. 제 1 항에 있어서,
    상기 싱글톤 서비스가 네이티브 세팅 오브젝트로의 모든 액세스를 제어하는, 소프트웨어 세팅을 저장하고 소프트웨어 세팅에 액세스하는 방법.
  3. 제 1 항에 있어서,
    상기 요청된 세팅 데이터가 상기 넌-네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 요청된 세팅 데이터를 획득하기 위해 넌-네이티브 프로세스를 구현하는 단계를 더 포함하는, 소프트웨어 세팅을 저장하고 소프트웨어 세팅에 액세스하는 방법.
  4. 제 1 항에 있어서,
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하는지 여부를 결정하는 단계; 및
    상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하지 않는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터로의 액세스를 거부하는 단계를 더 포함하는, 소프트웨어 세팅을 저장하고 소프트웨어 세팅에 액세스하는 방법.
  5. 제 4 항에 있어서,
    상기 네이티브 세팅 오브젝트가 발생되는 경우 상기 특권을 정의하는 단계를 더 포함하는, 소프트웨어 세팅을 저장하고 소프트웨어 세팅에 액세스하는 방법.
  6. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하고,
    상기 프로세서는,
    세팅 값을 포함하는 네이티브 세팅 오브젝트를 발생시킴으로써, 네이티브 데이터 저장부에 대한 네이티브 노드를 생성하는 단계;
    제 1 파일 타입을 이용하여 키로 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 단계로서, 상기 네이티브 데이터 저장부는 상기 제 1 파일 타입과 연관되고, 상기 제 1 파일 타입은 레지스트리에 의해 지원되는, 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 단계;
    상기 네이티브 노드를 상기 레지스트리에 등록시키는 단계;
    넌-네이티브 데이터 저장부의 넌-네이티브 노드를 수신하는 단계로서, 상기 넌-네이티브 데이터 저장부는 상기 레지스트리에 의해 지원되지 않는 제 2 파일 타입과 연관되는, 상기 넌-네이티브 노드를 수신하는 단계;
    커스텀 레지스트리 클래스에 대한 클래스 식별자를 이용하여 상기 레지스트리에 상기 넌-네이티브 노드를 등록시키는 단계;
    상기 세팅 데이터에 대한 요청을 애플리케이션 프로그래밍 인터페이스 (API) 호출의 형태로 애플리케이션으로부터 수신하는 단계;
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는지 또는 넌-네이티브 노드 내에 있는지 결정하는 단계; 및
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터를 획득하기 위해, 레지스트리와 연관된 싱글톤 서비스를 구현하는 단계로서,
    상기 싱글톤 서비스는 상기 네이티브 세팅 오브젝트로부터 상기 요청된 세팅 데이터를 획득하고,
    상기 싱글톤 서비스는 상기 API 로 획득된 세팅 데이터를 리턴하며,
    상기 획득된 세팅 데이터는 상기 API 로부터 상기 애플리케이션으로 상기 세팅 값을 리턴되는, 상기 싱글톤 서비스를 구현하는 단계;
    를 포함하는 단계들을 수행하기 위한 프로세서 실행가능 명령들로 구성되는, 이동 디바이스.
  7. 제 6 항에 있어서,
    상기 프로세서는, 상기 싱글톤 서비스가 네이티브 세팅 오브젝트로의 모든 액세스를 제어하도록 프로세서 실행가능 명령들로 또한 구성되는, 이동 디바이스.
  8. 제 6 항에 있어서,
    상기 프로세서는,
    상기 요청된 세팅 데이터가 상기 넌-네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 요청된 세팅 데이터를 획득하기 위해 넌-네이티브 프로세스를 구현하는 단계
    를 더 포함하는 단계들을 수행하기 위한 프로세서 실행가능 명령들로 또한 구성되는, 이동 디바이스.
  9. 제 6 항에 있어서,
    상기 프로세서는,
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하는지 여부를 결정하는 단계; 및
    상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하지 않는 것으로 결정하는 것에 응답하여,, 상기 세팅 데이터로의 액세스를 거부하는 단계
    를 더 포함하는 단계들을 수행하기 위한 프로세서 실행가능 명령들로 또한 구성되는, 이동 디바이스.
  10. 제 9 항에 있어서,
    상기 프로세서는, 상기 네이티브 세팅 오브젝트가 발생되는 경우 상기 특권을 정의하는 단계를 더 포함하는 단계들을 수행하기 위한 프로세서 실행가능 명령들로 또한 구성되는, 이동 디바이스.
  11. 컴퓨팅 디바이스의 프로세서로 하여금,
    세팅 값을 포함하는 네이티브 세팅 오브젝트를 발생시킴으로써, 네이티브 데이터 저장부의 네이티브 노드를 생성하는 단계;
    제 1 파일 타입을 이용하여 키로 상기 네이티브 세팅 오브젝트를 키를 이용하여 메모리에 저장하는 단계로서, 상기 네이티브 데이터 저장부는 상기 제 1 파일 타입과 연관되고, 상기 제 1 파일 타입은 레지스트리에 의해 지원되는, 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 단계;
    상기 네이티브 노드를 상기 레지스트리에 등록시키는 단계;
    넌-네이티브 데이터 저장부의 넌-네이티브 노드를 수신하는 단계로서, 상기 넌-네이티브 데이터 저장부는 상기 레지스트리에 의해 지원되지 않는 제 2 파일 타입과 연관되는, 상기 넌-네이티브 노드를 수신하는 단계;
    커스텀 레지스트리 클래스에 대한 클래스 식별자를 이용하여 상기 레지스트리에 상기 넌-네이티브 노드를 등록시키는 단계;
    상기 세팅 데이터에 대한 요청을 애플리케이션 프로그래밍 인터페이스 (API) 호출의 형태로 애플리케이션으로부터 수신하는 단계;
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는지 또는 넌-네이티브 노드 내에 있는지 결정하는 단계; 및
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터를 획득하기 위해, 레지스트리와 연관된 싱글톤 서비스를 구현하는 단계로서,
    상기 싱글톤 서비스는 상기 네이티브 세팅 오브젝트로부터 상기 요청된 세팅 데이터를 획득하고,
    상기 싱글톤 서비스는 상기 API 로 상기 획득된 세팅 데이터를 리턴하며,
    상기 획득된 세팅 데이터는 상기 API 로부터 상기 애플리케이션으로 상기 세팅 값을 리턴되는, 상기 싱글톤 서비스를 구현하는 단계;
    를 포함하는 단계들을 수행하게 하는 프로세서 실행가능 소프트웨어 명령들이 저장되는, 컴퓨터-판독가능 저장 매체.
  12. 제 11 항에 있어서,
    상기 저장된 프로세서 실행가능 명령들은 상기 프로세서로 하여금 상기 싱글톤 서비스가 네이티브 세팅 오브젝트로의 모든 액세스를 제어하는 단계들을 수행하도록 구성되는, 컴퓨터-판독가능 저장 매체.
  13. 제 11 항에 있어서,
    상기 저장된 프로세서 실행가능 명령들은 상기 프로세서로 하여금,
    상기 요청된 세팅 데이터가 상기 넌-네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 요청된 세팅 데이터를 획득하기 위해 넌-네이티브 프로세스를 구현하는 단계를 더 포함하는 단계들을 수행하도록 구성된, 컴퓨터-판독가능 저장 매체.
  14. 제 11 항에 있어서,
    상기 저장된 프로세서 실행가능 명령들은 상기 프로세서로 하여금,
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하는지 여부를 결정하는 단계; 및
    상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하지 않는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터로의 액세스를 거부하는 단계
    를 더 포함하는 단계들을 수행하도록 구성된, 컴퓨터-판독가능 저장 매체.
  15. 제 14 항에 있어서,
    상기 저장된 프로세서 실행가능 명령들은 상기 프로세서로 하여금,
    상기 네이티브 세팅 오브젝트가 발생되는 경우 상기 특권을 정의하는 단계를 더 포함하는 단계들을 수행하도록 구성된, 컴퓨터-판독가능 저장 매체.
  16. 세팅 값을 포함하는 네이티브 세팅 오브젝트를 발생시킴으로써, 네이티브 데이터 저장부의 네이티브 노드를 생성하는 수단;
    제 1 파일 타입을 이용하여 키로 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 수단으로서, 상기 네이티브 데이터 저장부는 상기 제 1 파일 타입과 연관되고, 상기 제 1 파일 타입은 레지스트리에 의해 지원되는, 상기 네이티브 세팅 오브젝트를 메모리에 저장하는 수단;
    상기 네이티브 노드를 상기 레지스트리에 등록시키는 수단;
    넌-네이티브 데이터 저장부의 넌-네이티브 노드를 수신하는 수단으로서, 상기 넌-네이티브 데이터 저장부는 상기 레지스트리에 의해 지원되지 않는 제 2 파일 타입과 연관되는, 상기 넌-네이티브 노드를 수신하는 수단;
    커스텀 레지스트리 클래스에 대한 클래스 식별자를 이용하여 상기 레지스트리에 상기 넌-네이티브 노드를 등록시키는 수단;
    상기 세팅 데이터에 대한 요청을 애플리케이션 프로그래밍 인터페이스 (API) 호출의 형태로 애플리케이션으로부터 수신하는 수단;
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는지 또는 넌-네이티브 노드 내에 있는지 결정하는 수단; 및
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터를 획득하기 위해, 레지스트리와 연관된 싱글톤 서비스를 구현하는 수단을 포함하고,
    상기 싱글톤 서비스는 상기 네이티브 세팅 오브젝트로부터 상기 요청된 세팅 데이터를 획득하고,
    상기 싱글톤 서비스는 상기 API 로 상기 획득된 세팅 데이터를 리턴하며,
    상기 획득된 세팅 데이터는 상기 API 로부터 상기 애플리케이션으로 상기 세팅 값을 리턴되는, 이동 디바이스.
  17. 제 16 항에 있어서,
    상기 싱글톤 서비스를 구현하는 수단이 네이티브 세팅 오브젝트로의 모든 액세스를 제어하는 수단을 포함하는, 이동 디바이스.
  18. 제 16 항에 있어서,
    상기 요청된 세팅 데이터가 상기 넌-네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 요청된 세팅 데이터를 획득하기 위해 넌-네이티브 프로세스를 구현하는 수단을 더 포함하는, 이동 디바이스.
  19. 제 16 항에 있어서,
    상기 요청된 세팅 데이터가 상기 네이티브 노드 내에 있는 것으로 결정하는 것에 응답하여, 상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하는지 여부를 결정하는 수단; 및
    상기 애플리케이션이 상기 네이티브 세팅 오브젝트에서 특정된 특권을 충족하지 않는 것으로 결정하는 것에 응답하여, 상기 세팅 데이터로의 액세스를 거부하는 수단을 더 포함하는, 이동 디바이스.
  20. 제 19 항에 있어서,
    상기 네이티브 세팅 오브젝트가 발생되는 경우 상기 특권을 정의하는 수단을 더 포함하는,이동 디바이스.
KR1020117012070A 2008-10-29 2009-10-29 운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리 KR101359126B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10938008P 2008-10-29 2008-10-29
US61/109,380 2008-10-29
US12/551,498 2009-08-31
US12/551,498 US8667512B2 (en) 2008-10-29 2009-08-31 Flexible hierarchical settings registry for operating systems
PCT/US2009/062494 WO2010051344A1 (en) 2008-10-29 2009-10-29 Flexible hierarchical settings registry for operating systems

Publications (2)

Publication Number Publication Date
KR20110079762A KR20110079762A (ko) 2011-07-07
KR101359126B1 true KR101359126B1 (ko) 2014-02-06

Family

ID=41404130

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020117012070A KR101359126B1 (ko) 2008-10-29 2009-10-29 운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리

Country Status (6)

Country Link
US (1) US8667512B2 (ko)
EP (1) EP2350820A1 (ko)
JP (1) JP5518884B2 (ko)
KR (1) KR101359126B1 (ko)
CN (1) CN102203731B (ko)
WO (1) WO2010051344A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8667512B2 (en) * 2008-10-29 2014-03-04 Qualcomm Incorporated Flexible hierarchical settings registry for operating systems
US20110145766A1 (en) * 2009-12-15 2011-06-16 International Business Machines Corporation Conveying dense information in an easily consumable format in a visual model
US20120310882A1 (en) * 2011-06-03 2012-12-06 Apple Inc. Key value data storage
US8881179B2 (en) * 2011-11-14 2014-11-04 Microsoft Corporation Cross-platform application programming interfaces for applications
US10025758B2 (en) * 2015-04-27 2018-07-17 Microsoft Technology Licensing, Llc Support for non-native file types in web application environment
US20220309041A1 (en) * 2021-03-23 2022-09-29 Microsoft Technology Licensing, Llc Flexible virtualization of application data for specified system locations
CN115373595B (zh) * 2022-07-21 2023-09-01 华为技术有限公司 存储系统的访问方法、装置、电子设备以及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903753A (en) * 1995-08-18 1999-05-11 International Business Machines Corporation Name space registry with backward compatibility for older applications
US20050246704A1 (en) * 2000-03-09 2005-11-03 Exent Technologies, Ltd. Registry emulation

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6496979B1 (en) * 1997-10-24 2002-12-17 Microsoft Corporation System and method for managing application installation for a mobile device
US6446255B1 (en) * 1999-03-29 2002-09-03 International Business Machines Corporation Global registry object for mapping registry functions and registry equivalent functions across multiple operating systems in a cross-platform program
US6578045B1 (en) * 1999-04-20 2003-06-10 Microsoft Corporation System and method for retrieving registry data
US6347331B1 (en) * 1999-04-26 2002-02-12 International Business Machines Corporation Method and apparatus to update a windows registry from a hetrogeneous server
US6917958B1 (en) * 1999-04-26 2005-07-12 International Business Machines Corporation Method and apparatus for dynamic distribution of system file and system registry changes in a distributed data processing system
US6779179B1 (en) * 2000-03-20 2004-08-17 Exent Technologies, Inc. Registry emulation
AU2001277868A1 (en) * 2000-07-11 2002-01-21 Juice Software, Inc. A method and system for integrating network-based functionality into productivity applications and documents
JP2002182983A (ja) * 2000-12-13 2002-06-28 Sharp Corp データベースへのアクセス制御方法、データベース装置、リソースへのアクセス制御方法、情報処理装置
US7203696B2 (en) 2003-08-29 2007-04-10 Microsoft Corporation Dynamic registry partitioning
US20050091658A1 (en) * 2003-10-24 2005-04-28 Microsoft Corporation Operating system resource protection
US7680758B2 (en) * 2004-09-30 2010-03-16 Citrix Systems, Inc. Method and apparatus for isolating execution of software applications
US8046831B2 (en) * 2005-03-02 2011-10-25 Actiance, Inc. Automating software security restrictions on system resources
US7606833B2 (en) * 2005-04-08 2009-10-20 The Mathworks, Inc. System and method for using an RMI activation system daemon with non-JAVA applications
US8151323B2 (en) * 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
US8171483B2 (en) * 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
US8667512B2 (en) * 2008-10-29 2014-03-04 Qualcomm Incorporated Flexible hierarchical settings registry for operating systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903753A (en) * 1995-08-18 1999-05-11 International Business Machines Corporation Name space registry with backward compatibility for older applications
US20050246704A1 (en) * 2000-03-09 2005-11-03 Exent Technologies, Ltd. Registry emulation

Also Published As

Publication number Publication date
CN102203731A (zh) 2011-09-28
JP5518884B2 (ja) 2014-06-11
WO2010051344A1 (en) 2010-05-06
EP2350820A1 (en) 2011-08-03
US20100138844A1 (en) 2010-06-03
CN102203731B (zh) 2014-04-30
KR20110079762A (ko) 2011-07-07
JP2012507801A (ja) 2012-03-29
US8667512B2 (en) 2014-03-04

Similar Documents

Publication Publication Date Title
US20220308941A1 (en) Sharing extension points to allow an application to share content via a sharing extension
KR101359126B1 (ko) 운영 시스템을 위한 플렉서블한 계층적 세팅 레지스트리
US8850572B2 (en) Methods for handling a file associated with a program in a restricted program environment
US8887152B1 (en) Android application virtual environment
CN107426169B (zh) 一种基于权限的业务处理方法及装置
Heuser et al. {ASM}: a programmable interface for extending android security
US9916475B2 (en) Programmable interface for extending security of application-based operating system
JP4897837B2 (ja) ユーザインターフェースコンポーネントをワイヤレスデバイスにダウンロードするシステムおよび方法
WO2011138852A1 (ja) 情報処理装置、情報処理方法、及びプログラム配信システム
Burns Developing secure mobile applications for android
WO2009058740A2 (en) A language framework and infrastructure for safe and composable applications
EP1416353B1 (en) Communication device, program and recording media
WO2005003969A1 (en) Hybrid system implementing distinct and co-existing application execution environments and methods for implementing the same
US20060117305A1 (en) Method for the secure interpretation of programs in electronic devices
US8732811B2 (en) Systems and methods for implementing security services
Späth Pro Android with Kotlin: Developing Modern Mobile Apps
Dai et al. Roppdroid: Robust permission re-delegation prevention in android inter-component communication
JP4472706B2 (ja) デバイスに特権モードフックを動的に登録するためのシステム
JP5847950B2 (ja) モバイルデバイスのための動的コンテンツインストーラ
CN115828195A (zh) 一种水印嵌入方法、装置、存储介质及电子设备
Dawoud OS Support For Capabilities In Android
Nadkarni Workflow Based Information Flow Control (IFC) in Modern Operating Systems.
Nirmala et al. Android Based Mobile Application Development and its Security

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20161229

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20171228

Year of fee payment: 5

LAPS Lapse due to unpaid annual fee