1. IE-only 사이트들

세상엔 아직도 크롬/파폭 같은 비 IE 브라우저에서는 웹사이트 레이아웃이 깨진다거나, 특히 플래시 메뉴 같은 걸 클릭해도 반응이 없는 안습한 웹사이트가 적지 않다.
사실은 플래시가 아닌 메뉴 중에도 비 IE에서는 동작하지 않는 게 있다.
이런 건 주로 무슨 표준을 안 지키고 뭘 잘못 만들어서 그런 건지 개인적으로 굉장히 궁금하다.
ActiveX 같은 걸 쓴 것도 아니고 순전히 자바스크립트 같은 다른 계층의 문제일 것이다. 네이티브 코드를 실행 안 하면 절대 안 되는 상황도 아니며, 코드를 약간만 수정해 주면 의외로 금방 문제를 해결할 수도 있어 보이는데 그저 안타까울 뿐이다.

2. 이런 메뉴 디자인은 최악

그리고 이건 브라우저 호환성 문제는 아니고 웹 디자인과 관련된 다른 얘기.
마우스로 어떤 메뉴를 가리키고 있으면 하부 메뉴가 아래에 뜨고, 그 하부 메뉴를 클릭했을 때 다른 웹페이지가 뜨는 구조인 플래시 메뉴를 생각해 보자. 우리에게 아주 익숙하다. 그런데, 하부 메뉴가 세로가 아니라 주 메뉴와 같은 형태인 가로로 길쭉하게 나타나는 사이트가 많다. 가령,

[ 회사소개 ] | 제품소개 | 커뮤니티 | 사이트맵
회사는  / CEO 소개 / CI 소개 / 조직 구성 / 찾아오시는 길

같은 식.
그런데 굉장히 불편할 때가 언제냐 하면,
마우스 포인터가 { 회사는 ... 찾아오시는 길 } 이라는 하부 메뉴 영역의 위나 아래로 조금만 벗어나도 그 하부 메뉴가 싹 사라져 버릴 때 말이다. -_-++++++;;;

자, [회사소개]를 가리켰다가 저 끝의 [찾아오시는 길]을 선택하는 게 아주 고역이 아닐 수 없다. 차라리 세로로 길쭉해서 하부 메뉴가 가로와 세로로 모두 충분히 공간이 있다면 모를까 저건 좀...;;;
[조직 구성]까지 갔다가 실수로 마우스 포인터를 아래로 옮기면 하부 메뉴가 사라져 버리고, 그럼 다시 [회사소개]를 가리키러 마우스 포인터를 옮기는 삽질을 해야 한다.
그런 메뉴는 좀 하루빨리 시정됐으면 좋겠다.

3. ActiveX

인터넷 세계에서 평생까임권을 획득한 존재이다. 물론 ActiveX의 존재라든가 취지 자체가 악의 축이라고 몰아붙이는 건 좀 억울한 면, 오해가 있는 면도 있다.
2000년대 초까지만 해도 인터넷 상으로 동영상 하나 보려고 해도, 아니면 게시판용 위지윅 HTML 에디터를 좀 붙이려고 해도 온갖 듣보잡 ActiveX 없이는 안 됐었다.
동영상이야 플래시가 2005년쯤부터 완전히 접수해서 여타 플레이어들을 발라 버린 덕분에 게임이 끝났다. 사실은 플래시 자체도 ActiveX이지만 이 녀석은 쓰임이 워낙 범용적이고 전세계 PC에 널리 퍼진지라 예외로 인정되는 인터넷 필수 구성 요소가 되었을 뿐이다.

그 반면 HTML 에디터는 무척 놀랍다. 블로그의 등장과 이것 때문에 평범한 양민이 HTML 코딩으로 홈페이지 만들 일이 완전히 없어졌으며, 덕분에 로컬 환경에서 네이티브로 동작하는 웹에디터는 떡실신하고 만 것이다. 간단한 HTML 위지윅 에디터는 심지어 비주얼 스튜디오 같은 개발툴조차 내장하고 있다. 그러니 기존 웹에디터는 아예 웹사이트 관리자 아니면 HTML 기반 도움말 저작도구로 더 전문적으로 변모하지 않으면 안 되게 구도가 바뀌었다.
요즘은 게시판 하나 만들려고 해도 HTML 에디터는 필수이다. 그런 점에서 그냥 plain text 입력 폼만 덩그러니 뜨는 제로보드 4는 엄청 캐안습 구닥다리이다.

웹에서 돌아가는 위지윅 HTML 에디터가 정착해 가던 과도기에는 이랬다. 그나마 조금 배려를 했다는 사이트는 IE에서는 full feature 위지윅 에디터가 뜨고, 여타 브라우저에서는 그냥 plain text만 입력할 수 있는 에디터가 떴었다. 본인의 주 메일 계정인 드림위즈의 이메일 작성 UI가 한 2, 3년 전까진 딱 그랬었다. plain text only -> IE만 위지윅 에디터 -> 다 위지윅 에디터의 식으로 발전하여 요즘은 어디서나 위지윅 에디터 제공.

요즘은 저렇게 동영상에, 위지윅 에디터에, 어지간한 암호화까지 웹 표준이 커버하는 분야가 크게 늘어난 덕분에 웹 상으로 굳이 네이티브 코드를 소환할 일은 점점 줄어들고 있다. 인터넷 상으로 내 컴퓨터 시스템 정보를 표시해 준다거나, 진짜로 키보드 드라이버 차원의 보안을 구현한다거나, 설치되어 있는 소프트웨어 정보를 레지스트리 정보를 통해 파악한다거나.. 그 정도가 아니라면 말이다.

2000년에 처음 개발된 <날개셋> 한글 입력기 1.x는 무려 ActiveX로 만들어졌었다! -_-;;;
아직 정식 인스톨러 패키지도 없던 시절에 도스창에서 regsvr32 해 주고 <날개셋> 편집기를 구동해서 세벌식 모아치기를 쓰던 시절을 기억하거나 겪어 본 분이 독자 중에 얼마나 있을까? ㅋㅋㅋㅋ
그때 본인은 <날개셋> 자체 에디트 컨트롤을 ActiveX로 만들면 비주얼 베이직이나 심지어 웹브라우저에서도 그대로 연동 가능하다고 해서 그냥 시범삼아 그 테크닉을 써 본 것이다. 그때는 아직 인터넷 상으로 ActiveX 컨트롤 자체를 보기 힘들었고 그게 지금처럼 악의 축으로 문제되기도 전이었다. 오픈웹 운동 나부랭이 따위도 없었다. 그랬는데... 세월 참 많이도 흘렀다.
그러다 2.0부터는 그냥 일반 윈도우 컨트롤로 바뀜.

4. 운영체제 재설치

본인은 가상 머신이 아닌 실제로 사용하는 개인용 컴퓨터의 운영체제를 마지막으로 재설치한 건... 무려 2007년 초쯤이다. 3년이 넘게 윈도우 설치 화면을 볼 일이 없이 지냈으며 앞으로도 당분간 볼 일이 없을 것이다. 본인 노트북은 꽤 오래 전부터 CD롬 드라이브가 고장났으나, 이것도 쓸 일이 없으니 고칠 일도 없었다. 요즘 컴퓨터는 아예 USB 메모리로도 부팅 가능하다고 하는데, 아무리 그래도 그렇지 부팅이 가능하려면 파일 시스템 차원에서 프로그램 파일이 아주 특수하게 기록되어 있어야 하지 않나? 어떻게 그게 가능한지 궁금하다.

마지막으로 윈도우를 재설치하던 3년 반 전에는 XP를 쓰고 있었는데, 그때는 운영체제가 확실하게 맛이 가 있었다. 딱히 악성 코드나 바이러스에 걸린 것도 아니었는데 언제부턴가 제어판의 일부 구성 요소가 제대로 안 나오고, 뭔가 전반적인 성능이 떨어진 느낌이 들고.. 내가 아무리 컴퓨터 유지 보수를 귀찮아하는 게으른 타입이라 해도 이건 인간적으로 OS를 정말 재설치해야 한다는 신호라는 느낌이 팍팍 들었다. 그래서 하드를 포맷해 버렸다.

하지만 점점 운영체제의 자가 관리 능력이 향상되면서 하드를 포맷하고 운영체제를 재설치해야 할 일은 줄어들고 있다는 느낌이 든다. 아직 비스타를 3년이 넘게 써 보지는 못했으나, 굉장히 안정적이라는 건 느낀다.
다만, 각종 업데이트와 패치를 설치하면서 디스크 용량이 줄어드는 건 어쩔 수 없는 듯.
윈도우를 새로 설치하면 그때까지 누적되어 있던 온갖 업데이트, 서비스 팩들도 다 원점으로 돌아가니 안습이다. 업데이트 내역만 쉽게 export/import하는 방법이 있었으면 좋겠다.

Posted by 사무엘

2010/07/27 08:37 2010/07/27 08:37
, , , , ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/331

Trackback URL : http://moogi.new21.org/tc/trackback/331

Comments List

  1. 다물 2010/07/27 10:44 # M/D Reply Permalink

    오픈아이디는 여전히 안되네요 ㅜ.ㅜ

    전 플래시가 제일 싫습니다.
    액티브 엑스는 보안이 좋아지면서 내가 깔기 싫으면 안깔면 됩니다.

    하지만 플래시는 안깔면 웹페이지 하나 들어갈 때 마다 몇 번이나 취소 단추를 눌러줘야 하니 도저히 안깔고 버티지 못하게 합니다.

    막상 깔고나면 플래시 때문에 죽는 오류도 많구요.

    아이폰에서 왜 플래시 안되게 했는지 이해가 되는 부분이죠.
    플래시로 만든 메뉴들도 제발 없어졌으면

    1. 사무엘 2010/07/27 17:30 # M/D Permalink

      MSI와 플래시를 싫어하시는 다물 님 ^^;;
      플래시도 점점 능동적인 요소가 많아지고 덩치도 너무 커져서.. 처리하기 골치아픈 존재가 돼 있죠.
      그리고 글에서 언급된 그 정도 메뉴는 이제 플래시 안 써도 어지간한 건 다 구현 가능한 거 같더군요.

    2. 다물 2010/07/28 10:00 # M/D Permalink

      아무래도 관심이 많거나 많이 보는쪽이 되다보니...

      전 MSI나 플래시로 오류 수 없이 겪어 봤습니다.(제 컴퓨터이기도 하고 다른 사람 컴퓨터이기도 하고)

      인스톨러 안되면 맨날 레지스터리 지우고 있어야 하고(처음에 모를땐 그냥 포맷도 몇 번 했습니다), 플래시 오류나면 웹브라우저 계속 죽으니 요즘도 불여우에서 플래시 충돌 났다는 창을 일주일에 몇 번씩은 보는데 보고 단추는 누르지만 그 외에 사용자가 할 수 있는 방법이 없죠.

      두 가지 모두 싫어하지만 그게 없는 세상에서 살 수 없으니 투덜만 대고 있는거죠 ㅜ.ㅜ

  2. 삼각형 2010/07/27 10:49 # M/D Reply Permalink

    1. OnlyIE 사이트에서 메뉴의 경우 보통 자바스크립트 문법을 비표준으로 사용하는 경우가 많습니다. IE가 함수 호출에 ""을 허용하는 등 자바스크립트 문법을 느슨하게(기괴하게) 적용하고 있거든요. 아니면 레이아웃이 깨저서 메뉴를 클릭할 수 없다던가.
    2. 요즘은 하위메뉴 크기를 크게 만들어서 그런 문제를 해결하더군요.
    3. 파이어폭스 사용중이지만, 이제 보안과 관련된 분야 외에는 ActiveX볼 일은 없는 것 같습니다. 다운로드 보안을 위해서 전용 다운로더를 실행한다거나, 해킹 방지 도구, 아니면 게임 인스톨러 같은 것들이요.
    4. WinVista 이상 부터는 제설치 할 일이 정말 많이 줄었습니다. XP는 2~3달에 한번 정도였다면 이 녀석은 악성코드 감염 같은 큰 일이 없다면 계속 쓸 수 있을 듯. 지금은 한 10달은 버텼군요.

    1. 사무엘 2010/07/27 17:31 # M/D Permalink

      말씀 감사합니다. 삼각형 님이라면 이 분야로 꼭 식견이 있을 것 같았어요.
      그런데 OS 재설치 정말 엄청 자주 하시네요. 짐 싸고 이사를 자주 다니는 거나 마찬가지인데, 프로그램들 다시 설치하고 세팅하기가 부담스럽지 않나요?

    2. 삼각형 2010/07/28 18:26 # M/D Permalink

      엄밀히 말하자면 '복구'라고 해야겠죠. 파티션을 통으로 이미지로 떠놓고 다시 복구하는거 말입니다. 그런데 제가 쓰는 프로그램만 셋팅하고 다른건 건들이지 않은 상태이기 때문에 윈도우즈 제설치에 가깝습니다. 그런데 Win7에 오고 나서는 이미지 뜨지도 않았습니다. 복구할 일이 없고 시스탬 복원으로 해결되는 정도라서요.

  3. 바보 2010/07/27 14:26 # M/D Reply Permalink

    2번.... 진짜 짜증나죠...

    1. 사무엘 2010/07/27 17:30 # M/D Permalink

      예. 각종 교회나 학교 홈페이지 중에서도 저런 곳 은근히 자주 봤어요. 겪어 본 사람이라면 그 짜증나는 심정을 누구나 공감할 겁니다.

Leave a comment
[로그인][오픈아이디란?]

※ 메신저

상대방에게서 마지막 대화가 도착한 지 n초가 경과하기 전에는 ESC를 눌러도 대화창이 없어지지 않게 하는 옵션이 있으면 좋겠다. (과거 대화 내용을 보관하는 기능이 없을 때에 한해)
상대방에게서 말이 막 도착했는데 그걸 예상 못 보고 창을 확 닫아 버리면 대략 난감하다.

아울러, MSN 메신저는 이모티콘 변환을 좀더 지능적으로 했으면 하는 바람이 있다. 이모티콘 때문에 메신저로 프로그램 코드를 주고받을 때 상당한 애로사항을 경험한 사람들이 적지 않을 것이다. 지금은 안 그런데 옛날에는 심지어 (?) 조차도 이모티콘으로 바꾸는 어처구니없는 일이 있었다.
이모티콘 변환은 내가 직접 타이핑하는 문자열에 대해서만 적용하고, 복붙한 텍스트에 대해서는 안 하기만 해도 불편이 상당수 해결될 텐데..

※ 텔넷 클라이언트

서버로부터 특정 패턴의 문자열을 받았을 때 사용자에게 alarm 하거나, 이런 명령을 보내거나, 로컬 컴퓨터에서 뭘 실행하는... 그런 스크립트 기능이 있었으면 좋겠다.
즉, 패턴으로 현재 쉘의 프롬프트 문자열을 등록해 놓고 긴 빌드 명령을 내리면... (가령 안드로이드 OS 빌드 같은)

나중에 빌드가 다 끝나고 프롬프트가 떴을 때, 서버에서 빌드된 이미지를 곧바로 로컬 컴퓨터로 복사한다거나 하는 사용자 정의 이벤트가 실행되게 할 수 있다. 즉, 서버 컴퓨터와 내 클라이언트 컴퓨터의 연계가 가능해진다. 단순히 login 내지 password 요청이 왔을 때 로그인을 자동으로 해 주는 것 이상으로, 이 정도 수준의 자동화 기능은 PC 통신 프로그램도(이야기의 혼잣말 기능 같은) 제공한 걸로 기억한다. 하지만 PuTTY 같은 프로그램에는 아직 없는 듯.

※ 비주얼 스튜디오 2005

본인이 비주얼 스튜디오 2005를 처음 접했을 때의 인상은 무척 충격적이었다. 드디어 아이콘이 16색을 넘어섰고, 무엇보다도 메뉴와 도구모음줄의 외형이 시퍼런 MS 오피스 2003 스타일을 물려받지 않고 예전 버전(VS 2003 = 오피스 XP)을 변형한 형태로, 즉 자신만의 스타일로 갔기 때문이다.

2005는 컴파일러가 더욱 C++ 표준을 준수하고 여러 가지 면에서 기능이 향상된 게 많아 만족스러웠다. 하지만 같이 설치되는 플랫폼 SDK가 좀 이상해서 기본 설치한 환경에서는 <날개셋> 한글 입력기 빌드에 필요한 일부 운영체제 컴포넌트가 설치되지 않았다. 그리고 이 버전에서 제공된 Spy++은 윈도우 비스타 이상급에서는 이상하게 일부 프로세스가 목록에 나타나지 않고 검색도 되지 않았다.
왜 그런지 모르겠다. 2008은 말할 것도 없고 심지어 구버전인 2003도 그런 문제가 없었는데 말이다.

※ 그리고 기타 전반적으로

비주얼 스튜디오, Source Insight, 이클립스는 모두 유명하고 널리 쓰이는 개발 환경이다.
취소(Ctrl+Z), 열기(Ctrl+O), 복사(Ctrl+C)처럼 모든 응용 프로그램에서 거의 이질감 없이 일치하는 단축키가 있는 반면, 전혀 표준화가 안 돼 있고 응용 프로그램마다 제각각인 단축키도 있어서 굉장히 신경 쓰인다.

가령, Find previous/next match 기능은 본인은 F3/Shift+F3에 아주 익숙한 반면 그렇지 않은 프로그램도 있다. 이는 파일 비교· 병합 프로그램도 마찬가지. 심지어 왼쪽/오른쪽 병합 기능도 WinMerge, 아락시스, Beyond Compare 등 프로그램들이 전부 단축키가 다르다.
Undo와는 달리 Redo는 단축키가 일치하지 않는 경우가 많다는 것 역시 특이점. Ctrl+Y or Ctrl+Shift+Z처럼 말이다. 이건 비단 개발 도구뿐만 아니라 워드 프로세서인 아래아한글과 MS 워드의 대표적인 차이이기도 하다.

다음은 불만 내지 제안 사항은 아니고, 윈도우 운영체제 관련 trivia.

1.
윈도우 95, 98, 2000은 welcome 프로그램이란 게 있었다. 즉, 부팅이 끝난 후 곧장 실행되어, 이 운영체제의 새로운 기능을 소개한다거나 자습서를 꺼낸다거나 하는 가이드 프로그램이다. ME는 없었던 걸로 기억한다.
95의 경우, 아직 Did you know 같은 팁 인터페이스가 유행하던 시절이었고(무려, 비주얼 C++ 6에도 아직 있다!) 3.1에 비해 워낙 breaking change가 많았던지라 새로운 기능 팁 위주였다. 그 반면 98과 2000 버전은 팁은 없고 인터넷 연결과 제품 등록과 관련된 아이템이 있었다.

하긴, 윈도우 비스타는 그와 비슷한 개념으로 ‘시작 센터’를 표시하는 게 있긴 하다. 7은 있나?
윈도우 3.1과 95는 자습서까지 있었다. 비주얼 베이직으로 만든 프로그램이었던 걸로 기억.
98과 2000은 운영체제 도움말이 하드코어 chm 형태인 반면, ME는 hta (HTML Application!) 기반의 좀 인터랙티브한 도움말이 추가됐고, XP는 전무후무하게 아예 플래시 기반 자습서 겸 도움말까지 내장하고 있었다. 영어여서 한글판에서는 정식으로 이를 들려 주지는 않았지만 말이다.

2.
32비트에 이어 개인용 PC에도 64비트 시대가 도래하고 64비트 윈도우는 16비트 바이너리는 지원조차 안 하게 되었지만, 아직도 16비트 코드의 잔재가 고스란히 전해 내려오는 분야가 있다. 바로 fon 글꼴 파일인데(ttf 말고), 이제는 시스템 비트맵 글꼴로밖에 안 쓰이는 이 과거 유물은 여전히 16비트 dll 형태이다. 물론 코드는 전혀 없고 리소스 전용 dll이지만...
이 파일은 이제 실행 파일이 아니라 데이터 파일로 해석된다고 보는 게 더 타당하겠다. System, Fixedsys, Terminal 같은 비트맵 글꼴이 fon 파일 형태로 들어있다. 시스템 기본 글꼴조차 힌팅과 안티앨리어싱이 적용된 윤곽선 글꼴로 나오는 판국에 정말 낡은 유물이 된 셈이다.

Posted by 사무엘

2010/07/06 09:07 2010/07/06 09:07
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/312

Trackback URL : http://moogi.new21.org/tc/trackback/312

Comments List

  1. 2010/07/06 10:58 # M/D Reply Permalink

    putty 에서는 스크립트에서 컴파일 끝나고 벨소리가 나도록 작성하고 putty에서 벨소리를 설정하는 정도가 가능하겠네요....

    1. 사무엘 2010/07/07 01:14 # M/D Permalink

      그 이벤트를 잡아내는 게 가능하다면, 그때 단순히 소리만 내는 게 아니라 아예 다른 프로그램을 실행할 수 있게만 해도 무궁무진한 자동화 및 일괄 처리가 가능할 것 같습니다.

Leave a comment
[로그인][오픈아이디란?]

※ CreateFont

받는 인자가 무려 14개나 되어, Win32 API 전체를 통틀어 손꼽힐 정도로 받아들이는 인자가 많다. MSDN 레퍼런스 없이는 함부로 꺼내 쓰지도 못한다.
그렇다고 해서 딱히 포인터를 전달한다거나, 결과값을 받는다거나 하는 것도 아니고 인자들은 다 단순한 int 아니면 문자열들이다. 이 값들을 LOGFONT라는 구조체에다 담아서 한꺼번에 전달하는 CreateFontIndirect라는 함수가 별도로 있기도 하다.

하지만 실제로 쓰이는 인자는 글꼴 이름과 크기(가중치 100), 그리고 아주 가끔 빌드/이탤릭 여부(가중치 20) 정도가 진짜 전부이다.
전문적인 워드/그래픽 프로그램이 아니고서야 장평값이 다르다거나 기울여진 상태로 글자를 찍을 일이 있기나 할까? 운영체제가 기본으로 지정한 퀄리티(안티앨리어싱 여부) 말고 다른 걸 지정할 일도 거의 없기는 마찬가지. 좀더 간단한 형태의 함수가 있었으면 좋겠다. MFC의 CFont::CreatePointFont()처럼 말이다.

※ CreateProcess

인자 개수 10개. 프로그램을 실행하는, 좀더 정확히 말하면 프로세스를 생성해 주는 가장 저수준 함수이다.
실생활에서는 파일 이름과 매개변수(가중치 100)만 있으면 거의 다 통용되고, 거기에다 초기 시작 디렉터리와 윈도우 초기 배치 방식을 나타내는 SW_* 값 정도만 있으면 될 것이다(가중치 20).

하지만 이 함수 역시 사용하기는 무진장 까다롭다. 파일 경로를 나타내는 버퍼는 read only여서는 안 되고 write 가능한 영역에 있어야 한다. 운영체제가 이 문자열을 그대로 strtok 스타일로 tokenize를 했다가 다시 원래 형태로 되돌려 주기 때문이다. null 문자를 잠시 삽입하므로 이는 버퍼를 수정하는 행위임.
디버거 붙일지 여부, 각종 보안 설정, 환경 변수 값, 심지어 멀티모니터 환경에서 프로그램을 초기에 띄울 모니터 위치 등등.. 별별 정보를 다 지정 가능하기 때문이다.

게다가 리턴값으로는 새로 생긴 프로세스 및 스레드의 식별자와 핸들 같은 것도 돌아오는데, 그 핸들은 이 함수를 호출한 프로세스가 알아서 Close 해 줘야 된다. 여간 손이 많이 가는 게 아니다.
MS는 프로그램을 실행할 때 16비트 시절의 잔재인 WinExec 함수를 사용하지 말고 이 함수를 사용할 것을 권하나, WinExec의 간편함(달랑 명령줄과 윈도우 배치 방식만 넘겨주면 됨!)의 유혹을 뿌리치기는 쉽지 않을 것이다. 사실 WinExec도 이제는 내부적으로 CreateProcess를 호출하는 방식으로 실행된다.

※ CreateFile

인자 개수 7개. C 표준 함수에 있는 fopen처럼 파일 이름과 용도(많지도 않다. 읽기 아니면 신규 생성)만 있었으면 좋겠지만, 역시 운영체제 API이다 보니 보안 관련, 파일 공유 여부 같은 잡다한 정보들이 엄청 많이 들어간다. 파일을 그저 문서의 열기/저장 기능 구현 용도로나 쓴다면 대부분의 세부 옵션들은 필요하지 없으며, 그냥 디폴트만 넘겨 주면 된다.
사실 이 함수는 디스크 상의 파일뿐만 아니라 파일의 형태로 표현 가능한 각종 운영체제 오브젝트들을 생성할 수도 있는 상당히 다재다능한 녀석이다. 피타고라스는 세상만물이 수라고 말했다면, 유닉스에서는 모든 게 파일이라고 한다. 윈도우 운영체제도 그런 철학이 아주 없지는 않다.

※ GetOpenFileName

우리에게 친근한 파일 열기 대화상자를 꺼내 주는 함수. 이제 얘는 인자로 일일이 입력 정보를 받는 방식을 애초부터 포기하고, 대신 크고 아름다운 구조체만을 받는 형태이다. C++로는 응당 클래스를 만들어 쓴다. MFC의 CFileDialog처럼.

하지만 실제로 자주 쓰이는 정보는 열기/저장 여부, 시작 디렉터리, 파일 포맷 필터 말고 있나? (가중치 100)
거기에다가 아주 가끔씩 파일 복수 선택 여부라든가 '읽기 전용으로 열기' 같은 자잘한 옵션만.. (가중치 30)
이렇게 굳이 구조체 만들 필요 없이 간단하게 실행이 끝나는 함수도 좀 있었으면 좋겠다는 생각을 꽤 자주 하곤 했다.

※ TaskDialogIndirect

너무나 클래식한 API인 MessageBox 함수를 대체하는 새로운 UI 대화상자 함수로, 윈도우 비스타에서 처음으로 추가된 걸로 잘 알려져 있다.
다른 건 '메시지 박스' 그대로 쓰면 되는데 "다음부터 이 메시지 표시하지 않음" 체크 같은 딱.. 2% 아쉬운 면모만 보충하고 싶을 때... 이 함수가 가히 구세주이다. 참고로 이 함수를 쓰려면 공용 컨트롤 6.0 매니페스트가 필수라는 걸 잊지 말자.

물론 얘는 TaskDialog와 TaskDialogIndirect로 아예 두 버전으로 나뉘어 있고, 쓸데없이 괜히 함수 프로토타입만 복잡한 게 아니라 진짜로 사용자가 실제로 쓸 수 있는 기능이 엄청 많은 게 맞다. 최근에 만들어진 만큼 API를 비교적 잘 설계했다는 생각이 든다. 하지만 정확하게 기억은 안 나는데 TaskDialog에는 정작 내가 꼭 써야 하는 customize 기능이 빠져 있어서 어쩔 수 없이 훨씬 더 복잡한 TaskDialogIndirect 함수만 써야 했던 것 같다. 그건 아쉬운 점.

대화상자의 제목, 큰 제목, 본문, 각 버튼의 모양, 링크, 라디오 상자 등등등...
이건 구조체가 아니라 아예 대화상자 생성 스크립트(XML 기반)를 받게 해도 이상할 게 없어 보인다.
최신 MFC에는 이 task dialog를 감싸는 클래스가 "당연히" 추가되어 있으며, 각종 상업용 GUI 패키지들에는 XP 이하 운영체제에다가도 task dialog를 자체 구현한 솔루션이 있기도 하다.

Posted by 사무엘

2010/06/29 08:53 2010/06/29 08:53
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/306

Trackback URL : http://moogi.new21.org/tc/trackback/306

Comments List

  1. 김 기윤 2010/06/29 09:10 # M/D Reply Permalink

    HFONT myFont = CreateFont(50,0,0,0,0,0,0,0,HANGEUL_CHARSET,0,0,0,0,"궁서");

    ...... 덩치가 흠좀무;

    1. 사무엘 2010/06/29 13:53 # M/D Permalink

      ㅋㅋㅋㅋ 전부 0으로..;; 정말로 서체 이름과 크기 빼고는 평상시에 variation이 거의 필요하지 않은 정보들입니다.
      사실, charset도 유니코드가 보급된 지금은 그리 큰 의미가 없는 개념이 됐죠. 완전히 불필요해진 건 아니지만. ㄲ

    2. 김 기윤 2010/06/29 21:22 # M/D Permalink

      레퍼런스를 보고 왔는데 레퍼런스대로라면 CreateFont(0,0,0,0,0,0,0,0,0,0,0,0,0,0); 도 되는 모양입니다 (.....) 아직 실험은 못해봤지만;

Leave a comment
[로그인][오픈아이디란?]

프로그램의 권한

1.
병특 회사에서 근무하던 시절의 일이다.
그때 본인은 본업을 넘어-_-, ActiveX 컨트롤을 만들어 관리하던 적이 있었다.
(사용자들이 아무리 ActiveX 욕하고 우리나라가 무슨 MS 공화국이네 뭐네 하면서 까도, 일선 개발자들은 위에서 까라면 깔 수밖에 없다. 더구나 본인은 국방부 시계가 돌아가던 중! ^^;;; )
ActiveX는 내부에 플래시 UI를 하나 만들어서 플래시는 웹 상에서 사용자와 소통을 하고, ActiveX는 플래시와 소통을 하면서 플래시만으로 하기 힘든 네이티브 코드를 수행했다. 내가 왕년에 저런 일까지 했다니..

그런데 문제가 있었다. 정확하게는 기억이 안 나지만, ActiveX든 플래시든.. 뭔가 로컬에 있는 파일을 참조하는 건 아무 문제가 없었는데 웹에 있는 놈을 가져오는 건 아무 이유 없이 도무지 되지 않고 작동을 거부하는 것이었다.
먼 옛날 일이 됐으니 망정이지, 이것 때문에 당시 회사에 환멸을 느낄 정도로 좌절하고 삽질했었다. -_-;;

문제의 원인은 보안이었다. 그 당시 갓 출시된 플래시 7이던가 8이던가.. 하필 그때부터 보안 정책이 딱 바뀌어 플래시의 액션스크립트는 아무 웹에서나 정보를 덥석 가져오지 못하게 되었다.
그 반면, 내 로컬 컴퓨터의 ....\flash player\#security\flashplayertrust 이런 디렉터리에다가 configuration file을 만들어서 접근을 허용하는 웹 주소를 먼저 적어 줘야 하고, 플래시는 허용된 웹으로만 접근할 수 있다.
자세한 정보: http://kb2.adobe.com/cps/116/1165eb90.html

어쨌든 이것 때문에.. 가장 권한이 많고 강력한 ActiveX가 DllRegisterServer를 통해 등록될 때 저 flashplayertrust에다가 우리 플래시에 대한 정보를 덩달아 등록해 주고, 등록 해제될 때 그 정보를 삭제하도록 함으로써 문제는 일단락되었던 걸로 기억한다. ActiveX는 네이티브 코드인 관계로 파일, 레지스트리, 웹 등에 다 접근이 되고, 심지어 Win32 API를 직접 호출해서 뭐든 다 할 수 있으니.. 사기 유닛이다.

물론 오늘날은 다른 웹 표준과 RIA 기술도 풍부한데 저런 무식한 방법을 쓰는 건 곤란하다.
참고로 플래시에 전설의 flv 동영상이 추가된 게 그 무렵부터일 것이다. 유튜브가 그때 막 태동했으니 말이다. 플래시가 벡터 드로잉 애니메이션뿐만 아니라 일반 비디오 플레이어 분야도 섭렵하기 시작했으며, 덕분에 이제 인터넷으로 동영상 볼 때 ActiveX 설치를 요구하는 사이트는 개념 없다는 소리를 듣기 시작하게 됐다.

2.
안드로이드 어플 만들면서도 비슷한 경험을 했다. 아놔 다른 프로그램에서는 잘 되는 환경설정 변경이 왜 도대체 안 되고, 기껏 되더라도 왜 내가 바꾼 환경설정이 다른 곳에 도무지 적용이 안 되는지.. 함수 호출 결과는 성공인데.. 그 뒤 결과는 그냥 씹히고 있던 것이다.
하루를 삽질하고 났더니 원인은 역시 매니페스트 파일에다가 android.permission.WRITE_SETTINGS , android.permission.CHANGE_CONFIGURATION 요 따위 퍼미션 요청을 안 해 놨기 때문이었다.

3.
그동안 유닉스 계열 OS에 비해 권한이나 보안 같은 관념이 너무 약하던 윈도우도, 비스타부터는 그쪽으로 좀더 엄격해졌다.
잘 알다시피 사용자 계정 컨트롤(UAC)라는 게 추가됐으며, 프로그램을 관리자 권한으로 실행할 때와 그렇지 않을 때에 허용되는 권한의 차이가 매우 커졌다. 가령, 관리자 권한이 아니면 '내 문서' 말고 다른 디렉터리에다가는 파일을 제대로 만들지도 못한다.

그리고 이 프로그램이 요구하는 권한을 명시하는 게 가능해졌다.
아무 권한에서나 실행 가능한지, 무조건 관리자 모드에서 실행돼야 하는지 하는 걸 말이다.
지정은 EXE 내부의 매니페스트 XML에다가 하면 된다. 그 개념은 이미 윈도우 XP에서 시스템 DLL의 로딩 방식을 제어하기 위해 도입된 바 있으므로 새삼스러울 게 없다.
비주얼 C++ 2008부터는 링커 옵션에 이걸 바로 지정해 주는 게 추가됐다. 그 이전 버전에서는 사용자가 직접 xml 파일을 손으로 써서 링크해 주면 된다.

스크린 키보드처럼 장애인 Accessbility용 프로그램은 의외로 높은 보안 수준이 필요하다.
내가 받은 입력에 대한 결과를 시스템 모든 프로그램에다가 끼쳐야(키보드 입력 흉내) 하기 때문에
이런 프로그램은 별도의 인증을 거쳐야 운영체제가 그 정도의 권한을 허락하게 되어 있다.
그런 인증을 거치지 않은 "<날개셋> 입력 패드"는, 사용자가 직접 관리자 권한으로 실행해 주지 않으면,
자기보다 권한 등급이 높은 프로그램에다가는 글자 입력을 전달해 줄 수 없다.

글을 맺는 소감:
삽질해야 하는 게 싫다. -_-;;
지금 유닉스 명령어 익히느라 땀 뻘뻘 흘리는 걸 보면, 옛날에 지금보다 영어도 훨씬 더 못 하던 시절에 도스 명령은 어째 알아서 외웠는지 궁금하다.
지금 이놈의 안드로이드 때문에 삽질하는 걸 보면, 옛날에 윈도우 API는 어째 공부했는지 내가 생각해도 나 자신을 이해할 수 없다.
그때는 삽질을 삽질이라고 여기지 않고 전적으로 재미로 했기 때문에 프로그래밍에 재미를 붙일 수 있었던 것 같다.

Posted by 사무엘

2010/06/22 08:55 2010/06/22 08:55
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/300

Trackback URL : http://moogi.new21.org/tc/trackback/300

Leave a comment
[로그인][오픈아이디란?]
윈도우 비스타/7에서는 아래아한글의 키매크로가 지원되지 않는다는 걸 며칠 전에야 처음으로 확인했다. 메뉴가 흐려져 있고 아예 선택이 되지 않더라. XP를 졸업한 지 2년이 넘었는데 몇 년째 이 사실을 왜 모른 채 지냈는지 모르겠다. 키매크로는 도스용 1.x 시절 이래로 아래아한글 고급 사용자의 최강의 애용 기능이었는데도 말이다.

아니 그럼 도움말에다가 언급이라도 해 놓지 왜 아무 설명도 없이 메뉴 접근만 막아 놨는지? 그 이유는 인터넷을 검색한 뒤에야 알 수 있었다. 물론 어느 정도 짐작은 했지만 말이다.
(아래아한글 2005는 비스타/7에서는 수 차례의 패치를 안 받으면 에러가 나고 아예 동작을 하지 않으며, 2007도 패치를 받아야 Aero가 적용된 운영체제 표준 모양 스킨을 쓸 수 있다. 비스타에서 키매크로 메뉴를 막은 것도 2005의 패치부터 그렇게 된 거라 함.)

비스타 이상부터는, 아래아한글이 키매크로를 구현할 때 쓰이는 기능 내지 테크닉이 운영체제의 보안에 영향을 끼친다고 간주되어 그걸 운영체제 차원에서 막아 버린 모양이다. UAC 끄고 관리자 모드로 실행해도 별 소용 없다.

사실, 도스가 아닌 윈도우 같은 이벤트 위주 환경에서 키매크로 같은 걸 구현하기는 쉽지 않다. 도스처럼 한 프로그램이 모든 하드웨어 자원을 장악하고 독점하고 일괄 처리를 하는 환경이 아니기 때문이다.
아래아한글이 윈도우용으로 처음으로 포팅되었던 3.0B 시절에는 기능은 분명 화려해졌다. 드디어 아래아한글에다가 윈도우용 TTF에다가 여타 프로그램의 OLE 개체를 집어넣는 게 가능해졌다니.. 그리고 도스용 아래아한글과 정보 손실 없이 파일 공유까지 가능하다니!

하지만 윈도우용에 매크로 기능은 응당 포팅이 안 돼 있었다.
Win32s에, 95에, NT까지 다 신경써야 하던 시절에 그렇게 하드웨어에 민감한 고급 기능을 넣기는 현실적으로 곤란했을 것이다. 내 기억이 맞다면 96까지도 아직 없었다.
그러다가 97에 와서야 프로그램이 Win32s를 제낀 체제로 개편되고 매크로 기능도 다시 생겼다.

그랬는데 한 가지 굉장히 신기한 것은, 매크로를 기록하는 파일 포맷이 9x 계열과 NT 계열이 서로 달랐다는 것이다. 아래아한글 사용 안내문에서 분명히 본 문장이다. 즉, 똑같은 97을 쓰는데, 윈도우 9x에서 녹화하여 저장한 매크로 파일을 NT4에 설치된 97에다 가져와서 쓸 수는 없으며 동일한 매크로를 해당 플랫폼에서 다시 만들어야 했다는 뜻이다.

도대체 무슨 데이터를 저장하기에 똑같은 x86 계열 컴퓨터에서 저장한 매크로 파일이 왜 서로 호환이 안 됐을까? 단순한 키 시퀀스를 저장한 게 아니라 아래아한글의 매크로 구현 방식이 아주 특이했을 거라는 짐작만을 해 볼 뿐이다.
본인은 나름 한컴사전의 노클릭 단어 인식 기능도 어떻게 구현했을지 대략 짐작할 정도이지만, 매크로에 대해서는 여전히 알쏭달쏭 갸우뚱이다. 노클릭 단어 인식도 훅 DLL이 9x과 NT 계열이 서로 별도로 존재하며, 심지어 16비트 프로그램용 훅 DLL까지 들어있다.

그렇게 아래아한글은 윈도우에서도 키매크로를 살려 내기는 했지만, 도스 시절 같은 빠른 속도까지 회복하지는 못했다. 전광석화처럼 화면이 깜빡이며 돌아가는 도스 매크로에 비해 윈도우는...;;
그냥 화면에 그림만 그리는 도스 시절의 대화상자와, 수십/수백 개의 개체로 이뤄진 윈도우 대화상자가 뜨는 오버헤드는... 서로 비교가 안 될 것이다.
게다가 Alt+L, K, T, A, D (블록으로 잡은 텍스트의 한글 서체를 궁서로 바꾸기) 같은 궁극의 단축키 신공도 느릿느릿 마우스 위주인 윈도우에서는 그대로 재현할 수 없게 됐다.

도스든 윈도우든 키매크로 자체를 구현할 정도라면, 매크로가 실행되는 중에 화면 업데이트를 안 하게 하는 옵션을 넣는 것도 불가능하지는 않을 것 같은데, 그것만 해도 매크로의 실행 속도를 무척 향상시킬 수 있지 않을까 싶다.

매크로는 일반적인 워드 프로세서 사용자보다 더 전문적인 컴덕후들이 즐겨 사용하는 텍스트 에디터에서는 더욱 필수인 기능이다. 비주얼 스튜디오의 경우 긴 매크로가 실행 중일 때는 트레이에 풍선 도움말도 뜨고, 이걸 건드리면 실행 중인 매크로를 손쉽게 중단도 시킬 수 있다. 아래아한글에도 이런 배려가 있었으면 좋겠다.

윈도우 환경에서는 도스 시절 같은 기계적인 키매크로의 의미가 여러 모로 퇴색한 만큼, 아래아한글도 최신 버전부터는 스크립트 기반 매크로를 지원하고 있다. 과거 PC 통신 에뮬인 이야기에 혼잣말 기능이 있었듯이. 키 조작이 아니라 키 조작이 의미하는 명령을 기록함으로써 좀더 똑똑하고 효율적인 매크로를 구현하고 간단한 프로그래밍 로직과 분기까지 구현한 것이다. 이 정도로 매크로가 능동적인 존재가 되고 나면, 슬슬 매크로의 보안도 따져야 할 필요가 생길 것이다.

스크립트 매크로는 키매크로와는 내부 구현 방식이 다른 듯하며, 아래아한글도 앞으로는 키매크로를 빼고 스크립트 매크로만 지원할 것으로 보인다.
그런데 스크립트 매크로를 이용하여 키 입력을 녹화해 봤는데 이상한 에러와 함께 실행이 안 돼서리...;;;
급하게 매크로를 수만 번 실행해야 할 일이 있는데 결국은 VMware 아래의 윈도우 XP에다가 아래아한글을 설치해서 키매크로 뺑이를 돌려야 했다. 아놔이런....;;;;;;;;

HWP.EXE의 속성-호환성 탭을 이용해서 운영체제의 버전을 일부러 낮춰 주면 매크로 메뉴를 사용은 할 수 있게 되나, 반복 실행이 되지 않았다. Alt+번호로 개개 실행도 속도가 매우 느렸다. 앞서 말했듯이 아래아한글의 키매크로는 어떻게 구현됐는지 정말 궁금할 따름이다.

제대로 된 매크로를 응용 프로그램이나 운영체제가 지원해 준다면, 매크로를 실행 중인 프로그램은 매크로 실행 결과를 실시간으로 업데이트 하든 안 하든, 최소한 응답이 없이 죽어서 ghost 윈도우가 되는 일은 없어야 하며, 언제든지 중단도 시킬 수 있어야 할 것이다. 그리고 다른 프로그램에서 사용자가 키 입력을 하든 말든 자기는 자기 일만 잘 하고 있어야 할 것이다.

그런데 아래아한글은 그렇지는 못한 것 같다. 매크로를 돌리고 나서 한참 컴퓨터를 가만 놔뒀더니, 화면 보호기가 갑툭튀 실행된 후로 프로그램 창은 거의 ghost 윈도우처럼 아무 응답이 없고, 게다가 그때부터 키보드 입력이 엉뚱한 곳으로 갔는지 매크로가 제대로 실행되어 있지 않았다. 이런 망할 화면 보호기.. -_-

요즘 사람들은 컴퓨터를 안 쓸 때도 그냥 켜 놓는 경우가 워낙 많기 때문에 컴퓨터 설계자들은 idle 상태일 때 전기를 최대한 아끼는 방법을 연구하는 게 당연지사이다.
그런데 가끔씩은 컴퓨터를 서버 용도로 쓸 때도 있고, 프레젠테이션 발표용으로 쓰기도 하고, 윗글처럼 일괄 처리를 시켜 놓는 경우도 있다. 그럴 때는 오랫동안 키보드 입력이 없다고 해서 컴퓨터가 함부로 툭 꺼져 버려서는 안 된다. 이 둘이 마치 교통수단의 이동성과 접근성처럼 동전의 양면 같은 면모가 아닐까 한다.

Posted by 사무엘

2010/05/20 08:32 2010/05/20 08:32
, ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/274

Trackback URL : http://moogi.new21.org/tc/trackback/274

Comments List

  1. 다물  2010/05/24 15:55 # M/D Reply Permalink

    키매크로는 아시는대로 일부러 막았습니다.(MS가 공개해준 자료만 가지고는 정상 동작이 안된다고 하더군요.)
    스크립트 매크로 오류가 나는건 적어주신 글만 가지고는 자세히 알기 어렵습니다.
    좀 더 자세한 내용 적어 주시면 확인해 보겠습니다.

    1. 사무엘 2010/05/25 02:17 # M/D Permalink

      function OnScriptMacro_script3()
      {
      HAction.Run("MoveParaEnd");
      }

      같은 이런 간단한 문장 하나만 넣고 실행해도

      "스크립트 분석에 오류가 발생했습니다.
      설명: (null)
      줄 수: 0"

      이러고 매크로 실행이 전혀 안 된답니다.
      나름 copyright 2010이라고 찍힌 최신 패치가 다 적용된 아래아한글 2007인데..
      뭐가 문제인지 모르겠습니다.

    2. 다물  2010/05/25 13:38 # M/D Permalink

      2010은 잘 되는데 2007은 안되네요.
      좀 더 알아보고 답변 적겠습니다.

    3. 다물  2010/05/26 16:47 # M/D Permalink

      초기화를 해 보세요.

      제품 설치 후 다른 여러가지 요인으로 인해서 제품에 필요한 dll 파일 등록이 제대로 되지 않을 수 있다고 합니다.
      [한글과컴퓨터 기본 설정]을 실행시킨 후 처음 상태로 돌린 후에 확인 해 보세요.
      (답변 적은대로 안되면 전화나 메신저 주세요 - 지금은 메신저 접속 안되어 있으시네요.)

    4. 사무엘 2010/05/29 07:55 # M/D Permalink

      앗, 신기하네요.
      ‘처음 상태로 돌리기’를 체크하지도 않고
      그냥 ‘한글과컴퓨터 기본 설정’을 한번 실행만 해 준 뒤, 프로그램을 다시 실행하니까 매크로가 되기 시작합니다.
      키매크로든 스크립트 매크로든, 아래아한글의 매크로 구현 방식은 신기하게 그지없습니다.
      그래도 다물 님께서도 동일 현상을 확인하셨을 정도라면, 저 오류도 해결돼야 할 사소한 버그가 아닌가 생각됩니다.

Leave a comment
[로그인][오픈아이디란?]

파일 대화상자

1. 파일 대화상자라는 개념

윈도우 운영체제.. 사실 이뿐만이 아니라 플랫폼을 불문하고 현대적인 GUI 프레임워크들은
불러오기/저장하기(파일 선택) 기능을 공통 기능으로 제공한다.

어떤 형태로든 사용자가 작업하는 문서(데이터)를 파일로 읽고 쓰는 소프트웨어치고 이 기능을 안 쓰는 녀석은 없으므로, 이건 가히 필수 공통 기능이라 하기에 손색이 없다. 도스 시절에는 불러오기/저장하기 UI도 프로그래머가 제각각으로 직접 구현해야 했으니 얼마나 번거로웠는지 모른다. 이거 하나만 운영체제가 고수준 API를 제공해 줌으로써 응용 프로그램이 직접 FindFirstFile, FindNextFile 같은 파일 탐색 함수를 호출해야 할 일은 상당수 없어졌다.

물론 이것 말고도 색깔을 찍는 대화상자, 인쇄 대화상자 같은 것도 공통 대화상자에 속하며 운영체제가 제공해 주는 게 있다. 그리고 필요한 경우, 대화상자의 일부 요소나 동작 방식을 프로그래머가 자기 입맛에 맞게 customize하는 테크닉도 응당 제공된다.

2. 윈도우 운영체제의 파일 대화상자의 역사

윈도우 3.x의 파일 대화상자는 파일 목록과 디렉터리 목록이 리스트 박스의 형태로 좌우로 나란히 나오고, 그 아래에는 저장하거나 열려는 파일의 format 그리고 드라이브 목록이 콤보 박스의 형태로 나란히 나와 있었다. 드라이브-디렉터리-파일이라는 클래식한 형태에 충실한 디자인이라 하겠다. 가정에서는 네트웍이 아직 많이 생소하던 시절이었기 때문에, 네트웍 드라이브에 접근하기 위해서는 별도의 버튼을 눌러야 했다.

사용자 삽입 이미지

그러던 것이 윈도우 95/NT4에 와서는 크게 바뀌었다. 사실 윈도우 95부터는 쉘의 디자인의 근간이 싹 바뀌어 오늘날까지 이어져 오고 있다. 드라이브를 제공하는 장치간의 구분이 완화되었고, 가장 최상위 계층인 바탕 화면 아래로 내 컴퓨터, 휴지통 등등이 따르는 컨셉이 이때 도입된 것이다. 파일 리스트는 구닥다리 리스트 박스 대신, 소위 공용 컨트롤이라고 불리는 리스트뷰 컨트롤 기반으로 바뀌고 디렉터리와 드라이브는 폴더라는 개념으로 바뀌었다. 그리고 탐색기가 제공하는 쉘 기능(파일 복사, 붙여넣기, 삭제, 개명, 각종 우클릭 메뉴)은 파일 대화상자 내부에서도 그대로 쓸 수 있게 된 것 역시 큰 변화이다.

사용자 삽입 이미지

윈도우 98부터는 파일 대화상자의 크기 조절이 가능해졌다. 상당히 바람직한 변화이다.

윈도우 2000/ME부터는 파일 리스트 왼쪽에 바탕 화면, 내 문서 등 주요 폴더로 곧바로 이동하는 아이콘이 추가되었다(일명 favorite bar). 그리고 아마 이 무렵부터, 파일이나 디렉터리 이름의 처음 몇 자를 입력하면 자동 완성 후보가 뜨는 아주 편리한 기능이 생겼다.

이 구조가 윈도우 XP까지 이어지다가 비스타/7부터는 또 파일 대화상자가 싹 바뀌었다. 변화의 양상에 대해 한 마디로 요약하자면, 탐색기와의 경계가 더욱 모호해지고 좀더 "웹처럼"(webby) 바뀌었다. 웹 페이지 탐색하는 기분으로 내 컴퓨터의 폴더를 탐색하게 되었는데, 이는 IE4부터 MS에서 부르짖은 캐치프레이즈이기도 하다. 물론 탐색기와 IE의 완전 통합은 보안상의 이유로 인해 IE7부터는 좀 지양되었지만 말이다.

얼마나 바뀌었냐 하면, 파일 대화상자에도 웹브라우저처럼 "뒤로, 앞으로" 버튼이 생겼고, 검색란이 생겼다. 자주 쓰는 폴더 목록은 마치 인터넷 즐겨찾기처럼 뜨기 시작한 것이다. 그런 디자인이야 디자이너의 취향 나름이라 하지만, 기본 크기가 좀더 큼직해지고 마우스로 두세 단계의 폴더를 바로 건너뛰어 상위 단계로 갈 수 있어서 디렉터리 변경이 좀더 편해진 게 매우 좋다.

3. 과거 호환성

이렇게 운영체제가 버전업되면서 파일 대화상자의 디자인은 몇 차례 변화를 겪었다.
응용 프로그램이 아무 조작을 안 가하고 기계적으로 MSDN에 명시된 input과 output만 FM대로 잘 활용한다면, 파일 대화상자의 디테일은 응용 프로그램의 본질적인 동작에 전혀 영향을 끼치지 않는다. (당연한 말이지만)

그렇기 때문에 윈도우 비스타 이전에 개발된 프로그램이라 할지라도, 파일 대화상자 API만 곱게 쓴다면 비스타에서 실행했을 때 최신 디자인의 파일 대화상자가 뜬다. 이게 무슨 공용 컨트롤 매니페스트도 아니고, 최신 대화상자를 쓰기 위해서 응용 프로그램이 뭔가 조치를 취해야 할 필요는 없다.

그럼에도 불구하고 운영체제들은 옛날 버전 파일 대화상자들의 디자인도 갖고는 있다.
응용 프로그램이 파일 대화상자에다가 자신만의 컨트롤을 추가하고, 동작 방식을 제어하고 특정 컨트롤을 서브클래싱까지 하는 경우, 그 파일 대화상자의 디자인이 최신 운영체제에서 바뀌어 버린다면 동작 방식에 심각한 문제가 생길 수 있기 때문이다.

이미지 프로그램의 경우 열기 대화상자에다가는 그림 preview를 추가하기도 하고, 저장 대화상자에다가는 JPG로 저장할 경우 화질을 지정하는 추가 옵션을 대화상자에다 덧붙이곤 했다.
압축 유틸리티나 파일 변환 프로그램은 아예 파일 열기 대화상자에다가 자기네 동작 옵션을 한 보따리 가득 집어넣어 그걸로 프로그램 메인 화면을 만들기도 했다는 걸 알 필요가 있다.

최신 디자인을 적용할 수 없는 경우, 운영체제는 여전히 윈도우 2000이나 심지어 98(favorite bar까지 없어진) 스타일로 파일 대화상자를 출력해 준다.
특히 MFC를 써서 프로그램을 개발하는 경우 이 점을 매우 신경써야 한다. MFC는 프로그래머가 원하는 타이밍에 손쉽게 이벤트를 날려 주기 위해서.. 쉽게 말해 개발자의 편의를 위해서 윈도우에다가 온갖 보이지 않는 훅킹과 서브클래싱을 남발하는데, 이런 이유로 인해서 구형 버전의 비주얼 C++로 CFileDialog 클래스를 쓰면, 아무리 내가 customize를 하는 게 없어도 최신 운영체제에서 파일 대화상자가 최신 디자인으로 나오지 않는다!

까놓고 말해 본인이 개발한 <날개셋> 편집기의 열기 대화상자와, <날개셋> 타자연습의 연습글 추가 대화상자를 윈도우 비스타/7에서 살펴보기 바란다. 차이가 느껴질 것이다.
이런 이유로 인해, 최신 운영체제의 GUI 혜택을 입으려면 새로운 기능을 쓰는 게 없어도 개발툴도 최신으로 써야 하는 경우가 있다. 싫으면 MFC 클래스 쓰지 말고, 불편하더라도 GetOpenFileName처럼 윈도우 API를 직접 호출하든가 말이다. ^^

4. 파일 대화상자의 중복 개발

그런데 MS 오피스 제품들은 전통적으로 운영체제의 표준 API를 쓰지 않고, 무려 자기네가 따로 자체 개발한 파일 대화상자를 사용해 왔다. 가령, 운영체제의 표준 파일 대화상자는 윈도우 2000/ME대에 가서야 favorite bar가 추가된 반면, MS 오피스의 대화상자는 꽤 일찍부터.. 최소한 오피스 97 시절부터 그런 걸 갖추고 있었다.

이런 식으로 MS 내부에서 운영체제 GUI가 오피스 GUI를 뒤쫓아가는 양상은 일상적인 모습 같다. 하다못해 윈도우 3.1 시절에도 오피스가 자체 구현했던 도구모음줄(toolbar), 상황선(status bar), 은빛 3D 효과 대화상자, 프로퍼티 시트와 위저드 같은 게 95로 넘어가면서 운영체제 표준 GUI로 나중에야 편입되었다. 그러던 관행이 세월이 흘러 윈도우 7에서는 리본 인터페이스가 워드패드와 그림판에까지 적용되어 있다.

오피스 제품 중에서도 무려 1980년대부터 개발되어 온 워드와 엑셀은, 겉모습은 별 차이 안 나지만 사실 일반 대화상자들마저도 윈도우 운영체제의 표준 대화상자가 아니며 마치 아래아한글처럼 자체 구현 대화상자이다! 걔네들이 처음부터 아주 크로스 플랫폼으로 개발되어서 그런 건 아니고, 애초에 개발 컨셉이, 빈약한 운영체제의 기본 컴포넌트에 의존하지 않고 자기네 컴포넌트로 UI를 자체 구상하겠다는 방향이었던 것 같다. 그 부자 기업이 하고 싶은 걸 뭘 못 하겠는가?

90년대 이후부터 개발된 파워포인트나 액세스는 그런 수준까지는 아니지만 열기/저장 대화상자라든가 About 대화상자만은 여전히 MS 오피스 공용 라이브러리의 것을 사용해 왔다.
개발툴인 비주얼 스튜디오도 닷넷급부터는 MS 오피스의 GUI 엔진을 이어받고 있는 중이다. 순수 MFC만으로 MS 오피스 짝퉁 GUI을 구현했던 비주얼 C++ 5와 6의 계보는 흑역사가 된 지 오래.

그런데, 그러던 정책이 이제는 바뀌었다.
윈도우 비스타와 동일한 timeline에 개발된 제품인 비주얼 스튜디오 2008과 MS 오피스 2007부터는
놀랍게도 운영체제의 표준 파일 대화상자를 사용하며, 앞으로도 계속 그런 구도가 유지될 것이다!
비주얼 스튜디오 2005와 MS 오피스 2003은 그렇지 않다는 소리.

다만, 이건 비스타 이상에서 실행됐을 때에 한해서이다. 윈도우 XP에서 돌아가는 비주얼 스튜디오 2008이나 MS 오피스 2007은 여전히 자체 대화상자를 사용한다. -_-;; 이것도 무지 신기한 점임.

비스타부터는 이제 운영체제의 파일 대화상자도 기능이 매우 향상되었고 customize하는 수단도 충분히 깔끔해졌기 때문에 굳이 운영체제 따로, 오피스 따로 노선을 갈 필요를 느끼지 않게 되어 그렇게 바뀐 것 같다.
비스타에서는 비주얼 스튜디오 2005의 옛날식 파일 대화상자가 오히려 더 촌스럽게 느껴진다. ^^;;

Posted by 사무엘

2010/05/13 07:34 2010/05/13 07:34
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/267

Trackback URL : http://moogi.new21.org/tc/trackback/267

Leave a comment
[로그인][오픈아이디란?]

사용자 삽입 이미지
위의 그림은 동일한 32비트 윈도우용 프로그램을 세 개 연달아 실행하여
1. 자신의 인스턴스 핸들
2. 어떤 지역 변수의 주소
3. 어떤 전역 변수의 주소
4. 그리고 동일한 공유 메모리(memory-mapped file)를 가리키는 주소
를 차례로 찍은 것이다.

그림을 보면 알겠지만 동일한 실험을
a. 윈도우 3.1+Win32s
b. 윈도우 9x
c. NT급 윈도우

에서 모두 해 봤다. (요즘 버전의 비주얼 C++로 그 구닥다리 Win32s에서도 동작하는 프로그램을 만들려면, 컴파일/링크 옵션을 상당히 특이하게 바꿔야 한다. ㄲㄲ)

Win32s의 한계를 절실히 느낄 수 있을 것이다.
CPU의 가상 메모리 기능을 적극 활용하여 각 프로세스마다 자신만의 주소 공간이 절대 보장되는 윈도우 NT에서는,
같은 프로그램은 아무리 동시에 여럿 실행하더라도 자기 주소가 0x400000으로 고정 불변임을 알 수 있다. 심지어 윈도우 9x조차도 그건 보장된다.

그러나 Win32s는 프로그램을 실행할 때마다 프로그램의 인스턴스 핸들이 제각각이며, 지역 변수와 전역 변수의 주소조차도 완전히 달라진다. 시스템의 모든 프로그램들이 단일 주소 공간을 공유한다는 게 바로 저런 의미인 것이다.

Win32s는 모든 메모리 주소가 0x80000000 위의 상위로 잡혀 있는 것도 매우 신기하다.
9x나 NT급 윈도우에서는 그런 주소는 사실상 커널에서나 볼 수 있기 때문이다.
16비트 운영체제에다 아주 특수한 임시방편으로 32비트를 구현한 Win32s의 동작 방식을 짐작케 한다.

또 하나 재미있는 차이를 발견할 수 있는 것은 인스턴스 핸들과 포인터와의 관계이다.
9x/NT에서는 인스턴스 내지 모듈 핸들이 곧 포인터이기 때문에, 0x400000 같은 값에 해당하는 메모리 주소를 들여다보면 EXE 파일이 통째로 로드된 흔적을 고스란히 찾을 수 있다. 즉 MZ 같은 EXE 헤더가 바로 나타난다는 뜻이다. 그리고 전역 변수의 주소는 역시 근처의 0x40????대로 잡힌 것을 볼 수 있다.

그러나 Win32s의 인스턴스 핸들은 포인터와 아무 관계가 없는 임의의 16비트 정수일 뿐이다. 이는 원래부터 포인터가 서로 아무 관계가 없던 16비트 윈도우의 인스턴스 핸들과 개념을 일치시키기 위한 조치로 보인다. 제아무리 32비트 프로그램이라 하더라도 16비트 운영체제 내부에서는 16비트 규모로 식별이 가능해야 하기 때문이다.

끝으로, 공유 메모리의 주소도 흥미로운 결과가 나와 있다. 오로지 윈도우 9x만이 세 프로그램이 가리키는 주소가 모두 일치해 있다.
이는 윈도우 9x만의 메모리 사용 방식 때문이다. 0x80000000~0xC0...에 해당하는 영역에다 모든 프로그램들이 공유하는 운영체제 시스템 DLL과 공유 메모리를 올려 놓는다. 즉, 이 영역은 윈도우 9x에서는 아무 프로그램이나 바로 접근할 수 있는 단일 주소 공간이나 마찬가지이기 때문에 어느 프로그램에서나 의미가 동일한 셈이다.

NT는 그렇지 않다. 비록 실질적으로 가리키는 물리 메모리는 동일한 위치인지 모르나 이를 가리키는 응용 프로그램의 주소는 완전히 제각각이다. 이렇게 하는 게 훨씬 더 안전하고 보안 관점에서도 유리하기 때문이다.

Win32s는 공유건 응용 프로그램의 코드건 데이터건 가리지 않고 무조건 0x80... 상위 메모리 주소가 뒤죽박죽으로 쓰이는데, 공유 메모리마저 9x와는 달리 제각각인 주소가 배당되는 건 좀 의외이다. 9x는 공유 메모리만 상위 메모리 주소가 쓰였고 NT는 보다시피 상위 메모리 주소가 전혀 등장하지 않는다. 사용자 계층과 커널 계층이 엄격하게 잘 분리되어 있음을 뜻한다.

※ 덧붙이는 말

1. 유니코드

일단 Win32s와 9x는 운영체제의 내부적으로는 유니코드 기반이 전혀 아니다. 그래도 9x는 GDI 계층 차원에서 유니코드 문자를 폰트로부터 인식하고 찍는 건 지원하며 98부터는 유니코드 IME 프로토콜까지도 지원한다. 그 반면 Win32s는 운영체제의 한계 때문에 그런 게 전혀 없다. 운영체제 차원에서 임의의 유니코드 문자를 출력할 방법이 없다는 뜻이다.
오늘날까지 살아남은 NT는 무려 1993년에 나온 3.1 버전부터 애초에 100% 유니코드 지원을 염두에 두고 16비트 wide string을 기본으로 설계했으니 과연 대인배. 물론 이렇게 하려면 메모리가 더 많이 필요하다.

9x는 TextOutW, ExtTextOutW, GetTextExtentPoint32W 같은 GDI 함수는 NT와 기능이 동일하다(비록 surrogate는 지원 안 하지만). 그리고 MessageBoxW도 지원한다. 에러 메시지 뱉고 죽는 최소한의 동작만은 유니코드 함수로도 가능하게 배려했다는 뜻이다.
이외에 리소스를 찾는 FindResourceExW, 명령 인자 옵션을 얻어오는 GetCommandLineW 같은 함수가 유니코드 버전도 간단히 구현돼 있다. 비록 문자열을 ansi 문자열로 변환해서 A 함수를 그냥 호출해 주는 수준이지만.

Win32s는 그런 거 없다. MessageBoxW도 지원하지 않으며, 오로지 WideCharToMultiByte(와 그 역함수) 처럼 문자열 변환 함수만 지원되고 나머지 W 함수는 전혀 지원되지 않는다.

2. GDI/User 계층의 32비트

NT는 순수한 32비트 운영체제인 반면 9x 계열은 아직 상당수의 코드가 16비트로 존재했다. 이런 이유로 인해 9x는 대표적으로 GDI의 좌표계가 16비트 크기로 제한되어 있었으며, NT는 GDI 함수의 실행이 실패했을 때 GetLastError() 에러값이 온 반면, 9x 계열은 그렇지 않은 경우가 많았다. 그 에러값은 32비트 코드 계층에서 설정되는 값이기 때문이다.

과거 16비트 윈도우(Win32s도 당연히 포함)에서는 어떤 GDI 오브젝트 자체와 그 오브젝트가 따로 동적으로 할당하는 메모리의 양이 모두 GDI 힙 64KB 내부에 매여 있었다면,
9x는 일단 할당 가능한 오브젝트의 개수는 64KB의 제약을 받으나 각 오브젝트가 추가로 할당하는 메모리는 ‘별도의 제약이 없는 32비트 범위’인 식으로 제한 조건이 완화된 경우가 많았다. 가령, 복잡한 path나 region 같은 경우 추가 메모리 사용량이 만만찮으리라 예상 가능하다.

제약이 완화되기는 했으나 그래도 9x는 공포의 ‘리소스 제한’이 여전했던 것이다. 리소스 퍼센티지를 아직 기억하시는 분 계시려나?
NT는 역시 애초부터 그런 개념이 없었다. 모든 게 자유로운 32비트 공간이고 지금은 64비트로 자연스럽게 확장되어 있기까지 하다. ^^;;

Posted by 사무엘

2010/05/07 07:45 2010/05/07 07:45
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/261

Trackback URL : http://moogi.new21.org/tc/trackback/261

Comments List

  1. 김 기윤 2010/05/07 21:30 # M/D Reply Permalink

    메모리 주소... 라 해도 그다지 깊게 생각한 적이 없었으니 처음 보는 내용이 좀 많군요 (^^;;)

    그냥 포인터 변수에 저장되는 것이 메모리의 주소이다.. 정도..

    1. 사무엘 2010/05/07 22:29 # M/D Permalink

      시스템 쪽도 파면 팔수록 재미있습니다.
      문제는.. 리눅스나 맥 같은 OS도 내가 윈도우를 아는 것처럼 알려면 얼마나 삽질을 더 해야 할지.. =_=;;;

  2. 정 용태 2010/05/07 21:36 # M/D Reply Permalink

    끔찍한 리소스 제한...;; 글자크기가 커져버리고 파란 화면을 뿜어내죠 ^^;; 그래서 항상 윈도우98의 리소스 모니터를 틀어놓고 작업했었습니다.. win32s를 사용했던 한글3.0b와 한글96은 어떤의미로든 참 대단했던것 같습니다 ^^

    1. 사무엘 2010/05/07 22:33 # M/D Permalink

      정말 악명높은 흑역사입니다.
      유니코드 지원 안 하는 건 그렇다 쳐도 리소스는.. 램이 아무리 많아도 해결이 안 되는 문제이다 보니 너무 치명적인 제한이었죠.

      Win32s는 지금 생각하면 정말 장난감 정도밖에 안 되는 열악한 환경인데, 옛날엔 그 불안정한 환경에서 무려 상업용 소프트웨어를 개발해 냈다는 게 신기할 따름입니다.
      아래아한글 3.0b와 96은 윈3.1+Win32s에서는 실행되기 전에 자체 메모리 서버도 올려야 했답니다. (95에서 돌릴 때는 필요하지 않음) 그리고 3.0b 말고 최초 3.0은 윈도우 3.1+Win32s에서는 돌아가는데 정작 윈도우 95/NT에서는 실행되지 않은 병크까지...;;;
      아래아한글도 큰 breaking change를 겪은 그때와 워디안 시절 때는 가루가 되도록 까인 적이 있었습니다. ^^;;

Leave a comment
[로그인][오픈아이디란?]

멀티태스킹 운영체제에는 한 주소 공간에 여러 프로그램들이 동시에 실행될 수 있다. 그렇기 때문에 그런 환경에서 동작하는 프로그램이라면 자기가 메모리의 어느 위치에 적재되는지를 신경써야 하며, 임의의 위치에 올라가더라도 잘 실행될 준비가 되어 있어야 한다.

과거 도스 시절에는 EXE말고 COM이라는 실행 파일이 있었는데, 이것은 최소한의 헤더 같은 것도 없고 코드와 데이터가 다 16비트 공간 안에 막혀 있으며(과거 메모리 모델로 치면 제일 작은 tiny와 동일), 메모리 주소도 고정 붙박이식이어서 오늘날의 컴퓨터 환경과는 도저히 어울릴 수 없는 과거 유물이 되어 있다.

윈도우 운영체제의 실행 파일이 사용하는 PE 포맷은 position dependent code 방식이다. 즉, preferred base라는 개념이 존재하여 자기는 32비트 주소 공간에서 어디에 적재되는 게 이상적인 경우라고 이미 가정하고 만들어져 있다는 뜻이다. 어떤 EXE나 DLL이 거기에 바로 적재가 가능하다면 가장 빠르고 좋지만, 만약 이 선호하는 주소에다 적재가 못 된다면 별도의 재배치 작업이 필요하다. 즉, 마치 퀵 정렬처럼 잘 될 때와 못 될 때의 성능 편차가 크며 일종의 모험이 동반된다는 뜻이다.

이는 유닉스의 shared library와는 다른 디자인이다. 그쪽은 이렇다할 preferred base 주소가 없으며, 코드 자체가 어느 메모리 주소에 적재되든 동일한 성능으로.. 하지만 딱히 최적의 성능을 발휘하지는 않는 구도로 동작한다. 일종의 힙 정렬이나 병합 정렬처럼 동작한다는 뜻.

윈도우 PE 포맷에는 실제로 실행되는 기계어 코드인 code 섹션도 있고 data라든가 리소스(rsrc)와 더불어 재배치 정보를 나타내는 섹션(reloc)도 있다. preferred base에서 동작하지 못할 때, 코드의 어느 부분을 쫙 수정해 주면 preferred base가 아닌 다른 지점을 기준으로 이 프로그램이 잘 돌아갈 수 있는지를 따로 기록해 놓은 것이다. 사실 이런 개념의 재배치 정보는 도스 EXE나 16비트 윈도우 EXE에도 있긴 했다.

그런데 32비트 윈도우 EXE만은(물론 64비트도 포함) 원칙상 이런 재배치 정보가 필요하지 않게 됐다. 32비트 환경부터는 모든 EXE들이 나만의 독립된 주소 공간을 가지기 때문에, preferred base가 무엇이든지에 무관하게 EXE는 무조건 내가 원하는 위치에 가장 먼저 적재되는 게 보장되기 때문이다.
그래서 통상 EXE들은 재배치 정보를 넣지 않는다. 필요가 없기 때문에, 넣지 않는 게 파일 크기를 줄이는 데도 도움이 되기 때문이다.

그럼에도 불구하고 재배치 정보가 필요한 경우는 다음과 같다.

1. EXE가 아닌 DLL은 반드시 필요하다. DLL은 다른 EXE의 밑에 붙어서 동작한다는 특성상 자신만의 주소 공간을 갖고 있지 않다. 나의 preferred base에 EXE라든가 다른 DLL이 이미 선점되어 있다면 응당 재배치가 필요하다. DLL은 그런 상황을 언제든지 대비해야 한다.

2. Win32s에서 돌아가는 32비트 프로그램이라면 EXE라도 재배치 정보가 반드시 있어야 한다. Win32s는 과거 윈도우 3.1에서 일부 32비트 프로그램을 구동하기 위해 제공되었던 일종의 운영체제 익스텐더로, 32비트 프로그램을 실행만 해 줄 뿐, 16비트 윈도우 3.1이 지니고 있던 시스템적인 한계는 그대로 답습하고 있다.
멀티스레딩을 지원하지 않으며 32비트까지 포함해 모든 EXE가 독립이 아니라 단일 주소 공간을 공유한다!
프로그램을 실행할 때마다 EXE의 핸들이 제각각인 값이 들어오며, 로딩도 preferred base에 정확하게 절대로 되지 않는다. 여기에 대해서는 추후 실험해 볼 예정.
실제로 테스트를 해 보면 핸들이 0x1xxx 이렇게 아주 작은 값으로 들어온다는 게 매우 흥미롭다. 윈도우 NT에서는 그렇게 낮은 주소는 아예 무조건 에러로 간주하는 반면, Win32s에는 그게 여전히 쓰인다는 소리이다. 포인터가 아니라 진짜로 다른 번호에 가깝다.

3. 비주얼 C++ 2008에서 추가된 '시작 주소 랜덤화' 기능을 사용하려면 재배치 정보가 필요하다.
보안을 위해 성능을 희생하듯, 윈도우 비스타부터는 PE 실행 파일도 일종의 position independent (과거의 dependent가 아닌) code처럼 써먹으려는 것 같다.
이 방식으로 빌드된 EXE는 운영체제가 일부러 EXE의 preferred base와는 다른 임의의 위치에다가 로딩을 해 준다. 즉, 이 EXE의 특정 지점의 코드나 데이터를 딱 맞춰 수정하는 프로그램이 제대로 동작하지 않게 위해서이다. (스타크로 치면 맵핵 같은 프로그램)

Posted by 사무엘

2010/05/04 08:36 2010/05/04 08:36
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/258

Trackback URL : http://moogi.new21.org/tc/trackback/258

Leave a comment
[로그인][오픈아이디란?]

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

2010/04/27 12:51 2010/04/27 12:51
,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/254

Trackback URL : http://moogi.new21.org/tc/trackback/254

Comments List

  1. 땅콩맨 2010/04/27 14:44 # M/D Reply Permalink

    말씀하신대로
    버그중 대부분은 서비스팩을 깔면 해결되는게 많은데
    전 왜이리 서비스팩을 설치하는게 귀찮던지...

    버그(벌레)에 한번 깔려봐야 무서운맛을 알텐데... ㅎㅎ

    귀차니즘일까요? ㅋㅋ

  2. 정 용태 2010/04/27 15:27 # M/D Reply Permalink

    엑스피 버그 No.3은 엄밀히 말하면 바이러스및 웜입니다. Sasser.. 제가 컴퓨터 조립해주었던 모든 집에서 컴이 이상하다는 전화가 와서 전부다 들려서 윈도 업데이트 및 백신 설치를 해야했죠.. 이거랑 MSSQL2000 관련 바이러스 때문에 엄청 고생했던 기억이 납니다. 그래서 랜선 빼고 윈도우 깔아야 된다는 이야기가 나왔던 시절입니다 ^^

  3. 정 용태 2010/04/27 15:30 # M/D Reply Permalink

    아.. 그리고 마우스 흔적이 남는 trail기능이 없으면 구형 노트북(윈도우 95및 펜티엄 133시절)의 올드LCD패널은 반응 속도가 너무 느려서 마우스가 보이지 않고 trail기능을 켜야 마우스의 움직임이 화면에 보입니다 ^^ 그리고 제가 명예역장으로 있는 횡천역에 열차안내장치 장착하였습니다 ~ 구경하러 오세요 http://blog.naver.com/kge999k

    1. 사무엘 2010/04/27 17:10 # M/D Permalink

      자체 버그는 아니고 웜 때문이라는 거군요. 뭐 버그나 취약점이나 거기서 거기지만.. ^^
      2002~2004년 이 때가 MS가 자사 소프트웨어에서 이스터 에그도 다 없애 버리고, C 라이브러리 자체까지 고쳐 가면서 오로지 프로그램 보안 강화에 총력을 기울였던 때라는 생각이 듭니다.
      그리고 사진은 잘 봤어요. 와~ 황 성덕(말짱황)님, 영동선 511 님하고 직접 아는 사이이신가 보군요! 대단하십니다. (저는 여러 블로그 돌아다니면서 그냥 이름만 들어서 앎)

  4. 김 기윤 2010/04/27 16:04 # M/D Reply Permalink

    마우스 자취 기능 오랜만에 들어보네요 -_-;

    옛날에는 간지나 보인다(..)는 이유로 항상 켜고 다녔었는데

    요즈음에는 걸리적거려서(..) 전혀 안쓰는 ㄷㄷ;

  5. 사무엘 2010/04/27 17:09 # M/D Reply Permalink

    땅콩맨: 그렇다고 해서 무서운 맛을 직접 체험해 볼 필요까지는.. =_=;;
    제가 예전 글에도 썼지만, 그런 컴터 보안 쪽으로 진짜 사용자에게 경각심을 일깨우는 실험 결과를 보여주는 TV 프로 같은 게 좀 있었으면 좋겠습니다.

    김 기윤: 네, 자취는 요즘은 별로 필요 없는 기능 같습니다. 잠깐 멋있어서 켜다가 금세 꺼 버리죠.

Leave a comment
[로그인][오픈아이디란?]
윈도우 운영체제가 인식하는 실행 파일 포맷인 PE(portable executable)의 헤더를 보면,
이 EXE/DLL이 실행되는 플랫폼(x86, x64, IA64 등등)이라든가, 이 실행 파일의 특성을 나타내는 플래그 등 여러 정보가 존재한다.
그런데 그 플래그 중에는 'Large address aware' 여부를 나타내는 플래그가 있다.
이건 무엇을 뜻하며, 왜 만들어진 것일까?

윈도우 NT는 도스의 잔재 없이 처음부터 순수 32비트로 개발된 운영체제이다.
32비트 공간에서는 최대 2^32 = 4GB 크기의 가상 메모리를 사용할 수 있는데, MS는 전통적으로 하위 2GB는 응용 프로그램이, 상위 2GB는 커널이 사용하는 구도로 운영체제를 설계했다.

그때는 램은커녕 하드디스크 용량도 4GB보다 훨씬 적던 시절. 그러니 그때 32비트는 가히 무한대에 가까운 공간이었으며, 메모리 분배를 어떻게 한다고 해도 이상할 게 없었다.
응용 프로그램은 언제나 하위 2GB만을 사용하다는 게 무슨 뜻일까?
포인터에서 32비트 크기가 다 쓰이는 게 아니라, 최상위 1비트는 절대로 1이 될 일이 없다는 말이다.

그래서 일부 잔머리 잘 굴리는 프로그래머들은 포인터에다가도 자신만의 1비트짜리 boolean 정보를 최상위 비트에다 얹고, 포인터를 쓸 일이 있으면 그 값을 잠시 제거한 후 사용했다고 한다. 흠좀무.

그런데 세상이 변해서 이제 램이 기가바이트급 스케일이 되었고, 32비트 공간만으로는 부족한 시대가 왔다. 본격적으로 64비트 시대가 도래하기 전부터 데이터베이스처럼 아주 memory-intensive한 프로그램을 돌리던 업계에서는, 유저와 커널을 2:2로 가르지 말고 3:1로 갈라서 응용 프로그램에다가 메모리를 좀더 많이 얹어 달라고 MS에다 끊임없이 요구했다. 그래서 MS는 '물리 주소 확장' 모드라는 걸 만들어 줬다.

사실, 커널도 메모리, 좀더 정확히 말하면 주소 공간이 의외로 많이 필요하다. 2:2도 오히려 부족한 감이 있다. 커널 코드를 얹고 각종 커널 오브젝트를 관리하는 메모리만 필요한 게 아니기 때문이다. 가상 메모리라는 시스템은 그 개념상 메모리를 관리하기 위한 메모리도 요구하는 법. 그와 관련되어 방대한 공간이 필요하며, 디바이스 드라이버를 얹고 돌리기 위한 메모리 등등도 따지면 결코 만만한 수준이 아니다.

3:1로 가르면 응용 프로그램이야 사용 가능한 메모리가 좀더 늘며, 종전에는 응용 프로그램이 한번에 약 1GB 남짓밖에 매핑을 못 하는 memory mapped file도 훨씬 더 큰 크기까지 확장할 수 있다. 하지만 만들 수 있는 프로세스/스레드 수가 감소하며 네트웍이라든가 운영체제의 전반적인 기능상의 한계가 매우 커지고, 운영체제가 이론적으로 관리 가능한 총 물리 메모리의 양도 줄어든다! 이 tradeoff를 반드시 잊지 말아야 한다.

그런데 문제는...
그렇게 3:1로 응용 프로그램의 메모리 주소를 확장하면...
드디어 최상위 비트가 1인 포인터 값이 응용 프로그램으로 오는 게 가능해진다는 것.
그렇다면, 예전에 놀고 있던 최상위 비트를 다른 용도로 활용하던 프로그램을 이런 확장 환경에서 돌리면.....;;; 더 이상의 자세한 설명은 생략한다.

그래서 호환성을 목숨처럼 1순위로 강조하는 MS는, 아무 프로그램이나 일방적으로 넓어진 포인터를 주는 게 아니라, 넓어진 포인터를 줘도 안전하다고 플래그가 따로 지정되어 있는 프로그램에 대해서만 제 기능을 다하도록 하는 정책을 선택했다. 그것이 바로 large address awareness이다. 이 플래그가 없이 빌드된 프로그램은 여전히 메모리를 2GB씩밖에 못 쓴다. 마치 윈도우 XP 이후에도, 별도의 매니페스트를 내장하고 있지 않은 옛날 프로그램들은 비주얼 스타일 테마가 적용되지 않는 것과 같은 맥락으로 말이다.

단, 이건 EXE에 한해서이다. DLL은 그런 선택의 권리가 없다. 확장 주소가 지원되는 EXE에 붙을 수도 있고 지원 안 되는 EXE에 붙을 수도 있으며, 어느 때건 동작을 잘 해야 한다. 따라서 DLL은 반드시 확장 주소를 지원하도록 작성되어야 한다.

본격적으로 64비트 환경이 되면서 확장 주소의 진정한 의미가 드러났다. 이제는 상위 1비트 정도가 아니라 아예 테라바이트급 메모리 주소에도 접근 가능해야 하며, 64비트 프로그램은 '확장 주소 지원' 플래그가 반드시 있어야 한다. 이 플래그가 없으면, 비록 x64 내지 IA64 아키텍처용으로 만들어진 64비트 프로그램이라 할지라도 포인터의 주소로는 여전히 무려 2GB 이내의 값만 들어온다. -_-
포인터 크기를 4바이트 int 크기로 하드코딩하고 제작된 무개념 프로그램을 최대한 쉽게 64비트로 포팅할 수 있게 배려한 것이다. 물론 이 역시 EXE에 한해서이지만 말이다.

large address aware 옵션은 비주얼 C++의 x86 플랫폼에서는 호환성 차원에서 디폴트로 꺼져 있다. 즉, 사용자가 별도로 옵션을 켜지 않으면, 2GB까지만 인식하는 프로그램을 만든다.
하지만 x64/IA64 플랫폼에서는 사용자가 별도로 이 옵션을 끄지 않으면 디폴트로 켜져 있으며, 코드가 2GB 정도가 아니라 4GB 이상의 공간도 안전하게 인식하는 것으로 간주한다. 둘이 묘한 차이가 있다는 것을 기억하자.

물론 굳이 램이 4GB가 아니더라도 64비트는 CPU가 한번에 정보를 처리하는 단위 자체가 더 크다는 점 하나만으로 32비트보다 대용량 데이터를 처리하는 성능이 더 뛰어나다. double 실수형을 하나 스택에 얹을 때만 해도 32비트에서는 CPU 명령을 최소 둘 이상 써야 하는데 64비트에서는 한 번만에 끝난다는 소리이지 않은가. 그렇기 때문에 램 용량이 32비트 크기를 초과하기 전부터도 64비트 프로세서가 개발되어 일부 제한된 영역에서 쓰이기도 했던 것이다.

잘 알다시피 64비트 윈도우는 과거 16-32비트가 그랬던 것처럼 그 정도로 지저분한 호환 계층은 제공하지 않으며, 한 프로세스 공간에 64-32비트 코드가 공존하는 것을 허용하지 않는다. 그래도 윈도우 핸들값은 여전히 32비트 범위 안에만 존재하며 32와 64비트가 값을 그대로 공유 가능하다는 게 신기하다. 하긴, 윈도우 9x에서는 윈도우 핸들값이 아예 16비트 범위에 있었지만 말이다. ^^ 썽킹이라는 말도 참 오랜만에 다시 듣는다.

Posted by 사무엘

2010/04/12 09:12 2010/04/12 09:12
, ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/242

Trackback URL : http://moogi.new21.org/tc/trackback/242

Comments List

  1. 땅콩맨 2010/04/12 09:32 # M/D Reply Permalink

    실행파일의 새로운 면모를 다시금 확인하게 되었네요. ^^
    좋은 글 감사합니다.

  2. 김기윤 2010/04/12 09:34 # M/D Reply Permalink

    이쪽 이야기는 언제나 재밌군요 ^-^

    앞으로도 사용할 용량은 계속 커질테니 언젠가는 128비트 운영체제가 나올지도 모를 일이죠 (..)

    뭐, 물론 7~15년 정도 뒤의 일이겠지만..

  3. 사무엘 2010/04/13 09:43 # M/D Reply Permalink

    윈도우 말고 다른 운영체제들도 발전사라든가 과거의 흑역사, API 구조 같은 걸 공부하면 재미있는 게 많을 텐데 하는 궁금증도 들더군요.
    그나저나 과연 64비트 공간마저 부족해질 날은 지구가 멸망할 때까지 과연 오긴 할까 궁금..;;
    64비트 포인터는 상위 1비트 정도가 아니라 최소 바이트나 워드 단위로 아직 쓰이지 않고 있기 때문에, 그 공간을 갖고 잔머리 굴리는 프로그래머도 있을 겁니다. ^^

    1. 아라크넹 2010/04/16 17:14 # M/D Permalink

      리눅스의 경우 2.6 전까지 운영체제 차원에서 쓰레드를 지원하지 않았던 흑역사가 있습니다. 대신 clone 시스템 콜을 써서 주소 공간을 공유하는 경량 프로세스로 쓰레드가 구현되었죠.

  4. 주의사신 2010/04/16 20:09 # M/D Reply Permalink

    windows에서 호환성과 관련하여 하나 재미있는 일화를 소개하자면은요(뭔가 얘기하면 다 알고 계셔서 가끔은 얘기하기 겁난다는...).

    dos에서 windows 3.1로 넘어갈 적에 MS에서 호환성 검사를 하느라고, 구할 수 있는 프로그램은 다 구해서 돌려보는데, 심시티는 매번 죽더랍니다.

    그래서 심시티를 역어셈블링해서 보니까, dos에서는 메모리에 직접 접근이 가능하다는 사실을 이용해서, 메모리를 잡고 사용하고 해제한 후에, 바로 그 주소를 다시 할당해서 사용하는 방식으로 구현이 되어 있음을 알아냈다고 합니다.

    그래서 windows 3.1에서 심시티가 돌아갈 때에는 그 방식을 에뮬레이팅 하는 방식으로 해결해 돌아가게 해 주었다고 합니다.

    아마 이런 노력이 있었기에 지금의 윈도우 제국이 있는듯합니다.

    1. 아라크넹 2010/04/17 14:54 # M/D Permalink

      생각보다 그러는 케이스가 꽤 많습니다. 레지스트리 편집기에서 "Compat"가 들어가는 키 찾아 보면 꽤 있죠. 이를테면 IE, DirectX, Windows 모두 호환성을 위한 별도 리스트가 몇 개씩 있습니다.

  5. 사무엘 2010/04/16 23:55 # M/D Reply Permalink

    아라크넹: 그쪽은 원래부터 워낙 스레드보다는 프로세스 찍어내길 좋아했던 곳이니까...

    주의사신: 저도 옛날에 비슷한 얘기를 들었던 것 같습니다. MS는 충분히 그런 짓 하고도 남을 곳입니다.
    한글 입력기 개발자로서 저의 경우를 첨언하죠. 과거 윈도우에 TSF 시스템을 구현한 DLL 내부를 들여다보면 netscape는 물론이고 무려 webeditor.exe (나모 웹에디터!!) 같은 문자열도 들어있습니다. TSF의 전신이자 MS의 흑역사라 할 수 있는 글로벌 IME를 지원하던 극소수의 프로그램을 따로 배려한 조치였던 것 같습니다. EXE 파일 이름을 식별해서 말이에요.

  6. 김 민규 2010/04/17 20:01 # M/D Reply Permalink

    저는 이번 학기에 컴퓨터 구조라는 과목을 배웁니다.
    레지스터, 어셈블리, 등등...
    안배웠으면 이 글이 무슨 말 하는지 몰랐겠죠. 아는 만큼만 보이니까...

    재밌네요. 그렇게 잔머리를 굴려서 한 비트씩을 자기꺼로 사용하고..
    굳이 그렇게까지 안 해도 될 것 같은데..ㅋ 나름의 사정이 있었을까요.

    1. 사무엘 2010/04/18 23:13 # M/D Permalink

      공돌이 암흑의 세계로 한발 한발 깊이 들어오시는군요. ^^;;
      다른 언어들보다도 특히 C/C++은 컴퓨터 구조를 잘 알아야 제대로 써먹을 수 있는 언어입니다. 뉴비 프로그래머에게 포인터가 어려운 존재인 이유도 딴 게 아니라 컴퓨터 자체의 내부 동작 방식을 몰라서이죠.

      "화장실에서 최후의 한 방울까지 철저히 관리하라"도 아니고 저 때는 메모리가 부족해서 "최후의 한 비트도 낭비하지 말라" 였던 것 같습니다. ㅋㅋ

Leave a comment
[로그인][오픈아이디란?]

블로그 이미지

철도를 사랑하고 한글에 관심이 많고 하나님의 말씀을 믿는 프로그래머의 개인 공간

- 사무엘

Archives

Authors

  1. 사무엘

Recent Trackbacks

Calendar

«   2010/08   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Site Stats

Total hits:
14649
Today:
16
Yesterday:
65