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

오늘은 설치 프로그램이라는 주제로 이야기 보따리를 풀어 보겠다.

과거 도스+윈도우 3.1 공존 시절에는
도스용 프로그램들은 어떤 소프트웨어의 설치 프로그램의 이름은 대개 install이었던 반면,
윈도우용 프로그램들은 어찌 된 영문인지 다들 setup이었다.
그리고 그 시절에 윈도우용 설치 프로그램들은 전체 화면으로 파랑-검정 그러데이션이 배경으로 쫙 깔리는 게 유행이었다. 그러면서 화면 좌측 상단엔 큼직한 흰색 글씨로 "무슨무슨 프로그램 설치/Setup"이 떴지. (짤방은 귀찮아서 생략-_-)
이걸 기억한다면 당신은 진정한 old timer.

그러다가 윈도우 95가 보편화하면서 전체 화면 배경은 그냥 옥색(cyan) solid로 바뀌었다.
MS 오피스 97과 아래아한글 97의 설치 프로그램이 그런 모양이었다.

그러나 그때와 지금의 근본적인 차이는.. 이제 설치 프로그램은 더는 전체 화면을 점유하는 형태로 실행되지 않는다는 것이다. 유행이 확 바뀌었다. 그냥 간단한 마법사 대화상자 하나만 달랑 뜨는 형태로 극도로 간소화됐다. 소프트웨어 설치가 무슨 게임 실행도 아니고... 그 정도로 유세 부릴 프로세스는 아니게 되었다는 의미.

MS 제품의 경우 Windows Installer 기술이 최초로 도입된 오피스 2000부터 설치 프로그램 UI가 싹 바뀌었으며, 아래아한글 역시 2002부터는 설치 프로그램이 마법사 대화상자 하나만 달랑 나올 뿐 전체 화면으로 뜨지 않는다.

사실 소프트웨어의 규모가 복잡해지고 한 제품도 온갖 버전 구분이 존재하게 되면서,
제대로 된 설치 프로그램을 만드는 것도 굉장히 골치 아프고 까다로운 일이 돼 있다.
단순히 파일을 복사했다가 지우는 것 이상이다. 예를 좀 들자면,

- 동일 제품의 여러 버전이 공존하고 이들이 다 한데 공유하는 파일이 있는데 이 파일은 언제 제거해야 하나? 그런 거 체크 리스트를 어떤 자료구조로 구축해야 하나?
- 그런 자료구조가 깨졌을 때 최대한 복구는 어떻게 하면 좋을까? 그리고 확장자 연결 복구는?
(사용자는 1.0과 2.0 중 어느 걸 먼저 설치할 수도 있고, 그 후 2.0과 1.0 중 어느 걸 먼저 제거할 수도 있다. 프로그램 설치/제거는 획일화된 스택이나 큐 구조가 아님. ㅋㅋ)
- 지금이 이전에 설치를 진행하다가 중단된 상태였는지 판단은?
- 지금 당장 건드릴 수 없는 파일을 건드려야 돼서 그걸 다음 재부팅 때 하도록 예약해 놓은 게 있나?

글 쓰면서 당장 떠오르는 복잡도만 생각해도 저 정도이다.
특히 재부팅 때 건드릴 파일을 예약하는 기법이나, 지금 실행돼 있는 프로그램 목록을 얻는 방법은.. 설치/제거 프로그램을 만들 때 반드시 필요한 동작임에도 불구하고 과거에 윈도우 9x과 NT 계열이 테크닉이 서로 완전히 달랐다. 유니코드 지원 여부 같은 차이도 존재하고.. 그러니 짜증 두 배.. -_-

예전에도 글을 쓴 적이 있지만, uninstall 프로그램을 만들 때 필요한 것이, 바로 자기 자신을 제거하는 기법이다. 윈도우 운영체제는 그 특성상 실행 중인 EXE/DLL은 운영체제가 memory-mapped file로 대응시켜 잡고 있기 때문에, 자신을 제거할 수 없다.
하지만 배치(일괄 처리 bat) 파일은 DEL 명령으로 자신을 제거할 수 있다. 그래서 EXE를 제거한 뒤 자기 자신을 제거하는 비밀 배치 파일을 만들어 실행하는 기법으로 자신을 제거하곤 한다. 리눅스나 맥은 사정이 어떤지 모르겠다.

이런 저런 사항도 있고, 아무튼 프로그램 설치/제거 및 버전 관리 기법은 어느 소프트웨어에서나 공통적으로 쓰이는 개념/테크닉만 뽑아내서 운영체제 차원에서 책임을 져 준다거나 어느 잘 만들어진 미들웨어를 쓰는 게 효율적이다.
그래서 진작부터 프로그램 설치/제거 솔루션이 나와 있었다. 가장 역사가 긴 녀석은 역시 InstallShield이다. 지금은 비록 위상이 옛날 만하지는 않고 Windows Installer의 단순 wrapper 수준처럼 된 것도 있지만.. 그래도 대형 상업용 소프트웨어에서 이게 여전히 쓰이고 있기도 하다.

InstallWise도 아마 윈도우 3.x 시절부터 건재했던 외산 솔루션이고, 국산 프로그램인 InstallFactory는 <날개셋> 한글 입력기의 2.0~2.4 시절에 잠시 도입된 적이 있다.
DeployMaster라는 제품도 있고, 아.. 그나저나 요즘 전세계적으로 가장 널리 쓰이는 솔루션은 역시 Nullsoft의 NSIS인 것 같다.
소프트웨어의 설치 프로세스라는 건 단순 파일/복사나 버전 체크 같은 아주 공통적이고 범용적인 동작도 있지만, 또 각 소프트웨어가 필요로 하는 customize 수준도 천차만별이라는 특성도 존재한다. 그러니 그런 것도 잘 살려 줘야 하면서도 최대한 배우기 쉽고 구조가 간단해야 한다.

<날개셋> 한글 입력기는 2.5 이후 버전부터 지금까지는 그냥 비주얼 스튜디오가 기본 제공하는 msi 생성 프로젝트를 이용하여 배포 패키지를 만들고 있다. AppLocale 버그(이건 뭐 MS가 만든 프로그램들끼리 충돌하는 문제-_-)도 있고, 다국어 UI도 지원 안 되는 등 좀 마음에 안 드는 면모가 없는 건 아니나, 일단 7년에 가까운 세월 동안 설치/제거 자체가 딱히 큰 트러블 없이 되는 게 검증이 되어 왔기 때문에 쓴다. 민감한 부위인 외부 모듈까지도 말이다.

또한 MSI 런타임 2.0은 윈도우 95/NT4에서도 무난하게 잘 동작한다는 점도 큰 이점이다.
사실 Application Data 같은 일부 known 디렉터리는 IE4 이전의 윈도우 95 초창기에는 없던 개념인데, MSI 런타임 2.0은 설치 과정에서 그런 디렉터리에 대한 정보도 레지스트리에다 넣어 준다. (<날개셋> 한글 입력기의 동작에 필요)

다만, 본인도 InstallShield와 Windows Installer에 대해서 그렇게 좋은 인상을 갖고 있지 않다는 점을 밝히며 글을 맺는다.
99%까지 게이지가 금세 꽉 찬 뒤, 그 뒤로 몇 분째 꼼짝도 안 하는 훼이크성 대화상자에 짜증 게이지가 확 치솟아서이다. ㅆㅂ.. 도대체 설치도 아니고 설치 준비 작업이 뭐 이렇게 오래 걸리나 모르겠다.

개발툴인 비주얼 스튜디오 2005도 2003보다 제품의 완성도는 올라갔다지만, 설치에 관한 한 정말 답이 안 나오는 제품이다.
서비스 팩 1 설치하는 시간이 2005 자체를 첫 설치하는 시간보다 더 길면 길지, 절대로 더 짧지 않다. 도대체 그 시간 동안 뭘 하는지 모르겠다.
거기에다가 윈도우 비스타 내지 7에서 쓰려면 SP1에다가 또 운영체제 패치도 설치해야 한다. 이거 뭐 해처리 → 레어 → 하이브로 올리는 정도의 시간이 걸린다.

비스타/7부터는 그냥 닥치고 2008 이상을 쓰라는 소리. 비주얼 스튜디오 2008이 나오자마자 바로 갈아탔다.
사용자에게 좋은 첫인상을 주는 설치 프로그램을 만드는 것도 중요하다.

Posted by 사무엘

※ 2000

일반 사용자를 대상으로 NT 커널과 9x 계열의 통합을 야심차게 기획했던 운영체제이다.
하지만 윈도우 디렉터리의 이름은 여전히 Windows가 아닌 WinNT였고, 특이하게도 마우스 포인터의 이동 자취(trail)를 남기는 기능이 없었다. 9x 계열은 말할 것도 없고 구닥다리 윈도우 3.1조차 갖추고 있는 기능인데 NT에서만 원래 없었던가? 물론 XP부터는 이 기능이 있다.
탐색기에서 wav/mp3을 클릭 후 바로 재생이 가능하던 유일한 운영체제이다.

그리고 2000부터 GUI의 표준 색상이 약간 바뀌었다. 그저 RGB(192,192,192)이던 회색은 살짝 더 누르스름하게 바뀌고, 파랑은 좀더 어둡고 군청색에 가깝게 바뀌었다.
그런데 유독 윈도우 2000만.. 스타크래프트 같은 256색 전체 화면에 들어갔다가 나오면 그 파란색이 예전의 덜 어두운 색으로 돌아가는 신경 쓰이는 버그가 있었다. 이 역시 ME라든가 XP 이후부터는 전혀 발생하지 않으며 윈도우 2000만의 문제. 후대의 추가 최신 업데이트까지 다 받으면 어찌 될지 모르지만, 아무튼 SP4까지 가도록 이 문제는 고쳐지지 않았다. 2000만의 고질병으로 기록될 듯.

(이해를 돕기 위해 스크린샷을 첨부하자면, '위'가 '아래'로 바뀐다는 뜻이다. RGB(10,36,106)이 RGB(0,0,128)로 변경. 본인에게는 정말 바로 티가 나고 아주 거슬리는 버그였던 반면, 저 버그에 대해서 공감하는 사람은 주변에서 지금까지 전혀 보지 못했다. 윈도우 2000 쓰면서 스타도 띄워 본 적 없나??)

※ XP

1. 유저 인터페이스가 파격적으로 많이 바뀌었다 보니 초창기 SP0은 별 특이한 버그가 많았다.
스트링을 내장하고 있지 않은 리스트박스나 콤보박스는 LB_ADDSTRING 내지 CB_ADDSTRING 메시지로 아이템을 추가할 때 당연히 string을 NULL로 지정해도 괜찮은데, 새로운 비주얼 스타일(테마)이 적용된 컨트롤은 저렇게 하면 프로그램이 죽는 어이없는 버그가 있었다. -_-;; (비주얼 스타일 없는 옛날 컨트롤은 문제 없음)

95부터 2000/ME까지 아무 탈 없던 코드가 유독 XP에서만 문제를 일으킨 것. 과거 <날개셋> 한글 입력기 2~3.x 시절에 윈도우 XP (sp0)에서 일부 제어판 UI가 뻗던 문제는 이 문제 때문이었다. 매우 황당한 버그이기 때문에 이 문제는 SP1에서 곧바로 고쳐졌다.

2. XP부터는 응답이 없이 죽은 윈도우는 대책 없이 배째라 있는 게 아니라, 최소한 창의 이동과 강제 닫기는 가능한 일명 고스트 윈도우를 그 프로그램의 원래 윈도우를 대체하여 잠시 보여주는 기능이 추가됐다. 그래, 만든 취지는 좋다.

그런데.. 최대화되어 있던 프로그램 창이 한동안 응답이 없어서 고스트 윈도우가 됐다가... 다시 돌아와서 깨어나면,
그 창의 최대화 이전의 위치와 크기가 사라지고 창의 최대화를 해제해도 창 크기 자체가 최대화나 마찬가지인 상태로 남는 버그가 있었다. -_-
이 문제 역시 SP1을 전후한 시기에 고쳐졌다.

3. SP0은 무선 인터넷을 좀 하다 보면 lsass던가 뭐가 이상한 시스템 프로그램이 문제를 일으켜서 1분간 초 단위로 카운트다운을 한 후 운영체제가 재부팅되는 현상도 있었다. -_-;;
갑자기 그런 게 떠서 놀랐고, SP1만 설치해도 그 문제가 없어지는 것을 보고는 더 놀랐다. 도대체 SP0에서는 무슨 문제가 있었기에?

이외에 다른 사람들은 XP에서 시스템 차원에서 첫 도입된 TSF와 관련된 문제(ctfmon) 등 여러 버그를 찾아낸 듯하던데(해결책이라고 내놓은 게 '고급 텍스트 서비스 사용 안 함' ^^), 본인은 그런 건 모르겠고 저 세 가지 버그가 지금까지 기억에 남는다.
SP2는 저런 사소한 버그 해결 수준이 아니라 보안 관련 기능 추가가 즐비해서 단순 서비스 팩 같지가 않고,
SP3은 제대로 쓸 일도 없이 그 즈음에 비스타로 갈아타게 돼서 잘 모르겠다. SP2 정도만 해도 사실 상당히 안정화가 돼 있으니까.

※ 비스타

굉장히 오랜만에 출시된 만큼 엄청나게 높아진 사양, 그리고 디폴트로 적용돼 있는 UAC (사용자 계정 컨트롤) 때문에 뭇매도 많이 맞았다. 하지만 비스타는 객관적으로 상당히 잘 만든 OS이며, 7에 비해서 그 정도로 평가절하될 품질은 결코 아니다. 윈도우 98이 단순히 95+IE4가 결코 아닌 것과 같은 이치이다.

본인은 language bar (TSF 도구모음줄, 입력 상태 표시줄)를 task bar(작업 표시줄) 내부에 포함(embed, minimize)시키는 게 아니라 바탕화면에 동동 띄워 놓고 지낸다.
그런데 유일하게 비스타에서만 구경한 버그로는.. 응용 프로그램을 좀 사용하다 보면 이 language bar가 사라져 버리고 아마 내 기억이 맞다면 한글 입력도 안 되는 것.
내 컴만 그런가.. 왜 그런지 좀 성가시고 불편했다. 윈도우 시스템 디렉터리로 가서 ctfmon.exe를 재실행하면 사라졌던 language bar가 살아났다.

이것도 요즘은 구경을 안 하는 걸 보니, 다행히 서비스 팩을 설치하는 과정에서 고쳐진 것 같다.
엑셀 2007에서 유명하던 65535 곱셈 버그가 생각난다.
예전에 MS의 정책은 SP n은 SP n-1을 다 포함하는 형태였던지라, 최신 서비스 팩 하나만 갖고 있으면 됐다. 비주얼 C++ 6이라든가 윈도우 NT는 패키지 프로그램을 설치 후 최신 SP인 SP6만 깔면 끝이었던 것.

그런데 윈도우 비스타부터는 SP2를 깔려면 먼저 SP1부터 깔아야 한다. 매번 꽤 오래 시스템 파일 고치고 재부팅하고.. 불편하더라.
그래도.. 본인은 보안 업데이트는 귀찮아하는 편이지만, 서비스 팩은 그때 그때 깔 필요가 있다는 걸 체험 중. 왜냐하면 내가 현실적으로 직접 겪는 버그가 서비스 팩을 통해 곧장 해결된 경우를 꽤 자주 겪었기 때문이다.
듣기로는 비주얼 스튜디오 2010을 설치하려면 비스타조차도 SP1 이상이 필요하다.

아 그리고.. 윈도우 비스타 SP0은 인증 기간이 끝나면 대놓고 작동이 완전히 맘춰 버리는 유일한 운영체제이기도 했다. 기능 제한 모드가 되어, 인증을 받게 인터넷 접속이 가능한 웹브라우저 하나만 달랑 뜨고 다른 모든 기능을 사용할 수 없었다. 이 때문에 항의가 빗발쳤는지 SP1부터는 바로 사라지고 이는 후속작인 윈도우 7도 마찬가지. 화면이 주기적으로 까맣게 변하고 '이 제품은 정품이 아닙니다' 자막만 뜰 뿐, 동작 자체는 한다.

※ 7

콘솔에서, 한글을 조합 중이다가 비조합 문자를 “IME 차원에서” 삽입하면 조합 중이던 문자가 덧나는 버그가 있다. 이건 <날개셋> 문제가 아니라 MS IME에서도 나타나는 운영체제의 버그이다.
가령, "다"를 조합 중에 마침표를 누르면 "다."가 아니라 "다다."가 되는 것.

MS IME의 경우 두벌식일 때는 발생하지 않는다. 두벌식은 A~Z 사이에 배당된 한글 글쇠만 IME 차원에서 삽입하고 여타 숫자나 기호는 영문 자판과 동일한 방식으로 별다른 터치 없이 응용 프로그램으로 보내기 때문이다.
과거에 포트리스 space 버그를 비롯해서 MS IME가 유독 세벌식 자판에서만 발생하는 버그가 심심찮게 발견됐던 이유는 이런 동작 방식의 차이 때문이다. 세벌식은 아는 사람도 쓰는 사람도 거의 없다 보니 버그 발견이나 수정도 금방 금방 되지 않을 것이고.. -_-

이제 문자 입력 쪽 기능은 비스타 이후로 좀 안정화가 돼 있길 바랐건만, 또 뭘 건드려서 저런 버그가 생겼는지 모르겠다. SP1에서라도 당장 고쳐져 있길 기대한다.

Posted by 사무엘

1.
요즘 스마트폰 프로그램 개발 플랫폼:
- 안드로이드: 자바
- 아이폰: 오브젝티브 C
- 윈도우 모바일: C/C++
아주 언어까지 가지각색 제각각이네. =_=;;;
생각해 보면 각각 데스크톱 PC에서 리눅스, 맥OS, 윈도우 진영이 그대로 형태만 바뀐 게 아닌가 싶다.

그래서 이런 기기 프로그램 개발하는 회사들.. 특히 문자 입력 솔루션을 개발하는 회사들이 고역이라고 한다. 서로 극단적으로 다른 분야인지라, 동일한 제품을 만들어도 플랫폼별로 프로그래머를 따로 고용해야 하기 때문에.

2.
64비트 윈도우에는 32비트 모듈과 64비트 모듈이 서로 철저하게 분리되어 있으며 시스템 디렉터리가 둘 존재한다.
그런데, SysWOW64는 32비트 dll이 들어있는 곳이고, system32가 64비트 dll이 들어있는 곳이다. 헷갈리지 말자.
이름에 들어있는 숫자하고 실제 숫자가 서로 일치하지 않는다는 게 아이러니이다. ^^;;;

3.
윈도우 7은 비스타와 비슷한 기술 계층 위에서 UI가 굉장히 세련되게 많이 바뀌어서 호평 받고 있다. 그 중엔 창을 화면 한구석으로 끌면 자동으로 창을 최대화하거나 좌우 반쪽을 꽉 채우게 바꾸는 기능이 있다. 대부분의 상황에서 그건 편리한 기능이긴 한데, 그래도 정말로 창을 그렇게 구석으로 살짝 치우기만 하고 싶고 최대화를 시키고 싶지는 않을 때는 어떡하는지가 좀 의아하다.
툴바를 도킹할 때처럼 ctrl 키를 누르고 있으면 채우지 않게 한다거나 하는 기능이 필요하지 않을까?

4.
윈도우 7 얼터밋 같은 상위 에디션에는 윈도우 XP 가상 머신이 추가되어 있다. 이것은 단순히 VMware 같은 가상 머신 유틸이 추가된 게 아니라 아예 윈도우 XP 모드로 웹브라우저를 다른 7 응용 프로그램들과 동일한 위상으로 돌려 주는 기능도 제공한다. 이걸 보고 적지 않게 놀랐다. XP 가상화 모드로 실행된 IE는 Aero 적용도 받지 않고, XP 스킨을 그대로 유지하고 있다. 하지만 다른 프로그램과 동일하게 다루는 게 가능하다.
그런데 그렇게 XP 가상화 모드로 실행된 프로그램의 윈도우의 클래스 이름이 RAIL_WINDOW이다. rail이 난간, 울타리라는 뜻이 있으니 그런 이름이 붙은 것 같다.

전에도 글로 썼듯이, 본인은 집이나 회사에서나 온통 비스타밖에 안 쓴다.
하지만 바깥에서는 차라리 XP를 쓰면 썼지 비스타 구경하기는 굉장히 힘들어져 있다. 온통 7 쓰니까. ^^;;

5.
본인은 초딩· 중딩이던 시절엔 제발 더 좋은 컴퓨터 좀 장만해 달라고 부모님을 진짜, 엄청 속 썩였는데
이제는 정반대로 지나칠 정도로 이쪽으로는 무덤덤해져 버렸다.
그때야 XT, AT, 386, 486.. 컴의 성능이 한 단계 한 단계 올라갈수록 당장 돌릴 수 있는 프로그램의 스케일이 극단적으로 달라지고 그야말로 천지개벽의 변화가 있었던 반면,

이제는 어지간한 넷북 수준의 컴퓨터에서도 비주얼 스튜디오 깔아서 프로그램 개발하는 덴 별 지장이 없으니, 업그레이드의 필요성을 별로 안 느끼게 된 것이다.
그래서일까? 명색이 IT 업계 종사자 소프트웨어 개발자라면서 본인은 우리 회사에서 최고령 휴대전화를 쓰고 있다. ^^;; 자동차로 치면 아직까지 포니, 스텔라, 엑셀 같은 차를 몰고 있는 것이다.

튼튼하고 배터리 오래 가고 통화· 문자만 되면 된다. 잃어버리거나 고장나지 않는 이상 도무지 전화기를 바꿀 필요를 느끼지 않는다. 본인에게는 인터넷이 되는 작은 전화기보다, 인터넷 안 되더라도 정상적인 타이핑이 가능한 휴대용 컴퓨터가 훨씬 더 필요하다.
오히려 부모님이 나보고 폰 좀 바꾸라고 성화일 정도이니 세상이 과연 극과 극으로 바뀌었다. ^^;;

그나저나 20~30년 전에 비해 다른 모든 분야의 물가는 2배~3배 가까이 뛴 반면(버스비, 라면· 우유값, 자장면 값 따위를 생각해 보라), 컴퓨터는 성능이 그야말로 넘사벽 충공깽 급으로 향상됐음에도 불구하고 가격은 예나 지금이나 여전히 수십만~100수십만 원..;; 보편적인 물가를 역행해도 한참 역행하고 있다. 정말 신기한 노릇이다!!

Posted by 사무엘

Paint Shop Pro!
윈도우 환경에서는 포토샵과 더불어 2D 그래픽 툴의 양대 산맥이었으며, 본인은 윈도우 3.1+PC 통신 시절부터 10년이 넘게 애용해 왔기 때문에 굉장한 애착을 지니고 있는 그래픽 툴이다. 포토샵은 맥 플랫폼이 주류이고 윈도우용으로는 나중에 포팅된 반면, PSP는 순수 윈도우용이다.

윈도우 운영체제의 보급 그림판은 워낙 기능이 너무 빈약하기 때문에, ‘싸제’ 그래픽 프로그램은 사실상 필수라 해도 과언이 아니다. PSP는 전문 그래픽 디자이너가 아닌 단순 파워 유저 내지 프로그래머의 입장에서 필요한 그래픽 기능이 정말 쓰기 쉽게 잘 갖춰져 있었다. 가령,

1. 일단 단색부터 24비트 색까지 모든 유형의 이미지를 다룰 수 있으며 다양한 디더링 알고리즘 지원
2. 기계적인 이미지 조작: 화면 캡처, 다양한 파일 포맷 변환, 특정 픽셀의 RGB 값 확인
3. 편집: 확대/축소, 자르기(crop), 임의의 모양의 selection 만들고 selection 자체를 저장하거나 합치기
4. blur, 색상 보정 등 디지털 카메라 사진 보정과 관련된 필터들

5. 거기에다 옵션으로 알파 채널을 지원하는 레이어와 간단한 벡터 드로잉 기능
6. 자매품인 Animation Shop Pro를 이용하면 애니메이션 GIF 다루는 것도 OK
7. 옛날에 운영체제가 자체 제공하는 이미지 관리 기능이 매우 빈약하던 시절엔, PSP 특유의 Browse 기능도 전매 특허였음.

본인이 2D 그래픽 툴로 하는 작업은 뻔하기 때문에, 딱 저것만 있으면 다른 프로그램이 도무지 필요하지가 않았다. PSP 수준 그 이상도 그 이하도 아니다. RGB 픽셀만 있으면 되지 포토샵처럼 인쇄와 관련된 개념은 필요하지 않으며, 고급 드로잉 기능도 그리 필요하지 않았던 것이다. 또한, 구동 시간이 꽤 길고 너무 무거운 느낌이 드는 포토샵과는 달리 PSP는 가볍다는 점도 무척 좋았다.

요즘은 PSP의 대안으로 공개 소프트웨어인 Paint .NET이 큰 인기를 끌고 있는 걸로 안다. 갈아타려고 써 보긴 했는데 역시 PSP 단축키에 손에 완전히 익어 버려서 적응이 안 된다. 엄청 옛날에 개발이 중단된 WinM 대신 NexusFile도 써 보려 했지만, 여전히 교체를 못 하고 있다. 이거 없이는 도저히 살 수 없는 몇몇 주요 단축키의 대체 기능을 못 찾았기 때문으로 기억한다. 세벌식이 아무리 좋아도 이미 익숙한 두벌식 때문에 못 바꾸는 것과 비슷한 맥락이라 할까?

과거 도스 시절엔 256컬러 그래픽 개발용 툴로는 딜럭스 페인트가 지존의 강자였다. ^^;; 그랬는데 요즘은 2D 그래픽은 무조건 포토샵, 3D는 3DS MAX인 것 같다. 심지어 아이콘조차 이제는 포토샵으로 만들어야 하지 프로그래머가 16컬러로 급조해서 만들 수 있던 시대는 옛날에 지났다. 본인도 그래픽을 조금은 다룰 수 있었으면 좋겠지만 그건 그저 희망 사항일 뿐. 남이 만들어 놓은 걸 어설프게 리터칭만 가능하다. =_=

윈도우 그림판도 MDI 지원 같은 건 바라지도 않지만, 최소한 1, 2, 4번 정도는 불편 없이 갖춰야 하지 않겠나 하는 생각이 든다.
도스 시절에 아래아한글은 GIF 파일을 렌더링하는 속도도 여타 포맷보다 굉장히 느렸으며, JPG는 다른 그래픽 포맷보다 처리하기가 월등히 힘들었던 관계로 386 이상급의 컴퓨터에서 전용 뷰어로나 볼 수 있었다. 사실, 컴퓨터에서 사진 이미지를 얻는 방법 자체도 옛날에는 스캐너가 전부였지만 지금은 디지털 카메라 덕분에 누구나 이미지 파일과 동영상을 만들 수 있는 세상이 됐다.

끝으로...
컴퓨터에서 그래픽 작업도 텍스트 에디팅 만만찮게 반복과 노가다가 엄청 많을 텐데, 고급 툴에는 매크로 내지 스크립트 기능이 없을 리가 없을 거라고 생각한다. 단순한 키매크로뿐만 아니라, 편집 중인 이미지를 거대한 2*2 배열로 접근하여 임의의 알고리즘에 의한 이미지 변형이 가능하고 프로그램이 제공하는 각종 필터 기능을 API를 통해 호출 가능한 수준 말이다. 그래, PSP에도 딱 하나 저것만 있으면 정말 더 바랄 게 없겠다.

Posted by 사무엘

Posted by 사무엘

개인적으로 1995-6년 사이는 PC 게임 환경의 역사상 굉장히 의미심장한 과도기였다고 생각한다.
플랫폼이 도스에서 윈도우로 넘어가고 있었고, 그래픽 역시 VGA 320*200 256색 모드를 탈피하여 2D 게임을 기점으로 고해상도화하기 시작했다. 사실, 그래픽 가속기라는 개념이 등장한 것도 이 무렵부터이고, 비록 아직 듣보잡 지위이긴 하나 DirectX란 것도 그때 개발되어 나왔다. 빌 게이츠는 윈도우 95를 게임용 엔터테이먼트 플랫폼으로 만들려고 안간힘을 다하는 중이었다.

패키지 게임의 경우, 저장 매체도 CD롬이 슬슬 플로피 디스크를 대체하기 시작했다. 하지만 그 당시 게임은 650MB 공간을 꽉 채울 정도로 대용량은 아니었다. 97~98년 사이에 출시된 스타크래프트도 음악과 동영상을 제외한 립버전이 200MB 안팎이었고, 윈도우 95 역시 실제 운영체제 파일 용량은 100MB도 채 하지 않던 시절이다.

이때 몇몇 게임은 CD롬을 아주 재미있게 활용했다. 디스크를 오디오 CD 겸 CD롬 겸용으로 만들어서 파일은 50-100MB 정도의 공간만 차지하고, 나머지 공간에다가는 게임 배경 음악을 집어넣은 것이다. 대표적인 예가 퀘이크 1이다. 옛날에 무슨 팝송 영어 교재 CD도 그렇게 겸용 형태였다. 공간 활용을 잘 한 경우라 하겠다.

게임 내부에서 사용하는 음악을 일반 CD 플레이어로 간단히 들을 수 있을 정도로 노출한 것이긴 하지만, 개인적으로 그건 굉장히 기발한 방법이라고 생각했다. 또한 그때는 그 CD를 정품 인증 수단으로 활용하기도 했다. 비록 가상 CD 기술 때문에 완전히 무력화됐지만 말이다.

그 당시에 오디오 CD는 CPU와는 완전히 별도로 동작했기 때문에 CPU에 부담을 전혀 주지 않았다. 요즘이야 MP3 틀어 놓고 온라인 게임도 마음대로 할 정도로 하드웨어 환경이 좋지만, 486이나 펜티엄급 컴퓨터만 해도 MP3 하나 트는 것만으로 CPU 사용률이 10~20% 정도 치솟던 시절이었다.

미디보다 음질 좋지, CD롬의 남는 용량을 활용하지, CPU 부담 안 주지, 40분 남짓한 정도의 시간이면 게임 사운드 트랙을 모두 담는 데 별 무리도 없지(게임 음악은 은근히 짧으며, 나머지는 전부 반복이다. ^^), 허접하게나마 정품 체크도 간단히 할 수 있지.. 일석이조가 아닐 수 없었다.
요즘은 온라인 게임 클라이언트가 최하 기가바이트급이다. 배경 음악은 미디도 아니고 그냥 내부적으로 mp3/wma/ogg 같은 걸 그대로 재상한다. 불과 15년 남짓 전인데 세상이 이렇게 달라졌다니 참 격세지감이다.

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 사무엘

Posted by 사무엘

본인은 컴퓨터 가상화 프로그램으로 VMware와 도스박스(DOSBox)를 애용하고 있다. 순수 도스와 윈도우 3.x까지를 돌리는 데는 도스박스가 독보적인 솔루션인 반면, 윈도우 9x부터 시작해 여타 NT급 운영체제, 리눅스 등을 구동할 때는 VMware를 사용한다.

둘은 구동하는 방식이 근본적으로 다른데 이 차이를 세세히 논하기 위해서는 나도 잘 모르는 CPU 계층에서의 난해한 개념 설명이 필요하다. 하지만 다 모르더라도 이 사실 하나만 기억하면 된다. VMware(와 기타 동급의 가상화 프로그램)는 CPU가 하드웨어 차원에서 자체 제공하는 가상화 기능을 적극 활용하여 동작하며 이는 32비트 윈도우 NT급 운영체제가 아주 허접하게 호환성 에뮬레이션 계층으로 제공하는 NTVDM도 마찬가지이다. 하지만 도스박스는 CPU 동작 자체를 포함해 모든 하드웨어 동작을 소프트웨어적으로 흉내 낸다.

그 결과 둘은 제각기 일장일단을 갖게 된다. D는 동작 방식의 특성상, 태생적으로 성능은 V보다 꽤 뒤쳐진다. 오늘날의 1~2GHz급 초고성능 컴퓨터에서 겨우 90년대 중반, 윈도우 95 출현 직전의 486~펜티엄급 PC의 성능을 낸다. 사실, 도스의 수명은 거기가 끝이었으므로 그 정도만 동작해도 D는 제 할 일 충분히 해 낸 셈이다. 32비트 보호 모드도 지원하여 둠 정도까지는 도스용을 잘 실행해 내지만, 퀘이크까지 되면 차라리 윈도우용으로 포팅된 퀘이크를 돌리는 게 낫다는 뜻.

하지만 D는 소프트웨어 계층이 담당하는 일이 많은 덕분에, V의 방식으로는 상상도 할 수 없는 다양한 옛날 하드웨어를, 호스트 컴퓨터의 성능만 좋다면 얼마든지 재현해 낼 수 있으며 컴퓨터 구동 속도도 세밀하게 제어할 수 있다.

V의 경우 PC 스피커 소리가 제대로 나지 않으며, 위험한 데이브는 너무 빠르게 돌아가고 금도끼(도스용)는 너무 느릿느릿 실행된다. 이것은 V의 방식으로는 소프트웨어적인 방법으로 제어를 할 수 없다. 윈도우 3.x를 설치는 할 수 있으나 guest extension(VMware tools)을 제공하지 않으며 겨우 16컬러 VGA에서밖에 사용할 수 없다. 사실 V는 근본적으로 16비트 구닥다리 플랫폼 에뮬이 주된 목적인 제품이 아니다.

그 반면 D는 어떤가? 아예 PC 스피커 소리와 옛날 애드립 소리를 사운드카드로 흉내 내어 준다. 그냥 비프음뿐만 아니라, 하드웨어를 교묘하게 제어하여 PC 스피커로 얼추 사운드카드 소리를 내던 기법까지 완벽하게 재현된다! 화면/동영상/음성 캡처야 요즘 가상화 프로그램들이 거의 필수로 갖추고 있는 기능이지만, 아예 프로그램이 내리는 미디 명령을 캡처하여 게임 음악의 미디 악보를 저장하는 기능은 하드웨어를 소프트웨어적으로 흉내 내지 않고서는 구현할 수 없는 기능인 것이다.

없는 하드웨어를 소프트웨어로 다 만들어 준다. 일일이 autoexec나 config.sys 튜닝을 하지 않아도 EMS, XMS 같은 메모리 세팅도 다 자동으로 해 주고, 과거의 베사 SVGA 비디오나 미디 카드, 마우스, 심지어 모뎀 따위도 프로그램이 필요로 하면 다 잡아 주니 V와는 비교가 안 되는 그야말로 도스 천국이 아닐 수 없다. 옛날 잡동사니 드라이버 파일을 뒤지면 윈도우 3.x도 그래픽/사운드 잡아서 쓸 수 있다. 더구나 D는 무려 윈도우 9x에서도 돌아간다!

아무튼 D는 참 대단한 프로그램임이 틀림없다.
그러고 보니 굳이 NT 계열로 운영체제가 완전히 넘어가기 전부터도 윈도우 9x 시대가 되면서 디렉터리의 파일들을 정렬-_-해 주는 유틸리티, 그리고 파일 첫 글자를 입력하여 지운 파일을 살리는 undelete 유틸리티는 아련한 추억 저편으로 사라진 것 같다. FAT32를 도입한 윈도우 95 OSR2가 이를 더욱 가속화한 게 아닌가 싶다. 요즘 NT 계열에서 쓰이는 NTFS는 아예 구조적으로 파일이 자동으로 정렬이 유지되는 파일 시스템이다.

그 전의 FAT16은 하드디스크 크기를 겨우 2GB까지밖에 인식 못 했었다. 요즘은 하드가 아니라 램 크기가 수 GB인데! ㅎㄷㄷㄷ FAT16이 MS 도스 4.0에서 처음 도입되어서 그때는 그걸 갖고 “하드디스크 용량 제한이 ‘없어졌다’”라고 말을 붙이곤 했다. (과거의 FAT12는 한술 더 떠서 하드디스크를 32MB까지밖에 인식 못 했음)
하지만 윈도우 9x는 FAT32로도 100수십 GB 이상의 하드는 제대로 인식 못 하니 어차피 요즘 컴퓨터에서는 쓰지도 못한다.

참고로, VMware에다 과거 윈도우 운영체제를 설치해 보면, 2000/ME부터는 사운드를 자동으로 인식하고 멀티웨이브까지 되는 반면 95/98은 그렇지 못하다. USB 메모리를 안전하게 제거하는 트레이 메뉴가 추가된 것도, 그리고 미디에 소프트웨어 신시사이저가 기본 내장된 것도 2000/ME부터이다.

이런 맥락에서 보면 윈도우 ME는 같은 9x 계열 중에서 그저 나쁘기만 한 게 아니라 최신 하드웨어의 지원 면에서는 98 SE보다 나아진 점도 분명 있다. 하지만 괜히 도스로 부팅하는 기능만 쏙 빼서, 도스 지원 때문에 윈도우 9x 계열을 일부러 선호하는 사용자들로부터도 외면 받았고, 1년 남짓 XP가 출시되는 바람에 아주 짧은 시간만에 묻혀 버린 비운의 마지막 9x 계열 운영체제로 역사에 기록된 셈이다.

98도 마찬가지. 처음 나왔을 때는 윈도우 95+IE4 통합일 뿐이라고 비아냥거림이 많았지만, 95는 마우스 휠, USB, 멀티 모니터라는 개념 자체가 없었던 캐 구닥다리였다. 그런 것들이 도입되고 IME의 문자 입력 프로토콜이 유니코드로 확장된 것만으로도 98은 정말 숨통을 튼 것이었다. 98 SE는 윈도우 9x 계열 중에서는 정말 최장수 안정판이었음도 주지의 사실이다.

Posted by 사무엘

윈도우즈에서 메모장은 그야말로 운영체제의 역사와 함께 해 온 기본 프로그램이다.
1.0때부터 있어 왔고, 윈도우 7에서도 도구상자 하나, 리본 하나 장착되는 법이 없이 그 베이직한 형태를 유지하고 있다.

사실, 맥에서는 TextEdit, 우분투 리눅스에서는 gedit라고 하여 워드패드와 메모장의 구분이 딱히 없이 서식/비서식 텍스트를 모두 다룰 수 있고 텍스트의 경우 문법 강조까지 지원되는 우수한 에디터가 있는 반면 윈도우즈는 그렇지 못하다.

TextEdit은 수십 MB의 텍스트 파일을 열어서 수십 MB에 달하는 구간을 블록으로 잡아서 지워도 성능 하락이 그렇게 크게 느껴지지 않을 정도로 에디팅이 굉장히 탄탄하게 잘 만들어져 있다는 생각이 들었다.
(참고로 <날개셋> 편집기는 그렇지 못하다. 특히 TSF를 A급으로 지원해 주는 데 드는 오버헤드가 굉장히 큰 편이기 때문에, 10MB급 이상 되는 파일을 편집할 때는 “TSF 지원” 옵션을 끄고 프로그램을 다시 실행하는 게 좋다.)

어쨌든..
메모장은 운영체제가 제공하는 기본 에디트 컨트롤을 사용한다. 보통 텍스트 에디터는 매 줄별로 linked list를 사용하는 반면, 에디트 컨트롤은 텍스트 전체가 한 배열이다! 텍스트 맨 앞에다 문자를 삽입하는 경우 그 뒤 문자열은 일일이 한 자씩 뒤로 밀려나며, 메모리 공간이 부족한 경우 전체 메모리가 재할당된다. ㅎㄷㄷㄷ

이런 이유로 인해 메모장은 비록 가볍다고 해서 덩치 큰 파일을 편집하는 데 좋은 환경이 되지는 못한다. 윈도우 9x 때까지는 16비트의 잔재로 인해, 아예 64KB가 넘는 파일은 읽지도 못하던 암울한 시대가 존재했었다. NT급으로 와서는 그런 물리적인 크기 한계는 비록 해결되었지만, 에디팅 엔진은 여전히 64KB짜리 작은 파일에나 적합하게 설계되어 있다는 사실은 변함없음을 기억할 필요가 있다.

거의 변화가 없는 것 같은 메모장이지만 운영체제 버전이 올라가면서 개선된 것도 은근히 많았다.
Fixedsys 고정이던 글꼴을 바꿀 수 있게 된 것이 윈도우 98부터이고, XP부터는 자동 줄바꿈 옵션을 끈 경우 줄/칸 위치를 보여주는 옵션도 추가되었다.

같은 메모장이라 해도 윈도우 9x 계열과 NT 계열은 저렇게 읽을 수 있는 파일 크기만 차이가 나는 게 아니라 편집 기능에도 차이가 존재한다. 전자는 찾기 기능만 제공되는 반면 후자는 바꾸기도 지원하며 한번에 전체 바꾸기(replace all) 기능도 제공된다.

그런데 전체 바꾸기 기능을 구현한 방식이 무척 재미있다.
윈도우 2000/XP는 말 그대로 매번 메시지를 보내서 순차적으로 찾기/바꾸기를 수행한다. 그래서 화면이 쭉 스크롤되어 내려가는 모습이 보이며, 바꾸기 작업을 수행한 후에 Ctrl+Z를 누르면 바로 직전에 바꾼 문자열 하나만 취소가 된다.

그 반면 비스타는 문자열 전체를 선택하여(select all) 얻어 온 후, 내부적으로 문자열을 기계적으로 빠르게 치환한다. 그러고 나서 문서를 그 텍스트로 일괄 교체한다. 덕분에 Ctrl+Z를 누르면 바꾸기 작업이 전부 취소된다.

근본적으로 에디트 컨트롤에는 일괄 바꾸기 기능을 수행하는 기능이 없기 때문에 응용 프로그램이 그런 것을 직접 구현할 필요가 있다. 하지만 비스타의 메모장은, 메모리를 좀 희생하는 대신 더 빠르고 일괄 취소가 가능한 방법을 선택한 것이다.

Posted by 사무엘