MS-DOS 2.0, IBM의 압박 속에서 태어난 '원치 않는 아이'
The Road to MS-DOS 2.0
MS-DOS는 원래 '임시방편'으로 만들어진 운영체제였지만, IBM PC XT의 등장과 함께 재탄생해야 했습니다. IBM은 단순히 하드디스크 지원만 원했지만, Paul Allen은 계층적 파일 시스템, 동적 드라이버 로딩, 백그라운드 스풀링 등 UNIX에서 영감을 받은 대대적인 개편을 추진했습니다. IBM과의 갈등 속에서 Allen의 팀은 6명만으로 MS-DOS 2.0을 완성했고, 이는 단일 작업 OS의 한계를 뛰어넘는 중요한 전환점이 되었습니다.
IBM은 DOS 2.0을 DOS 1.1의 8,000바이트에 최대한 가깝게 유지하기로 했습니다. 기존 사용자 기반을 방해하지 않기 위해서였죠. 우리의 새 DOS가 너무 많은 메모리를 차지하면, 작은 PC 시스템에서 인기 있는 응용 프로그램을 실행할 공간이 부족해질까 봐 IBM은 두려워했습니다.
HN 토론
56- add2
이 글은 정말 통찰력이 있네요. 유닉스 머신(특히 XENIX, 주로 셸 스크립트 작성과 파일 시스템 탐색에 사용)으로 성장하고 MS-DOS에서 어셈블리로 프로그래밍하면서, MS-DOS의 작동 방식과 유닉스의 작동 방식 사이에 이상할 정도로 평행을 이루는 점을 자주 볼 수 있었습니다. 저는 그냥 MSFT 프로그래머들이 유닉스를 사용해 본 적이 있고 DOS에 그 기능과 관용구를 가져오고 싶어했다고 생각했습니다. XENIX가 MSFT 라이선스의 유닉스 파생판이라는 것을 알면서도, DOS에 있는 그 모호한 유닉스 '풍미'에 더 직접적인 영감이 있을 수 있다는 생각은 전혀 하지 못했습니다.
저는 CP/M 프로그래밍을 해본 적이 없어서, MS-DOS의 FCB 기반 파일 조작 API는 그저 이상한 오래된 잡동사니처럼 보였습니다. CP/M에 노출되었더라면 핸들 기반 API 뒤에 있는 유닉스 영감이 훨씬 더 분명했을 것입니다. (저는 MS-DOS 3.3 시절쯤에 시작했습니다...)
MSFT가 IBM이 유닉스 경로 구분자를 채택하도록 설득했다면 얼마나 이상한 세상이 되었을까요.
- pjmlp
예상치 못하게도, MS-DOS 2.0에는 /dev 디렉토리가 포함되어 있었습니다.
https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...
- markus_zhang
며칠 전 밤에 MS-DOS 5.0에서 8086 16비트 어셈블리를 독학하고 있었습니다. CGA에 컬러 블록을 표시하는 것이 정말 재미있었습니다.
그럼에도 불구하고, 어셈블리로 시스템 코드를 작성하는 것은 많은 불면증과 다른 부작용을 일으킬 수 있었을 것입니다. 특히 마이크로소프트가 IBM PC에서 지배적인 세력이 되기 훨씬 전에는 더욱 그랬을 것입니다.