요약
윈도 11에는 오래된 앱을 위해 다시 컴파일한 윈도 95의 메모리 관리자가 아직 들어 있습니다.
마이크로소프트 엔지니어 레이먼드 첸의 옛 글을 바탕으로 IT 매체가 정리한 기사입니다. 기자는 EmulateHeap이라는 호환성 수정이 최신 윈도 11 26H2에도 남아 있는 것을 직접 확인했습니다.
왜 중요한가
- 30년 된 앱을 돌리려고 옛 운영체제 코드의 상당 부분을 옮겨 올 만큼 마이크로소프트가 하위 호환성을 중시해 왔음을 보여 줍니다.
- 22H2 업데이트 뒤 이 수정을 켠 GTA Vice City에서 소리가 사라지는 등, 호환성 지원에도 한계가 있습니다.
핵심 내용
- EmulateHeap은 옛 앱의 힙(실행 중 메모리를 빌리고 돌려주는 영역) 호출을 윈도 95식으로 동작하는 대체 코드로 넘깁니다.
- 마이크로소프트는 윈도 95 힙 관리자의 소스 코드를 복사해 다시 컴파일한 뒤 앱 호환성 체계에 넣었습니다.
- 첸은 옛 코드를 수정을 켠 앱에서만 불러오므로 평소에는 돌지 않는다고 설명했습니다.
- 비슷한 전례로, 윈도 95는 해제한 메모리를 다시 읽는 버그가 있던 SimCity를 감지해 메모리 해제를 늦췄습니다.
- 관리자용 도구 Compatibility Administrator의 32비트 판에서 수정 목록을 보면 EmulateHeap을 찾을 수 있습니다.
HN 반응
- 기사가 첸의 블로그를 고쳐 쓴 수준이고, SimCity용 특별 처리를 한 번뿐인 예외로 오해했다는 비판이 많았습니다.
- 비스타 시절 윈도 개발자였던 이용자는 규격에 맞지 않는 값싼 USB 기기까지 살리려 애쓴 경험을 전했고, 옛 앱이 금방 막히는 맥과 비교하는 댓글도 이어졌습니다.
> 이 전통은 심시티에서 시작됐습니다. 심시티는 마이크로소프트가 특별한 코드를 써 준 덕분에 윈도 95에서 돌아갔습니다... 그렇습니다. 마이크로소프트는 게임 하나의 버그를 덮으려고 운영체제를 고쳤습니다... 심시티 핵은 단발성 사례였습니다
이 글에서 심시티를 다룬 부분은 형편없이 쓰였습니다. 글쓴이는 이 일을 단발성 특수 사례로 오해한 것 같습니다. 조엘 스폴스키의 글을 다시 찾아봤는데, 심시티는 수많은 사례 중 하나일 뿐이라고 꽤 분명하게 적혀 있습니다. "옛날 16비트 소프트웨어도 여전히 완벽하게 돌아갔다. 마이크로소프트는 여기에 집착해서, 구할 수 있는 모든 옛날 프로그램을 윈도 95에서 테스트하느라 큰돈을 썼다."
글 뒷부분에 "윈도 XP의 숨겨진 앱 수정 데이터베이스"가 언급되기는 하지만, 이런 발상이 사실상 윈도 95에서, 그것도 대규모로 시작됐다는 점은 이해하지 못하고 있습니다. "게임 하나의 버그를 덮으려고" 한 일이 결코 아닙니다.
어림짐작이지만 이건 전부 https://devblogs.microsoft.com/oldnewthing/ 에 있는 레이먼드 천의 글을 콘텐츠 농장식으로 우려먹은 것 같네요. 결정적 증거는 못 찾겠지만요. 인튜잇이 뭔가 어이없는 짓을 해서 내부 API가 엉뚱한 값을 계속 돌려주게 남겨 뒀어야 했다는 글을 읽은 기억은 분명히 있어요.
윈도 95가 썼던 테스트 방식에 대한 레이먼드 천의 블로그 글은 여기 있습니다. https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34463/
저는 트랜스메타에서 QA 엔지니어로 일하면서, 우리 CPU에서 x86 호환성이 확보되는지 소프트웨어를 돌려 테스트했습니다. 우리 팀장님도 이런 식으로 일하셨습니다. 항상 구해 올 만한 옛 소프트웨어를 찾아다니셨고, 가장 좋아하신 일 중 하나가 망한 스타트업 건물 밖 쓰레기통을 뒤져서 CD와 플로피 디스크에 담긴 옛 소프트웨어를 건져 오는 것이었습니다. 디아블로 2, 여러 버전의 툼 레이더, 스타워즈 에피소드 I 레이서, 리스크(윈도 3.0용)를 많이 테스트했던 기억이 납니다.
하드코어 지옥 난이도 소서리스로 한 판 끝내 보고 왔는데, 그쪽 CPU는 이 소프트웨어와 완벽하게 호환된다는 소식을 기쁜 마음으로 전합니다.
저는 특정 CPU와 칩셋 조합에서 툼 레이더 2를 하고 나면 시스템이 멈추는 버그를 찾았습니다. 제 기억이 맞다면 사우스브리지 어딘가에서 허용할 수 없는 수준의 전압 강하가 일어난 게 원인이었습니다.
"음, 다시 한번 확인해 봐야 할 것 같은데요. 일정 좀 일주일만 더 비워 주세요."
이 일을 다룬 글[0]에서 가져왔습니다.
[0] https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems
이 글은 내용이 전반적으로 꽤 부실합니다. 예전 방식대로 스크린샷 몇 장 붙인 트윗 하나로 충분히 다룰 수 있었을 내용이고, 그랬어도 잃을 건 아무것도 없었을 겁니다.
좋게 말할 수 있는 점은 AI가 쓴 것 같지는 않다는 것뿐입니다.
글쓴이가 자기가 쓰는 내용을 제대로 이해하고 있다고 생각하지 않습니다. 조금 조사하고, 스크린샷 몇 장 만들고, 검색 엔진에 걸리게끔 분량만 채워 넣은 글입니다.
윈도 오류 코드를 다루는 수많은 글이 떠오릅니다. 거의 다 뻔한 내용을 쓸데없이 길게 늘어놓고는 "해결 프로그램"을 설치하라고 유도합니다. 기술을 아는 사람이 이런 글을 만나면 짜증만 납니다. 쓸모없는 콘텐츠로 검색 결과를 노골적으로 조작한 글이기 때문입니다.
심지어 글쓴이가 "도움"을, 그것도 아주 많이 받았을 거라는 추측도 가능하죠. 글쓴이라는 사람이 실존한다면 말이지만요.
AI의 도움을 받는 것 자체는 문제될 게 없습니다. 그 도움 중 어느 부분이 쓸 만한지 제대로 된 판단력으로 가려내기만 한다면 말입니다.
이 글쓴이는 그러지 않았어요. 남의 블로그 연재글을 그냥 말만 바꿔 썼을 뿐이에요.
그랬다고 말한 적 없습니다. 저는 AI를 쓰는 것 자체가 나쁜 일은 아니라고 일반적인 얘기를 했을 뿐입니다.
윈도와 마이크로소프트를 어떻게 생각하든, 30년도 더 된 앱을 아직도 실행할 수 있다는 건 대단한 일입니다.
저는 롱혼/비스타 개발 시기에 윈도 코어 OS 부서에서 장치 연결 쪽 일을 했습니다. 그 전에는 리눅스와 SunOS 쪽에 있었고요. 아무리 오래되고 고장 나 있고 말썽을 부리는 USB나 프린터 장치라도 윈도가 하위 호환성을 유지하도록 쏟아붓는 헌신과 노력은 정말 말도 안 될 정도였습니다. USB 규격을 따르지 않지만 윈도 98에서는 "그럭저럭 돌아가던" 이름 없는 싸구려 웹캠들이 있었는데, 이것들이 비스타에서도 작동해야 했습니다. 동시에 싸구려 장치의 온갖 전제를 깨뜨리는 새로운 보안 드라이버 모델도 구현해야 했고요. 그 장치들을 전부 작동하게 만드는 건 길고 험난한 여정이었습니다.
새 PC, 특히 비스타에서 옛날 윈도 게임을 즐기는 저희를 대표해서 감사드려요!
그런 작업을 하려면 온갖 장치를 모아 놓은 실물 라이브러리를 직접 마련해야 했나요?
레이먼드 천이 실제로 이 얘기를 했습니다. https://devblogs.microsoft.com/oldnewthing/20240521-00/?p=109786/
컴퓨터 상점에서 찾아낸 온갖 잡동사니를 허브로 지원되는 USB 규격의 최대치까지 가득 채운 카트가 있었다고 합니다. 허브를 꽂고는 모든 게 고쳐져서 제대로 작동할 때까지 윈도가 뻗는 모습을 지켜봤고, 그다음에는 장치를 아직 인식하는 도중에 허브를 뽑아 버리기 시작했답니다.
가장 재미있는 부분을 빼먹으셨네요. 그 카트 이름이 "USB 죽음의 카트"였다는 거요!
저 댓글 쓴 분은 어떤지 모르겠지만, 마이크로소프트에 그런 게 있었던 건 확실해요. 이 AI가 베껴 온 주 출처인 레이먼드 천이 얘기한 적이 있거든요.
맥이 맥 앱을 얼마나 빨리 못 돌리게 되는지도 놀랍죠.
윈도를 좋아하던 게이머인데 맥을 써야 했던 저한테는 이게 충격이었습니다. 로제타가 한동안 도움이 되긴 했어요. 요즘은 따라올 의지가 없는 개발자를 솎아내려는 의도적인 러닝머신처럼 느껴집니다.
맞습니다. 애플과 구글 모두 "한동안" 업데이트되지 않은 앱은 스토어에서 밀어냅니다. 앱이 멀쩡히 작동하고 완성도가 완벽해도 마찬가지입니다.
맞아요, 맥과 게임이 안 맞는 이유는 그것 말고도 있죠. 애플은 개발자들이 Metal을 쓰길 원하는데 개발자들은 Metal을 쓰고 싶어 하지 않거든요. 저는 어쩌다 맥에서 돌아가는 몇 안 되는 게임을 가끔 하는데, 그거면 충분해요.
Metal을 쓰고 싶어 하지 않는 건 FOSS 개발자들입니다.
게임 개발자들은 자기 엔진에 이미 Metal 지원을 넣어 뒀고, FOSS 커뮤니티처럼 API 전쟁에 시간을 쓰지 않습니다.
맞아요, 말이 안 되죠. 표준은 OpenGL과 Vulkan인데 애플은 그냥 남과 다르려고 그걸 버렸잖아요. 적어도 OGRE 같은 큰 게임 엔진 몇몇은 Metal을 지원하니까, 크로스 플랫폼으로 개발하고 싶다면 가능하긴 해요.
공정하게 말하면 Metal이 먼저 나왔고, Vulkan 개발에 영감을 준 것도 Metal입니다.
하지만 USB-C처럼 어느 시점에는 업계 표준을 그냥 받아들여야 합니다.
어디의 업계 표준이요? 게임 쪽은 아닌데요.
아닙니다. OpenGL과 Vulkan은 카맥 같은 유명한 사람들이 밀어붙였을 뿐, 게임 개발자들이 받아들인 표준이 아닙니다. 심지어 카맥조차 DirectX가 훨씬 낫다고 인정했습니다.
게임 콘솔은 대부분 크로노스 API를 쓰지 않습니다. 사실상 GNU/리눅스와 안드로이드에서만 표준입니다.
크로스 플랫폼이라는 것들도 맥은 제대로 지원하지 않는 경우가 많아요. 예를 들어 CSGO는 다른 소스 엔진 게임들처럼 맥 버전이 있었지만 맥에서는 한 번도 제대로 돌아간 적이 없어요. 입력 지연도 있고 프레임도 들쭉날쭉했거든요. 이기는 데 목숨 거는 편은 아니지만 그렇게는 하기 괴로울 정도였어요. 같은 기기에서 부트 캠프로 윈도를 돌리면 게임은 완벽했고요.
그리고 Metal 위에서 돌리는 Vulkan이 있긴 한데 변환 오버헤드가 있고, 그 밖에 어떤 문제가 생기는지는 저도 몰라요. 돌핀 에뮬레이터 쪽에서 이걸 조사한 적이 있어요.