윈도우가 오래된 소프트웨어를 얼마나 끈질기게 돌려주느냐는 실무자에게 단순한 호기심 이상의 문제다. 기업 환경에는 수십 년 전 작성된 내부 도구나 장비 제어 프로그램이 여전히 돌아가는 경우가 흔하고, 운영체제를 올릴 때마다 '이게 아직 뜰까'가 실제 마이그레이션 비용을 좌우하기 때문이다. 한 개발자가 블로그에 정리한 실험, 즉 '수정이나 에뮬레이션 없이 윈도우 11에서 실행되는 가장 오래된 GUI 애플리케이션은 무엇인가'라는 질문은 이 호환성의 한계선을 흥미롭게 짚어준다.
출발점부터 제약이 하나 있다. 많은 사람이 윈도우의 하위 호환성을 떠올리며 1980~90년대 16비트 프로그램을 기대하지만, 64비트 윈도우에는 16비트 코드를 돌리는 NTVDM이 없어서 16비트 윈도우 프로그램은 그 자체로는 실행되지 않는다. 결국 탐색 범위는 초기 NT 시대의 32비트 프로그램으로 좁혀진다. 글쓴이는 예전에 한 익명 포럼에서 Win32s와 그 초기 버전에 포함된 FREECELL.EXE를 추천받았고, 실제로 1993년 2월 22일 날짜가 찍힌 프리셀 실행 파일이 아무 수정 없이 최신 윈도우 11에서 정상적으로 플레이되는 것을 확인했다. 작성 시점 기준 약 33년 8개월 된 프로그램이다.
더 오래된 것을 찾아서
여기서 멈추지 않고 글쓴이는 인터넷 아카이브에 올라온 더 이른 NT 3.1 프리릴리스 빌드들을 뒤졌다. 그 과정에서 드러난 두 가지 걸림돌이 기술적으로 흥미롭다. 첫째, 1991년의 가장 이른 버전들은 지금의 PE 실행 파일 형식과 호환되지 않는 초안 단계 포맷을 썼다. 둘째, 1992년 중반까지의 빌드는 윈도우 API 호출에 stdcall이 아니라 cdecl 호출 규약을 가정하고 있었다. 호출 규약이 어긋나면 스택에서 인자가 이중으로 정리되면서 프로그램이 그대로 죽는다. 운영체제의 ABI가 개발 중에 바뀌었다는 뜻이고, 이 경계를 넘지 못한 빌드는 오늘날 실행 자체가 불가능하다.
이 경계를 아슬아슬하게 통과한 것이 빌드 347에 들어 있던 CDPLAYER.EXE로, 1992년 11월 16일에 링크된 파일이다. 이 시점에는 호출 규약 문제가 이미 해결돼 있었다. 다만 같은 빌드의 다른 프로그램들은 자체 번들된 C 런타임에서 죽어버리는데, CDPLAYER.EXE는 번들 런타임 대신 시스템의 crtdll.dll을 사용한 덕분에 살아남았다. 그리고 윈도우 11은 여전히 SysWOW64에 crtdll.dll을 포함해 배포한다. 수십 년 전 프로그램이 지금도 뜨는 이유가 '우연히 올바른 공용 라이브러리를 참조했기 때문'이라는 점은, 호환성이란 것이 설계된 보장이라기보다 여러 조건이 맞아떨어진 결과에 가깝다는 사실을 잘 보여준다.
CD 없이 CD 플레이어 돌리기
정작 이 프로그램을 실행하면 멀쩡히 뜨긴 하지만 재생할 CD가 없다는 화면이 나온다. 요즘 PC에 CD-ROM 드라이브가 없으니 당연한 결과다. 글쓴이는 cdemu.dll이라는 작은 DLL로 가짜 오디오 데이터를 가진 드라이브를 흉내 내 실제로 음원을 재생시켰다. 거의 34년 된 프로그램이 소리를 내게 만든 셈인데, 이는 실행 가능성과 실제 기능 동작이 별개의 문제임을 상기시킨다. 오래된 소프트웨어는 프로세스가 뜨더라도 전제로 삼던 하드웨어나 외부 환경이 사라지면 반쪽짜리로만 살아난다.
마지막으로 글쓴이는 16비트의 벽을 우회하는 방법도 덧붙였다. otvdm 같은 호환 레이어를 쓰면 더 오래된 윈도우 프로그램을 돌릴 수 있는데, 이 방식으로 윈도우 1.01에 들어 있던 1985년 11월 15일자 REVERSI.EXE를 윈도우 11에서 완전히 플레이 가능한 상태로 띄웠다. 다만 그는 이것이 별도 호환 계층을 거치는 만큼 '맨몸 실행'이라는 원래 질문의 조건에서는 벗어난, 일종의 반칙에 가깝다고 분명히 선을 그었다.
실무자에게 남는 것
이 실험은 놀이처럼 보이지만 레거시 자산을 다루는 사람에게는 실용적인 교훈을 준다. 운영체제 세대를 건너뛰는 지점마다 ABI, 실행 파일 포맷, 호출 규약, 공용 런타임의 존재 여부 같은 저수준 조건이 호환성의 실제 분기점이 된다는 것이다. 특히 번들 런타임 대신 시스템 제공 라이브러리에 의존하는 설계가 장기 수명에 유리했다는 대목은, 오래 살아남아야 하는 도구를 만들 때 의존성을 어디에 두느냐가 결정적임을 시사한다. 물론 이 결과는 어디까지나 개인이 특정 빌드들을 수집해 돌려본 사례이지, 모든 초기 프로그램의 동작을 보장하는 체계적 조사가 아니라는 한계는 분명하다. 그럼에도 '어디까지가 맨몸이고 어디부터가 에뮬레이션인가'라는 경계 감각은, 가상화와 호환 레이어를 일상적으로 쓰는 요즘 환경에서 오히려 더 또렷하게 가져둘 만하다.