기본 Windows 개념 및 용어

---

이 장에서는 Windows의 기본 개념을 소개하며 이러한 개념은 Windows 내부의 이해를 용이하게 하여 Windows의 기본 개념과 몇 가지 용어를 미리 이해하도록 합니다.

윈도우 API

Windows 응용 프로그래밍 인터페이스(응용 프로그래밍 인터페이스, API)는 Windows 운영 체제 제품군의 사용자 모드 시스템 프로그래밍 인터페이스입니다. 64비트 Windows가 출시되기 전에는 32비트 Windows용 프로그래밍 인터페이스를 Win32 API라고 했습니다. 이는 주로 이전 16비트 Windows API와 차별화하기 위한 것입니다. 대부분의 Windows API는 현재 32비트 및 64비트 Windows 프로그래밍 인터페이스를 모두 참조하는 Win32 API라고 합니다.

윈도우 API 스타일

Windows API는 초기에 C 스타일 함수만 포함했습니다. 현재 수천 개의 이러한 기능을 개발자가 사용할 수 있습니다. 윈도우가 탄생하던 날 C언어는 많은 언어의 최하위 공통분모라고 할 수 있고(즉, C언어는 다른 언어를 통해서도 접근이 가능하다), C언어는 운영체제 서비스를 노출할 정도로 낮기 때문에 가장 자연스러운 선택이었다. 그러나 C 언어의 단점은 순전히 함수 수가 많고 명명 일관성과 논리적 그룹화(C++의 네임스페이스와 같은)가 부족하다는 것입니다. 이러한 어려움의 한 가지 결과는 일부 최신 API가 COM(구성 요소 개체 모델)이라는 다른 API 메커니즘을 사용한다는 것입니다.

COM은 원래 Microsoft Office 응용 프로그램이 문서 간에 통신하고 데이터를 교환할 수 있도록 개발되었습니다(예: Excel 표를 Word 문서 또는 PowerPoint 프레젠테이션에 포함). 이 기능은 개체 연결 및 포함(OLE)이라고도 합니다. OLE는 원래 DDE(동적 데이터 교환)라는 오래된 Windows 메시징 메커니즘을 사용하여 구현되었습니다. DDE에는 몇 가지 본질적인 한계가 있었기 때문에 COM이라는 새로운 통신 방법이 개발되었습니다. 사실 COM은 원래 OLE2라고 불렸으며 1993년경에 공식적으로 출시되었습니다.

COM은 두 가지 기본 원칙을 기반으로 합니다.

1. 첫 번째 원칙: 클라이언트는 인터페이스를 통해 개체(COM 서버 개체라고도 함)와 통신할 수 있습니다. 인터페이스는 가상 테이블 스케줄링 메커니즘에 따라 그룹화된 논리적으로 상호 관련된 일련의 메서드로 구성된 잘 정의된 "계약"입니다. 이는 C++ 컴파일러가 가상 테이블 스케줄링을 구현하는 일반적인 방법이기도 합니다. 이것은 바이너리 호환성을 허용하고, 컴파일러 맹글링 문제를 피하고, C, C++, 비주얼 베이직, .net, 델파이 등과 같은 많은 언어(및 컴파일러)에서 이러한 방법을 조사합니다.
2. 두 번째 원칙: 클라이언트에 정적으로 연결하지 않고 구성 요소 구현을 동적으로 로드할 수 있습니다.

COM 서버라는 용어는 일반적으로 COM 클래스를 구현하는 데 사용되는 동적 연결 라이브러리(Dynamic Link Library, DLL) 또는 실행 파일(executable, EXE)을 가리킵니다. COM은 또한 보안, 마샬링, 스레딩 모델 등과 관련된 중요한 기능을 제공합니다. COM에 대한 자세한 소개는 여기에서 다루지 않을 것이며 관심이 있는 경우 Don Box가 쓴 Essential COM 책을 참조할 수 있습니다.

윈도우 런타임

Windows 8은 Windows Runtime(단순히 WinRT라고도 하지만 Windows 운영 체제의 ARM 기반 버전인 Windows RT와 같지 않음)이라는 새로운 API 및 지원 런타임을 추가합니다. Windows 런타임은 플랫폼 서비스로 구성되며 주로 Windows 앱(이전에는 메트로 앱, 최신 앱, 몰입형 앱 및 Windows 스토어 앱이라고 함)의 애플리케이션 개발자를 대상으로 합니다. Windows 앱은 소형 IoT 장치에서 휴대폰, 태블릿, 랩톱, 데스크톱, 심지어 Xbox One 및 HoloLens와 같은 장치까지 다양한 유형과 크기의 장치에서 실행할 수 있습니다.

API 관점에서 WinRT는 기본 COM 인프라에 다양한 확장이 추가된 COM 위에 구축됩니다. 예를 들어 WinRT는 형식 라이브러리라고 하는 COM의 유사한 개념을 확장하기 위해 전체 형식 메타데이터(.NET 메타데이터 형식을 기반으로 WINMD 파일에 저장됨)를 사용할 수 있습니다. API 디자인 관점에서 볼 때 네임스페이스, 계층 구조, 일관된 이름 지정 및 프로그래밍 패턴을 제공하는 기존 Windows API 기능보다 더 제한적입니다.

Windows 앱은 일반 Windows 응용 프로그램(현재 Windows 데스크톱 응용 프로그램 또는 클래식 Windows 응용 프로그램이라고 함)과 매우 다른 새로운 규칙 집합을 준수합니다.

다양한 API와 애플리케이션 간의 관계는 그리 간단하지 않습니다. 데스크톱 응용 프로그램은 WinRT API의 하위 집합을 사용할 수 있고 Windows 응용 프로그램은 Win32 및 COM API의 하위 집합을 사용할 수 있습니다. 이 부분에 대한 자세한 내용은 MSDN 설명서를 참조하십시오.WinRT API는 새로운 "네이티브" API가 아니라 기존 Windows API를 사용하는 .NET과 다소 유사합니다.

.넷 프레임 워크

.NET Framework는 Windows의 일부입니다. 다음 표에는 Windows에 기본적으로 설치되는 .NET Framework 버전이 나와 있습니다. 최신 버전의 .NET Framework는 이전 버전의 Windows 운영 체제에도 설치할 수 있습니다.

윈도우 버전	.NET 프레임워크 버전
윈도우 8	4.5
윈도우 8.1	4.5.1
윈도우 10	4.6
윈도우 10 버전 1511	4.6.1
윈도우 10 버전 1607	4.6.2

.NET Framework는 두 가지 주요 구성 요소로 구성됩니다.

1. 공용 언어 런타임(CLR). 이것은 .NET의 런타임 엔진으로, CIL(Common Intermediate Language) 명령을 기본 하드웨어 CPU 시스템 음성, 가비지 수집기, 유형 확인, 코드 액세스 보안 등으로 변환하는 Just-In-Time(just-in-time, JIT) 컴파일러를 포함합니다. Windows API에서 제공하는 기능을 사용하는 COM DLL(프로세스 내 서버)로 구현됩니다.
2. .NET Framework 클래스 라이브러리(프레임워크 클래스 라이브러리, FCL). 이는 사용자 인터페이스 서비스, 네트워킹, 데이터베이스 액세스 등과 같이 클라이언트 및 서버 응용 프로그램에 일반적으로 필요할 수 있는 기능을 구현하는 데 사용되는 대규모 유형 모음입니다.

새로운 고급 프로그래밍 언어(C#, Visual Basic, F#) 및 지원 도구와 함께 위의 기능을 제공함으로써 .NET Framework는 개발자가 대상 응용 프로그램의 개발 판매량을 늘리고 보안 및 안정성을 향상시킬 수 있습니다. .NET Framework와 Windows 운영 체제 간의 직접적인 관계는 아래 그림에 나와 있습니다.

서비스, ​​기능 및 루틴

Windows 사용자 문서 및 프로그래밍 문서에서 많은 용어는 상황에 따라 다른 의미를 갖습니다. 예를 들어 "서비스"라는 단어는 운영 체제, 장치 드라이버 또는 서버 프로세스의 호출 가능한 루틴을 나타낼 수 있습니다. 다양한 용어의 의미는 다음과 같습니다.

• 윈도우 API 기능. 노출되고 호출 가능한 Windows API의 서브루틴입니다. CreateProcess, CreateFile, GetMessage 등.
• 기본 시스템 서비스(또는 시스템 호출). 운영 체제에 노출되지 않지만 사용자 모드에서 호출할 수 있는 저수준 서비스. 예: Windows의 CreateProcess 함수는 내부 시스템 서비스인 NtCreateUserProcess를 호출하여 새 프로세스를 생성합니다.
• 커널 지원 함수(또는 루틴). Windows 운영 체제 내에서 커널 모드에서만 호출할 수 있는 서브루틴. 예: 드라이버는 ExAllocatePoolWithTag 루틴을 호출하여 Windows 시스템 힙에서 메모리를 할당할 수 있습니다.
• 윈도우 서비스. Windows 서비스 제어 관리자가 시작한 프로세스입니다. 예를 들어 사용자 모드에서 실행되는 작업 스케줄러 서비스는 schtasks 명령도 지원할 수 있습니다.
• 동적 링크 라이브러리(DLL). 호출 가능한 서브루틴은 서브루틴을 사용하는 애플리케이션에서 동적으로 로드할 수 있는 이진 파일에 연결됩니다. 예를 들어 Msvcrt.dll 및 Kernel32.dll(Windows API 하위 시스템 라이브러리 중 하나)입니다. Windows 사용자 모드 구성 요소 및 응용 프로그램은 DLL을 많이 사용합니다. 정적 라이브러리에 비해 DLL의 장점은 응용 프로그램이 DLL을 공유할 수 있고 Windows는 여러 응용 프로그램에서 사용하는 동일한 DLL의 복사본 하나만 메모리에 존재하도록 보장한다는 것입니다.

프로세스

프로그램과 프로세스는 표면적으로는 유사해 보이지만 근본적인 차이점이 있습니다. 프로그램은 명령의 정적 시퀀스인 반면 프로세스는 프로그램 인스턴스를 실행하는 데 사용되는 리소스 집합을 포함하는 컨테이너입니다. 가장 높은 수준의 추상화에서 Windows 프로세스는 다음 요소를 포함할 수 있습니다.

1. 개인 가상 주소 공간. 프로세스에 사용 가능한 가상 메모리 주소 범위.
2. 실행 가능한 프로그램. 프로세스의 가상 주소 공간에 매핑될 초기 코드 및 데이터를 정의합니다.
3. 열려 있는 핸들 목록입니다. 핸들은 다양한 시스템 리소스에 매핑됩니다. 예를 들면 프로세스의 모든 스레드에서 액세스할 수 있는 세마포어, 동기화 개체 및 파일이 있습니다.
4. 보안 컨텍스트. 프로세스 관련 사용자, 보안 그룹, 권한, 속성, 클레임, 기능, UAC(사용자 계정 제어) 가상화 상태, 세션, 제한된 사용자 계정 상태 ID를 식별하는 데 사용되는 액세스 토큰이며 앱 컨테이너 식별자 및 관련 샌드박스 정보도 포함합니다.
5. 프로세스 ID. 내부적으로 클라이언트 ID 식별자의 일부인 고유 식별자입니다.
6. 하나 이상의 실행 스레드. 그러나 "빈" 프로세스를 생성하는 것은 가능합니다.

많은 도구가 프로세스 및 프로세스 정보를 보거나 수정하는 데 도움이 될 수 있습니다. 아래에서 우리는 시연하려고 노력할 것입니다.

작업 관리자를 사용하여 프로세스 정보 보기

Windows에서는 단축키 Ctrl+shift+esc를 사용하여 작업 관리자를 열거나 도구 모음에서 마우스 오른쪽 버튼을 클릭하여 작업 관리자를 열 수 있습니다.

프로세스 탭에는 기본적으로 CPU, 메모리, 디스크 및 네트워크의 네 가지 정보 열이 표시됩니다. 테이블 헤더를 마우스 오른쪽 버튼으로 클릭한 후 더 많은 열 정보를 표시하거나 표시된 정보의 일부를 숨기도록 선택할 수 있습니다. 표시할 수 있는 정보에는 프로세스 이름, 프로세스 ID, 유형, 상태, 게시자 및 명령줄이 포함됩니다. 일부 프로세스는 확장되어 해당 프로세스에서 생성된 최상위 표시 창을 표시할 수 있습니다.

프로세스 정보도 표시되지만 더 간결한 방식으로 표시되는 세부 정보 탭으로 이동할 수 있습니다. 프로세스에 의해 생성된 창은 여기에 표시되지 않지만 더 많은 유형의 정보 열이 제공됩니다.

마찬가지로 상세 정보에서 머리글을 마우스 오른쪽 버튼으로 클릭하고 열 정보 설정을 선택하여 프로세스에 대한 자세한 정보를 표시할 수도 있습니다.

여기서 우리는 몇 가지 옵션 값의 역할에 초점을 맞출 필요가 있습니다.

• "스레드": 각 프로세스가 소유한 스레드 수를 표시합니다.
• "Handle": 프로세스의 내부 잠금으로 열린 커널 개체 핸들의 수를 표시합니다.
• "상태": 실행 중, 일시 중단 등과 같은 프로세스의 현재 실행 상태를 표시합니다.

상위 프로세스

또한 각 프로세스는 자신의 상위 프로세스를 가리킵니다(상위 프로세스는 생성자 프로세스일 수 있지만 항상 그런 것은 아닙니다). 상위 프로세스가 더 이상 존재하지 않는 경우 이 정보는 더 이상 업데이트되지 않습니다. 따라서 프로세스가 존재하지 않는 상위 프로세스를 가리킬 수 있습니다. 그러나 이것은 어떤 프로세스의 동작이 부모 프로세스 정보가 유효한지 여부에 의존하지 않기 때문에 문제를 일으키지 않습니다. 프로세스 탐색기는 재사용된 프로세스 ID에 연결된 하위 프로세스를 방지하기 위해 상위 프로세스의 시작 시간을 고려합니다.

대부분의 도구는 프로세스의 상위 또는 생성자 프로세스의 ID를 표시하지 않습니다. 성능 모니터를 사용하여 생성 프로세스 ID를 쿼리하여 이 정보를 얻을 수 있습니다. Windows용 디버깅 도구에서 /t 스위치와 함께 Tlist.exe 도구를 사용하여 프로세스 트리를 표시합니다. (새로운 Windows 10에서는 Tlist.exe가 TaskList(Tasklist.exe)로 변경되었으며, .t 옵션은 더 이상 지원되지 않습니다.)

여기에서는 MS에서 제공하는 sysinternals 패키지의 프로세스 탐색기를 사용하여 보다 자세한 프로세스 정보를 표시합니다. (이 도구에 대한 설명 및 다운로드 링크: https://learn.microsoft.com/zh-cn/sysinternals/downloads/ )

sysinternals의 프로세스 탐색기는 다른 유사한 도구보다 더 자세한 프로세스 및 스레드 정보를 표시할 수 있으며 일부 고유한 기능을 표시하거나 구현할 수도 있습니다.

1. 임대 및 권한 목록, 가상화 상태와 같은 보안 토큰을 처리합니다.
2. 프로세스, 스레드, DLL 및 핸들 목록의 변경 사항을 강조 표시합니다.
3. 서비스 서비스의 표시 이름 및 설명을 포함하여 호스팅 프로세스 내의 서비스 목록입니다.
4. 완화 정책 및 프로세스 보호 수준과 같은 기타 프로세스 속성 목록입니다.
5. 작업에 포함된 프로세스 및 작업 세부 정보입니다.
6. .NET 응용 프로그램 및 appdomain 목록, 로드된 어셈블리 및 CLR 성능 카운터와 같은 .NET 관련 세부 정보를 호스팅하는 프로세스입니다.
7. Windows 런타임을 호스트하는 프로세스(몰입형 프로세스).
8. 프로세스 및 스레드의 시작 시간입니다.
9. 메모리 매핑된 파일의 전체 목록(DLL만이 아님).
10. 프로세스 또는 스레드를 일시 중단하는 기능.
11. 특정 스레드를 종료하는 기능.
12. 일정 기간 동안 가장 많은 CPU 리소스를 사용하는 프로세스를 쉽게 식별합니다.

참고: 성능 모니터는 지정된 프로세스 집합에 대한 CPU 사용률을 표시할 수 있지만 성능 모니터 세션이 시작된 후 생성된 프로세스에 대한 정보를 자동으로 표시할 수 없으며 수동으로 생성된 이진 출력 형식에만 이러한 정보가 포함될 수 있습니다.

Process Explorer는 또한 사용자가 한 곳에서 다음 정보에 쉽게 액세스할 수 있도록 도와줍니다.

1. 트리의 일부를 축소하는 기능이 있는 프로세스 트리.
2. 명명되지 않은 핸들을 포함하여 프로세스에서 핸들을 엽니다.
3. 프로세스의 DLL 목록입니다.
4. 프로세스의 스레드 활동.
5. Windows용 디버깅 도구에서 제공하는 Dbghelp.dll을 사용하여 주소가 매핑되는 이름을 포함한 사용자 모드 및 커널 모드 스레드 스택.
6. 최대 메모리 커밋, 커널 메모리 페이징 제한 및 비페이징 메모리 풀 제한과 같은 메모리 관리자 세부 정보입니다.

실

스레드는 Windows가 실행을 예약하는 프로세스 내의 엔터티입니다. 스레드가 없으면 프로세스의 프로그램을 실행할 수 없습니다.

스레드는 다음 기본 요소로 구성됩니다.

1. 프로세스의 상태를 나타내는 CPU 레지스터 내용 목록입니다.
2. 두 개의 스택: 하나는 커널 모드에서 실행되는 스레드용이고 다른 하나는 사용자 모드에서 실행되는 스레드용입니다.
3. 하위 시스템, 런타임 라이브러리 및 DLL에서 사용하는 스레드 로컬 저장소라는 개인 저장소 영역입니다. (스레드 로컬 스토리지, TLS)
4. 스레드 ID라는 고유 식별자입니다.

또한 스레드에는 토큰이라고도 하는 고유한 보안 컨텍스트가 있는 경우가 있는데, 이는 주로 다중 스레드 서버 응용 프로그램에서 제공되는 클라이언트의 보안 컨텍스트를 모방하는 데 사용됩니다.

휘발성 및 비휘발성 레지스터와 개인 저장 영역의 조합이 스레드 컨텍스트를 형성합니다. 아키텍처가 다른 컴퓨터에서 실행되는 Windows에서는 이러한 정보가 다르기 때문입니다. 따라서 본질적으로 이 구조는 특정 아키텍처와 관련이 있습니다. Windows의 GetThreadContext 함수는 이 아키텍처 종속 정보(CONTEXT 블록이라고도 함)에 대한 액세스를 제공합니다. 또한 각 스레드에는 자체 스택이 있습니다(스레드 컨텍스트의 스택 레지스터 섹션이 가리킴).

한 스레드에서 다른 스레드로 실행 프로세스를 전환하려면 커널 스케줄러의 참여가 필요하며 이는 특히 두 스레드가 서로 자주 전환해야 하는 경우 비용이 많이 드는 작업일 수 있습니다.오버헤드를 줄이기 위해 Windows는 두 가지 메커니즘을 구현합니다.

• 섬유
• UMS(사용자 모드 스케줄링) 스레드

섬유

파이버를 사용하면 응용 프로그램이 Windows의 기본 제공 우선 순위 기반 예약 메커니즘에 의존하지 않고 자체 스레드 실행을 직접 예약할 수 있습니다. 섬유는 일반적으로 경량 스레드라고도 합니다. 스케줄링 측면에서 파이버는 Kernel32.dll을 통해 사용자 모드에서 구현되기 때문에 커널에 보이지 않습니다. 섬유를 사용하려면 먼저 스레드를 실행 중인 섬유로 변환하는 Windows ConvertThreadToFiber 함수를 호출해야 합니다. 새로 변환된 파이버는 CreateFiber 기능을 통해 더 많은 파이버를 생성할 수 있습니다. (각 파이버는 고유한 파이버 세트를 가질 수 있습니다.) 그러나 스레드와 달리 파이버는 SwitchToFiber 함수를 호출하여 수동으로 선택할 때까지 실행을 시작할 수 없습니다. 새로 생성된 광섬유는 종료되거나 SwitchToFiber 기능이 다시 호출되고 다른 광섬유가 실행되도록 선택될 때까지 계속 실행됩니다. 파이버 기능에 대한 자세한 내용은 Windows SDK 설명서에서 찾을 수 있습니다.

사용자 모드 스케줄링 스레드

64비트 Windows에서만 사용할 수 있는 UMS(User-Mode Scheduling) 스레드는 파이버와 유사한 기본 용도를 제공하지만 파이버의 단점을 대부분 방지합니다. UMS 스레드에는 자체 커널 스레드 상태가 있으므로 커널에 표시되므로 여러 UMS 스레드가 차단 시스템 호출을 발행하고 리소스를 공유하거나 경쟁할 수 있습니다. 또는 두 개 이상의 UMS 스레드가 사용자 모드에서 작업을 수행해야 하는 경우 주기적으로 실행 컨텍스트를 전환할 수 있으며(한 스레드가 다른 스레드에 실행 권한을 양보함) 이 프로세스는 스케줄러의 참여 없이 사용자 모드에서 수행할 수 있습니다. 커널의 관점에서 볼 때 동일한 커널 스레드가 이 시점에서 여전히 실행 중이며 변경된 사항은 없습니다. UMS 스레드가 수행하는 작업이 커널에 진입해야 하는 경우(예: 시스템 호출) 자체 전용 커널 모드 스레드로 전환할 수 있습니다(이 프로세스를 방향성 컨텍스트 전환, 방향성 컨텍스트 전환이라고 함). 동시 UMS 스레드는 여전히 여러 프로세스를 통해 실행될 수 없지만 선점형 모드를 준수하므로 완전히 협조적이지는 않습니다.

스레드가 자체 실행 컨텍스트를 가지고 있고 프로세스의 각 스레드도 프로세스의 가상 주소 공간을 공유하지만 프로세스의 모든 스레드는 프로세스의 가상 주소 공간에 대한 액세스를 완전히 읽고 쓸 수 있습니다. 그러나 다른 프로세스가 자체 개인 주소 공간의 일부를 공유 메모리 영역(Windows API에서 파일 매핑 개체라고 함)에 프로그래밍하거나 프로세스가 ReadProcessMemory 및 WriteProcessMemory 기능과 같은 크로스 프로세스 메모리 기능을 사용하기 위해 다른 프로세스를 열 수 있는 권한이 없는 경우 스레드는 실수로 다른 프로세스의 주소 공간을 참조할 수 없습니다(프로세스는 AppContainer 또는 다른 유형의 샌드박스가 아닌 동일한 사용자 계정으로 실행되어야 하며 대상 프로세스에 일종의 보호 메커니즘이 없으면 액세스할 수 있습니다). 기본적으로).

개인 주소 공간과 하나 이상의 스레드 외에도 각 프로세스에는 고유한 보안 컨텍스트와 파일, 공유 메모리 영역, 뮤텍스, 이벤트 및 세마포어와 같은 동기화 개체와 같은 커널 개체에 대한 열린 핸들 목록이 있습니다.

그림에서 VAD는 프로세스가 사용하는 가상 주소를 추적하기 위해 메모리 관리자가 사용하는 데이터 구조인 가상 주소 설명자를 나타냅니다.

각 프로세스의 보안 컨텍스트는 액세스 토큰이라는 개체에 저장됩니다. 프로세스 액세스 토큰에는 프로세스의 보안 ID 및 자격 증명이 포함됩니다. 기본적으로 스레드에는 고유한 액세스 토큰이 없지만 프로세스의 다른 스레드에 영향을 주지 않고 다른 프로세스(원격 Windows 시스템의 프로세스 포함)의 보안 컨텍스트를 가장할 수 있는 토큰을 얻을 수 있습니다(나중에 프로세스 및 스레드 보안에 대해 자세히 설명).

작업

Windows는 "작업"이라는 프로세스 모델에 대한 확장을 제공합니다. 작업 개체의 주요 기능은 리소스 집합을 전체적으로 관리하고 운영하는 것입니다. 작업 개체를 사용하여 특정 속성을 제어하고 작업이 연결된 하나 이상의 프로세스에 제한을 둘 수 있습니다. 또한 작업과 관련된 모든 프로세스 및 작업과 관련되었지만 연결 후 종료된 모든 프로세스에 대해 기본 계정 정보를 기록할 수 있습니다. Job 개체는 구조화된 프로세스 트리에서 Windows의 부족함을 어느 정도 보완하고 많은 경우에 Unix와 같은 프로세스 트리보다 더 강력합니다.

가상 메모리

Windows는 플랫(선형) 주소 공간을 기반으로 가상 메모리 시스템을 구현하므로 각 프로세스가 거대한 개인 주소 공간을 얻을 수 있다고 "느낄" 수 있습니다. 가상 메모리가 메모리에 대해 제공하는 논리적 보기는 물리적 레이아웃과 일치하지 않을 수 있습니다. 런타임에 메모리 관리자는 (하드웨어의 도움으로) 가상 주소를 변환할 수 있습니다. 데이터가 실제로 저장된 물리적 주소에 즉시 매핑 보호 및 매핑 프로세스를 제어함으로써 운영 체제는 프로세스가 서로 영향을 미치지 않고 운영 체제 데이터를 덮어쓰지 않도록 보장할 수 있습니다.

대부분의 OS에서 물리적 메모리의 양은 프로세스를 실행하는 데 필요한 총 가상 메모리 양보다 훨씬 적기 때문에 메모리 관리자는 일부 메모리 내용을 변환해야 합니다. 즉, 이를 디스크로 페이징해야 합니다. 데이터를 디스크로 페이징하면 다른 프로세스나 운영 체제 자체에서 사용할 물리적 메모리가 해제됩니다. 스레드가 디스크로 페이징된 가상 주소에 액세스해야 하는 경우 가상 메모리 관리자는 관련 정보를 디스크에서 물리적 메모리로 다시 로드합니다.

하드웨어 지원을 통해 메모리 관리자가 프로세스나 스레드에 대한 지식이나 지원 없이 페이징할 수 있으므로 페이징이 제공하는 이점을 활용하기 위해 응용 프로그램을 특별히 조정할 필요가 없습니다. 두 프로세스가 사용하는 가상 메모리 중 일부는 여전히 물리적 메모리(Physical Memory RAM)에 매핑되어 있고 다른 일부는 디스크에 페이징되어 있습니다. 연속된 가상 메모리 블록은 비연속적인 물리적 메모리 블록에 매핑될 수 있습니다. 이러한 블록을 페이지라고도 하며 각 페이지의 기본 크기는 4KB입니다.

가상 메모리 주소 공간의 크기는 하드웨어 플랫폼마다 다릅니다. 32비트 X86 시스템에서 총 가상 메모리 공간의 이론적 최대값은 4GB입니다. 기본적으로 Windows는 이 주소 공간의 아래쪽 절반(0x00000000에서 0x7FFFFFFFF까지)을 프로세스에 고유한 개인 저장소로 프로세스에 할당하고 위쪽 절반(0x80000000에서 0xFFFFFFFF까지)을 보호된 운영 체제 메모리로 자신에게 할당합니다. 매핑의 아래쪽 절반은 현재 실행 중인 프로세스의 가상 주소 공간을 반영하도록 변경되지만 매핑의 위쪽 절반(대부분)은 항상 운영 체제의 가상 메모리로 구성됩니다. Windows에서 지원하는 시작 옵션(예: 부팅 구성 데이터베이스의 증가 사용자바 수정자)은 특수 태그가 있는 프로그램을 실행하는 프로세스가 최대 3GB의 개인 주소 공간을 사용하여 운영 체제에 1GB만 남겨둘 수 있도록 합니다.

32비트 Windows에서 지원하는 두 가지 일반적인 가상 주소 공간 레이아웃이 아래 그림에 나와 있습니다.

3GB의 가상 주소 공간이 2GB보다 낫지만 매우 큰 데이터베이스를 매핑하기에는 여전히 충분하지 않습니다. 32비트 시스템에서 이 문제를 해결하기 위해 Windows는 AWE(Address Windowing Extension)라는 메커니즘을 제공합니다. 이를 통해 32비트 응용 프로그램은 최대 64GB의 실제 메모리를 할당한 다음 보기 또는 창을 자체 2GB 가상 주소 공간에 매핑할 수 있습니다. AWE는 가상 메모리-물리적 메모리 매핑 관계의 관리 부담을 개발자에게 전가하지만 더 많은 물리적 메모리에 대한 직접 액세스에 대한 요구를 충족하며 특정 수는 32비트 프로세스 주소 공간이 한 번에 수용할 수 있는 상한을 초과합니다.

64비트 Windows는 64비트 주소 길이가 최대 2의 64제곱(16EB, 1EB = 1024PB, 1PB = 1024TB, 1TB = 1024GB)에 액세스할 수 있기 때문에 프로세스에 더 큰 주소 공간을 제공합니다.

커널 모드와 사용자 모드

사용자 응용 프로그램이 운영 체제의 중요한 데이터에 액세스하거나 수정하는 것을 방지하기 위해 Windows는 두 가지 프로세서 액세스 모드를 사용합니다(사실 Windows를 실행하는 프로세서는 더 많은 모드를 지원할 수 있음). 두 가지 모드는 사용자 모드와 커널 모드입니다.

1. 사용자 모드: 애플리케이션 코드는 사용자 모드에서 실행됩니다.
2. 커널 모드: 운영 체제 코드는 커널 모드에서 실행됩니다. 커널 모드는 모든 시스템 메모리 및 CPU 명령에 대한 액세스를 허용하는 프로세서 실행 모드입니다.

일부 프로세서는 서로 다른 모드를 구분하기 위해 코드 권한 수준 또는 링 수준과 같은 용어를 사용합니다. 그러나 유사한 감독자 모드(수퍼바이저 모드)와 응용 프로그램 모드를 구별하여 사용하는 프로세서도 있습니다.

각 Windows 프로세스에는 자체 전용 메모리 공간이 있지만 커널 모드 운영 체제와 장치 드라이버 코드는 동일한 가상 주소 공간을 공유합니다. 가상 메모리의 각 페이지에는 프로세서가 페이지를 읽거나 쓰기 위해 사용해야 하는 액세스 모드를 나타내는 태그가 있습니다. 시스템 공간의 메모리는 커널 모드에서만 액세스할 수 있지만 사용자 주소 공간의 모든 페이지는 사용자 모드 또는 커널 모드에서 액세스할 수 있습니다.

읽기 전용 페이지(정적 데이터가 있는 페이지)는 어떤 모드에서도 쓸 수 없습니다. 또한 실행 불가능 메모리 보호를 지원하는 프로세서의 경우 Windows는 페이지에 포함된 데이터를 실행 불가능으로 표시하여 부주의하거나 악의적인 코드가 데이터 영역에서 실행되는 것을 방지합니다(데이터 실행 방지(데이터 실행 방지, DEP)가 켜져 있어야 함).

Windows는 커널 모드에서 실행되는 구성 요소가 사용하는 개인 읽기/쓰기 시스템 메모리에 대한 보호를 제공하지 않습니다. 즉, 커널 모드에 들어가면 운영 체제와 장치 드라이버 코드 모두 전체 시스템 공간 메모리에 액세스할 수 있으며 Windows 보안 메커니즘을 우회하여 다양한 개체에 액세스할 수 있습니다. Windows 운영 체제에는 커널 모드에서 실행되는 많은 양의 코드가 있기 때문에 커널 모드에서 실행되는 구성 요소는 시스템 보안 메커니즘을 위반하거나 시스템 불안정을 유발하지 않도록 신중하게 설계하고 테스트해야 합니다.

이러한 보호 기능 부족은 또한 타사 장치 드라이버를 로드할 때 더욱 주의해야 하며, 특히 타사 장치 드라이버에는 디지털 서명이 포함되어 있지 않습니다.커널 모드에 들어가면 드라이버는 운영 체제의 모든 데이터에 완전히 액세스할 수 있습니다. 이것은 Windows 2000이 드라이버 서명 메커니즘을 구현하기 시작한 이유 중 하나이기도 합니다. (서명 메커니즘 외에도 Windows는 드라이버 테스트 및 버그 찾기를 위한 드라이버 검증 도구를 제공합니다. 이에 대해서는 나중에 설명합니다. 링크: https://learn.microsoft.com/zh-cn/windows-hardware/drivers/devtest/devcon-examples#example-8-list-all-driver-files )

Windows 10과 함께 제공되는 성능 모니터를 통해 커널 모드와 사용자 모드 간의 현재 전환과 시간이 많이 걸리는 비교를 관찰할 수 있습니다.

하이퍼바이저

최근 몇 년 동안 클라우드 서비스의 출현과 사물 인터넷 장치의 편재성 등 애플리케이션 및 소프트웨어 개발 모델에 큰 변화가 있었습니다. 이러한 새로운 추세로 인해 운영 체제 및 하드웨어 공급업체는 호스트 하드웨어를 통해 게스트 운영 체제를 보다 효율적인 방식으로 가상화하는 방법을 찾게 됩니다. 예를 들어, 서버를 통해 여러 테넌트를 호스팅하고, 하나의 서버로 100개의 격리된 웹 사이트를 실행하고, 개발자가 전용 하드웨어를 구입하지 않고도 수십 개의 서로 다른 운영 체제를 테스트할 수 있도록 해야 할 수 있습니다. 사용자는 가상화 기술의 속도, 효율성 및 보안에 대해 더 높은 요구 사항을 제시했으며, 이는 새로운 컴퓨팅 모델 및 소프트웨어 이론을 탄생시켰습니다. 실제로 Docker와 같은 오늘날의 일부 소프트웨어는 자체적으로 Windows 10 및 Windows Server 2016에서 지원되며 컨테이너에서 실행하여 완전히 격리된 가상 머신 환경을 얻을 수 있으므로 동일한 애플리케이션 스택 또는 프레임워크를 실행하여 게스트/호스트 머신 모델의 혁신을 실현할 수 있습니다.

이러한 가상화 서비스를 제공하기 위해 거의 모든 최신 솔루션은 가상 및 물리적 메모리에서 장치 인터럽트, 심지어 PCI 및 USB 장치에 이르기까지 컴퓨터의 모든 리소스를 가상화하고 격리하는 매우 권한이 높은 특수 구성 요소인 하이퍼바이저를 사용합니다. Hyper-V는 그러한 하이퍼바이저 중 하나이며 Windows 8.1 이상의 Hyper-V 클라이언트 기능은 이 기술로 활성화됩니다.

Windows 10에서 Microsoft는 Hyper-V 하이퍼바이저를 사용하여 VBS(가상화 기반 보안)를 위한 일련의 새로운 서비스를 제공합니다.

1. 디바이스 가드. Via Hypervisor Code Integrity(HVCI)는 KMCS만 사용하는 것보다 더 강력한 코드 서명 보증을 제공하고 Windows 운영 체제용 사용자 모드 및 커널 모드 코드에 대한 사용자 지정 서명 정책을 제공합니다.
2. 하이퍼 가드. 커널 및 하이퍼바이저와 관련된 중요한 데이터 구조 및 코드를 보호합니다.
3. 크리덴셜 가드(크레덴셜 가드). 자격 증명 및 암호는 도메인 계정에 대한 무단 액세스를 방지하고 생체 인식 인증 메커니즘과 함께 사용할 수 있습니다.
4. 애플리케이션 가드. Microsoft Edge 브라우저에 더 강력한 샌드박스 메커니즘을 제공합니다.
5. 호스트 가디언 및 차폐 패브릭. v-TPM(가상 TPM)을 사용하여 인프라에 대한 위협으로부터 가상 머신을 보호할 수 있습니다.

펌웨어

Windows 구성 요소는 하이퍼바이저가 제공하는 보호 기능에 의존하는 운영 체제 및 시스템 커널의 보안에 점점 더 의존하고 있습니다.

그러면 문제가 발생합니다. 그런 다음 하이퍼바이저 구성 요소를 안전하게 로드하고 내용을 확인할 수 있는지 확인합니다. 일반적으로 이는 부트 로더의 책임이지만 부트 로더 자체는 동일한 수준의 유효성 검사를 받아야 하므로 서로 다른 구성 요소 간의 신뢰 관계가 복잡해집니다.

그렇다면 루트 신뢰 체인을 통해 부팅 프로세스가 안정적이고 영향을 받지 않도록 하는 방법은 무엇입니까? 최신 Windows 8 이상 시스템에서는 시스템 펌웨어를 통해 이 작업을 수행하지만 UEFI 기반 인증 시스템을 사용하는 경우에만 가능합니다.

Windows 요구 사항이자 UEFI 표준의 일부인 보안 부팅은 부팅 관련 소프트웨어의 서명된 품질에 대한 강력한 보증 및 요구 사항을 제공해야 합니다. 이 검증 프로세스는 Windows 구성 요소가 부팅 프로세스 초기부터 안전한 방식으로 로드되도록 합니다. 또한 TPM(신뢰할 수 있는 플랫폼 모듈) 주입과 같은 기술을 통해 전체 부팅 프로세스를 측정하고 해당 증명(로컬 또는 원격 증명)을 제공할 수 있습니다.

터미널 서비스 및 멀티세션

터미널 서비스는 단일 시스템을 통해 여러 대화형 사용자 세션을 지원하는 Windows의 기능을 나타냅니다. 원격 사용자는 Windows 터미널 서비스를 사용하여 다른 컴퓨터에서 세션을 설정하고 서버에 로그온하고 응용 프로그램을 실행할 수 있습니다. 그런 다음 서버는 그래픽 사용자 인터페이스(GUI)를 클라이언트에 전송하고 클라이언트는 사용자 입력을 다시 서버로 보냅니다. (X Window 시스템과 유사하게 Windows는 특정 응용 프로그램을 서버 시스템에 업로드하고 디스플레이 화면을 원격 클라이언트로 다시 보내지만 데스크톱 전체를 원격으로 전송할 필요는 없습니다.)

첫 번째 세션은 일반적으로 시스템 서비스 호스팅 프로세스를 포함하는 서비스 세션인 세션 0입니다. 콘솔에 대한 물리적 로그인을 통해 컴퓨터에 설정된 첫 번째 세션은 세션 1이며 이후에 원격 데스크톱 연결 프로그램(Mstsc.exe) 또는 빠른 사용자 전환을 통해 추가 세션이 연결됩니다.

Windows 클라이언트 버전에서는 한 명의 원격 사용자만 컴퓨터에 연결할 수 있으며 연결 시 콘솔에 누군가 이미 로그인되어 있으면 워크스테이션이 잠깁니다. 즉, 원격 연결에 사용되는 컴퓨터는 여러 사람이 동시에 사용할 수 없습니다.

Windows Server 시스템은 두 개의 동시 원격 연결을 지원합니다. 이는 원격 관리를 용이하게 하기 위한 것입니다. 예를 들어 사용되는 관리 도구는 사용자가 관리 중인 컴퓨터에 로그인할 필요가 없을 수 있습니다. 필요한 라이센스가 있고 터미널 서버로 구성된 경우 추가 원격 세션을 지원할 수 있습니다.

개체 및 핸들

Windows 운영 체제에서 커널 개체는 정적으로 정의된 개체 유형의 단일 런타임 인스턴스를 나타냅니다. 개체 유형은 시스템 정의 데이터 유형, 해당 데이터 유형에 대한 작업을 수행하는 함수 및 개체 속성 집합으로 구성됩니다.

Windows 응용 프로그램을 개발해야 하는 경우 프로세스, 스레드, 파일, 이벤트 개체 등과 같은 많은 개념을 접할 수 있습니다. 이러한 개체는 Windows에서 만들고 관리하는 기본 개체를 기반으로 합니다. Windows에서 프로세스는 실제로 프로세스 개체 유형의 인스턴스이고 파일은 파일 개체 유형의 인스턴스입니다.

개체 속성은 개체 상태의 일부를 정의하는 개체의 데이터 필드입니다. 예를 들어 프로세스 유형의 객체는 속성을 통해 프로세스 ID, 기본 스케줄링 우선 순위, 액세스 토큰 객체에 대한 포인터 등을 포함합니다. 개체 메서드는 개체 속성을 읽거나 변경하는 데 운영 체제 개체를 사용할 수 있는 수단입니다. 예를 들어 프로세스의 Open 메서드는 프로세스 식별자를 입력으로 받아들이고 개체에 대한 포인터를 출력으로 반환할 수 있습니다.

객체와 일반 데이터의 가장 본질적인 차이점은 객체의 내부 구조가 불투명하다는 것입니다. 개체에 저장된 데이터를 가져오거나 외부 데이터를 개체에 넣기 위해 개체 서비스를 호출해야 하지만 개체 내부의 데이터를 직접 읽거나 변경할 수는 없습니다. 이 차이는 개체의 기본 구현을 단순히 사용하는 코드와 효과적으로 구분하므로 언제든지 개체의 구현에 쉽게 액세스하고 변경할 수 있습니다.

커널 구성 요소인 개체 관리자의 도움으로 개체는 다음과 같은 네 가지 중요한 운영 체제 작업을 용이하게 할 수 있습니다.

• 시스템 리소스에 사람이 읽을 수 있는 이름 제공
• 프로세스 간 리소스 및 데이터 공유
• 무단 액세스로부터 리소스 보호
• 개체가 더 이상 사용되지 않을 때 시스템이 이를 인식하여 자동으로 해제할 수 있도록 하는 참조 추적.

Windows 운영 체제의 모든 데이터 구조가 객체인 것은 아니며 공유, 보호, 이름 지정 또는 사용자 모드 프로그램에서 볼 수 있는 데이터만 객체에 배치해야 합니다.

안전

Windows는 보안을 염두에 두고 설계되었으며 CCITSE(정보 기술 보안 평가) 사양에 대한 공통 기준과 같은 정부 및 업계의 다양한 정식 보안 등급 요구 사항을 충족할 수 있습니다. 정부 승인 보안 등급을 획득하면 관련 분야에서 운영 체제의 경쟁력을 높일 수 있습니다. 물론 이러한 기능 중 다수는 모든 다중 사용자 시스템에 도움이 될 수 있습니다.

Windows의 핵심 보안 기능은 다음과 같습니다.

1. 파일, 디렉터리, 프로세스, 스레드 등과 같은 모든 공유 가능한 시스템 개체에 대한 재량권이 제공되며 응용 프로그램의 보호가 강조됩니다.
2. 주체 또는 사용자에 대한 보안 감사 및 책임과 그들이 시작하는 작업을 수행합니다.
3. 로그인 시 사용자 인증.
4. 사용 가능한 메모리 또는 디스크와 같이 다른 사용자가 할당을 취소한 리소스에 대한 사용자의 무단 액세스를 방지합니다.

Windows는 개체에 대한 세 가지 형태의 액세스 제어를 제공합니다.

• 임의 액세스 제어. 이 보호 메커니즘은 대부분의 사람들이 운영 체제 보안을 생각할 때 가장 먼저 생각하는 것입니다. 이러한 방식으로 개체(예: 파일 또는 프린터)의 소유자는 다른 사람에 대한 액세스를 실행하거나 거부할 수 있습니다. 사용자가 로그인하면 보안 컨텍스트라고도 하는 일련의 보안 자격 증명을 얻을 수 있습니다. 사용자가 개체에 액세스하려고 하면 시스템은 해당 보안 컨텍스트를 원하는 액세스 제어 목록과 비교하여 사용자가 요청된 작업을 수행할 수 있는 권한이 있는지 확인합니다. Windows Server 2012 및 Windows 8에서는 이 임의 제어 메커니즘이 특성 기반 액세스 제어(동적 액세스 제어)로 더욱 향상되었습니다. 그러나 리소스에 대한 액세스 제어 목록은 개별 사용자 및 그룹을 식별할 필요가 없으며 "권한 수준: 일급 비밀" 또는 "경력: 10년"과 같이 리소스에 대한 액세스를 허용하는 데 필요한 특성 또는 클레임을 식별할 수도 있습니다. Active Directory의 도움으로 SQL 데이터베이스 및 스키마를 구문 분석하여 이러한 속성을 자동으로 획득함으로써 보다 우아하고 유연한 이 보안 모델은 그룹 및 그룹 계층을 수동으로 관리하는 지루한 작업에서 조직을 해방시킬 수 있습니다.
• 권한 있는 액세스 제어. 임의 액세스 제어가 요구 사항을 완전히 충족할 수 없을 때 필요한 메커니즘이기도 합니다. 이 방법을 사용하면 소유자를 사용할 수 없을 때 다른 사람이 보호된 개체에 계속 액세스할 수 있습니다. 예를 들어 직원이 퇴사하고 관리자가 이전에는 해당 직원만 액세스할 수 있었던 파일에 액세스할 방법이 필요한 경우 관리자는 Windows에서 파일 소유권을 얻은 다음 필요에 따라 파일에 대한 액세스를 관리할 수 있습니다.
• 필수 무결성 메커니즘. 이 메커니즘은 동일한 사용자 계정으로 액세스하는 보호된 개체에 추가 보안 제어가 필요한 경우에 필요합니다. 이 메커니즘은 Windows 응용 프로그램에 제공되는 샌드박스 메커니즘, 사용자 구성을 통해 보호 모드에서 Internet Explorer가 제공하는 격리, 상승되지 않은 관리자 계정의 액세스로부터 상승된 관리자 계정으로 생성된 개체 보호와 같은 여러 위치에서 사용됩니다.

Windows 8부터 시스템은 appcontainer라는 샌드박스를 사용하여 Windows 응용 프로그램을 호스팅합니다. 이 기술은 서로 다른 appcontainer 간에 그리고 appcontainer와 비 Windows 응용 프로그램 프로세스 간에 격리할 수 있습니다. appcontainer의 코드는 브로커를 통해 통신할 수 있으며 Windows 런타임에서 제공하는 잘 정의된 계약을 통해 때로는 다른 appcontainer 또는 프로세스와 통신할 수 있습니다.

다양한 보안 메커니즘이 Windows API 인터페이스에 완전히 통합되어 있습니다. Windows 하위 시스템은 운영 체제와 유사한 방식으로 개체 기반 보안 모델을 구현합니다.

• 무단 액세스를 방지하기 위해 공유 Windows 개체에 대한 Windows 보안 설명자를 설정합니다.
• 응용 프로그램이 처음으로 공유 객체에 액세스하려고 시도하면 Windows 하위 시스템이 응용 프로그램의 권한을 확인합니다.
• 보안 검사를 통과하면 Windows 하위 시스템에서 애플리케이션이 계속 액세스하도록 허용합니다.

등록 양식

Windows 운영 체제를 사용해 본 사람이라면 레지스트리에 대해 들어봤거나 사용해 본 적이 있을 것입니다. Windows의 내부 원칙에 관해서는 레지스트리의 시스템 데이터베이스에 다음이 포함되어 있기 때문에 레지스트리를 언급하는 것이 불가피합니다.

• 시스템 자동화 및 구성에 필요한 정보
• Windows 실행 방식을 제어하는 ​​시스템 수준 소프트웨어 설정
• 보안 데이터베이스
• 사용된 화면 보호기와 같은 사용자 구성 정보

또한 레지스트리는 시스템의 현재 하드웨어 상태(로드된 장치 드라이버, 드라이버에서 사용하는 리소스)와 같은 메모리의 휘발성 데이터에 대한 액세스를 제공합니다. Windows 성능 카운터도 있습니다. 성능 카운터는 실제로 레지스트리에 위치하지 않지만 레지스트리를 통해 성능 카운터 세부 정보에 액세스할 수 있습니다.

많은 Windows 사용자와 관리자가 레지스트리를 직접 처리할 필요는 없지만(대부분의 구성 옵션은 표준 관리 도구를 통해 보고 변경되기 때문에) 레지스트리는 여전히 시스템 성능과 동작에 영향을 줄 수 있는 많은 설정을 포함하는 Windows 내부에 대한 유용한 정보 소스입니다. (HKLM이라고 하는 레지스트리의 시스템 수준 구성 루트 키 HKEY_LOCAL_MACHINE)

유니코드

Windows는 대부분의 다른 운영 체제와 큰 차이점이 있습니다. Windows의 대부분의 텍스트 문자열은 16비트 폭의 유니코드 문자열(기술적으로는 UTF-16LE 사용)로 저장되고 처리됩니다. 유니코드는 세계적으로 알려진 대부분의 문자 집합에 대해 고유한 값을 정의하는 국제 문자 집합 표준으로, 각 문자에 대해 8비트, 16비트 또는 심지어 32비트 인코딩을 제공합니다.

많은 응용 프로그램이 8비트(싱글바이트) ANSI 문자열을 처리하기 때문에 많은 Windows 함수는 다음 두 진입점을 통해 문자열 매개 변수를 받아들일 수 있습니다.

• 유니코드(16비트 와이드 문자) 버전
• ANSI(8비트 좁은 문자) 버전

좁은 문자 버전의 Windows 함수를 호출하는 경우 입력 문자열 매개변수가 시스템에서 처리되기 전에 유니코드 문자로 변환되어야 하고 출력 매개변수가 응용 프로그램에 대한 출력을 위해 유니코드에서 ANSI로 변환되기 때문에 성능에 약간의 영향이 있을 수 있습니다. 따라서 Windows에서 이전 버전의 서비스 또는 코드를 실행해야 하고 관련 코드가 ANSI 문자열로 작성된 경우 Windows는 자체 사용을 위해 ANSI 문자를 유니코드로 변환하지만 Windows는 파일의 데이터를 변환하지 않습니다. 데이터를 유니코드로 저장할지 ANSI로 저장할지는 응용 프로그램에 달려 있습니다.

Dependency Walker 도구를 통해 Kernel32.DLL을 열면 서로 다른 문자열 유형에 대해 제공되는 쌍을 이루는 함수 인터페이스인 CreateFileA 및 CreateFileW 함수 인터페이스를 포함하여 포함된 함수 인터페이스를 볼 수 있습니다.
(Dependency Walker 도구 다운로드 링크: http://dependencywalker.com/ )

요약하다

이 기사는 나중에 Windows 커널 및 드라이버를 쉽게 배울 수 있도록 Windows 운영 체제의 주요 개념과 용어만 구성하고 기록합니다. 이 기사를 읽으면 Windows 운영 체제의 일반적인 구조와 일부 전문 용어에 대해 어느 정도 이해하고 친숙할 수 있으며 특정 세부 사항을 깊이 연구하고 이해해야 합니다.