윈도우 3.1의 잊힌 파일 winstart.bat, TSR 격리의 원형을 다시 읽다

오래된 소프트웨어의 내부 구조를 추적해 온 마이크로소프트의 기술 블로그가 이번에는 거의 잊힌 배치 파일 하나를 꺼냈다. C:\WINDOWS\WINSTART.BAT다. 한 독자가 이 파일이 AUTOEXEC.BAT와 무엇이 다른지, 그리고 부팅 과정 중 정확히 언제 실행되는지 물었고, 그에 대한 답이 글의 출발점이 됐다. 오늘날의 실무자에게 당장 쓸모가 있는 지식은 아니지만, 가상머신 위에서 운영체제를 다시 얹는 초창기 윈도우의 구조와 실행 환경 격리라는 개념의 뿌리를 이해하는 데는 꽤 좋은 사례다.

부팅 순서로 본 두 배치 파일의 차이

윈도우 95의 부팅 과정을 순서대로 따라가면 winstart.bat가 놓인 위치가 분명해진다. 먼저 MS-DOS와 명령 프롬프트가 뜨고, command.com이 AUTOEXEC.BAT를 실행하면서 TSR(메모리 상주 프로그램)이 설치될 수 있다. 그다음 윈도우가 뜨면서 가상머신 관리자가 초기화되고, 시스템은 보호 모드로 전환된다. 이때 실제 모드에서 돌던 환경을 그대로 담은 가상머신, 이른바 '시스템 VM'이 만들어진다. 가상머신 관리자는 파일 시스템 책임을 넘겨받으면서 실제 모드의 MS-DOS 파일 시스템을 꺼버린다. 부팅한 운영체제 위에 또 다른 운영체제를 얹어, 처음 운영체제가 두 번째 운영체제가 통제하는 가상머신 안에서 돌게 되는 셈이다.

바로 이 지점, 즉 시스템 VM이 만들어진 뒤 윈도우 애플리케이션을 담당하는 사용자 모드 커널이 뜨기 직전에 winstart.bat가 실행된다. 여기서 또 다른 TSR이 설치될 수 있다. 그 후 사용자 모드 커널이 가상머신을 보호 모드로 전환하면 우리가 흔히 '윈도우'라고 부르는 화면이 나타난다. 반면 AUTOEXEC.BAT는 윈도우가 뜨기 전, 순수한 실제 모드 단계에서 돌아간다는 점이 핵심적인 차이다.

winstart.bat가 존재한 이유

이 실행 시점의 차이가 곧 용도를 규정한다. 윈도우 GUI에서 명령 프롬프트를 새로 열면 두 번째 가상머신이 만들어지는데, 이 가상머신은 윈도우가 시작되던 시점의 시스템 상태를 복제한 것이다. 따라서 AUTOEXEC.BAT에서 설치된 TSR은 보이지만, winstart.bat에서 설치된 TSR은 보이지 않는다. 결국 winstart.bat의 의도된 목적은 윈도우 프로그램에만 적용되는 TSR을 설치하는 것이다.

대표적인 예가 네트워크 드라이버다. MS-DOS 프로그램에는 네트워킹이 필요 없어 관습 메모리를 아끼고 싶거나, 해당 드라이버가 여러 가상머신에서 동시에 동작하지 못해 시스템 VM에서만 쓰고 DOS 프로그램에서는 포기해야 할 때, 드라이버를 전역이 아니라 시스템 VM에만 얹는 선택지가 생긴다. 오늘날 컨테이너나 프로세스 단위로 실행 환경을 분리하는 감각과 통하는 발상이, 이미 이 시절의 메모리 제약 속에서 나름의 형태로 존재했던 것이다.

'윈도우 95 기능'이라는 오해

글이 짚는 흥미로운 지점은 출처의 착각이다. 이 파일을 발견한 사람들 대부분이 윈도우 95의 기능이라고 여기지만, 실제로는 윈도우 3.1의 기능이며 어쩌면 3.0까지 거슬러 올라간다. 윈도우 3.1 리소스 킷 263쪽에 문서화돼 있고, 그 페이지에는 TSR을 실행하는 세 가지 방법과 각각이 서로 다른 가상머신에서 어떻게 보이는지 정리한 표도 실려 있다. 다만 이 문서는 '가상머신'이라는 용어를 윈도우 자신이 도는 가상머신을 제외한 비윈도우 가상머신만을 가리키는 관례로 쓴다는 점은 읽을 때 유의해야 한다. 정식으로 문서화된 기능임에도 검색으로는 좀처럼 정보가 나오지 않았다는 독자들의 반응은, 오래된 기능이 어떻게 집단의 기억에서 지워지는지를 보여준다.

현장에서의 쓰임과 그 이면

댓글에는 이 파일이 실제로 쓰인 사례가 여럿 등장한다. 한 독자는 일부 설치 프로그램이 윈도우가 돌고 있는 동안에는 교체할 수 없는 파일을 지우거나 바꾸는 데 winstart.bat를 이용했다고 회고한다. GUI가 초기화되기 직전에 화면에 잠깐 스치는 'File not found' 메시지를 보고 이 파일의 존재를 알게 됐다는 것이다. 더 나은 방법이 있었지만 프로그래머들이 늘 그런 것을 신경 쓰지는 않았다는 냉소가 뒤따른다.

한 독자가 털어놓은 이야기는 이 기능의 어두운 활용을 보여준다. 관리자가 PC 설정을 잠글 수 있게 해 주는 윈도우 3 시절의 상용 앱을 만들면서, winstart.bat로 헤드리스 DOS 실행 파일을 띄워 고객이 수임료를 냈는지 검사하게 했다는 것이다. 미납이면 난수를 생성해 특정 값이 나올 때 무한 루프로 시스템을 멈추게 만들었고, 이는 고객이 문제 해결을 요청하도록 유도하는 장치였다. 실제로 한 고객사 사장의 PC에만 이 앱이 설치돼 있었고, 납기가 지난 어느 날 오후 4시에 잠금 현상 신고가 들어왔다고 한다. 오늘의 보안 기준으로는 명백히 부적절한 방식이지만, 시스템 시작 시점에 조용히 코드를 끼워 넣을 수 있는 실행 지점이 어떤 위험을 내포하는지 역설적으로 드러낸다.

결국 winstart.bat는 지금 당장 손에 쥘 지식은 아니다. 그러나 실행 환경을 어느 계층에 격리할 것인가라는 물음, 그리고 부팅 시퀀스의 특정 틈에 코드가 끼어들 수 있다는 사실이 갖는 양면성은 시대를 넘어 유효하다. 우리가 매일 다루는 플랫폼의 토대가 이런 잊힌 설계 결정들 위에 쌓여 있다는 점을 되짚게 한다는 데 이 글의 가치가 있다.