일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
세상 사람들이 여섯 명만 거치면 모두 아는 사람이라는 이론이 있습니다. 대부분들 좁은 세상이라는 말에는 수긍하면서도 정말 여섯 명만 거치면 지구상에 있는 어떤 사람과도 연결될 수 있을까라는 의문을 가지게됩니다. <링크>라는 책을 보면 이것과 관련된 한 가지 재미있는 연구가 나옵니다. 바로 에르되스 넘버입니다. 에르되스는 유명한 수학자입니다. 에르되스 넘버란 에르되스를 기준으로한 네트워크 경로 상의 경로의 길이를 말합니다. 에르되스와 같이 논문을 쓴 수학자는 1의 에르되스 넘버를, 에르되스와 같이 논문을 쓴 사람과 같이 논문을 쓴 사람에게 2란 에르되스 넘버를 부여하는 형태입니다. 아래 그림에서 A, B, C는 1을, K, Y는 2란 값을 가지게 됩니다. 즉, 이 에르되스 넘버가 작을수록 에르되스와 네트워크 상의 거리가 가깝다고 할 수 있습니다. 그런데 신기한 사실은 대부분의 수학자가 에르되스 넘버 2에서 5사이의 값을 가지고 있다는 겁니다. 앞서 말했던 좁은 세상 이론과 비슷한 결과를 나타내는 셈이죠.![]() 오늘 서브버전에 관한 내용을 검색하고 있었습니다. 그동안 개인적으로만 써오다가 회사적으로 쓸 일이 있을것도 같고 해서 관련 자료를 찾는 중이었죠. 역시나 구글님과 상담을 했고, 좋은 ppt 자료를 받을 수 있었습니다. 단국대학교에 있는 박선응님께서 만든 자료인것 같은데 서브버전을 모르는 사람이 봐도 한 눈에 이해가 될 수 있을 만큼 자세한 자료였습니다. 보면서 음. 이런 자료를 공짜로 볼 수 있다니 영광이군 따위의 생각을 하고 있었습니다. 분량은 그닥 많지 않아서 마지막 페이지까지 읽게 되었고, 마지막은 참고 자료 항목으로 구성되어 있더군요. 아래는 해당 문서에서 발췌한 참고 자료 부분입니다. Subversion 사용 HowTo – pyrasis.com참고 자료를 보다가 풉하고 웃었습니다. <링크>에 나오는 좁은 세상 이야기가 떠올랐기 때문입니다. 첫 번째 참고자료 저자인 pyrasis님은 전에 같은 회사에 근무했던 동료이고, 두 번째 있는 최규철군은 학교 동기이기 때문이죠. 사실 pyrasis님은 서브버전 자료를 많이 작성해서 kldp 쪽에서는 꽤나 유명하기 때문에 그렇다고 생각했는데 동기 녀석은 좀 쌩뚱맞았습니다. 그래서 더 반가웠는지도 모르겠네요. 규철사마를 처음 만난 때가 3학년 하드웨어 실험 때였습니다. 그 때 같은 조를 하게되면서 알게 되었죠. 한 조에 세 명이었는데, 규철이 입장에서 우리 조는 정말 최악이었습니다. 규철이 말고는 둘 다 고문관이었거든요. ㅋㅋ 보드 디자인하고 납땜해서 그것을 만드는 것이 주된 실험이었는데, 그 모든 과정을 규철이 혼자서 다했죠. 전 옆에서 가끔 음료수 사다 날르는 역할만 했던것 같습니다. 앞담화가 튀어나올만큼 힘든 실험인데도 그런 내색하나 하지 않고 혼자 열심히 한 녀석이 대단하기도 하고, 고맙기도 하고 그랬습니다. 웃긴 사실은 조별 실험이라 세 녀석 모두 같은 학점을 받았다는 것이죠. ㅋㅋㅋ 세상 참 좁은것 같습니다. 착하게 살아야할 한 가지 이유가 되겠죠? ㅎㅎ |
재즈벌레님께서 완전히 한글화하신 버전을 아래 링크에서 다운받으실 수 있습니다. http://jazzbug.tistory.com/130 ![]() 어제 올렸던 노트패드에 툴바가 표시된지 않는 문제가 있었습니다. 노트패드 소스는 제가 수정을 전혀 안했던터라 -- Scintilla 라이브러리 코드만 변경했죠 -- 원인이 뭘까 고민을 잠깐 해봤습니다. 그러다 문득 저렇게 이뿌게 표시되야할 프로그램이 투박하게 표시되는 것에서 매니페스트(manifest) 설정이 잘못되었음을 눈치챘습니다. 하나는 금방 찾은 셈이었습니다. 프로젝트 설정에서 매니페스트를 포함해서 링크하도록 고치고 원래있던 매니페스트 리소스를 제거했습니다. 이젠 되겠지 했는데 여전히 툴바는 표시되지 않았습니다. 그래서 디버깅을 했습니다. [CPP]SendMessage(hwndReBar,RB_INSERTBAND,(WPARAM)-1,(LPARAM)&rbBand);[/CPP] 위 부분에서 문제가 있음을 찾을 수 있었습니다. 위 결과가 0이면 실패한 것인데 계속 0을 리턴하더군요. 답답한 것은 GetLastError도 없다는 겁니다. 단지 실패한 거죠. 이런 경우에는 보통 rbBand 구조체를 잘못 설정한 경우가 많습니다. 그래서 위쪽에 rbBand를 설정하는 부분을 꼼꼼히 살펴봤습니다. 이상하게 없더군요. 그래서 WTL의 밴드 삽입 코드를 복사해서 그 놈을 호출하도록 변경했습니다. 그래도 여전히 실패합니다. 구조체를 모두 다 채워요 여전히 툴바는 표시되지 않았습니다. 이쯤되면 막장이죠. ㅠㅠ 가장 최고의 방법은 되는 것과 비교하는 거죠. 어제 정수님께서 올려주신 버전을 OllyDbg로 꺼냈습니다. 리바 메시지 핸들러에 RB_INSERTBAND가 오는 경우에 브포가 걸리도록 설정하고 스택을 뒤졌습니다. 넘어온 구조체는 다음과 같더군요. ![]() 50이라고 선택된 곳 부터가 구조체 시작 지점입니다. RBBANDINFO의 첫 번째 필드는 cbSize로 구조체 크기입니다. 0x50바이트라는 거죠. 이번에는 제가 어제 컴파일한 바이너리를 넣고 확인했습니다. 저기에 0x64가 들어있습니다. 이제 먼가 잘못됐다는 것을 알았죠. 구조체 정의 부분으로 갔습니다. [CPP]typedef struct tagREBARBANDINFOA { UINT cbSize; UINT fMask; UINT fStyle; COLORREF clrFore; COLORREF clrBack; LPSTR lpText; UINT cch; int iImage; HWND hwndChild; UINT cxMinChild; UINT cyMinChild; UINT cx; HBITMAP hbmBack; UINT wID; #if (_WIN32_IE >= 0x0400) UINT cyChild; UINT cyMaxChild; UINT cyIntegral; UINT cxIdeal; LPARAM lParam; UINT cxHeader; #endif #if (_WIN32_WINNT >= 0x0600) RECT rcChevronLocation; // the rect is in client co-ord wrt hwndChild UINT uChevronState; // STATE_SYSTEM_* #endif } REBARBANDINFOA, *LPREBARBANDINFOA;[/CPP] 제가 사용하는 SDK는 비스타용으로 최신 버전입니다. 0x600이상이면 이라고 정의하는 부분이 보이시죠. 그 만큼이 추가된 20바이트 였습니다. Notepad2 프로젝트에서 _WIN32_WINNT를 정의하지 않아서 자동으로 0x600으로 정의됐고, 그로인해 구조체 크기가 달라졌던 겁니다. 당연히 XP에서는 동작할리 없겠죠. 간만에 제대로 말렸네요. ㅋㅋㅋ 아래 파일은 수정된 버전입니다. |
그라바타 기능을 업데이트 하면서 댓글을 많이 쓰신분들은 이미지를 올려드리고 싶은데 그걸 찾기가 참 난감하더군요. 그래서 플러그인을 하나 만들어 봤습니다. 이름하여 베스트 커멘터 플러그인입니다. ㅋㅋㅋ 댓글 개수로 실시간 순위가 집계됩니다. 지금은 용현님께서 일등이네요. *^^* [USER_LIST] |
![]() http://www.flos-freeware.ch/notepad2.html 여기에 올려진 notepad2 2.0.18버전을 패치한 것 입니다. 별도의 한글화는 하지 않았습니다. 전 개인적으로 sourceforge 버전이 더 이쁜것 같아요. ㅎㅎ 즐노트패드 하세요. *^^* |
그라바타 기능을 많은 분들께서 쓰실 줄 알았는데 거의 쓰지 않더군요. 그래서 과감하게 제거해 버렸습니다. 맨날 휑한 이미지만 보고 있기도 좀 그렇더군요. 물론 그라바타 홈페이지 접속 불량과 느린 속도도 제거를 결심하는데 한 몫 했습니다. 그라바타 플러그인을 조금 고쳐서 제 홈페이지에 올려진 이미지에서 불러오도록 수정했습니다. 그래서 이제는 자신의 이름으로 댓글을 남기면 아래 그림처럼 자동으로 이미지가 표시됩니다. 물론 사전에 등록된 분들에 한해서 동작합니다. ㅋㅋ ![]() 제가 임의로 몇 분의 이미지를 올려 두었습니다. 예전 홈페이지 운영할 때 사용했던 아바타 팩에서 임의로 그림을 선택해서 올려두었습니다. 바꾸고 싶거나 자신의 아바타를 등록하고 싶으신 분들은 codewiz 골뱅이 gmail.com으로 메일 주세요. *^^* 물론 직접 등록하지 않으셔도 자주 댓글 남겨주시면 임의로 제가 등록해 드리겠습니다. 블로그 운영하는 입장에서 그림 나오는 칸이 휑하니 그것도 쫌 그렇더군요 ㅋㅋㅋ 일원짜리 팁: 이번에 수정하면 재미난 HTML 기능을 하나 배웠습니다. 이미지를 옆으로 배치해두니 글을 조금 남긴 경우는 이미지가 커서 밑에 글이랑 중복이 되더군요. 이미지를 출력하고 다음 줄에 글을 쓰도록 하니 또 이미지 오른쪽이 휑하고 그랬습니다. 한참을 margin, padding, border 등과 시름하다가 우연찮게 발견한 기능으로 아주 쉽게 해결했습니다. <br clear=left>가 그것이죠. 이것을 사용하면 이미지 옆의 여백이 있어도 바로 이미지 밑으로 이동시켜서 출력을 시작합니다. IE로 들어가보니 레이아웃이 또 이상하게 되더군요. 아래 페이지를 참고하시면 완벽한 해결책을 찾을 수 있습니다. http://www.greywyvern.com/code/min-height-hack |
예전에 사운드카드가 귀한 시절에는 PC 스피커를 통해서 음악을 연주하곤 했다. 그 단순한 기계음 마저도 정겹게 느껴지던 시절이었다. 하지만 요즘은 사운드카드가 달리지 않은 컴퓨터도 없고, PC 스피커를 통해서 음악을 연주하는 프로그램은 더더욱 없다. PC 스피커가 사용되는 유일한 이유는 사용자의 이목을 끌기 위한 아래와 같은 용도 뿐이다. [CPP]printf("경고: 집중해주세요!!!\a");[/CPP] 마지막에 있는 \a가 비프음을 출력하는 역할을 한다. 요 근래에 몇몇 프로그램을 사용하면서 몇 차례 이 잊고 지냈던 비프음을 들을 기회가 있었다. ASUS 노트북 제조사는 이 시스템 스피커를 노트북 스피커 출력 단자랑 연결을 시켜 두었고, 이어폰을 착용하고 있던 나는 이어폰을 통해서 강도높은 주파수의 찌릿하는 소리를 들을 수 있었다. 한 몇차례 듣다 보니 이건 완전 노이로제가 걸릴지경이다. 아마 심장 약한 사람은 쇼크사를 할 수 있을 정도로 강한 음이다. 특히나 그 음은 시스템의 볼륨과는 전혀 독립적으로 동작하기에 문제가 더 컸다. 나는 그 소리를 더 이상 듣고 싶지 않았다. 처음엔 바이오스에서 조절할 수 있을 거라고 생각했지만 조절되지 않았다. 스피커 볼륨을 조절하는 칸을 0으로 해보았지만 PC 스피커의 볼륨과는 상관이 없었다. 장치 관리자에서 시스템 스피커를 사용안함으로 만들어보았다. 그러나 이 또한 무용지물이었다. 시스템 스피커를 중지 시켜도 중지되지 않은 시스템 스피커 미칠 지경이었다. ![]() 모르면 찾으라고 인터넷 항해를 시작했다. 여기저기에 PC 스피커 연결 단자를 제거하라는 말 뿐이었다. 노트북을 열어서 그 짓을 할 수도 없는 노릇이었다. 그러던 와중에 마지막 댓글에 한 줄기 광명의 빛이 보였다. 장치 관리자에서 보기 메뉴에서 숨김 장치 표시를 선택한 다음 나오는 Beep를 사용안함으로 하면된다는 글이었다. 숨김 장치를 표시하도록 만들면 아래와 갈은 화면이 뜬다. ![]() Beep를 중지시키고 나자 시스템 스피커는 이제 더 이상 미칠듯한 삐- 소리를 내지 않게 되었다. 결론: 장치 관리자에서 숨김 장치 표시에서 나오는 Beep를 사용안함으로 만들면 PC 스피커를 끌 수 있다. ㅋ 다른 방법 이건 PC 스피커 선을 사운드 카드 출력에 연결해둔 노트북에서만 통하는 방법입니다. 볼륨 조절을 열고, 옵션에서 속성 메뉴를 선택합니다. 그럼 아래 화면처럼 속성 창이 나타납니다. 거기에 보시면 PC Beep라는게 있습니다. 체크를 하고 확인을 누릅니다. ![]() 그럼 이제 볼륨 설정에 PC Beep가 나타날 겁니다. 듣고 싶지 않다면 음소거를 낮은 볼륨으로 듣고 싶다면 볼륨을 조절하시면 됩니다. ![]() |
북스 조선의 북스 체험단 이벤트에 당첨되서 "일요일의 마음"이란 책을 받게 되었습니다. 별로 두껍지 않은 책인데 내용은 꽤나 어렵습니다. 특히나 문학적 소양이 없는 제가 읽기엔 더 어려운 것 같습니다. 문학 교수님께서 쓴 책이라 더 그렇겠지요. 저자 소개 부분이 꽤나 인상적이었습니다. 문학평론가 이남호 선생님이 저자인데, 고려대학교 문학 교수가 직업이라고 합니다. 후훗. 그런데 뒷 부분을 보면 이렇게 썼습니다. 총 스무권의 편, 저서를 출간하였는데 세상의 사랑을 받은 책은 없음. 왠지 애틋한 마음이 느껴지지 않나요? 저만 그랬는지도 모르겠습니다. "총 스무개의 프로그램을 만들었으나 세상의 사랑을 받은 프로그램은 없음" 이란 말이 뇌리를 스치더군요. B급 대중문화라는 말을 하기도 하지만 때로는 대중성이 아쉽기도 하죠. 어쩌면 그런게 간절한지도 모르겠습니다. 처음 절반을 읽을 때 까지의 제 심정은 이건 뭐 진짜 탐미주의자를 넘어서 좀 있어보이고 싶어한다는 느낌이 많이 들었습니다. 한번도 들어보지 못한 음악을, 가보지 못한 도서관, 보지 못했던 그림들, 이해할 수 없는 시들에 시샘이 드는 마음이었죠. 그러나 나머지 절반을 읽으면서 생각이 많이 바뀌었습니다. 후반부에는 더러 제가 아는 영화가 나오기도 했고, 이해할 수 있는 소설도 나왔기 때문입니다. 후반부를 읽으면서 제 마음은 정말 이 글의 저자이신 이남호 선생님께서는 아름다움을 볼 줄 아는 심미안을 가졌구나라는 생각을 많이 하게되었습니다. 길지 않은 분량의 책이지만 퍽이나 멋있는 문장은 많이 있습니다. 그 중에서 하나를 고르라고 한다면 소동파의 아래 시를 소개한 부분을 택하고 싶네요. 흰 비단 그대로 그리지 않음도 뜻이 높더라시가 이해가 가시나요? 사실 전 뒤에 해설을 읽기 까지 시를 완전 이해하지 못했습니다. 특히나 이 연이 무슨 말인지 잘 모르겠더군요. 이남호 선생님의 설명을 들어보도록 합시다. 흰 비단에는 아무것도 그려져 있지 않다. 그렇지만 그 비단은 온갖 꽃과 달과 금대 옥루도 다 숨기고 있다. 다 가지고 있지만, 겉모습은 아무 그림도 그려져 있지 않은 흰 비단일 따름이다. 흰 비단을 명함에 비유해 볼 수도 있다. 시시한 사람일수록 명함에 많은 직함을 적어 다닌다. 높은 사람은 명함이 아주 단순하다. 그보다 더 높은 사람은 아예 명함을 가지고 다닐 필요가 없다.꽤나 공감가지 않나요? 특히나 전 명함 부분에서 감탄했습니다. 그러면서 전 아직은 시시한 사람이라는 생각을 했습니다. 언젠간 아무것도 그리지 않은 흰 비단처럼 되야겠죠. 요즘 저런 생각을 몇 차례 했었던 터라 더 감동적이었는지도 모르겠습니다. 우리는 아름다움에 관해서 많은 이야기들을 하고, 또한 그런 것들을 찾기 위해서 노력하곤 합니다. 그래서 이쁜 여자 배우가 나오는 영화를 보러 가기도 하고, 아름다운 경치가 있는 명산에 가기도 하고, 절경을 이루는 곳을 찾아 해외여행을 떠나기도 합니다. 그리면서 늘 아름다움은 자신의 주변보다는 멀리 찾아 떠나야 있다는 환상에 빠져듭니다. 하지만 제가 이 책의 마지막 장을 덮으면서 느낀 점은 전혀 그렇지 않다는 것이었습니다. 아름다움은 우리 주변에 넘쳐나게 많이 있지만 단지 우리에겐 그것을 볼 수 있는 안목이 없다는 것이죠. 그리고 그 안목은 지식도 지혜도 아닌 관심과 애정에서 나온다는 점이었습니다. 똑같은 삽화를 보더라도 그것에 관심을 가진 사람만이 진정한 가치와 아름다움을 볼 수 있는 법이죠. 아는 만큼만 보인다라는 말도 있고, 자신이 이해할 수 없는 정도의 복잡함은 머리만 아프게 한다는 이야기도 있습니다. 이 책을 읽으면서 다시 한번 그런 생각을 많이 느꼈습니다. 이미 경험했던 영화나 소설 이야기에서는 깊은 공감을 느꼈지만 그렇지 않은 많은 부분에 대해서는 이질감을 더 많이 느꼈기 때문입니다. 책에 소개된 시, 소설, 영화, 그림, 장소들을 경험해 본 다음 다시 "일요일의 마음"을 읽는다면 좀 더 깊이있는 책으로 다가올 것 같습니다. 이런 모든 부분을 차치하고서라도 이 책을 높이 평가하고 싶은 단 한 가지 이유는 저자이신 이남호 선생님의 솔직함 이었습니다. 앞서 소개했던 저자 소개 부분이나 에필로그에 나오는 진실함이 읽고 있는 저를 더 기분좋게 만들었던 것 같습니다. 한 가지 아쉬운 점이라면 굳이 양장으로 묶을 필요가 있었을까 하는 점이었습니다. |
아이님 블로그를 보다가 재미난 글을 발견했습니다. 인텔 면접 문제라고 하는데 오래된 건지도 모르겠네요. 본 것 같기도 하고 가물가물 합니다. 각설하고 문제를 살펴보면 이렇습니다. 아래 코드에서 한 글자만 고쳐서 -가 20개가 출력되도록 만드는 것 입니다. [CPP]int i, n=20; for(i =0 ; i < n ; i--) printf("-");[/CPP] 어렵진 않지만 잠시나마 지적 유희를 즐기고 싶으신 분들을 위해서 답은 가려두겠습니다. 한번씩 생각해보세요. *^^* more.. |
이제는 운명이니, 숙명이니, 천명이니 하는 이야기들을 꺼내기에는 참 부담스러운 세상이 되었습니다. 아마도 사람들이 더 이상 신의 존재나 하늘을 무서워 하지 않기 때문이겠죠. 저 또한 그런 사람들 중에 한 명이었습니다. 결정론적 인생관에 굉장히 회의적이었고, 여렸을 적에는 제가 그렇지 않다는 것을 보여주는 한 명이 되기 위해서 노력해야 겠다고 결심하기도 했습니다. 그런데 언젠가 저의 이런 생각에 일침을 놓는 이야기를 들은 적이 있습니다.인생이란 결국 사람과 사람 사이의 관계에 의해서 이루어지고, 이런 관계를 결정짓는 중요한 요소 중에 하나가 성격입니다. 그러한 성격은 오랜 시간에 걸쳐서 형성되는 것이고, 한 번 형성되고 나면 쉬이 바뀌지 않습니다. 사춘기 이후로 성격이 바뀐 적이 있는지 곰곰 생각해 보세요. 이렇게 형성된 성격으로 평생을 살아가기 때문에 결국 그것이 그 사람의 운명이라 할 수 있습니다. 물론 그 사람의 성격상의 단점을 살면서 의지로 바꾼다면 운명도 바뀐다고 할 수 있겠죠.물론 이 이야기는 운명을 결정론적 관점에서 보고 있지는 않습니다. 왜냐하면 자신의 의지로 성격을 바꾼다면 운명도 바뀐다는 뜻을 내비치고 있기 때문이죠. 그렇다면 왜 바꿀 수 있는 속성에 운명이란 말을 썼을까요? 아마도 자신의 단점을 똑바로 인식하는 것이나 차후에 그것을 고치는 일 모두 쉽지 않기 때문일 것 입니다. 운명이라고 부를 수 있을 만큼 결정적 요소가 된다는 것이죠. 그 말을 듣고 곰곰 생각해 보았습니다. 사춘기 이후로 내 성격의 결정적 변화가 온 적이 있을까? 내가 의도적으로 고치고 싶었던 성격의 일부를 고쳐본 적이 있는가? 안타깝게도 전무했습니다. 시간이 흐르면서 전 좀 더 주변 일들을 이와 같은 시각에서 바라볼 수 있는 기회를 많이 가지게 되었습니다. 관찰한 결과에 의하면 놀랍게도 구할 정도는 저 말과 일치한다는 결론에 도달했습니다. 주변에 혹시 실력은 별로 없는데 쉽게 쉽게 가는것 같은 사람을 본 적이 있습니까? 아니면 대단한 실력의 소유자임에도 어렵게 어렵게 가는 사람을 본 적이 있습니까? 또는 별로 가진것도 없는데 너도 나도 주변에서 도와주겠다고 발벗고 나서서 도와주는 친구를 가진 사람을 본 적이 있습니까? 그렇다면 다시 한번 그 일들을 천천히 생각해 보세요. 그 이지고잉 내지는 가시밭길을 누가 만든 것인지? 그것이 어디서 온 것인지? 거울 속을 바라보세요. 자신의 얼굴을 보고 냉정하게 생각해 봅시다. 오늘 하루 나는 주변 사람들에게 기쁨을 줬는지 아니면 불행을 줬는지? 생각하는 그 순간의 결과는 중요하지 않습니다. 만족스럽지 않다면 다음부터 고치면 되니까요. 그러면 오늘보다는 더 좋은 내일을, 내일보다는 더 아름다운 모레를 만날 수 있을 겁니다. 그것이 곧 여러분의 운명이 될 것이고, 그것이 곧 성공일 겁니다. 가장 중요한 것은 차가운 이성으로 자신을 똑바로 바라보는 일 입니다. |
![]() WJR 아저씨께서 새로운 버전의 PEView를 릴리즈 했습니다. 메일로 몇 차례 물어보는데 답고 못하고 쌩까고 있었는데 결국 릴리즈 했다는 메일까지 보내주시네요. 세상엔 고마운 사람들이 정말 많은 것 같습니다. WJR 아저씨 만쉐. ㅋ Finally updated at the usual: http://www.magma.ca/~wjr --- 요즘 PE 관련 글을 쓰다보니 제일 많이 쓰는 유틸리티가 PEView가 되었습니다. 그런데 제가 가지고 있는 버전이 0.7이었는데 이놈은 시작할때 라이센스 화면이 뜨고, 닫으면 또 바로 파일 열기 대화상자가 표시됩니다. 한번씩 쓸때는 별로 몰랐는데 불편하더군요. 그래서 최신 버전은 괜찮은가 싶어서 홈페이지 들어가서 0.9 버전을 새로 다운 받았습니다. 역쉬 라이센스 화면이 없어졌더군요. 하지만 여전히 파일 열기 대화상자가 표시되었습니다. 저는 주로 파일을 열때는 드래그를 해서 넣고 필요한 부분만 확인하고 바로 닫는 작업을 합니다. PEView가 CreateFileMapping으로 파일을 열어서 그런지 PEView에 열어두면 파일 변경이 되지 않기 때문이죠. 그래서 Close 메뉴도 상당히 자주 쓰는데 단축키가 없습니다. 버튼도 없구요. 그래서 매번 File에 들어가서 Close를 누르는 불편함을 감수하면서 사용했습니다. 원고쓰다 간만에 삘받아서 고쳐보았습니다. 시작시에 파일 대화상자가 표시되지 않고, Help 오른쪽에 Close 버튼이 있습니다. 이제 드래그해서 집어넣고 클릭 한방으로 파일을 닫을 수 있습니다. 저와 같은 불편함을 겪으셨다면 이 패치가 도움이 될 것 같네요. -- 몇 바이트 고친것도 아니지만 안타깝게도 공유하기는 힘들것 같네요. PEView의 경우 라이센스 문구가 프로그램에 포함되어 있습니다. 라이센스를 살펴보면 상업적인 용도가 아닌 경우에 배포및 복사는 자유롭습니다. 수정에 관한 내용이 없어서 메일로 보내서 물어봤더니 배포는 하지 말라고 하시는군요. 다음 버전에 넣을지 말지 고민을 해보겠다고 하십니다. 저는 그동안 왜 무료 소프트웨어의 수정을 허용 하지 않을까? 굉장히 궁금했는데 이번 기회에 그 이유를 알 수 있었습니다. Wayne J. Radburn 아저씨의 설명에 따르면 너도나도 패치를 제작해서 발표하게되면 그 과정에서 생긴 버그에 대한 내용은 고스란히 자기 메일함으로 날라온다는 것이었습니다. 어느 정도 납득은 가는 내용이죠. 그리고 시작 시에 파일 다이알로그가 뜨는 것이 불편하다고 말한 사람은 제가 처음이라고 하더군요. 제가 굉장히 특이하게 소프트웨어를 사용하나 봅니당. *^^* |
대화에 있어서 하수는 말을 많이 하는 것이고, 중수는 필요한 말만 하는 것이고, 상수는 상대방의 말을 듣는 것이다. 작문에 있어서 하수는 글을 많이 쓰는 것이고, 중수는 핵심만 간단히 쓰는 것이고, 상수는 쓰기전에 남의 글을 읽는 것이다. 개발에 있어서 하수는 코드를 많이 만드는 것이고, 중수는 코드는 조금 쓰고 생각을 많이 하는 것이고 상수는 코드를 쓰기 전에 남의 코드를 많이 보는 것이다. 무릇 한 마디 말을 하기 위해서는 열 마디 말을 들어야 하고, 한 문장을 쓰기 위해서는 백 문장을 읽어야 하고, 한 줄의 코드를 만들기 위해서는 천 줄의 코드를 검토할 필요가 있다. |
노래 좋네요. 듣다가 가사가 너무 좋아서 퍼왔습니다. 사실 노래, 가사 모두 아트입니다. 술잔을 비우고 그대를 비우면 흐르는 눈물로 다시 그댈 채우네요. 사랑해 입술은 그대만 부르고 귓가엔 그대만 들리고 두눈을 애써 감아도 다시 그대가 보이네요. 정말 예술이지 않습니까? 어떻게 저런 표현을 생각해냈는지 토할뻔 했습니다. 이런 사람 있으신가요??? 있으면 참 행복할 것 같아요. ㅎㅎ 이루(Eru) - 둘이라서 |
블로그를 운영한다면 누구나 블로그에 더 많은 방문자 숫자에 조금은 연연하게 됩니다. 특히나 애드센스를 달고 있는 블로그라면 그 의미가 더 크죠. 메타 사이트 가입과 댓글과 트랙백을 남기는 활발한 활동을 입이 닳도록 강조한 이유도 바로 거기 있겠죠. 하지만 사실 메타 사이트 가입도 가입 초기에는 조금 늘어나는듯 하지만 메타 사이트의 관심사 밖의 비주류 글들만 올라오는 "괴짜 프로그래머의 일상사~@@"같은 사이트는 여전히 그림자 속에 묻히기 마련입니다. 댓글과 트랙백도 사실 쉽지 않은 일이죠. 하지만 이는 열심히 활동한다면 반드시 돌아오긴 합니다. 하여튼 기존의 이랬던 블로그 홍보의 불모지대를 수직으로 파고드는 엄청난 서비스가 새로 나왔습니다. 사실 애드센스와는 개념은 비슷합니다. 하지만 좀 더 자선적이고, 좀 더 간단합니다. 이름하여 블로그링크입니다. 일단 아래 그림을 볼까요? ![]() 애드센스를 써보신 분이라면 삘이 확 올겁니다. 그렇습니다. 블로그에 스크립트를 추가하면 위와 갈이 블로그를 광고하는 글이 자동으로 추가됩니다. 그렇다면 자신의 블로그는? 자신의 블로그에 위 스크립트 코드를 다는 순간 다른 사람의 블로그에 홍보가 됩니다. 십시일반이니, 상부상조니 하는 우리 조상들의 정신과 일맥 상통하지 않습니까? ㅎㅎ 저는 가입 절차가 없다는데 정말 놀랐습니다. 거기다 무료입니다. 헐 ㅠㅠ. 지금 바로 즉시 블로그에 블로그링크 스크립트 코드를 추가해 봅시다. 여러 블로거 분들이 절찬리 가입 중이군요. ㅋㅋㅋ 한 가지 아쉬운 점은 서비스를 제공하는 곳에서 아무런 댓가도 요구하지 않는다는 점 입니다. 블로거 입장에서는 굉장히 반가운 일이지만 서비스 제공 업체는 무엇을 얻을 수 있을지 하는 궁금점이 듭니다. 부디 중단되지 않고 지속적으로 제공되는 서비스가 됐으면 좋겠습니다. |
R6025를 새롭게 소개해 드린 이유는 __purecall에 대해서 설명하기 위해서 였습니다. 그 녀석과 __purecall이 매우 밀접한 관계에 있거든요. 아래 코드를 봅시다. R6025 예제보다 더 작위적이죠. 아직 생성되지 않은 가상 함수를 호출하기 위해서 func란 함수를 이용합니다. Entry를 main으로 고치고 컴파일해서 실행해 보면 R6025 에러가 날 겁니다. 하지만 이번에는 조금 다르게 해봅니다. 아래 코드를 Visual C++의 콘솔 프로젝트에 타이핑해 넣고 CRT를 연결하지 않고, 진입점을 Entry로 설정해두고 컴파일 해 봅니다. 아마도 에러가 날 겁니다. __purecall을 찾을 수 없다는 에러죠. CRT를 연결하지 않는 방법은 간단합니다. 여러분이 지정한 CRT 라이브러리를 링크시에 무시하도록 만들면 됩니다. 만약 멀티 스레드 CRT를 선택했다면 프로젝트 속성 창에서 링크 필드에 있는 무시 라이브러리 목록에 libcmt.lib를 추가해 주면 됩니다. [CPP]#include <windows.h> class CBase; class CDerived; void func(CBase *p); class CBase { public: CBase() { func(this); } virtual void test() = 0; }; class CDerived : public CBase { public: void test() { TCHAR buf[] = _T("hello\n"); WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE) , buf , sizeof(buf) / sizeof(TCHAR) - 1 , NULL , NULL); } }; void func(CBase *p) { p->test(); } int Entry() { CDerived a; return 0; }[/CPP] 에러를 없애기 위해서는 아래와 같이 _purecall을 만들어서 넣어주면 됩니다. __purecall이 없다는데 _purecall을 만드는 이유는 Visual C++ 컴파일러가 함수 명 앞에 언더바를 붙이기 때문입니다. 이 녀석을 추가한 다음 컴파일을 하면 정상적으로 컴파일이 될 겁니다. 실행하면 purecall이란 메시지가 출력 될 겁니다. [CPP]int _purecall() { TCHAR buf[] = _T("purecall\n"); WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE) , buf , sizeof(buf) / sizeof(TCHAR) - 1 , NULL , NULL); return 0; }[/CPP] 아마 이쯤되면 여러분 모두가 눈치를 챘을 겁니다. 맞습니다. 순수 가상 함수는 이론적으로는 존재하지 않는 함수 입니다. 하지만 실질적으로 컴파일러는 그 부분을 __purecall로 채웁니다. 즉, 가상 함수를 저장하는 vtable의 함수 부분을 __purecall로 대체한다는 것이죠. 그렇게 함으로써 런타임에 에러를 출력해 줄 수 있죠. 만약 그 부분을 채우지 않고 NULL로 두었다면 잘못된 연산을 수행했다는 메시지와 함께 종료될 것 입니다. |
![]() 이런 런타임 오류를 접해보신 적이 있으신가요? 아래 코드를 실행하면 위와 같은 오류가 발생합니다. 몇 해 전에 작성한 글들을 보니 R6025를 R605라고 잘못 적어뒀더군요. 헐 ㅠㅠ [CPP]class CBase; class CDerived; void func(CBase *p); class CBase { public: CBase() { func(this); } virtual void test() = 0; }; class CDerived : public CBase { public: void test() { printf("hello\n"); } }; void func(CBase *p) { p->test(); } int _tmain(int argc, _TCHAR* argv[]) { CDerived a; return 0; }[/CPP] 코드를 잠시 설명해 보겠습니다. CDerived는 CBase를 상속받은 클래스입니다. CBase에는 test라는 순수 가상함수가 있습니다. main에서 CDerived 클래스를 호출하고 있습니다. 이 호출을 따라가면서 함수 호출 순서를 한번 그려 봅시다. CDerived 생성자 => CBase 생성자 => func(this) => this->test 위와 같이 되겠죠. 중요한 것은 마지막에 호출되는 this->test 함수 입니다. 처음 생성하려고 의도했던 객체는 CDerived 입니다. 하지만 CDerived는 아직 완전하게 생성된게 아니죠. CBase 생성자가 리턴하지 않았기 때문입니다. 따라서 여기서 this->test는 CBase의 순수 가상 함수인 test를 호출합니다. 그래서 런타임 오류를 발생하는 것이죠. 예제가 너무 작위적이기 때문에 이런 바보같은 코드를 누가 작성하겠어? 라고 반문하실 수도 있습니다. 하지만 생성자를 통해서 뭔가를 하는 코드를 작성하는 경우라면 언제든지 실수를 할 수 있는 부분입니다. 저 또한 예전에 워커 스레드 래퍼 클래스를 작성할 때 이런 실수를 한 적이 있습니다. 따라서 클래스를 설계할 때 생성자는 항상 주의 해야 하겠습니다. 가장 좋은 방법은 생성자에서 가상 함수를 호출하지 않도록 하는 것 입니다. 보다 자세한 설명은 아래 MS 기술 자료에서 얻으실 수 있습니다. http://support.microsoft.com/?kbid=125749 |
저의 요즘의 화두는 고민이었습니다. 그래서 종종 주변 사람들과 만날 일이 있으면 꼭 물어보곤 했습니다. 요즘 고민이 무엇인지 말이죠. 그 사람의 고민을 듣다보면 그 사람을 더 잘 이해할 수 있고, 다른 사람들은 어떤 생각을 하면서 살고 있는지도 알 수 있다고 생각했기 때문입니다. 제가 살면서 느낀 고민의 두 가지 재미난 특징은 연속성과 심각성이었습니다. 연속성이란 고민은 끊임없이 계속해서 나타난다는 것 입니다. 이 고민만 해결하면 끝날것 같지만 그 고민을 해결하면 새로운 고민이 저절로 찾아온다는 것이죠. 그래서 전 종종 인생은 고민의 연속이 아닐까? 란 생각을 하기도 합니다. 심각성이란 과거 어떤 고민보다 지금 하고 있는 고민이 더 심각하다는 것 입니다. 과거에 했던 고민을 떠올려보면 정말 고민같지도 않은 고민이 많이 있습니다. 거기에 비하면 지금의 고민은 정말 심각하죠. 하지만 그것도 미래에 올 고민에 비하면 정말 사소한 것에 불과합니다. 이런 두 가지 특성에 기인해서 생각해 본다면, "하나님, 부처님 이 고민만 해결해 주신다면 앞으론 열심히 살도록 하겠습니다."라고 마음 속으로 다짐하는 일이 얼마나 부질 없는 짓인지를 알 수 있습니다. 나의 고민 제가 한창 했던 고민은 가치 평가(valuation)에 관한 것이었습니다. '과연 고객들은 어떤 가치에 기꺼이 금액을 지불할까?'와 같은 것이었죠. 좀 더 구체적으론 '고객이 지불할만한 가치가 있는 서비스는 어떤 것들일까?'가 되겠죠. 김창준님의 글을 보면 이런 말이 있습니다. "고객에게 매일 가치를 전하라." 좋은 말임엔 틀림없습니다. 그런데 정작 진짜 문제는 그 글에도 나와 있듯이 그 가치가 무엇인지를 모른다는 것 입니다. 즉, 가치를 전달해야 한다는 생각은 다들 하고 있지만 어떤 가치를 전달해야 할지를 모르는 경우죠. 내지는 자신이 가치라고 전달한 것을 고객은 가치라고 인정하지 않을수도 있습니다. 또한 그러한 가치 중에서도 제대로 평가 받을 수 있는 가치를 발견하는 것은 더욱 어려운 일이죠. 안타깝게도 아직 이 문제에 대한 답을 찾진 못했습니다. ㅠㅠ 선배의 고민 대학교 선배 중에 제가 굉장히 좋아하는 형이 있습니다. 아마 제 인생에 부모님 다음으로 가장 많은 영향을 받은 사람을 꼽으라면 저는 주저없이 그 형을 말할겁니다. 물론 저 말고도 그 형을 알고 있는 사람들이라면 대부분 그렇게 이야기할 겁니다. 그만큼 후배들에게 학문적으로나 인간적으로나 귀감이 되는 선배였죠. 지금은 미국에 있어서 자주 볼 수는 없지만 종종 메일로 안부를 묻곤 합니다. 근래에 메일을 보냈었는데 어김없이 고민이 뭔지를 물어봤습니다. 사실 전 형의 고민을 한번도 들어본적도 물어본적도 없었거든요. 이런거 물어보는게 좀 웃기긴 하죠. 근데 제법 근사한 답변이 와서 메일의 일부를 발췌해서 올려봅니다. 이 시대를 살고 있는 현대인이라면 누구나 해야 하는 고민이 아닐까하는 생각도 들긴 합니다. 빌게이츠를 박애주의자라고 한 부분이 굉장히 인상적이더군요. 형이 프로그래밍도 굉장히 잘하긴 하는데 주로 BSD 환경과 유닉스 계통에서 많이 작업을 했고, 전공은 칩 설계 쪽입니다. 글 중에 밀물에 관한 이야기도 참 공감이 가는 표현인 것 같습니다. > 형은 요즘 고민 없으세요???다른 사람들의 고민?? 여러분은 요즘 고민이 있으신가요? 있다면 무엇인가요? 앞서 말했던 고민의 두 가지 특성인 연속성과 심각성 외에도 두 가지 특성이 더 있습니다. 우연성과 공개성이 그것인데요, 우연성이란 고민은 항상 심각하게 생각하는 과정보다는 우연한 일에 의해서 해결되는 경우가 많다는 것이고, 공개성이란 공개된 고민이 그렇지 않은 고민보다 해결될 가능성이 높다는 것을 의미합니다. 일반적으로 오픈 소스가 그렇지 않은 프로그램보다 버그나 보안 결함이 낮은 것과 같은 원리죠. 고민을 한다는 것. 어쩌면 그건 우리가 아직 살아있다는 것에 대한 반증인지도 모르겠습니다. 나는 고민한다 고로 나는 살아있다?? |