| [ HYU ] in KIDS 글 쓴 이(By): jpu (류 정 필) 날 짜 (Date): 1995년12월22일(금) 21시43분37초 KST 제 목(Title): Win95 vs OS/2 워프 비교 어나니 보드의 두 OS의 논쟁을 종식시키기 위해서... HYU보드의 애용자에게 양해를 구합니다. 글이 길므로 갈무리해서 보세요. 제 목 : [강좌] Win95 vs OS/2 워프(pc-line 기사) ## 이글은 PC-line의 10월호에 실린글입니다. 제목 : [윈도우즈95 빛과 그림자] 제14부-윈95 vs OS/S 워프 출판년월 : 95년 10월 윈도우즈95 빛과 그림자 (제14부)윈95 vs OS/S 워프 마이크로소프트사의 윈도우즈95 발표는 도스/윈도우즈 3.1에 머물러 있던 많은 다수의 PC사용자들에게, 새로운 패러다임을 받아들일 시기가 왔음을 말해주고 있다. 현재 PC 시장은 펜티엄이 주기종으로 자리잡고 있지만, 그 시스템의 성능을 충분히 활용하지 못해온 것이 현실이었다. 여기서는 OS/2 워프가 윈도우즈95와 비교해서 겉으로 쉽게 드러나지 않는 장점을 알아보고, 그 차이점이 시스템에 어떤 영향을 주는지 알아 보려고 한다. 그러나, 가정에서 간단한 문서작성과 PC 통신이 PC 활용의 전부인 이들에게 32비트 운영체제는 과소비라는 주장도 어느 정도 타당하다. 이 글은 32비트 운영체제로서 먼저 출시된 OS/2 워프와 강력한 후발 주 자인 윈도우즈95 사이에서 선택의 갈등으로 고민하는 이들에게 보다 정 확한 차이점을 보여주려는 것이 목적이다. 대다수의 PC 사용자가 32비 트 운영체제를 써야하는 당위성을 주장하려는 의도가 아니다. 더불어, 어떤 운영체제를 다른 것과 비교한다는 것이 사과와 오렌지 를 비교하는 것과 같이 모호한 부분도 있다. 따라서, 이 글은 필자의 주관적, 객관적인 판단에 근거해서 작성하기보다 외국에서 비교적 공신 력 있다고 여겨지는 PC Magazine, PC Computing, LAN Magazine 및 IBM 이 제시하는 문헌들을 참고하고 정리하는 형식으로 내용을 전개한다. 그러나, 현존하는 많은 외국 자료들도 같은 문제를 놓고 서로 상이 한 결론이나 데이터를 제시하는 경우도 적지 않다. 이런 자료들이 언급 되는 것을 피하기 위해서 될 수 있으면 널리 받아들여지는 이론이나 뚜 렷한 이유가 제시되는 내용에 대해서만 언급하기로 한다. 이 글에서 다뤄질 내용들 깊은 산골에 연락을 끊고 칩거 생활을 하는 독자가 아니라면, 여러 매체를 통해 윈도우즈95와 OS/2 워프에 대해서 적어도 한 번은 들어본 기억이 있을 것이다. 이 둘은 모두 32비트 운영체제로서, 마이크로소프 트사의 솔루션은 널리 알려진 윈도우즈 3.11 운영체제 환경을 기반으로 하고 있다. 여기서는 이 두 32비트 운영체제를 크게 아키텍처, 사용자 인터페이 스, 응용 프로그램 지원 등으로 나눠 비교하고자 한다. 이 글을 통해, 윈도우즈 3.1과 윈도우즈95에서는 불가능한 애플리케이션을 서로 보호 하기 위해 각각의 16비트 윈도우즈 응용프로그램을 분리시켜 자신의 고 유한 VDM을 제공하는 OS/2 기능의 중요성을 파헤쳐 본다. 그리고 이들 분리 세션은 결국 기존의 16비트 윈도우즈 응용 프로그램이 32비트 응 용 프로그램의 성능에 영향을 주지 않고 선점형 다중작업을 하게끔 해 준다는 사실을 아키텍처 부분에서 살펴볼 것이다. 그리고 OS/2의 가상도스머신(VDM)이 윈도우즈95보다 융통성이 있는 이유와, 이것이 기존의 도스와 16비트 윈도우즈 응용 프로그램을 사용 하는데 있어서 어떤 영향을 주는지 보여줄 것이다. 또한 사용자 인터페이스 측면에서 OS/2의 시스템 오브젝트 모델 (System Object Model, SOM)이 왜 중요한 지, 객체지향의 사용자 인터 페이스에서 워크플레이스 셸 인터페이스의 아교풀과 같은 SOM의 역할이 사용자에게 어떤 커다란 영향을 주는 지 살펴본다. 이런 내용을 통해 주로 다룰 내용은 16비트 윈도우즈 응용프로그램 을 실행할 때 윈도우즈95가 타협할 수밖에 없는 구조상의 문제와 그런 문제가 32비트 응용 프로그램과 기존의 도스 또는 윈도우즈16 응용 프 로그램과 함께 사용할 경우 윈도우즈95의 다중작업 기능을 제한한다는 사실, 윈도우즈95 인터페이스에 SOM과 같은 기반이 없다는 점이 낳는 한계점, 그리고 윈도우즈95가 16비트 도스 디바이스 드라이버를 다룰 때의 유연성 결여 등을 함께 언급한다. 이로써 OS/2가 현존하는 도스/ 윈도우즈 3.1 프로그램에 대한 투자를 보호하기 위해 현명한 선택임을 이해할 수 있을 것이다. 마지막 부분에서는 윈도우즈95와 32비트 운영체제의 선두주자격인 OS/2 간의 특정 서브 시스템 또는 특징/기능 등을 표를 통해 직접적으 로 비교해 본다. 앞서 언급했듯이 이 글의 내용은 기밀자료가 아니며 현재 여러 서적을 통해 공개된 문서들을 바탕으로 하고 있음을 다시 한 번 밝힌다. 어째서 OS/2인가? 어째서 OS/2인가? 왜냐하면 오늘날의 PC 사용자에게 가장 현명한 업 그레이드 길을 제시해주기 때문이다. OS/2는 16비트 도스와 윈도우즈 3.1 응용 프로그램에을 보호하면서 새로운 32비트 객체지향기술로의 길 을 열어준다. OS/2는 기존 환경과의 호환성과 32비트 프로세싱 파워, 사용의 용이 함과 더불어 운영체제의 견고성을 자랑하는데, 이는 OS/2 워프 V3가 이 미 3세대에 들어섰기 때문이다. 그러면 윈도우즈95는 어떠한가? 윈도우즈95가 16비트와 32비트 애플리케이션을 모두 실행시킬 수 있 지만, 마이크로소프트는 사용자가 32비트로 향하길 바라고 있다. 윈도 우즈95는 16비트 코드에 상당히 의존하고 있는데, 32비트 응용 프로그 램이 실행될 때에도 마찬가지이다. 물론 마이크로소프트에서도 윈도우즈95가 완전한 32비트 운영체제가 아니라는 점은 솔직히 인정하고 있다. 윈도우즈95에서 실행되는 Win32 응용 프로그램은 상당 시간을 16비트 USER (윈도우 관리와 메세지)와 GDI(그래픽) 모듈에서 소모하고 있다. 이런 점에서 32비트 응용 프로그 램을 실행하는데 있어서 윈도우즈95가 충분히 그 장점을 발휘할지 의문 이 생긴다. 윈도우즈95는 95년 8월에 태어난 1세대 운영체제란 점에서도 안정성 측면에서 미래를 좀 더 두고 볼 필요가 있다. 운영체제 구조의 차이 구조적인 면에서 윈도우즈95와 OS/2 워프는 OS 스펙트럼의 양 끝단 을 차지한다. 애초부터 IBM은 많은 다중작업을 염두에 두고 OS/2를 설 계했다. OS/2에서 모든 구성요소는 입출력 서브 시스템에서 메모리 관 리 루틴까지, 동시에 여러 응용 프로그램이 항상 그들의 서비스를 위해 경쟁한다는 가능성을 염두에 두고 만들어졌다. 재진입(reentrancy) 같 은 개념들은 OS/2 전체 구조의 기본으로 코드의 아키텍처 일부가 하나 이상의 프로그램으로 하여금 동시에 실행하게끔 해준다. 한마디로 OS/2 는 다중처리를 위해 태어났다고 할 수 있다. 반면에 윈도우즈95는 윈도우즈 3.1의 직속 후계자로서, 선친의 많은 문제를 그대로 가져왔다. 마이크로소프트는 윈도우즈를 원래 도스의 그 래픽 확장자로서 설계했다. 초기 버전인 윈도우즈 2.0은 리얼모드 도스 응용 프로그램으로, 단순하고 단일 쓰레드(thread)의 응용 프로그램을 실행하기 위해서 컨벤셔널 메모리(conventional memory)와 EMS(Expanded Memory Specification)를 함께 사용했다. 그러나, 초기 구조였기 때문에 말할 필요도 없이 대부분 시장에서는 받아들여지지 못 했다. 1990년에 윈도우즈 3.0이 발표되면서 마이크로소프트는 16비트 보호 모드로 상당수의 코드를 포팅함으로써 윈도우즈의 기능을 향상시키려고 했다. 그 아이디어는 설계에 대한 주요한 불만 중 하나로서, 보호 모드 를 필요로 하는 확장 메모리(Extended Memory) 액세스를 가능하게 해줌 으로써 윈도우즈를 보다 매력적인 개발 플랫폼으로 만들었다. 보호 모 드로의 이주는 응용 프로그램에게 더 많은 메모리를 보장해주며, 개발 자에게는 보다 복잡하고 큰 프로그램을 만들도록 해준다는 것을 의미한 다. 마이크로소프트의 응용 프로그램인 엑셀이나 워드와 같이 대중적인 프로그램이 나옴으로써 그 전략은 먹혀들어갔다. 많은 ISV(Independent Software Vendor)들은 윈도우즈로 모여들었고, 어쨌던 새로운 운영체제 의 아이디어에 민감한 시장에서 그 매력이 증명되었다. 초기 OS/2 버전 이 여러 가지 이유로 상대적으로 고전하는 동안, 윈도우즈 3.0과 3.1은 빈 자리를 채웠다. 그러나, 윈도우즈 3.0의 보호 모드로 이주하면서 마이크로소프트는 늘 따라다니는 문제를 해결하기 위해 계속 설계를 변경해야 했다. 그중 하나가 선점형 다중작업 위에서 리얼 모드의 윈도우즈 응용 프로그램과 의 호환성을 부여하려한 점이다. OS/2와 같이 각각의 응용 프로그램들 을 각각의 고유한 주소 공간에 분리시키는 대신, 마이크로소프트는 그 들을 모두 하나의 16비트 가상머신(System VM)에 몰아 넣었다. 여기서 이들은 CPU 시간과 메모리 리소스를 운영체제 코드 자체와 함께 나누는 데, 윈도우즈 3.xx에서 운영체제와 응용 프로그램은 동일한 메모리 공 간을 사용한다. 이러한 절충 구조가 응용 프로그램 개발자들에게 리얼 모드에서 보 호 모드로 전환을 쉽게 해주긴 했지만, 운영체제로 하여금 프로그램들 을 효율적으로 다중작업하는 것을 불가능하게 만들었다. 인텔 CPU 구조 상에서 선호되는 테크닉인 선점형 다중작업은 각각의 프로그램이 각자 고유의 어드레스 공간에 존재할 필요가 있다. 윈도우즈의 싱글 가상머 신 모델은 이것을 허용하지 않았고, 따라서 응용 프로그램들이 서로 경 쟁을 해야만 했는데, 진정한 선점형 시스템에서는 싱글 애플리케이션의 프로세서 시간 분할이 일반적인 형태이다. 마이크로소프트는 하는 수 없이 응용 프로그램 개발자들이 이따금 CPU의 컨트롤을 양보해 다른 프로그램들이 실행될 수 있도록 허락했다. 이러한 수정이 오늘날 '협동형 다중작업(cooperative multitasking)'과 윈도우즈 아래에서 실행 시간에 민감한(time-critical) 응용 프로그램 을 만드려는 개발자의 생활을 비참하게 만들었다. 따라서 협동형 시스 템인 윈도우즈에서는 현재 실행중인 프로그램이 프로세서의 컨트롤을 마칠 때까지, 어느 특정 응용 프로그램에 CPU 시간을 보장할 수가 없 다. 초기의 OS/2 설계 단계에서, IBM은 각각의 응용 프로그램이 각각의 고유한 주소 영역(가상머신)에 분리되게끔 만들어서 이러한 제한을 피 하기로 결정했다. 이러한 실행방법은 운영체제로 하여금 CPU의 궁극적 인 컨트롤을 가지게 함으로써, 처리 시간에 민감한 프로그램에게 추가 의 처리 시간을 줄 수 있도록 했다. 그림 1. 윈도우즈95의 시스템 아키텍처 OS/2에서 각각의 가상머신이 서로 다른 어드레스 영역을 사용하는 장점이, 가상머신 사이의 데이터 교환을 불가능하게 하는 것이 아닌지 궁금해 하는 사람이 있을 것이다. 그러나 32비트 그리고 16비트 OS/2 응용 프로그램들은 서로 독립된 가상머신에서 선점형 다중작업을 수행 할 수 있을 뿐 아니라, OS/2의 DDE를 통해서 서로 통신이 가능하다. 마 찬가지로 도스와 Win16 응용 프로그램은 독립된 다중작업을 하는 가상 머신에 분리되어 실행될 수 있다. 이때 분리된 세션의 Win16 응용 프로 그램들은 서로 완전한 DDE와 OLE 2.0 연결을 유지할 수 있고, 32비트 OS/2 응용 프로그램과 DDE 연결을 유지할 수 있다. 윈도우즈95는 Win32 응용 프로그램에서만 선점형 다중 작업 실제로 윈도우즈 95는 Win32 응용 프로그램에서만 제대로된 다중 작 업을 지원한다. 마이크로소프트는 윈도우즈95에서 원래의 싱글 가상머 신 윈도우 디자인 꼭대기에 선점형 다중작업을 접목시켰다. 이것으로 인해 소프트웨어 개발자들은 32비트 프로그램을 개발해야 했다. 왜냐하 면 Win32 응용 프로그램이 기존의 시스템 가상머신 모델을 붕괴시키지 않은 채 그들 고유의 가상머신을 가질 수 있기 때문이다. 그림 2. OS/2 워프의 아키텍처 불행히도, 윈도우즈95에서 이들 응용 프로그램들은 여전히 윈도우 그리기와 비트맵 관리와 같은 기본적인 서비스를 위해 여전히 운영체제 를 호출해야만 한다. 그리고 이들 기능들은 대부분 시스템 가상머신에 존재하는 16비트 코드에 의해서 처리된다. 윈도우즈95는 인텔 x86 CPU의 4개의 링(ring) 보호 모델 중에서 2개 의 링(ring)을 사용한다(그림 2 참조). 링3는 응용 프로그램과 운영체 제 서비스를 제공하는 DLL(Dynamic Link Libraries)이 위치하며, 링0는 운영체제의 로우레벨 구성요소가 위치한다. 이러한 배열은 윈도우즈3.1 과 비슷하며 중요한 운영체제 구성요소를 응용 프로그램과 분리시켰다. 이는 운영체제 영역의 메모리에 쓰기가 가능해 운영체제 자체를 다운시 킬 수 있는 도스 환경보다 훨씬 안정된 환경을 제공한다. 링3는 응용 프로그램이 실행되는 가상머신들의 주인 노릇을 한다. 윈도우즈 3.1을 위해 개발된 16비트 프로그램을 포함하여 모든 윈도우즈 응용 프로그램 들은 시스템 가상 머신(system VM)에서 실행되고, 도스 응용 프로그램 들은 가상 도스머신(VDM)이라 불리는 다른 VM에서 실행된다. 가상 머신 들은 하나의 VM에서 실행되는 응용 프로그램이 다른 VM에서 실행되는 응용 프로그램을 보거나 이들 다른 주소 영역에 쓰기가 금지된다. 응용 프로그램 입장에서 다른 VM에서 실행되는 프로세스는 다른 PC에서 실행 되는 것과 마찬가지이다. 이론적으로 도스 프로그램이 코드나 데이터로 윈도우즈95를 다운시키는 것은 불가능하다. 그러나, 실제로는 도스 프 로그램이 시스템을 다운시키는 것이 간단한데, 모든 VM에서 공유되는 어떤 메모리 영역이 있기 때문이다. 16비트 모델에 의존하는 이런 32비트 디자인(보통 thunking이라고 말하는)은 결과적으로 시스템 가상머신 안의 16비트의 재진입이 안되는 (non-reentrant) 싱글-쓰레드 윈도우즈 3.1 코드가 응용 프로그램을 효 율적으로 다중작업하는 운영체제의 능력을 저해하는 병목현상을 야기시 킨다. 썽킹(thunking)은 32비트 코드가 16비트 코드의 호출이나 그 반대, 그리고 호출에 동반되는 파라미터를 번역하는 메커니즘을 말한다. 편리 해 보이는 이 메커니즘은 Win32 응용 프로그램에 의해 만들어진 호출의 얼마는 16비트로 썽크다운(thunk down)되어야만 하는데, OS/2의 경우에 는 이런 문제가 없다. 마이크로소프트의 프로그래머들은 이러한 썽크 메커니즘을 빠르게 하려고 많은 노력을 기울이고 있지만, 썽킹은 어쩔 수 없이 시간이 걸리기 마련이다. Win32 응용 프로그램들은 운영체제 커널(kernel)의 16/32비트 구획 때문에 어쩔 수 없이 얼마간 속도 저하 가 생긴다. 또한, 16비트와 32비트 운영체제를 동시에 실행시키는 윈도우즈95의 이런 디자인은 커널의 16비트 코드가 재진입불가능(non-reentrant)이기 때문에 문제를 야기시킨다. 이는 두개의 쓰레드가 시스템을 다운시키는 위험을 감수하지 않고는 동시에 억세스할 수 없다는 의미이다. 선점형 이 아닌 윈도우즈 3.1에서는 별로 문제가 안되었지만, 선점형의 윈도우 즈95는 어떤 쓰레드도 실행도중 인터럽트될 수 있다는 문제가 있다. 마이크로소프트는 이 문제를 해결하기 위해 Win16Mutex를 고안해냈 다. mutex는 다른 쓰레드가 16비트 커널의 코드를 실행시킬 때 그곳으 로부터 떨어지도록 다른 쓰레드에게 경고하는 플래그(flag)이다. 16비 트 측을 가로지르는 Win32 쓰레드는 만약 플래그가 올라간 상태이면 동 작을 중지해야 한다. Win32 쓰레드는 이 플래그를 16비트 커널에 들어 갈 때와 나올 때만 세팅한다. 그러나, Win16 프로세스에 속한 쓰레드는 자신들이 활성화(active) 상태인 동안 내내 이 플래그를 세팅한다. 그 결과는 Win32 응용 프로그램들은 Win16 응용 프로그램이 실행될 때 반 응 시간이 느려진다는 점이다. 또한 다운된 Win16은 Win32를 중단시킬 수 있게 된다. OS/2의 경우에는 이것이 CPU 시간을 소모한다는 것 이외 에는 아무런 영향을 주지 않는다는 측면에서 윈도우즈95와 다르다. 윈도우즈95는 여전히 16비트 도스 데이터 구조를 가지고 있고, 16비 트 도스 코드를 실행하기 위해서 V86 모드로 스위치 되어야 한다. 또 한, 모든 하드웨어의 디바이스 드라이버가 윈도우즈95 버전으로 나올 때까지 16비트 리얼모드 코드를 써야만 한다. 이런 모든 문제들이 시스 템 성능의 저하와 Win32 프로그램의 실행에 문제를 야기할 수 있다는 점을 고려해야 한다. 윈도우즈95의 응용 프로그램은 16비트 코드 구조에 의존한다 윈도우즈 95에서 16비트 그리고 32비트 응용프로그램들은 윈도우즈 3.1에서 유래된 시스템 VM 코드에서 존재하는 16비트 코드 구조에 의존 한다. 모든 Win16 프로그램들은 하나의 공통 어드레스 공간에서 실행되 며, 협동형 다중작업을 한다. USER, USER32, GDI, GDI32, KERNEL 그리 고 KERNEL32 같은 DLL은 모든 윈도우즈 프로그램들에게 운영시스템 서 비스를 제공하는데, 시스템 가상머신(system VM)에 로드되고 각각의 프 로세스의 주소공간으로 매핑된다. 이는 시스템 서비스가 호출될 때 링 (ring) 전환에 필요한 시간을 줄여서 성능을 향상시킬 수 있지만, 운영 체제가 응용 프로그램들에게 노출됨으로써 시스템 안정성을 위협할 수 있다. 가상도스머신(VDM)은 도스 프로그램들이 실행되는 곳으로 이들은 선점형 다중작업을 한다. 따라서, 윈도우즈95 구조가 빠른 컴퓨터에서 적당한 다중작업에는 적합하지만, 다수의 다중 쓰레드 응용 프로그램이 돌아가는 환경 아래 서는 문제가 발생하기 시작한다. 이런 상황은 16비트 윈도우즈 3.1 응 용 프로그램이 실행될 때 더 가능성이 높아지는데, 16비트 응용 프로그 램이 실행되는 한, 윈도우즈95 환경은 협동형 다중작업으로 되돌아가야 만 하기 때문이다. 그림 3. 윈도우즈95 시스템 DLL 사용자 인터페이스 비교 미(美)는 단지 껍데기에 지나지 않는다는 말이 있다. 윈도우즈95에 서 셸에 해당하는 말이다. 마이크로소프트는 진정한 객체지향 사용자 인터페이스를 만드는 대신, 기초가 되는 지지 구조에 변화없이 새로운 기능들을 첨가해 기존의 윈도우즈 셸 구성을 치장하는 방식을 택했다. 윈도우즈95는 객체지향 인터페이스가 아니다 OS/2 워크플레이스 셸은 근간이 되는 SOM에 의해 진정한 객체지향 인터페이스를 제공한다. 그러나 윈도우즈95는 SOM에 비교되는 아무것도 가지지 않으며 객체 지향 인터페이스가 아니다. SOM은 OS/2 워프의 객 체지향 기능의 근간이 되며, 워크플레이스 셸 기능 전부가 제대로 작동 하게끔 해주는 비밀공작 활동에 그 기능을 비유할 수 있다. 워크플레이 스 셸 데스크탑 위의 오브젝트를 다룰 때, SOM은 거기서 작동이 적절히 번역되고 있는지 그리고 그 결과는 객체지향 반응의 기정 지침서를 따 르는지 확인하는 기능을 백그라운드에서 수행한다. 단순히 OS/2 워프를 잠시 사용해보는 것만으로 SOM의 기능을 눈으로 확인할 수 있다. 데스크탑을 가로질러 오브젝트를 끌고 갈 때, SOM은 그 움직임을 추적하고 오브젝트의 새로운 위치를 기록한다. 구체적으로 폴더 간에 오브젝트를 이동하는 경우, SOM은 오브젝트의 위치상 변화를 알아차린다. 문서를 프린터 아이콘으로 끌고가면, SOM은 관련 응용 프 로그램의 인쇄 코드를 시작하게 함으로써, 프린터 요구 서비스를 하게 끔 한다. 모든 이런 오브젝트 추적과 감시는 워크플레이스 셸의 구조에서 매 우 중요한 부분이다. 워크플레이스 셸로 하여금 사용자 인터페이스 환 경을 그렇게 강력하게 만들어주는 SOM이 없다면, OS/2 워프는 인쇄, 그 림자 오브젝트, 템플리트와 같이 많은 수의 복잡한 오브젝트 상호작용 을 관리할 수 없을 것이다. 포괄적인 SOM의 장점은 이제 분명하다, 윈도우즈95 인터페이스의 결 함은, SOM을 가지고 있지 않다로 요약할 수 있다. 윈도우즈95는 OS/2의 SOM과 비교되는 아무것도 가지고 있지 않다. 독자들은 OLE 2.0을 머리 속에 떠올리겠지만, 윈도우즈95 데스크탑 자 체는 OLE 2.0 오브젝트가 아니다. 전체 인터페이스는 정적인 그래픽 이 미지와 .INI(윈도우즈 응용 프로그램의 경우) 그리고 .PIF(도스 응용 프로그램의 경우) 파일들에 근거한다. 사용자의 눈을 즐겁게 해주긴 하 지만 단지 그것뿐이다. 윈도우즈95의 구이는 정적이다 각각의 오브젝트에 대한 링크가 자동으로 갱신되는 진정한 객체 지 향형 환경인 OS/2와 달라 윈도우즈95는 구이(GUI)는 정적이며 데스크탑 의 오브젝트는 단순히 디스크상의 파일에 대한 포인터에 불과하다. SOM의 위력이 OS/2 워프와 워크플레이스 셸과 작동할 때 분명해지는 것처럼, 윈도우즈95의 사용자 인터페이스는 간단한 시스템 운용 작업을 수행해보면 단점이 드러난다. 예를 들면, 윈도우즈95와 OS/2 워프는 모 두 오브젝트 앨리아스 형태를 지원하거나, 오브젝트에 대한 레퍼런스를 만들 수 있으며, 이 레퍼런스는 시스템 어디에나 둘 수 있다. OS/2는 이들 그림자(shadow)를 호출하지만, 반면에 윈도우즈95는 이들을 최단 경로로 호출한다. 그러나 이름이 무엇이건 간에, OS/2만이 어떤 스트레 스 아래에서도 끊어지지 않는 융통성 있는 방식으로 그 개념을 확실하 게 실제로 수행한다. 윈도우즈95 아래서, 그러한 지름길(shortcut)은 기초를 이루는 파일 시스템에서 끌어낸 패스 정보에 근거한 동적이 아닌 정적 연결일 뿐이 다. 예를 들면, 원래 오브젝트의 아이콘을 끌어다가 새로운 폴더에 넣 어보면 연결이 끊어진다. 이러한 제한은 연결이 정적이고 단지 패스 정 보에 근거한다는 데 기인한다. 그러한 모델은 연결 자체의 유연하지 못 한 성질 때문에 원래 깨지기 쉬운 것이다. 지름길은 원본이 같은 장소 에 계속 있다는 가정에 기초한다. 신뢰성을 높이기 위해, 윈도우즈95는 원본이 마지막에 위치했던 디 스크 볼륨에서 비슷한 크기와 날짜 스탬프가 찍힌 파일을 검색하여 끊 어진 지름길을 수리하는 일을 어느 정도 훌륭하게 해낸다. 그러나, 이 러한 디스크 검색이 원래 볼륨에 제한되기 때문에, 항상 정확한 파일 위치를 찾아내지는 못하며 오브젝트가 다른 디스크나 네트워크 드라이 브로 이동했을 때 완전히 실패하게 된다. 화면 1. 디스크 볼륨을 뒤져 비슷한 파일을 겸색한 결과의 다이알로 그 화면 (NOTOOP.GIF) 그러면, OS/2 워프는 그런 상황을 어떻게 처리하는가? 그럴 필요가 없다. 왜냐하면 SOM이 원본과 원본의 그림자 사이의 링크를 동적으로 추적하기 때문이다. 윈도우즈95가 원본을 찾고 그 위치에 대한 가능한 정확한 추측을 해야하는 반면에, OS/2 워프는 우선 그 관계를 절대로 끊어지지 않게끔 관리한다. 화면 2, 윈도우즈95는 모든 디바이스 드라이버를 각각의 도스 세션 의 하위 메모리에 로드한다.(MULDOS.PCX) 응용 프로그램 지원 이제 응용 프로그램 지원 차원에서 윈도우즈95와 OS/2의 차이를 비 교해 보자. 앞서 말했지만, OS/2 워프와 윈도우즈95는 32비트 응용 프 로그램들을 그들 고유의 분리된 어드레스 공간 또는 가상머신에서 실행 시킨다. 이것은, 윈도우즈95에서는 약간의 제한은 있지만, 도스 프로그 램 실행에 필요한 도스 디바이스 드라이버를 CONFIG.SYS에서 지정할 필 요가 있다. 그러나, 이들 드라이버는 모든 가상도스머신(VDM)에 로드되 어, 컨벤셔널 메모리의 사용가능한 메모리를 불필요하게 감소시킨다. 반면에 OS/2는 세팅 노트북을 통해서 사용자가 필요한 가상 도스머신에 만 이들을 동적으로 로딩할 수 있게끔 해준다. 그러나 두 운영체제의 가장 큰 차이점은 16비트 윈도우즈 응용 프로 그램 수행 처리 방식에 있다. OS/2 워프는 가상 도스머신(VDM)을 만들 어서, 윈도우즈 응용 프로그램을 마치 도스 응용 프로그램처럼 처리한 다. 다음 OS/2는 윈도우즈의 런타임 복사본과 응용 프로그램 자체를 VDM으로 로드하고, WIN-OS2 세션이라고 불리는 합체를 만들어낸다. OS/2는 많은 수의 이들 WIN-OS2 세션을 만들 수 있고, 16비트 윈도우즈 응용 프로그램은 싱글 VDM을 공유하던지, 각각의 응용 프로그램을 그들 만의 고유한 VDM으로 격리시킬 수 있다. 후자 옵션이 OS/2의 윈도우즈에 관련된 주요 장점 중 하나이다. 각 각의 응용 프로그램을 그들만의 고유한 VDM으로 분리시킴으로써, OS/2 는 윈도우즈의 싱글 시스템 가상머신 모델에서는 불가능한 응용 프로그 램간의 보호를 가능하게 해준다. 게다가, OS/2는 이들 응용 프로그램들 을 선점형 방식으로 다중 작업을 할 수 있는데, 각각의 VDM은 그들의 고유 어드레스 공간과 그들만의 CPU 시분할을 가지기 때문이다. 윈도우즈95는 진정한 선점현 다중작업 운영체제 아니다 OS/2는 애초부터 진정한 선점형 다중작업 운영체제로 도스, Win16, OS/2 응용 프로그램들을 혼합해서 실행되도 선점형 다중 작업이 유지되 지만 윈도우즈 95는 그렇지 못하다. 윈도우즈95는 윈도우즈 3.xx로부터 여러 제한 사항과 싱글 시스템 가상머신을 그대로 물려받았다. 모든 16비트 윈도우즈 응용 프로그램들 은 윈도우즈 3.xx와 마찬가지로 같은 어드레스 공간에서 수행된다. 따 라서 어떤 하나의 응용 프로그램의 정지는 도미노와 같은 효과를 만들 어, 시스템 가상머신 안에 다른 모든 응용 프로그램을 시스템 폭주시켜 버린다. 설상가상으로, 윈도우즈 3.xx 원래 디자인은 싱글 가상머신의 OS 코 드에 모든 실행 응용 프로그램이 모든 실행 프로그램들의 코드와 함께 들어있다. 윈도우즈95는 중요한 시스템 서비스를 위해 계속해서 이 코 드에 의존하여, 다른 응용 프로그램들을 중지시키는 것은 물론이고, 어 떤 하나의 응용 프로그램이 전체 운영체제를 중지시킬 가능성도 있는 셈이다. 윈도우즈 3.xx에서 general protection fault(GPF)를 경험해본 사람이라면, 이 문제가 일어날지 모르는 어떤 것이 아니라, 실제 일어 나기도 한다는 것을 알 것이다. 이 GPF는 윈도우즈95에도 여전히 살아 있는 셈이다. 윈도우즈95의 싱글 시스템 가상머신 모델에 대한 의존성의 또 다른 파급효과는 16비트 응용 프로그램들의 협동형 다중작업을 극복할 수 없 다는 사실이다. 이들은 여전히 시스템 가상머신에 함께 들어있기 때문 에, 윈도우즈95가 경우는 OS/2의 WIN-OS2 분리 세션과 달리 이들에게 각각의 시간 간격을 할당할 방법이 없다. 따라서, 문제가 있는 응용 프 로그램이 CPU 컨트롤을 놓아주지 않는다면 여러분의 인생은 여러 가지 문제를 안겨줄 것이다. 표 1. 윈도우즈95에서 응용 프로그램에 따른 다중작업의 형태 응응 프로그램의 형태 다중작업의 형태 Win32 선점형(Preemptive) WIn16 협동형(Cooperative) Win16과 Win32가 함께 실행 반선점형(Semi-Preemtive) 이러한 윈도우즈95의 제한을 극복하기 위해서, 마이크로소프트는 사 용자들이 모두 32비트 응용 프로그램을 사주길 바라는 것으로 보인다. 윈도우즈95의 발표와 발맞춰 많은 Win32 프로그램들이 함께 발표되 고 있다. 그러나, 이런 현실의 이면을 생각해볼 필요가 있다. 바로 API 문제이다. 운영체제의 내부 함수들은 애플리케이션 프로그래밍 인터페이스 (API)를 통해 억세스된다. API는 서브루틴과 같은 프로시져의 집합으 로, 프로그램으로 하여금 파일을 열고, 메모리를 할당하고, 다른 작업 들을 수행한다. 윈도우즈95에서 이들 함수들은 GDI, GDI32, USER, USER32, KERNEL, KERNEL32와 그 밖의 DLL에 의해서 실행된다. API는 운 영체제 구조의 중요한 일부인데, 프로그램들이 어떻게 시스템과 상호대 화를 하는지 정의하기 때문이다. 윈도우즈95는 Win32 API를 사용하는데, 16비트 윈도우즈 3.1의 32비 트 버전이다. 윈도우즈 3.1 응용 프로그램의 윈도우즈95로의 포팅은 어 렵지 않다. 단순한 포팅은 그렇다. 그러나, 윈도우즈95에 새로 첨가된 멀티쓰레드, 메모리맵 파일, 공동 조절 라이브러리와 같은 기능들을 기 존의 Win16 프로그램 포팅에 첨가하는 일은 프로그램 전체 구조에 영향 을 미치며, 재코딩 이상의 작업이 될 수 있다. 따라서, 윈도우즈95의 Win32 프로그램이 32비트 운영체제의 특징을 잘 살린 응용 프로그램들 이 되려면, 시간이 좀 더 필요할 것이다. 윈도우즈95, 좀더 경쟁력 갖춰야 한다 이상의 내용에서 시스템 전체를 비교했을 때 윈도우즈95는 아직 OS/2에 비해 기능상 떨어지는 점이 많다. 운영체제의 안정성 측면에서 도 윈도우즈95의 혼합구조에 비교해 OS/2가 안정적이고, 분리가능한 WIN-OS2 세션이 지원되므로 도스와 윈도우즈에 대한 지원도 융통성 있 고 믿을 만하다. 윈도우즈95의 인터페이스 역시 겉으로만 객체 지향적 이다. 반면 OS/2의 사용자 인터페이스인 워크플레이스 셸은 시스템 오 브젝트 모델(SOM)과 함께 객체지향 컴퓨팅 환경을 제공한다. 마찬가지 로 OS/2의 다중작업 또한 어떤 형태의 응용 프로그램을 함께 사용하더 라도 선점형 다중작업이 가능하게끔 설계됐다. 윈도우즈95가 일반 및 기관 사용자들의 저항에 직면한 것은 OS/2 워 프나 다른 운영체제보다 4~10년 늦게 출시됐으며 다중 작업같은 중요한 핵심 기능은 경쟁 제품보다 뒤떨어져 시스템이 불안정한 현상을 보이기 때문이다. 윈도우즈95가 안고 있는 커다란 문제점으로는 기존의 윈도우즈 3.1 응용 프로그램과의 호환성과 시스템 안정성 문제를 들 수 있다. 그밖에 MSN(Microsoft Network)에 대한 PC통신 서비스 업체의 전세계적인 반발 과, 마이크로소프트사가 PC 운영체제와 MSN을 연계해 정보를 제공하는 것이 불공정 행위에 해당하는지 여부와 윈도우즈95에 내장된 등록 마법 사 프로그램에 의한 정보 유출 가능성 등이 문제이다. 우리 나라 정보 통신부를 비롯해, 미국 국방부, 호주 해군 등 각국 공공기관들은 최근 윈도우즈95에 내장된 MSN를 통한 정보유출 가능성을 우려해 윈도우즈95 의 구매계획을 무기한 유보하고 있다. 그리고 한글을 사용하는 우리의 입장에서 무엇보다 커다란 문제점 은 윈도우즈95의 한글코드 파행 문제이다. 한글 윈도우95는 기존의 완 성형 한글코드인 KSC 5601-1987, 조합형 한글코드인 KSC 5601-1992를 모두 따르지 않고 독자적으로 만든 확장완성형 한글 코드를 채택했다. 확장 완성형은 완성형 한글 코드에서 지원되지 않는 글자들을 짜깁기 형식으로 추가한 통합형 한글 코드이다. 문제는 한글 윈도우95의 통합 형 한글코드는 문자코드 체계의 모든 글자가 순서대로 배열돼야 한다는 원칙을 위배하고 있다. 더군다나, 이 코드를 사용해 작성한 메시지는 통신을 통해 전달된 다른 매킨토시나 유닉스 시스템에서 읽을 수 없는 경우가 생긴다. 매킨토시나 유닉스 기종은 모두 2350자의 완성형 한글 코드만 지원하므로, 이를 제외한 나머지 글자는 읽을 수가 없게 된다. 한글 윈도우즈95의 이러한 한글코드 파행은 프로그램 개발업체에게 응 용 프로그램 개발에 큰 어려움을 줄 수 있다. OS/2 워프가 PC 운영체제에서 마이크로소프트를 막을 수 있을지 회 의적인 의견도 있지만, 이를 위해 OS/2 워프 진영에 가담하는 기업들도 무시할 수 없는 세력을 형성하고 있다. 중국 전자공업청이 공식 운영체 제로 OS/2 워프를 채택했고 일본의 최대기업인 일본전신전화회사(NTT) 와 NEC, 도시바가 OS/2 워프 지원을 공식발표 했다. 특히 일본 NTT는 일본 최대의 클라이언트/서버 구축 프로젝트인 IRIS에 OS/2 워프를 일 반 사용자에게 권장하는 우선 채택 제품으로 선정했다. 아직까지 우리 나라에는 한글 윈도우즈95가 정식 발표되지 않고 있 으며, 필자도 마지막 한글 베타 버전으로 테스트해봤다. 이상에서 지적 한 여러 가지 문제점들이 한글 윈도우즈95에서 어느 정도 향상될 것으 로 기대된다. 짧은 시간에 운영체제의 기본 구조와 같은 사항은 변경을 기대하기 어렵겠지만. 한글 OS/2 워프는 지난 3월에, WIN-OS2 코드를 포함한 풀팩 버전도 이미 발표됐고 한글 OS/2 워프 커넥트(CONNECT)도 조만간 발표될 예정 이다. OS/2 워프와 윈도우즈95의 성능 비교 차트 OS/2 워프 vs. 윈도우즈95 아키텍처 -------------------------------------------------------------------------- 기능 OS/2 워프 윈도우즈95 -------------------------------------------------------------------------- 32비트 윈도우 관리 예 아니오(1) 32비트 그래픽 서브시스템 예 아니오(2) 32비트 프린트 서브시스템 예 예 32비트 멀티미디어 서브시스템 예 예 32비트 커널 예 예 요구 페이지 가상 메모리 예 예 잠김 없는 입력 큐(Non-locking Input Queue) 예(3) 아니오 -------------------------------------------------------------------------- (1) USER는 16비트, 재진입불가능 코드 (2) GDI의 50% 호출은 16비트,재진입불가능 코드에 의해 서비스된다. (3) OS/2 워프는 만약 입력 큐가 잠겼을 때 이를 여는 엔진을 가지고 있다. -------------------------------------------------------------------------- OS/2워프 vs. 윈도우즈95 응용 프로그램 환경 ------------------------------------------------------------------- 기능 OS/2 워프 윈도우즈95 -------------------------------------------------------------------------- 16비트/32비트 OS/2 PM 응용 프로그램 예 아니오 Win32s 응용 프로그램(v 1.0 & 1.1) 예 예 선점형 다중작업 예 약간(4) Win16 응용 프로그램 지원 예 예 Win16 디바이스 드라이버 지원 예 약간(5) 32비트 응용 프로그램의 숫자 2000+ 100+(6) -------------------------------------------------------------------------- (4) 다중작업 비교 차트를 참조 (5) 다시 쓰여져야 하는 윈도우즈 3.x 통신 드라이버들 (6) PC매거진 9월12일자 참조 -------------------------------------------------------------------------- OS/2워프 vs. 윈도우즈95 다중작업 특징 비교 -------------------------------------------------------------------------- 기능 OS/2 워프 윈도우즈95 -------------------------------------------------------------------------- 선점형 32비트 OS/2 그리고 Win32s v1.1 예 아니오 선점형 도스 응용 프로그램들 예 예 선점형 Win16 응용 프로그램들 예 아니오 선점형 16/32비트 혼합 응용 프로그램들 예 아니오(7) 다중, 보호모드 Win16 VDM들 예 아니오(8) 시스템 폭주 보호 예 아니오(9) 선점형 멀티 쓰레딩 예 예 -------------------------------------------------------------------------- (7) 16 & 32비트 OS/2, Win16, 그리고 Win32s v1.1 응용 프로그램들 (8) WinMUTEX는 Win16 응용 프로그램이 실행되는 동안 USER와 GDI 부분 억세스를 금지 (9) 모든 16비트 응용 프로그램들은 하나의 어드레스 공간을 공유한다 - 시스템 가상머신 -------------------------------------------------------------------------- OS/2 워프 vs. 윈도우즈95 사용자 인터페이스 -------------------------------------------------------------------------- 기능 OS/2 워프 윈도우즈95 -------------------------------------------------------------------------- 폴더 워크 영역 예 아니오 SOM과의 합체 예 아니오(10) 런치 패드 예 예 드래그 앤 드롭 억세스 경로 예 아니오 (실행 경로 변화에도 여전히 작동) 오브젝트 타입 탬플리트 예 아니오 부모 폴더 닫히기 옵션 예 아니오 -------------------------------------------------------------------------- (10) 윈도우즈95 쉘 구성요소는 OLE 2.01 오브젝트가 아니다. -------------------------------------------------------------------------- OS/2 워프 vs. 윈도우즈95 번들 응용 프로그램들 -------------------------------------------------------------------------- 기능 OS/2 워프 윈도우즈95 -------------------------------------------------------------------------- 인터넷 억세스 툴 예 아니오(11) (FTP, Telnet, Gopher, Newsreader, Web Exploere) 워드프로세서 예 아니오(12) 스프레드쉬트 예 아니오 데이타베이스 예 아니오 차트 그리기 예 아니오 리포트 쓰기 예 아니오 전자 메일 예 예 팩스 예 예 전화번호부 예 아니오 개인정보관리자 예 아니오 시스템정보보기 예 아니오 비디오인(VideoIn) 예 아니오 비디오 컨퍼런스 예 아니오 -------------------------------------------------------------------------- (11) 컴퓨터 통신을 이용하여 별도로 다운로드 받아야만 한다. (12) 텍스트 에디터는 포함되지만, 워드 프로세서는 아니다. -------------------------------------------------------------------------- 홍재용<하이텔 아이디, sayla> |