90년대 마이크로소프트 윈도에 도전장을 내민 신예 지오웍스 (2016)

요약

가볍고 싼 PC에서도 잘 돌던 지오웍스는 윈도에 밀렸지만 PDA와 초기 스마트폰에서 명맥을 이었습니다.

뉴스레터 Tedium을 쓰는 어니 스미스가 2016년 아틀라스 옵스큐라에 옮겨 실은 글입니다. 어린 시절 386 PC에 깔려 있던 지오웍스를 떠올리며, 윈도의 승리가 아직 확실하지 않았던 90년대 초를 돌아봤습니다.

왜 중요한가

기술이 앞서도 외부 개발자를 모으지 못하면 시장을 얻기 어렵다는 점을 보여 주는 사례입니다.
실패한 운영체제도 사라지지 않고 다른 기기에서 여러 번 되살아날 수 있다는 점을 짚었습니다.

핵심 내용

Commodore 64용 GEOS에서 출발해 아주 가벼웠고, 윈도 3.1이 486을 원할 때 286·386에서도 안정적으로 돌았습니다.
개발하려면 7,000달러짜리 썬 워크스테이션이 필요해서 서드파티 앱(외부 회사가 만든 앱)이 거의 나오지 않았습니다.
AOL의 전신인 퀀텀 컴퓨터 서비시스가 지오웍스로 첫 온라인 서비스를 만들었고, 초기 AOL 디스크에도 지오웍스 축소판이 들어갔습니다.
PC에서 밀린 뒤에도 Tandy Zoomer PDA, Nokia 9000 Communicator 스마트폰, 브라더의 전자 타자기와 GeoBook에 쓰였습니다.
글을 쓴 2016년에는 마지막으로 코드를 관리하던 브레드박스가 창업자의 갑작스러운 죽음으로 멈춰 서서 앞날이 불투명했습니다.

HN 반응

적은 용량으로 많은 일을 했다는 칭찬이 나왔고, 8086 어셈블리 1,500만 줄이 발목을 잡았다는 전직 개발자 스티브 예기의 회고도 소개됐습니다.
공개된 PC/GEOS 소스를 라즈베리 파이 등으로 옮기자는 제안에는 거의 전부 x86 어셈블리라서 사실상 새로 써야 한다는 반론이 붙었습니다.

21개 표시 · 전체 21개

twotwotwo1일 전 HN

옛날 소프트웨어가 얼마나 빨랐는지는 흔히들 이야기하지만, 제가 보기에 GeoWorks에서 눈에 띄는 점은 많은 일을 하면서도 얼마나 작았는가입니다.

물론 요즘 소프트웨어를 더 크게 만드는 것 중에는 없이는 도저히 못 살 것들이 많습니다. 완전한 유니코드 지원, 접근성, 영리한 렌더링, 사용성 개선 같은 것들이죠. 하지만 우리가 딛고 선 '토대' 자체도 더 높아졌습니다. 웹 플랫폼과 여러 네이티브 툴킷이 기본으로 많은 것을 제공하니까요. (물론 지금은 사실상 표준이 된 위젯을 플랫폼이 전부 갖추고 있지는 않아서, 어차피 그 위에 많은 것을 쌓아야 하긴 합니다.)

너무 비대해지지 않으면서 가져다 쓸 수 있는 유용한 서드파티 라이브러리도 아주 많고, 그때는 비대했겠지만 지금은 그렇지 않은 것도 많습니다. 90년대라면 딱히 필요하지도 않은 SQL DB를 내장하지는 않았겠지만, 지금은 SQLite가 꽤 안전한 의존성이죠.

딱히 어딘가를 겨냥해서 하는 말은 아니지만, 수십 년 사이에 상황과 수치가 많이 바뀌었어도 "코드량 대비 기능의 비율을 어떻게 좋게 유지할 것인가"는 여전히 상위 수준의 설계 결정을 바라보는 흥미로운 관점이 될 수 있다고 생각합니다.
WillAdams1일 전 HN

그에 대한 고전적인 답변입니다.

https://www.folklore.org/Negative_2000_Lines_Of_Code.html
jmspring1일 전 HN

요즘은 LLM한테 러스트로 다시 짜게 시키죠. </s>

요즘 소프트웨어는 그때에 비하면 비대해요. 그때는 메모리 제약도 있었고 프로세서 제약도 있었으니까요. RamAltman 뜻대로 되면 아마 우리는 다시 그래야 하는 처지로 돌아가게 될 거예요.
olivierestsage1일 전 HN

진심으로 관심을 갖고 읽어 보려 했는데, 광고 때문에 페이지가 네 번이나 새로 고침되길래 포기했어요. 댓글창에서 광고 불평이나 늘어놓는 건 별로 좋아하지 않지만, 아니 진짜, 정신 좀 차리세요.
WillAdams1일 전 HN

밑바탕 기술이 궁금하신 분들은 이걸 보세요.

https://github.com/bluewaysw/pcgeos

(라즈베리 파이로 포팅되는 걸 보고 싶습니다. 수정: 아니면 요즘 하드웨어에서 쉽게 돌릴 수 있게 업데이트되면 좋겠습니다.)
Lerc1일 전 HN

PI Pico로 포팅하려면 뭐가 필요할지 살펴본 적이 있습니다.

충분히 가능하다고 봅니다. 크기와 메모리 모델이 거의 이상적으로 들어맞습니다.

PSRAM을 붙인 rp2350에 SD 카드를 하드디스크 삼으면 꽤 쓸 만한 구현이 가능할 겁니다.

거의 전부 어셈블리라서 코드 포팅이라기보다는 아키텍처 포팅에 가깝습니다.
raphlinus1일 전 HN

안녕하세요! 저도 비슷한 걸 하고 있어요. vic-2350이요. 다만 기존 시스템을 포팅하는 건 아니고, 지금 우리가 가진 하드웨어의 제약에 맞춰서 만드는 중입니다.
Lerc17시간 전 HN
제가 작업 중인 것들을 보여드리려던 참이었습니다.

이건 스캔라인 단위로 그리는 제 렌더러입니다.

https://fingswotidun.com/cruft/2350LCD_5.mp4

텍스트 모드는 ARM 코어로 스캔라인마다 생성합니다. 타일, 이미지, 스프라이트 레이어는 전부 DMA+PIO로 생성하고요.

그래서 타일 레이어는 이런 구조가 됩니다.
```
         TileMapDMA
             |
             V
        TileIndexPIO
             |
             V
        TileDataDMA
             |
             V
     UnpackPixelIndex_PIO
             |
             V
      PaletteReadDMA
             |
             V
      TransparencyPIO   <-- ScanlineBufferReadDMA
             |
             V
   ScanlineBufferWriteDMA    (Yes this was as hard to debug as it looks)
```
팔레트 방식 타일셋을 쓰는 타일 맵 전체가 체인으로 연결된 DMA 연산 한 번으로 처리되고, 다른 레이어는 조금 더 단순합니다. 디스플레이 전체를 CPU 없이 생성할 수도 있겠지만, 그러면 디스플레이 디스크립터가 차지하는 메모리가 너무 커집니다. 그래서 스캔라인이 시작될 때마다 간단한 인터럽트로 스캔라인마다 바뀌는 소스·목적지 주소의 DMA 디스크립터 포인터를 갱신합니다.

텍스트 모드도 CPU 없이 돌려 본 적이 있는데, 속성 색상 조회 때문에 맵 조회가 하나 더 붙어서 번거로웠습니다. 지금은 스캔라인마다 CPU 시간을 조금 써서 문자 읽기, 속성 읽기, 폰트 읽기를 거쳐 바이트당 색상이 하나씩 붙은 1비트/픽셀 이미지로 변환합니다.

이쪽이 성능이 더 좋습니다. CPU가 일을 조금 더 하긴 해도 스캔라인 렌더링이 더 빨라지니까요. 모든 레이어가 하나의 스캔라인 버퍼에 렌더링되기 때문에 시간이 허락하는 만큼 레이어를 쌓을 수 있는데, CPU를 전혀 안 쓴다 해도 여전히 시간이 너무 오래 걸리면 소용이 없습니다.
cmrdporcupine1일 전 HN

그런데 전부 x86 어셈블리예요. '포팅'하려면 ARM64로 완전히 다시 짜야 하는 거죠.
ranger_danger1일 전 HN

말하자면 AI 프롬프트 한 방이면 된다는 거죠.
DrJokepu1일 전 HN

글쎄요. Claude도 Codex도 16비트 리얼 모드 8086 어셈블리는 그렇게 잘하지 못해요.
cmrdporcupine1일 전 HN

그럴 수도 있겠지만, 다 하고 나면 완전히 허무할 것 같기도 해요. 영혼 없는 하룻밤 상대처럼요 :-)

그냥 에뮬레이터로 돌려도 되고요.
ranger_danger1일 전 HN

코딩하는 이유는 사람마다 다릅니다.

어떤 사람에게 '요점'은 그저 문제를 푸는 것이고, 그 방법은 중요하지 않습니다.

또 어떤 사람에게 코딩은 예술이어서, 자신의 지식과 경험으로 아무나 할 수 없는 특별한 일을 해냄으로써 자기 가치를 느낍니다.

어느 쪽이 옳고 그른 것은 아닙니다. 사람마다 목표가 다를 뿐입니다.
RajT881일 전 HN

저는 뛰어난 프로그래머도 아니고, 큰 개인 프로젝트를 끝까지 해낼 집중력도 분명히 없습니다. 하지만 제가 원하는 아키텍처와 UI의 모양새, 그리고 전체가 어떻게 동작해야 하는지는 Claude에게 잘 설명할 수 있습니다.

제 홈랩에서는 멋지고 놀랍고 쓸모 있는, 세상에 하나뿐인 것들이 돌아가고 있습니다. 기분이 정말 좋습니다.
cmrdporcupine1일 전 HN

오해하지는 마세요. 저는 늘 만드는 재미로 만들고 덕질을 해 왔고, 이제는 AI로 그걸 더 많이 할 뿐이에요. 반대하는 게 아니에요.

예를 들면 이거예요. https://github.com/rdaum/rekursiv/ 25년째 책장에 꽂아 둔 책 한 권을 보고 불쑥 만든 거고요.

요즘은 해낼 수 있는 일의 양이 말도 안 돼요.

제 말은 이것만큼은 x86 어셈블리라서 '포팅'이 아니라 다시 짜는 거라는 거예요. 그럴 거면 왜 하필 이걸 하나 싶기도 하고요? :)
andsoitis1일 전 HN

그런데 AI로 빠르게 포팅하고, 그다음에 AI로 기능을 확장하고 세부를 다듬고 하는 걸 상상해 보세요. 예를 들어 저라면 그게 아주 흡족할 것 같아요.
RajT881일 전 HN

와! 어릴 때 GEOS를 썼는데 이해를 못 했던 기억이 나네요. ㅋㅋ

그때까지는 소프트웨어를 명령줄로만 돌려 봤거든요. 우리 집 첫 윈도 컴퓨터는 몇 년 뒤에나 들어왔고요(386에 win 3.11).
paulryanrogers1일 전 HN

90년대에 호기심에 한번 써 봤습니다. 윈도 3과 비슷한 테마가 있었던 걸로 기억합니다. 하지만 제가 뭔가 만들 때 쓰던 프로그램들이 없어서 윈도로 돌아갔습니다.

기억이 맞다면 OS 셸치고는 성능이 꽤 좋았습니다.
LocalH1일 전 HN

조심하세요. nokiamuseum dot info 링크는 뭔가 수상한 걸 다운로드하려 해요.
ChrisArchitect1일 전 HN

(2016)

이전 논의와 관련 논의입니다.

2017 https://news.ycombinator.com/item?id=14748209

GeoWorks: The Other Windows (2019)

2024 https://news.ycombinator.com/item?id=41373650

2021 https://news.ycombinator.com/item?id=29402609
Modified30191일 전 HN

GEOS 같은 건 제 시대보다 조금 앞선 것이었고, 제가 GeoWorks를 아는 건 주로 2003년 고등학생 때 "Wyvern"( https://web.archive.org/web/20030212212420/http://www.cabochon.com/ )을 많이 했기 때문입니다. 주로 스티브 예기가 만든 온라인 2D RPG였는데, 초기에 GeoWorks 관련 사람들이 상당히 기여한 듯했고 그 이름이 가끔 눈에 띄었습니다.

재미있어 하실 만한 GEOS/GeoWorks 관련 인터넷 고고학 자료를 소개합니다.

GEOS 소프트웨어 라이브러리: https://web.archive.org/web/20021203000244/http://www.tvakatter.org/about.php ("Två Katter"는 스웨덴어로 고양이 두 마리라는 뜻으로, tucows.com을 비튼 이름입니다)

GeoWorks Ensemble 2.0 출시 파티 영상, CEO 브라이언 도허티 출연: https://www.youtube.com/watch?v=wOImkzTyJ7s "Geoworks - Brian's Got A Brand New Bag"

스티브가 자신이 GeoWorks에서 일했다고 짧게 언급하면서, GeoWorks가 결국 변화를 따라가지 못한 이유가 무엇이라고 생각하는지(생각했는지) 이야기합니다. https://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

저는 워싱턴 대학교를 다녔고, [그 뒤에] Geoworks라는 회사에 들어가 어셈블리어 프로그래밍을 5년 했습니다. 우리 Geoworker들은 운영체제 전체와 라이브러리, 드라이버, 앱까지 다 썼습니다. 그러니까 데스크톱 운영체제를 어셈블리로요. 8086 어셈블리로! 좋은 어셈블리도 아니었습니다! 레지스터가 네 개뿐이었어요! 386까지 쳐 주면 si [레지스터]도 있었겠지만요, 아시죠? 끔찍했습니다.

사실 우리는 그게 좋았습니다. 객체지향 어셈블리였으니까요. 사람이 뭐든 스스로 좋아하게 만들 수 있다는 게 놀랍습니다. 이게 이 모든 일의 진짜 아이러니죠. 그리고 우리에게 C++는 로마식 퇴폐의 극치였습니다. 더 먹으려고 토하러 가는 거나 마찬가지였죠. 그쪽에는 IF가 있었습니다! 우리한테는 jump CX zero가 있었는데요! 그쪽에는 "객체"가 있었죠. 우리도 있었지만, 그쪽에는 그걸 위한 문법이 있었다는 겁니다, 아시겠어요? 전부 그저 찌질한 짓이었습니다. 게다가 우리는 어떤 컴파일러보다도 빠른 코드를 짤 수 있다는 걸 알았습니다. 그때는 실제로 그랬으니까요!

그래서 어떻게 됐을까요? 파산했습니다. 왜일까요? 아마 저는 지금 Geoworker 모두와 의견이 다를 텐데, 확실히 압니다. 이렇게 믿는 사람은 저뿐입니다. 하지만 이유는 우리가 8086 어셈블리어를 1,500만 줄이나 썼기 때문입니다. 정말 좋은 도구가 있었습니다. 세계 최고 수준의 도구였죠. 믿으세요, 그런 게 필요합니다. 하지만 어느 시점에 가면, 이봐요...

문제는 이겁니다. 개미 한 마리가 차고 바닥을 가로질러 가는데, 일직선으로 가려 한다고 상상해 보세요. 일직선으로는 못 갑니다. 여러분은 전체를 보는 시야가 있으니 그걸 압니다. 개미가 돌아다니는 걸 보면서 "히히히, 저 돌멩이 피하려고 국소 최적화하는 것 좀 봐, 이제 저쪽으로 가네" 하고 웃을 수 있죠.

우리가 이 거대한 어셈블리어 시스템을 쓰면서 딱 그 꼴이었습니다. 결국 마이크로소프트가 우리 것보다 훨씬 빠른 모바일 기기용 플랫폼을 내놨거든요. 아시겠어요? 그래서 디버거를 들고 들어가 보면서 이랬죠. 뭐야? 이게 어떻게 된 거지? 렌더링이 정말 느리네, 굼뜨네. 그러다 화면을 새로 고칠 때마다 어떤 제목 표시줄이 140번이나 렌더링되고 있다는 걸 알게 됐습니다. 제목 표시줄만이 아니었습니다. 모든 게 여러 번씩 호출되고 있었습니다.

시스템이 어떻게 돌아가는지 더는 우리 눈으로 볼 수 없었기 때문입니다!

Hacker News에서 보기 ↗