WSL 이전에 Windows 안에서 수정하지 않은 Linux 바이너리를 돌리는 대표 방법으로 CoLinux와 flinux가 있었다고 봄 http://www.colinux.org/ https://github.com/wishstudio/flinux
flinux는 사실상 WSL1 구조에 가까웠고, CoLinux는 Linux 커널을 옆에 실어 올리는 점에서 WSL2 쪽 느낌이었음
기술적으로는 Cygwin이 더 정석적이었다고 느낌. 외부 Linux 배관을 억지로 끼우기보다 Windows 위에서 네이티브 POSIX 바이너리를 돌리는 접근이었고, 가벼운 DLL 링크만으로 끝나서 ring 0을 건드리지 않는 점도 마음에 들었음
다만 당시에는 CLI 패키지 매니저의 편의성이 부족했고, 실제로 Windows에서 작업할 때는 CoLinux에 꽤 빠져 있었음
Cygwin은 CoLinux보다 훨씬 오래됐다고 기억함. CoLinux는 2004년, Cygwin은 1995년 공개였음
내가 기억하는 핵심 문제는 DLL hell이었음. 예를 들어 Windows용 OpenSSH 포트가 자기만의 cygwin1.dll을 들고 오면 버전 충돌이 자주 났음
그래도 RAM이 적고 스와핑이 무겁던 시절에는 오버헤드가 적다는 점이 의미 있었음
그 시절엔 Web 2.0이나 NodeJS 같은 것보다 네이티브 앱이 중심이었고, Java도 평판이 좋지 않았음
결국 늘 그렇듯 두 걸음 전진하고 한 걸음 후퇴하는 흐름처럼 느껴졌음
Cygwin이 정석이라는 말은 일부 기준에선 맞을지 몰라도, 내겐 상당히 기묘한 접근으로 보였음
느리지 않다는 뉘앙스와 달리 실제로는 느렸고, 다른 방식들보다 호환성도 떨어졌고, 재컴파일도 필요했으며, 긴 생애 대부분 동안 널리 사랑받는 도구는 아니었다고 느낌
cygwin1.dll 안에서는 엄청난 호환성 요술이 벌어지고 있었고, 결국 외부 Linux 배관을 프로세스 안으로 끌고 들어온 셈이라고 봄. 특히 시스템 지원 없이 fork()를 구현하는 방식을 떠올리면 더 그랬음
Cygwin은 Windows AppContainer 격리 안에서는 아예 동작하지 않음. MSYS2도 지금까지 이 기반을 써서, MSYS2 바이너리는 AppContainer에서 못 돌림
그래서 Claude Code 샌드박싱에서는 완전히 다른 길을 써야 했음. Claude Code는 Git for Windows를 원하고, Git for Windows는 MSYS2로 빌드된 bash.exe 등을 배포하기 때문이었음
반면 진짜 네이티브 Windows 빌드는 cygwin1.dll이 요구하는 그런 특이한 해킹이 없어서, 내가 찾은 non-MSYS2 빌드들은 AppContainer에서 잘 돌아갔음
요즘은 MSYS2가 내부적으로 cygwin에 의존하면서도 패키지 매니저를 제공한다고 봄
Arch Linux의 pacman을 쓸 수 있어서, Linux VM 없이도 Windows에서 네이티브 POSIX 바이너리를 꽤 친화적으로 다룰 수 있게 됐음
실제 개발 경험으로는 Cygwin 위 작업이 정말 고통스러웠음
쓰고 싶은 C 라이브러리에 미리 빌드된 Cygwin 버전이 없으면 의존성 트리 전체를 configure, make로 직접 돌려야 했음
게다가 내 기억으론 대략 3분의 2 확률로 뭔가를 직접 고쳐야 했는데, POSIX가 아주 완벽하게 맞지는 않았기 때문이었음
Cygwin은 기본적으로 Win32 위에 POSIX API를 구현하고, 호환성을 높이려고 일부 Nt 호출을 섞는 구조였음
다만 올바른 의미론을 맞추기 위해 온갖 우회와 해킹이 필요했고, 예를 들어 fork는 copy-on-write가 아니었음
나는 1999년쯤부터 2022년까지 Cygwin을 썼고, WSL2도 조금 써봤으며 지금도 노트북에서는 그걸 씀
다만 데스크톱은 작년부터 완전히 Linux로 넘어왔음
이게 colinux의 pre-NT Windows 버전 같은 건가 싶어서 꽤 반가웠음
예전에 XP 시절 Windows를 쓰던 때 Colinux를 돌렸는데, 정말 신기한 도구였음
Linux 쪽에 LAMP 스택을 올리는 게 훨씬 쉬웠고, 편집은 Windows 에디터로 하면서 로컬 개발 환경을 꽤 괜찮게 꾸릴 수 있었음
Windows용 X11 서버를 붙여서 Linux 데스크톱을 위에 띄우는 실험도 가능했음
그렇게 점점 더 Unix 같은 환경을 Windows 위에 쌓고 있는 나를 보다가 결국 macOS로 갈아탔음
순수한 해킹 가치 말고 실제 용도를 떠올리면, 486급 머신에서는 금방 메모리 한계에 부딪힐 것 같다는 생각도 듦 http://colinux.org/
Colinux는 정말 기술적 위업이었다고 봄
다만 그걸 알아본 사람이 많지 않았을 뿐이라고 느낌
이걸 만든 사람이 거의 마법사처럼 느껴졌음
내 눈엔 거의 불가능해 보이는 작업이었음
다만 구조를 이해하는 사람들 눈에는 어떻게 보일지 궁금해졌음
그래서 수학자 둘이 어떤 정리를 사소하다고 말하고, 두 시간 설명한 뒤에야 정말 사소하다고 인정하는 그 농담이 떠올랐음
나도 CS 1학년 때 집합론 수업에서 칠판 앞에 서서 증명을 하다가, 도저히 못 보이던 부분을 그냥 사소함이라고 넘긴 적이 있음
그러자 교수도 맞다고 하고 그냥 다음으로 넘어갔던 기억이 남음
나는 대체로 구조를 이해하는 편인데, 이게 마법처럼 보이진 않음
대신 이걸 가능하게 만드는 긴 비전서 같은 디테일 목록을 작성자가 하나씩 파악해냈다는 점에서 크게 감탄하게 됨
현대 운영체제의 핵심 역할은 여러 프로그램이 서로 간섭하지 못하게 하면서 동시에 돌게 만드는 일이라고 이해함
그래서 각 프로그램은 자기 메모리 일부만 읽을 수 있고, CPU도 제한된 시간만 쓰고 다음 프로그램에 넘기게 됨
Windows는 이런 기능을 Windows NT부터 본격적으로 썼고, XP도 그 계열임
반면 Windows 98까지는 프로그램이 거의 무엇이든 할 수 있었고, 하드웨어의 그런 보호 기능이 사실상 놀고 있었음
그 시절 Windows는 운영체제라기보다 UI를 띄우고 주변장치와 대화하는 기능 라이브러리 묶음에 더 가까웠다고 느낌
CPU에는 메모리 접근과 처리 시간을 제한하는 특수 하드웨어가 있는데, Windows 9x는 이를 충분히 활용하지 않았음
그래서 Windows 9x용 Linux 서브시스템이 스스로 운영체제인 척하면서 그 하드웨어를 가져다 현대 운영체제를 돌릴 수 있는 여지가 생겼다고 봄
프로젝트 페이지를 보면 설명이 꽤 잘 되어 있다고 느낌
내가 보기에 이런 작업에서 가장 어려운 부분은 Microsoft 드라이버 API를 파악해내는 일임
9x 시절 문서는 충분히 상세하지도 않았고 접근도 쉽지 않았으며, 지금도 썩 유쾌한 영역은 아니라고 봄
win9x 커널은 원래 하는 일이 많지 않다는 걸로 유명했음
그래서 오히려 Linux의 저수준 기능 일부를 이식해 넣을 공간이 꽤 생기는 것처럼 보였음
이런 글이 같은 날 프런트 페이지에 올라온 게 반가웠음
한쪽에서는 Show HN이 세 배로 늘고 비슷한 바이브 코딩 느낌의 앱이 많아졌다는 얘기가 나오고, 다른 한쪽에서는 누군가가 6년 동안 Win9x 내부를 파고들어 현대 Linux 커널을 그 안에서 돌리고 있었음
20분 프롬프트로 만들어진 앱들로 가득한 스레드와 비교하니, 이런 게시물은 정말 행복하게 느껴졌음
프로젝트 README에 Proudly written without AI라고 적혀 있다고 봄
이런 문구를 보게 되어 꽤 좋았음
심지어 프롬프트 자체도 AI가 만들었을 가능성이 높다고 느낌
create me an owl app 대신, owl app을 만들기 위한 종합 프롬프트를 만들어 달라고 한 뒤 그걸 다음 AI 세션에 붙여넣는 식이 흔해졌다고 봄
README의 > Proudly written with zero AI 라는 표현은 좀 애매하게 느껴졌음
왜냐하면 Zero AI라는 제품명이 실제로 있어서 그렇게 읽힐 수도 있기 때문이었음
지금은 > Proudly written without AI 로 더 명확하게 수정된 것 같음
표현도 훨씬 분명해졌고, 프로젝트 자체도 정말 놀랍다고 느낌
Windows 3.x와 9x의 구조를 잘 설명하는 좋은 자료가 뭐가 있을지 궁금함
VM Monitor가 있다는 정도와 이런 종류의 지원이 있다는 조각 정보는 알고 있지만, 자세한 설명은 여기저기 흩어져 있다고 느낌
많은 사람이 Windows를 그냥 DOS 위에서 도는 것처럼 요약하지만, 그건 분명 정확하지 않다고 봄
물론 오늘날 의미의 가상머신과는 다르겠지만, 그 안에 꽤 흥미로운 기술적 구조가 있었고 대부분의 자료가 그 부분을 얕게만 다루는 것 같음
또 이 프로젝트가 BSD on Windows와 얼마나 비슷한지도 궁금함
그리고 Architecture of Windows 9x도 알고 있지만, 내 취향엔 깊이가 부족하게 느껴졌음
Microsoft식 네이밍이라면 이건 Windows Subsystem for Linux가 아니라 Linux Subsystem for Windows가 되어야 하지 않나 싶었음
꼭 그렇진 않다고 봄
WSL이 Linux on Windows를 뜻하니, 이것도 Windows 9x 위의 Linux라는 의미에서 W9xSL로 읽히는 것 같았음
나도 이 이름은 예전부터 직관적이지 않다고 느꼈음
나 역시 동의함
지금 당장 근거를 들 수는 없지만, 예전에 읽기로는 이게 상표 문제와 관련 있었다고 기억함
원래는 Linux Subsystem for Windows라고 부르고 싶었지만, Linux foundation 쪽에서 비인가 프로젝트가 Linux로 시작하는 이름을 쓰는 걸 허용하지 않았다는 식의 얘기였음
NT 커널은 NT 3.1부터 2000, XP를 거쳐 나중엔 Windows 10/11의 WSL에도 일부 계보가 이어졌는데, 1993년 처음부터 POSIX 서브시스템을 염두에 두고 설계됐다고 이해함
핵심 철학은 여러 개의 personality를 두고, 각 환경의 시스템 호출을 NT 커널 호출로 번역하는 구조였음
그래서 WSL1도 2016년에 사실상 같은 묘수를 Linux용으로 다시 구현한 셈이라고 봄
반면 Windows 9x는 DOS 계열이어서, 그 안에서 Linux를 돌리려면 훨씬 더 지저분하고 근본적으로 다른 해킹이 필요했을 것 같음
아마 당시엔 아무도 안 한 이유도 그 때문일 거라고 짐작함
그래서 이게 실제로 돌아간다는 사실 자체가 NT 아키텍처가 얼마나 시대를 앞섰는지를 보여준다고 느낌
실용적인 용도로는 오래된 의료나 산업용 소프트웨어처럼 Windows 98에 묶여 있는 환경이 떠오름
다만 2026년에 486을 손에 들고 있다면, 30년 된 DOS 파생체 안에 Linux를 넣기보다 그냥 네이티브 Linux를 돌리는 쪽이 훨씬 더 유용할 가능성이 높다고 봄
다 맞는 말이지만, 완전히 전례 없는 일은 아니라고 생각함
Windows 9x가 DOS를 실행할 수 있었던 것만 봐도 이미 상당한 마법이 들어가 있었음
관련해서 읽어볼 만한 글도 남겨둠
Hacker News 의견들
http://www.colinux.org/
https://github.com/wishstudio/flinux
flinux는 사실상 WSL1 구조에 가까웠고, CoLinux는 Linux 커널을 옆에 실어 올리는 점에서 WSL2 쪽 느낌이었음
기술적으로는 Cygwin이 더 정석적이었다고 느낌. 외부 Linux 배관을 억지로 끼우기보다 Windows 위에서 네이티브 POSIX 바이너리를 돌리는 접근이었고, 가벼운 DLL 링크만으로 끝나서 ring 0을 건드리지 않는 점도 마음에 들었음
다만 당시에는 CLI 패키지 매니저의 편의성이 부족했고, 실제로 Windows에서 작업할 때는 CoLinux에 꽤 빠져 있었음
내가 기억하는 핵심 문제는 DLL hell이었음. 예를 들어 Windows용 OpenSSH 포트가 자기만의 cygwin1.dll을 들고 오면 버전 충돌이 자주 났음
그래도 RAM이 적고 스와핑이 무겁던 시절에는 오버헤드가 적다는 점이 의미 있었음
그 시절엔 Web 2.0이나 NodeJS 같은 것보다 네이티브 앱이 중심이었고, Java도 평판이 좋지 않았음
결국 늘 그렇듯 두 걸음 전진하고 한 걸음 후퇴하는 흐름처럼 느껴졌음
느리지 않다는 뉘앙스와 달리 실제로는 느렸고, 다른 방식들보다 호환성도 떨어졌고, 재컴파일도 필요했으며, 긴 생애 대부분 동안 널리 사랑받는 도구는 아니었다고 느낌
cygwin1.dll 안에서는 엄청난 호환성 요술이 벌어지고 있었고, 결국 외부 Linux 배관을 프로세스 안으로 끌고 들어온 셈이라고 봄. 특히 시스템 지원 없이 fork()를 구현하는 방식을 떠올리면 더 그랬음
Cygwin은 Windows AppContainer 격리 안에서는 아예 동작하지 않음. MSYS2도 지금까지 이 기반을 써서, MSYS2 바이너리는 AppContainer에서 못 돌림
그래서 Claude Code 샌드박싱에서는 완전히 다른 길을 써야 했음. Claude Code는 Git for Windows를 원하고, Git for Windows는 MSYS2로 빌드된 bash.exe 등을 배포하기 때문이었음
반면 진짜 네이티브 Windows 빌드는 cygwin1.dll이 요구하는 그런 특이한 해킹이 없어서, 내가 찾은 non-MSYS2 빌드들은 AppContainer에서 잘 돌아갔음
Arch Linux의 pacman을 쓸 수 있어서, Linux VM 없이도 Windows에서 네이티브 POSIX 바이너리를 꽤 친화적으로 다룰 수 있게 됐음
쓰고 싶은 C 라이브러리에 미리 빌드된 Cygwin 버전이 없으면 의존성 트리 전체를 configure, make로 직접 돌려야 했음
게다가 내 기억으론 대략 3분의 2 확률로 뭔가를 직접 고쳐야 했는데, POSIX가 아주 완벽하게 맞지는 않았기 때문이었음
다만 올바른 의미론을 맞추기 위해 온갖 우회와 해킹이 필요했고, 예를 들어 fork는 copy-on-write가 아니었음
나는 1999년쯤부터 2022년까지 Cygwin을 썼고, WSL2도 조금 써봤으며 지금도 노트북에서는 그걸 씀
다만 데스크톱은 작년부터 완전히 Linux로 넘어왔음
예전에 XP 시절 Windows를 쓰던 때 Colinux를 돌렸는데, 정말 신기한 도구였음
Linux 쪽에 LAMP 스택을 올리는 게 훨씬 쉬웠고, 편집은 Windows 에디터로 하면서 로컬 개발 환경을 꽤 괜찮게 꾸릴 수 있었음
Windows용 X11 서버를 붙여서 Linux 데스크톱을 위에 띄우는 실험도 가능했음
그렇게 점점 더 Unix 같은 환경을 Windows 위에 쌓고 있는 나를 보다가 결국 macOS로 갈아탔음
순수한 해킹 가치 말고 실제 용도를 떠올리면, 486급 머신에서는 금방 메모리 한계에 부딪힐 것 같다는 생각도 듦
http://colinux.org/
다만 그걸 알아본 사람이 많지 않았을 뿐이라고 느낌
내 눈엔 거의 불가능해 보이는 작업이었음
다만 구조를 이해하는 사람들 눈에는 어떻게 보일지 궁금해졌음
그래서 수학자 둘이 어떤 정리를 사소하다고 말하고, 두 시간 설명한 뒤에야 정말 사소하다고 인정하는 그 농담이 떠올랐음
그러자 교수도 맞다고 하고 그냥 다음으로 넘어갔던 기억이 남음
대신 이걸 가능하게 만드는 긴 비전서 같은 디테일 목록을 작성자가 하나씩 파악해냈다는 점에서 크게 감탄하게 됨
그래서 각 프로그램은 자기 메모리 일부만 읽을 수 있고, CPU도 제한된 시간만 쓰고 다음 프로그램에 넘기게 됨
Windows는 이런 기능을 Windows NT부터 본격적으로 썼고, XP도 그 계열임
반면 Windows 98까지는 프로그램이 거의 무엇이든 할 수 있었고, 하드웨어의 그런 보호 기능이 사실상 놀고 있었음
그 시절 Windows는 운영체제라기보다 UI를 띄우고 주변장치와 대화하는 기능 라이브러리 묶음에 더 가까웠다고 느낌
CPU에는 메모리 접근과 처리 시간을 제한하는 특수 하드웨어가 있는데, Windows 9x는 이를 충분히 활용하지 않았음
그래서 Windows 9x용 Linux 서브시스템이 스스로 운영체제인 척하면서 그 하드웨어를 가져다 현대 운영체제를 돌릴 수 있는 여지가 생겼다고 봄
내가 보기에 이런 작업에서 가장 어려운 부분은 Microsoft 드라이버 API를 파악해내는 일임
9x 시절 문서는 충분히 상세하지도 않았고 접근도 쉽지 않았으며, 지금도 썩 유쾌한 영역은 아니라고 봄
그래서 오히려 Linux의 저수준 기능 일부를 이식해 넣을 공간이 꽤 생기는 것처럼 보였음
한쪽에서는 Show HN이 세 배로 늘고 비슷한 바이브 코딩 느낌의 앱이 많아졌다는 얘기가 나오고, 다른 한쪽에서는 누군가가 6년 동안 Win9x 내부를 파고들어 현대 Linux 커널을 그 안에서 돌리고 있었음
20분 프롬프트로 만들어진 앱들로 가득한 스레드와 비교하니, 이런 게시물은 정말 행복하게 느껴졌음
이런 문구를 보게 되어 꽤 좋았음
create me an owl app 대신, owl app을 만들기 위한 종합 프롬프트를 만들어 달라고 한 뒤 그걸 다음 AI 세션에 붙여넣는 식이 흔해졌다고 봄
왜냐하면 Zero AI라는 제품명이 실제로 있어서 그렇게 읽힐 수도 있기 때문이었음
표현도 훨씬 분명해졌고, 프로젝트 자체도 정말 놀랍다고 느낌
https://codeberg.org/hails/wsl9x
Mastodon은 글 하나 읽으려 해도 여전히 JavaScript 실행을 요구해서 보통 그냥 무시하게 됨
https://github.com/mastodon/mastodon/issues/23153
https://github.com/mastodon/mastodon/issues/19953
VM Monitor가 있다는 정도와 이런 종류의 지원이 있다는 조각 정보는 알고 있지만, 자세한 설명은 여기저기 흩어져 있다고 느낌
많은 사람이 Windows를 그냥 DOS 위에서 도는 것처럼 요약하지만, 그건 분명 정확하지 않다고 봄
물론 오늘날 의미의 가상머신과는 다르겠지만, 그 안에 꽤 흥미로운 기술적 구조가 있었고 대부분의 자료가 그 부분을 얕게만 다루는 것 같음
또 이 프로젝트가 BSD on Windows와 얼마나 비슷한지도 궁금함
그리고 Architecture of Windows 9x도 알고 있지만, 내 취향엔 깊이가 부족하게 느껴졌음
https://winworldpc.com/product/windows-sdk-ddk/windows-95-ddk
문서가 아주 자세하고 샘플 코드도 많아서 직접 파고들기 좋았음
WSL이 Linux on Windows를 뜻하니, 이것도 Windows 9x 위의 Linux라는 의미에서 W9xSL로 읽히는 것 같았음
지금 당장 근거를 들 수는 없지만, 예전에 읽기로는 이게 상표 문제와 관련 있었다고 기억함
원래는 Linux Subsystem for Windows라고 부르고 싶었지만, Linux foundation 쪽에서 비인가 프로젝트가 Linux로 시작하는 이름을 쓰는 걸 허용하지 않았다는 식의 얘기였음
핵심 철학은 여러 개의 personality를 두고, 각 환경의 시스템 호출을 NT 커널 호출로 번역하는 구조였음
그래서 WSL1도 2016년에 사실상 같은 묘수를 Linux용으로 다시 구현한 셈이라고 봄
반면 Windows 9x는 DOS 계열이어서, 그 안에서 Linux를 돌리려면 훨씬 더 지저분하고 근본적으로 다른 해킹이 필요했을 것 같음
아마 당시엔 아무도 안 한 이유도 그 때문일 거라고 짐작함
그래서 이게 실제로 돌아간다는 사실 자체가 NT 아키텍처가 얼마나 시대를 앞섰는지를 보여준다고 느낌
실용적인 용도로는 오래된 의료나 산업용 소프트웨어처럼 Windows 98에 묶여 있는 환경이 떠오름
다만 2026년에 486을 손에 들고 있다면, 30년 된 DOS 파생체 안에 Linux를 넣기보다 그냥 네이티브 Linux를 돌리는 쪽이 훨씬 더 유용할 가능성이 높다고 봄
Windows 9x가 DOS를 실행할 수 있었던 것만 봐도 이미 상당한 마법이 들어가 있었음
관련해서 읽어볼 만한 글도 남겨둠