KR19990071479A - 동적 프로그램 가능 모드 스위칭 장치 드라이버 구조 - Google Patents

동적 프로그램 가능 모드 스위칭 장치 드라이버 구조

Info

Publication number
KR19990071479A
KR19990071479A KR1019980703750A KR19980703750A KR19990071479A KR 19990071479 A KR19990071479 A KR 19990071479A KR 1019980703750 A KR1019980703750 A KR 1019980703750A KR 19980703750 A KR19980703750 A KR 19980703750A KR 19990071479 A KR19990071479 A KR 19990071479A
Authority
KR
South Korea
Prior art keywords
operating system
device driver
interface
module
hardware
Prior art date
Application number
KR1019980703750A
Other languages
English (en)
Other versions
KR100421228B1 (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 KR19990071479A publication Critical patent/KR19990071479A/ko
Application granted granted Critical
Publication of KR100421228B1 publication Critical patent/KR100421228B1/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)
  • Programmable Controllers (AREA)
  • Debugging And Monitoring (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

기능 부 구성요소를 포함하는 제어기 장치의 컴퓨터 인터페이스에 운영 체계(54)를 결합하는 장치 드라이버 구조가 제공된다. 장치 드라이버(50)는 운영 체계 인터페이스(OSI)를 운영 체계(54)에 제공하는 각각의 운영 체계 인터페이스 객체, 제어기 장치의 각 소정의 부 구성요소의 운영 모드를 설정하도록 컴퓨터 인터페이스에 인가될 프로그래밍 값의 생성을 위해 제공하는 각각의 컴퓨터 인터페이스 객체와, 데이터를 처리하여, 소정의 조합에서 다수의 컴퓨터 인터페이스 객체에 호출을 생성시키도록 각 운영 체계 인터페이스 객체에 의해 호출 가능한 처리 루틴의 장치 드라이버 라이브러리를 포함한다. 장치 드라이버 라이브러리는 컴퓨터 인터페이스에 대한 프로그래밍 값의 생성 및 응용을 정의하도록 실행 문맥을 선택한다. 하드웨어 인터페이스의 상태는 가상화되어, 이산 문맥에 유지되고, 선택된 운영 체계 이벤트에 응답하여 장치 드라이버(50)에 본질상 전용 문맥 스위칭을 통해 하드웨어 인터페이스의 상태의 응용 특성 동적 변경을 허용한다.

Description

동적 프로그램 가능 모드 스위칭 장치 드라이버 구조
통상적인 컴퓨터 시스템에서, 소프트웨어 운영 체계는 유틸리티 및 데몬(utility and daemon) 프로그램을 포함하는 응용 프로그램에 범용 시스템 서비스를 제공한다. 이런 시스템 서비스는, 통상적으로 제각기 잘 정의된 하드웨어 인터페이스를 일반적으로 컴퓨터 시스템에 제공하는 무슨 개별 하드웨어 주변 장치가 컴퓨터 시스템에 직간접적으로 부착될 수 있는 것에 액세스한다. 운영 체계내로 통합될 수 있는 소프트웨어 모듈 또는 부품으로 구현된 장치 드라이버는 통상적으로 잘 정의된 소프트웨어 응용 프로그램 인터페이스(APIs)를 각 하드웨어 인터페이스에 대한 응용 프로그램 및 운영 체계에 제공하는 데 이용된다. 장치 드라이버는 종종 비디오 제어기와 같은 특정급의 하드웨어 인터페이스의 특성(specifics)과 응용 프로그램 또는 운영 체계의 상호 작용을 간단하게 할 수 있는 장치 독립도 또는 가상도를 제공한다. 통상적으로, 특정 하드웨어 인터페이스에 기초하여 제각기 구현하기 위하여, 특별한 장치 드라이버는 응용 프로그램 및 운영 체계에 제공되는 다른 공통 API 를 구현하는데 사용된다.
종래의 장치 드라이버 설계 방식에는 본래 많은 문제점이 있다. 첫째로, 종래의 장치 드라이버는 기본 장치 또는 제어기 시스템의 기능과 특정 하드웨어 인터페이스에 특별한 것이다. 따라서, 하드웨어 제어기의 신규 또는 다른 버전(version)이 생성될 때마다, 신규 또는 다른 하드웨어에 동일하게 특별한 신규 장치 드라이버는 또한 개발되어야 한다. 하드웨어 장치의 많은 서로 다른 버전이 있는 곳에, 일반적으로 동일한 수의 장치 드라이버가 개발되어야 한다. 선택적으로, 단일 조합(single combination)장치 드라이버는 소자형 또는 다중버젼을 지원하도록 구성될 수 있다. 그런 장치 드라이버는 통상적으로 또한 서로와 거의 무관한 다중 장치 특정 드라이버를 단일 2진 파일에 합체시킨다.
하드웨어의 특정부를 지원하는 데 요구된 효과적인 많은 장치 드라이버는 또한 하드웨어가 이용될 수 있는 운영 체계 환경에서의 수 및 차에 의존한다. 가장 밀접하게 관련된 운영체제를 제외한 모두에서, 장치 드라이버를 특정 운영 체계에 합체시킬 적당한 능력을 제공하고, 특히, 논리적으로 유사하지만 종종 완전히 다른 API 를 운영 체계 및 응용에 제공하기 위해서는 장치 드라이버를 실제로 재개발할 필요가 있다. 보통, 장치 드라이버의 API 에 대한 상세 정의는 장치 드라이버 그 자체의 상세 설계를 결정한다. 따라서, 다른 운영 체계를 제외한 동일한 하드웨어에 대한 장치 드라이버는 종종 거의 완전히 독립적으로 개발된다.
특정 하드웨어 제어기를 지원하는 데 요구되는 장치 드라이버의 수에 영향을 주는 다른 동기는 특정 제어기에 접속되는 다른 하드웨어 및 시스템의 본성으로 부터 일어난다. 다시 말하면, 컴퓨터 시스템의 상세 구성에 유연성을 제공하기 위하여, 하드웨어 제어기는 명백히 다른 많은 동작 모드를 지원할 수 있다. 예를 들면, 비디오 제어기는 상당한 범위의 비디오 표시 해상도 및 색농도를 지원할 수 있다. 그러나, 이런 범위는 특정 비디오 제어기상에 실제 구현된 비디오 RAM 량과 같은 한도(limitations)에 의해 직접적으로 제한되고, 부착된 비디오 디스플레이의 최대 수직 및 수평 주파수에 의해 간접적으로 제한될 수 있다. 특정 응용의 요구사항(requirements)은 또한 장치 드라이버에 의해 지원될 수 있는 특정 운영 모드의 선택을 드라이버할 수 있다. 통상적으로, 많은 장치 드라이버에는 하드웨어 제어기가 제공되는 데, 제각기 서로 다른 세트의 하나 이상의 운영 모드를 지원한다. 그래서, 제공된 장치 드라이버중 하나는 직접적으로 특정 컴퓨터 시스템의 구성에 기초한 운영 체계 합체를 위해 선택되어야 한다. 운영 모드의 바람직한 세트를 지원하는 장치 드라이버를 픽(pick)하는 어려움을 제외하고는, 서로 다른 개별 장치 드라이버가 지원할 수 있는 각종 모드를 선점하여 결정할 시에 실제 어려움이 있다. 개별 드라이버가 적당한 소정량만큼만 다를 수 있지만, 이의 수는 개발에 관하여 중요할 수 있다.
두 번째 문제점은 얼마간 첫 번째 문제점의 결과로서 각 장치 드라이버가 상업적으로 허용 가능한 운영을 확실하게 하도록 장치 드라이버를 이용할 수 있는 각종 환경내에서 철저히 검사되어야 한다는 것이다. 통상적으로, 장치 드라이버는 본질상 운영 체계내에 완전히 합체되는 모놀리식 소프트웨어 모듈이다. 그와 같이, 특정 운영체제에 대한 장치 드라이버의 약간의 변경조차 테스트하기 위해서는 완전 스위트(suite)의 운영 기능 및 응용 호환성 테스트가 장치 드라이버의 정확한 운영을 검증하도록 실행되어야 한다. 선택적인 기능 테스팅은 모놀리식 코드 장치 드라이버의 소정의 수정으로 부터 유발된 부수적인 운영 에러의 실 가능성으로 인해 부적당하다. 통상적으로 꽤 복잡한 하드웨어 제어기를 위해 지원된 실제로 다른 장치 드라이버의 실제수와 대응 테스트 스위트의 사이즈 및 실제 범위가 주어질 경우, 장치 드라이버의 테스팅은 실제로 비용이 많이 들고, 상당히 시간이 오래 걸려, 신규 또는 개선된 버전의 제품이 시장에 나오기 어렵다.
종래의 장치 드라이버 설계에 따른 세 번째 문제점은 실제 정적(static) 유형의 하드웨어 제어기 관리를 제공한다는 것이다. 일반적으로, 장치 드라이버는 장치 드라이버에 의해 관리되는 하드웨어 제어기에 대한 단일 세트의 운영 파라미터를 설정한다. 컴퓨터 시스템상에서 실행되는 응용 프로그램 및 운영체제는 모두 이런 정적 모드의 파라미터를 허용해야 하거나, 본질적으로 정확히 운영하지 못한다.
제한된 경우에, 종래의 장치 드라이버는 응용 프로그램으로 소정의 모드를 유용하게 하거나 가시적이게 할 수 있다. 그래서, 이런 모드를 이용하기 위하여, 장치 드라이버는 본질상 컴파일인(compiled-in) 하드웨어 종속성을 갖도록 응용 프로그램에 의존한다. 그런 경우에, 모드 스위치를 불러낼 수 있을지라도 소정의 그런 스위치를 효과적으로 알지 못하는 다른 실행 프로그램상의 잠재적인 유해한 효과를 갖는 한이 있더라도 응용 프로그램은 모드 변경을 불러낼 수 있다.
통상적인 몇몇 다중 작업(muti-tasking) 운영 체계는 단지 운영 체계 지원 상태 변경을 통하는 한이 있더라도 제한된 동적 하드웨어 제어기 모드 스위칭을 수행할 수 있다. 이런 경우에, 운영 체계는 본질적으로 신규 운영 모드의 상태와 일치하는 장치 드라이버 및 하드웨어 제어기의 상태를 재적재(reload)한다. 그러나, 응용 실행과 장치 드라이버 및 하드웨어 제어기의 상태 사이에는 직접적인 관련이 없다. 다시 말하면, 소정의 실행 응용은 주로 소정의 모드 스위치를 완전히 모르지 않을 경우에 관계한다. 결과적으로, 선택된 모드는 소정의 실행 응용에 최적일 수 있지만, 반드시 현재 실행 포커스(focus)를 가진 응용이 아니다.
발명의 요약
따라서, 본 발명의 일반적인 목적은 동적 재구성 토대위에 독립 하드웨어 구성 옵션을 제공할 수 있는 플렉시블 모듈러 장치 드라이버를 제공하는 것이다.
이는 본 발명에서 장치 드라이버 구조를 제공함으로써 성취되는 데, 이런 구조는 프로세서를 가진 컴퓨터 시스템의 메모리내에 제공되어, 다수의 기능적 부구성요소(sub-element)를 포함하는 제어기 장치의 컴퓨터 인터페이스에 운영 체계를 커플하도록 운영한다. 장치 드라이버는 운영 체계 인터페이스(OSI)를 운영체제에 제공하는 각각의 다수의 운영 체계 인터페이스 객체(objects), 제어기 장치의 각 예정된 부구성요소의 운영 모드를 설정하도록 컴퓨터에 인가될 프로그래밍 값을 생성시키기 위해 제공하는 각각의 다수의 컴퓨터 인터페이스 객체와, 데이터를 처리하여, 예정된 조합의 다수의 컴퓨터 인터페이스 객체에 호출을 생성시키도록 다수의 운영 체계 인터페이스 객체의 각각에 의해 호출 가능한 처리 루틴의 장치 드라이버 라이브러리(library)를 포함한다. 장치 드라이버 라이브러리는 컴퓨터 인터페이스에 대한 프로그래밍 값의 생성 및 응용을 정의하도록 실행 문맥을 선택하게 한다.
본 발명의 잇점은 하드웨어 인터페이스의 상태 및, 그에 따라 하드웨어 인터페이스를 제공하는 제어기의 상태가 가상화되어, 이산(discrete) 문맥으로 유지단되는 것이다. 개별 응용 프로그램에 의해 조절되거나 관리되는 제어기의 운영 특징 또는 모드는 본 발명의 운영으로 가상화될 수 있다. 본 발명은 장치 드라이버의 운영으로 구현된 본질상 전용(private) 문맥 스위칭을 통해 하드웨어 인터페이스의 상태의 응용 특정 동적 변경을 위해 제공한다. 선택된 운영 체계 이벤트(events)는 장치 드라이버에 의해 문맥간의 동적 스위칭 및 신규 문맥의 생성을 초기화하도록 수정되거나 트랩(trap)된다.
본 발명의 다른 잇점은 장치 드라이버가 제어기에 의해 장치 드라이버를 통해 지원된 기능의 포괄적인 최적화를 위해 제공하는 것이다. 장치 드라이버는 이에 의해 지원된 API 호출 인터페이스의 가상화를 위해 제공한다. 운영 체계 인터페이스 객체의 이용을 통한 호출 인터페이스의 가상화를 독립적으로 정의된 API 에 특정 지원을 하고, 거의 공통 실행 스트림(streams)에 의해 지원될 기능상 등가 호출문을 번역한다.
본 발명의 다른 잇점은 장치 드라이버의 호출 인터페이스의 가상화가 구조적으로 API 호출문 및 그의 파라미터를 공통 평가하여, 본질상 공통 실행 스트림내에서 연속 파라미터 체크를 위한 소정의 요구 사항을 제거한다는 것이다. 문맥 데이터 구조의 포인터 참조(pointer referencing)와 커플된 결과적 거의 선형 실행 스트림은 종래의 모놀리식 장치 드라이버내에서 성취 가능한 것보다 실재 더 큰 기능성을 인에이블할 동안 확실히 유효 실행 성능을 갖게 한다.
본 발명의 또다른 잇점은 장치 드라이버가 거의 선형 실행 시트림의 문맥 종속 변경을 위해 제공한다는 것이다. 문맥간에 스위칭을 인에이블하거나 지원하는 데 요구된 변환 기능은 변환 기능이 수행될 필요가 있는 지를 결정하기 위해 반복 테스팅을 최소화하도록 기능을 실행 스트링내에 직접 링크 함으로써 지원된다.
본 발명의 또다른 잇점은 장치 드라이버가 하드웨어 인터페이스를 통해 접근 가능한 특정 제어기 구성을 지원하는 데 필요하거나 최적인 필수 기능 객체의 동적 적재 및 구성을 내장하는 것이다. 장치 드라이버는 하드웨어 인터페이스를 통해 성취되거나 제어기를 구성하는 독립 기능 부구성요소를 식별하도록 제어기로 부터 성취된 엔코드된 구성 데이터에 응답하고, 부 구성요소를 지원하는 데 적당한 대응 세트의 하드웨어 인터페이스 객체를 결정하며, 장치 드라이버의 초기화 부분으로서 객체 세트내에 동적으로 적재 및 링크한다.
본 발명의 또다른 잇점은 장치 드라이버가 하드웨어 인터페이스를 통해 접근 가능한 특정 제어기 구성을 지원하는 데 필요하거나 최적인 필수 기능 객체의 동작 적재 및 구성을 내장하는 것이다. 장치 드라이버는 하드웨어 인터페이스를 통해 성취되거나 제어기를 구성하는 독립 기능 부구성요소를 식별하도록 제어기로부터 성취된 엔코드된 구성 데이터에 응답하고, 부구성요소를 지원하는 데 적당한 대응 세트의 하드웨어 인터페이스 객체를 결정하며, 장치 드라이버의 초기화 부분으로서 객체 세트내에 동적으로 적재 및 링크한다.
본 발명의 또다른 잇점은 장치 드라이버가 소정의 기능 또는 운영 양상에 간해 프로그램 가능한 각종 하드웨어 인터페이스 객체를 지원하는 것이다. 하드웨어 인터페이스를 통해 성취되거나 제어기로 부터 성취된 엔코드된 구성 데이터에 의해, 장치 드라이버는 시스템 메모리 부터 구성 데이터를 식별하고, 적재하여, 하드웨어 인터페이스 객체가 대응 부구성요소를 지원하는 방법의 상세 사항을 정의하는 운영 구성 데이터를 가진 하드웨어 인터페이스 객체를 프로그램한다.
본 발명의 또다른 잇점에 따르면, 장치 드라이버는 신규 하드웨어 인터페이스 객체가 장치 드라이버의 다른 구조적 구성요소 및 다른 하드웨어 인터페이스 객체로 부터 거의 분리하여 생성될 수 있는 설정된 구조를 제공하는 것이다. 하드웨어 인터페이스 객체의 구조적 설계는 또한 대응 하드웨어 인터페이스 객체를 프로그램하는 데 이용된 운영 구성 데이터의 재정의를 통해 실재 구성 교정 및 증진을 이루어지게 한다. 교정 또는 신규 제어기 부구성요소를 지원할 장치 드라이버의 수정은 부구성요소 대응 하드웨어 인터페이스 객체에 대한 준비 소스 코드 수정에 대립되는 것으로서 구성 데이터 파일이 간단히 편집으로 제한될 수 있다. 어느 경우에, 호환성 테스팅은 제어기의 교정 또는 신규 부구성요소를 지원하는 특정 하드웨어 인터페이스 객체를 테스트함으로서 적당히 제한될 수 있다.
본 발명의 또다른 잇점은 장치 드라이버가 비디오 디스플레이 제어기에 의해 현재 지원된 색농도의 일관성 보고를 실시하도록 운영 체계의 수정을 위해 제공하는 것이다. 서로 다른 색 농도 문맥은 하나 이상의 실행 응용의 최대 허용 가능한 색농도에 대응하는 각 문맥에 따른 실행 응용의 세트를 위해 설정된다. 문맥이 변경될 시와, 응용의 최대 색 농도가 비디오 디스플레이 제어기의 색농도 능력을 초과하는 곳에서, 적당한 선형 실행 스트림으로 링크된 색농도 변환 기능은 디스플레이 데이터 색농도 변환을 위해 제공한다.
본 발명은 일반적으로 코어 운영 체계(core operating system) 및 통상적인 하드웨어 장치 사이에 인터페이스를 정의(define) 및 설정하도록 컴퓨터 운영 체계내에 활용된 장치 드라이버의 설계에 관한 것으로써, 특히, 정보 표시 기능을 포함한 운영 체계 기능을 지원하는 통상적인 하드웨어 장치를 동작시키도록 가상화 문맥 교환 가능 인터페이스(virtualized context switchable interface)를 제공하는 모듈러 장치 드라이버 구조에 관한 것이다.
본 발명의 상기 및 다른 잇점과 특징은 첨부한 도면을 참조하여 본 발명의 아래의 상세한 설명에 따라 더욱 더 이해하게 되며, 여기서 동일 참조 번호는 동일 부분을 나타낸다.
도 1 은 본 발명에 따라 구성된 컴퓨터 시스템의 구성 블록도이다.
도 2 는 본 발명의 장치 드라이버의 초기화동안 본 발명의 구조적 구성의 구성 블록도이다.
도 3 은 본 발명의 초기화의 상세 흐름도이다.
도 4 는 본 발명의 장치 드라이버의 런(run)시간 실행동안 본 발명의 구조적 구성의 구성 블록도이다.
도 5a 는 장치 드라이버 문맥을 정의하는 다수의 셀(shell) 객체, 셀 라이브러리 및, 본 발명의 양호한 실시예에 다른 운영 체계의 물리적 장치 구조간의 관계의 일반적 예시도이다.
도 5b 는 본 발명의 양호한 실시예에 따른 하드웨어 인터페이스 객체의 다수의 사례화(instantiations)간의 관계의 일반적 예시도이다.
도 6a 는 본 발명의 양호한 실시예에 다라 문맥 스위치를 준비하는 단계를 수행함을 기술한 흐름도이다.
도 6b 는 본 발명의 양호한 실시예에 따른 신규 문맥을 실현함에 활용된 단계를 기술한 흐름도이다.
도 7 은 본 발명에 따라 구성된 장치 드라이버의 운영을 종료함에 활용된 단계의 소프트웨어 흐름도이다.
도 8 은 본 발명에 따른 운영 체계내에서 실행하는 다중 가상 머신을 지원하여 본 발명의 실제 및 가상 구조적 구성 양자의 이용을 설명한 블록도이다.
도 9 는 본 발명에 따라 구성된 가상 장치 드라이버의 구조적 구성의 구성 블록도이다.
I. 하드웨어 시스템 조사
본 발명의 활용하는 데 적당한 컴퓨터 시스템(10)은 도 1 에 도시된다. 컴퓨터 시스템(10)은 양호하게도 시스템 데이터 버스(14)를 통해 주 메모리(16) 및 대용량 기억 주변기기(18)에 결합된 중앙 처리 유니트(cpu)(12)를 포함하고, 디스크 드라이브 제어기 및 하드 디스크 드라이브 유니트를 포함한다. 본 발명을 위하여 대용량 기억 주변기기(18)의 운영은 지원된 기능이 비휘발성 자원으로 부터 소정의 실행 가능한 데이터 및 구성 파일을 판독할 경우에는 충분하다. 따라서, 대용량 기억 주변 기기(18)는 통상적으로 파일 지향 구성내에서 컴퓨터 시스템(10)에 의해 판독가능한 데이터의 기억을 위해 제공하는 외부 또는 원경 장치나 시스템으로 접근하는 통신 제어기일 수 있다.
비디오 디스플레이 제어기(19)는 또한 시스템 버스(14)에 결합된 주변 장치로서 제공된다. 비디오 디스플레이 제어기(19)의 하드웨어 구현은 일반적으로 사실상 본 발명을 위하여 통상적으로 이루어진다. 그러나, 본 발명의 문맥에서, 비디오 제어기(19)는 제어기(19)로 구성되는 논리적 독립 부구성요소의 집합체로서 유일하게 기술된다. 부구성요소는 특히 일반적 독립 운영 프로그램 가능성에 관한 기능 아이텐티티(identity)에 의해 논리적으로 구별된다. 즉, 제어기(19)의 하드웨어 구현의 기능 디비전(divisions)은 주로 본 발명을 위하여 제어기(19)의 분리 부구성요소를 정의한다.
부구성요소를 구별하기 위한 다른 근거는 cpu(12)의 프로그램 실행에 의해 결과로서 대응 부구성요소를 프로그래밍하는 방식으로 공통성(commonality)에 의해 기능의 그룹핑(grouping)이다. 따라서, 일반적으로 도 1 에 도시된 바와 같이, 비디오 제어기(19)의 부구성요소는 양호하게도 비디오 디스플레이 버퍼(20), 디지털-아날로그 변환기(DAC)(22), 비디오 그래픽 가속기(24), 비디오 제어기(26), 프로그램 가능 클록 발생기(28), 하드웨어 커서 제어기 및 코더-디코더 유니트(CODEC)를 포함하지만, 여기에 제한되지는 않는다. 제어기(19)의 부구성요소의 각각은 시스템 버스(14)에 적당히 결합되는 하드웨어 레지스터 인터페이스(30)를 통해 비교적 독립적으로 프로그램 가능하다. 따라서, cpu(12)는 부구성요소(20, 22, 24, 26, 28)로 부터 정보를 프로그램하고 성취할 수 있다. 레지스터 인터페이스(30) 및 하나 이상의 부구성요소는 실제적인 문제로서 단일 집적 회로상에 물리적으로 상추(resdent)할 수 있다. 단일 집적 회로상의 부구성요소의 공동상주(co-residency), 또는 부구성요소가 다른 부 구성요소를 통해 접근 가능한 가능성은 부 구성요소를 서로 구별하는 가능성이 영향을 주지 않는다.
부 구성요소(20 내지 28)를 프로그래밍함으로써, 비디오 디스플레이(32)는 텍스트(textual) 및 그래픽 정보를 제공하기 위해 지원된다. 본 발명의 양호한 실시예에서, 다중 디스플레이 윈도(34, 36)는 디스플레이(32)상에서 가시적인 현재 능동 또는 "포커스" 디스플레이 윈도를 선택하는 데 이용될 수 있는 포인터(38)와 조합하여 지원된다. 디스플레이 윈도(34, 36)는 많은 이산 이벤트를 통해 현재 포커스를 성취할 수 있다. 이런 이벤트는 컴퓨터 시스템(10)에 의해 실행하기 위한 신규 응용 프로그램의 란칭(launching)을 포함한다. 디폴트(default)에 의해 신규 란치(launched) 응용의 주 윈도는 디스플레이(32)의 현재 포커스를 성취한다. 포인터(38)를 또한 활용하여, 예를 들어 마우스를 누름과 동시에 포커스를 수신할 수 있는 윈도(34, 36)를 선택할 수 있다. 최종으로, 디스플레이 인도(34, 36)는 다른 응용의 종료와 동시에 포커스를 수신할 수 있다. 이런 각 상황에서, 운영 체계의 실행을 통해 cpu(12)가 작용할 수 있는 포커스 이벤트가 생성된다.
다른 주변기기(40)는 또한 컴퓨터 시스템(10)의 구성 요소로서 존재한다. 이런 다른 주변기기(40)는 복잡한 제어기 지원 오디오, 실시간 비디오 및 단지 다른 복잡한 다기능 동작 또는 서로 조합한 그런 동작을 포함한다. 제어기의 기능 동작 및 구성이 cpu(12)에 의해 직간접적으로 프로그램 가능한 다수의 기능 소자로 적당히 세분되는 경우에 그런 복잡한 제어기는 본 발명에 의해 효과적으로 지원될 수 있다. 예를 들면, 시스템 버스(14)에 제공된 레지스터 인터페이스 처럼 모두 직간접적으로 표시되는 웨이브테이블(wavetable) 합성, FM 합성, 균등화(equalization) 제어기, 반향 제어기 및 다채널 증폭기 부 구성요소를 제공하는 고성능 오디오 부시스템은 본 발명에 의해 최적으로 지원될 수 있다.
II. 소프트웨어 시스템 조사
본 발명이 소정수의 부 구성요소를 가진 소정의 주변 제어기를 쉽게 지원할 수 있지만, 본 발명은 양호한 실시예에서 비디오 디스플레이 제어기(19)의 지원 및 제어에 적용되는 것으로 최상 이해될 수 있다. 도 2 에서, 본 발명의 양호한 장치 드라이버(50)의 실시예는 비디오 디스플레이 제어기(19)의 레지스터 인터페이스(30)에 대한 장치 드라이버의 논리적 케넥션을 나타내는 하드웨어 인터페이스와 운영 체계 계층(layer)(54)사이에 위치되는 것으로 도시된다. 운영 체계 계층(54)은 통상적으로 운영 체계 커널(kernel)(56) 및, 소정의 기본 운영 체계 레벨 기능성을 부가하는 하나 이상의 운영 체계 확장부(extensions)(58)를 포함한다. 최종으로, 운영 체계 계층(54)은 번갈아 하나 이상의 응용 프로그램(60)을 지원할 수 있다.
운영에 있어서, 응용 프로그램(60)은, 응용(60)에 의해 호출될 수 있는 한 세트의 실행 진입점으로서 효과적으로 제공되는 응용 프로그램 인터페이스(API)를 통해 운영 체계 계층(54) 지원 서비스를 성취한다. 본 발명의 일 실시예에 따르면, 운영 체계 커널 API 호출점의 작은 서브세트(62)는 장치 드라이버(50)의 초기화 동안 수정된다. 이런 수정된 호출점은 윈도 포커스 변경 이벤트를 응용(60)에 보고하는 진입점 구틴 및, 디스플레이(32)의 현재 색농도를 응용(60)에 되돌아 보고하는 진입점 루틴을 포함한다. 포커스 변경 이벤트는 양호하게도 포커스 변경 이벤트에 응답하여 부가적인 이벤트 처리를 위해 제공하는 운영 체계 확장부(58)에 대한 API 호출을 포함하도록 수정된다. 이런 부가적인 이벤트 처리는 일반적으로 포커스 이벤트의 결과로서 란치될 수 있는 응용의 실행 환경을 정량화하는(quantifying) 데이터를 성취하도록 구성 검색을 수행한다. 검색된 데이터는 양호하게도 란치된 응용에 바람직한 스크린 해상도 및 색 농도 구성을 포함한다.
소정의 응용(60)에 의해 요구된 최대 색농도가 디스플레이(32)의 현재 색농도일 시에 응용(60)에 확실히 보고되도록 색농도 보고 루틴을 수정한다. 띠라서, 본 발명의 양호한 실시예에 따르면, 모든 응용(60)은 특히 색농도에 관해 디스플레이(32)의 완전 가상화 표현(representation)에 대비하여 실행한다. 즉, 요구된 색농도가 다른 응용(60)에 의해 조절될 수 있는 최대 색농도 또는 디스플레이(32) 그 자체의 최대 색농도를 초과하는 여부에 관계없이 장치 드라이버(50)는 색농도가 응용(60)에 의해 요구되는 것에 전 지원을 제공한다.
1. 장치 드라이버 소프트웨어 구조 - 상위 레벨
진입점을 가진 운영 체계 커널(56) 및 소정의 확장부(58)를 장치 드라이버(50)에 제공하는 운영 체계 API(o/s API)를 통해 커널 계층(54)은 장치 드라이버(50)에 접속한다. 장치 드라이버(50)내에는 o/s API 가 먼저 다수의 운영 체계 인터페이스 모듈에 의해 지원되며, 상기 모듈은 그래픽 디스플레이 인터페이스(G야) 모듈(64), 다이렉트 드로(Draw)(DD) 모듈(66) 및 소정수의 다른 모듈(68)을 포함하며, 이는 제각기 다이렉트 3D(D3D)와 같은 현재 또는 미래 정의 API 를 나타낸다. 부가적인 API 진입점은 운영 체계(o/s) 모듈(70), 그래픽 인터페이스(GRX) 모듈(71) 및 셀 모듈(72)에 의해 제공된다. 이런 모듈은 합체 필수적으로 장치 드라이버(50)의 o/s API 를 구성하는 모든 호출 가능 진입점을 제공한다.
셀 모듈(72)은 시스템 가동 동안 운영 체계 커널(56)의 초기화의 부분으로서 메모리(16)내에 적재된 장치 드라이버(50)의 초기 구성 요소이다. 마이크로소프트 MS-윈도 95TM과 같은 종래의 운영 체계에서, 운영 체계 커널(56)은 MS-윈도 95 레지스트리(registry)서비스와 같은 표준 초기화 구성 파일 또는 데이터 베이스내의 참조의 결과로서 셀 모듈(72)을 메모리(16)내에 적재한다.
셀 모듈(72)에 의해 제공된 초기화 진입점은 운영 체계 커널(56)이 장치 드라이버(50)의 장치 드라이버 특정 초기화를 개시하게 한다. 이런 초기화의 부분으로서, 셀 모듈(72)은 보드(Board) 드라이버, 하드웨어 인터페이스 모듈 세트 및, 운영 체계 인터페이스 모듈의 컴플리먼트(compliment)를 결정하며, 이는 장치 드라이버(50)에 의해 운영 체계 계층(54)에 제공되는 o/s API 를 지원하도록 장치 드라이버(50)의 구현을 완료하는데 요구된다. 양호한 실시예에서, 이런 결정된 부가적 모듈은 셀 모듈(72)에 정적으로 링크되지 않을 경우에 동적으로 적재되어, 장치 드라이버(50)내에 논리적으로 링크된다.
장치 드라이버(50)의 초기화를 위한 지원 서비스를 획득할 필요가 있을 시에 o/s API 에 대한 호출 인터페이스를 설정하기 위하여, 적어도 운영 체계 모듈(70)은 셀 모듈(72)의 정수부 또는 구성 요소로서 적재한다. 양호하게도, GRX 모듈(71)은 또한 셀 모듈(72)로 적재된다. 편의상, 통상 이용된 다른 디폴트 운영 체계 인터페이스 모듈은 또한 운영 체계 모듈(70)에 정적으로 링크될 수 있다.
특히, GDI(64), DD(66) 및 D3D(68) 모듈로 명시된 바와 같이, 본 발명의 장치 드라이버(50)는 양호하게도 운영체제 커널(56) 및/또는 운영 체계 확장부(58)의 특정부에 특별한 분리 유니트내의 장치 드라이버(50)의 o/s API 를 구현한다. 따라서, 양호한 실시예에서, GDI 모듈(64)은 양호하게도 MS-윈도 '95TM제품을 위해 마이크로소프트에 의해 선정된 플랫 모델 DIBEngine 드라이버 인터페이스를 지원한다. 마찬가지로, 디이렉트 드로모듈(66)은 표준 다이렉트 드로 API 를 위한 하드웨어 독립 인터페이스를 지원한다. D3D 모듈(68)은 윈도 95TM에 대해 발표된 마이크로소프트 다이렉트 3D API 를 지원한다. 이런 API 의 각각에 대한 문서는 마이크로소프트 소프트웨어 디벨로프먼트 키트(SDK) 및 마이크로소프트 디바이스 드라이버 키트(DDK)의 부분으로 이용할 수 있고, 워싱턴 레드몬드 소재의 마이크로소프트사의 상업적 제품으로서 이용할 수 있다. 따라서, 본 발명의 동적 적재 능력은 장치 드라이버(50)에 의해 제공된 포괄적인 API 지원으로 하여금 부가적인 운영 체계 인터페이스 모듈의 동적 적재를 통해 적용되고 확장되게 한다.
장치 드라이버(50)의 운영을 통해 재래식 및 독점(conventional and proprietary) 지원 기능을 지원할 필요가 있을 시에 o/s 및 GRX 모듈(70, 71)을 포함하는 셀 모듈(72)은 약정 및 독점 API 인터페이스 부분을 운영 체계 계층(54)에 제공한다. 재래식 API 부분은 메모리(16)내로 적재함과 동시에 운영 체계 계층(54)이 셀 모듈(72)의 초기화를 개시하게 하는 초기화 진입점을 포함한다. 일반적인 표준 종료 호출 진입점은 또한 제공된다. 이런 진입점은, 운영 체계 계층(54)의 차단(shutdown)이 임박하고, 장치 드라이버가 규칙적으로 종료될 필요가 있는 장치 드라이버(50)를 운영 체계 계층(54)이 신호화하게 한다.
셀 모듈(72)에 의해 제공된 독점 API 진입점은 디스플레이(32)상에 제공된 현재 데스크탑(desktop), 장치 드라이버(50)의 운영을 정의하는 소정의 데이터 및 현재 뷰포트(viewport)를 정의하는 데이터의 판독 및 기록을 위해 제공하는 진입점을 포함한다. 이런 후자 정보는 디스플레이(32)의 현재 물리적 색농도, 디스플레이 포인터(38)의 현재 색 및 패턴과, 장치 드라이버(50)의 인터페이스(interlace), 비디오 동기 타입, 비디오 고속 스크롤(scroll) 및 색 인에이블 옵션과 같은 많은 비디오 하드웨어 특정 양상을 세트시킬 수 있다.
최종으로, 운영 체계 모듈(72)은 기본 운영 체계 서비스를 획득하도록 운영 체계 계층(54)을 호출하는 장치 드라이버 지원 루틴을 제공한다. 본 발명의 양호한 실시예에서, 이런 시스템 서비스는 메모리 할당, 사전 할당된 메모리의 프리잉(freeing), 동적 링크 라이브러리의 적재 및 비적재, 실메모리내의 메모리 객체를 실행할 수 있거나 로크(lock)하고, 메모리 객체의 실행 가능 또는 로크 상태를 디스에이블하며, 정의된 I/O 어드레스로 데이터를 판독 및 기록하며, 그리고 통상적으로 대용량 기억 주변기기(18)에 의해 기억되는 바와 같이 명명된 데이터 파일을 개방, 판독 및 폐쇄하도록 메모리 객체를 인에이블하는 것과 같은 메모리 관리 기능을 포함한다.
2. 장치 드라이버 소프트웨어 구조 - 하위 레벨
셀 모듈(72)은 또한 비디오 디스플레이 제어기(19)의 특정 경우에 관해 장치 드라이버(50)의 동적 구성을 제공한다. 기능상 유사한 많은 소정의 비디오 디스플레이 제어기(19)가 컴퓨터 시스템(10)내에서 활용될 수 있지만, 본 발명의 장치 드라이버(50)는 특정 비디오 디스플레이 제어기(19)의 하드웨어 특성을 최적으로 지원하도록 장치 드라이버(50)내로의 보드 드라이버(74)의 동적 선택 및 내포(inclusion)를 위해 제공한다. 셀 모듈(72)은 소정수의 가변부(variants)중에서 특정 보드 드라이버(74)를 선택하며, 이런 드라이버(74)는 특정 비디오 디스플레이 제어기(19)의 주요 양상에 대응한다.
사실상, 특정 비디오 디스플레이 제어기(19)의 주요 양상은 제어기(19)의 구현에 이용된 집적 회로 그래픽 가속기 칩 또는 칩 세트의 특정 구조이다. 따라서, 단일 보드 드라이버(7)는 디스플레이 제어기(19)의 특정 가변부의 정의된 패밀리에 대응할 수 있다. 다른 보드 드라이버는 서로 다른 정의의 제어기의 다른 패밀리에 대응하도록 구성될 수 있다.
보드 드라이버(74)는 한세트의 하드웨어 인터페이스 모듈의 선택적 지원으로 장치 드라이버(50)의 동적 구성의 부가적인 계층을 제공한다. 이런 하드웨어 인터페이스 모듈은 장치 드라이버(50)의 구성 소자로서 동적으로 적재 가능하고, 비디오 디스플레이 제어기(19)의 특정 구현의 개별 부 구성요소에 실재 대응한다. 본 발명의 양호한 실시예에서, 하드웨어 인터페이스 모듈의 세트는 클록 모듈(76), DAC 모듈(78), CODEC 모듈(80), 하드웨어 커서 지원 모듈(82), 비디오 모듈(84), 2차원 그래픽 제어 모듈(86) 및 3차원 그래픽 제어(3D) 모듈(88)을 포함한다. 장치 드라이버(50)내로 동적 적재된 하드웨어 인터페이스 모듈의 특정 세트는 비디오 디스플레이 제어기(19)의 구현에 제공된 특정 보 소자에 대응하여 보드 드라이버(74)에 의해 결정된다. 즉, 클록 부 구성요소(28)의 특정 구현에 의존하여, 특정 및 대응 클록 모듈(76)은 보드 드라이버(74)에 의해 식별되고, 장치 드라이버(50)내에 동적으로 적재된다. 결과적으로, 예를 들면, 비디오 디스플레이 제어기(19)의 일반적 현존 설계로의 DAC 부 구성요소(22)의 신규 버전의 내포는 본질상 장치 드라이버(50)의 DAC 모듈(78)만의 기능성의 대응 교정으로 즉시 이루어질 수 있다. 따라서, 동적 적재 가능한 모듈로의 장치 드라이버(50)의 부 구성요소 특정 양상의 분할은 장치 드라이버(50)의 최종 구성 수행 및 운영의 상당한 교정으로 하여금 장치 드라이버(50)의 나머지로 부터 분리하게 한다. 그런 하드웨어 특정 변경부는 또한 다른 하드웨어 인터페이스 모듈 및, 장치 드라이버(50)의 상위 계층에서 효과적으로 분리된다. 그래서, 디스플레이 제어기(19)의 신규 버전에 대한 장치 드라이버(50) 구성의 테스팅은 특정한 신규 또는 교정된 하드웨어 인터페이스 모듈에 대해서만 신뢰있게 행해질 수 있다.
사실상, 소정의 하드웨어 인터페이스 모듈은 보드 드라이버(74)에 정적으로 링크될 수 있다. 모듈의 기본 컴플리먼츠가 특정 보드 드라이버(74)로 거의 항상 이용되는 곳에서, 보드 드라이버(74)와 함께 모듈을 적재함으로써 최적화가 이루어진다. 정적 링크된 모듈의 연속 이용은 대응 부 구성요소를 지원하기 위해 동적 링크 가능한 모듈을 제공함으로써 효과적으로 무효화될 수 있다. 동적 적재된 모듈은 양호하게도 대응 정적 링크된 모듈 이상으로 이용된다.
III. 장치 드라이버 초기화
본 발명의 장치 드라이버(50)를 초기화하는 프로세스는 일반적으로 도 3 에서 설명된다. 이런 초기화 프로세스는 MS-윈도 95TM운영 체계로 운영하는 양호한 실시예에 관해 기술된다.
1. 초기 상위 레벨 초기화
운영 체계 초기화의 통상적인 실행에 관하여, 셀 모듈(72)은 레지스트리 서비스 데이터베이스 파일내의 통상적인 시스템 드라이버 레퍼런스의 결과로서 90을 메모리(16)내에 적재시킨다. 메모리내에 일단 상주하면, 장치 드라이버 종속 초기화를 개시하도록 셀 모듈(72)의 초기화 진입점으로 호출이 행해진다. 셀 모듈(72)의 초기화 루틴은 셀 객체(126)(SHELLOBJ)의 생성부(creation)(92)를 제공하고나서, (93)에서 운영체제 객체(128)(OSOBJ)를 제공한다.
셀 객체는 장치 드라이버(50)의 구조와 함께 논리적으로 링크하는 최상위 레벨 데이터 구조로서 이용된다. 셀 객체의 중요 요소는 표 I 에서 식별된다.
표시된 바와 같이, 셀 객체는 소정의 글로벌 플래그 데이터, API 호출 진입점, 장치 드라이버(50)의 구성 요소를 나타내는 고 레벨 소프트웨어 객체에 대한 포인터와, 장치 드라이버(50)의 내부 운영을 지지하는 데 이용된 많은 셀 라이브러리 루틴 또는 기능을 포함한다.
운영 체계 객체는 API 호출을 운영 체계 계층(54)의 지원 기능으로 접근시킨다. 운영 체계 객체의 요소는 표 II 에서 식별된다.
지원된 진입점으로 표시된 바와 같이, o/s 객체는 운영 체계 계층(54)에 대한 호출 인터페이스, 저 레벨 및 bios 기능에 대한 호출 인터페이스 및, 플랫폼 특정 기능에 대한 호출 인터페이스를 제공한다. 이런 플랫폼 특정 호출 인터페이스는 플랫폼 이식성 상세부(portability details)를 감추는 역할을 하는 다수의 유틸리티 또는 라이브러리 루틴을 나타낸다. 본질상 o/s 객체의 다른 기능과 관련되지 않지만, 이런 루틴은 여기서 집중되어, 한 모듈에서 모든 플랫폼 특정 호출 및 기능을 수집함으로써 플랫폼 이식성 변경부를 거의 이런 한 모듈로 제한시킨다. 더욱이, 이런 루틴은 일반적으로 나머지 모듈에서와 같이 어셈블러 코딩을 이용하여 최상으로 구현된다.
2. 하위 레벨 초기화
그후, 셀 모듈(72)은 장치 드라이버(50)의 나머지의 동적 적재를 초기화한다. 정확한 보드 드라이버(74)를 식별하기 위하여, 셀 모듈(72)은 특정 보드 형을 식별하도록 비디오 디스플레이 제어기(19)의 초기 사정부(assessment)(94)를 수행한다. 보드 식별자는 양호하게도 제어기(19)상에 물리적으로 상주한 데이터 구조로 부터의 제어기(19)에서 판독되어, 셀 객체의 "Boarddata" 필드내에 기억된다. 양호한 실시예에서, 보드 식별자는 초기에 레지스터 인터페이스(30)를 통해 접근 가능한 비디오 디스플레이 제어기(19)상에 위치된 통상적인 온-보드(on-board) ROM(29)내에 기억된다. 표 III는 보드 식별자 데이터 구조의 양호한 구조를 제공한다.
"ID" 필드는 장치 드라이버(50)에 따라 보드식별자 구조를 확인하는 정적 데이터값을 제공한다. "Revision" 필드는 선택적 구조가 소정의 미결정(future) 데이터로 구현될 경우에 보드 식별자 구조의 특정 구조를 정의하는데 이용된다. "structureSize"필드는 구조의 사이즈를 정의한다. "BoardFamily" 필드는 비디오 디스플레이 제어기(19)의 그런 특정 사례(instance)를 지원하는 데 요구된 장치 드라이버(50)의 부분으로서 적재될 필요가 있는 보드 드라이버(74)를 원칙상 식별하는데 이용될 수 있는 값을 기억시킨다. 적어도 "BoardFamily" 값을 포함하는 보드 식별자 구조의 값은 board.dat 파일내에서 키 명칭 탐색을 수행할 키로서 이용된다. 양호하게도, 이런 키는 중요한 보드 식별자 필드값의 간단한 연결부(concatenation)로서 형성된다. board.dat 파일은 양호하게도 보드 드라이버(74)의 특정 사례의 대응 파일 명칭에 대한 플랫(flat) 파일 상관 키이다.
일단 특정 보드 드라이버(74)가 식별되면(94), 셀 모듈(72)은 키 값에 대응하는 보드 드라이버(74)를 적재하도록 운영 체계 모듈(70)을 통해 호출한다. 응답하여, 운영 체계 계층(54)은 요구된 보드 드라이버(74)를 메모리(16)내에 적재하여(96), 메모리 포인터를 셀 모듈(72)로 복귀시킨다. 보드 드라이버(74)의 초기화 진입점은 그때 호출된다.
보드 드라이버(74)의 초기화의 부분으로서, 보드 객체(98)는 생성된다. 운영 체계나 하드웨어 인터페이스 모듈의 어느것도 정확히 나타내지 못하지만, 보드 객체는 운영체제 또는 하드웨어 인터페이스 모듈을 나타내는 객체에 의해 편리하게 이용되는 기본 데이터 구조형을 설정한다. 보드 객체의 구조는 표 IV 에서 제공된다.
보드 객체 초기화의 부분으로서, 보드 식별자 구조에 대한 포인터, "BoardData"는 셀(72)로 부터 획득된다(100). 보드 식별자 구조의 다른 필드는 그때 비디오 디스플레이 제어기(19)상에 제공된 각 부 구성요소의 특정형을 식별하도록 조사된다. 프리-세트(pre-set) 세트된 값은 부 구성요소의 특정 사례를 식별하는데 이용된다. 양호하게도, 보드 식별자의 필드는 일반적으로 제어기(19)의 부 구성요소의 고정 양상에 대응한다. 예를 들면, DAC 형이나, 비디오 메모리형, VRAM 또는 DRAM 은 보드 식별자 구조를 통해 제공될 수 있다.
부 구성요소의 양상이 고정되지 않는 곳에서, 아마 필드 업그레이드 가능한 바와 같이, 특정 양상은 통상적인 방식으로 결정될 필요가 있다. 예를 들면, 비디오 디스플레이 제어기(19)상에서 유용한 디스플레이 RAM의 양(비디오 메모리 사이즈)은 제어기가 일단 운영 상태에 놓이게 되었을 경우에 변경될 수 있다. 그러나, 보드 식별자는 정적이고, 제어기(19)의 제조시에 설정된다. 따라서, 종래의 메모리 주사 루틴은 그런 경우에 비디오 디스플레이 제어기(19)상에 제공된 비디오 메모리의 전체량을 정확히 결정하는 데 활용될 수 있다. 디스플레이 제어기(19)는 또한 제어기(19)의 전통적(legacy) 구현으로 브드 식별자(29)를 갖지 않을 수 있다. 제어기(19)상에 제공된 부 구성요소의 적당한 식별은 그때 종래의 Int10 Bios 호출은 통해 획득된 정보로 부터 추론될 수 있다.
보드 식별자 구조의 최종 필드는 "BoardDependentInfo" 필드이다. 이런 필드는 특정 보드형 및 모델의 부가적 운영 특징을 플래그하는 데 양호하게 이용된 워드-와이드 비트맵(word-wide bitmap) 데이터 영역을 제공한다. 이런 플래그는 구현 종속물이고, 보드 드라이버(74)에 의해 유일하게 디코드된다. 특히, 이런 플래그 비트는 보드 식별자의 다른 필드에 의해 커버(cover)되지 않는 상세 구성 옵션을 식별하는 데 이용될 수 있다. 예를 들면, 플래그 비트는 장치 드라이버(50)의 나중 버전으로 이용될 수 있는 저위(minor) 부 구성요소 옵션의 존재를 식별하는데 이용될 수 있다.
보드 식별자 구조로 부터, 보드 드라이버(74)는 비디오 디스플레이 제어기(19)를 최적으로 지원하는 데 요구되는 하드웨어 인터페이스 모듈의 특정 세트를 결정한다(102). 보드 드라이버(74)는 그때 운영 체계 모듈(70)을 통해 보드 모듈과 정적으로 링크되지 않은 하드웨어 인터페이스 모듈의 식별된 세트의 순차적 적재(104)를 요구한다. 각 하드웨어 인터페이스 모듈(76 내지 88)이 메모리(16)내에 적재될 시에, 각 모듈의 초기화 루틴은 대응 소프트웨어 객체를 설정하도록 호출된다(106). 양호한 장치 드라이버(50)에서, 각 하드웨어 인터페이스 객체는 공통 헤더부 및 하드웨어 종속부를 포함하는 데이터 구조로서 구성된다. 공통 헤더부는 양호하게도 표 V 에서 식별된 필드를 포함하는 객체 헤더 데이터 구조(OBJHDR)이다.
"objectVer" 필드는 캡슐화 하드웨어 인터페이스 객체에 의해 지원된 하드웨어 부 구성요소의 특정 구현을 지정하는 유일한 식별자를 제공한다. "Module" 필드는 캡슐화된 하드웨어 인터페이스 모듈의 메모리 위치로 포인트한 운영체제로 부터 복귀된 메모리 포인터를 포함한다. "objDataInstance" 필드는 하드웨어 인터페이스 객체의 그런 사례화를 위해 예약된(reserved) 전용 데이터 영역에 포인터를 제공한다. "RegclassHandler" 필드는 관련된 하드웨어 부 구성요소가 모드 세트 운영의 호출의 부분으로서 프로그램되는 인터페이스 레지스터를 갖는지를 정의한다. 필드의 값이 널(null)일 경우, 소정의 요구된 모드 세트 프로그래밍은 하드웨어 인터페이스 객체에 의해 캡슐화된 모듈로 하드 코드된다. 필트가 널이 아닐 경우, 필드의 값은 모드 변경을 지원하는데 이용될 수 있는 레지스터 명칭 및 인터페이스 절차의 정의를 포함하는 구조에 대한 포인터이다. RegclassHandler 의 구조는 표 VI 에 도시된다.
객체 헤더의 "ObjectInil" 및 "ObjUnInit" 필더는 현재 하드웨어 인터페이스 객체에 의해 캡슐화된 하드웨어 인터페이스 모듈을 초기화하고 프리잉(freeing)하기 위해 호출 어드레스를 제공한다. 객체 헤더의 "Mode set" 필드는 하드웨어 인터페이스 객체로 모드 변경을 신호화하는 데 이용된 하드웨어 인터페이스 모듈 진입점을 설정한다. 양호한 실시예에서, 이런 진입점에 대한 3개의 서로 다른 호출이 행해질 수 있다. 각 호출은 모드 세트가 막 일어날려고 하고, 모드 세트를 호출할려고 하며, 모드 세트가 완성되었음을 명시하도록 호출의 오퍼랜드에 의해 구별된다.
최종으로, "SetDPMSState" 필드는 특정 모듈에 특별한 시스템(10)의 전원 관리 상태의 변화를 서비스하는 진입점을 제공한다.
따라서, 하드웨어 인터페이스 모듈 초기화 루틴은 캡슐화 하드웨어 인터페이스 객체의 사례를 생성시키기 위해 제공하는 데, 이런 사례는 하드웨어 인터페이스 객체의 하드웨어 인터페이스 종속부에 대한 기억문을 포함하고, 이런 객체의 사례에서 객체 지정 필드를 초기화하며, 그리고 하드웨어 인터페이스 객체의 이런 사례에 전용될 수 있는 소정의 사례 데이터를 할당한다. 사례 데이터에 대한 포인터는 객체 헤더내의 "ObjDataInstance" 필드내에 기억된다. 초기화 루틴은 그때 하드웨어 인터페이스 객체로 포인터를 복귀시킨다. 이런 포인터는 보드 객체 부구조의 멤버 필드내에 기억된다(108).
기본 하드웨어 인터페이스 객체, 특히 클록 객체는 표 VII 에서 정의된다.
표시된 바와 같이, 클럭 부 구성요소와 관련된 어떤 하드웨어 특정 기능이 없다. 그러나, 클록 주파수는 클록 부 구성요소의 통상적 프로그램 가능 양상이며, 또한 운영 모드 세트내에 완전히 포함된다. 따라서, 객체 헤더 구조의 RegclassHandler 필드는 궁극적으로 내장(on-board) 제어기(19)상에서 발생된 클록 주파수를 제어하는 클록 부 구성요소의 인터페이스 레지스터로의 접근을 지원하도록 필요한 레지스터 정의를 포함하는 RegClassHandler 구조에 대한 포인터를 포함한다.
표 VIII 는 예를 들어 하드웨어 커서 객체를 정의하는 다소 더 복잡한 객체를 설명한 것이다.
전술된 바와 같이, 객체 헤더는 커서 객체의 구성 요소로서 포함된다. CursorEnable 필드는 하드웨어 커서의 가시성을 호출 파라미터의 상태에 따라 턴 온 또는 오프하도록 하드웨어 커서 인터페이스 모듈로의 진입점에 포인터를 제공한다. CursorSet 필드는 오퍼랜드에 의해 호출에 지정된 패턴으로 커서 패턴을 세팅하는 진입점(15)에 포인터를 제공한다. CursorMove 필드는 호출이 제공된 X 및 Y 오퍼랜드에 의해 커서의 핫스포트(hot spot)를 디스플레이(32)상에 지정하는 루틴에 대한 진입점을 식별한다. CursorSetColor 필드는 디스플레이(32)상에 제공된 2색 커서를 색 확장하는 데 이용된 루틴을 식별한다.
다른 하드웨어 인터페이스 객체는 DAC 객체(130)(DACOBJ; 표 IX), 비디오 객체(136), 그래픽 객체(138)(DRAWENGOBJ; 표 X) 및 3D 그래픽 객체(140)를 포함한다.
DrawEngObj 로 참조된 부구조는 많은 기본 드로어계(drawing) 기능을 포함한다. 이런 부구조는 드로어계 엔진(engine) 객체내에서 설정되고, 기능 포인터의 복사본(copy)은 API 호출에 응답하여 GDI 객체로 부터 호출의 선형 실행시에 기능으로 직접 접근하도록 GDI 객체의 코드 공간내에 위치되기 시작한다. 부구조는 표 XI 에서 정의된다.
이런 객체 정의에 의해 설명된 바와 같이, 하드웨어 인터페이스 모듈(76 내지 88)의 각각은 대응 하드웨어 인터페이스 객체를 설정하도록 초기화시키는데, 이런 객체는 객체를 쉽게 관리하는 표준화부 및, 객체 특정 진입점의 고정 세트를 제공하는 하드웨어 특정 확장부를 포함한다. 이런 객체 특정 엔트리(entry)는 캡슐화 하드웨어 인터페이스 모듈의 초기화 루틴에 의해 참조된 포인터로 채워진다. 포인터 레퍼런스는 논리 참조 기능을 제공하는 캡슐화 모듈내의 기능일 수 있다. 논리 기능의 특정 구현이 현재 색농도, 스크린 해상도 또는 다른 제어기 관련 특징에 따라 다른 곳에서, 캡슐화 모듈은 양호하게도 대응 특정 진입점으로 구현된다. 진입점의 적당한 서브세트는 객체 진입점내로 초기화된 포인터 레퍼런스에 의해 식별되어, 제어기(19)의 현재 특징상태의 반복된 실행 시간 테스트없이 운영 동안 적당한 특징 운영을 암시적으로 설정한다.
결과적으로, 개별객체는 객체 구조의 공통 OBJHDR 양상에 따라 포괄적으로 관리됨과 동시에 특히 색농도 및 스크린 해상도와 같은 특징에 의한 기능의 서로 다른 구현을 포함하는 언더라잉(underlying) 기능 및 구현 상세와 무관하게 각 특정형의 하드웨어 인터페이스 객체에 대해 정의된 진입점 인터페이스를 설정하는 데 이용된다.
본 발명의 양호한 실시예에서, 보드 식별자로 부터 식별된 board.dmm 파일이 비디오 디스플레이 제어기(19)상에 제공될 시에 클록, DAC 또는 하드웨어 커서의 존재를 명백히 지정하지 않는 곳에서, 디폴트 모듈로서 보드 드라이버(72)와 정적으로 링크된 대응 디폴트 모듈은 활용된다. 따라서, 하드웨어 인터페이스 모듈 세트가식별되고, 적재되며, 초기화된 후에, 보드 객체내의 널 포인터는 보드 드라이버(74))에 의해 검출된다. 예를 들어, 하드웨어 커서 객체가 그때 존재하지 않을 경우, 보드 드라이버(74)는 객체를 생성시키며, 보드 드라이버(74)내의 대응 디폴트 루틴에 대한 하드웨어 종속 진입점을 초기화시킨다. 이에 의해 하드웨어 커서의 기능성은 소프트웨어 어뮬레이션을 통하거나, 통상적으로 다른 하드웨어 인터페이스 객체의 내장(intrinsic) 구성 요소로서 지원될 수 있다. 여하튼간에, 디폴트 객체는 보드 객체에 링크되고, 그후에 동적으로 적재 및 링크된 하드웨어 커서 객체와 같은 내장 기능성을 제공한다.
3. 상위 레벨 초기화 완료
일단 하드웨어 인터페이스 객체가 초기화되었을 경우, 보드 드라이버(74)의 초기화 루틴은 셀 모듈(72)로 복귀한다. 셀 모듈(72)은 그때 GRX API 객체(71)를 생성시키도록 진행한다(109). GRX 객체는 운영체제 인터페이스 객체(64, 66, 68)에 대한 내부 유니버살 또는 가상화 인터페이스 역할을 한다. GRX 객체(71)는 표 XII 에서 설명된 바와 같이 비교적 간단한 인터페이스를 제공한다.
GrxApiFastCopy 호출 진입점은 온-스크린 및 오프-스크린 비디오 메모리내에 위치된 비트맵을 조작하도록 특히 셀 모듈을 포함하는 모든 운영 체계 API 레벨 모듈에 의해 사용 가능한 공통 접근점을 제공한다. 공통 접근점의 설정은 비디오 메모리 관리를 간단하게 한다. GrxApicolorMatch 호출 진입점은 또한 스크린(32)의 현재 색농도에서 물리적 색변환을 논리적으로 수행하도록 모든 운영 체계 API 레벨에 의해 사용 가능한 공통 접근점을 제공한다.
GRX 객체(71)의 OBJHDR 내의 초기화 진입점은 셀 모듈(72)에 의해 호출되어, 운영 체계 인터페이스 객체(64, 66, 68)의 설정을 초기화한다(110). 본 발명의 양호한 실시예에서, GDI 및 DD 객체(64, 66)는 GRX 객체 초기화 루틴내에서 정적으로 식별된다. 선택적으로, 또는 부가적으로, 운영 체계 인터페이스 객체는 interface.dat 구성 파일을 참조로 셀 모듈(72)에 의해 식별될 수 있다. 셀 모듈(72)과 정적으로 링크되지 않을 경우, 식별된 운영 체계 시스템 인터페이스 모듈은 메모리(16)내로 순차적으로 적재된다(112).
각 운영 체계 모듈이 적재될 시에(112), 모듈 초기화 루틴(114)이 호출된다. 각 운영 체계 인터페이스 모듈의 초기화는 대응 운영 체계 인터페이스 객체를 생성시킨다. 하드웨어 인터페이스 객체에 따라, 운영 체계 인터페이스 객체는 제각기 양호하게도 운영 체계 인터페이스 객체를 조작하기 위해 공통 기저(basis)를 설정하는 객체 헤더 부구조(OBJHDR)를 포함한다. 객체 헤더의 사용은 또한 장치 드라이버(50)에 의해 모드 변경을 신호화하도록 호출에 대한 지원을 제공한다. 차례로, 운영 체계 객체는 필요하다면, 객체의 각 사례화에 대한 전용 데이터 공간을 지원한다.
GDI 객체(120)는 표 XIII 에서 주어진 정의로 생성된다.
GDI 객체(120)는 표준 Dib 엔진의 부구조 인터페이스(DibengObj)에 링크 레퍼런스를 제공하거나 포함한다. 부구조는 표 XIV 에서 정의된다.
DibengObj 의 다른 표준 부구조는 표 XV 및 XVI 에서 정의된다.
표 XV 및 XVI 는 다이렉트 드로어 객체(124)를 정의한 객체를 설명한 것이다.
[표 XV]
[표 VI]
16 및 32 비트 환경에서의 사용을 지원하기 위하여, 부가적인 ObjInstData 부구조는 16 및 32 비트 API 호출을 지원하는 장치 드라이버(50)의 구성 요소에 16 및 32 비트 포인터를 제공하는 데 사용된다.
최종으로, 각 운영 체계 인터페이스 객체의 초기화가 완료될 시에, 링크(116)는 GRX 객체(71)와 GDI 및 DD 객체(120, 122) 사이에서 설정된다. GRX 초기화 루틴은 그때 셀로 복귀한다. 또한, 모든 운영 체계 인터페이스 객체는 그때 셀 객체로 링크된다. 셀 모듈(72)의 초기화 루틴은 그때 복귀한다.
IV. 운영 상태 구성
도 4는 단일 문맥 상태의 운영동안에 대응 실행 가능 모듈을 논리적으로 캡슐화하는 하드웨어 인터페이스 객체 및 각 운영 체계를 가진 장치 드라이버(50)의 논리 구성을 설명한 것이다. 셀 드라이버(74)의 논리적 비캡슐화부는 일반 셀 라이브러리(72')로서 계속 상주한다. 마찬가지로, 보드 드라이버(74)의 논리적 비캡슐화부는 보드 라이브러리(74')로서 계속 상주한다. 두 라이브러리(72',74')는 장치 드라이버(50)의 내부 기능을 지원하는 공통 자원 역할을 한다. 따라서, 드라이버 소프트웨어 원근법(perspective)으로부터, 초기화된 장치 드라이버(50)는 장치 드라이버(50)에 의해 제공된 운영체제 API 를 응집력있게 설정하는 운영 체계 인터페이스 객체와, 장치 드라이버(50) 및 하드웨어 인터페이스 레지스터(30) 사이에서 하드웨어 특정 인터페이스를 설정하는 하드웨어 인터페이스 객체에 의해 정의된다.
1. 상위 레벨 관계
GDI 객체(120), 다이렉트 드로 객체(122), 다이렉트 3D 객체(124) 및 셀 객체(126)를 포함하는 운영 체계 인터페이스 객체는 운영 체계 계층(54)에 제공되는 부분 API 의 정의에 의해 서로 논리적으로 분할되는 한세트의 객체를 나타낸다. 현행 API 호출 지원 방식의 개정 및, 소정의 특정 운영 체계 인터페이스 객체에 대한 신규 API 호출의 가산은 계획적으로 다른 운영 체계 인터페이스 객체의 운영 또는 구현에 영향을 주지 않는다. 더욱이, 운영 체계 계층(54)에 의해 새로이 정의되거나, 응용(60)으로부터 직접 발신된 호출을 지원할 시에 신규 부분 API 에 대한 지원은 대응 운영 체계 인터페이스 객체 및 캡슐화 운영 체계 인터페이스 모듈의 정의를 통해 쉽게 제공될 수 있다. 그러나, 신규 또는 개정된 API 호출이 현행 운영 체계 인터페이스 객체에 의해 지원된 다른 소정의 API 호출과 상당히 다른 기능을 포함하거나 필요로 할 경우, 부가적인 라이브러리 루틴은 셀 라이브러리(72')에 가산될 필요가 있을 수 있다.
셀 라이브러리(72')는 운영 체계 인터페이스 객체의 전 세트에 의해 사용가능한 한세트의 공통 또는 가상화 지원 기능을 설정하는 역할을 하는 루틴의 라이브러리를 제공하도록 운영 체계 인터페이스 객체는 기능상(1) 정의된 API 호출 세트를 지원하고, (2) 각 지원된 API 호출에 대한 파라미터 타당성 검사(validation)를 위해 제공하며, (3) 장치 드라이버(50)의 운영에서의 문맥 변경을 지속시키는데 바람직한 데이터 객체에 대한 전용 데이터 공간을 잠재적으로 관리하며, (4) 객체에 의해 지원된 각 API 호출을 기능적으로 구현하도록 하나 이상의 가상화 호출의 시퀀스를 셀 라이브러리(72')에 지시하며, 그리고 최종으로 (5) 객체에 의해 지원된 각 API 호출에 적당한 방식으로 데이터를 포맷시켜 운영 체계 계층(54)으로 복귀시키는 것으로 제한된다.
본 발명에 의해 인식되는 바와 같이, 장치 드라이버(50)에 대한 많은 호출 변경은 호출이 제공된 오퍼랜드 데이터의 특정 형태 및 시퀀스와 같은 특정 양상에서 다르다. 그와 같이, 특정 오퍼랜드 데이터의 타당성 검사는 각 API 호출에 특별하다. 그래서, 각 객체는 양호하게도 API 호출 특정 오퍼랜드 타당성 검사 및, 잠재적으로 이런 또는 다른 운영 체계 인터페이스 객체에 의해 지원된 기능상 유사한 다른 API 호출로서 단일화되는 포맷으로의 오퍼랜드 데이터의 변환을 수행한다. 따라서, 하나 이상의 API 호출 세트는 내부적으로 장치 드라이버(50)로 가상화된다.
운영 체계 인터페이스 객체에 의해 지원된 API 호출의 오퍼랜드에 관련되고, 유도되며, 또는 그로서 제공된 데이터 객체를 보존하는 데 요구되는 바와 같이 각 운영 체계 인터페이스 객체는 문맥 특성 데이터 공간을 관리한다. 예를 들면, GDI 객체(120)는 주어진 문맥에서 디스플레이 포인터(38)의 사례와 관련된 해상도 종속 비트-맵 패턴 또는 색을 정의하는 데이터 객체를 유지할 수 있다. 따라서, 현행 문맥을 되찾음(resumption)과 동시에, 데이터 객체는 이런 문맥내에서 디스플레이 포인터(38)의 사례를 효과적으로 재실현하는 데 이용될 수 있다. 특정 주석(note)에서, 재실현은 어느 요구된 참여 또는 동등한 통지없이 전적으로 소정의 응용 프로그램(60) 또는 운영 체계 계층(54)에 지원된다. 이런 예에서, 데이터 객체는 초기에 디스플레이 포인터(38)의 패턴 또는 색을 세트하는 API 호출의 오퍼랜드로서 제공된 원 데이터 객체로 부터 유도된다. 예를 들어 신규 색농도를 포함하는 신규 문맥이 생성될 시에, 신규 데이터 객체는 이전의 문맥의 데이터 객체로 부터 색농도 변환에 의해 유도된다. 사전 존재 문맥으로 문맥을 교환함과 동시에, 데이터 객체의 사전 존재 사례는 디스플레이 포인터(38)의 사례의 재실현에서 어떤 정보도 상실되지 않는 결과로 재사용된다.
마찬가지로, GDI 객체(120)의 사례는 양호하게도 팔레트화된(palettized)색 문맥내의 색 팔레트 뿐만 아니라 팔레트화된 문맥에 특별한 PDevice 구조의 부분으로서 순방향 및 역방향 팔레트 변환표를 유지한다. 윈도 95TM운영 체계에서, 운영 체계 계층(54)은 운영 체계 계층(54)으로 부터 적어도 선택된 호출상에 타입 장치 드라이버를 디스플레이하도록 통과되는 소정의 정보를 유지하는 데 이용되는 물리적 장치(PDevice)구조에 단일 포인터를 지원한다. PDvice 구조의 의도(intent)는 장치 드라이버(50)에 의해 일반적으로 하드웨어 특정 구성 데이터를 기억하는 데 이용될 수 있는 확장 가능한 데이터 구조를 제공할 수 있다. 본 발명은 팔레트화된 문맥에 특별한 색변환포를 기억시킬 PDevice 구조를 활용할 뿐만 아니라, 일반적으로 각 문맥에 대한 신규 PDevice 구조를 복사하고, 대응 문맥의 색 농도와 일치하는 구조를 확장한다. PDevice 구조의 양호한 구조는 표 XVII 에 제공된다.
문맥 특정 지속 데이터 객체로서의 색 팔레트 변환표의 효과적인 유지는 팔레트화된 문맥으로 문맥 교환상의 색 팔레트 및 변환표를 급속히 복원시킨다. PDevice 구조의 부분으로서의 색 팔레트 변환표의 유지는 또한 비팔레트화된 문맥 동안 및, 잠재적으로는 독립 색 팔레트 및 변환표 정의로 독립 PDevice 구조를 이용하는 다른 팔레트화된 문맥 동안 드로어 운영에 따른 연속 팔레트를 지원한다. 여하튼간에, 팔레트화된 문맥에 대비하여 논리적으로 실행하는 응용으로 부터 유도된 진행 드로어 운영은 대응 문맥의 색 팔레트 데이터 및 변환표에 대비하여 드로어 명령을 변환하거나 해결함으로써 현재 활동 문맥의 색농도 또는 색 팔레트로 정확히 변환될 수 있다. 즉, 현재가 아닌 활동 문맥에 대비하여 논리적으로 실행하는 응용(60)의 드로어 명령은 현재 문맥의 색농도에서 드로어 명령을 수행하도록 현재가 아닌 문맥의 데이터 객체로 참조로하여 요구되는 바와 같이 효과적으로 재실현된다. 현재가 아닌 문맥의 데이터 객체는 데이터 구조, 특히 각 문맥을 정의하는 데 이용되는 셀 객체를 탐색함으로써 위치될 수 있다.
본 발명의 양호한 실시예에서, 운영 체계 인터페이스 객체는 다소 엷은 계층을 나타낸다. 인터페이스 객체에 의해 지원된 각 특정 API 호출에 대한 실행 스레드(threads)를 정의하는 데 적당한 바와 같이 API 호출은 양호하게도 셀 라이브러리(72') 및 하드웨어 객체(130 내지 140)에 대한 거의 선행 호출 시퀀스로 고레벨에서 가상화된다. 일반적으로, 셀 라이브러리(72')내의 루틴으로 공통 호출의 사용을 최대화하는 것이 바람직하다. 역으로, 운영 체계 인터페이스 객체의 기능을 각 지원된 API 호출에 대한 선형 실행 스레드의 실재 데이터 타당성 검사, 기본 데이터 변환 및 명세로 제한하는 것이 바람직하다.
윈도 95TM구현에서, 운영 체계 계층(54)은 상당한 원자 API 호출을 장치 드라이버(50)에 지시한다. 결과적으로, 운영 체계 인터페이스 객체의 거의 모두는 API 호출을 수행하는 데 필요한 실행 스레드를 기능적으로 구현하도록 셀 라이브러리(72') 및 하드웨어 인터페이스 객체를 불과 몇몇만 호출한다. 수행을 위한 방편 또는 용도가 특정 API 호출로 거의 제한되는 곳에서, 소정의 실행 기능은 운영 체계 인터페이스 객체로 수행될 수 있다. 특히, 좌표의 초기 클립핑 및 변환은 API 호출에 응답하여 객체를 드로어하도록 오퍼랜드 타당성 검사와 협조하여 운영 체계 인터페이스 객체에 의해 수행될 수 있다. 신규 지속 데이터 객체의 기억을 설정하고, 신규 데이터 객체의 내용을 다른 객체로 부터 유도하도록 색농도 변환을 수행하며, 그리고 스크린(32)에 대한 드로어계 운영을 실현하는 데 이용된 루틴과 같은 다중 API 호출에 의해 요구되기 쉬운 더욱 실재적인 루틴은 셀 라이브러리(72') 및 하드웨어 인터페이스 객체에 적당한 바와 같이 양호하게 구현된다.
따라서, 예를 들면, 제 1 API 호출은 바람직한 신규 데이터 객체의 생성을 요구하여, 궁극적으로 객체에 대한 포인터를 수신하도록 운영 체계(54)에 의해 대응 운영 체계 인터페이스 객체로 행해진다. 호출의 가상화 선형 스레드는 차례로 할당을 요구하고, 메모리내에 로크하며, 포인터를 결과 객체로 복귀시키는 셀 라이브러리(72')로 호출하기 시작한다. 이런 요구를 수행하는 셀 라이브러리(72')는 요구된 운영 체계 API를 운영 체계 계층(54)으로 릴레이(relay)할 필요가 있을 시에 운영 체계 인터페이스 객체(128)를 순차적으로 호출한다. 셀 라이브러리(72')에 의해 지원된 개별 기능의 그런 선형성은 운영 체계 인터페이스 객체에 의해 수행된 선점(preemptive) 오퍼랜드 타당성 검사 및 가상화에 의해 가능하게 된다. 오퍼랜드 데이터는 셀 라이브러리(72') 또는 소정의 하드웨어 인터페이스 객체가 특정 API 호출에서 뒤따르는 각 처리 단계에 적당한 형태 및 포맷으로 호출된다. 결과적으로, 예외 조건을 조정하거나, 데이터가 입수 가능하거나 처리를 위한 접근 가능 포맷내에 있는지를 결정하는 모든 조건부 브랜치(branches)가 운영체제 인터페이스 객체의 레벨 아래에서 제거되지 않을 지라도, 오퍼랜드 데이터의 존재, 형태 및 포맷을 체크할 진행 조건부 브랜칭없이 가상화 API 호출의 구현은 거의 선형화된다. 더욱이, 현재 색 농도 및 해상도의 적당한 기능에 대한 기능 포인터에 따르는 하드웨어 인터페이스 객체의 초기화는 디스플레이(32)의 현재 운영 상태를 체크 및 조정하도록 진행 조건부 브랜칭을 제거한다.
운영 체계 객체에 대한 다음 API 호출은 신규 생성된 데이터 객체내의 식별된 데이터 객체의 변환을 지시할 수 있다. 운영 체계 인터페이스 객체를 통한 연이은 API 호출은 앞선 생성 및 변환된 API 호출 식별 데이터 객체를 이용하여 특정 드로어 운영의 수행을 명시할 수 있다. 각 API 드로어 호출은 하나 이상의 호출의 거의 선형 시퀀스를 셀 라이브러리(72')에 다시 지시함으로써 수신 운영 체계 인터페이스 객체에 의해 실행되고, 또한 특정 드로어 운영을 실현하는 데 적당한 하드웨어 인터페이스 객체에 의해 실행된다.
따라서, 운영 체계 인터페이스 객체의 각각은 오퍼랜드 검증 및 포맷 변환을 수행함과 동시에 최소 복사 코드를 포함함으로써 호출의 가상화를 최대화하도록 정의된다. 그래서, 셀 라이브러리(72')의 사용은 원 오퍼랜드 데이터의 소정의 반복 재타당성 검사, 변환 또는 재포맷팅으로 인해 실행 수행 페널티없이 최대화된다. 더욱이, 운영 체계 인터페이스 객체에는 즉시 이용 가능한 기능 포인터를 통하여, 제어기(19)의 운영 특징을 연속 재평가하고 조정할 필요없이 하드웨어 인터페이스 객체로 접근하는 직접 기능 호출이 제공된다.
셀 라이브러리(72')는 또한 운영 체계 인터페이스 객체로 부터 수신된 공통 가상화 호출의 유효 확장 및 구현을 제공할 수 있다. 셀 라이브러리(72')에 대한 그런 호출은 양호하게도 차례로 하드웨어 특정 기능을 불러드리도록 하드웨어 인터페이스 객체로 지향된 통상적 짧고 거의 선형 호출 시퀀스로 확장된다. 셀 라이브러리(72')에 의해 호출된 하드웨어 인터페이스 객체의 특정 세트 또는 서브세트는 운영 체계 인터페이스 객체로 부터 수신된 특정 호출에 상당히 의존한다. 그러나, 셀 라이브러리(72')에 의해 행해진 각 호출은 하드웨어 인터페이스 객체 데이터 구조의 가상화 정의의 결과로서 하드웨어 인터페이스 객체의 세트와의 유효 가장 관계를 갖고 있다. 즉, 하드웨어 인터페이스 객체의 구조 정의는 객체에 의해 캡슐화된 특정 하드웨어 인터페이스 모듈의 구현과 관계없이 각 객체 형에 고정된다. 결과적으로, 운영 체계 인터페이스 객체 및 셀 라이브러리(72')로 부터 하드웨어 인터페이스 객체로의 호출은 하드웨어 인터페이스 모듈의 실제 구현으로 부터 추상화(abstract)된다. API 호출을 구현하는 데 이용된 짧은 거의 선형 호출 시퀀스의 이용으로, 가상화 API 호출의 실행 속도는 최대화된다.
2. 하위 레벨 구성 관계
하드웨어 인터페이스 객체는 제어기(19)의 인터페이스 레지스터(30)와 인터페이스 하는 데 필요한 하드웨어 특정 운영을 정의하는 엷은 계층으로서 양호하게 실현되는 운영 체계 인터페이스 객체와 유사하다. 하드웨어 인터페이스 객체는 양호하게도 (1) 하드웨어 부 구성요소의 특정형에 특별한 운영의 정의된 세트를 지원하고, (2) 각 지원된 운영의 기능을 구현하도록 관련 하드웨어 인터페이스 레지스터의 적어도 논리적 프로그래밍을 제공하며, (3) 장치 드라이버(50)의 운영의 문맥 변경을 지속시키는 데 바람직한 데이터 객체에 대한 전용 데이터 공간을 잠재적으로 관리하며, 최종으로, (4) 인터페이스 레지스터(30)로 부터 직간접적으로 판독된 소정의 데이터를 복귀시키도록 기능상 제한된다.
하드웨어 인터페이스 객체의 특정형에 의해 지원된 운영은 객체 구조의 부분으로서 정의된다. 일반적으로, 하드웨어 인터페이스 객체에 대한 호출은 인터페이스 레지스터(30)의 하나 이상의 레지스터에 대한 레퍼런스의 생성 및, 레퍼런스 레지스터내로 프로그램될 데이터값의 스트링(string)을 유발시킨다. 양호하게도, 레지스터의 실제 프로그래밍은 보드 라이브러리(74')에 대한 호출에 응답하여 수행된다. 셀 라이브러리(72')에 따라, 보드 라이브러리(74')는 하드웨어 인터페이스 객체에 의해 사용된 범용 또는 공통 루틴을 집중시킨다. 따라서, 코드의 복사량은 일반적으로 감소되고, 메모리(16)의 어드레스 공간내에서 디스플레이 버퍼(20)를 위치, 정의 및 관리하는 루틴을 포함하는 상세 레지스터 인터페이스 루틴은 장치 드라이버(50)의 모든 다른 양상으로 부터 본질상 분리되는 정의된 위치내로 주로 위치된다. 양호하게도, 이에 대한 한가지 중요한 예외는 그래픽 하드웨어 인터페이스 객체(138)에 관련하여 일어난다는 것이다. 수행을 위하여, 이런 객체는 양호하게도 레지스터 인터페이스(30) 및 디스플레이 버퍼(20)에 대비하여 직접 운영한다. 따라서, 보드 라이브러리(74')는 양호하게도 디스플레이 버퍼(20)의 현재 위치 및 정의를 복귀시키는 루틴을 제공한다. 비디오 및 3D 하드웨어 인터페이스 객체(136, 140)는 또한 제어기(19)의 대응하는 부 구성요소의 하드웨어 인터페이스에 직접 접근함으로써 득을 본다.
결과적으로, 하드웨어 인터페이스 객체를 통한 운영 체계 인터페이스 객체간의 유효 계층 가상화 관계는 본 발명에 의해 설정된다. 이런 가상화 관계는 2개의 서로 다른 API 호출의 실행 흐름을 장치 드라이버(50)로 트레이스함으로써 쉽게 입증된다.
V. 운영 상태 문맥 및 보드 스위칭
본 발명의 양호한 실시예에서, 비디오 디스플레이 제어기(19)는 많은 서로 다른 수평 및 수직 또는 공간 해상도와, 많은 서로 다른 색 농도에서 동작할 수 있다. 통상의 컴퓨터 시스템(10)은 종종 서로 다른 공간 해상도 및 색농도에 대해 최적으로 동작하는 다수의 응용(60)을 실행한다. 참으로, 컴퓨터 시스템(10)상에서 공동 실행할려고 하는 응용(60)의 공간 및 색 농도 요구 사항과 운영 한계는 상호 배타적이 아닐 경우 종종 응용(60)의 연속 실행에 최적이 아닌 공간 해상도 및 색 농도에 대한 공동 실행을 제한한다.
본 발명에 따르면, 장치 드라이버(50)의 구조는 장치 드라이버(50)의 운영 상태에서 모드 스위치 단독 및 문맥 스위치와 조합하여 수행한다. 모드 스위치 및 문맥 스위치 양자는 수행되고, 특히 응용(60)의 문맥 상태 및 운영 체계 계층(54)과 본질적으로 관계없이 관리된다.
모드 스위치만은 현행 모드의 특정 양상에 특별한 데이터가 모드 스위치에 걸쳐 유지하는 곳에서 수행될 수 있다. 문맥 스위치는 독립문맥에서 모드 데이터의 지속적인 기억을 위해 제공하도록 모드 스위치와 조합하여 장치 드라이버(50)에 의해 수행된다. 따라서, 장치 드라이버 문맥 스위치는 특정 문맥과 관련된 지속 데이터 객체내에 상태 및 모드 특정 데이터를 기억함으로써 상태 제어기 모드 변경을 지원하는 데 이용될 수 있다. 장치 드라이버(50)에 의한 문맥 관리 및 문맥 스위치 수행으로 응용 프로그램(60)을 변경시키지 않고 문맥이 스위칭되며, 얼마간의 특정 수정은 운영 체계 커널(56)에 행해진다.
1. 일정한 문맥 모드 스위칭
모드 스위치를 지원하기 위하여, 운영 체계 커널(56)은 패치(62)를 커널(56)에 설치함으로써 수정되며, 이는 윈도가 현재 포인터 포커스를 가진 응용(60)에 사전 선택된 공간 해상도로 비디오 디스플레이 제어기(19)를 스위치하도록 장치 드라이버(50)에 지향하는 API 호출을 지시한다. 더욱 개선된 운영 체계(54)는 본질적으로 운영 체계 패치를 설치할 필요없이 이용될 수 있는 이벤트의 생성을 위해 제공한다. 양호하게도, 모드 세트 API 호출내의 패치는 셀 객체로 훅(hook)되고, 물리적 디스플레이(32)의 바람직한 신규 공간 해상도를 제공한다. API 호출은 또한 바람직한 공간 해상도와 조합하여 색 농도를 지정한다. 바람직한 색농도 및 공간 해상도 양쟈가 현재 색 농도 및 공간 해상도와 동일할 경우, API 호출은 간단히 복귀한다. 공간 해상도만이 다를 경우, 모드 스위치만이 수행될 필요가 있다. 모드 스위치를 수행할 필요가 있는 제어기 모드 세트 변경은 장치 드라이버(50)의 현재 문맥내에서 수행된다.
본 발명의 양호한 실시예에 따르면, 단일 문맥내의 모드 세트 변경은 주로 셀 객체(126) 및 셀 라이브러리(72')의 제어하에 수행된다. 셀 객체(126)에 대한 API 호출은 모드 세트가 수행될 수 있음을 암시한다. 셀 객체(126)는 바람직한 색 농도 및 공간 해상도를 획득하도록 o/s 객체(128)를 통해 운영 체계 계층(54)로 호출한다. 셀 객체(126)는 먼저 바람직한 공간 해상도를 지정하는 복귀된 오퍼랜드를 타당성 검사한다. 셀 라이브러리(72')의 세트 모드 루틴은 그때 셀 객체(126)에 의해 호출되어, 운영 체계 및 하드웨어 인터페이스 객체의 각각, 먼저 "모드가 각 변경할려 함" 오퍼랜드, "모드 변경" 오퍼랜드 및 최종으로 "모드가 변경했음" 오퍼랜드를 순차적으로 호출한다.
"모드가 막 변경할려고 함" 오퍼랜드에 따른 제 1 호출은 제어기(19)에 관해 드라이버(50)의 상태를 중지시킬 필요가 있는 장치 드라이버(50)내의 이벤트의 시퀀스를 초기화시킨다. 특히, 셀 라이브러리(72')의 모드 세트 루틴은 모드 세트에 참여할 필요가 있는 현재 문맥내에서 운영 체계 및 하드웨어 인터페이스 객체의 각각을 식별하도록 운영한다. 이런 인터페이스 객체는 객체 특정 RegclassHandler 구조에 대한 타당 또는 넌-널(non-null) 포인터를 가질 시에 식별된다. 모드 세트 호출은 그때 참여 객체의 각각에 순차적으로 위치된다. 응답하여, 각 객체는 순차적으로 현재 PDevice 및 GDI-Infotable 구조와 같은 시스템 데이터 구조에 대한 현재 상태 데이터를 저장하거나, 현재 문맥내에서 정의된 실행 상태를 설정하는 데 적당할 시에 객체 그 자체의 전용 데이터 공간에 대한 현재 상태 데이터를 저장하도록 수행한다. 최종 참여 객체가 복귀했을 시에, 장치 드라이버(50)의 운영은 본질상 중지된다. 셀 라이브러리(72')는 그때 셀 객체(126)로 복귀한다.
"모드 변경"을 지정하는 제 2 모드 세트 호출은 그때 셀 객체(126)에 의해 셀 라이브러리(72')에 지시된다. "모드 변경" 오퍼랜드에 따른 셀 라이브러리(72')에 의해 호출됨과 동시에 보드 라이브러리(74')는 공간 해상도 및 색 농도의 바람직한 조합에 대응하는 "SectionName"을 구성한다. o/s API 호출은 그때 운영 체계 인터페이스 객체(128)를 통해 행해져, 소정의 "SectionName"에 의해 식별된 섹션을 위치시키도록 양호하게도 일반적으로 system.ini 파일과 동일한 구조 구문(syntax)을 가진 modes.dmm 구성 파일을 주사한다. 윈도 95TM구현 방식에서, 픽셀마다 8 비트 색 농도와 함께 1024 x 768 의 공간 해상도를 정의하는 SectionHeader 은 "[1024, 768, 8]" 로서 지정된다.
소정의 SectionHeader 에 따른 텍스트는 판독되어, 셀 라이브러리(72')에 의해 분석된다. 이런 텍스트는 운영의 신규 제어기 모드를 세트하도록 제어기(19)의 각 참여 부 구성요소에 대해 수행되는 특정 모드 세트 명령어의 구조화된 명세를 나타낸다. 양호한 실시예에서, 모드 세트 명령어는 REGISTERCLASS, COMMAND 및 인수(arguments)로서 콤마 구분 용어(comma delimited terms)내에 구조화된 라인 지향 문장이다. 양호한 실시예에서, RegclassHandler 구조의 "class name" 필드는 궁극적으로 제어기(19)의 어느 부 구성요소가 특정 명령어에 응답하여 프로그램될 수 있는 가를 결정하도록 명령어의 REGISTERCLASS 용어에 상관된다.
현재 4개의 직접 실행 명령, 런(RUN), 판독/마스크/기록(RMW), 지연(DLY) 및 Int10(I10)이 있다. 본 발명의 양호한 실시예에서 지원된 제 5 명령어는 modes.dmm 파일내의 포함(include) 지시 지정 SectionName 하에 발견된 명령어를 논리적으로 포함하여 중지하도록 셀 라이브러리(72')의 중지 루틴을 지시하는 포함 지시 의사(pseudo) 명령어이다. 런 명령은 아래의 명령어 포맷을 갖는다.
REGISTERCLASS, RUN, REGISTERNAME, value1, value2, value3, ....
REGISTERNAME 용어는 REGISTERCLASS 연관(association) 방식을 이용하여 RegClassHandler 구조를 통해 RegClassMap 구조로 트레이스될 수 있는 논리적 명칭을 제공한다. 논리적 REGISTERNAM 명칭은 궁극적으로 레지스터 인터페이스(30)내에서 특정 레지스터로 리졸브(resolve)될 수 있는 논리적 포트 어드레스에 대해 RegClassMap 으로 정의된다. 명령어의 실행에서, 셀 라이브러리(72')의 중지 루틴은 제 1 값, "Valuel" 로 REGISTERNAME 의 포트 어드레스를 기록한다. RegClassMap 내에서 식별된 다음 순차적 포트 어드레스는 그때 제 2 값, value2 로 기록된다. 따라서, 논리적 순차 포트 어드레스는 특정 런 명령에 제공된 모든 값이 기록되었을 때까지 연속값으로 기록된다.
판독/마스크/기록 명령은 아래의 명령어 포맷을 갖는다.
REGISTERCLASS, RMW, REGISTERNAME, ANDMask, XORMask
이런 명령의 실행에서, 셀 라이브러리(72')의 중지 루틴은 먼저 REGISTERNAME 에 대응하는 포트 어드레스로 부터의 값으로 판독하고, ANDMask 에 따른 갓의 2진 AND 을 수행시키며, 그리고 XORMask 에 따른 결과의 2진 XOR 을 수행시킨다. 결과는 그때 REGISTERNAME 포트 어드레스로 다시 기록된다.
지연 명령은 아래의 명령어 포맷을 갖는다.
SHELL, DLY, DelayValue
이런 명령어의 RegisterClass 은 어떤 하드웨어 인터페이스 객체도 명령어의 실행에 직접 관계되지 않으므로 항상 "SHELL"이다. 이런 명령어의 실행에서, 셀 라이브러리(72')의 중지 루틴은 양호하게도 50 마이크로초의 배수로서 DelayValue 에 의해 지정된 대기 시간 주기에 따라 소프트웨어 또는 하드웨어를 구현한다. 이런 지연 명령어는 하드웨어 프로그래밍 설정 시간이 관계되지만, 레지스터 판독 가능 준비 신호가 하드웨어에 의해 제공되지 않는 곳에서 유용하다. 중지 루틴은 지연 시간 주기가 만료한 후에도 계속한다.
Int10 명령은 아래의 명령어 포맷을 갖는다.
SHELL, I10, EAX, EBX, ECX, EDX
다시, 이런 명령어의 RegisterClass 은 어떤 하드웨어 인터페이스 객체도 명령어의 실행에 직접 관계되지 않으므로 항상 "SHELL"이다. 셀 라이브러리(72')의 중지 루틴은 소프트웨어 인터럽트(10)를 수행하여, 인터럽트시에 대응 cpu 레지스터내에 명령어의 인수를 제공하도록 o/s 객체(128)를 호출함으로써 상기 명령어를 구현한다.
최종으로, 포함 명령은 아래의 특정 명령어 포맷을 갖는다.
SHELL, INC. SectionName
포함 명령은 셀 라이브러리(72')의 중지 루틴을 명령하여, modes.dmm 파일의 현재 섹션의 중지를 효과적으로 중단하고, "SectionName."에 의해 식별된 섹션을 중지한다. 중단된 섹션의 중지는 포함된 섹션이 셀 라이브러리(72')에 의해 중지된 후에 재개한다. modes.dmm 파일에 의해 제공된 명령어를 실행함에 있어서, 셀 라이브러리(72')는 특정 명령어를 대응 하드웨어 인터페이스 객체와 연관시킬 REGISTERCLASS 용어를 활용한다. 명령어가 궁극적으로 제어기(19)의 운영 모드를 프로그래밍하도록 지향되므로, 본 발명의 양호한 실시예에서, 운영 체계 인터페이스 객체는 명령어의 소정의 REGISTERCLASS 용어에 의해 레퍼런스되지 않는다.
명령어가 실행될 시에, 대응 RegClassHandler 구조의 Read_reg 및 Write_reg 엔트리는 명령어의 실행시에 요구된 판독/기록 운영을 수행하도록 중지 루틴에 의해 호출된다. RegClassHandler 구조가 객체 특성이므로, Read_reg 및 Write_reg 기능은 또한 REGISTERNAME 용어에 의해 식별된 특정 객체에 특별하다.
본 발명의 양호한 실시예에서, 각 객체의 Write_reg 기능은, 명령어의 실행시에 성취되는 바와 같이, 레지스터/인수쌍을 실제 기록될 수 있는 레지스터의 하드웨어 특정 표현으로 효과적으로 변환시킨다. 레지스터/인수쌍은 명령어를 실행시켜 플랫 순차 논리적 레지스터 모델로 효과적으로 기록된다. Write_reg 기능은 상기 쌍을 부 구성요소 하드웨어 특정 모델로 변환시킨다. 예를 들면, DAC 인터페이스 객체(130)의 특정 상황에서, 변환이 이루어지는 것은, 논리적 레지스터 인덱스값으로 프로그램되도록 기준 물리적 레지스터와, 인덱스된 논리적 레지스터내에 기억될 값으로 프로그램되는 다음 순차적 기준 레지스터를 필요로하는 멀티플렉스된 레지스터 모델이다. 따라서, 순차적 레지스터가 호출시 DAC 인터페이스 객체(130)의 Write_reg 기능에 레퍼런스될 동안, 물리적 기준 레지스터의 단일 쌍은 이런 기능에 의해 기록된다.
각 객체의 Read_reg 기능은 유사한 변환을 수행한다. 레퍼런스된 논리적 레지스터는 대응 물리적 기준 레지스터에 대한 레퍼런스로 변환된다. DAC 인터페이스 객체(130)의 경우에, 변환은 정확한 값이 판독될 수 있는 논리적 레지스터를 정의하는 인덱스를 가진 기준 물리적 레지스터를 프로그래밍하는 것을 포함한다.
다른 인터페이스 객체는 제어기(19)의 다른 부 구성요소를 프로그램하는 데 적당한 바와 같이 명령어의 플랫 순차 레지스터 모델을 직렬 또는 비트 순차 모델로 변환시킬 수 있다. 따라서, 순차적 레지스터/인수 쌍은 논리적 레지스터 인덱스값으로 변환된 후에, 제어기(19)의 특정부 구성요소를 프로그램하는데 적당한 프로그램 값의 비트 직렬 시퀀스로 변환된다.
일례로서, S3 비젼 868 그래픽 가속기 칩을 활용하여 다이어몬드 스틸스 64 비디오 DRAM 비디오 제어기는 선택적으로 프로그램되어, 아래의 그래픽 모드를 인에이블시키고,
양호한 실시예에서, 하드웨어 인터페이스 객체의 Write_reg 및 Read_reg 기능은 레지스터 인터페이스(30)에 대해 하드웨어 판독 및 기록 운영을 실제로 수행하도록 보드 라이브러리(74')의 다수의 기능을 활용한다. 간접적 방식의 그런 부가적인 레벨은 제어기(19)의 특정 모델에 의존하는 서로 다른 물리적 어드레스에 존재하도록 제어기(19)의 서로 다른 하드웨어 부 구성요소를 고려한다. 따라서, 특정 하드웨어 인터페이스 객체가 완전히 제어기(19)의 부 구성요소의 특정 프로그래밍을 나타낼 동안, 보드 라이브러리(74')는 컴퓨터 시스템(10)의 물리적 어드레스 공간내에 부 구성요소를 암암리 위치시킨다. 결과적으로, Write_reg 기능 호출을 통해 DAC 인터페이스 객체에 의해 식별된 기준 물리적 레지스터는 DAC 부 구성요소 그 자체에 논리적으로 관계한다. 보드 라이브러리(74')는 레지스터 인터페이스(30)의 물리적 시스템 어드레스 공간내에 레지스터를 위치시키도록 DAC 기준 물리적 레지스터에 물리적 어드레싱 오프셋을 공급한다.
물리적 어드레싱 오프셋을 설정하기 위하여, 보드 라이브러리(74')는 차례로 제어기의 부 구성요소의 주요형에 특별한 다수의 판독 및 기록 루틴을 제공한다. 예를 들면, 제어기(19)의 특정 및 정의된 부 구성요소를 제어하더라도 클록 인터페이스 객체는 통상적으로 DAC 부 구성요소와 관련된 레지스터내에 위치되거나 그를 통해 접근 가능한 프로그램 가능 클록 발생기를 레퍼런스한다. 따라서, DAC 및 클록 인터페이스 객체 양자에 대해 보드 라이브러리(74')에 의해 제공된 물리적 어드레싱 오프셋은 동일하다.
보드 라이브러리(74')는 양호하게도 플랫 순차 물리적 레지스터 세트를 어드레스하는 하드웨어 인터페이스 객체에 대한 BoardRead_reg 및 BoardWrite_reg 기능을 지원한다. BoardRead_DAC, BoardWrite_DAC 및 BoardWrite_DAC_Array 기능은 보드 라이브러리(74')에 의해 제공되어, 멀티플렉스된 레지스터의 판독 및 기록을 지원하고, 제어기(19)에 의해 설정된 바와 같이 DAC 부 구성요소의 물리적 레지스터 어드레스 공간내에 위치된 색 팔레트 어레이(array)를 기록한다.
최종으로, BoardWrite_SerialDevice_start, 및 BoardWrite_SerialDevice_end 기능은 직렬 기록 운영을 제어기(19)의 직렬 프로그램된 부 구성요소에 지원하도록 제공한다.
일단 modes.dmm 파일로 부터 주사된 명령어가 실행되고 나면, 제어기(19)의 운영 모드는 바람직한 공간 해상도 및 색 농도에 대응하도록 변화되었다. 셀 라이브러리(72')는 그때 호출에 대한 오퍼랜드로서 "변경 모드"를 가진 인터페이스 객체의 특정 세트의 각 모드 세트 기능을 호출한다. 인터페이스 객체는 이런 호출을 활용하여 제어기(19)의 신규 운영 모드를 설정하는 데 필요한 소정의 부 구성요소 특정 루틴을 실행한다. 레지스터 인터페이스(30)내의 레지스터의 소정의 요구된 프로그래밍 또는 디스플레이 버퍼(20)의 조작은 이때에 수행될 수 있다. 최종 인터페이스 객체는 이런 모드 세트 호출로 부터 복귀할 시에, 셀 라이브러리(72')는 셀 객체(126)로 복귀한다.
"모드가 변경했음" 오퍼랜드에 따른 제 3 및 최종 호출은 그때 셀 라이브러리(72')에 의해 모드 세트에 참여한 각 인터페이스 객체로 행해진다. 양호하게도, 참여 하드웨어 인터페이스 객체는 운영 체계 인터페이스 객체 전에 호출된다. 각 인터페이스 객체가 호출될 시에, 객체는 제어기(19)의 신규 운영 모드에서 제어기(19)의 대응 부 구성요소의 운영 지원하는 데 필요한 소정의 하드웨어 특정 운영을 실행한다. 일반적으로, 하드웨어 인터페이스 객체는 이런 호출에 응답하여 간단히 복귀시킨다. 예외적인 것은 특정 객체가 공간 해상도, 색 농도 또는 다른 장치 특징에 의한 구현 종속성을 갖는 곳에 존재한다. 그래픽 객체(138)와 같은 하드웨어 인터페이스 객체에 의해 캡슐화된 모듈이 예를 들어 색농도로 구별된 동일 논리 기능을 지원하는 다중 루틴을 제공하는 곳에, 객체 구조의 호출 진입점내의 기능 포인터는 신규 색 농도에 적당한 루틴으로 포인트하도록 갱생(update)된다.
운영 체계 인터페이스 객체는 양호하게도 이런 "변경 모드" 호출을 활용하여, 제어기(19)의 신규 운영 모드의 디스플레이 해상도, 색 농도 또는 다른 장치 특징에 대응하도록 현재 문맥내에 존재하는 데이터 객체를 재실현한다. 특히, GDI 객체와 같은 운영 체계 인터페이스 객체는 디스플레이(32)상에서 가시적인 특징을 나타내는 관리 비트 맵 데이터 객체일 수 있다. 따라서, 특정 운영 체계 객체는 양호하게도 먼저 운영 체계 인터페이스 객체에 의해 자주 이용된 소정의 변경된 하드웨어 인터페이스 객체 기능 포인터를 편리한 호출 디스패치(dispatch)를 지원하는 운영 체계 인터페이스 객체의 로컬 코드 공간내로 복사시킬 수 있다. 비트 맵의 선형 보간법(interpolation)은 그때 양호하게 수행되어, 디스플레이(32)의 신규 공간 해상도를 매치(match)하도록 실제 비트맵 해상도 데이터 객체를 조정한다.
운영 체계 인터페이스 객체는 최종으로 요구되는 바대로 디스플레이(32)를 효과적으로 리프레시(refresh)하도록 대응 갱생 운영을 지향함으로써 "모드가 변경했음" 모드 세트 호출에 응답한다. 그런 갱생은 특히 제어기(19)의 신규 운영 모드에서 디스플레이(32)상에 가시적인 데이터 객체를 재 실현한 소정의 운영 체계 인터페이스 객체를 위해 수행된다. 일단 스크린 리프레시가 완료되면, 셀 라이브러리 모드 세트는 차례로 모드 세트 API 호출로 부터 복귀하는 셀 객체로 복귀한다. 따라서, 현재 문맥내의 모드를 변경하는 프로세스는 완료된다.
1. 조합된 문맥 및 모드 스위치
문맥 스위치는 양호한 실시예에서 제어기(19)의 모드 세트를 신규 색 농도에 지원하도록 모드 스위치와 조합하여 수행된다. 제어기(19)의 현재 운영 모드의 것과 다른 특정 색 농도의 기대치(expectation)로 실행하는 응용(60)을 위한 API 호출은 현재 색 농도에 적합하게 되어야 한다. 특히, 그런 API 호출이 지속 팔레트 또는 색 맵의 존재에 의존하여 장치 드라이버(50)에 행해지는 곳에, 필요하지 않다면 문맥의 지원이 바람직하다. 선택적 사항은 운영 체계에 의해 지원될 수 있다. 운영 체계 커널(56)내로의 호출 가능 진입점은 목표(target) 색 농도에 대한 o/s API 호출 인터페이스에서나 그위에서 모든 상주 비트맵의 색 농도 변환을 위해 제공할 수 있다. 그러나, 지시는, 그런 변환의 효율 및 역방향 가능성과, 실제 가변적인 비트맵의 일정한 형태 및 포맷에 관한 지속 가정(assumptions)에 의한 운영 체계 계층(54)과 상호 동작하는 응용 및 장치 드라이버의 잠재적 비호환성에 관해 존재할 수 있다. 결과적으로, 장치 드라이버 그 자체내에서 분리되는 문맥 스위칭은 서로 다른 운영 체계 구현중에서 더욱 튼튼하고 휴대 가능하다.
팔레트 및 다른 지속 데이터는 각 문맥에 의해 유지되어, 그런 문맥이 현재 활동하지 않을 시에 조차 레퍼런스에 이용 가능하다. 문맥은 장치 드라이버(50)의 초기화동안 디폴트에 의해 생성된다. 부가적인 문맥은 신규 색 농도에 대한 모드 변경을 위해 장치 드라이버(50)에 행해진 API 호출에 응답하여 필요한 만큼 생성된다.
도 5a 에서, 셀 라이브러리(72')는 적어도 초기에는 단일 셀 객체(150) 및 잠재적으로는 부가적인 셀 객체(152, 153, 156)를 포함하는 메모리 폴(pool)(148)을 관리한다. 셀 객체(150, 152, 154, 156)의 각각은 장치 드라이버(50)내의 독립 문맥을 나타낸다. 하나 이상의 셀 객체(150, 152, 154, 156)는 현재 실행하는 하나 이상의 응용(60)의 색 농도를 나타내는 데에 적당한 바와 같이 풀(148)내에서 언제라도 존재할 수 있다. 셀 객체(150)에 의해 표시되는 문맥을 포함하는 문맥은 그때 실행하는 어떤 응용(60)도 문맥에 의해 지원된 색 농도를 레퍼런스하지 않을 경우 나중에 폐쇄될 수 있다. 셀 라이브러리(72')는 셀 객체(148)의 풀을 관리하는 것 이외에도 현재 문맥 포인터(158)를 유지한다. 이런 포인터(158)는 제어기(19)의 현재 운영 모드에 대응하거나 논리적으로 정의하는 특정 셀 객체(150, 152, 154, 156)를 식별하는 데 이용된다.
도 5b 에서 일반적으로 도시된 바와 같이, 장치 드라이버(50)의 운영에서 문맥을 정의할 셀 객체의 사용으로, 장치 드라이버(50)내의 각 문맥내에서 별개의 인터페이스 객체(170, 172)의 사례화가 허용된다. 인터페이스 객체(170, 172)의 각 사례화로, 전용 데이터 공간(174, 176)은 할당되어, 각 인터페이스 객체(170, 172)와 관련된다. 그러나, 특정 인터페이스 객체(170, 172)의 모든 사례화는 공통으로 공유된 인터페이스 모듈(178)을 캡슐화한다. 인터페이스 모듈(178)의 실행에서, 전용 데이터 공간(174, 178)에 대한 레퍼런스는 각 인터페이스 객체(170, 172)내에서 설정된 독립 포인터를 통해 인에이블된다. 따라서, 인터페이스 모듈(178)은 특정 문맥에서 정확한 객체에 전적으로 접속되고, 모듈(178)은 다중 문맥의 존재의 양상을 명백히 관리하는 데 요구되지 않는다. 오히려, 문맥 관리 및 조작 기능은 집중되어, 셀 라이브러리(72')의 루틴에 의해 수행된다.
문맥 스위치를 수행하는 프로세스는 도 6a 및 6b 에서 설명된 프로세스 단계에 따라 일어난다. 문맥 스위치는 적어도 추론상 운영 모드로 모드 변경을 암시하는 API 호출을 수신하는 셀 객체의 현재 활동 문맥 사례화(150)로 시작하는 데, 상기 운영 모드는 현재 문맥의 것과 다른 색 농도에 대한 모드 변경과 같은 현재 모드의 소정의 양상의 지속성을 필요로 한다. 전과 같이, 셀 객체(150)는 API 호출의 오퍼랜드의 초기 타당성 검사를 수행하고, 문맥 스위치가 호출되는 지를 결정하며, 그리고 생성 신규 문맥 호출(180)을 셀 라이브러리(72')에 지시한다. 셀 라이브러리(72')는 바람직한 색 농도를 가진 문맥이 이미 존재하는 지를 결정하도록 (184) 문맥 풀(148)내에 존재할 수 있는 셀 객체의 존재하는 각 사례화를 조사한다. 셀 객체의 사례화가 셀 객체(152)와 같이 바람직한 색 농도와 함께 존재할 경우, 셀 라이브러리(72')에 대한 생성 신규 문맥 호출은 셀 객체(150)으로 복귀한다.
그러나, 바람직한 문맥이 그때 존재하지 않을 경우, 신규 셀 객체 사례화는 생성된다(186). 이런 신규 셀 객체의 생성전에, 문맥 변경이 앞서 지원되지 않는 색 농도에 대한 지원을 필요로 하는 그런 제 1 변경일 경우, 셀 라이브러리(72')는 대응하는 색 농도 변환을 위한 지원을 포함하도록 수정될 수 있다. 본 발명의 양호한 실시예에서, 셀 라이브러리(72')는 단지 편의상 모든 가능 색 농도 변환을 위한 지원을 포함하도록 제 2 존재 문맥의 생성과 동시에 수정된다. 특히, 현재 및 목표 색 농도를 결정하고, 그 사이에서 변환하는 루틴은 셀 라이브러리(72')의 코드로 직접 패치(patch)되어, 색 농도 변환이 단일 문맥만이 사용중일 시에 조차 각 및 모든 드로어계 운영에 적용할 수 있는지의 일정한 조건부 레스팅을 제거한다.
본 발명의 색 농도 루틴은 8, 16, 24 및 32 비트의 색 농도 사이에서 장치 종속 비트맵의 접촉식(on-the-fly) 변환을 위해 제공한다. 16, 24 및 32 비트 색 농도간의 변환은 현재 디스플레이 색 농도에서 각 디스플레이 픽셀에 기억된 RGB 색 값 투플(tuples) 간에 직접 맵함으로써 수행한다. 픽셀마다 8비트 색 인덱스를 이용한 팔레트화된 색 공간으로 부터의 변환은 원시(source) 응용의 문맥의 PDevice 기억된 색 팔레트 및 변환표내에서 RGB 색 값 투플을 먼저 탐색하여, 다시 현재 디스플레이 색농도로 직접 RGB 색 맵핑을 수행함으로써 수행된다.
16, 24 또는 32 비트 색 농도로 부터 8 비트 팔레트화 형태로 접촉식의 변환이 다소 포함된다. 이런 변환은 변환되는 각 RGB 투플에 가장 적합한 8비트 색 공간의 탐색을 요구한다. 일반적으로, 최소 평균 제곱 알고리즘은 최상 적합 색 맵핑을 발견하는 데 이용될 수 있다. 유효(significant) 수행 개선은 변환된 색을 캐시(cache)함으로써 달성될 수 있다. 예를 들면, 8, 192 32 비트 캐시 엔트리를 가진 기본 캐시표는 32 비트 RGB 투플을 8 비트 팔레트 인덱스로 변환시키는 데 이용될 수 있다. 각 10 비트 RGB 값은 3개의 비트만큼 감소된 정밀도를 갖고 있다. 따라서, 현재 색 팔레트에 대해 접촉식 최소 평균 제곱 최상 적합 매치를 행함으로써 결정된 8 비트 팔레트 인덱스값은 빠른 변환 탐색표를 설정하도록 각 21 비트 투플과 캐시될 수 있다. 연이은 색 변환은 그때 먼저 선 변환된 팔레트 인덱스에 대한 표를 탐색할 수 있다. 결과적으로, 모든 색 농도 변환은 각 API 초기화된 드로어계 운영의 부분으로서 셀 라이브러리(72')에 직접 지원될 수 있다.
신규 셀 객체의 사례화는 셀 인터페이스 모듈의 사례화 루틴을 호출함으로써 수행된다. 장치 드라이버(50)의 원 사례화에 따라, 신규 셀 객체 사례화, 지금은 셀 객체(152)가 할당되어 초기화된다. 초기화 호출은 그때 보드 라이브러리(74')로 행해진다. 셀 라이브러리(72')와 같은 보드 라이브러리(74')가 제어기(19)의 모든 운영 모드에 걸쳐 상수(constant)이므로, 개별 하드웨어 인터페이스 객체에 대한 레퍼런스와 다른 보드 라이브러리(74')에 대해 필요한 레퍼런스는 신규 셀 객체(152)에 접속된다. 보드 라이브러리(74')는 그때 시퀀스내의 각 하드웨어 인터페이스 모듈의 사례화 루틴을 호출하여, 객체의 신규 사례화를 생성시키고, 객체를 신규 셀 객체(152)의 보드 구조에 접속시킨다. 각 모듈의 RegClassHandler 구조의 내용물(contents)과 같은 색 농도 스위치에 걸친 상수는 완전히 재생성되거나 간단히 복사되며, 또는 현재 문맥의 객체로 부터 레퍼런스될 수 있다. 예를 들면, 그래픽 하드웨어 인터페이스 객체(138)의 초기화시, 신규 전용 하드웨어 가속기 코드 데이터 객체는 생성될 수 있다. 이런 데이터 객체에 의해 기억된 코드는 제어기(19)의 그래픽 부 구성요소의 하드웨어 가속기를 초기화하도록 다운로드(download)되는 초기화 상수 또는 시퀀서 코드일 수 있다. 따라서, 서로 다른 시퀀서 코드 세트 및 서브-세트는 서로 다른 문맥에서 그래픽 인터페이스 객체에 의해 관리될 수 있다. 이런 능력은 가속기 코드가 필요한 만큼 아마 서로 다른 드로어계 명령세트의 최적 실행을 위한 가속화 알고리즘을 조정하도록 단일 운영 모드내에서 그래픽 부 구성요소의 운영시 동적으로 교체(swap) 가능한 곳에 특히 중요하다. 보드 라이브러리 초기화 루틴은 그때 셀 라이브러리(72')로 복귀한다.
잔여 운영 체계 인터페이스 모듈의 초기화 루틴은 그때 신규 셀 객체(152)의 초기화를 완료하도록 호출된다. 각 모듈은 대응 인터페이스 객체의 신규 사례화를 생성시키고, 객체에 대한 소정의 필요한 전용 데이터 공간을 생성시켜, 객체를 신규 셀 객체(152)에 접속한다. 특히, 직접 드로어 운영 체계 인터페이스 객체(122)의 초기화는 신규 문맥 특성 PDevice 구조 및 잠재적으로는 신규 GDI-Infotable 구조의 생성을 위해 제공한다. 하드웨어 인터페이스 객체에 따라, 이런 구조에 의해 기억된 데이터는 완전히 재생성될 수 있거나, 현재 문맥의 대응 구조로 부터의 데이터는 신규 구조를 초기화하는 데 이용될 수 있다. 그러나, 신규 PDevice 구조의 데이터는 특히 신규 문맥의 색 농도를 정의하도록 수정된다. 마찬가지로, GDI-Infotable 의 픽셀 농도 필드는 또한 신규 색농도를 반영하도록 수정된다. 그후 셀 라이브러리(72')에 의해 관리되는 그런 2개의 신규 구조에 대한 포인터는 논리적으로 신규 문맥의 셀 객체(152)와 관련된다.
결과적으로, 운영 체계 및 하드웨어 인터페이스 객체의 전 컴플리먼트(compliment)는 셀 객체(150)에 의해 표시되는 현재 문맥과 논리적으로 다른 문맥을 정의하도록 생성된다. 실행은 그때 셀 라이브러리(72')로 부터 셀 객체(150)으로 복귀한다.
셀 객체(150)는 그후 신규 문맥을 실현하도록 호출을 보드 라이브러리(72')에 지시한다(200). 셀 객체(150)는 양호한 실시예에서 제어기(19)의 바람직한 운영 모드에 대한 바람직한 색 농도 및 공간 해상도를 포함하는 신규 문맥의 특징을 식별하기에 충분한 오퍼랜드를 제공한다. 응답하여, 셀 라이브러리(72')는 문맥 풀(148)을 탐색하여, 바람직한 신규 문맥에 대응하는 셀 객체(152)와 같은 셀 객체를 선택한다.
문맥 스위치의 실제 수행을 준비함에 있어서, 셀 라이브러리(72')는 그때 "모드가 막 변경할려고 함" 오퍼랜드에 따른 모드 세트 호출을 모드 세트(206)에 참여하는 각 인터페이스 객체에 지시한다. 전과 같이, 각 참여 인터페이스 객체는 소정의 상태 관련 정보를 대응 전용 데이터 공간내에 저장하여, 그런 정보가 모드 스위치 뿐만 아니라 문맥 스위치에도 걸쳐 확실히 지속하게 한다.
최종 참여 인터페이스 객체로 부터 복귀함과 동시에, 셀 라이브러리(72')는 현재 문맥을 정의하는 셀 객체로서 신규 셀 객체(152)를 설치한다. 동시에, 셀 라이브러리(72')는 연속 API 호출의 운영 체계 계층(54)에 의해 장치 드라이버(50)에 레퍼런스되는 구조로서 셀 객체(152)와 논리적으로 관련된 PDevice 구조 및 GDI-Infotable 구조를 설정한다.
셀 라이브러리(72')의 중지 루틴은 그때 모드 스위치를 구현하는 데 필요한 명령어를 실행하도록 호출된다. 이런 명령어의 처리 및 실행은 장치 드라이버(50)에 의해 문맥 스위치를 포함하지 않는 간단한 모드 스위치를 구현할 필요한 처리와 일치한다.
일단 모드 세트 명령어가 실행되었을 경우, 셀 라이브러리(72')는 변경 모드 오프랜드에 따른 모드 세트 호출을 각 참여 객체에 지시한다. 전과 같이, 각 객체는 신규 시퀀서 코드를 그래픽 가속기 부 구성요소에 다운로드하는 바와 같은 제어기(19)의 신규 운영 모드를 구현하거나 지원하는 데 필요한 소정의 객체 특정 루틴을 실행할 수 있다.
최종으로, 셀 라이브러리(72')는 모드 세트 호출을 "모드가 변경했음" 오프랜드에 따른 각 참여 객체에 지시한다. 응답하여, 각 참여 객체는 예를 들어 디스플레이 버퍼(20)내의 메모리 사용을 재할당하고, 디스플레이(32)상에 하드웨어 커서의 위치를 설정하는 제어기(19)의 운영 환경을 설정하도록 실행한다. 게다가, 호출은 폴(fall) 스크린 리프레서(refresher)을 요청하도록 운영 체계 객체(128)를 통해 행해진다. 응답하여, 운영 체계 커널(56)은 포인터 레퍼런스를 디스플레이(32)상에서 가시적인 비트맵에 제공하는 장치 드라이버(50)에 일련의 호출을 동등하게 한다. 각 비트 맵이 장치 드라이버(50)를 통해 처리될 시에, 소정의 요구된 색 농도 변환은 셀 라이브러리(72')에 의해 적당히 수행된다.
최종 참여 객체로 부터 복귀함과 동시에, 셀 라이브러리(72')는 셀 객체(152)를 통해 효과적으로 운영 체계 계층(54)으로 복귀한다. 결과적으로, 장치 드라이버(50)는 운영 체계 계층(54) 또는 응용(60)의 포함된 참여 없고, 본질상 그와 관계없이 모드 스위치 및 문맥 스위치 양자를 완료한다.
VI. 운영 상태 종료
최종으로, 본 발명은 일반적으로 도 7 에 도시된 바와 같이 장치 드라이버(50)의 운영을 종료하는 프로세스를 제공한다. 특히 윈도 95TM과 같은 운영 체계 커널(56)의 구현은 운영 체계 커널(56)의 종료와 동시에 컴퓨터 시스템(10)내의 각 장치 드라이버에 지시된 표준 호출로서 차단(shutdown) API 호출을 제공한다. 차단 API 호출의 수신과 동시에, 셀 객체(152)와 같은 현재 활동 문맥의 셀 객체는 운영 체계 인터페이스 모듈에 의해 연속 수신된 API 호출의 수동(222)을 종료함으로써 장치 드라이버(50)에 의해 소정의 다른 API 호출의 처리를 디스에이블하도록 운영한다. 결과적으로, 장치 드라이버(50)는 그때 기대되지 않은 API 호출의 수신으로 방해를 받지 않고 순서에 맞는 방식으로 차단을 수행할 수 있다.
modes.dmm 구성 파일의 디폴트 섹션은 그때 판독되어, 셀 라이브러리(72')의 파스 루틴에 의해 실행된다. 이런 디폴트 섹션에 의해 제공된 명령어는 제어기(19)에 대한 디폴트 운영 모드를 세트하도록 활용한다. 따라서, 제어기(19)는 운영 체계 커널(56)의 차단에 연이은 잠재적인 사용에 적당한 공지된 안정 상태에서 설정된다.
셀 라이브러리(72')는 그때 장치 드라이버(50)의 인터페이스 객체 및 모듈에 의해 사용된 시스템 메모리를 프리(free)하도록 운영한다. 특히, 셀 라이브러리(72') 는 장치 드라이버(50)의 각 존재 문맥을 식별하도록 동작한다. 각 식별된 문맥(228)에 대해, 셀 라이브러리(72')는 특정 문맥(230)에 특별한 각 하드웨어 인터페이스 객체를 순차적으로 프리하도록 보드 라이브러리(72')를 호출한다. 보드 라이브러리(74')는 차례로 식별된 문맥의 셀 객체와 관련된 각 하드웨어 인터페이스 객체를 호출한다. 하드웨어 인터페이스 모듈과 관련도니 최종 객체의 프리잉(freeing)으로, 객체 및 모듈 양자와 관련된 메모리 공간은 프리된다. 일단 모든 문맥에 대한 하드웨어 인터페이스 객체의 모두가 프리되었을 경우, 보드 라이브러리(74')는 다시 그의 자신의 메모리(232)를 프리하도록 호출된다.
셀 라이브러리(72')는 객체 및 대응 모듈과 관련된 메모리 공간을 프리하도록 각 존재 문맥에 대한 각 운영 체계 인터페이스 객체(234)를 호출한다. 장치 드라이버(50)의 존재 문맥을 정의하는 셀 객체는 또한 프리된다. 셀 라이브러리(72')는 관련된 메모리를 효과적으로 프리하도록 종료하고(236), 실행은 운영 체계 계층(54)의 종료를 계속하도록 운영 체계 커널(56)로 복귀한다.
V. 가상화 드라이버 운영
양호한 마이크로소프트 윈도 95 환경에서, 소위 Dos-Box 보호 실행 공간내에서 레거시(legacy) 응용 런닝(running)을 지원할 필요가 있다. 본 발명의 양호한 구현에 적절한 보호 실행은 전 스크린 또는 윈도 모드로 제공된다. 레거시 응용은 직접 접근하여 전 스크린 모드에서 제어기(19)를 프로그램하도록 허용된다. 윈도 모드에서, 통상적으로 VxD 드라이버라 칭하는 가상화 장치 드라이버는 레거시 응용에 의해 기대된 하드웨어 레지스터를 에뮬레이트(emulate)하도록 제공된다. 다른 윈도 응용과 공동 존재하고, 공동 실행하기 위하여, VxD 드라이버는 레거시 응용에 의해 동적으로 제공된 하드웨어 프로그래밍의 윈도 관련 에뮬레이션을 제공하도록 기대된다. 통상적으로, VxD 드라이버는 다시 제어기(19)의 특정 구현 전체의 에뮬레이션을 지원하는 단일 모놀리식 소프트웨어 모듈로서 구현된다. 따라서, 통상의 VxD 드라이버는 통상 장치 드라이버와 관련된 동일한 문제를 갖는다.
일반적으로 도 8 에 도시된 바와 같이, 본 발명의 장치 드라이버(50)의 구조는 특히 가상 디스플레이 드라이버(VDD)를 포함하는 VxD 드라이버를 구현하는 데 직접적이고 효과적으로 적응될 수 있다. 전술된 바와 같은 장치 드라이버(50)는 양호하게도 운영 체계 계층(54)내에서 통상적인 방식으로 설정된 윈도(Win 16) 가상 머신(VM)(240)을 지원하여 운영한다. Dos VM(242)는 하드웨어(30)에 직접 접근할려고 하는 레거시 응용에 Dos-Box 보호 실행 공간을 제공한다. 장치 드라이버(50)의 버전(50')은 Dos VM(242)내로 부터나 그에 의해 지시된 하드웨어 접근 시도의 결과를 적당히 에뮬레이트하는 바와 같이 트랩(trap)하고 평가하도록 제공된다. Dos VM(242)내에서 응용의 윈도 모드 실행을 지원하여 활동적으로 됨과 동시에 VDD(50')은 운영체제의 통상적인 사용을 통해 레지스터 인터페이스(30)에 대응하는 I/O 또는 메모리 공간에 대한 접근 트랩을 선택적으로 설정한다. 이런 접근 트랩은 일반적으로 Dos VM(242)가 전 스크린 모드로 스위치할시나, 실행이 다른 가상 머신(240,244)로 이동할시에 해제된다. 접근 트랩은 실행이 윈도 모드에서 Dos VM(242)로 복귀하거나, 전 스크린 모드로 부터 윈도 모드로 스위치함과 동시에 재표명(reassert)된다.
접근 트랩이 접근 시도를 검출할 때마다, VDD(50')에는 트랩에 의해 획득된 접근 특징 정보가 제공된다. 특히, 도 9 에 도시된 바와 같이 보드 라이브러리(74")에는 논리적으로 커넥션(246)을 통해 운영 체계(54)에 의해 접근시도 정보가 제공된다. 양호하게도, VDD(50')의 구성요소는 디스플레이 드라이버(50)의 단일 문맥 버전을 구현한다. 그러나, 다중 문맥은 Dos VM(242)하에 다중 제어기(19)를 지원하는 데에 적당한 바와 같이 쉽게 지원될 수 있다.
단일 문맥내에서, 하드웨어 인터페이스 객체(130', 132', 134' 및 138')는 하드웨어에 직접 접근할 연속 시도에 의해 디스플레이의 의도된(intended)상태의 표시를 유지하도록 접근 특징 데이터를 기억하기 위해 운영한다. 양호하게도, 하드웨어 인터페이스 객체와 관련된 RegClassMap 구조는 하드웨어 부 구성요소의 각 등급과 관련된 상태 정보를 위한 기억 공간에 포인터로 확장된다. 하드웨어 인터페이스 객체는 또한 운영체제 호출을 생성시키는 에뮬레이션 루틴에 o/s 객체(128')을 지원하여, 의도된 스크린 외관(appearance)의 적당한 표시의 디스플레이를 유발시킨다. 이런 호출은 운영 체계 계층(54)에 적용되고, 차례로 디스플레이 드라이버(54)로 적당히 루프된다. 전 스크린 모드로 스위치함과 동시에, 하드웨여 인터페이스 객체에 의해 유지된 디스플레이 상태는 상태 데이터를 레지스터 인터페이스(30)에 인가함으로써 의도된 디스플레이 상태를 직접 설정하는 데 이용될 수 있다.
장치 드라이버(50')의 파서(parser) 루틴은 보통과는 반대로 접근 특징 정보를 효과적으로 분석하는 데 이용된다. 양호하게도, 접근 트랩은 어드레스를 등급 트랩 핸들러에 지정함으로써 장치 등급을 전적으로 접근시도를 특징화하는 역할을 한다. 따라서, 접근이 이루어진 등급, 어드레스 및 값은 트랩 핸들러에 의해 수집되어, 역 파서 루틴에 제공된다. 따라서, 각 트랩된 접근 시도로, 접근 관련 데이터는 대응 RegClassMap 식별된 기억 장치내에 기억된다. 역 파서는 또한 modes.dmm 파일내에 기억된 등급 레지스터 명령어로 부터 궁극적으로 결정된 레지스터 정의에 대한 분석을 수행한다. 분석의 결과는 기억되도록 의도된 레지스터가 인덱스 레지스터이거나 다른 관리 기능 레지스터 또는 데이터 레지스터인지를 논리적으로 결정한 것이다. 여기서, 의도된 레지스터는 인덱스 레지스터 또는 다른 관리 기능 레지스터이고, 상태의 결과 반경은 기록된다. 의도된 레지스터가 데이터 레지스터인 곳에, 레지스터의 신규 상태는 기록되어, 소정의 에뮬레이션이 요구되는 지에 관해 결정이 행해진다. 기록되는 특정 레지스터에 따라, 어떤 에뮬레이션도 요구되지 않거나, 전 인덱스 및 데이터 접근 운영은 그때 수행될 수 있다.
결과적으로, 거의 동일한 하드웨어 및 운영 체계 인터페이스 객체 정의는 양호하게 이용되고, 또한 서로 다른 디스플레이 특징을 지원하는 다기능간에 선택하는 동안 방법은 캡슐화된 하드웨어 인터페이스 모듈에 의해 구현된 디스플레이 특징 에뮬레이션 루틴중에서 선택하는 데 이용될 수 있다. 파서 루틴이 식별 가능한 모드 세트는 검출하는 곳에, 셀 객체(126')는 전술된 바와 같이 모드 세트 운영을 수행하도록 o/s 객체(128')를 통해 호출될 수 있다. 운영 체계 객체(120', 122', 126')에 의해 구현된 거의 선형 호출 시퀀스는 직접 인에이블된다. 그래서, 운영 체계 인터페이스 객체 및 잔여 VDD(50')간의 기능 호출 관계는 장치 드라이버(50)의 경우에서와 동일하다.
V. 결론
따라서, 가상 장치 드라이버로서 운영할 뿐만 아니라 복잡한 다기능 주변 제어기를 지원하는 데 적당한 매우 최적인 장치 드라이버 구조는 기술되었다. 기술된 장치 드라이버의 구조는 적재 시간에 장치 드라이버의 동적 구성을 직접 지원하여, 양호하게도 부구성 요소마다의 상세 토대위에 하드웨어로 부터 직접 결정되는 바와 같이 주변 제어기의 하드웨어 구성을 특별히 매치하는데, 이는 특정 부 구성요소 설계에 따라 특히 모듈 변경의 기능 분리를 지원하는 모듈러 구조를 사용하고, 제어기의 운영 상태의 모드 스위치를 수행하는 효율적인 메카니즘을 제공하며, 선택적으로 모드 스위치의 수행에 따른 독립문맥의 지원을 통해 모드 스위치와 관계없이 지속 데이터의 유지 및 관리를 위한 효율적인 메카니즘을 제공하며, 그리고 비디오 디스플레이 제어기 응용에서 색 농도 변환의 효율적인 관리를 위해 제공한다. 더욱이, 상기 구조의 모듈러 복잡성에도 불구하고, 모듈간에 지원된 상호 운영 관계는 거의 선형화 호출 시퀀스가 운영 체계 API 호출을 가상화하고 구현하게 한다.
본 발명의 양호한 실시예에 대해 전술된 바에 따르면, 기술된 실시예는 본 기술 분야의 숙련자에 의해 다양하게 수정 및 변형이 쉽게 이루어질 수 있다. 첨부된 청구의 범위내에서 본 발명은 전술된 바와 다르게 실시될 수 있는 것으로 이해된다.

Claims (10)

  1. 프로세서 및 메모리를 포함하고, 장치 드라이버를 통해 상기 하드웨어 제어기에 결합하는 운영 체계를 실행하는 컴퓨터 시스템에 부착된 하드웨어 제어기의 운영 상태의 조작을 제어하는 프로세스에 있어서,
    1) 제 1 소정의 운영 상태에서 상기 하드웨어 제어기의 제 2 소정의 운영 상태까지의 모드 수위치 이벤트의 발생을 상기 프로세서의 운영으로 결정하는 단계,
    2) 상기 장치 드라이버에 의해 상기 메모리내에 예약된 제 1 사전 정의 위치내의 상기 하드웨어 제어기의 상기 제 1 소정의 운영 상태에 대응하는 제 1 문맥을 정의한 데이터를 선택적으로 기억하는 단계,
    3) 상기 장치 드라이버에 의해 상기 메모리내에 예약된 제 2 사전 정의 위치로 부터 상기 제 2 소정의 운영 상태에 대응하는 제 2 문맥을 정의한 데이터를 선택적으로 복원하는 단계와,
    4) 상기 제 2 소정의 운영 상태를 설정하도록 상기 제 2 문맥을 정의하는 상기 데이터를 상기 하드웨어 제어기에 인가하는 단계로 이루어지는 것을 특징으로 하는 운영 상태 조작 제어 프로세스.
  2. 제 1 항에 있어서,
    선택적으로 복원하는 상기 단계는,
    1) 상기 제 2 사전 정의 위치가 상기 장치 드라이버에 의해 예약되었는 지를 결정하는 단계,
    2) 상기 제 2 사전 정의 위치가 사전에 예약되지 않았을 경우에 상기 장치 드라이버에 대한 상기 제 2 사전 정의 위치를 예약하는 단계와,
    3) 상기 제 2 문맥을 정의하는 데이터를 초기하화하는 단계를 포함하는 것을 특징으로 하는 운영 상태 조작 제어 프로세스.
  3. 제 1 항에 있어서,
    선택적으로 기억 및 복원하는 어느 상기 단계는 스킵(skip)되는 것을 특징으로 하는 운영 상태 조작 제어 프로세스.
  4. 제 1 또는 3 항에 있어서,
    상기 제 2 문맥을 정의하는 상기 데이터는 상기 장치 드라이버 외부의 데이터 파일로 부터 동적으로 획득되는 것을 특징으로 하는 운영 상태 조작 제어 프로세스.
  5. 운영 인터페이스를 프로그램가능 제어기에 제공하기 위해 컴퓨터 시스템의 운영 체계와 함께 사용되는 장치 드라이버에 있어서,
    1) 운영 체계에 결합가능하고, 모드 세트 운영을 초기화하도록 소정의 API 호출에 대한 진입점 지원을 제공하는 제 1 인터페이스 모듈,
    2) 상기 운영 체계에 결합 가능하고, 시스템 구성 데이터를 판독하도록 소정의 운영 체계에 대한 진입점 지원을 제공하는 제 2 인터페이스 모듈,
    3) 프로그램 가능 제어기에 결합 가능하고, 소정의 하드웨어 인터페이스 레지스터 프로그래밍 루틴에 대한 진입점 지원을 제공하는 제 3 인터페이스 모듈과,
    4) 상기 제 1, 2 및 3 인터페이스 모듈에 결합 가능한 라이브러리 모듈을 구비하는 데, 상기 라이브러리 모듈은 상기 제 1 인터페이스 모듈에 의해 상기 소정의 API 호출의 수신에 응답하고, 상기 라이브러리 모듈은 상기 제 2 인터페이스 모듈에 호출을 제공하여, 상기 운영 모드 세트 데이터에 대응하는 소정의 시스템 구성 데이터를 판독하도록 상기 소정의 운영 체계 호출을 초기화하며, 상기 라이브러리 모듈은 상기 소정의 시스템 구성 데이터내에 제공된 소정의 명령어를 실행함으로써 레지스터 프로그래밍 데이터를 생성시키는 파서를 포함하며, 상기 레지스터 프로그래밍 데이터는 상기 제 3 인터페이스 모듈의 상기 소정의 하드웨어 인터페이스 레지스터 프로그래밍 루틴에 제공되는 것을 특징으로 하는 장치 드라이버.
  6. 제 5 항에 있어서,
    상기 라이브러리 모듈은 상기 컴퓨터 시스템의 메모리내의 상기 운영 체계에 의해 적어도 상기 장치 드라이버의 사례화 및 초기화와 동시에 상기 제 1, 2 및 3 모듈에 결합되는 것을 특징으로 하는 장치 드라이버.
  7. 제 6 항에 있어서,
    상기 제 3 모듈은 상기 제 3 모듈에 의해 지원된 실행 가능 기능에 대한 다수의 호출 진입점을 가진 프로그램 가능 모듈 인터페이스를 포함하고, 상기 제 3 모듈은 상기 제 3 모듈의 상기 다수의 호출 진입점의 소정의 서브세트에 대한 상기 다수의 호출 진입점의 초기화를 위해 제공하는 것을 특징으로 하는 장치 드라이버.
  8. 제 7 항에 있어서,
    상기 제 3 모듈은 상기 모드세트 운영과 일치하는 상기 제 3 모듈의 상기 다수의 호출 진입점의 선택적 서브세트에 대한 상기 다수의 호출 진입점의 재초기화를 위해 제공하는 것을 특징으로 하는 장치 드라이버.
  9. 제 8 항에 있어서,
    상기 제 1 모듈은 상기 프로그램 가능 모듈 인터페이스의 복사본(copy)을 포함하고, 상기 복사본은 상기 제 3 모듈의 상기 프로그램 가능한 모듈 인터페이스내에 제공된 상기 다수의 호출 진입점의 상기 소정의 서브세트 또는 상기 선택적 서브세트에 적합한 것을 특징으로 하는 장치 드라이버.
  10. 컴퓨터 시스템에 결합되어, 레지스터 인터페이스를 상기 컴퓨터 시스템에 제공하는 프로그램 가능한 제어기의 운영 상태의 모드 세트를 수행하는 프로세스로서, 상기 컴퓨터 시스템에 의해 실행된 운영 체계는 상기 프로그램 가능한 제어기의 운영 모드의 소정의 특징을 정의하는 소정의 데이터를 포함한 모드 스위치 호출을 제공하는 운영 상태의 모드 세트 수행 프로세스에 있어서,
    1) 상기 모드 스위치 호출에 응답하여, 상기 프로그램 가능한 제어기의 모드 세트를 수행하도록 결정하는 단계,
    2) 상기 소정의 데이터에 의해 상기 모드 세트에 대한 목표(target) 모드를 결정하는 단계,
    3) 상기 목표 모드에 대응하는 소정의 구성 데이터를 획득하는 단계,
    4) 상기 소정의 구성 데이터내에 포함된 다수의 명령어를 식별하여 실행하도록 상기 소정의 구성 데이터를 파스(parse)하는 단계로서, 상기 다수의 명령어의 실행은 상기 목표 모드로 상기 프로그램 가능한 제어기의 상기 모드 세트를 수행하는 데 적당한 레지스터 프로그래밍 데이터를 제공하는 상기 소정의 구성 데이터 파스 단계와,
    5) 상기 레지스터 프로그래밍 데이터를 상기 레지스터 인터페이스에 제공하는 단계로 이루어지는 것을 특징으로 하는 운영 상태의 모드 세트 수행 프로세스.
KR10-1998-0703750A 1995-11-21 1996-11-21 동적프로그램가능모드스위칭장치드라이버구조 KR100421228B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/561412 1995-11-21
US8/561412 1995-11-21
US08/561,412 US6289396B1 (en) 1995-11-21 1995-11-21 Dynamic programmable mode switching device driver architecture

Publications (2)

Publication Number Publication Date
KR19990071479A true KR19990071479A (ko) 1999-09-27
KR100421228B1 KR100421228B1 (ko) 2004-05-31

Family

ID=24241869

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-1998-0703750A KR100421228B1 (ko) 1995-11-21 1996-11-21 동적프로그램가능모드스위칭장치드라이버구조

Country Status (7)

Country Link
US (1) US6289396B1 (ko)
EP (1) EP0862759B1 (ko)
JP (2) JP4442732B2 (ko)
KR (1) KR100421228B1 (ko)
AT (1) ATE352067T1 (ko)
DE (1) DE69636855T2 (ko)
WO (1) WO1997019402A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070058977A (ko) * 2005-12-05 2007-06-11 한국전자통신연구원 홈 네트워크 단말 시스템 소프트웨어의 동적 재구성 장치및 방법

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161250A (ja) 1994-12-06 1996-06-21 Canon Inc 情報処理装置
US5812857A (en) * 1996-08-28 1998-09-22 Extended Systems, Inc. Field configurable embedded computer system
US6496847B1 (en) * 1998-05-15 2002-12-17 Vmware, Inc. System and method for virtualizing computer systems
US6952829B1 (en) * 1998-06-29 2005-10-04 International Business Machines Corporation Dynamically adapting between pessimistic and optimistic notifications to replicated objects
US8631066B2 (en) 1998-09-10 2014-01-14 Vmware, Inc. Mechanism for providing virtual machines for use by multiple users
US6347344B1 (en) * 1998-10-14 2002-02-12 Hitachi, Ltd. Integrated multimedia system with local processor, data transfer switch, processing modules, fixed functional unit, data streamer, interface unit and multiplexer, all integrated on multimedia processor
US7516453B1 (en) * 1998-10-26 2009-04-07 Vmware, Inc. Binary translator with precise exception synchronization mechanism
US6536040B1 (en) * 1999-03-29 2003-03-18 International Business Machines Corporation Cross-platform program, system, and method having a system independent registry for use on operating systems irrespective of a registry equivalent
DE60045202D1 (de) * 1999-03-29 2010-12-23 Hughes Electronics Corp Procede et appareil de traitement conditionnel, stockage et affichage du contenu d'un canal numerique, dans un système de reception de television
US6684260B1 (en) * 1999-05-04 2004-01-27 Hewlett-Packard Development Company, L.P. Maintaining consistency of device driver settings
DE19934787B4 (de) * 1999-07-27 2004-08-05 T-Mobile Deutschland Gmbh Verfahren zur automatischen Anpassung der von einer datenbereitstellenden Einrichtung zu einer datenabrufenden Einrichtung zu übertragenden Daten an die Fähigkeiten dieses Endgerätes
US6654546B1 (en) * 1999-10-05 2003-11-25 Digital Networks North America, Inc Field upgradeable recording device
US6591417B1 (en) * 1999-12-30 2003-07-08 International Business Machines Corporation Method of and system for testing compatibility with an external API upgrade
US6496195B1 (en) * 2000-01-31 2002-12-17 Autodesk, Inc. Method and apparatus for automatically displaying and manipulating identifiers of a mechanical design
US7159041B2 (en) * 2000-03-07 2007-01-02 Microsoft Corporation Method and system for defining and controlling algorithmic elements in a graphics display system
US6810438B1 (en) * 2000-04-05 2004-10-26 Microsoft Corporation Method for enabling value-added feature on hardware devices using a confidential mechanism to access hardware registers in a batch manner
US6701357B1 (en) * 2000-04-19 2004-03-02 Toshiba America Information Systems, Inc. Server appliance
US6891893B2 (en) * 2000-04-21 2005-05-10 Microsoft Corp. Extensible multimedia application program interface and related methods
US7634011B2 (en) 2000-04-21 2009-12-15 Microsoft Corporation Application program interface (API) facilitating decoder control of accelerator resources
US6940912B2 (en) * 2000-04-21 2005-09-06 Microsoft Corporation Dynamically adaptive multimedia application program interface and related methods
US7649943B2 (en) * 2000-04-21 2010-01-19 Microsoft Corporation Interface and related methods facilitating motion compensation in media processing
US6609155B1 (en) * 2000-05-25 2003-08-19 International Business Machines Corporation Method and apparatus for providing relationships in simple network management protocol management information base
US20030105887A1 (en) * 2001-12-03 2003-06-05 Cox Burke David Method and system for integration of software applications
US6831635B2 (en) * 2001-03-01 2004-12-14 Microsoft Corporation Method and system for providing a unified API for both 2D and 3D graphics objects
US6828975B2 (en) * 2001-03-01 2004-12-07 Microsoft Corporation Method and system for managing graphics objects in a graphics display system
US6812923B2 (en) * 2001-03-01 2004-11-02 Microsoft Corporation Method and system for efficiently transferring data objects within a graphics display system
US6874150B2 (en) * 2001-03-01 2005-03-29 Microsoft Corporation Method and system for maintaining connections between surfaces and objects in a graphics display system
GB2373884B8 (en) 2001-03-28 2006-05-04 Nokia Corp Method of configuring electronic devices
US20020174266A1 (en) * 2001-05-18 2002-11-21 Krishna Palem Parameterized application programming interface for reconfigurable computing systems
EP1286270A1 (en) 2001-07-24 2003-02-26 Deutsche Thomson-Brandt Gmbh An integrated circuit having a generic communication interface
EP1280065B1 (en) * 2001-07-24 2005-06-15 Thomson Licensing S.A. An integrated circuit having a generic communication interface
US6819960B1 (en) 2001-08-13 2004-11-16 Rockwell Software Inc. Industrial controller automation interface
US8086664B2 (en) * 2001-09-24 2011-12-27 Siemens Industry, Inc. Method and apparatus for programming programmable controllers and generating configuration data from a centralized server
US7571445B2 (en) * 2001-11-29 2009-08-04 Dell Products L.P. System and method for dynamic device driver support in an open source operating system
US20030145127A1 (en) * 2002-01-03 2003-07-31 Unice W. Kyle Method and computer program product for providing a device driver
US7286823B2 (en) * 2002-02-15 2007-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Mobile multimedia engine
US7620904B1 (en) 2002-06-21 2009-11-17 Autodesk, Inc. On demand identifier and geometry piece association in computer aided design (CAD) environment
US7088360B1 (en) 2002-07-20 2006-08-08 Autodesk, Inc. Simplified identifier generation in a computer aided design (CAD) environment
EP1398694B1 (en) * 2002-07-26 2013-09-11 Canon Kabushiki Kaisha Information processing method
US20040117532A1 (en) * 2002-12-11 2004-06-17 Bennett Steven M. Mechanism for controlling external interrupts in a virtual machine system
KR100524066B1 (ko) * 2003-02-08 2005-10-26 삼성전자주식회사 디바이스 대화창 표시방법 및 장치
DE10320827A1 (de) * 2003-05-08 2004-12-09 Siemens Ag Verfahren zur Softwareanpassung
US7636096B2 (en) * 2004-06-25 2009-12-22 Autodesk, Inc. Automatically ballooning an assembly drawing of a computer aided design
US7721298B2 (en) * 2004-12-03 2010-05-18 Microsoft Corporation Operating system performance
US8442042B2 (en) * 2005-06-09 2013-05-14 Whirlpool Corporation Appliance and a consumable holder with an embedded virtual router
EP2247067B1 (en) * 2005-06-09 2016-05-11 Whirlpool Corporation Appliance with embedded virtual router
US8533253B2 (en) * 2005-06-09 2013-09-10 Whirlpool Corporation Distributed object-oriented appliance control system
CN100472452C (zh) * 2006-06-23 2009-03-25 联想(北京)有限公司 一种虚拟机系统及其硬件设备的切换方法
US8127310B1 (en) * 2007-03-26 2012-02-28 Celio Corporation Method and apparatus for dynamically switching display drivers in mobile device operating system
US8566565B2 (en) * 2008-07-10 2013-10-22 Via Technologies, Inc. Microprocessor with multiple operating modes dynamically configurable by a device driver based on currently running applications
CN101770433B (zh) * 2008-12-30 2012-01-11 意法半导体研发（上海）有限公司 通用驱动方法和通用驱动设备
US20110063309A1 (en) * 2009-09-16 2011-03-17 Nvidia Corporation User interface for co-processing techniques on heterogeneous graphics processing units
US9830889B2 (en) 2009-12-31 2017-11-28 Nvidia Corporation Methods and system for artifically and dynamically limiting the display resolution of an application
CN102385435A (zh) * 2010-08-27 2012-03-21 宏达国际电子股份有限公司 动态调整电子装置运作模式的方法及电子装置
US8813167B2 (en) * 2010-12-30 2014-08-19 Apple Inc. Dynamic device configuration using predicates
CN102867284B (zh) * 2011-07-07 2016-10-26 腾讯科技（深圳）有限公司 一种图形绘制引擎装置及其实现方法
US9442732B2 (en) 2012-03-19 2016-09-13 Via Technologies, Inc. Running state power saving via reduced instructions per clock operation
US9310957B2 (en) * 2013-03-07 2016-04-12 Tencent Technology (Shenzhen) Company Limited Method and device for switching current information providing mode
US10187479B2 (en) 2013-08-26 2019-01-22 Vmware, Inc. Cloud-scale heterogeneous datacenter management infrastructure
US10019260B2 (en) 2013-09-20 2018-07-10 Via Alliance Semiconductor Co., Ltd Fingerprint units comparing stored static fingerprints with dynamically generated fingerprints and reconfiguring processor settings upon a fingerprint match
US9330011B2 (en) 2013-09-20 2016-05-03 Via Alliance Semiconductor Co., Ltd. Microprocessor with integrated NOP slide detector
US9575778B2 (en) 2014-05-20 2017-02-21 Via Alliance Semiconductor Co., Ltd. Dynamically configurable system based on cloud-collaborative experimentation
US9755902B2 (en) 2014-05-20 2017-09-05 Via Alliance Semiconductor Co., Ltd. Dynamic system configuration based on cloud-collaborative experimentation
WO2015198880A1 (ja) * 2014-06-25 2015-12-30 ソニー株式会社 再生装置、再生方法、プログラム、および記録媒体
US9967418B1 (en) 2016-10-31 2018-05-08 Microsoft Technology Licensing, Llc Platform DMFT and interaction with IHV DMFT
US11086800B2 (en) 2019-06-01 2021-08-10 Apple Inc. Execution space agnostic device drivers

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0664536B2 (ja) 1986-01-17 1994-08-22 インタ−ナショナル ビジネス マシ−ンズ コ−ポレ−ション 仮想端末サブシステムの制御方法
US4975829A (en) 1986-09-22 1990-12-04 At&T Bell Laboratories Communication interface protocol
US5175855A (en) * 1987-07-27 1992-12-29 Laboratory Technologies Corporation Method for communicating information between independently loaded, concurrently executing processes
US4755478A (en) 1987-08-13 1988-07-05 International Business Machines Corporation Method of forming metal-strapped polysilicon gate electrode for FET device
US4855936A (en) 1987-09-25 1989-08-08 International Business Machines Corp. Full-screen input/output application program interface
NL8800222A (nl) 1988-01-29 1989-08-16 Philips Nv Werkwijze voor het vervaardigen van een halfgeleiderinrichting waarbij op zelfregistrerende wijze metaalsilicide wordt aangebracht.
EP0419064A3 (en) * 1989-09-22 1992-08-05 International Business Machines Corporation Computer system having apparatus for providing pointing device independent support in an operating environment
CA2010591C (en) 1989-10-20 1999-01-26 Phillip M. Adams Kernels, description tables and device drivers
JPH0727505B2 (ja) 1990-02-12 1995-03-29 インターナショナル・ビジネス・マシーンズ・コーポレイション インターフェース方法及びインターフェース・システム
US5438672A (en) * 1990-12-18 1995-08-01 National Semiconductor Corporation Microcontroller emulator for plural device architecture configured by mode control data and operated under control code transmitted via same switching bus
US5265252A (en) * 1991-03-26 1993-11-23 International Business Machines Corporation Device driver system having generic operating system interface
US5291585A (en) 1991-07-29 1994-03-01 Dell Usa, L.P. Computer system having system feature extension software containing a self-describing feature table for accessing I/O devices according to machine-independent format
US5319751A (en) 1991-12-27 1994-06-07 Intel Corporation Device driver configuration in a computer system
US5305461A (en) 1992-04-03 1994-04-19 International Business Machines Corporation Method of transparently interconnecting message passing systems
EP0584909A1 (en) 1992-08-26 1994-03-02 Sun Microsystems, Inc. Self configuring device system
US5339432A (en) 1992-10-13 1994-08-16 Microsoft Corporation Method and system for providing user control of device driver configuration
US5352631A (en) 1992-12-16 1994-10-04 Motorola, Inc. Method for forming a transistor having silicided regions
US5530858A (en) 1993-04-01 1996-06-25 Intel Corporation Method and apparatus for background processing for PCMCIA card services
US5581766A (en) 1993-05-17 1996-12-03 Compaq Computer Corporation Selectable video driver system
US5564011A (en) 1993-10-05 1996-10-08 International Business Machines Corporation System and method for maintaining file data access in case of dynamic critical sector failure
JP3566975B2 (ja) 1993-10-18 2004-09-15 株式会社日立製作所 計算機操作端末装置の自動操作装置
US5603014A (en) * 1993-12-03 1997-02-11 Intel Corporation Protected mode simulation of a real mode interupt based programming interface in a computer system
US5459869A (en) * 1994-02-17 1995-10-17 Spilo; Michael L. Method for providing protected mode services for device drivers and other resident software

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070058977A (ko) * 2005-12-05 2007-06-11 한국전자통신연구원 홈 네트워크 단말 시스템 소프트웨어의 동적 재구성 장치및 방법

Also Published As

Publication number Publication date
US6289396B1 (en) 2001-09-11
EP0862759A4 (en) 1999-01-27
JP2010033607A (ja) 2010-02-12
DE69636855T2 (de) 2007-10-11
WO1997019402A1 (en) 1997-05-29
ATE352067T1 (de) 2007-02-15
DE69636855D1 (de) 2007-03-08
EP0862759B1 (en) 2007-01-17
KR100421228B1 (ko) 2004-05-31
JP4442732B2 (ja) 2010-03-31
JP2000500601A (ja) 2000-01-18
EP0862759A1 (en) 1998-09-09

Similar Documents

Publication Publication Date Title
KR19990071479A (ko) 동적 프로그램 가능 모드 스위칭 장치 드라이버 구조
KR19990071480A (ko) 에뮬레이션 환경 지원 장치 드라이버 구조
KR19990071476A (ko) 문맥 가상화 장치 드라이버 구조
KR19990071478A (ko) 모듈러 가상화 장치 드라이버 구조
KR19990071475A (ko) 제어기 하드웨어 부 구성요소 식별자를 이용한 적응 장치 드라이버
US5355498A (en) Method and apparatus for booting a computer system without loading a device driver into memory
US5291585A (en) Computer system having system feature extension software containing a self-describing feature table for accessing I/O devices according to machine-independent format
US5701476A (en) Method and apparatus for dynamically loading a driver routine in a computer memory
US6321323B1 (en) System and method for executing platform-independent code on a co-processor
US6959441B2 (en) Intercepting system API calls
US8214849B2 (en) System for loading device-specific code and method thereof
US5964843A (en) System for enhancing device drivers
US6237044B1 (en) Method for object-oriented programming using dynamic interfaces
US5175830A (en) Method for executing overlays in an expanded memory data processing system
US7506131B2 (en) Reformat logic to translate between a virtual address and a compressed physical address
US5504920A (en) Video driver system for communicating device specific primitive commands to multiple video controller types
US8782675B2 (en) Method and system of accessing display window memory
Unified NVIDIA CUDA
WO2002042898A2 (en) Interpretation loop for object oriented processor

Legal Events

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

Payment date: 20061025

Year of fee payment: 4

LAPS Lapse due to unpaid annual fee