21. Windows 10

마이크로소프트 윈도우 10 운영 체제는 선점적 멀티태스킹 클라이언트 운영체제이다. 이는 마이크로프로세서에 대해서는 인텔 IA-32, AMD64, ARM, ARM64 명령어 집합과 아키텍쳐를 구현한다. 이를 알아보자.

21.1. History

1980년대 중반에 마이크로소프트와 IBM은 OS/2 운영 체제 개발을 위해 협업하였으며 이는 단일 프로세서 인텔 80286 시스템의 어셈블리 언어로 쓰여졌다. 윈도우 NT의 네이티브 환경으로 OS/2 API를 쓰려던 팀은 개발 도중 새 32비트 윈도우 API (Win32)를 쓰기로 변경하였으며 이는 윈도우 3.0에서 널리 쓰여진 16비트 API에 기반했다.

21.1.1. Windows XP, Vista, and 7

2001년 10월 윈도우 XP는 윈도우 2000 데스크톱 운영 체제의 업데이트와 윈도우 95/98의 대체재로서 배포되었다. 윈도우 XP의 오래 기다려진 업데이트인 윈도우 비스타는 2007년 1월에 배포되었으나 널리 쓰이진 않았다. 결과는 2009년 10월에 배포된 윈도우 7로 이는 윈도우 서버 2008 R2라는 서버 에디션을 동반했다. 이는 이벤트 추적을 널리 썼다.

21.1.2. Windows 8

2012년 10월에 의 시대가 시작되며 마이크로소프트는 윈도우 8을 배포하였다. 이는 Metro라는 새 UI와 WinRT라는 새 프로그래밍 모델을 포함하였다. 또한 윈도우 스토어에서 지원되는 패키지 시스템으로 애플리케이션을 관리했다. 모바일 세계를 지원하기 위해, 윈도우 8은 최초에는 32비트 ARM ISA로 포팅되었으며 전력 관리와 커널의 하드웨어 확장성 특성에 대한 여러 변화를 겪었다. 마이크로소프트는 최초로 자체 브랜드 모바일 하드웨어를 서피스 브랜드로 배포하였다. 이는 윈도우 RT 운영 체제에서 독점적으로 가동된 태블릿 기기인 서피스 RT를 포함했다. 불운하게도 윈도우 8은 상업적으로 실패했다. 마이크로소프트는 2013년 10월에 이 문제점들을 수정해 윈도우 8.1을 배포하였다.

21.1.3. Windows 10

2015년 7월에 윈도우 10과 그 서버 동반인 윈도우 서버 2016을 2016년 10월에 배포하며 마이크로소프트는 서비스로서의 윈도우(WaaS) 모델로 이전하였다. 윈도우 10은 시작 메뉴와 키보드 지원을 개선하였으며 전체 화면 애플리케이션을 위축시키고 실시간 타일을 쓰기 시작했다. Metro는 Modern으로 명명되었으며 윈도우 데스크톱 브릿지라는 새 메커니즘은 Win32 애플리케이션을 윈도우 스토어에 배포함으로서 새 시스템에서 써진 애플리케이션의 부족을 해소하였다. 윈도우 10은 윈도우 8에서 삭제된 복수 서브시스템의 개념을 피코 프로바이더로 대체하였다. 모바일과 클라우드 컴퓨팅 세계의 늘어나는 경쟁에 대비해, 마이크로소프트는 윈도우 10에서 전력, 성능, 확장성 개선을 수행해 많은 수 기기에서 동작할 수 있도록 하였다. 윈도우 GUI는 윈도우 비스타에서는 데스크톱 윈도우 관리자(DWM)에서 시작했다. 윈도우 DirectX 11, 12는 다이렉트 컴퓨트라고 불리는 GPGPU 메커니즘을 포함하였고 CoreUI라는 새 렌더링 층도 생겼다. 윈도우 XP는 64비트 버전으로 최초에 배포된 윈도우 버전이다. 남은 챕터에서는 윈도우 10의 클라이언트 에디션과 서버 에디션을 구분하지 않도록 하자.

21.2. Design Principles

마이크로소프트의 윈도우 디자인 원리는 보안, 신뢰성, 호환성, 고성능, 확장성, 호환성, 국제적 지원에 기반한다.

21.2.1. Security

윈도우 비스타나 그 이후의 보안 목표는 미국 정부에서 C2 보안 분류(오렌지 북으로부터 주어진)를 따라 윈도우 NT 4.0에서 표준화된 기준 그 이상이 필요해졌다. 윈도우는 전통적으로 자유 재량에 의한 접근 제어에 기반한 보안을 기반으로 했다. 시스템 오브젝트는 접근 제어 목록(ACLs)으로 제어되었으나 이는 보안성이 취약했으므로 윈도우 비스타는 통합성 단계라는 새 메커니즘을 도입했다. 윈도우 10은 이 보안 모델을 특성 기반 접근 제어와 동적 기반 접근 제어의 조합으로 강화하였다. 이런 보안 특성들은 주소 공간 레이아웃 무작위화(ASLR), 데이터 실행 방지(DEP), 제어 흐름 보호(CFG), 임의 코드 방어(ACG) 등을 포함했다. 2001년부터, 인텔과 AMD의 칩은 메모리 페이지가 마킹됨으로써 실행 가능한 명령어 코드를 포함할 수 없도록 하였다. 데이터 실행 방지는 코드로부터 실행되는 공격자 제어 데이터를 막았기 때문에 악성 개발자들은 코드 재사용 공격으로 이동하였다. 이는 프로그램 내 실행 가능 코드가 예상 불가능한 방식으로 재사용될 수 있게 하는 것이다. 어느 보안도 완벽하진 않으며 주소 공간 레이아웃 무작위화도 예외가 아니다. 이는 정보 누수 공격 등에는 효과적이지 못했다. 공격자가 실행 가능한 데이터를 공격으로 가져올 수 없거나 존재하는 코드를 재사용할 수 없다면 프로그램이 실행 가능하고 쓸 수 있는 코드를 할당해 공격자가 이를 채울 수도 있다. 윈도우 10은 이 외에도 30가지 이상의 보안 강화를 하였다. 이는 제어 흐름 강제 기술(CET) 등이 있다. 보안의 다른 중요한 부분은 통합성이다. 윈도우는 몇 개의 디지털 서명을 코드 통합성 특성으로 도입하였다. 이 코드 통합성 모듈은 부트 시점에 가동되어 커널의 모든 모듈의 통합성을 보장한다. 윈도우 10의 상업 버전은 장치 가드라는 새 보안 특성을 적용하였다.

21.2.2. Reliability

윈도우는 첫 10년 동안 운영 체제로서 매우 완숙하였다. 윈도우 경험의 가장 중요한 개선은 부팅 시점에서 메모리 진단을 할 수 있게 한 것이다. 윈도우 7은 폴트 대처 가능한 메모리 힙도 도입하였다. 윈도우에서 동작하는 시스템은 20억 개 수준이므로 윈도우 내 높은 가용성을 얻는 것은 힘들다. 이 난점들에 대처하기 위해 마이크로소프트는 생태계 내 사용자 기기로부터 데이터를 모으는 소통에 주력한다.

21.2.3. Windows and Application Compatibility

윈도우 XP는 윈도우 2000의 업데이트와 윈도우 95/98의 대체재였다. 윈도우 XP처럼, 윈도우 10은 심 엔진이라 불리는 호환성 층을 갖고 있었다. 윈도우 10은 SwitchBranch 메커니즘도 채택하였다. 윈도우 10은 텅킹 층을 통해 16비트 API 호출을 32비트 호출로 변환해 16비트 애플리케이션을 가동할 수 있었다. 본래의 윈도우 부분시스템 모델은 애플리케이션이 마이크로소프트 컴파일러에 의해 호환 가능하게 제작된 한 복수의 운영 체제 개성을 가능케 하였다.이런 더 강한 모델은 커널을 모든 시스템 호출/예외/폴트/스레드 생성과 종료, 프로세스 생성을 외부 2차 드라이버로 전달시킬 수 있도록 하였다. 윈도우 10은 LxCore라는 피코 프로바이더를 리눅스 커널의 재구현으로서 포함하였다. 마지막 호환성 측면으로, 윈도우 8.1 및 그 이후는 Hyper-V for Client도 포함하였다.

21.2.4. Performance

윈도우는 데스크톱 시스템(입출력 성능에 크게 의존하는), 서버 시스템(CPU가 병목인), 큰 멀티스레드 멀티프로세서 환경(락 성능과 캐시 라인 관리가 확장성의 열쇠인)에서 고성능을 내도록 설계되었다. 윈도우 NT는 대칭 멀티프로세싱(SMP)를 위해 설계되었다. 윈도우 XP는 임계 함수의 코드 경로 길이를 줄이고 더 확장성 있는 락 프로토콜 (큐 스핀락과 푸시락 등)을 구현함으로써 성능을 더 개선하였다. 이는 하이퍼 스레딩의 도입으로 인해 필요했다. 이후, 큰 멀티프로세서 서버를 대상으로 한 윈도우 서버 2003은 더 개선된 알고리즘과 프로세서별 데이터 구조, 락, 캐시 등을 제공하고 페이지 컬러링과 NUMA 기기 지원을 지원하면서 배포되었다. 윈도우 7이 개발되었을 때, 컴퓨팅 관련해서도 많은 변화들이 도입되었다. 윈도우 NT의 멀티프로세싱 지원에 대한 구현은 비트마스킹을 사용해 프로세서 모음을 표현하였고 스레드가 어떤 프로세서에 스케쥴링될 수 있는지를 특정하였다. 윈도우 7는 이에 더해 프로세서 그룹의 개념을 추가하였다. 이런 추가 CPU는 CPU와 메모리 스케쥴링에 쓰이는 락에 대해 논쟁을 불러일으켰다. 다른 변화들은 병렬 컴퓨팅의 지원의 중요성이 커짐으로써 이루어졌다. 마지막으로, 전력 고려 요소들은 고성능 컴퓨팅의 설계 결정들을 복잡하게 했다. 이는 특히 배터리가 성능 요구 사항을 저하시킬 수 있는 모바일 시스템과 전력 비용이 빠른 연산 결과의 필요성을 상회하는 클라우드/서버 환경에서 더 그랬다. 작업 기반 병렬화를 지원하기 위해 윈도우 7 이후의 AMD 포트는 사용자 모드 스케쥴링(UMS)의 새 형태를 제공하였다. 초소형 컴퓨터에서도 복수 CPU가 출현한 것은 병렬 컴퓨팅으로의 변화의 일부분일 뿐이다. GPU는 SIMD 아키텍쳐를 이용해 그래픽 알고리즘을 가속하였고 이는 연산 커널 특정도 요구하였다.

21.2.5. Extensibility

확장성은 운영 체제가 컴퓨팅 기술의 발전을 따라갈 수 있는 능력을 뜻한다. 윈도우는 원격 프로시져 호출(RPCs)을 구현하였으며 이는 발전된 로컬 프로시져 호출(ALPC)에 비해 이점이 있었다.

21.2.6. Portability

운영 체제는 한 CPU 아키텍쳐에서 다른 아키텍쳐로 이동할 수 있으면 호환 가능하다고 한다. 운영 체제는 CPU 아키텍쳐뿐만 아니라 CPU 서포트 칩(칩셋)이나 하드웨어 부팅 프로그램들에도 크게 의존한다. 윈도우는 칩셋 의존적 코드를 하드웨어 추상화 층(HAL)으로 불리는 동적 연결 라이브러리(DLL)로 분리시켜 이를 커널에서 로드함으로써 해결하였다. 윈도우 커널은 기반 칩셋 세부 사항보다는 하드웨어 추상화 층 인터페이스에 의존하였다. 시간이 지나면서, 윈도우는 여러 다른 CPU 아키텍쳐로 포팅되었다.

21.2.7. International Support

윈도우는 여러 국가에서 쓰이도록 설계되었다. 이는 다국어 지원(NLS) API를 통해 여러 로케일을 지원했다. 시스템 텍스트 문자열은 시스템이 여러 언어에서 지원될 수 있도록 자원 테이블에 저장된다. 윈도우 비스타의 복수 사용자 인터페이스(MUI)는 여러 로케일이 동시에 쓰일 수 있도록 했다.

21.2.8. Energy Efficiency

에너지 효율성의 증대는 배터리가 랩탑과 인터넷 전용 넷북에서 오래 유지되어 전력과 데이터 센터 냉각의 운영 비용을 크게 감소시켰고 친환경적 계획에도 기여하였다. CPU가 오래 미사용된 시간이 길수록, 더 많은 에너지가 절약된다. 윈도우 7은 시계 인터럽트를 논리적 CPU 0와 현재 동작 중인 CPU들에만 전달하고 소프트웨어 타이머를 더 작은 수의 이벤트로 뭉침으로써 CPU의 비활성 시간을 증대하였다. 이런 기준들일 도움이 되었지만, 배터리 용량이 랩탑보다 현저히 떨어지는 폰과 같은 모바일 시스템에서는 불충분했다. 그래서 윈도우는 CPU가 시계의 소유자가 아니도록 하는 동적 틱을 도입하였다. 더 중요한 것은, 윈도우 스토어를 통해 배포되는 전체 Metro/Modern/UWP 애플리케이션 모델은 프로세스 생애 주기 관리자(PLM)라는 특성을 포함해서 프로세스가 몇 초 이상 비활성되면 모든 스레드를 지연시키도록 하였다. 이는 브로커의 시스템에 대처할 수 있도록 하였다. 데스크톱 활동 중재자(DAM)이라는 새 컴포넌트를 이용해, 윈도우 8 및 그 이후 버전들은 연결 스탠바이라는 새 시스템 상태를 도입하였다. 이는 전원 버튼이 눌리거나 화면이 꺼지면 컴퓨터를 완전히 수면시키지 않고 가상으로 컴퓨터를 중지시킴으로써 문제를 해결했다.

21.2.9. Dynamic Device Support

PC 업계의 역사 초기에, 컴퓨터 설정은 매우 정적이었다. 컴퓨터의 뒤에 시리얼, 프린터, 게임 포트에 새 기기가 부착될 수 있었음에도 불구하고. 기기의 동적 설정에 대한 지원은 윈도우에서 계속해서 발전하고 있다. 윈도우 서버는 동적 CPU/RAM의 추가/대체와 RAM의 제거도 지원한다.

21.3. System Components

윈도우의 아키텍쳐는 여러 권한 레벨에서 동작하는 계층화된 모듈의 시스템이다. 윈도우 10은 가상 신뢰 레벨(VTLs)을 도입하였고 계층화된 권한 시스템은 노멀 월드, VTL 0과 보안 월드, VTL 1의 두 구현을 갖는다. 노멀 월드에서는 커널 모드는 HAL 및 그 확장과 커널 및 그 실행자들이다. 보안 월드에서는 분리된 Trustlet들이 안전한 사용자 모드에서 동작한다. 보안 월드의 최하층은 특수 프로세서 모드에서 동작해 Hyper-V 하이퍼바이저 컴포넌트를 포함하고 하드웨어 가상화를 사용해 월드간 경계를 구성한다. 이런 방식의 이점은 모듈이나 특권 층간 상호 작용이 간단하게 유지되고 분리/보안에 대한 필요성이 특권과 충돌하지 않는다는 것이다.

21.3.1. Hyper-V Hypervisor

하이퍼바이저는 사용자가 Hyper-V 컴포넌트를 활성화하는 즉시 VSM이 활성화된 시스템에서 초기화되는 컴포넌트이다. 이는 하이퍼콜 인터페이스를 제공한다.

21.3.2. Secure Kernel

보안 커널은 고립 사용자 모드 Trustlet 애플리케이션에 대한 커널 모드 환경으로서 동작한다. 시스템 호출 전달 외에도, 보안 커널의 다른 역할은 하드웨어 비밀 요소, 신뢰 플랫폼 모듈, 부트 시 포착되는 코드 통합성 정책에 대한 접근을 제공하는 것이다. 또한, 장치 가드가 활성화되면, 이는 VTL 1의 능력을 이용해 모든 디지털 서명 체크를 보안 커널로 이동시킨다. 추가로, USB 웹캠이나 스마트카드 리더 같은 특수 하드웨어 기기들이 VTL 1에서 사용자 모드로 직접 관리되기 위한 추가 작업이 수행된다. 이를 통해 VTL 1에서 사용 데이터 수집이 노멀 월드의 컴포넌트가 방해받지 않고 가능해진다.

21.3.3. Hardware-Abstraction Layer

하드웨어 추상화 층은 하드웨어 칩셋의 차이를 운영 체제의 상층으로부터 숨기는 소프트웨어 층이다.

21.3.4. Kernel

윈도우의 커널 층은 스레드 스케쥴링, 컨텍스트 스위칭, 저수준 프로세서 동기화, 인터럽트/예외 처리, 시스템 호출 인터페이스를 통한 사용자 모드/커널 모드간 전환을 맡는다.

21.3.4.1. Dispatcher

디스패쳐는 실행자와 부분시스템의 기반을 제공한다. 또한, 인터럽트 요청 수준(IRQLs) 아래에서 하드웨어와 소프트웨어 인터럽트 우선 순위화도 관리한다.

21.3.4.2. Switching Between User-Mode and Kernel-Mode Threads

전통적인 윈도우에서 스레드는 사용자 모드 스레드(UT)와 커널 모드 스레드(KT)의 두 실행 모드로 나뉜다. 윈도우 7은 커널 층의 동작을 사용자 스레드의 사용자 모드 스케쥴링을 가능케 하도록 변경하였다. 윈도우에서 디스패쳐는 커널에서 독립적으로 동작하는 스레드가 아니라 사용자 모드 스레드의 커널 스레드 컴포넌트로 실행된다.

21.3.4.3. Threads

다른 현대 운영 체제들과 마찬가지로 윈도우는 스레드를 스케쥴링 가능한 실행 가능 코드 핵심 단위로 쓰고 프로세스는 스레드의 컨테이너로 쓴다. 스레드에는 8가지 가능한 상태가 존재한다. 선점은 즉각적이며, 지연된 프로시져 호출(DPC)이라는 소프트웨어 인터럽트에 의해 이루어진다. 디스패쳐는 32단계의 우선도를 가지며 각 우선도마다 연결 리스트인 디스패쳐 데이터베이스를 가져 이를 관리한다. 윈도우 서버 2003 이전 디스패쳐 데이터베이스는 전역이었지만 이후에 스레드가 그 이상적 프로세서의 데이터베이스에만 있도록 바뀌었다. 단일 프로세서 시스템에서는 준비된 스레드를 찾아볼 수 없다면 디스패쳐는 대기 스레드라는 특수 스레드를 실행하고 이 역할은 CPU의 초기 수면 상태 중 하나로 전환하는 역할을 한다. 스레드를 이상적 프로세서의 디스패쳐 데이터베이스에만 놓는 것은 국소성 문제를 불러일으키는데, 윈도우 7은 부하 분산 알고리즘을 도입해 이를 해결했으나, 손이 많이 가고 국소성 문제에 지장을 주는 접근법이었다. 윈도우 8 이후부터는 공유 대기 큐를 이용하였다. 윈도우는 15ms마다 틱되는 시간이 존재해 시스템 상태를 조사하고 시간을 업데이트하고 다른 관리를 수행한다. 가변 우선도 스레드가 대기 연산으로부터 깨어나면 디스패쳐는 그 우선도를 높일 수 있다. 뮤텍스, 세마포어, 또 다른 동기화 오브젝트를 대기하는 스레드에 수행될 수 있는 다른 부양들도 존재한다. 추가로, 사용자 활성화된 GUI 윈도우에 연관된 스레드는 깨어날 때마다 그 반응 시간을 최소화하기 위해 최상위의 부양을 부여받는다. 마지막으로, 윈도우 서버 2003은 임계 영역 같은 특수 클래스의 락에 대해서는 락 핸드오프 부양을 추가하였다. 대기에서 깨어나는 스레드가 부양된 우선도를 가졌을 때에는 각 퀀텀마다 그것의 기본 우선도로 되돌려진다.

21.3.4.4. Thread Scheduling

스케쥴링은 스레드가 준비나 대기 상태에 돌입하거나, 스레드가 종료되거나, 애플리케이션이 스레드의 프로세서 친화도를 변경할 때 발생한다. 저우선도 스레드는 자체적으로 디스패쳐를 작동시키는 이벤트를 동작시켜 대기 스레드를 깨우고 준비 상태에 스스로를 놓으면서 자신으로 컨텍스트를 전환시킨다. 윈도우는 강한 리얼타임 운영체제는 아니다. 어떤 스레드라도 특정한 시간 제한 안에서 실행된다고 보장되지 않기 때문이다. DPC나 인터럽트 서비스 루틴(ISRs)에 의해서 무기한으로 대기할 수 있으며 언제나 선점될 수 있다. 전통적으로 윈도우 스케쥴러는 샘플링을 통해 스레드의 CPU 사용량을 측정하였다. 윈도우 비스타로부터, 대기 시간은 펜티엄 프로부터 모든 프로세서에 포함된 하드웨어 타임스탬프 카운터(TSC)를 이용해서도 실행 시간을 추적하였다.

21.3.4.5. Implementation of Synchronization Primitives

윈도우는 여러 디스패쳐 오브젝트를 사용해 디스패칭과 시스템 동기화를 제어한다. 이 오브젝트는 이벤트, 뮤텍스, 세마포어, 스레드, 타이머 등이 있다. 이는 사용자 모드에서 모두 접근 가능하다.

21.3.4.6. Interrupt Request Levels (IRQLs)

하드웨어나 소프트웨어 인터럽트는 모두 우선도가 매겨지고 그 순서로 서비스된다.

21.3.4.7. Software Interrupts: Asynchronous and Deferred Procedure Calls

디스패쳐는 2종류의 소프트웨어 인터럽트를 구현한다: 비동기 프로시져 호출(APCs)과 지연된 프로시져 호출(DPCs). 지연된 프로시져 호출은 인터럽트 처리를 연기하기 위해 쓰인다. 인터럽트 요청 레벨 2는 0, 1보다 높기 때문에, 지연된 프로시져 호출의 실행은 표준 스레드를 현재 프로세서에서 실행되는 것을 가로막고 비동기 프로시져 호출이 입출력의 완료를 호출하는 것도 막는다.

21.3.4.8. Exceptions, Interrupts, and IPIs

커널 디스패쳐는 하드웨어나 소프트웨어로부터 생성되는 예외나 인터럽트에 대한 트랩 처리도 제공한다. 예외는 예외 디스패쳐에 의해 기록된다. 예외가 커널 모드에서 발생하면 예외 디스패쳐는 단순히 예외 핸들러를 위치시키는 루틴이다. 사용자 모드 프로세서에서는 더 복잡해지는데, 윈도우 에러 보고 (WER) 서비스는 모든 프로세서마다 ALPC 에러 포트를 설치하기 때문이다. 이는 Win32 환경 서브시스템 맨 위에 위치한다. 윈도우 에러 보고는 대개 사용자가 그것을 취소하거나 로컬 에러 보고 서버로 보내지 않는 한 정보를 마이크로소프트에 추가 분석을 위해 보낸다. 커널 내 인터럽트 디스패쳐는 디바이스 드라이버나 커널 트랩 핸들러 루틴에 의해 제공되는 인터럽트 서비스 루틴을 호출해 인터럽트를 다룬다. 이는 인터럽트 오브젝트로 표현된다. 다른 프로세서 아키텍쳐는 다른 타입과 인터럽트 수들을 갖고 있다. 커널은 인터럽트-디스패치 테이블을 사용해 각 인터럽트 레벨을 서비스 루틴에 연결시킨다.

21.3.5. Executive

윈도우 실행자는 모든 환경 내 부분시스템들이 사용하는 서비스 집합을 제공한다. 이는 오브젝트 타입을 가진 오브젝트에 기반한 객체 지향 원리로 구성되었다.

21.5.3.1. Object Manager

커널 모드 객체들을 관리하기 위해 윈도우는 사용자 모드 프로그램에 의해 조작되는 일반적인 인터페이스 집합을 사용한다. 이를 조작하는 실행 컴포넌트는 오브젝트 관리자이다. 사용자 모드와 커널 모드 코드 또한 이 오브젝트를 핸들이라는 불명확 값으로 다룰 수 있다. 각 프로세스는 프로세스에 의해 사용되는 오브젝트를 추적하는 엔트리를 담는 핸들 테이블을 포함한다. 핸들 사용과 더해, 커널 모드 코드는 특수 API를 통해서만 얻을 수 있는 참조 포인터를 사용해 오브젝트에 접근할 수 있다. 핸들은 오브젝트 생성이나 존재하는 오브젝트 열기, 중복 핸들 받기, 부모 프로세스부터 핸들 상속을 통해 얻을 수 있다. 오브젝트 핸들을 생성하는 객체는 오브젝트 관리자 뿐이므로, 중앙화된 보안 참조 모니터(SRM)을 통해 보안을 감시한다. 접근 체크가 성공적이면 이에 대한 접근 마스크가 캐싱된다. 오브젝트 관리자는 프로세스가 사용할 수 있는 최대 메모리 양과 같은 할당량도 강제하는데, 이는 메모리를 참조하는 오브젝트로부터 해제하고 프로세스의 할당량을 넘어서는 메모리를 할당하는 것을 거부하는 식으로 이루어진다. 오브젝트는 사용자 모드와 커널 모드의 핸들이나 커널 모드의 포인터로 참조될 수 있으므로 오브젝트 관리자는 각 오브젝트에 대해 2개의 카운터를 추적한다. 오브젝트 핸들과 참조 횟수. 오브젝트 관리자는 윈도우의 내부 이름공간을 유지한다. 이 계층은 각 오브젝트의 해시 버킷을 담는 디렉토리 오브젝트에 의해 유지된다. 프로세스나 스레드는 이름 없이 생성되므로, 이는 프로세스 ID나 스레드 ID같은 별개의 수치 식별자로 참조된다. 각 오브젝트는 오브젝트 타입의 인스턴스이다. parse() 함수는 오브젝트의 구현이 오브젝트 관리자의 기본값 명명을 따르도록 한다. 파일 시스템 볼륨을 표현하는 디바이스 오브젝트도 이를 지원한다.

21.3.5.2. Virtual Memory Manager

가상 주소 공간, 물리 주소 할당, 페이징을 관리하는 실행 컴포넌트는 메모리 관리자(MM)이다. 물리적 메모리에 없는 프로세스에 할당된 데이터 페이지는 이차 저장소의 페이징 파일에 존재하거나 로컬이나 원격 파일 시스탬 내 기본 파일에 직접 매핑된다. IA-32나 ARM같은 32비트 프로세서에선 각 프로세스는 4GB 가상 주소 공간을 가진다. 각 프로세스의 주소공간에서의 커널 코드의 가용성은 중요하며, 다른 많은 웅영체제에서도 찾아볼 수 있다. 윈도우 메모리 관리자는 2단계 과정을 통해 가상 메모리를 할당한다: 예약과 수행. 윈도우는 섹션 오브젝트를 정의해 공유 메모리를 구현한다. 프로세스는 섹션의 메모리를 라 불리는 주소 범위로 매핑한다. 섹션은 여러 방식으로 쓰일 수 있는데, 이 중에서는 접근 금지 페이지(가드 페이지 같은)나 쓰기 시 복사 메커니즘으로도 쓰일 수 있다. 많은 현대 프로세서에서의 가상 주소 전환은 다층 페이지 테이블을 사용한다. IA-32나 AMD64 프로세서에서는 각 프로세서는 512 페이지-디렉토리 엔트리(PDEs)를 포함한 페이지 디렉토리를 갖고, 각 페이지-디렉토리 엔트리는 페이지-테이블 엔트리로 이루어진 페이지-디렉토리 엔트리 테이블을 갖는다. 각 페이지-테이블 엔트리는 물리적 메모리 내 페이지 프레임을 가리킨다. 이는 1GB의 가상 메모리만 다룰 수 있으며 이상으로는 추가 엔트리가 필요하다. IA-32 호환 가능 프로세서에서 가상 주소가 물리적 주소로 전환되는 방식도 이를 따른다. 물리적 주소 내 비트 수는 가상 주소 내 비트 수와 다를 수 있다. 성능을 개선하기 위해, 메모리 관리자는 페이지-디렉토리와 페이지-테이블 엔트리 테이블 페이지를 모든 프로세스의 가상 주소의 같은 연속된 영역으로 매핑한다. 자체 맵을 생성할 때, 페이지 디렉토리 엔트리 중 하나는 그 자체를 가리키는 최상위 페이지 디렉토리 엔트리로서 페이지 테이블 전환에서 순환을 형성한다. 64비트 가상 메모리에 사용되는 추가 페이지 디렉토리 층도 똑같이 동작한다 – 가상 주소 포인터가 더 여러 개의 값으로 쪼개진다는 것만 빼고. 가상 주소를 변환할 때마다 페이지 디렉토리 엔트리나 페이지 테이블 엔트리를 참조함으로써 생기는 오버헤드를 막기 위해, 프로세서는 변환 보기 버퍼(TLB) 하드웨어를 사용한다. 이는 가상 페이지를 페이지 테이블 엔트리로 매핑하는 연관 메모리를 캐시한다. 이는 각 프로세서 내 메모리 관리 단위(MMU)의 일부이다. 페이지-디렉토리 엔트리나 페이지-테이블 엔트리는 물리적 페이지 번호보다 더 많은 것을 갖고 있다. 페이지-디렉토리 엔트리는 페이지-테이블 엔트리처럼 동작하도록 마킹될 수도 있다. 필요할 때 2MB 페이지가 가용해지도록 물리적 메모리를 관리하는 것은 어렵다. 이후에 4KB 페이지로 쪼개져 메모리의 외부 파편화를 야기할 수 있기 때문이다. 윈도우는 각 물리적 페이지에 7가지 상태 중 하나를 부여해 관리한다. 자유, 0화, 수정된, 대기, 불량, 전환, 올바른 상태. 올바른 상태의 페이지는 프로세스의 페이지 테이블에 포함되고, 다른 상태의 페이지는 별도 리스트 각각에 포함된다. 이 목록은 대응 엔트리를 페이지 프레임 번호(PFN) 데이터베이스에 연결하는데 이는 각 물리적 메모리 페이지에 대한 엔트리를 포함한다. 페이지 테이블 엔트리 내 올바름 비트가 0이라면 하드웨어는 다른 모든 비트를 무시하고 메모리 관리자는 자체적으로 그 쓰임새를 정의한다. 윈도우는 작업별, 최소 최근 사용(LRU) 대체 방식을 써 프로세스로부터 적절한 페이지를 가져온다. 페이지의 수명은 메모리에 얼마나 오래 있었는지뿐만 아니라 언제 마지막으로 참조되었는지에 의해서도 결정된다. 프로세스는 그것이 사용할 수 있는 물리적 메모리의 강한계가 정해지면 가용 메모리가 많아도 할 수 있는 작업이 제약될 수 있다. 윈도우는 사용자 모드 프로세스뿐만 아니라 여러 커널 모드 영역에 대해서도 작업 집합을 추적하는데, 이는 파일 캐시나 페이지 가능한 커널 힙이 있다. 메모리 관리자는 즉각적으로 필요한 페이지에서만 폴트를 일으키는 것은 아니다. 스레드를 참조하는 메모리는 국소성을 띄는 경향이 있으므로, 폴트를 일으킬 때 인접하는 페이지에도 폴트가 일어난다. 수행된 메모리를 관리하는 것에 더해, 메모리 관리자는 각 프로세스의 예약된 메모리나 가상 주소 공간을 관리한다. 폴트되는 주소가 초기화되지 않았다면 메모리 관리자는 가상 주소 디스크립터(VADs)의 프로세스 트리에서 주소를 찾아 페이지 테이블 엔트리를 채우고 페이지를 가져온다. 비스타로부터, 윈도우 메모리 관리자는 슈퍼 페치라는 컴포넌트를 포함한다. 이는 시스템 내 모든 페이징을 모니터링하는데 이것이 가져오는 오버헤드는 이것이 가져오는 이점에 의해 상쇄된다. 윈도우 10은 압축 저장소 관리자를 도입해 메모리 관리자에 대한 추가적인 개선을 이루었다. 이는 시스템 프로세스인 메모리 압축 프로세스의 작업 집합 내 압축된 페이지를 생성한다.

21.3.5.3. Process Manager

윈도우 프로세스 매니저는 프로세스, 스레드, 작업을 생성, 삭제, 조사, 관리하는 역할을 한다. 각 프로세스는 하나 이상의 스레드를 포함한다. 프로세스는 모여서 작업 오브젝트를 이룰 수 있다. 그 결과로, 모든 윈도우 스토어 애플리케이션과 모든 UWP 애플리케이션 프로세스는 작업 단위로 동작한다. 윈도우 10은 작업 오브젝트를 사일로라 부른다. 윈도우의 계층화된 아키텍쳐와 환경 서브시스템의 존재로 인해, 프로세스 생성은 더 복잡하다. UWP 현대 윈도우 스토어 애플리케이션(패키지된 애플리케이션)의 실행은 더 복잡하다. 윈도우에선 API를 통해 가상 메모리와 스레드를 조작하고 중복 핸들에 대해 프로세스 핸들을 취해 부분시스템이나 다른 서비스들이 프로세스 생성을 알림받았을 때 새 프로세스의 컨텍스트를 직접적으로 실행하지 않고서도 새 프로세스가 생성된 사실을 기반으로 행동할 수가 있다. 프로세스 리플렉션을 포함하는 여러 특성은 이 능력에 기반한다. 프로세스의 관리자의 디버거 지원은 스레드를 중단하고 재개하고 중단된 채로 스레드를 생성할 수 있는 API를 포함한다. 실행자에서 수행될 때, 스레드는 다른 프로세스에 일시적으로 부착될 수 있다. 이런 스레드 부착은 커널 작업 스레드에 의해 작업 요청이 기원하는 프로세스 컨텍스트를 실행하기 위해 사용된다.

21.3.5.4. Facilities to Client-Server Computing

다른 많은 현대 운영체제와 같이, 윈도우는 계층화된 메커니즘을 주로 쓰는 클라이언트-서버 모델을 사용하며, 이는 많이 쓰이는 기능을 서비스로 놓고 컨텐츠를 파싱하는 코드를 시스템 동작이 가능한 코드로부터 분리시킨다. 이런 윈도우 컴퓨터 내 가장 기본적 서버는 Win32 환경 부분시스템으로 윈도우 95/98 시절로부터 상속된 Win32 API의 운영 체제 개성을 구현하는 서버이다. 윈도우에서 클라이언트-서버 컴퓨팅을 구현할 때 추천되는 패러다임은 원격 프로시져 호출을 사용해 요청을 소통하는 것이다. 근본적인 보안성, 직렬화 서비스, 확장성 때문이다. 원격 프로시져 호출은 복수의 전송 통로를 사용해 시스템간 원격 프로시져 호출을 구현할 수 있다. ALPC는 UNIX 도메인 소켓이나 Mach IPC와 비슷한 메시지 전달 메커니즘이다. 이 시점에서 메시지는 소통 포트를 통해 전달하는데 이는 UDP처럼 응답을 요구하지 않을 수도 있고, 응답을 요구할 수도 있다. ALPC 메시지가 전송되면 2가지 메시지 전송 기법이 선택 가능하다. 소형-중간 크기 메시지에 대해서는 포트의 커널 메시지 큐가 중간 저장소 역할을 하며 메시지는 다른 프로세스로 복제된다. 더 큰 메시지에 대해서는 포트에 대해 공유 메모리 섹션 오브젝트가 생성되어 메시지 큐가 데이터 뷰 특성을 유지해 이를 관리한다. 클라이언트-서버 통신을 구현하는 데는 다른 많은 방법이 있다.

21.3.5.5. I/O Manager

입출력 관리자는 시스템 내 모든 디바이스 드라이버에 대해 역할을 맡으며, 이는 디바이스가 서로, 커널과, 사용자 모드 클라이언트/소비자와 통신할 수 있게 하는 통신 모델을 정의하고 구현한다. 추가적으로 입출력은 항상 파일 오브젝트를 대상으로 한다. 윈도우의 입출력 관리자는 어떤 입출력 흐름이 원 요청을 수정/확장/보강하는 데 쓰일 수 있는지를 결정하는 디바이스 스택을 형성해 디바이스 드라이버가 다른 드라이버에 의해 필터링될 수 있도록 한다. 파일 시스템 드라이버는 특히 중요하므로, 입출력 관리자는 이에 대해서 특수화된 지원을 하며 파일 시스템을 로드하고 관리하는 인터페이스를 구현한다. 디바이스 관리자는 각 디바이스에 대한 리스트로 정렬되어, 드라이버는 드라이버 오브젝트로 나타내어진다. 디바이스 드라이버는 입출력 스택에서는 디바이스 오브젝트로 나타내어진다. 핸들이 디바이스 오브젝트에 의해 열리면 입출력 관리자는 파일 오브젝트를 생성해 디바이스 핸들 대신 파일 핸들을 반환한다. 이는 받는 요청을 입출력 요청 패킷(IRP)이라는 표준 형태로 전환한다. 입출력 요청은 그것이 만들어진 컨텍스트와 다른 컨텍스트에서도 완료될 수 있다. 입출력 스택 모델은 매우 유연한데, 드라이버 스택이 만들어지면서 여러 드라이버는 그 자신을 필터 드라이버로서 스택에 삽입할 수 있다. 이는 각 입출력 동작을 조사하고 수정할 수 있다. 볼륨 스냅샷 (섀도우 카피)나 디스크 암호화 (비트로커)가 그 예다. 윈도우 서버 2003 및 그 이후는 필터 관리자 컴포넌트를 도입해 독립된 파일시스템 필터로 기능하도록 하여 특정 고도로 순서화되는 미니필터를 로드한다. 윈도우의 디바이스 드라이버는 윈도우 드라이버 모델 명세에 의해 쓰여진다. WDM의 풍부함으로 인해, 새 하드웨어 디바이스마다 완전한 WDM 드라이버를 쓰는 것은 매우 많은 일을 필요로 한다. 그래서 포트 드라이버, 미니포트 드라이버 등의 공유 드라이버를 공통된 부분에 대해 차용하기도 한다. 비슷하게, WDM은 클래스/미니클래스 모델도 도입한다. 포트/미니포트와 클래스/미니클래스 모델이 있더라도 커널을 다루는 코드는 많은 양이 쓰여야 한다. 이를 위해서는 커널 모드 드라이버 프레임워크(KMDF), 사용자 모드 드라이버 프레임워크(UMDF) 등이 쓰일 수 있는데 이는 커널의 리플렉터 드라이버를 이용해 사용자 모드를 통해 쓸 수 있다. 이는 윈도우 드라이버 파운데이션 모델을 형성한다. 많은 드라이버는 커널 모드로 동작할 필요가 없으며 사용자 모드에서 드라이버를 개발/배포하기 더 쉽기 때문에 사용자 모드 드라이버 프레임워크가 새 드라이버에 대해서 추천된다.

21.3.5.6. Cache Manager

윈도우는 캐시 관리자를 통해 논리적/가상 파일 단계에서 동작하는 중앙화된 캐싱을 제공한다. 캐시는 가상 주소 제어 블록(VACB)이라는 256KB 블록으로 분할된다. 입출력 관리자가 파일의 사용자 수준 읽기 요청을 바등면 이는 IRP를 그 파일이 위치하는 볼륨의 입출력 스택에 보낸다. 이 복사가 실패하면 페이지 폴트로 인해 메모리 관리자가 입출력 관리자에 캐싱되지 않은 읽기 요청을 보내서 그런 것이다. 캐싱된 파일에 대한 동기적 연산은 가능할 경우 입출력은 빠른 입출력 메커니즘을 통해 다뤄진다. 커널 수준 읽기 연산은 비슷하나, 데이터가 사용자 공간의 버퍼에 복사되는 것이 아니라 캐시로부터 직접 읽어진다는 것이 다르다. 이 때 페이지의 메타데이터 수정을 위해서는 페이지를 잠그는 피닝이 쓰인다. 성능 개선을 위해, 캐시 관리자는 읽기 요청들을 기록하고 이를 통해 미래 요청을 예측한다. 캐시 관리자는 메모리 관리자에 캐시의 내용물을 씻어낼 것을 요청하는 역할도 한다. 빠른 쓰기 프로세스는 캐시 쓰기 스레드가 깨어나 페이지를 이차 저장소로 플러시하기도 전에 모든 가용 캐시 페이지를 채워버릴 수도 있는데 캐시 쓰기는 이를 방지하는 메커니즘도 갖는다. 네트워크 파일 시스템은 이차 저장소와 네트워크 인터페이스간 데이터 이동도 맡아야 하므로 캐시 관리자는 데이터를 직접 이동시킬 수 있는 DMA 인터페이스도 제공한다.

21.3.5.7. Security Reference Monitor

오브젝트 관리자 내 시스템 객체의 관리를 중앙화하는 것은 윈도우가 런타임 접근 검증과 시스템 내 사용자 접근 가능한 모든 객체를 검사하는 균일한 메커니즘을 사용하는 것을 가능케 했다. 스레드가 보호되는 자료 구조에 대한 핸들을 열 때마다, 보안 참조 감시자(SRM)는 유효 보안 토큰과 오브젝트의 보안 디스크립터를 체크한다. 각 프로세스는 연관된 보안 토큰을 가지는데, 이는 사용자의 보안 식별자(SID) 등을 포함한다. 다른 사용자의 보안 식별자를 부여해 다른 사용자를 흉내낼 수도 있다. 이 기능은 클라이언트-서버 모델에서 핵심적인데 서비스가 여러 클라이언트에 대해 서로 다른 보안 식별자로서 기능해야 하기 때문이다. 보안 참조 감시자는 보안 토큰들의 특권을 조작하는 역할도 한다. 프로세스 내 실행되는 코드의 통합성 수준 또한 토큰으로 표현된다. 통합성 수준은 외부 컨텐츠 파싱 공격 소프트웨어 등으로 인해 코드들이 시스템을 침범하기 어렵게 하기 위해 도입되었다. 낮은 통합성 수준에서 동작하는 애플리케이션을 만드는 것은 개발자에게 이 보안 특성을 구현하도록 요구한다. 이를 위해서는 브로커와 파서, 렌더러를 지원하는 클라이언트-서버 모델도 구현해야 한다. 윈도우 8은 토큰 오브젝트의 특별 확장인 애플리케이션 컨테이너도 도입하였다. 이 메커니즘은 보안 모델을 보호 자원에 대한 접근이 사용자나 그룹에 의해 정의되는 재량 시스템에서 각 애플리케이션이 고유의 보안 식별자를 갖고 접근이 애플리케이션 기반으로 이루어지는 필수 시스템으로 전환시켰다. 이 능력들은 윈도우에서 구현된 시스템 브로커에서 쓰임으로써 여러 동작들이 패키지된 애플리케이션처럼 동작하도록 한다. SRM의 마지막 역할은 보안 감시이다. 이는 ISO 표준 공통 기준에 의한 것이다.

21.3.5.8. Plug-and-Play Manager

운영 체제는 플러그-앤-플레이(PnP) 관리자를 이용해 하드웨어 설정의 변화를 인식하고 적용시킨다. 플러그 앤 플레이 관리자는 버스 드라이버로부터 디바이스 목록을 받아, 특수 자원 관리자와 함께, 이는 최적의 자원 할당을 계산해 부여한다. 플러그 앤 플레이 관리자는 제거 쿼리 등 다른 요청도 지원한다. 시스템 내 많은 프로그램은 디바이스의 추가나 제거에 관심이 있으므로, 플러그 앤 플레이 관리자는 알림도 지원한다. 디바이스의 설치는 시스템 내 새 서비스를 시작하는 역할도 한다. 윈도우 7은 서비스 제어 관리자(SCM) 내 서비스 트리거 메커니즘을 도입했는데 이는 시스템 서비스를 관리한다.

21.3.5.9. Power Manager

윈도우는 전력 관리자를 통해 하드웨어의 에너지 효율성을 위한 복잡한 전략들을 구현한다. 수면 모드의 주 이점은 시스템이 이 상태로 (예를 들면 랩탑을 덮은 이후 몇 초 내에도) 빠르게 돌입할 수 있다는 것이다. 동면은 수면보다 훨씬 더 오래 걸리는데 메모리 내 모든 내용이 시스템이 꺼지기 전 이차 저장소로 옮겨져야 하기 때문이다. 윈도우 7에서 전력 관리자는 프로세서 전력 관리자(PPM)을 포함해 코어 파킹, CPU 스로틀링/부스팅 등의 전략을 구현하였다. 윈도우 8은 이에 더해 파워 프레임워크(PoFX)도 도입하였다. 플러그 앤 플레이 관리자와 같이, 전력 관리자는 시스템 나머지에 대해 전력 상태에 대한 알림 기능도 지원한다.

21.3.5.10. Registry

윈도우는 하이브로 불리는 내부 저장소에 많은 설정 정보를 담는다. 이는 레지스트리로 알려져 있는 윈도우 설정 관리자에 의해 관리된다. 시스템 정보, 각 사용자의 선호, 소프트웨어 정보, 보안, 부트 옵션에 대해서 독립적인 하이브가 존재한다. 레지스트리는 각 하이브에 대한 설정 상태를 계층화된 키들의 이름공간으로 표현해 각각이 임의 크기 값을 갖도록 한다. 레지스트리는 범용 데이터베이스의 역할도 한다. 프로그램의 설정은 애플리케이션이나 시스템이 시작할 때마다 바뀌는 것은 아니고 플러그 앤 플레이나 전력 관리자 등에 의한 알람이 갈 때 설정이 바뀐다. 시스템에 중요한 변경이 이루어질 때마다 (예를 들면 운영 체제 업데이트나 드라이버 설치 등) 윈도우는 시스템 복원 지점을 만들어 설정의 오염을 방지한다. 레지스트리 설정의 안정성을 개선하기 위해, 레지스트리는 자가 복구 알고리즘도 여럿 구현하고 있다.

21.3.5.11. Booting

윈도우 PC 부팅은 하드웨어 전력이 켜지고 펌웨어가 ROM으로부터 실행될 때 시작된다. UEFI는 안전 부팅도 제공한다. 펌웨어는 전력이 켜지면 자체 테스트(POST) 진단을 수행해 시스템에 부착된 디바이스를 식별하고 이를 깨끗한 켜진 상태로 초기화하고 ACPI에 사용되는 디스크립션을 만든다. 동면 중이었던 기기에서는 winresume.efi 프로그램이 다음에 로딩된다. 윈도우 10에서는 hvloader.exe나 hvloader.dll을 사용해 하이퍼바이저를 먼저 로딩한다. 커널이 자신을 초기화하면 대기 프로세스, 시스템 프로세스, 안전 시스템 프로세스 등 여러 프로세스를 생성한다. 첫 사용자 모드 프로세스는 역시 커널에 의해 만들어지는데 세션 관리자 부분시스템(SMSS)이다. 윈도우 XP로부터, 시스템은 이전의 부팅에 기반한 이차 저장소로부터 파일을 미리 페칭함으로써 부트 과정을 단축시킨다. 윈도우 8은 특히 RAM과 코어가 제한된 모바일 시스템에서의 부팅 시간 개선을 위해 혼성 부팅을 도입하였다.

21.4. Terminal Services and Fast User Switching

윈도우는 GUI 기반 콘솔을 제공해 사용자와 키보드, 마우스, 디스플레이로 상호작용한다. 윈도우 7은 멀티터치 하드웨어에 대한 지원을 추가하였다. 이후에 마이크로소프트는 HoloLens 증강 현실도 추가하였다. PC는 최초에는 단일 사용자 기기였으나 이후에는 각 사용자가 세션을 통해 각각의 GUI을 사용하게 하였다. 한 PC의 사용자는 새 세션을 만들거나 다른 컴퓨터의 세션에 원격 데스크톱으로 접속할 수 있다. 많은 회사는 데이터 센터로 유지되는 협업 시스템을 사용해 이 기기들을 터미널 서버로 위임함으로써 사용자가 그들의 PC 각각의 자원보다는 회사의 자원을 접근하는 사용자 세션을 가동시킨다. 이는 얇은 클라이언트 컴퓨팅의 예이다.

21.5. File System

윈도우의 네이티브 파일 시스템은 NTFS이다. 이는 ACL을 통해 각 파일에 대한 접근을 제어하고 각 파일이나 전체 볼륨에 대한 암묵적 암호화를 지원한다.

21.5.1. NTFS Internal Layout

NTFS의 기본적 객체는 볼륨이다. 이는 저장소 기기의 각 섹터를 다루진 않지만 저장소 할당의 단위로 클러스터를 사용한다. NTFS는 저장소 주소로 논리적 클러스터 번호(LCNs)를 사용한다. NTFS 내 파일은 UNIX처럼 단순한 파일 스트림은 아니고 타입이 주어진 특성들로 이뤄진 구조화된 오브젝트이다. 대다수의 전통적 데이터 파일은 파일의 모든 데이터를 담는 이름 없는 데이터 특성을 가진다. NTFS 내 모든 파일은 마스터 파일 테이블(MFT)로 불리는 특수 파일에 기록된 하나 이상의 배열로 표현된다. 파일이 기록에 대해 오버플로우될 경우 이는 기본 파일 기록이라는 포인터들로 표현된다. NTFS 볼륨 내 각 파일은 파일 참조라는 고유의 식별자를 가진다.

21.5.1.1. NTFS B+ Tree

NTFS 이름공간은 UNIX처럼 계층화된 디렉토리로 이루어져 있으며 B+ 트리라는 자료 구조를 사용한다. 최상층은 인덱스 루트이다.

21.5.1.2. NTFS Metadata

NTFS 볼륨의 메타데이터는 전부 파일에 저장되어 있다. 이는 로그 파일, 볼륨 파일, 특성 정의 테이블, 루트 디렉토리, 비트맵 파일, 부트 파일, 불량 클러스터 파일 등이 있다. 실제 파일 내 NTFS 메타데이터를 전부 보존하는 것은 유용하다.

21.5.2. Recovery

많은 단순한 파일 시스템에서 잘못된 시점에서의 전력 실패는 파일 시스템 자료 구조를 심각히 망가뜨려 전체 볼륨을 뒤섞을 수 있다. NTFS는 파일 시스템 강건함에 대해 모든 파일 시스템 자료 구조 업데이트가 트랜잭션에서만 수행되도록 한다. 크래시 이후 시스템은 수행된 트랜잭션 연산을 재개하고 크래시 이전에 성공적으로 수행되지 못한 트랜잭션 연산을 되돌림으로써 로그 기록을 수행해 파일 시스템 자료구조를 일관적인 상태로 복원한다. 이 방식은 모든 사용자 파일 컨텐츠가 크래시 이후에 올바른 상태가 되도록 보장해 주지는 못한다. 로그는 볼륨의 시작 부분에 있는 세 번째 메타데이터 파일에 저장된다. 이 기능은 로그-파일 서비스에 의해 제공된다.

21.5.3. Security

NTFS 볼륨의 보안은 윈도우 오브젝트 모델로부터 파생된다. 일반적인 동작에서, NTFS는 파일 경로명 내 디렉토리 순회에 대한 허가를 강제하지는 못한다. POSIX 호환성을 위해서 이 체크는 활성화될 수 있다.

21.5.4. Compression

NTFS는 데이터 압축을 파일 각각에 대해 또는 디렉토리 내 모든 데이터 파일에 대해 압축 단위로 압축함으로써 수행할 수 있다. 희박한 파일에 대해서는 NTFS는 다른 기법을 사용한다.

21.5.5. Mount Points, Symbolic Links, and Hard Links

마운트 지점은 윈도우 2000에 도입된 NTFS 내 디렉토리에 대한 심볼릭 링크이다. 윈도우 비스타는 UNIX에서 찾아볼 수 있는 것과 비슷한 더 일반적인 심볼릭 링크를 지원한다. NTFS는 하드 링크도 지원한다.

21.5.6. Change Journal

NTFS는 파일 시스템에 이뤄진 모든 변경을 표현하는 저널을 유지한다.

21.5.7. Volume Shadow Copies

윈도우는 볼륨을 알려진 상태로 가져오고 그에 대한 그림자 복제를 만들 수 있는 능력을 구현한다. 이는 볼륨에 대한 일관적인 뷰를 백업하는 데 쓰인다. 윈도우의 서버 버전은 그림자 복제를 사용해 파일 서버에 저장된 파일의 옛 버전을 효과적으로 유지한다.

21.6. Networking

윈도우는 피어-피어와 클라이언트-서버 네트워킹을 모두 지원한다.

21.6.1. Network Interfaces

윈도우의 네트워킹은 2가지 네트워킹 인터페이스로 묘사된다: 네트워크 디바이스 인터페이스 명세(NDIS)와 전송 디바이스 인터페이스(TDI).

21.6.2. Protocols

윈도우는 전송 프로토콜을 드라이버로 구현한다.

21.6.2.1. Server Message Block

서버 메시지 블록(SMB) 프로토콜은 MS-DOS 3.1에 처음 도입되었다. 범용 인터넷 파일 시스템(CIFS)로 배포된 SMB 프로토콜 버전은 많은 운영 체제에서 쓰인다.

21.6.2.2. Transmission Control Protocol/Internet Protocol

인터넷에서 쓰이는 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 세트는 네트워킹 기반 시설의 표준이 되었다. 윈도우는 네트워크 통신을 위한 프로그램들에서 쓰일 수 있는 TCP 포트를 제한하는 소프트웨어 방화벽을 제공한다.

21.6.2.3. Point-to-Point Tunneling Protocol

점대점 터널링 프로토콜(PPTP)는 윈도우에서 윈도우 서버 기기에서 가동하는 원격 접근 서버 모듈과 인터넷으로 연결된 다른 클라이언트 시스템 간 통신을 위해 제공하는 프로토콜이다. 이 원격 접근 서버는 가상 전용 네트워크(VPNs)도 지원한다.

21.6.2.4. HTTP Protocol

HTTP 프로토콜은 월드 와이드 웹을 사용해 정보를 get/put 한다.

21.6.2.5. Web-Distributed Authoring and Versioning Protocol

웹 분산 저작 및 버저닝(WebDAV)는 네트워크를 통한 협업 저작을 위한 HTTP 기반 프로토콜이다.

21.6.2.6. Named Pipes

기명 파이프는 연결 지향 메세지 메커니즘이다. 파이프 명의 형식은 균일 명명 관습(UNC)를 따른다.

21.6.2.7. Remote Procedure Calls

원격 프로시져 호출(RPCs)은 한 기기에서의 애플리케이션이 다른 기기의 코드에 대한 프로시져 호출을 가능케 하는 클라이언트-서버 메커니즘이다. 이는 마셜링을 통해 인자들을 패킹한다. 윈도우에서 이는 마이크로소프트 인터페이스 정의 언어로 컴파일된다. 윈도우 원격 프로시져 호출 메커니즘은 원격 프로시져 호출 메시지에 대해 널리 쓰이는 분산형 컴퓨팅 환경 표준을 따름으로써 이를 쓰는 프로그램의 호환성이 높도록 하였다.

21.6.2.8. Component Object Model

컴포넌트 오브젝트 모델(COM)은 윈도우를 위해 개발된 프로세스간 통신 메커니즘이다. 이는 마이크로소프트의 오브젝트 연결 및 삽입(OLE)에 쓰인다. 분산형 시스템을 위한 확장으로 DCOM이 있다.

21.6.3. Redirectors and Servers

윈도우에서 리디렉터는 입출력 요청을 원격 시스템 서버로 전달하는 클라이언트 쪽 오브젝트이다. 이는 복수 UNC 제공자(UNP)라는 드라이버를 호출한다. 호환성을 위해, 리디렉터나 서버는 네트워크 통신을 위해 TDI API를 쓴다.

21.6.3.1. Distributed File System

윈도우는 네트워크 관리자에게 파일을 단일 분산 이름공간을 사용하면서 복수 서버로부터 제공받을 수 있는 분산형 파일 시스템(DFS) 프로토콜을 지원한다.

21.6.3.2. Folder Redirection and Client-Side Caching

컴퓨터를 빈번하게 바꾸는 사용자의 PC 경험을 개선하기 위해, 윈도우는 관리자들에게 로밍 프로필을 제공해 사용자의 선호와 다른 설정을 서버에 저장할 수 있도록 했다. 이 때 폴더 리디렉션이 사용자의 문서나 다른 파일을 서버로부터 불러올 수 있다. 사용자가 오프라인에서도 이를 접근하기 위해 윈도우는 클라이언트 단 캐싱(CSC)을 사용한다.

21.6.4. Domains

그룹 내 전역 접근 권한을 관리하기 위해 윈도우는 도메인을 사용한다. 구체적으로, 윈도우 도메인은 공통된 보안 정책과 사용자 데이터베이스를 공유하는 윈도우 워크스테이션과 서버의 그룹이다.

21.6.5. Active Directory

활성 디렉토리경량 디렉토리 접근 프로토콜(LDAP) 서비스에 대한 윈도우의 구현이다. 이는 윈도우 그룹 정책 등을 제공한다.

21.7. Programmer Interface

Win32 API는 윈도우 기능에 대한 기본적 인터페이스이다.

21.7.1. Access to Kernel Objects

윈도우 커널은 애플리케이션 프로그램이 사용할 수 있는 여러 서비스를 제공한다.

21.7.2. Sharing Objects Between Processes

윈도우는 프로세스간 오브젝트 공유를 하는 데 있어 3가지 방법을 쓴다. 첫 번째 방법은 자식 프로세스가 오브젝트 핸들을 상속하도록 하는 것이다. 자식 프로세스가 어떤 핸들을 공유하는지 알면 부모와 자식은 공유 오브젝트를 통해 프로세스간 통신을 할 수 있다. 두 번째 방법은 오브젝트가 만들어질 때 이름을 부여하고 다른 프로세스에서 이 이름을 여는 것이다. 이는 관계 없는 프로세스들이 손쉽게 오브젝트를 공유할 수 있도록 한다. 세 번째 방법은 DuplicateHandle() 함수를 쓰는 것이다.

21.7.3. Process Management

윈도우에서 프로세스는 애플리케이션의 로딩된 인스턴스고 스레드는 커널 디스패쳐에 의해 스케쥴될 수 있는 코드의 실행 단위이다.

21.7.3.1. Scheduling Rule

Win32 환경의 우선도는 네이티브 커널(NT) 스케쥴링 모델을 따르나 6가지의 우선도 클래스만 쓴다. 프로세스는 대개 NORMAL_PRIORITY_CLASS 멤버이나, 부모가 IDLE_PRIORITY_CLASS이거나 CreateProcess 시에 다른 클래스가 특정되었을 시는 아니다. 사용자가 상호작용하는 프로세스와 부하를 전환할 때 시스템은 적절한 스레드를 스케쥴링해 좋은 반응성을 이끌어내야 한다.

21.7.3.2. Thread Priorities

스레드는 클래스에 의해 초기 우선도를 판정받으며 이는 SetThreadPriority()로 바뀔 수 있다. THREAD_PRIORITY_IDLE, THREAD_TIME_CRITICAL로 바뀔 수도 있으며 커널이 우선도를 동적으로 조절할 수도 있다.

21.7.3.3. Thread Suspend and Resume

스레드는 SuspendThread() 함수를 통해 또는 생성 시에 중지된 상태로 만들어질 수 있다.

21.7.3.4. Thread Synchronization

스레드에 의해 공유되는 오브젝트에 대한 동시 접근을 동기화하기 위해 커널은 세마포어나 뮤텍스 같은 동기화 오브젝트를 제공한다. 다른 방법으로는 Win32 임계 영역 오브젝트 등이 있다. 임계 영역 진입 전 프로세스 내 스레드는 반드시 InitializeCriticalSection()을 호출해야 한다. 뮤텍스 대신 사용자 모드 읽기-쓰기 락을 쓰는 프로그램에 대해서는 Win32는 얇은 읽기-쓰기 (SRW) 을 제공한다. Win32 API는 조건 변수도 제공한다.

21.7.3.5. Thread Pool

Win32 스레드 풀은 사용자 모드 프로그램에 SubmitThreadpoolWork(), RegisterWaitForSingleObject(), CreateThreadpoolTimer(), WaitForThreadpoolTimerCallbacks(), BindIoCompletionCallback() 등을 제공한다. 스레드 풀 사용의 목적은 성능 개선과 메모리 사용량 감소이다.

21.7.3.6. Fibers

파이버는 사용자 정의 스케쥴링 알고리즘에 따라 스케쥴링되는 사용자 모드 코드이다. 시스템은 CreateFiber()나 ConvertThreadToFiber()로 파이버를 만든다. 이는 호환성 면에서 추천되지는 않으며, Win32 사용자 모드 스레드는 스레드 환경 블록(TEB)을 가져 Win32 API에 사용되는 여러 스레드별 필드를 포함한다.

21.7.3.7. User-Mode Scheduling UMS and ConcRT

윈도우 7의 새 메커니즘인 사용자 모드 스케쥴링(UMS)는 파이버의 여러 한계점에 대처하였다. UMS는 각 윈도우 스레드가 사실은 사용자 스레드와 커널 스레드의 2개 스레드라는 것을 인식함으로써 대체 모델을 제공하였다. 사용자 스레드가 커널로 진입하면 그 커널 스레드는 블락될 수 있다. 파이버와 다르게 UMS는 프로그래머에 의해 직접적으로 쓰여지도록 한 것은 아니다.

21.7.3.8. Winsock

Winsock은 윈도우 소켓 API이다. 이는 윈도우 오픈 시스템 아키텍쳐(WOSA) 모델을 따르는데 이것은 애플리케이션과 네트워킹 프로토콜 간 표준 서비스 제공자 인터페이스를 제공한다.

21.7.4. IPC Using Windows Messaging

Win32 애플리케이션은 프로세스간 통신을 여러 방식으로 다룬다. 로컬 원격 프로시져 호출, 기명 파이프, 공유 커널 오브젝트, 동기화 오브젝트, 메시징 기능 등이 있다. 메시지 전송에 더해, 스레드는 메시지에 데이터를 추가해 전송할 수도 있다. 모든 Win32 GUI 스레드는 메시지를 받을 수 있는 입력 큐를 갖고 있다.

21.7.5. Memory Management

Win32 API는 애플리케이션에 메모리를 사용하기 위한 여러 방식을 제공한다.

21.7.5.1. Virtual Memory

VirtualAlloc()을 호출하는 애플리케이션은 가상 메모리를 예약하거나 수행하고 VirtualFree()를 통해 이를 해제하거나 수행 취소한다.

21.7.5.2. Memory-Mapped Files

애플리케이션이 메모리를 쓰는 다른 방법은 파일을 주소공간으로 메모리 매핑하는 것이다. 프로세스는 CreateFileMapping()을 통해 이를 수행한다.

21.7.5.3. Heaps

힙은 애플리케이션이 메모리를 사용하는 세 번째 방법이다. Win32 프로세스는 기본값 힙으로 초기화된다. Win32는 프로세스가 전용 힙을 할당/관리할 수 있는 여러 함수를 제공한다. 윈도우 XP에서는 저 파편화 힙을 제공해 파편화를 크게 줄였다.

21.7.5.4. Thread-Local Storage

애플리케이션이 메모리를 사용하는 네 번째 방법은 스레드 로컬 저장소(TLS) 메커니즘이다. 이는 스레드 로컬 저장소를 만드는 정적/동적 메소드를 모두 제공한다.

21.7.5.5. AWE Memory

애플리케이션이 메모리를 사용하는 다섯 번째 방법은 주소 윈도윙 확장(AWE) 기능을 ㅌ통해서이다.

21.8. Summary

  • 마이크로소프트는 윈도우를 확장 가능한, 호환성 있는 운영 체제로 설계하였다. 이는 새 기술과 하드웨어의 이점을 살릴 수 있다.
  • 윈도우는 복수의 운영 체제 환경과 대칭적 멀티프로세싱을 지원한다. 이는 32비트/64비트 프로세서와 NUMA 컴퓨터를 포함한다.
  • 커널 오브젝트를 사용해 기본 서비스와 클라이언트-서버 컴퓨팅 지원을 제공하는 것은 윈도우에 넓은 범위의 애플리케이션 환경을 지원하는 것을 가능케 한다.
  • 윈도우는 가상 메모리, 통합된 캐싱, 선점 스케쥴링을 제공한다.
  • 사용자 데이터를 보호하고 프로그램 통합성을 보장하기 위해, 윈도우는 정교한 보안 메커니즘과 보안 취약점 완화와 하드웨어 가상화를 이용한다.
  • 윈도우는 폭넓은 컴퓨터들에서 쓰여서 사용자는 하드웨어를 선택하고 업그레이드해서 그들이 사용하는 애플리케이션을 바꾸지 않고서도 예산과 성능 요구 사항을 만족시킬 수 있다.
  • 국제화 특성들을 포함함으로써, 윈도우는 여러 나라나 언어에서 사용될 수 있다.
  • 윈도우는 성능과 확장성을 위해 복잡한 스케쥴링과 메모리 관리 알고리즘을 가진다.
  • 윈도우의 최근 버전은 전력 관리, 빠른 수면/각성 특성, 여러 영역에 대한 감소한 자원 사용을 추가해 폰이나 태블릿 같은 모바일 환경에서 더 유용하도록 하였다.
  • 윈도우 볼륨 관리자나 NTFS 파일 시스템은 데스크톱이나 서버 시스템에 대해 복잡한 특성들을 제공한다.
  • Win32 API 프로그래밍 환경은 특성이 많고 광범위하며 프로그래머들이 그 프로그램 내에서 윈도우 특성들을 전부 사용할 수 있도록 한다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중