64비트 윈도에서 돌아가는 16비트 윈도(윈도 1.x, 2.x, 3.0, 3.1 등)

요약

16비트 윈도 프로그램을 64비트 윈도에서 바로 실행하게 해 주는 오픈소스 도구입니다.

개발자 otya128이 16비트 윈도 에뮬레이터인 winevdm을 고쳐 64비트 윈도로 옮긴 프로젝트입니다. 64비트 윈도는 윈도 1.x부터 3.1 시절의 16비트 프로그램을 아예 실행하지 못합니다.

왜 중요한가

30년 전 윈도 프로그램을 가상 머신 없이 지금 쓰는 윈도에서 띄울 수 있습니다.
64비트 윈도가 16비트 설치 프로그램을 만나면 이 도구로 넘기므로, 설치 단계에서 막히던 옛 소프트웨어도 설치할 수 있습니다.

핵심 내용

64비트 윈도는 LDT(16비트 프로그램이 쓰는 메모리 구획 표)를 고칠 수 없어서 CPU를 에뮬레이션하는 방식으로 돌립니다.
16비트 윈도 API 호출은 Wine(리눅스 등에서 윈도 프로그램을 돌리는 호환 계층)의 코드를 바탕으로 32비트 API로 바꿔 줍니다.
16비트 핸들(창·파일 등을 가리키는 식별값)과 64비트 윈도의 핸들도 서로 바꿔 줍니다.
옛 프로그램이 윈도 폴더에 설정 파일을 쓰려 하면 요즘 윈도가 막기 때문에, 그 쓰기를 다른 곳으로 돌려 줍니다.
도스 프로그램도 실행할 수 있지만 완성도가 낮아 DOSBox 같은 다른 도구를 권합니다.

HN 반응

마이크로소프트가 직접 이런 호환 계층을 넣었어야 했다는 의견에, 64비트 핸들을 16비트로 줄일 수 없다는 공식 설명이 반론으로 나왔습니다.
MS Office 2.0을 설치해 일주일 써 보니 이메일 같은 일상 문서 작업에 충분했다는 사용기에 여러 이용자가 공감했습니다.

30개 표시 · 전체 34개

londons_explore1일 전 HN

마이크로소프트가 64비트 윈도를 내놓을 때 왜 이걸 안 만들었는지 정말 이해가 안 돼요.

16비트 윈도는 복잡하지 않았어요. 간단한 VM과 API 변환 계층만 있었어도 30년 넘게 호환성을 유지할 수 있었을 텐데, 들어가는 엔지니어링 시간은 그리 많지 않았을 거고요.

그런데 16비트 윈도 지원을 끊고 나니, 낡은 소프트웨어를 어떻게든 업데이트하려는 데 아마 더 많은 엔지니어링 시간이 들었을 테고, 그 낡은 소프트웨어가 필요해서 윈도 업그레이드를 미룬 사용자들도 있었겠죠.
xacky1일 전 HN

하위 호환성에도 한계가 있습니다. 30년 동안 방치된 소프트웨어를 지원해서 얻는 상업적 가치는 거의 없습니다. 애플, 구글, 심지어 리눅스도 지원을 훨씬 공격적으로 끊습니다. 비용이 얼마가 들든 하위 호환성을 지키려는 곳은 수백만 달러짜리 계약을 가진 메인프레임의 IBM 정도뿐입니다.
my1231일 전 HN

특히 COM/OLE 통합 때문에 16비트와 32비트 경계를 넘어 HANDLE을 주고받는 일이 훨씬 골치 아파집니다.

마이크로소프트는 https://learn.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications 에서 이렇게 설명합니다.

64비트 윈도는 16비트 윈도 기반 애플리케이션 실행을 지원하지 않는다는 점에 유의하십시오. 주된 이유는 64비트 윈도에서 핸들이 32비트의 유효 비트를 갖기 때문입니다. 따라서 핸들을 잘라서 16비트 애플리케이션에 넘기면 데이터 손실이 생깁니다. 16비트 애플리케이션을 실행하려 하면 ERROR_BAD_EXE_FORMAT 오류와 함께 실패합니다.

윈도의 winevdm은 그 수준의 통합을 포기했지만, 아무것도 안 내놓느니 MS가 제한이 있더라도 WoW16을 내놓았어야 했는지도 모릅니다.
vintagedave1일 전 HN
이런 호환 계층을 만들어 본 적 없는 사람의 순진한 질문입니다. VDM이 핸들을 매핑할 수는 없나요? 핸들은 불투명한 값이잖아요. 값을 바꿔서, 말하자면 16비트 테이블을 두고 호스트 OS의 실제 32/64비트 핸들에 대응시키면 되지 않을까요?

수정: readme에 아주 비슷한 내용이 있네요.
```
    wine based Win16->Win32 conversion codes:
    BOOL16 WINAPI DestroyWindow16( HWND16 hwnd )
    {
        return DestroyWindow( WIN_Handle32(hwnd) );
    }
```
WIN_Handle32 메서드/매크로가 바로 그 일을 하는 것 같습니다.
my1231일 전 HN

어느 정도 매핑을 시도했지만 잘 풀리지 않았던 모양입니다. https://www.vttoth.com/CMS/technical-notes/?view=article&id=33
lupical1일 전 HN

반대로, 16비트 애플리케이션을 쓰는 회사라면 어차피 64비트 설치로 업그레이드하려 하지 않았을 거라고 봅니다. 32비트 윈도는 95 때부터 이미 있었으니, 마이크로소프트는 소프트웨어 개발자들이 Win32로 넘어오도록 밀어붙이는 편이 낫다고 판단한 겁니다.
da_chicken1일 전 HN

맞는 말이지만, 16비트 프로그램 중 가장 많이 쓰이던 건 아마 setup.exe나 install.exe였을 겁니다. 오랫동안 모든 소프트웨어 패키지를 16비트 설치 프로그램으로 배포하는 게 흔했어요. (조금이나마) 크기가 작고, 32비트 처리가 필요한 작업은 어차피 하지 않으니까요.

그래서 지금도 2005년쯤까지 나온 소프트웨어 중에 실제로는 32비트 소프트웨어인데 설치 프로그램만 16비트인 경우가 드물지 않습니다.

사실 제가 돌려 보고 싶었던 16비트 애플리케이션은 Castle of the Winds와 Scorched Earth를 빼면 이것밖에 없을 정도입니다.
masfuerte1일 전 HN

별로 중요하진 않지만, MS가 16비트 설치 프로그램을 권장한 이유는 인텔이 아닌 윈도 NT 변종들이 에뮬레이션으로 16비트 x86 소프트웨어를 실행할 수 있었기 때문입니다. 여러 아키텍처에서 돌아가는 윈도 소프트웨어(많지는 않았지만)는 보통 아키텍처를 확인하고 네이티브 32비트 설치 프로그램을 실행하는 아주 작은 16비트 x86 설치 프로그램을 두었습니다.

추가: x86 전용 소프트웨어도 비슷하게 작은 16비트 설치 프로그램을 두어, x86에서는 32비트 설치 프로그램을 실행하고 다른 아키텍처에서는 친절한 오류 메시지를 보여 줬습니다. 윈도가 엉뚱한 아키텍처에서 32비트 exe를 실행했을 때 내놓는 오류 메시지가 형편없었기 때문입니다.
haunter1일 전 HN

몇 달 전에 재미 삼아 이걸로 MS Office 2.0을 설치해 봤어요. 사전 파일만 빼면 꽤 잘 돌아갑니다. 사전 파일은 왜인지 인식이 안 되더라고요.

https://files.catbox.moe/dy4bqy.png

궁금해서 일주일 동안 써 봤는데요.

1, 요즘 일상적인 문서 작성(주로 이메일)에 쓰기에 충분한가? 네, 충분합니다.

2, 요즘 워드 프로세서(Office 365, LibreOffice, Google Docs)가 여기서 만든 파일(doc, rtf 등 일반 텍스트가 아닌 것)을 인식해서 열 수 있나? 네, 열 수 있어요.
pjmlp1일 전 HN

업무용으로는 다른 요구 사항 때문에 어렵겠지만, 개인 문서라면 첫 번째 말씀에 전적으로 동의합니다. MS Office 2.0은 손으로 부치는 편지나 학교 보고서, 이력서를 쓰기에 충분히 좋습니다.
haunter1일 전 HN

보안 문제도 있죠. 그냥 제 추측인데, 이런 오래된 16비트 파일 형식은 어느 정도는 다 악용될 수 있을 것 같아요.
pjmlp1일 전 HN

맞습니다. 다만 어차피 종이로 보낼 문서를 쓰는 현대판 타자기처럼 혼자서만 쓴다면 걱정이 덜합니다.

다른 사람과 파일을 공유하는 건 별개의 문제이고, 그 부분은 전적으로 동의합니다.
londons_explore1일 전 HN

같은 VM에 중요한 ssh 키를 저장해 두지는 않겠죠.
ale421일 전 HN

제가 알기로는 VM이 아니에요. OTVDM일 가능성이 높아요.
pjmlp1일 전 HN

일부 오프쇼어링 프로젝트가 어떻게 굴러가는지 알면 놀라실 겁니다. 어쨌든 제가 하던 이야기와는 전혀 상관없는 말씀이고요.
spider-mario1일 전 HN

게다가 요즘의 거대한 괴물 같은 프로그램들에 비하면 UI가 신선할 만큼 단순하죠.
ant6n1일 전 HN

놀라운 건, 16GB 맥북에서 오피스 창을 10개만 띄워도 시스템이 완전히 무릎을 꿇는다는 거예요.

그런데 기능만 보면 대부분의 용도는 늦어도 Office 95 정도면 거의 다 갖춰져 있었잖아요(동기화는 빼고요).

요즘 소프트웨어는 25년 전 소프트웨어보다 자원을 1000배나 쓰면서, 쓸 만한 기능은 겨우 조금 늘었을 뿐인 이유가 뭘까요?
gabmartini1일 전 HN

좋네요, 이제 윈도 11에서 Civ2를 할 수 있겠어요!

관련 소식으로, 리눅스에서는 최신 WINE으로 16비트/32비트 애플리케이션이 지원돼서 제가 사랑하는 Civilization 2도 문제없이 돌렸어요.
krige1일 전 HN

Civ2도, 적어도 Test of Time 판은 외부 도구 없이 돌아가도록 따로 패치가 나와 있어요.
yako210001일 전 HN

세상에, 윈도 3.1x라니... 좋았던 옛날이네요. 절대 죽지 않던 워드 프로그램도 있었고요!
tonyedgecombe1일 전 HN

절대 죽지 않던 워드 프로그램도 있었고요!

저랑은 다른 세상에 사셨나 보네요.
yako210001일 전 HN

하하, 적어도 제가 그때 워드를 쓰던 용도로는 윈도 3.1x에서 죽지 않았어요. 그래도 그땐 많이 어렸으니까 대단한 건 안 했죠.
gschizas1일 전 HN

윈도 3.x는 항상 죽었습니다. 죽지 않을 때도 리소스인지 메모리인지 뭔가가 계속 가득 찼고요. 윈도 95(완벽하진 않았죠, 한참 멀었습니다)를 설치했을 때 친구가 "그래서 재부팅은 얼마나 자주 해?"라고 물었는데, 그제야 제가 윈도 3.11을 하루에도 몇 번씩 "재부팅"했다는 걸 깨달았습니다. 메모리가 차서 어쩔 수 없이 그래야 했던 거죠.

그때 윈도 3.x에서 메모리를 감시하려고 계속 띄워 두던 프로그램이 있었는데(L로 시작했다는 것 말고는 이름이 기억나지 않지만, 집에서 인터넷을 쓰기 시작한 게 1996년 이후였으니 분명 잡지에서 얻었을 겁니다), 작업 관리자 겸 실행기로도 쓸 만했습니다. 윈도 95로 넘어간 뒤로는 쓰지 않았습니다.
yako210001일 전 HN

오, 흥미롭네요. 저희 아버지 노트북이었는데, 아버지는 수업용으로만 쓰셨어요(프랑스어 선생님이셨거든요). 그래서 거의 워드만 쓰셨고 가끔 지뢰찾기를 했고, 저도 자주 글을 썼어요. 그래도 대단한 작업은 아니었어요. 그래서 메모리 문제는 겪어 본 적이 없는데, 세상에, 플로피 디스크는 정말 많았어요!
tcsenpai1일 전 HN

64비트 윈도에는 16비트 윈도를 딱 네 개 넣을 수 있어요.
Grimeton1일 전 HN

16비트 지원은 윈도 2008에서 제거됐습니다. "DOS" 지원(NTVDM)만 사라진 게 아닙니다. 2k8에서 마지막 남은 OS/2와 SFU 계층도 같이 없앴던 걸로 기억합니다.
1970-01-011일 전 HN

네이티브로 돌린다는 게 핵심인 건 알지만, 아주 가벼운 VM 안에서 돌려도 되잖아요.
orionblastar2일 전 HN

드디어 64비트 윈도에서 16비트 윈도를 지원하는군요.
bitwize1일 전 HN

Winevdm은 나온 지 꽤 됐어요.
mschuster911일 전 HN

잠깐 또 하나 더 AI 쓰레기 "recomp"나 qemu 같은 억지 해킹일까 봐 겁먹었는데, 이건 진짜더군요. 쓰레기 같은 게 유행하기 오래전부터 있던 프로젝트고요.

멋진 작업이네요.

Hacker News에서 보기 ↗