사내 스터디

1. 왜 애플리케이션이 Hang 되어도 OS는 괜찮을까? 마이에트 엔터테인먼트 Server Programmer Microsoft VC++ MVP 최흥배 Twitter : @jacking75

3. 애플리케이션은 유저 모드로 동작,시스템은 커넬 모드로 동작하므로 안전. 시스템과 애플리케이션이 완전하게 분리되어 있으면 애플리케이션에서 시스템의 기능을 어떻게 이용할 수 있을까? 애플리케이션 유저모드 커널모드 시스템 하드웨어 어디엔가 유저 모드와 커널 모드의 사이를 중개 하는 것이 있지 않을까?

4. 따분할 수도 있겠지만 답을 찾기 위해 짧은 여행을 떠나 보시죠~ 내용과는 전혀 상관없는 일본 오사카의 야경입니다. 올해 가고 싶은 곳입니다.^^;

5. Windows의 아키텍처는 프로세서와 깊은 관계가 있다. 「유저 모드」와「커널 모드」라고 불리는 동작 모드는 그대로 Intel의 프로세서(80386~Pentium 4)가 갖추고 있는 「링3」와「링0」의 특권 레벨. 최초는Intel 프로세서는 「80286」의 「프로텍트 모드」 링 번호가 높은 레벨에서 낮은 레벨로 접근 할 수 없음. Windows에서는「링0」을 「커넬 모드」, 「링3」을 「유저 모드」라고 부러며 이 2개의 모드만을 사용한 나머지의 링을 이용하지 않는 이유는 다른 프로세서와의 호환성을 위해

6. 유저모드 커널모드 시스템 서비스 디스패쳐 MS-DOS 애플리케이션 Win32 애플리케이션 Win16 애플리케이션 각종 매니져 Window, User, GDI WOW 16 커널 디바이스 드라이버, 파일 시스템 드라이버 그래픽스 드라이버 DOS 에뮬레이션 DOS 에뮬레이션 HAL Windows 서브 시스템

7. 「시스템 서비스 디스패쳐」는 유저 모드와 커넬 모드의 변환을 담당. Windows 서브 시스템 블록이 중요. Windows API가 구현되어 있다. Windows 서브 시스템이 유저 모드와 커널 모드를 묶는 열쇠. Kernel32.dll,User32.dll,Gdi32.dll등의 DLL을 관리 Kernel32.dll은 이른바 「Windows API」 애플리케이션에서 보면 이름은 「서브」이지만 Windows서브 시스템은 시스템 그 자체라고 해 과언은 아니다

8. Windows 서브 시스템 (Win32 API) 애플리케이션 실제 애플리케이션이 Windows 서브 시스템 내의 API를 직접 호출할 수 없다. 왜냐하면 애플리케이션과 Windows 서브 시스템은 같은 유저 모드 상의 다른 가상 address 공간에 있기 때문 Kernel32.dll Gdi32.dll User32.dll

9. 32비트 프로세서는 프로세서가 가지는 「페이징」기능을 사용하여 물리 메모리 용량과 상관 없이 애플리케이션은 4G의 메모리 공간을 할당할 수 있음. 32비트 프로세서의 페이징 기능은 4G바이트의 가상 메모리 공간을 하나의 세그먼트(segment)로 여러개 가질 수있고, 그 세그먼트(segment) 주소와 실제 물리 메모리 주소를 대응표로 관리한다. 이 대응표를 「페이지 테이블」이라고 부른다. 그리고 Windows는 페이지 테이블을 이용하여 가상 머신 마다 4G 바이트의 가상 메모리 공간을 할당해서 그 중 2G바이트를 애플리케이션 영역,나머지 2G 바이트를 시스템 영역으로 지정하고 있다. 마치 Windows 시스템 안에 4G바이트의 메모리를 가진 컴퓨터가 여러개 존재하고 있는 이미지가 된다.

10. “간단한 구조이지만 애플리케이션에서 다른 애플리케이션이 사용하는 메모리 영역을 침범한다면??” 메모리 공간 애플리케이션 1 애플리케이션 2 애플리케이션 n Windows 시스템의 메모리 공간 장황한 구조지만 애플리케이션이 사용하는 메모리 영역을 벗어나도 다른 애플리케이션에 영향을 주지 않음 !!! 가상머신 A 가상머신 B

11. 그러나 실제로 이 이미지대로 시스템을 만들려고 하면 큰일난다. 후임병으로 온다면…..-_-;; 모든 가상 머신의 메모리 공간에 같은 Windows 서브 시스템을 준비하고 , 가상 머신으로 비동기로 실행되는 API의 협조를 얻는 것은 어려움. 물론기술적으로는 가능하지만 메모리 용량의 문제나 기동 시간 등 불리한 점이 많다. 그래서애플리케이션의 가상 머신과는 별도로 Win32 API용의 가상 머신을 진짜 Windows 서브 시스템에서 준비해 두고,애플리케이션 측에는 더미 DLL을 넣음. 이러한 DLL을 「stub DLL」이라고 부른다.

12. 가상머신 A 가상머신 A 가상머신 A Stub Dll Stub Dll Stub Dll Windows 서브 시스템 (Win32 API)

13. 그러나 아직 문제가 있다 !!! 애플리케이션은 자신이 할당할 수 있는 4G바이트 공간 밖에 액세스 할 수 없다. 이대로는 다른 세그먼트(segment)에 있는 Windows 서브 시스템의 API는 호출할 수 없게 된다.

14. 해결은… 커널 모드로 동작하는 매니저의 하나로 「로컬 프로시저 콜(LPC)」서비스

15. 가상 머신 가상 머신 LPC 서비스 가상 머신으로 동작하는 애플리케이션이 실행하는 API는 Windows 서브 시스템 가운데에 있다. 그리고 Windows 서브 시스템도 유저 모드로 동작하는 가상 머신이다. 이 2개의 가상 머신 사이를 주선하는 것이 로컬 프로시저 콜이다.

17. 가장 중요한 시스템의 중심은 커널 모드로 보호하고, 애플리케이션은 유저 모드의 가상 머신에서 실행. 그 애플리케이션이 호출한 Windows API는 또 다른 가상 머신에 놓여져 있고 서로 커널 모드가 제어하는 통신 기술로 접속된다. 이것이 정확하게 애플리케이션 크래쉬가 Windows의 시스템에까지 영향을 미치지 않는 진짜 이유.

18. 1차 출처 : http://itpro.nikkeibp.co.jp/article/Windows/20051111/224393/?ST=win&P=1