Windows ETC

Windows NT 아키텍처 - Part 5

2012.11.30 08:27

호스트웨이 조회 수:1487

Win32

 

 Win32 NT에서 본질적이고 가장 중요한 서브시스템이다.    서브시스템의

기본은 Win32 API로서, NT를 개발할 동안에 만들어진 것이다.  API의 대부

분은 Win16 API에서부터 직접 확장된 것이다.

 클라이언트/서버 모델에서 먼저 말했듯이, Win32 서브시스템은 NT  지원하

는 모든 다른 서브시스템에 대한 서버처럼 행동한다. 다른 환경 서브시스템은

클라이언트처럼 작동하며, 그들의 API 콜들을 적절한 Win32 API로 바꾸어준다.

API들은 다시 Win32 서브시스템을 통해 수행된다.

 Win32서브시스템은 모든  유저 입출력에 대한 관장도 한다.  즉 디스플레이,

키보드, 마우스 동작에 관할한다는 뜻이다. OS/2 POSIX같은 다른  서브시스

템들이 이 디바이스들을 이용하려면,  Win32서브시스템에 해당 서비스를 요청

하는 것이다.

 Win32서브시스템이 처음 디자인될 때에는, NT의 개발자는 그것의  동작을 될

수 있는 한 Win 3.1과 가까이 맞추려고 노력했다. 이것은 Win32 서브시스템을

다섯 개의 주요한 조각들로 디자인하는 결과를 낳았다. 그것은 윈도우 매니저

(종종 USER라고 불리는), 그래픽 디바이스 인터페이스(GDI), 콘솔,  운영체제

함수들, 그리고 Win32 그래픽 디바이스 드라이버이다.

 그러나, 윈도우 NT 4에서, Win32 서브시스템의 조직은 바뀌었다.  먼저 언급

했던 것처럼 다른 모든 서브시스템들이 Win32API를 사용자 입출력에 사용하기

때문에, GDI USER섹션을  Win32 서브시스템에서 NT실행부 안으로  옮겨버린

것이다.

 이런 구조는 GDI USER 서버를 이용하는 시스템 상의 모든 프로세스들의 오

버헤드를 감소시키는 효과가 있다. 이것이 윈도우 NT의 안정성에 영향을 준다

고 말들이 많았다. 많은 사람들이 이런 구조가 커넬모드에서 동작하는 코드를

증가시킴으로써 시스템  크래시 확률을  높일 수 있다고 얘기했다.  커넬모드

프로세스들은 시스템 자원을 액세스할 수 있기 때문이다.

 그러나 그것은 사실이 아니라고 생각한다. Win32 subsystem GDI  USER

있던 오리지널 모델로는, GDI USER에 문제가 생기면 그것을 이용하는  모든

프로그램이 잘못될 수 있기 때문이다. 그것은 전체 시스템의 다운현상을 가져

올 수 있다. 그러나, 그 두 가지를 NT실행부로 옮김으로써,  커넬이 그것들을

감시할 수 있게 되었다. 만약 동작중에 반응이 없으면, 그냥 시스템이 뻗어버

리는 것 보다는 커넬이 버그 체크 화면을 띄우고 (블루스크린이다.) 리부트를

허가할 수 있기 때문이다.  실제로는 이런 동작이 더 쓸모가 있다.  왜냐하면

본질적인 서비스의 실패로 NT커넬에게 리부트하도록 허가하는 것은 전체 시스

템이 멎어버리고 완전히 사용불가가 되는 것보다는 낫기 때문이다.

 여기에 대해서 말들이 많지만, 이 모델은 Windows NT 4를 여러번 테스트하면

서 결정된 것이다.

 

***MS-DOS Win16

 

 NT의 성공의 열쇠중 하나는 대부분의 Win3.1 DOS애플리케이션에 대한 지원

이다. NT의 초기 개발 시기에는, 여기에 대한 고려가 많이 이루어졌는데, 

NT가 하위호환성이 없다면 유저들이 업그레이드하기 어려웠을 것이다. 

사 업그레이드를  한다고 해도 부가적인 지출이  생긴다는 뜻이 된다. 그래서

Win16 DOS지원을 결정하게 된 것이다.

 DOS Win16지원은 NT의 강건한 설계 덕분에 쉽게 이뤄졌다.

 이 작업의 목표의 일부는 다음과 같다.

 

   수정 없이 DOS프로그램이 동작되도록 한다.

   Win16애플리케이션들의 대부분이 수정없이 동작하도록 호환성을 제공한다.

   시스템과 기타 Win32 애플리케이션들이 16비트 윈도우 프로그램이나 DOS

   로그램으로부터 간섭받지 않도록 한다.

   Win32애플리케이션과 Win16애플리케이션간에 데이터 공유 메커니즘을 제공

   한다.

 

 많은 사람들은 Win 3.x OS라고 생각한다. 하지만 기술적으로 볼 때 이것은

O/S는 아니고 DOS기반으로 GUI를 제공하는 툴 정도이다.

 그래서,  호환성을  제공하는 첫 번째 방법은 우선 도스 환경을 만드는 것이

된다. NT에서의 도스 환경은 VDM(가상 도스 머신)또는  NTVDM이라고 불리우는

, VDM Win32서브시스템에 서비스를 요청하고 간간히  NT시스템 서비스 계

층에 직접 액세스하는 완전한 32비트 사용자 애플리케이션이다.  이것은  DOS

5.0에 기반했고 그만큼의 호환성을 제공한다.

 NT는 유저가 원하는 만큼 여러개의 도스 애플리케이션을 동작할    있도록

하며, 각각의 애플리케이션들은 독립적인 VDM에서 동작한다. VDM도 다른 프로

그램과 마찬가지로 동작하므로 그것들은 다른 프로그램들과 함께  선점적으로

멀티태스킹된다. 따라서, 윈도우 NT DOS 프로그램들에 대해 선점적인  멀티

태스킹을 지원한다고도 말할 수가 있다.

 VDM  또다른 특징은  620kb이상의 기본메모리를 제공할 수 있다는 것이다.

이것은 DOS환경에 CDROM과 네트웍, 마우스 등의 지원을 윈도우 차원에서 해주

기 때문인데, 즉 도스드라이버가 차지했던 만큼의 프리 메모리가 더 생긴다.

 윈도우 3.x  도스가 제공하는 서비스에 많이 의존했던 것처럼, 윈도우  NT

상의 Win16 서브시스템도 Windows NT VDM에 의존한다.  VDM안에 있는  16비트

윈도우 에뮬레이터는 WOW(Windows on Win32)라고  불린다. 이것이 VDM 안쪽에

존재하기 때문에, 그것은 원래의 Windows 3.x  DOS에게 서비스를  요구했던

것처럼 VDM에게 서비스를 요구하게 된다.  VDM  그리고  나서  이 호출들을

Win32 서브시스템으로 보낸다. Win16 프로그램이 Win16 API 호출을 하면, WOW

서브시스템은 썽킹 이라고 하는 프로세스를 통해 동격의 Win32  API로 그것을

변환한다. 마찬가지로, 해당 Win32 콜에서 생긴 데이터를 Win16 애플리케이션

으로 다시 리턴할 때에도 썽킹이 일어난다.

 썽킹이 필요한 이유는  16비트 데이터 포맷을 32비트로(또는 반대로) 변환하

는 룰이 필요하기 때문이다.  16비트에서  32비트로 가는 것은 0만 더 넣으면

되니 간단하지만, 반대의 상황일 때에는 데이터가 잘릴 수도 있다.

 윈도우 3.X가 공유 메모리 모델을 사용하기 때문에,  많은 프로그램들은 

공유 주소 모델을 기대하거나 요구한다. 이런 프로그램과의 호환성을  증대시

키기 위해, 모든 16비트 윈도 애플리케이션들은 한 개의 VDM상에서 수행된다.

 WOW 서브시스템은 멀티스레드 형식이 아니며, 16비트 윈도우 애플리케이션들

자체가 협력형 멀티태스킹을 하기 때문에, 그 프로그램들은 실제 윈도우 3.x

시스템 상에 있는 것과 비슷하게 동작하게 된다.

 보통  NT커넬은 우선 순위에 기인하여 스케줄링을 한다.  동작중인 쓰레드가

선점되면, 커넬은 우선순위에 따라 다음 쓰레드에 제어를 넘긴다. 커넬은 WOW

쓰레드는 다르게 취급한다. 커넬이 현재 동작중인 WOW 쓰레드를 선점하면,

것은 평소처럼 다른 쓰레드를 실행할 것이다. 그러나, 그것은 이 WOW  쓰레드

가 제어권을 포기할 때까지는 다른 어떤 WOW쓰레드에 대한 실행도 스케쥴링하

지 않을 것이다.  WOW가 실제로 여러개의 쓰레드를 갖고 있지만, 그것들이

실제로 이용되지는 않는다.  이것은 윈도우 3.x와의 호환성을 위해 꼭 필요한

일이다.

 또한, WOW상의 모든 애플리케이션이 동일한 하나의 메모리를 공유하기  때문

, 하나의 Win16 애플리케이션이 크래시되면 모든 16비트 윈도우 애플리케이

션들이 멎게 된다. 그러나,  그것은 시스템 자체 또는 기타 Win32 프로그램에

영향을 미치지는 못한다.

 DOS와 윈3.X 애플리케이션들이 인텔 어셈블리 코드를 많이 이용하기 때문에,

인텔이 아닌 다른 플랫폼에서 이들을 실행하는 것은 무척 까다롭다.  그러나,

Insignia Solution(SoftWindows for Macintosh를 제작한 회사)이란  회사에서

만든 인텔 에뮬레이션 루틴에 의해 번역되면 실행이 가능하다.

 4.0 이전 버전 NT에서는 에뮬레이션 수준이 286 정도였지만, 지금은 486모드

까지 완벽 지원한다.

 

 

 

 

***OS/2

 

 윈도우 NT는 원래 OS/2의 다음 버전 격이 된다.  따라서 처음에는 텍스트 기

반 프로그램은 물론 GUI환경의 OS/2프로그램까지 지원하려고 했었으나 윈도우

환경의 대중화로 인해 GUI 애플리케이션은 지원하지 않게 되었다.

 

***POSIX

 

 POSIX서브시스템은 Unix계열의 표준화된 서브시스템의 일종이다. 그러나 

원만 할 뿐 실제로 이것을 사용하는 서브시스템은 본 적이 없다. 즉 중요하다

고 생각되지 않으므로 과감하게 생략하도록 하겠다.

 

 

 

 

번호 제목 글쓴이 날짜 조회 수
57 특정폴더 자동으로 백업하기 호스트웨이 2012.11.29 4598
56 윈도우 네트워크 드라이브 연결 호스트웨이 2012.11.29 4625
55 Windows Server 기본 관리 공유 제거 file 호스트웨이 2012.11.30 2465
54 메모리 관리 용어 정리 - Part 1 호스트웨이 2012.11.30 901
53 메모리 관리 용어 정리 - Part 2 호스트웨이 2012.11.30 1542
52 메모리 관리 용어 정리 - Part 3 호스트웨이 2012.11.30 3895
51 메모리 관리 용어 정리 - Part 4 호스트웨이 2012.11.30 3189
50 메모리 관리 용어 정리 - Part 5 호스트웨이 2012.11.30 1979
49 Windows NT 아키텍처 - Part 1 호스트웨이 2012.11.30 1480
48 Windows NT 아키텍처 - Part 2 호스트웨이 2012.11.30 1987
47 Windows NT 아키텍처 - Part 3 호스트웨이 2012.11.30 1455
46 Windows NT 아키텍처 - Part 4 호스트웨이 2012.11.30 702
» Windows NT 아키텍처 - Part 5 호스트웨이 2012.11.30 1487
44 리소스 부족으로 프린터 작업을 계속할 수 없습니다 호스트웨이 2012.11.30 10455
43 MBR 과 GPT 호스트웨이 2012.12.01 2336
42 전송속도 규격 호스트웨이 2012.12.01 1919
41 Wbamin 을 통하여 스냅샷이 삭제 불가 시 공간확보를 위해 vssadmin 을 이용하여 vss 삭제 호스트웨이 2012.12.01 982
40 한/영 키 변환 불가 시 호스트웨이 2012.12.01 2766
39 outlook 2010 첨부파일 용량제한 해제 호스트웨이 2012.12.01 3223
38 아웃룩 첨부파일 차단 해제 file 호스트웨이 2012.12.01 2518