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

1.
지난 5월 말, 석가탄신일 연휴 때 고향에 가서 부모님께서 쓰시는 컴퓨터를 여러 군데 손 봤다. XP 정도나 돌릴 수 있는 구형 컴퓨터이다. 내가 없는 사이에 컴퓨터 A/S를 받아서 하드를 포맷하고 운영체제를 새로 설치했다고 하던데, 파일 시스템이 웬 생뚱맞게 FAT32로 되어 있어서 당장 NTFS로 바꿨다.

그리고 드디어 IE7을 설치했다. 부모님의 반응은 “서울 컴퓨터와 같은 인터페이스이구나”였다. 내가 있는 곳에서는 XP가 없고 비스타만 있기 때문이다. 탭을 지원하고 메뉴가 기본적으로 숨어 있는 IE7의 외형과, 그렇지 않은 IE6의 외형은 부모님이 보시기에도 차이가 명백했던 것이다.

때가 2010년인데 IE8이 아닌 IE7을 선택한 이유는 짐작하다시피 병맛 같은 국내 사이트 때문이다. 교사가 쓰는 컴퓨터에다 NEIS가 안 돌아가는 브라우저를 설치할 수는 없는 노릇이고, 본인 역시 IE8을 비스타 64비트에서 한번 설치해 봤다가 국민 은행 뱅킹이 에러 메시지도 없이 그냥 전혀 동작하지 않는 걸 보고, 혼비백산하여 곧바로 IE7로 복귀해야만 했다. 본인의 개인 노트북에만 IE8을 설치해 쓰는 중이다.

IE8이 IE7보다 그렇게도 가벼워지고 성능이 향상되고 ACID 지수도 올라갔다고 하는데 본인은 거기까지는 잘 모르겠다. 그저 탭의 윗부분 색깔이 colorful해졌다는 차이밖에 안 보인다. 세월이 흐르면서 본인은 얼리 어답터 기질은 다 죽어서 업데이트 같은 걸 귀찮아하는 타입. O<-<

그럼에도 불구하고 본인이 지금까지 서울 각지에서 이용해 본 PC방들은 어쩜 이리도 한결같이 IE6을 쓰고 있으니 과연 충격과 공포이다. 각종 통계에 잡히는 IE6 사용자들의 상당수가 PC방이 아닐까 하는 생각이 들 정도였다.
윈도우 XP sp3이면 어차피 IE8까지 돈도 안 들이고 업그레이드 가능한데 왜 이런 투자에 인색한 걸까?

여기서 IE의 역사를 좀 살펴보자. 1은 가히 듣보잡이고, 2는 윈도우 95 번들로 제공된 최초의, 그러나 정말 빈약한 버전이었다.
3은 드디어 넷스케이프 3과 맞장뜨기 시작한 버전인데, 넷스케이프의 플러그 인에 대응하여 ActiveX를 최초로 내장했다. IE3은 MS가 개발한 프로그램 중 전무후무하게 toolbar에 텍스처가 존재했으며, 마우스가 가리키고 있는 버튼에만 윤곽이 나타나는 소위 flat 스타일 toolbar를 최초로 도입한 프로그램이었을 것이다. 나름 산뜻한 외형을 지향했다는 뜻.

오늘날의 IE의 근간이 잡힌 건 4부터이다. HTML 도움말, 액티브 데스크톱 같은 갖가지 기술이 이때 첫 도입됐다. 5에서는 complex script, global IME 등 다국어 처리 능력이 크게 강화된 걸로 기억하며, 무려 윈도우 3.x를 지원한 마지막 버전이다. 그 이후의 버전에 대해서는 설명을 생략하겠다.

윈도우 XP와 같은 시기에 출시된 IE6이 수 년간 엄청 장수하고 독점적인 지위를 누리면서, MS에서는 이제 IE 팀을 해체할까 하는 생각까지 했다고 하는데 흠좀무. 그러던 차에 2004년 가을을 생생히 기억한다. 모질라 재단에서 파이어폭스라는 획기적인 브라우저를 내놓으면서 현재까지 IE의 독점 구도를 크게 무마하는 데 성공했다. 오늘날은 잘 알다시피 구글 크롬까지 빠른 속도를 강점으로 승부 중이다.

2.
오늘날처럼 블로그나 트위터 같은 게 생기기 전, 너도 나도 나모 웹에디터 같은 프로그램으로 아기자기한 홈페이지 만들던 시절이 있었다. 딱 그런 옛날 스타일 홈페이지를 보면 감회가 새롭다. 애니메이션 gif, 아주 초보적인 수준의 플래시, 그리고 테크노트나 제로보드 기반 게시판들. 본인이 학창 시절 때 몇몇 선생님들이 만든 홈페이지가 아직도 그런 스타일이다. 옛날 생각이 난다.

본인이 인터넷이란 걸 처음 접한 게 1997년 말이다. 내가 저장해 놓은 적이 없는 새로운 글과 그림이 화면으로 쏟아져 나오는 게 이리도 신기할 수 없었다. 그때 조선일보던가 MBC던가.. 국내 언론사들은 웬 VivoActive player라는 듣보잡 ActiveX로 동영상도 보여주곤 했다. 물론 지금과는 비교조차 할 수 없는 열악한 화질이었지만 말이다. 그때는 RealAudio/Video도 있었으나, 컴퓨터와 네트워크 속도의 향상 덕분에 이내 mp3 등에 캐발리고 말았다. 그리고 얼마 안 가 넷스케이프도 IE에 완전히 발린다.

3.
맥 OS에는 애플에서 자체 개발한 사파리라는 브라우저가 기본 내장되어 있다. 비록 사파리는 크로스 플랫폼 프로그램이기는 하지만, 윈도우에서는 별 재미를 못 보고 있는 모양이다. <날개셋> 한글 입력기도 그렇게 윈도우, 맥, 리눅스를 다 날아다니는 프로그램이었으면 얼마나 좋을까?

그나저나 맥 OS 클래식은 9까지만 해도 메모리 보호와 선점형 멀티태스킹조차 지원되지 않았다니 대체 뭐야... 90년대 말까지 쓰이던 운영체제가 기술적으로는 그 허접한 윈도우 3.1과 다를 바가 없었다는 말인지? CPU가 16비트였는지 32비트였는지? PC 쪽과는 역사가 너무 다르니 그저 궁금할 따름이다. 어렸을 때부터 본인에게 매킨토시에 대한 이미지는, 전자 출판과 복잡한 그래픽 작업처럼 PC하고는 가히 넘사벽인 최고급, 최고가 컴퓨터였기 때문이다.

아울러 맥 OS X에는 그림판뻘 되는 간단한 그래픽 편집기를 내장하지 않고 있다는 것에도 깜짝 놀랐다. 워드패드와 메모장 둘의 역할을 훌륭하게 해 내는 TextEdit는 있지만 그림판에 대응하는 프로그램은 없다니... =_=

Posted by 사무엘

이 글에서 소개하는 두 게임은, 본인이 좋아한 장르가 아니고 즐겨 하지는 않았지만, 본인의 기억에 비교적 좋게 남아 있는 고전 게임이다.

1. LHX

헬리콥터 시뮬레이션 게임이다.
1992년 5월, 초등학교 4학년의 나이로 본인이 최초로 접한 개인용 컴퓨터가 286 AT급 기종이었다. 40MB짜리 하드디스크의 GAME 디렉터리 아래에 기본으로 깔려 있던 게임이 페르시아 왕자 1과 바둑(the many faces of go던가? 그 유명한 프로그램), 그리고 이놈이었다. 그러니 이 게임을 어찌 잊을 수 있으리요?

그 시절엔 단순한 화면 스크롤이나 스프라이트의 2차원적인 이동 말고 전체 화면급으로 프레임이 완전히 새로 바뀌는 애니메이션 자체를 보기가 쉽지 않던 시절이었다. 컴퓨터 성능이 뒷받침을 못 해 줬기 때문이다. 그런데 부동소수점 전용 프로세서조차 없던 그 열악한 기계에서 비록 허접하게나마(텍스처 같은 것도 없고 그저 solid color ^^) 3차원 공간이 구현되고 헬리콥터 조종석이 1인칭 시점으로 보이니 놀랍지 않을 수 없었다.

인트로 화면에서 LHX 글자와 ■●▲ 도형이 뱅글뱅글 돌아가는 애니메이션도 아주 인상적이었다. 캐드 프로그램 같다. 본인이 먼 훗날에 3차원 그래픽 시연 프로그램을 직접 만들 수 있게 됐을 때도 둠, 퀘이크와 더불어 이 장면이 떠오를 정도였다. 아 이제야 나도 저런 프로그램을 만드는 이론적인 배경을 터득했구나!

꽤 현실감을 추구했던 만큼, 헬리콥터의 체력은 단순히 hit point 하나로만 표현되는 게 아니라, 속도계의 일부가 깨지거나 어느 부품이 날아가거나 무슨 기능이 박살나는 것처럼 무척 세세한 묘사가 지원되었다. PC 스피커로 나오는 소리 역시 백미. 본인은 도스 시절에 하드웨어 제어 프로그래밍 경험이 전혀 없이 32비트 윈도우 운영체제로 바로 넘어간 세대이기 때문에, 옛날에 그런 걸 갖고 놀았던 시절이 무척 신기하게 느껴진다.

LHX의 개발자는 Brent Iverson이다. 프로필을 보니 예술 쪽과 전산학 내공을 두루 갖춘 굉장히 탁월한 프로그래머인 것 같다. 과거에 유명한 2D 그래픽 프로그램이던 딜럭스 페인트의 도스용 포팅을 한 사람이기도 하다.
(상업용 게임들이 320*200 256컬러 VGA에서 돌아가던 시절에는 딜럭스 페인트가 오늘날의 포토샵 정도로 스프라이트 만들 때 필수 툴이었다. ^^;;)
듣기로는 군 복무 경력도 있는 듯? 그러니 저런 사실적인 군사 미션 게임도 만들 수 있었을 것이다.

다음은 LHX 화면 녹화 동영상이다.
http://www.youtube.com/watch?v=rbgJGg5yd1A (인트로 화면)
http://www.youtube.com/watch?v=VC3OUrgf1Lg (게임 플레이)

2. 대항해시대 2

대항해시대 시리즈 중에서 가장 명작이었다고 평가 받는 작품. 본인에게는 국산 게임인 <그 날이 오면 3>만큼이나, 음악이 아름다워서 기억에 남는 게임이다.
오프닝부터... 툭툭툭툭 툭툭툭툭.. 빠암 빠암.. 빠암 빠암.. 빠 밤 빰... ^^;;
그리고 비록 3D와는 관계가 없고 16컬러이기까지 하지만, 그래픽 역시 16컬러치고는 색상이 미려하고 고해상도의 장점을 살려 깔끔한 편이다.

다음은 이 게임의 오프닝 동영상이다.
http://www.youtube.com/watch?v=EM143YYEdEg

일본물에 조예가 깊은 분이라면 이미 알겠지만, 이 게임의 음악들을 작곡한 사람은 칸노 요코라는 40대 중반의 여성 음악가이다. 초등학교에 들어가기도 전부터 작곡을 했다는 음악 신동이라 한다. 캐릭터 선택 음악, 항해 중 음악 등등... 아주 낭만적이다.
이 사람은 유수의 게임뿐만 아니라 우리나라의 몇몇 드라마 주제곡도 작곡했으며, 한국에도 팬이 많다.

이 게임은 한글화도 되어 나왔다. 요즘처럼 유니코드도 없고 문자 처리의 국제화와 관련된 그 어떤 표준도 존재하지 않던 시절에 localizing은 상당한 고역이었을 것이다.
특히 이름을 입력할 때 쓰이는 한글 입력 루틴은 어떻게 만들었을까? 키보드를 이용한 두벌식 한글 입력 같은 건 당연히 존재하지 않았으며, 한글 자모를 화살표로 일일이 선택한 후 조합해야 했다.

그러고 보니 오늘날처럼 터치 스크린이나 포인팅 장비가 대중화하기 전부터도, 아주 제한된 key만으로 한글이든 로마자든 글자를 입력해야 하는 환경이 있었다. 게임, 특히 오락실 게임에서 말이다. 알파벳과 숫자 정도야 그냥 A부터 Z까지 위 아래 화살표로 고르고, 대소문자마저 무시하고서 이니셜만 입력하게 해도 되지만 한글은 그보다는 복잡한 과정이 필요할 것이다.

그러나 한글은 그래도 그런 환경에서 입력을 구현이라도 할 수 있지, 일본어와 한자로 가면 정말 답이 안 나온다. 일본이 다른 소프트웨어 중에서도 오직 게임 산업이 발달한 것은 그나마 가장 locale-neutral한 분야여서 그렇다고 하는데 사실인지?

우리나라가 한글 처리에 특화된 아래아한글이라는 워드 프로세서가 강세이듯,
일본도 외국 기업이 흉내 내기 어려운 수준의 일본어 처리 능력을 자랑하는 이치타로(일태랑)라는 토종 워드 프로세서가 있다고 한다. 하지만 아래아한글만치 독자적인 영역을 확보하지는 못하고 결국 MS 워드에게 발리고 있는 듯? 하긴, 일본은 IME마저 패키지 소프트웨어로 팔리는 나라이니, 문자 사정이 한국과는 마치 지구와 금성의 차이만큼이나 극단적으로 다르다. 그래도 한국에도 <날개셋> 같은 3rd-party 입력기가 있다. ^^;;

.
.
.

갑자기 얘기가 문자 쪽으로 새었다. 다시 게임 얘기로 돌아오자면..
풍부한 리소스와 하드웨어 환경만이 명작 게임을 반드시 보장하지는 않는 것 같다.
개나 소나 3D를 써야 하는 오늘과는 달리, 옛날에는 오히려 제한된 자원의 특성을 이용해서 더욱 창의적인 방식의 게임이 많이 시도되었다. 레밍즈나 테트리스 같은 게임이 3D로 컨버전된 후 완전 ㅈ망이지 않았던가.
또한, 그야말로 불멸의 명작으로 평가 받는 스타크래프트도 3D가 전혀 아니며, 무려 윈도우 95에서 실행 가능하고 640*480 256컬러로 돌아가는.. 초 구닥다리이다.

본인은 온라인 게임류를 별로 안 좋아해서 품질 좋은 패키지 게임을 선호하는 편이지만,
게임 업계의 현실은 불법 복제 걱정이 없는 온라인밖에 답이 없는 모양이다.
마치 노트북도 4:3 화면을 선호하는데 온통 와이드 화면밖에 안 나오는 것처럼 말이다.

Posted by 사무엘

Posted by 사무엘

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

과거 도스+윈도우 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 사무엘