김 용묵의 절대공간 - 블로그

1. undelete (노턴 유틸리티의 unerase)

그렇다. 도스 시절에는 지금처럼 휴지통이라는 개념이 없었다. FAT 파일 시스템에서 파일 삭제는 파일 이름의 첫 글자만 ?로 바꿔서 지워진 것처럼 속이는 작업이었기 때문에, 그런 파일을 찾아내어 첫 글자를 지정해 주면 지워진 파일을 살릴 수 있었다.

그러나 이것은 100% 완전히 복구된다는 보장이 없었다. 본디 파일이 있던 위치에 다른 파일이 덮어써지면 파일이 소실되거나 심지어 다른 파일 내용과 충돌이 일어날 수 있었다. 이건 또한 보안상으로도 굉장한 허점을 남기는 위험한 일이며, 옛날 도스 시절에 운영체제나 파일 시스템이 지금보다 훨씬 더 단순할 때나 통용되던 편법에 불과했다.

2. sort (노턴 유틸리티의 ds)

요즘 우리가 매일 사용하는 탐색기나 여타 파일 관리 유틸리티들은 파일 목록을 보기 좋게 잘 정렬해서 보여주지만 DIR을 쳐서 나타나는 파일 목록은 그렇지 않았다. 말 그대로 디스크에 저장된 순서대로 저장된 파일 목록을 보여줄 뿐이었다. 그래서 디스크에 보관되는 파일 목록 자체를 ABC 순으로 정렬해서 재기록해 주는 별도의 유틸리티가 있었다. 그것도 하위 디렉토리들까지 재귀적으로 알아서 말이다.

하지만, 오늘날 윈도우 NT 계열이 사용하는 NTFS 파일 시스템은 자체적으로 파일 목록을 알아서 ABC 순으로 무조건 정렬해 놓으므로 그런 유틸리티가 무의미하고 불필요해졌다. 내부적으로 단순 연결 리스트가 아니라 tree 같은 자료 구조를 쓰는 듯하다. 과거의 윈도우 9x와 윈도우 NT는 아무 디렉터리에서나 DIR만 쳐 봐도 결과가 차이가 났던 것이다.

지금도 FAT32를 쓰는 플래시메모리를 꽂아서 DIR를 해 보면 차이를 알 수 있다. 하드디스크는 파일 목록이 ABC 순으로 출력되는 반면, 플래시메모리는 그렇지 않다.

3. 디스크 검사 (노턴 유틸리티의 NDD)

요즘 애들은 디스크 드라이브가 A부터 시작을 안 하고 왜 C부터 시작하는지 이유를 모를 것이다. 옛날 A와 B를 차지하고 있던 플로피디스크는 용량 적고 느린 건 둘째치고라도 물리적인 에러가 정말 잘 났다. 이 디스크 에러 내지 데이터 에러는 도스가 간단히 에러 메시지만 뱉고 끝내는 게 아니라 꼭 A중단, R재시도, I무시 같은 더 끈질긴(?) 인터페이스로 대응했기 때문에 더욱 무섭기도 했다.

그래서 그 시절에 디스크 검사 유틸리티는 필수였다. 물리적인 에러가 난 부위는 bad sector로 처리하여, 거기를 건드리다가 운영체제가 에러 메시지를 뱉는 일이 없도록 조치를 취해 줘야 했다.

과거에 하드디스크 용량이 한 수백 MB대일 때까지는 하드디스크도 NDD를 돌려볼 만했다. 그러나 그 이후부터는 디스크 검사라는 게 의미가 없어졌다. 에러가 거의 없어지기도 했고, 또 디스크 용량도 너무 커졌기 때문이다.

4. 디스크 조각 모음 (노턴 유틸리티의 SPEEDISK)

오늘날 존재하는 디스크의 모든 파일 시스템들은 어떤 형태로든 정기적인 조각 모음(defragmentation) 작업이 필요하다. 데이터베이스 파일도 그렇고, 가상 머신 이미지 파일도 그러하다. 그렇기 때문에 조각 모음은 과거 도스 시절만의 잔재는 아니며, 윈도우 XP까지도 별도의 시스템유틸리티가 존재했다.

비스타부터는 idle time 때 조각 모음을 운영체제가 알아서 지능적으로 찔끔찔금 하는 형태로 바뀌어, 덕분에 사용자가 이런 걸 신경쓸 필요가 사실상 없어졌다. 지금은 옛날 같은 방식으로 조각 모음을 하기에는 하드디스크 용량이 커져도 너무 커졌고, 또 SSD 같은 디스크는 아예 내부 특성상 전통적인 의미의 조각 모음을 해서는 안 되는 물건이기도 하다. 세상이 그만치 많이 변했다.

윈도우 95를 설치해 놓고 도스용으로 만들어진 디스크 조각 모음을 실행하면 긴 파일 이름이 싹 다 날아가고 대략 패닉이 벌어졌다.
그뿐만이 아니라 그 상태에서 undelete라든가 디렉터리 정렬 같은 저수준 작업을 시도하면 emm386 같은  메모리 드라이버가 에러를 내면서 컴퓨터가 그냥 다운되어 버리기도 했다. 오늘날은 과거 노턴 유틸리티의 DISKEDIT 같은 무식한 저수준 유틸리티가 돌아가는 건 절대 권력 운영체제가 허락하지 않을 것이다.

도스와 윈도우 9x 시절의 잔재라 할 수 있는 FAT 파일 시스템의 역사를 간략하게 소개하며 글을 맺는다.

FAT12: MS 도스 초창기에 도입. 플로피디스크용이며, 인식 가능한 하드디스크 용량은 최대 32MB.
FAT16: MS 도스 4.0(무려 1988년)에서 도입. 디스크 용량의 이론적 한계치가 2GB로 증가

FAT32: 윈도우 95 OSR2에서 도입(1996년). 최대 용량이 테라바이트급으로 늘긴 했으나, 파일 하나의 최대 크기는 여전히 4GB 제약을 받으며 디스크 용량이 수십, 수백 GB에 육박하면 슬슬 불안정해진다. NTFS로 갈아타는 게 낫다.
exFAT: 윈도우 비스타 SP1에서 도입(2008년). 플래시메모리 구조에 최적화되었고 파일 1개의 4GB 제약도 없어졌다고 함.

Posted by 사무엘

요 며칠, 압축 프로그램으로 7zip과 압축시대-_-를 써 보다가 다시 빵집으로 복귀했다.

빵집!
한창 알집이 불안정함, 버그, 황당한 독자 포맷 때문에 파워 유저들을 중심으로 까이고 있던 무렵에, 개인 명의로 순수 공개로 개발된 프로그램인지라 한동안 인기를 누렸다. 하지만 개발자의 개인 사정 때문에 너무 오랫동안 버전업이 못 되고 있어서 차츰 사용자가 다시 줄고 있다.

하긴, 빵집이 나오기 전에 알집이 국내 압축 유틸리티의 판도를 완전히 뒤집어엎긴 했다. 알집이 없었으면 본인도 WinZIP이나 WinRAR 같은 것이나 어렵게 크랙판 구해서 썼을테니 말이다.
컴퓨터를 잘 모르는 초보자의 관점에서는 압축 포맷 나부랭이를 떠나서 아무 포맷이나 원큐에 압축을 풀고 할 수도 있는 프로그램을 원했을 것이고 알집은 수요 분석 하나는 잘 했다. (그보다 더 옛날엔, 아예 A, E, X 같은 옵션을 익혀서 온갖 어려운 명령행 유틸리티로 압축을 했으니 더욱 암울했다)

과거 WinZIP이 압축하기/풀기 마법사에다가 완벽한 쉘 통합(탐색기 우클릭)까지 환상적인 인터페이스 껍데기를 선보였다면, 알집은 ‘새 폴더’라는 개념을 처음으로 도입했고 빵집은 ‘알아서 풀기’, 복사해서 붙여넣기 등을 추가하여 더욱 편리한 기능을 제공했다. 요즘은 압축 프로그램이 액세서리로 심지어 CD 이미지 파일까지 열 수 있다. 압축 파일은 아니지만, 파일 시스템 정보를 포함한 아카이브 파일이라고 볼 수 있기 때문이다.

그런데 요즘 압축 프로그램에게 또 필요한 덕목이 생겼으니, 바로 64비트+유니코드 지원이다. 그야말로 필수가 됐다. 64비트 OS에서는 우클릭 메뉴가 안 나온다거나, 요즘 세상이 어느 세상인데 일본어로 된 영화 자막 파일의 압축을 못 푼다거나 해서는 곤란하다.

하지만 빵집은 안타깝게도 저게 되지 않는다. 시스템 코드 페이지가 한글로 되어 있지 않으면 프로그램 UI가 죄다 깨진다. 또한, 정확한 재연 조건을 잘 몰라서 빵집 잘못이라고 100% 단정은 못 내리지만, 빵 폴더 같은 쉘 통합 기능을 사용하다 보면 아주 가끔 explorer가 죽는 현상을 경험한다.
왜 빵집을 ‘의심’하는가 하면, 첫째, exception 상황을 알리는 에러 메시지 박스가 델파이로 개발된 프로그램이 죽었을 때 뜨는 스타일이기 때문이다. 둘째, 빵집이 설치되지 않은 컴에서는 그런 현상을 지금까지 전혀 겪은 적이 없기 때문이다.

어쨌든 이런저런 이유로 인해 본인도 빵집에서 다른 프로그램으로 갈아타려고 대안을 찾아봤는데..
회사에서만은 도로 빵집으로 돌아오고 말았다.

이유는 단 하나.
다른 모든 압축 프로그램들은 tar.gz 파일을 열면 내부의 tar 파일 하나만 달랑 보여주는 반면,
빵집은 사용자에게서 확인 질문을 받은 후 친절하게도 tar 내부까지 자동으로 보여주기 때문이다. 이거 정말, 너무 편하다.

리눅스 환경에서 그냥 tar로 압축하여 백업한 파일을 다루는 경우가 많은데 그걸 윈도우 환경에서 손쉽게 관리하기 위해서는 다른 기능보다도 저게 무엇보다도 마음에 들고 꼭 필요한 기능인 것이다.

흠, 이런 건 혼자만 알고 있지 말고 개발자에게 건의를 해 봐야겠다. 본인은 특정 분야의 공개 소프트웨어 개발자이다 보니 다른 사람들로부터 버그 신고와 건의를 많이 듣는 편이지만, 본인도 역시 아주 가끔은 다른 소프트웨어에 대한 버그 신고와 건의도 직접 한다.

※ 덧.

윈도우 비스타나 7에서 Aero를 사용하고 있을 때 창을 최소화하면, 대부분의 표준 윈도우들은 작업 표시줄 쪽으로 멋있게 사그라든다.
하지만 경험상 델파이로 개발한 프로그램들은 아래로 멋있게 사그라들지 않고, 그냥 창을 닫을 때와 동일하게 그냥 fade-out으로 사라진다. AcroEdit라든가 WinM, 빵집 모두 마찬가지임. 뭔가 특별한 방식으로 윈도우를 다루는 것 같다.

그 반면 완전 자체 스킨을 사용하는 아래아한글이나 알집-_- 같은 프로그램은 그런 효과가 전혀 적용되지 않고 그냥 없어진다.
또한 비스타 이상에서 정상적인 실행이 보장되지 않는 비주얼 C++ 2003 같은 프로그램은, 최소화될 때 빈 창틀만 사그라들면서 다른 어느 프로그램과도 다른 이상한 애니메이션을 보인다.

Posted by 사무엘