30년 된 노트북에서 파일 복사하는 방법

 (unterminated.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • 1994년형 Apple PowerBook Duo 280c에 남은 짧은 오디오 녹음을 보존해야 했지만, 오디오 출력·플로피·네트워크·디스크 어댑터가 모두 막혀 팩스 전송이 우회 경로가 됨
  • ResEdit의 헥스 에디터로 오디오 파일을 16진수 텍스트로 열고, Microsoft Word에 붙여 넣은 뒤 프린트 대화상자의 팩스 기능으로 보냄
  • 수신은 Windows XP가 설치된 ThinkPad T60의 내장 모뎀과 팩스 앱이 맡았고, 두 노트북을 직접 전화선으로 잇는 대신 9V 배터리 기반 전화선 시뮬레이터 회로가 필요했음
  • TIF 팩스 이미지를 OCR로 되돌리는 방식은 0/C, 9/4, 0/D 오인식과 누락·삽입 오류 때문에 오디오에 크랙링과 팝 노이즈를 남김
  • 결국 고정폭 글자 격자를 직접 분석하는 FaxToBinary 도구를 만들어 문자 패턴을 수동 학습시켰고, 원본과 바이트 단위로 일치하는 오디오 파일을 복구함

막혀 있던 복사 경로

  • 대상 기기는 1994년형 PowerBook Duo 280c였고, 내부에는 보존하려는 짧은 오디오 녹음 몇 개가 들어 있었음
  • 다행히 노트북은 아직 부팅됐고, 하드드라이브를 살짝 두드리면 회전했으며, 오디오 파일은 내부 스피커로 재생 가능했음
  • 일반적인 복사 방법은 하나씩 막혔음
    • 오디오 잭이 없어 좋은 품질의 아날로그 복사가 어려웠음
    • 내부 하드드라이브는 특이한 커넥터의 SCSI를 사용했고, 최신 시스템에서 오래된 HFS 파일 시스템을 쉽게 읽을 수 있을지도 불확실했음
    • 외장 플로피 드라이브를 연결하면 컴퓨터가 동작하지 않았고, 고장 원인도 찾지 못했음
    • AppleTalk 포트와 전화 잭은 있었지만 네트워킹 소프트웨어가 설치되어 있지 않았음
  • HTTP는 1996년에야 확정됐고, 해당 노트북에는 당시 사용 가능했을 전화 접속용 소프트웨어도 없었음
  • 대신 전화 다이얼러와 팩스 소프트웨어가 남아 있어 모뎀을 이용한 우회가 가능해짐

파일을 팩스 문서로 바꾸기

  • 노트북에는 게임들과 함께 리소스 편집기 ResEdit가 설치되어 있었고, 이 도구의 헥스 에디터로 파일의 원시 내용을 16진수로 볼 수 있었음
  • ResEdit는 출력 기능을 지원하지 않아, 16진수 텍스트를 다른 앱으로 옮겨야 했음
  • 예시 오디오 파일은 37,928바이트였고, 각 바이트가 두 글자의 16진수로 표시되므로 텍스트 표현은 그 두 배 길이가 됨
  • 한 번에 다룰 수 있는 크기에 제한이 있어 파일을 나누어 복사했고, 오프셋을 기억하기 쉬운 12288바이트, 즉 0x3000 단위로 처리함
  • 클립보드로 복사한 16진수 텍스트는 Microsoft Word 문서에 그대로 붙여 넣을 수 있었고, Word는 출력 기능을 제공했음
  • 파일들은 모두 100KB 미만이었고, ResEdit에서 Word로 클립보드를 통해 수동 복사하는 속도는 평균 약 316바이트/초로 추정됨

두 노트북 사이에 모의 전화선 만들기

  • 수신용 컴퓨터는 내장 전화 접속 모뎀이 있는 ThinkPad T60이었고, Windows XP의 팩스 앱은 들어오는 팩스를 다중 페이지 TIF 이미지로 저장할 수 있었음
  • 두 노트북을 전화 케이블로 직접 연결하는 방식은 실패함
    • PowerBook은 전화를 걸었지만 ThinkPad가 받지 않았음
    • “Ignore Dial Tone” 옵션도 효과가 없었음
  • 실제 유선 전화망이 제공하는 전압이 모뎀 동작에 중요했고, 이 문제는 phone line simulator circuit로 해결함
  • 이 회로는 흔한 전자 부품과 9V 배터리로 만들 수 있었고, 두 노트북 사이에 모의 전화선을 제공함
  • 팩스 전송에는 FCC 요구로 커버 페이지가 필요했고, 커버 페이지를 추가한 뒤 전송이 진행됨
  • 처음에는 래스터라이즈 후 전송 시간이 24분으로 예상됐지만, 글꼴 크기를 줄여 6페이지·7분으로 단축했고, 팩스는 14400bps로 ThinkPad에 수신됨

OCR로는 남는 오류

  • ThinkPad가 받은 팩스는 TIF 이미지였고, 이를 다시 바이너리 파일로 바꾸기 위해 먼저 PDF 변환과 OCR을 시도함
  • 팩스 이미지는 OCR에 유리해 보였음
    • 텍스트가 컴퓨터로 생성되어 정렬과 형태가 일정했음
    • 사용 문자는 0-9와 A-F의 16종류뿐이었음
    • Courier라는 흔한 고정폭 글꼴을 사용했음
  • OCR 결과 텍스트를 선택해 헥스 에디터에 복사하고 바이너리 파일로 저장할 수 있었음
  • Audacity는 결과 파일의 오디오 형식을 unsigned 8-bit PCM, little-endian, 22050Hz, mono로 추정했고 파형도 표시함
  • 재생은 대체로 괜찮았지만, 파형의 갑작스러운 딥이 OCR 전사 오류로 인한 크랙링 또는 팝 노이즈로 들렸음
  • 여러 OCR 프로그램과 글꼴 크기·글꼴 변경을 시도해도 100% 정확도에는 도달하지 못함
    • 0과 C, 9와 4, 0과 D를 혼동함
    • 문자를 누락하거나 새 문자를 삽입하는 경우도 있었음

FaxToBinary로 바이트 단위 복구

  • 팩스 이미지의 텍스트가 고정폭 글꼴로 생성됐기 때문에, 전체 문서를 일정한 간격의 문자 격자로 취급할 수 있었음
  • 시작점, 문자 오프셋, 줄 간격을 맞추면 각 문자를 개별적으로 캡처하고 분석 가능했음
  • 자체 도구는 왼쪽 미리보기로 크기와 오프셋 파라미터가 맞는지 확인하게 했고, 문자를 이동하거나 줄을 바꿔도 드리프트가 없으면 처리를 시작할 수 있었음
  • 문자 인식은 단순한 수동 학습 방식으로 동작함
    • 처음 보는 고유 패턴마다 사용자가 해당 문자가 무엇인지 지정함
    • 이후 같은 모양의 문자를 만나면 이전 답을 기억해 재사용함
  • 도구 소스는 FaxToBinary.zip으로 제공됨
  • 약간의 수동 학습 뒤 도구가 파일을 출력했고, 오디오는 팝 노이즈 없이 부드럽게 재생됐으며 원본과 바이트 단위로 일치하는 복사본이 됨
  • 파일 복구 뒤에는 해당 PowerBook에서 DOOM도 실행됨

함께 보면 좋은 글 β

kayws426   [-]

그냥 생각.

  • 30년된 파워북에 마이크로소프트 워드가 설치되어 있다니 놀라움.
  • OCR할려면 RAW-HEX코드가 아니라 체크섬이 제공되는 형태였어야함. ihex 또는 srecord 와 같은 간단한 포멧도 체크섬을 제공함.
  • 리눅스 가이였다면 전화를 걸어 zmodem으로 파일을 안전하게 전송했을것 이라고 예상함.
답변달기
GN⁺   [-]
Hacker News 의견들

  • 오래된 컴퓨터 잡지의 16진 덤프를 OCR하다가 비슷한 문제를 겪었고, OCR 결과를 검증하는 도구를 만들어 해결했음
    OCR 결과를 입력해 숫자를 분할하면, 원본에서 잘라낸 문자들을 분류별로 보여주고 사람이 눈으로 보면 “8” 그룹에 들어간 “3” 같은 오분류를 빠르게 찾을 수 있음
    https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
    https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
    관련 글을 두 개 썼고 도구도 글에 링크되어 있음. 다만 도구의 사용성은 sendmail보다 아주 조금 나은 정도임
    옛 Apple 노트북에 프로그래밍 환경이나 당시 Microsoft Word 비슷한 것이 있었는지는 모르지만, 하드웨어 해킹 없이도 더 나은 방법이 있었을 것 같음

    • 프로그래밍 환경은 물론 있었지만 내장되어 있지는 않았고, 여기서는 외장 플로피가 작동하지 않는 것이 핵심 문제였음
      더 나은 방법은 모뎀 포트로 팩스를 보내기보다 직렬 포트를 쓰는 것이었을 듯함. 직렬-USB 어댑터는 쉽게 구할 수 있음
    • 이 방식은 자동화 개선도 가능해 보임. 아마 40년 전 논문에 이미 있었는데 이름을 모르는 것일 수도 있음
      기본적으로 두 번째 패스에서 각 문자 그룹의 이상치를 찾아 다른 그룹으로 임시 재분류하고, 관련 그룹들의 유사도 점수가 좋아지면 유지한 뒤 더 이상 개선이 없을 때까지 반복하는 방식임
      예를 들어 “다른 3들과 가장 덜 닮은 3”을 찾아 임시로 “8”에 넣고, “3 조각들끼리 얼마나 닮았는가”와 “8 조각들끼리 얼마나 닮았는가” 점수가 좋아지면 그 변경을 유지할 수 있음
      다만 문서에 여러 서체가 섞여 있으면, 서로 다른 서체의 “3”을 한데 묶어 그룹 유사도 점수를 망치는 식으로 역효과가 날 수 있음
    • Word의 찾기/바꾸기로 OCR 혼동을 피하는 16개 문자 집합을 골라 쓸 수도 있었겠음
    • PGS 자막을 SRT로 바꿀 때 쓰던 OCR 앱이 떠오름. 단어와 글자를 묶어서 보여주고 사용자가 번역 결과를 승인하거나 고치게 했음

  • 그 노트북에 직렬(COM) 포트가 있지 않았나? 당시에는 거의 보편적이었고, 이 사이트 [1]에 따르면 두 개가 있었음
    Zmodem으로 풀면 간단했을 것이고, 터미널 소프트웨어도 이미 있었던 것 같음
    [1] https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...

    • xmodem이나 zmodem을 쓸 수 있고, macbinary 인코딩으로 원하는 파일을 양방향 전송할 수 있음
      다만 PowerBook 쪽에서 직렬 수신이 가능한 무언가가 필요함. ClarisWorks는 확실히 가능했고, Office에도 같은 “문서 받기” 기능이 있었을 가능성이 큼
      아니면 직렬 포트로 “인쇄”하고 직렬 출력을 캡처해도 됨. 사실상 단방향 텍스트 전송이지만, 글쓴이가 하려던 일에는 충분함
      그래도 팩스로 보내고 OCR하는 방식은 꽤 멋짐
    • 글쓴이임. 좋은 질문이고 아마 포트가 있었을 것 같지만, 솔직히 Zmodem에는 익숙하지 않음
      노트북에 터미널 앱이 설치되어 있었던 기억은 없지만, 충분히 찾아보지 않았을 수도 있음
    • 포트는 있었음. Home Alone에서 Kevin McCallister가 경찰에 전화할 수 있었던 것처럼, 글쓴이는 가장 단순한 해결책보다 특별한 이야기가 되기를 택한 것 같음
    • Apple은 직렬 포트에 8핀 mini DIN 커넥터를 썼기 때문에, 글쓴이가 맞는 케이블을 갖고 있지 않았을 수도 있음

  • 처음에는 오래된 노트북 화면을 사진으로 찍고 OCR할 줄 알았는데, 실제 방식이 훨씬 더 재미있었음
    그래도 큰 글꼴로 두고 전송에 24분을 쓰는 편이 더 빨랐을지도 모름. 업데이트된 OCR 소프트웨어를 작성하는 데 24분보다 더 걸렸을 가능성이 큼
    하지만 그랬다면 재미가 없었겠지

    • 글쓴이임. 깨끗한 컴퓨터 생성 텍스트를 상용 소프트웨어로 OCR하는 것조차 안정적으로 나오기 어려웠던 걸 보면, 사진 OCR은 더 신뢰하기 어려웠을 것 같음
      글에서는 간결하게 쓰려고 생략했지만, 실제로 여러 글꼴과 글자 크기를 한 페이지씩 시험하고 수동 검수했으며 큰 개선은 없었음
    • 예전에 Wayland 화면 공유 문제를 이런 식으로 해결한 적이 있음. [0]
      [0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
    • 이 나이대의 노트북이면 직렬 포트가 있어야 함. Win95 같은 환경에서도 널 모뎀과 TCP/IP를 올리고 SMB로 비교적 현대적인 OS에 파일을 복사할 수 있음
    • 글쓴이는 여러 글자 크기를 시도했다고 말했음

  • 젊을 때 CP/M 데스크톱에서 MS-DOS 휴대용 PC로 dBase 2 데이터베이스를 빼내야 했던 적이 있음
    직렬 케이블을 설정하고 PC에서 PROCOMM을 실행한 뒤 양쪽 포트를 9600/n/8/1로 맞추고, dBase 2에서 인쇄하면서 PROCOMM이 세션을 파일로 기록하게 했음
    플로피에 쓰기 위해 너무 오래 멈추지 않고 돌리면 문자가 유실되어서, CP/M 쪽에서 ctrl-s/q로 흐름을 제어했음
    그때는 아무도 이런 식으로 하는 법을 알아낸 적이 없었던 것 같음

    • 이 MacBook 사례에서는 적절한 소프트웨어가 없는 게 문제였던 것 같음
      그래도 모뎀이 설치되어 있었다면 터미널 소프트웨어도 있었어야 한다고 기억함

  • AppleTalk가 정답에 가까움. 드라이버가 내장되어 있고 Apple은 장기간 호환성을 잘 유지했음
    IIGS와 현대 장비 사이에서 파일을 옮길 때 비슷한 문제를 겪었는데, 플로피 에뮬레이터, SCSI, 원시 직렬도 가능하지만 AppleTalk와 이더넷을 모두 가진 Mac을 중간에 두면 대상 AppleTalk 기반 기기와 SMB 같은 공유 사이에서 전체 파일 계층을 드래그 앤 드롭으로 옮길 수 있어 단순함
    SCSI도 드라이브 커넥터와 종류를 알며 어댑터 몇 개를 체인으로 연결할 의지가 있으면 대체로 변환하기 쉬움. 2.5인치 SCSI 드라이브는 SCA 계열 커넥터였던 것으로 기억하고, 단일 종단/차동 규칙만 지키면 거의 무엇이든 서로 잇는 SCSI 어댑터가 있음
    문제는 오래된 Mac 파일 시스템을 읽을 OS나 도구를 찾는 일인데, 원시 이미지를 읽는 유틸리티 중 하나로 디스크 이미지를 읽고 쓸 수 있었을 듯함

    • 글쓴이가 HDD 모델과 PCB, 커넥터 사진을 제공했으면 좋았겠음
      아마 다른 곳에 연결해 데이터를 복사하는 일은 꽤 단순했을 가능성이 큼. 30년 넘은 하드웨어도 이런 식으로 자주 다루는 곳에서 일하는데, 핵심은 소프트웨어 해결책이라는 틀에서 벗어나는 것임
      이건 소프트웨어 문제가 아니고, 대부분 다른 종류의 전문성이 필요함
    • 글쓴이는 네트워킹 소프트웨어가 설치되어 있지 않았다고 했음
      SCSI 변환은 나도 같은 생각을 했고, 글쓴이는 HFS 볼륨을 읽을 수 있을지 확신하지 못했다고 했지만 Linux에는 이미 수십 년째 HFS 드라이버가 있음
    • 내부 커넥터 문제를 제쳐두면, 대부분의 Mac 노트북과 모든 현대 Mac에는 내부 하드디스크를 외부 SCSI, FireWire, Thunderbolt, USB 장치처럼 노출해 다른 컴퓨터에 마운트할 수 있는 Target Mode가 있음
      이 경우 PowerBook Duo와 SCSI 디스크라서 Duo Dock 같은 장치[2], HDI-30 변환 어댑터[3], 그리고 병렬 SCSI 장치를 현대 시스템에 연결할 케이블·컨버터·컨트롤러 조합이 필요함
      PCI Express 슬롯이나 Thunderbolt PCI Express 인클로저가 있는 장비라면 eBay에서 50달러 미만인 LSI Logic Ultra320 어댑터를 추천함. macOS, Linux, Windows용 드라이버가 쉽게 구할 수 있음
      준비가 되면 SCSI 케이블로 Mac들을 연결하고 PowerBook 부팅 중 T를 눌러 대상 디스크 모드에 들어간 뒤, OS가 읽을 수 없는 디스크를 포맷하겠냐고 물으면 반드시 아니라고 답하면 됨
      HFS 파일 시스템 접근은 macOS 기준으로 원시 디스크 이미지를 만들고, 백업한 뒤 qemu에 Mac OS 9를 설치해 이미지를 붙이고, Alsoft PlusMaker로 HFS를 HFS+로 제자리 변환한 다음 현재 macOS에서 이미지를 마운트하는 방식이 가장 완전하고 쉬워 보임
      덤으로 현대 Mac에서 원래 PowerBook 하드디스크의 앱 대부분을 실행할 수 있는 에뮬레이트된 Mac OS 9 시스템도 얻게 됨
      [1] https://developer.apple.com/library/archive/technotes/tn/tn1...
      [2] https://en.wikipedia.org/wiki/PowerBook_Duo#Docking_stations
      [3] https://www.amazon.com/dp/B0081SAIS2/
      [4] https://www.broadcom.com/support/download-search?pg=Legacy+P...
      [5] https://wiki.qemu.org/Documentation/GuestOperatingSystems/Ma...
      [6] https://www.macintoshrepository.org/19-plusoptimizer-plusmak...
      [7] https://www.macintoshrepository.org/809-stuffit-deluxe-1-5-x...
      [8] https://www.macintoshrepository.org/1724-toast-5-titanium

  • 이건 실전 정보 이론 시험 같아서 좋음
    “32,000바이트 파일을 원하는 채널로 전송하라. 모든 채널은 어떤 식으로든 별로다. 스마트폰, 직렬 포트, 컴퓨터가 있다. 컴퓨터에는 컴파일러가 없지만 기본 기능은 무엇이든 쓸 수 있다. 전송할 파일보다 더 많은 입력 바이트가 필요한 해법, 예컨대 스크립트는 탈락이다. 시간 제한은 없지만 가장 빠른 해법이 이긴다. 시작.”
    오래된 Mac이라면 글쓴이보다 더 잘했을지는 모르겠음. 다만 3과 8처럼 시각적으로 비슷한 문자를 8→Z처럼 아주 구분되는 문자로 바꿀 수 있다면, 스마트폰으로 화면을 촬영해 OCR하는 방법이 가장 빠를 수도 있겠다는 유혹은 듦
    System 7에는 AppleScript가 있었던 것 같으니 sed 비슷한 치환 단계가 가능했을지도 모름

    • 소프트웨어 해법을 생각하기 전에 먼저 드라이브를 꺼내 XYZ-to-USB 인터페이스에 꽂았을 것임
      hfsprogs를 설치해 드라이브를 마운트하고 필요한 파일을 빼내면 끝임
      독자 커넥터가 문제가 될 수 있어 즉석 납땜 같은 우회가 필요하겠지만, 다행히 오래된 장비는 그렇게 해도 꽤 잘 동작함
      솔직히 하드웨어 쪽 사람의 장점임
    • 스마트폰 카메라 OCR은 탐지와 수정이 어려운 오류를 쉽게 만들 수 있음
      그래서 오류가 극히 드물어지는 인코딩을 찾을 것 같음. 노트북 전체 드라이브를 덤프해야 한다면, 더 빠르지만 오류가 생기는 방법보다 한 번 노트북을 일주일 동안 켜두는 편이 낫다고 봄
      단순 계산으로 320MB를 일주일에 보내면 초당 530바이트임. 화면을 4Hz로 표시하고 스마트폰으로 녹화하면 프레임 누락이나 이상한 아티팩트는 없다고 가정할 수 있고, 프레임당 약 135바이트, 즉 1080비트가 됨
      8.4인치 640×480 화면을 16×16픽셀 정사각형으로 나누면 0.5cm 정도의 칸 1000개가 생김. 각 칸을 0.25초 동안 흑백으로 표시하면 카메라 아티팩트가 데이터에 큰 영향을 주지 않고 필요한 대역폭에 거의 맞음
    • 헥스 편집기로, QR 코드 비슷하지만 QR은 아닌 흑백 이미지 연속으로 데이터를 화면에 출력하는 바이너리 프로그램을 입력하려면 몇 바이트가 필요할지 궁금함
      문자를 OCR하지 않으니 위에서 나온 문제가 줄어들겠지만, 먼저 그 프로그램을 기계에 집어넣어야 함

  • 내부 하드디스크가 특이한 커넥터의 SCSI라서 어댑트가 쉽지 않아 보였다는 대목은 사실 SCSI 버스를 쓰면 되는 길이었음
    SCSI는 여러 마스터가 버스를 공유할 수 있는 버스 마스터링 프로토콜이라 두 컴퓨터를 같은 SCSI 버스에 동시에 꽂고 디스크 장치를 함께 접근할 수 있음. 파일 시스템을 동시에 쓰는 걸 믿으면 안 되지만, 당시 전체 디스크는 오늘날엔 큰 파일 하나일 뿐이라 통째로 덤프하면 됨
    열린 파일 시스템의 불일치는 충돌 복구와 비슷한 수준이고, 오래 저장된 파일에는 영향이 없었을 것임
    오래된 HFS도 오픈소스/New Jersey 스타일의 좋은 점 덕분에 Linux에서 루프백으로 마운트하기 아주 쉬웠을 것임
    1988년산 오래된 Mac SE20의 전체 디스크 이미지를 아직 갖고 있고 가끔 마운트함. 그것도 SCSI 버스로 빼냈음. 20은 68020 프로세서의 MHz를 뜻했던 것 같지만 우연히 20MB 디스크도 달려 있었고, 다음 해 SE30도 비슷했음
    팩스 소프트웨어를 이용한 부분은 예전에 생각만 하고 실행하지 않았던 아이디어를 떠올리게 함. 팩스 표지에 문서의 .DOC 형식을 인코딩한 큰 QR 코드 같은 것을 넣으면, 일반 팩스 기계로도 보내고 수신자가 컴퓨터 모뎀이면 원본 형식 문서를 받아 나머지 팩스 전송을 핸드셰이크로 중단할 수 있었을 것임
    낡은 팩스 기술을 부드럽게 넘어가는 방법이 됐을 것 같음

  • 몇 년 전 Macintosh Plus와 현대 컴퓨터 사이에서 파일을 주고받으려고 꽤 시간을 썼음
    당시에는 100MB ZIP 드라이브 두 개, 즉 Mac Plus용 SCSI와 현대 컴퓨터용 USB를 쓰고, 나중에는 터미널 소프트웨어로 직렬 포트 연결을 사용했음 [1]
    지금은 더 좋고 저렴한 선택지로 BlueSCSI[2]가 있음. SD 카드에 저장된 .img 파일을 HDD 디스크로 마운트할 수 있는 SCSI HDD 에뮬레이터이며, CD와 네트워크 카드 에뮬레이션도 지원함
    파일을 이런 가상 드라이브에 복사한 뒤에는 현대 기기에서 HFS 탐색기나 에뮬레이터로 추출할 수 있음
    [1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
    [2] https://bluescsi.com/

    • 예전에는 Zip 드라이브를 꿈꿨음. 나중에 USB 드라이브가 표준이 된 것처럼 왜 표준이 되지 못했는지 아직도 잘 이해가 안 됨

  • 정말 흥미진진한 글이었고, 내 제한된 컴퓨터 지식으로는 너무 복잡했음
    1993~1994년쯤, 다른 사건들과의 순서를 떠올려 보면 부팅되지 않는 IBM 노트북을 “고칠” 기회가 있었음. 두껍고 무겁고 컸지만 화면은 3.5인치 플로피만 한 크기였음
    사진에서도 다른 곳에서도 그런 노트북을 본 적이 없어서, 당시 기준으로도 더 오래된 물건이었을 것으로 추정함. 뭔지 아는 사람이 있으면 사진을 보고 싶음
    시대에 뒤처진 괴짜 동네 삼촌이자 멘토 같은 분이 고쳐보라고 줬고, 나는 며칠 동안 책상에 올려두고 자랑했음. 아마 AUTOEXEC.BAT를 바꾸고 WordStar를 로드하는 멍청하고 단순한 방법으로 고쳤던 것 같음. 필요한 것도 DOS에서 WordStar뿐이었고 Windows 3.x도 아니었음
    그 노트북은 고향의 지역 교회에 방문하던 기독교 선교사들이 준 것이었을 가능성이 큼
    또 다른 컴퓨터 수리 이야기도 있지만 세부를 떠올려 적어야 함. 산속 군 막사에서 자고, 소변 볼 때 무장 경비가 붙고, 임산부를 구급차로 돌보며 귀가했던 일임. 그 “미션”은 어린 시절 이웃 친구와 함께였지만 그는 세상을 떠났고, 그 시대착오적 삼촌도 세상을 떠났음. 서로 관련은 없음

  • “팩스 소프트웨어”가 있었다면 거의 확실히 터미널 에뮬레이터도 있었을 것이고, ZMODEM 같은 걸로 파일을 손상시키지 않고 보낼 수 있었을 것임
    정밀 드라이버 대신 버터 나이프를 쓰는 걸 보는 것처럼 읽기 괴로웠음

답변달기