« Previous : 1 : ... 12 : 13 : 14 : 15 : 16 : 17 : 18 : 19 : 20 : ... 29 : Next »

GetMessage는 Windows 프로그래밍에서 윈도우 message loop을 구현할 때 쓰이는 함수이다.
이 함수는 명목상 리턴값이 BOOL이며, 평소에는 nonzero를 되돌리다가 WM_QUIT가 접수되어서 응용 프로그램이 종료되어야 할 때 FALSE가 된다.

그러나 이 함수의 리턴값이 이것이 전부가 아니다.
정상적으로 한 메시지를 끄집어 왔을 때는 nonzero이긴 한데 양수이며, argument가 올바르지 않다거나 해서 함수의 실행 자체가 실패했을 때는 음수 -1을 되돌린다.

그렇기 때문에 메시지 loop을 while( GetMessage(&msg, NULL, 0, 0)) { }  이런 식으로 구현하면, 메시지를 아예 가져오질 못했는데도 loop의 조건이 만족되며 프로그램은 무한 루프에 빠진다.
!=0으로는 불충분하니, 반드시 while( GetMessage(&msg, NULL, 0, 0) >0)이라고... >0을 명시해야 한다.

(1) 이 함수 말고도 타입이 BOOL인데 사실은 TRUE/FALSE라는 순수한 흑백 논리값 말고 다른 의미 있는 값도 되돌리는 페이크 BOOL 함수가 또 있었던 것 같으나, 당장은 기억이 안 난다. 이런 지저분한 이슈도 있고, 또 Windows API의 기반 언어인 C가 어지간한 건 그냥 machine word 정수로 처리하는 관행이 있기도 하니(문자 상수의 크기도 char이 아닌 int!), 프로그래밍에서도 BOOL은 C++의 bool이 아니라 그냥 int에다 대응시켜 놓은 것 같다.

(2) COM에도 이와 비슷한 얘깃거리가 있다. HRESULT는 원래 0과 양수가 '성공'을 나타내고, 음수가 실패를 나타낸다. 하지만 현실에서는 대부분 그냥 hr==S_OK (0) 여부만으로 성공/실패 여부를 판단한다.
거의 모든 COM 인터페이스 함수들은 실행이 성공했을 때 어차피 S_OK라는 단일한 값만을 되돌리기 때문에 이것이 현실에서 당장 크게 문제가 되지는 않는다. 그러나 원칙적으로는 어지간해서는 hr==S_OK를 쓸 곳에 SUCCEEDED(hr)을 써야 한다. 이것은 hr>=0 여부를 체크하는 매크로이다. hr!=S_OK를 대신해서는 FAILED(hr)이 바람직하고 말이다.

음수도 아니고 0도 아닌 대표적인 리턴값은 S_FALSE이다. 이것은 해당 함수가 의미 있는 동작을 하지는 않았지만 어쨌든 오류가 발생했거나 실패한 상황도 아닐 때 돌아온다. 가령, 뭔가 객체를 enum하고 있는데, 포인터가 이미 끝에 도달해서 더 fetch할 게 하나도 없으면 보통 &ulFetched는 0이 돌아오고 함수 리턴값은 S_FALSE가 된다. 하나라도 fetch된 게 있으면 S_OK이고 말이다.
따라서 이 경우, loop의 종료 조건을 지정하려면 SUCCEEDED와 더불어 fetch된 개수도 체크해야 한다.

(3) 다시 GetMessage 얘기로 돌아온다.
얘는 메시지를 수집하는 윈도우, 그리고 필터링할 메시지의 최소값과 최대값을 인자로 받는다. 하지만 PeekMessage도 아니고 GetMessage에다가 뭔가 동작의 범위를 제한하는 유의미한 값을 지정하는 것은 사실상 거의 쓸데없는 짓이다. 언제나 NULL, 0, 0을 하는 게 맞다. (레이몬드 챈 선생도 인증한 사실임)

이 함수는 뭔가 메시지를 얻을 때까지 실행이 끝나지 않고 계속 기다린다. 어떤 GUI 프로그램이 실행되면 굳이 자신이 아니어도 그 스레드 소속으로 남이 생성한 각종 잡다한 윈도우가 붙는다. 이들 윈도우도 메시지 큐로부터 메시지를 받아야 하는데, GetMessage에다가 필터링을 걸면 해당 윈도우는 메시지를 받지 못하며 그 동안 우리 프로그램도 실행되지 못하게 된다. 쉽게 말해 deadlock에 빠진다.

따라서 아무 윈도우로 전달된 아무 메시지라도 일단은 받아서 윈도우 프로시저로 Dispatch를 시켜야 한다. 정 특정 메시지만 필터링을 하고 싶다면 아까도 말했듯이 PeekMessage를 쓰는 게 훨씬 더 안전하고 바람직하다. 얘는 그래도 한 번만 체크 후 실행이 곧장 끝나기라도 하니까 말이다.

Posted by 사무엘

2014/04/30 08:31 2014/04/30 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/957

Windows API에서 LoadLibrary는 잘 알다시피 자기 프로세스 공간에다가 다른 DLL을 추가로 매핑시키는 매우 중요한 함수이다. 코드 실행이 아니라 단순 리소스 추출만이 목적인 경우, EXE 내지 현재의 기계가 지원하지 않는 다른 아키텍처로 빌드된 모듈을 열 수도 있다.
Windows에서 어떤 모듈(EXE/DLL)은 타 모듈을 말 그대로 자신이 실행되는 로드타임(load-time) 때 곧장 불러와서 여타 DLL에 대한 함수 링킹을 할 수 있으며, 반대로 실행 중인 런타임(run-time) 때 동적으로 할 수도 있다.

로드타임 로딩은 간편하긴 하지만 모듈 파일 이름 이상으로 불러들이고자 하는 디렉터리 위치를 세밀하게 제어할 수 없다. 그리고 모듈이 단 하나라도 존재하지 않거나 해당 파일에 함수 심벌이 단 하나라도 존재하지 않으면 프로그램이 전혀 실행되지 않는다. 그런 예외 상황이 발생했을 때의 제어도 사용자가 전혀 할 수 없기 때문에 프로그램의 유연성 내지 융통성이 떨어진다는 단점이 있다. 내 프로그램의 로드 자체가 실패해 버리니 말이다.

그래서 새 운영체제에 들어있는 API 함수를 쓰긴 하는데, 그 함수가 존재하는지 체크를 미리 해서 구형 운영체제와의 호환성도 유지하기 위해서는.. LoadLibrary와 GetProcAddress를 이용하는 런타임 로딩 기법을 써야 한다. 로드타임 로딩이라면 운영체제가 그 기능을 내부적으로 자동으로 제공해 줬을 텐데 런타임 로딩은 함수 포인터를 수동으로 관리해야 하니 좀 번거롭긴 하다.

이럴 때, 비주얼 C++ 6때부터 도입된 delay-loading은 로드타임 로딩과 런타임 로딩의 장점을 취합한 굉장히 괜찮은 대안이 될 수 있다. COM은 런타임 로딩을 규격화된 인터페이스라는 형태로 좀 더 깔끔하게 정형화한 바이너리 표준일 테고 말이다.

DLL을 불러올 때, LoadLibrary에다가 파일의 절대 경로를 주지 않고 파일 이름만 달랑 넘겨 주면 이 함수는 프로그램이 실행된 current 디렉터리, 프로그램이 존재하는 디렉터리, 운영체제의 시스템 디렉터리, PATH에 등록된 디렉터리 등 다양한 순서대로 파일을 탐색한다. 로드타임 로딩 때도 대상 DLL은 이런 순서대로 탐색된다.

이것은 프로그램의 동작에 유연성을 부여하고 한 DLL을 여러 프로그램들 사이에서 최대한 쉽게 공유가 되게 하기 위함이나, 오늘날에 와서는 이런 정책은 보안에 악영향을 끼치게 되었다. 이름만 같고 우선순위가 더 높은 디렉터리에 존재하는 악의적인 DLL이 잘못 선택되어 로딩될 수 있기 때문이다. 또한 하위 호환성이 지켜지지 않는 시스템 DLL이 덮어써짐으로써 DLL hell 같은 고전적인 문제도 야기될 수 있다. 갈수록 난잡해지고 포화 상태로 치닫는 시스템 디렉터리는 큰 골칫덩어리이다.

LoadLibrary의 디렉터리 탐색 방식 자체를 바꿀 수는 없다. 그 방식에 의존하여 동작하는 수많은 기존 프로그램들과의 호환성을 유지해야 하기 때문이다. 그렇기 때문에 오늘날 마소에서는, 새로 개발되는 프로그램에서는 LoadLibrary를 호출할 때 저런 알고리즘에 의존하지 말고 반드시 DLL의 전체 경로를 명시해 줄 것을 권고하고 있다. 또한, 전면 금지하는 건 불가능하겠지만, 운영체제의 시스템 디렉터리에다가는 가능한 한 자기 싸제 DLL을 집어넣지 말 것을 권고한다.

일례로, 예전에 qt 라이브러리를 DLL 링크한 프로그램을 돌려 봤다. 이 DLL은 운영체제의 시스템 디렉터리에 있는 것도 아니었는데 어떻게 DLL을 찾는지 궁금했는데... 에구, 그냥 PATH 지정이더라. 운영체제의 환경변수를 대놓고 바꿔 버리는 건 굉장히 안 좋은 방법인데 어쩔 수 없다. 이제 윈도 XP가 나온 지도 10년이 넘었으니 WinSXS 매니페스트 방식이라도 써야 하지 않나 싶다.

요컨대 Windows는 (1) 제3자 응용 프로그램이 자기끼리 공유하는 공용 DLL을 손쉽게 찾아 로딩하는 법, 그리고 (2) 운영체제의 시스템 DLL을 보안 문제 없이 간편히 로딩하는 법을 완전히 이원화하여 체계적으로 제공할 필요가 있다. 확장 버전인 LoadLibraryEx 함수에라도 그런 기능을 좀 추가할 수 없나 궁금하다.

(1)의 경우 아까도 말했듯이 delay-loading이나 WinSXS가 그럭저럭 해결책이다. 이게 중요한 문제이기 때문에 윈도 XP부터는 SetDllDirectory 함수가 추가되긴 했으나, 이것은 로드타임 로딩을 제어할 수 없기 때문에 여전히 근본적인 해결책이 아니다.

(2)는 known DLL 리스트라는 게 레지스트리에 존재한다. 그래서 "kernel32", "user32" 같은 건 DLL계의 예약어(reserved word)처럼 돼서 주변에 kernel32.dll, user32.dll 같은 동일 명칭의 사칭 파일이 있다 해도 언제나 운영체제의 시스템 디렉터리에 있는 놈이 로딩된다는 게 보장된다.

그러나 개인적인 생각은 그걸 API 차원에서 좀 더 엄밀하게 했으면 좋겠다. 아까 말했듯이, API 하위 호환성 유지를 위해 운영체제의 시스템 DLL을 수동으로 로딩하는 경우는 빈번하게 존재한다. 그리고 운영체제가 버전업되면서 새로운 시스템 DLL이 앞으로 얼마나 더 추가될지 모른다. 그러니 오로지 시스템 DLL만 로딩하고 다른 싸제 DLL은 유사품이 있다 해도 거부하는 명령이 있었으면 좋겠다.

앗싸리 시스템 DLL까지 몽땅 시스템 디렉터리 전체 경로를 지정해 줘서 로딩시켜 보기도 했다. 그런데 이렇게 했더니 한 가지 복병에 걸리는 게 있다. 바로 comctl32.dll이다.
얘는 WinSXS 매니페스트로 넘어가서 길고 이상한 다른 디렉터리에 있는 놈이 로딩되기 때문이다. 이걸 무시하고 운영체제 시스템 디렉터리에 있는 놈을 로딩하면 TaskDialog처럼 공용 컨트롤 6.0 이상에서만 지원되는 기능들을 사용할 수 없다.

그러니 시스템 DLL은 경로 다 생략하고 그냥 "comctl32", "kernel32" 이렇게만 로딩하는 게 정답인 듯하다.
문득 스프레드 시트 프로그램인 엑셀이 생각난다. 엑셀은 구조적인 이유로 인해 이름이 동일하고 서로 다른 디렉터리에 존재하는 여러 파일을 동시에 열 수 없다. 수식에서 다른 워크시트 파일을 참조할 때 디렉터리 대신 오로지 파일 이름만을 토대로 탐색을 하기 때문이다.

Posted by 사무엘

2014/04/27 08:25 2014/04/27 08:25
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/956

1. 특정 명칭(클래스, 함수, 변수 등등)의 선언지로 곧바로 찾아가기.
(1) 소스 코드에서 cursor나 마우스 포인터가 가리키고 있는 명칭에 대해서는 현재 소속되어 있는 클래스나 namespace 문맥을 감지하여 동작해야 하며, (2) 그냥 임의의 심벌을 타이핑하여 조회하는 기능도 있어야 한다. 둘 다 필요하다.

2. 디렉터리를 불문하고 프로젝트에 있는 특정 파일 이름을 곧바로 타이핑으로 조회하여 파일 열기. 시작하는 단어와 중간에 있는 단어가 모두 지원되어야 한다.

3. 그리고 명칭이 아닌 임의의 문자열을 검색하는 Find in files인데, 다음과 같은 범위에서 모두 가능할 것.
(a) 소스(=번역 단위)든 헤더든 프로젝트에 정식으로 등록돼 있는 파일
(b) 프로젝트에 정식으로 등록은 안 돼 있지만, 등록된 파일로부터 인클루드에 의해 한 번이라도 엮이는 파일들
(c) 프로젝트 파일이 하나라도 존재하는 디렉터리에 덩달아 있는 모든 소스 파일들

즉, 3은 파일 내부의 문자열 검색이고 2는 파일 이름 자체의 검색이다. 2의 경우 일단은 검색 도메인이 (a)만으로 한정이지만, 2도 (b)나 (c)가 옵션에 따라 지원된다면 금상첨화다.

Visual Studio IDE의 경우, 1은 진작부터 인텔리센스 엔진을 통해 지원되어 왔다. 그러나 2는 2012에 와서야 가능해졌으며, 3은 (a)만 가능하다. (c)를 하려면 결국 프로젝트 경로를 수동으로 직접 입력해야만 가능하여 매우 불편함. 프로젝트에 존재하지는 않지만 같은 디렉터리에 있는 파일들을 덩달아 찾아야 할 때도 있는데도 말이다.

물론 (b)는 소스 코드를 컴파일까지는 아니어도 전처리기 수준의 파싱은 해야 구현 가능하기 때문에, 좀 어려울지 모른다. #include를 제대로 처리하려면 프로젝트 차원의 인클루드 디렉터리 관리자가 있어야 하며, 조건부 컴파일뿐만 아니라 인클루드 대상 자체에 대해서도 매크로 상수 전개가 필요할 때가 있으니 말이다.

c/cpp 같은 소스 코드가 그 자체로 온전한 번역 단위를 구성하는 게 아니라, 다른 소스 코드에 또 인클루드되어 쓰이는 경우가 있다. 물론 프로젝트에 등록되지 않은 채로 말이다.
이런 파일은 (a) 형태의 문자열이나 파일명 검색이 되지도 않아 대단히 불편하며, IDE가 구문 분석을 하는 것도 굉장히 복잡하고 어렵게 만든다. C/C++에서 인클루드는 정말 양날 달린 검인 게 실감이 간다.

끝으로 (b)와 관련된 여담 하나 좀 남기겠다.
과거 비주얼 C++ 6 시절엔 프로젝트 파일 리스트에 External dependencies라고 해서, 정식으로 프로젝트에 포함돼 있지는 않지만 프로젝트 파일에 의해 인클루드되는 파일을 대충, 얼추 계산해서 표시해 주는 기능이 있었다. '대충, 얼추'라는 말은 그 동작이 100% 정확하지는 않았다는 뜻이다. 그러던 것이 닷넷으로 넘어가면서 이 얼렁뚱땅 불완전한 기능은 삭제되었다.

그 뒤, 버전이 201x으로 넘어가면서 이 기능은 부활했다. 온전한 컴파일러가 소스 코드를 머리부터 발끝까지 다 분석하면서, MFC와 플랫폼 SDK가 중첩 인클루드하는 수십, 수백 개의 헤더 파일들을 하나도 빠짐없이 정확하게 나열해 주는 무시무시한 기능으로 다시 태어난 것이다. 비주얼 C++ IDE는 변화가 없는 것 같아도 내부적으로 이렇게 변모하고 있다.
모든 파일들의 의존도 정보를 파악하고 있다는 소리이니, 이를 바탕으로 함수 호출 tree처럼 파일들의 include 계층 다이어그램(includes / included by)을 그려 주는 기능은 IDE에 혹시 없나 궁금하다.

Posted by 사무엘

2014/04/21 08:28 2014/04/21 08:28
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/954

Windows API에는 FreeLibraryAndExitThread라는 함수가 있다.
얘가 하는 일은 이름이 암시하는 바와 같다. 주어진 모듈에 대해 FreeLibrary를 한 뒤 ExitThread를 호출하여 지금 실행 중인 자기 스레드를 종료한다.

어지간하면 응용 프로그램이 두 함수를 차례로 직접 호출해 주면 되며, 둘을 나란히 호출해야 할 일 자체도 실무에서는 매우 드물다. DLL을 제거하는 건 대체로 응용 프로그램이 종료될 때 같이 행해지지, 특정 스레드의 실행이 끝나자마자 칼같이 행해지는 일은 없기 때문이다. 그런데 왜 이런 함수가 정식으로 별도로 제공되는 걸까(Windows NT 3.1 첫 버전은 아니고 3.5에서 추가됨)? 다 이유가 있기 때문이다.

어떤 DLL이 별도의 스레드를 생성해서 자신의 코드를 동시에 실행하고, 실행 후에는 자기 자신을 스스로 깔끔하게 제거하여 사라지게 설계되어 있다고 치자. 즉, DLL을 로딩한 모듈이 그걸 수동으로 따로 해제하는 게 아니라, 그 DLL이 자기 임무를 다한 후 스스로 사라진다는 것이다. 이건 비록 흔한 디자인 형태는 아니지만 말이다.

이 경우, DLL의 코드가 자신에 대해서 FreeLibrary(hMyDLL)을 함부로 호출해 버려서는 곤란하다. 그러면 자기 스레드가 활동하던 모듈이 메모리에서 사라져 버리기 때문에 그 다음에 실행될 스레드 실행 종료 부분에 해당하는 코드(return 0 내지 ExitThread)까지 사라진다. 스레드는 정상적으로 종료되지 못하고 곧장 access violation이 발생한다.

그렇다고 ExitThread를 먼저 호출하면? 이 DLL을 실행하는 주체인 스레드의 실행이 끝나 버리기 때문에 FreeLibrary가 호출될 기회가 없다. 마치 실행 중인 EXE 자신을 제거하는 코드를 실행하는 것과 비슷한 맥락의 딜레마가 발생한다.

모듈(공간) 해제와 스레드(시간) 종료가 동시에 행해져야 할 경우, 이것은 운영체제가 알아서 동시에 수행해 줘야 한다.
FreeLibraryAndExitThread를 호출한 경우, 내부적으로 FreeLibrary가 됐더라도 그 다음으로 ExitThread를 호출하는 코드는 그 DLL이 아니라 운영체제가 책임을 지기 때문에 안전하다.

한편, Windows에서는 EXE나 DLL의 로딩이 파일 자체를 가상 메모리 주소에다 곧장 연결하는 memory-mapped file 기법으로 행해진다. 그렇기 때문에 실행 중인 프로그램 파일이 중간에 지워지는 것은 운영체제가 허용하지 않는다. 즉 DLL과 스레드 문제로 비유하자면 FreeLibrary 단계에서 이미 실패한다는 것이다.

그렇다고 자신을 먼저 종료해 버리면 자기 자신 파일을 지우는 코드가 실행되지 못할 테니, 이 역시 동시에 충족될 수 없는 모순이 된다. ExitProcessAndDeleteFile 같은 전용 함수라도 있어야 할 것 같은데.. Windows API에는 그런 건 없다.

다만 EXE와는 달리 실행 중인 배치 파일은 자기 자신을 제거하는 게 가능하다. 그래서 설치 제거 프로그램 같은 데서는 내부적으로 EXE를 지우고 자기 자신도 삭제하는 배치 파일을 만들어서 이걸 내부적으로 실행한 뒤, 자기 프로그램은 최대한 신속하게 종료함으로써 흔적 없는 '자폭'을 한다. 배치 파일은 당연히 IF EXISTS와 GOTO loop가 있어서 파일이 완전히 지워질 때까지 삭제 시도를 반복한다.

배치 파일은 자가삭제가 가능하긴 하지만 삭제된 뒤의 명령들은 실행되지 못하고 에러와 함께 실행이 끝난다. 옛날에 4DOS 같은 MS-DOS 대체 명령 프롬프트에는 BTM (Batch to memory)처럼 모든 내용을 메모리로 읽은 뒤에 실행하는 특수한 배치 파일이 있긴 하지만 이것은 MS 기반의 오리지널 셸에 있는 기능은 아니다.

물론 설치/제거 프로그램이라면 요즘은 직접 짜는 게 아니라 Windows Installer를 사용하는 게 대세이니 저런 꼼수를 직접 구현해야 할 필요는 더욱 없어지긴 했다. 자기 정체를 요리 조리 교묘하게 숨겨야 하는 악성 코드나 돼야 필요할까?

거의 모든 Windows API 함수들은 뭘 실행하더라도 성공/실패 여부를 되돌리는 리턴값이 있다. 리턴값이 없는 void형 함수는 정말 실패를 절대로 걱정할 필요가 없는 예외적인 물건을 제외하면 매우 드물다.
그러나 ExitProcess 내지 ExitThread처럼 뭔가 자신의 실행을 종료하고, 실행 후에 리턴값을 받을 주체 자체가 없어지는 함수라면 리턴값이 응당 void이다. 종료하는 동작이 실패할 리도 없을 테고 말이다.

FreeLibraryAndExitThread도 예외가 아니다. 모듈 핸들을 잘못 줄 경우 FreeLibrary 부분은 실행이 실패할 수 있지만, 후반부의 ExitThread 부분은 언제나 성공이 보장되기 때문이다.

그러고 보니 메시지 큐에다가 WM_QUIT를 넣어 주는 PostQuitMessage도 종료와 관계가 있는 전용 함수이며 void 형이다. WM_QUIT 메시지는 GetMessage 함수로 구성된 message loop을 끝내는 역할을 하며, 윈도우 프로시저를 통해 전달되지는 않는다.
MSDN은 저 메시지는 반드시 PostQuitMessage라는 전용 함수를 통해서(주로 메인 윈도우의 WM_DESTROY 타이밍 때) 넣어야지, 수동으로 PostMessage(hWnd, WM_QUIT, 0, 0) 같은 식으로 넣어서는 안 된다고 명시한다.

사실 저건 특정 윈도우가 대상이 아니라 스레드의 메시지 큐 자체가 대상이기 때문에 hWnd에 아예 NULL을 주거나, PostThreadMessage(GetCurrentThreadId(), WM_QUIT, 0, 0)과 비슷하다.
다만, WM_QUIT은 여느 메시지와 동일하게 취급되는 게 아니라 스레드의 내부 상태 차원에서 종료 플래그가 붙은 것으로 특수하게 처리되기 때문에 PostQuitMessage 같은 별도의 함수가 존재하는 것이다. 제거 딜레마의 해결 필요 때문은 아니다.

Posted by 사무엘

2014/04/15 08:25 2014/04/15 08:25
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/952

소프트웨어 GUI 구성요소 중에 콤보 박스는 굉장히 유용한 물건이다.
공간을 적게 차지하면서 리스트 박스의 역할을 고스란히 수행할 수 있으며(비록 다중 선택은 안 되지만)
에디트 박스(입력란)의 역할을 수행하면서, 예전에 사용자가 입력했던 문자열이나 샘플이 될 수 있는 디폴트 값을 곧장 선택할 수 있게도 해 주기 때문이다.

입력란이 없이 선택만 가능한 타입을 Windows에서는 drop list 형태라고 부른다.
일반적으로 콤보 박스에서는 마우스 휠을 굴리거나 상하좌우 화살표를 누르면 선택 항목이 인접한 다른 것으로 바뀐다. 그리고 마우스를 클릭하거나 키보드 F4 내지 Alt+상하 화살표를 누르면 리스트가 화면에도 뜬다. 이것이 표준 동작 방식이다.

그런데 Windows는 이것과 약간 다른 형태의 동작 방식도 지원한다. 일명 extended UI라고 들어 보셨나 모르겠다.
이 모드를 사용하는 콤보 박스는 일반적인 기능은 여느 drop list 콤보 박스와 완전히 똑같다.
그러나 얘는 일단 마우스 휠에 반응하지 않는다. 클릭을 하거나 아래 화살표를 누르면 먼저 리스트부터 나타난다. 그 뒤에야 상하 화살표나 마우스를 이용해서 선택 아이템을 변경할 수 있다.
다른 프로그램들에서 이렇게 동작하는 콤보 박스를 본 기억이 있으신 분 계신가? 이런 콤보 박스는 매우 드물고 보기 힘들긴 할 것이다.

extended UI가 지정된 콤보 박스는 아이템 선택을 바꾸는 게 번거롭다. 굳이 리스트를 꺼내지 않고 간편하게 선택을 바꿀 수가 없으며, 리스트를 여는 키보드/마우스 동작이 반드시 선행되어야 하기 때문이다.
굳이 이런 모드를 왜 넣었는지 본인으로서는 알 길이 없다. 혹시 Windows 3.x 시절에는 콤보 박스가 원래 이렇게 동작하기라도 했었나? 아니면 다른 프로그램의 GUI와 호환성을 유지하기 위해서였는지?

호환성이 이유라면 차라리 모든 콤보 박스들이 extended이든 그렇지 않든 사용자가 지정한 방식으로 동일하게 동작하도록 제어판 설정 같은 걸 추가하면 된다. 굳이 각각의 콤보 상자에 따로 적용되는 옵션으로 둘 필요는 없다.

더구나 extended UI의 사용 여부는 내가 아는 한은 어느 개발 환경에서도 리소스 차원에서 개체 속성의 수정만으로 간단히 지정하는 방법이 없다. 다시 말해 반드시 코딩을 통해서 지정해 줘야 하며, API의 형태도 구리다는 뜻이다. 이상한 점이 아닐 수 없다.

CB_GETEXTENDEDUI 메시지를 보내서 사용 여부를 얻어 오고, CB_SETEXTENDEDUI로 지정하면 된다. 진짜로 BOOL 값 하나를 달랑 얻어 오거나 지정하는 get/set 함수 형태 그 이상도 그 이하도 아니다.

트리 뷰나 리스트 뷰 같은 공용 컨트롤의 경우, 지정할 수 있는 속성이 워낙 많다 보니 운영체제가 기본으로 할당해 주는 스타일과 확장 스타일(extended style)로도 공간이 부족하다. 그래서 자체적인 추가 확장 스타일을 얻거나 지정하는 메시지가 따로 존재한다.

그러나 콤보 박스는 필요한 정보량이 겨우 1비트에 불과하고 그 정도면 그냥 CBS_(EX)_EXTENDEDUI 같은 스타일 비트 하나만 추가하는 걸로 충분하지 않았을까? 안 그래도 잉여력이 충만한 옵션인데 왜 사용하기도 번거롭게 만들어 놓았나 하는 의문이 남는다. 아니... 반대로 잉여로운 옵션이니까 API도 그렇게 따로 뚝 고립시켜 놓은 것인지도?

옛날에는 extended UI를 리소스 에디터에서 속성 변경만으로 곧장 지정했던 것 같기도 해서 지금 비주얼 C++의 리소스 에디터를 뒤져 보고, 심지어 비주얼 C++ 6 같은 옛날 버전들도 살펴봤다. 하지만 그런 건 없다.

그 대신, 비주얼 C++ 4~6이 사용하던 옛날 프로퍼티 대화상자가 사용하는 콤보 박스가 extended UI를 사용하는 것을 확인했다. 마우스 휠이 동작하지 않으며, F4 대신 아래 화살표를 누르면 drop list가 나오더라.
그리고 그러고 보니.. MS 오피스 프로그램들, 특히 대화상자들까지 운영체제의 표준 GUI 대신 자체 GUI를 쓰는 Word와 Excel의 경우, 모든 콤보 상자들이 extended UI 기반이긴 하다.

운영체제의 GUI를 API 날것 형태로 그대로 제공하는 게 아니라 자체적으로 재분류도 해 놓은 닷넷(C#)이나 비주얼 베이직 6의 폼 에디터도 살펴봤다. 콤보 박스를 집어넣었지만 딱히 extended UI 속성을 지정하는 프로퍼티는 보이지 않는다. (단, 델파이까지는 못 살펴봄)

이상, Windows의 기본 GUI에 존재하는 어느 대단히 잉여로워 보이는 기능과 불편한 API에 대해서 살펴보았다.
지금이나 앞으로나.. extended UI가 적용된 콤보 상자는 거의 찾을 수 없을 것이다.
옛날에 노턴 유틸리티의 GUI(뭐, 텍스트 모드에서 GUI를 비슷하게 흉내 내며 동작한 것이니 정확히 말하면 TUI?)가 제공하는 콤보 상자는 Ctrl+아래 화살표를 눌러야 리스트가 떴었는데 Windows는 F4 또는 "Alt+아래 화살표"이구나.

여담을 하나 남기며 글을 맺겠다.
운영체제가 제공하는 각종 Win+? 단축키에 대한 설명은 컴퓨터 활용 팁 같은 데에 많이 소개되어 있다. 하지만 운영체제가 제공하는 기본 컨트롤 자체에 대한 팁 정보는 상대적으로 문서화나 공유가 덜한 것 같다.

예를 들어 복수 선택이 가능한 리스트 컨트롤은 Shift+F8을 눌러서 복수 선택 모드로 진입하게 되어 있는데, 이것 말고도 내가 모르는 기능이 있는지도 모른다. 왜 하필 그냥 F8도 아니고 Shift+F8인 것이며 그 유래는 무엇일까?
그리고 리스트 뷰 컨트롤은 아이템 이름을 바꾸는 단축키가 왜 하필 F2일까? 이런 것에 대해 좀 더 알았으면 하는 생각이 있다.

Posted by 사무엘

2014/04/04 08:31 2014/04/04 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/948

#define의 대체제

확실히 #define은 다른 걸로 대체 가능할 때는 가능한 한 안 쓰는 게 좋을 것 같다.
C++은 용도별로 다음과 같은 다양한 대체제를 제공한다.

1. 매크로 함수의 대체제: 인라인 함수로 대체 가능하며, 템플릿까지 동원하면 매크로 함수 만만찮은 유연한 메타프로그래밍이 가능하다.
또한 한 함수 안에서만 지엽적으로 반복되는 루틴을 정리하려면 C++0x부터는 람다 함수를 쓸 수도 있다.

2. 매크로 상수의 대체제: 정수의 경우 enum을 쓰면 같은 성격의 여러 심벌들을 한데 묶어 놓을 수도 있어서 좋다.
그리고 문자열은 그냥 const char/WCHAR 형태의 전역/클래스 static 변수로 처리함. 선언과 정의가 따로 존재해야 해서 불편할 수 있으나, 이것은 선언부에다 값을 다 집어넣고 확장 문법인 __declspec(selectany) extern const 를 지정해서 해결할 수도 있다.

아무 통제도 없이 너무 일방적으로 효력이 나타나는 #define보다는 저런 대체제들이 type-safety와 엄격한 scope 검증이 보장되기 때문에 "훨씬 더" 깔끔하다. 가능한 한 전처리기보다는 컴파일러에게 일을 맡기는 게 바람직하다.
내가 만든 명칭이 매크로로 이미 존재하여 딴 걸로 치환되고 있는 줄도 모르고 컴파일러가 자꾸 이상한 난독증을 보이며 에러를 뱉는 것 때문에 빡친 경험이 있는 사람.. 주변에 의외로 많다. ㅎㅎ

단, 그럼에도 불구하고 대체제가 존재하지 않아서 #define을 불가피하게 써야만 하는 경우는 아마도 다음과 같을 것이다.

1. #if #elif #endif 같은 조건부 컴파일 변수 지정

2. 함수 형태를 갖추기조차 민망할 정도로 너무 간단한 로직. 디버그 빌드에서도 독립된 함수 호출이 아니라 언제나 인라이닝이 반드시 보장되기를 바라는 부분

3. 호출하는 함수나 지정하는 변수 이름을 말 그대로 간단히 치환만 시키기를 원하는 경우

4. 대체제의 문법적 한도를 넘는 과격한 구문 치환을 해야 하는 경우. 특히 #나 ## 같은 연산자를 동원해서 완전히 새로운 토큰을 만들어 내야 할 때

5. __LINE__, __FILE__, __TIME__ 같은 빌드/디버그 정보를 그때 그때 삽입하고 싶을 때

6. 정수와는 달리 부동소숫점과 문자열은 여전히 #define이 유용한 경우가 있다.
부동소숫점은 enum이 지원되지 않고 static const 멤버도 클래스 선언부에서 바로 값 지정이 되지 않기 때문이다. (이걸 지원하는 컴파일러도 있긴 하나, 일단은 비표준임)
문자열은 매크로 상수의 경우, concatenate(연결)되는 문자열의 일부가 되는 게 가능하다. const 상수는 그렇지 않다.

#include와 #define이 너무 지저분하고 컴파일 시간을 증가시키는 요인이라며 없애자니.. 위와 같은 용도까지 부정하는 건 현실적으로 무리이긴 하다.

여담으로..
근래엔 남이 만든 코드를 읽다가 IID_PPV_ARGS라는 매크로를 보고 감탄하여 내가 짠 기존 코드에다가도 다 리팩터링을 해서 적용해 놨다.

CoCreateInstance와 IUknown::QueryInterface 때 꼴도 보기 싫던 void ** 형변환을 없애 주는 매우 편리하고 유용한 물건이다. COM이 등장한 건 무려 20년이 넘었고 C++에 템플릿이 추가된 것도 만만찮게 오래 됐을 텐데 이 매크로는 무려 Windows 7의 플랫폼 SDK에서야 정식 등장했다는 게 놀랍다.
매개변수 2개를 하나로 줄이는 역할까지 하니 이 정도라면 컴파일러가 아니라 전처리기 매크로밖에 선택의 여지가 없긴 하다.

Posted by 사무엘

2014/04/01 19:20 2014/04/01 19:20
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/947

윈도 GUI 환경에서 동작하는 프로그램이 자기 창을 띄우기 위해 먼저 해야 하는 일은 바로 자기 윈도우의 클래스를 운영체제에다 등록하는 것이다. WNDCLASS 구조체와 RegisterClass함수는 그야말로 기본 중의 기본 필수 과정이다.

WNDCLASS 구조체에서 중요한 멤버는 클래스 이름(lpszClassName), 윈도우 프로시저 주소(lpfnWndProc) 정도다. 나머지 값들은 전부 0 / NULL이어도 클래스 등록이 가능하다.

우리에게 친숙한 에디트 컨트롤, 리스트박스, 콤보박스 등등은 다 고유한 클래스 이름이 존재하기 때문에 사용자 프로그램이 이를 변경하거나 없앨 수 없다. 윈도우 클래스계의 일종의 예약어라 해도 과언이 아니다. 공용 컨트롤은 내장 컨트롤 급의 붙박이는 아니지만 그래도 공용 컨트롤 매니페스트를 사용하는 요즘 프로그램들에서는 사실상 붙박이다.
대화상자, 메뉴, Alt+Tab 전환 창처럼 운영체제가 내부적으로만 사용하는 known 윈도우들도 사실은 다 고유한 클래스 이름을 갖고 있다.

한편, 각각의 윈도우 클래스 명부는 고유한 기억장소를 갖고 custom 데이터를 보관할 수 있다(cbClsExtra). 그러나 이건 거의 필요하지 않으며 쓰이지 않는다. 여러 윈도우 클래스들이 한 윈도우 프로시저를 공유하면서 그 프로시저가 클래스별로 custom 데이터를 가려서 동작하기라도 하지 않는 이상 말이다. 그런 게 아니라 윈도우 클래스별로 완전히 따로 노는 공유 데이터라면 그냥 해당 프로그램이 자체적으로 static/전역 변수의 형태로 갖고 있으면 될 일이다.

차라리 클래스가 아니라 각각의 윈도우들이 custom 데이터를 저장할 공간이라면(cbWndExtra) 이건 그래도 종종 쓰이는 경우가 있다. 그러나 굳이 이게 0이더라도 포인터 하나 정도 집어넣을 공간은 모든 윈도우들이 기본으로 갖고 있기 때문에 HWND로부터 그 창에 대응하는 C++ 객체의 포인터를 저장하는 것 정도는 이런 방식으로 하면 된다.

그 다음으로 외형 관련 부가 정보들은 나중에 클래스 차원이 아닌 윈도우 차원에서 변경 가능한 것들이다.

프로시저의 주소만 있으면 충분할 텐데 굳이 인스턴스 핸들까지 따로 받는 건 16비트 시절의 잔재이긴 하다. 요즘 같으면 윈도우 프로시저 주소가 어느 영역에 있는지만 봐도 이 윈도우 클래스의 소속 모듈은 곧바로 알 수 있으니 굳이 그 핸들을 따로 줄 필요는 없기 때문이다.
하지만 호환성 문제도 있고, 또 외형 리소스(메뉴, 마우스 포인터, 아이콘 등)를 어디서 불러올지 기준으로 삼을 모듈이 필요하기도 하니 인스턴스 핸들을 받는 란이 있는 것이다.

아이콘(hIcon)은 시스템 메뉴와 두꺼운 프레임이 갖춰진 커다란 윈도우를 만들 때에나 필요할 텐데,
여기서 지정한 뒤에도 나중에 실행 중에 WM_SETICON 메시지를 운영체제에다 보내서 변경이 가능하다. 대화상자의 아이콘을 바꿀 때 주로 쓰인다.

text를 바꾸는 것과는 달리 아이콘을 변경하는 건 함수가 전혀 존재하지 않고 메시지만 쓰인다는 게 특징이다.
또한, HICON 자체를 여러 크기의 아이템 컬렉션/패밀리로 설정한 게 아니라 특정 크기의 그림 하나만을 나타내게 설정한 바람에 WNDCLASS에 이어 WNDCLASSEX까지 등장하는 등 API가 다소 지저분해진 건 아쉬운 점이다. 지금은 이분법적인 큰 아이콘/작은 아이콘뿐만이 아니라 다양한 크기의 아이콘까지 등장해 있는데 말이다.

마우스 포인터(hCursor)는 잘 알다시피 WM_SETCURSOR 메시지가 왔을 때 동적으로 변경 가능하다.
기본 배경색(hbrBackground)으로 화면을 지우는 동작도 WM_ERASEBKGND 메시지 때 변경 가능하다.
즉, WNDCLASS에 지정된 것만이 절대적이지는 않다는 뜻이다.

그것도 모자라서 클래스 구조체에 메뉴(lpszMenuName)까지 지정 가능한 것이 굉장히 뜻밖이다.
보통 윈도우를 만들 때 메뉴 정보는 CreateWindowEx 함수에다가 따로 지정해 주기 때문이다. 그렇기 때문에 WNDCLASS 구조체에 굳이 메뉴 핸들이 공급될 필요는 없다.
본인 역시 10여 년간 Windows API로 프로그래밍을 하면서 이 멤버에다가 값을 지정해 준 적은 한 번도 없었다.

자, 그럼 이제 스타일(style)만 남는데, 다음과 같은 것들이 있다. 이 역시 굳이 이 스타일을 안 줘도 동일한 기능을 코드를 통해 얼마든지 재연할 수 있는 게 대부분이고, 오늘날에는 거의 필요하지 않거나 사용이 권장되지 않는 잉여 옵션도 있다.

1. 정말 유의미한 차이가 있음 (유일!): CS_GLOBALCLASS

원래 윈도우 클래스 명칭은 해당 클래스를 등록한 스레드도 아니고 그 등록한 코드가 들어있는 모듈(EXE든 DLL이든)에서만 쓸 수 있다. 그러나 이 옵션이 지정된 채로 등록된 윈도우 클래스는 해당 프로세스 전체에서 사용할 수 있게 된다.
어떤 특수한 윈도우--custom 컨트롤이 대표적인 예--에 대한 코드가 DLL에 들어있고 그 윈도우를 그 DLL을 불러들인 EXE에서 사용하고자 한다면, 그 클래스는 당연히 이 스타일이 지정된 채로 등록되어야 한다.

쉽게 말해 이 윈도우 클래스를 작성하지 않은 다른 EXE/DLL에서 컴포넌트처럼 생성되고 사용되고자 하는 윈도우라면 이 스타일이 반드시 필요하고, 그냥 한 프로그램 모듈 안에서 내부적으로만 사용하고 말 local 윈도우라면 지정하지 않으면 된다.

16비트 시절에는 이 스타일의 여파가 훨씬 더 강력해서 한 EXE가 등록해 놓은 윈도우 클래스를 다른 EXE가 마음대로 사용할 수도 있었다. 인스턴스 핸들로 데이터 세그먼트를 구분하는 게 오늘날로 치면 그냥 응용 프로그램의 주소 공간을 마음대로 넘나드는 거나 마찬가지였기 때문이다. 그러나 오늘날은 그렇게까지는 할 수 없으며, 일반적으로는 DLL에다가 윈도우 프로시저를 구현한 뒤, 그 윈도우를 사용하고자 하는 EXE가 DLL을 매번 불러오고 클래스 등록을 저렇게 해 줘야 한다.

2. 다른 코드를 통해 대체 가능한 동작 방식의 차이

CS_DBLCLKS
좌든 우든 한 마우스 버튼을 충분한 시간 간격 이내에 빠르게 연타했을 때, 둘째 클릭은 WM_?BUTTONDOWN이 아니라 WM_?BUTTONDBLCLK라는 메시지로 달리 알리게 한다. 이것은 실행 시간에 매번 바뀔 만한 동작 방식은 아니니 윈도우의 스타일이 아니라 클래스의 스타일로 존재하는 게 적절하긴 하다.

굳이 이 스타일이 없어도 더블클릭을 인식하는 것을 우리가 직접 구현하는 건 어렵지 않다. 그러나 타이머 체크를 해야 하고 예전 클릭 시점을 저장해 놓는 등 별도의 시간· 공간 오버헤드가 필요하기 때문에 운영체제는 이걸 원하는 윈도우에다가만 더블클릭 메시지를 전해 주고 있다. 더블로 모자라서 트리플 클릭이라도 인식하려면 역시 사용자가 상태 전환 로직을 직접 구현하는 게 필수일 게다.

메뉴의 경우 마우스의 클릭에 따라 열렸다가 닫히는 게 토글되는 물건이다. 더블클릭에 따른 동작 구분이 필요하지는 않지만, 보통은 더블클릭 때는 열렸던 메뉴가 닫히지 않게 만들어져 있다. 지금 당장 XP~7의 운영체제의 시작 메뉴를 눌러 보시기 바란다. 초보자들은 더블클릭을 할 필요가 없는 물건도 불필요하게 더블클릭하는 경향이 있기 때문에 더블클릭은 클릭+클릭으로 인식하지 않고 메뉴를 닫는 동작으로 인식하지 않는다.

물론 이런 정책은 진짜로 시도 때도 없이 짧은 간격의 클릭 연타를 인식해야 하는 게임 같은 데서는 절대로 적용해서는 안 될 것이다. 정반대의 정책을 취해야 한다.

CS_VREDRAW, CS_HREDRAW
일반적으로 창의 크기가 예전보다 커지면 커져서 새로 생긴 오른쪽 내지 아래쪽의 신규 영역에 대해서만 WM_PAINT가 날아온다. 그러나 이 옵션이 적용되면 가로 and/or 세로 크기가 바뀌었을 때 창 전체가 갱신되고 WM_PAINT가 날아온다.

화면에 문자열이 가로 내지 세로 기준으로 중앙 정렬되어 출력된다거나, 화면 폭에 따라 자동 줄바꿈이 적용되어 출력되고 있다면 화면 크기가 바뀌었을 때 화면 전체가 갱신되어야 할 것이다. 동일 배율의 2차원 비트맵을 찍는 경우가 아닌 이상, 화면 전체의 갱신이 필요한 상황은 생각보다 많다.

하지만 그럼에도 불구하고 이 옵션은 생각만치 그렇게 독창적이거나 유용하지 않다. WM_SIZE 메시지가 왔을 때 InvalidateRect를 수동으로 호출하는 것만으로도 동일한 효과를 낼 수 있기 때문이다.

CS_NOCLOSE
바로 얼마 전에 쓴 글에서 다루었듯이, 창에 [X] 버튼과 Alt+F4를 사용할 수 없게 만든다.
그러나 이것은 (1) GetSystemMenu를 이용해서 시스템 메뉴에 있는 '닫기' 명령을 없애거나 disable시키고, (2) WM_CLOSE 메시지가 왔을 때 이를 무시하여 DefWindowProc에다 전달하지 않으면 클래스 스타일 없이도 역시 거의 똑같은 효과를 얻을 수 있다.

3. 외형/성능과 관련된 마이너한 차이

CS_SAVEBITS
창이 생겼을 때 우리 창이 가리고 있는 배경 영역을 저장해 둔다. 그리고 우리 창이 사라지면 아래의 가려졌던 창에다가 WM_PAINT를 보내는 게 아니라 그냥 저장된 놈을 도로 뿌려 준다. 언제나 무조건 그렇게 하라는 뜻이 아니며 어지간한 비디오 메모리가 남아 있고 할 만하다 싶을 때만 그렇게 하라는 권장 사항이다.

이 스타일을 사용하는 윈도우는 크기가 작고 생성된 후에 이동하지 않으며, 잠깐 동안만 존재했다가 곧 없어지는 휘발성 강한 용도인 게 바람직하다. 툴팁, 메뉴 같은 윈도우의 클래스에 이 옵션이 지정돼 있다. 우리 코드의 동작 방식을 바꾸는 스타일이 아니기 때문에 존재감이 적다.

Windows Vista와 7의 Aero에서는 어차피 모든 창들의 내용이 메모리에 따로 저장되어 있고 DWM에 의해 합성되어서 출력되기 때문에 이 스타일의 존재감이 없는 거나 마찬가지다. 큼직한 창이 가려졌다가 다시 나왔는데도 예전 내용이 알아서 자동으로 출력되지 WM_PAINT가 오지 않는다니..! Vista가 출시되었을 때, Windows의 역사상 최초로 벌어지는 광경에 놀란 개발자들이 많았을 것이다.

CS_DROPSHADOW
Windows XP에서 최초로 도입된 이 스타일은 창 주변에 은은한 그림자 효과를 넣는다. Windows 2000에서는 마우스 포인터의 주변에 은은한 그림자를 넣는 효과가 추가되었는데, 동일한 알고리즘이 이제 임의의 창에도 적용된 것이다.
용도면에서 앞의 CS_SAVEBITS와 비슷한 구석이 있는지라, Windows XP부터는 툴팁과 메뉴에 이 스타일이 적용돼 있다.

시스템 메뉴와 뼈대가 갖춰진 일반적인 창에도 적용을 못 하는 건 아니지만, Aero 환경에서는 어차피 자체적으로 창 테두리 주변에 큼직한 그림자 효과가 추가되어 있기 때문에 이 클래스 스타일이 딱히 유효하지 않다.
또한 Aero 없는 모드에서는 그림자가 붙은 커다란 창은, 움직이거나 크기를 조절할 때 화면을 다시 칠하는 부담이 굉장히 커진다.

4. DC의 생성 방식과 관련된 이상한 옵션

Windows에서는 GDI API를 이용하여 화면에다 그림을 그리려면 먼저 device context라고 불리는 DC 핸들을 얻어 와야 하는 게 정석이다. 보통은 WM_PAINT 메시지가 왔을 때 BeginPaint 함수를 이용하여 얻으면 되는데, 다른 상황에서도 GetDC를 호출해서 얻을 수 있긴 하다. 그러나 BeginPaint는 딱 정확하게 칠해야 하는 영역에만 클리핑 영역이 최적화된 DC를 넘겨 주기 때문에 성능을 생각한다면 전자만을 이용하는 게 더 좋다.

윈도우와 이 DC 사이의 대응 관계는 생각보다 미묘하다. 일반적으로 시스템에 존재하는 창의 개수보다는 운영체제가 관리하는 화면용 DC의 개수가 더 적다. 솔직히 어떤 창이든 하드웨어 차원에서는 동일· 단일한 비디오 메모리에다 출력되는 것이니 동시 요청이 아닌 이상 DC가 굳이 많이 있어야 할 필요가 없다. 이 DC는 그때 그때 내부 상태가 초기화되고 클리핑 영역만 바뀐 채 재활용된다.

그런데.. CS_OWNDC가 지정되면 이 스타일이 적용된 클래스의 모든 창별로 별도의 전용 DC가 할당된다. 이는 프로그래밍 패러다임을 크게 바꿔 놓는다.
GetDC를 아무리 여러 번 호출해도, 그리고 BeginPaint를 호출해도 돌아오는 화면용 DC 핸들은 동일하며, 이 DC는 다른 윈도우에서는 쓰이지 않는다.

이 DC는 생명 주기가 자기가 소속된 윈도우와 동일하다. 그렇기 때문에 그림을 그려 준 뒤 GetDC 다음에 ReleaseDC를 하지 않아도 된다. 그리고 한 WM_PAINT 타이밍 때 지정했던 내부 상태가 다음 WM_PAINT때도 고스란히 보존되어 있다. 글자색, current positon, 선택되어 있는 GDI 개체들이 모조리..

통상적으로 해야 하는 초기화나 뒷정리가 필요하지 않으니 일면 편리한 점도 있지만, 이것은 생각보다 그리 큰 장점이 아니다.
그에 반해 윈도우 하나가 생길 때마다 수백 바이트에 달하는 전용 DC가 추가로 생성되는 것은 운영체제의 입장에서는 상당한 부담이었다. 특히나 16비트 시절에는 리소스라고 불리던 GDI 힙의 크기가 겨우 64K밖에 안 됐는데 이건 그야말로 리소스 잡아먹는 하마나 마찬가지였으며 심지어 윈도 9x에서도 상황이 크게 나아지지 않았다.

이 때문에 이 옵션은 존재는 하되 사용이 절대로 권장되지 않는 물건으로 전락했다.
CS_CLASSDC는 CS_OWNDC보다 메모리를 좀 아껴 보자는 발상에서 유래되었는데, 한 전용 DC를 동일 클래스에 소속된 모든 윈도우들이 공유하는 방식이다. 한 윈도우가 글자색을 빨간색으로 바꿔 놓으면, 다음에 그려지는 같은 윈도우는 기본적으로 글자가 빨간색으로 찍힌다. 이것도 기괴한 사고방식이긴 하다.

요건 GDI 자원을 좀 아낄 수 있을지는 모르나 '전용 DC'라는 장점이 사라지는 상태에서 멀티스레드 환경에서는 상당히 위험한 결과를 초래할 가능성이 있기 때문에 32비트 이후에서는 단점만 더욱 부각되었으며, 역시 봉인된 옵션으로 전락했다. 이런 게 있다는 것 정도만 알면 된다.

다음으로 CS_PARENTDC는 위의 두 옵션과는 성격이 약간 다르고 약간 더 실용성이 있다. 자기를 그릴 때 부모 윈도우의 기존 DC를 활용해도 좋다고 알려 준다. 좀 더 구체적으로 말하자면 굳이 클리핑 영역을 자기 윈도우로 맞추지 않아도 된다고 알려 준다.

대화상자에 아기자기한 컨트롤이 굉장히 많이 있는데 그 컨트롤들이 CS_PARENTDC 스타일이 맞춰져 있다면 대화상자의 그리기 속도가 약간이나마 향상될 수 있다. 자신이 클리핑 기능 없이도 알아서 자기 클라이언트 영역을 안 벗어나고 똑똑하게 그림을 그릴 자신이 있다면 이 스타일을 사용하는 게 나쁘지 않으며, 실제로 운영체제의 표준 컨트롤들은 다른 잉여스러운 옵션 말고 이 옵션은 사용한다고 한다.

다만, 이런 꼼수를 허용하는 스타일이 존재하는 경우, layered 윈도우나 drop shadow 같은 특수 효과와는 충돌이 발생할 수 있으니 사용 전에 MSDN 설명을 참고하는 게 좋다. 요즘 같이 메모리와 성능이 풍족한 시대엔 그냥 저런 기괴한 옵션들은 다 잊어버리고 그냥 0으로만 지정해도 무관하다.

5. Windows 1~2.x 시절에나 유효하던 완전 캐잉여: CS_BYTEALIGNCLIENT, CS_BYTEALIGNWINDOW

이것은.. 거의 20년 이상 전부터 전혀 쓸모가 없어진 옛날 잔재이다.
잘 알다시피 옛날에는 컴퓨터 화면이 흑백이던 시절이 있었고 이때는 1바이트가 8비트, 즉 8개의 가로 픽셀을 담당했었다.

그러니 이 스타일은 창의 꼭지점 위치(외곽 모서리 또는 클라이언트 모서리 기준)를 강제로 8 또는 최소한 4의 배수 위치로 맞춰서 그림을 찍는 게 바이트 경계에 딱 걸쳐지는 게 보장되게 하는 역할을 했다.
당연히 256컬러, 혹은 16컬러가 지원된 시점부터 모든 픽셀은 자동으로 이미 바이트 align이 맞춰지기 시작했으며 이 옵션은 전혀 필요가 없어졌다.

또한 Windows 3.0부터는 영문이 가변폭 글꼴로 출력되기 시작한지라 그렇잖아도 글자를 찍을 때 어차피 바이트 align이 무의미해지기도 했다.
지금쯤이면 이 스타일이 갖던 값은 그냥 다른 용도로 재사용해 버려도 되지 않나 싶다. 하지만 extended 스타일까지 존재하는 윈도우와는 달리, 클래스에는 스타일이 그렇게 다양하게 많이 추가될 여지도 별로 없긴 하다.

Windows API를 심층 연구하는 건 재미있다. ^^;;

Posted by 사무엘

2014/02/26 19:27 2014/02/26 19:27
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/935

자, 오늘은 아주 간단한 Windows API 프로그래밍 퀴즈를 하나 내겠다.
다음과 같은 창을 만들려면 어떻게 해야 할까? (닫기 X 버튼이 사용 불가)

사용자 삽입 이미지

닫기 버튼 말고 최소화 및 최대화 버튼이야 윈도우의 스타일이라는 형태로 지정 가능하다.
WS_MINIMIZE/WS_MAXIMIZE와 WS_MINIMIZEBOX/WS_MAXIMIZEBOX가 있는데, BOX가 붙은 비트는 이 창에 해당 버튼과 기능을 제공하라는 뜻이다. 그리고 BOX가 없는 비트는 이 창이 현재 실제로 최소화됐거나 최대화돼 있음을 나타낸다.

즉, 프로그램이 지정하는 속성 정보와, 사용자가 변경하는 상태 정보가 비트값만 달리하여 동일 스타일에 한데 담겨 있다. 이건 개인적으로는 좀 이상한 설계라고 생각한다. 뭐 그건 그렇고...

그런데 닫기 버튼은 이런 스타일의 형태로 존재하지 않는다.
사실, UI 디자인 상으로도 응용 프로그램은 사용자에게 뭔가 강압적인 요소를 가능한 한 만들지 않아야 하며, 모든 창은 사용자가 언제라도 닫을 수 있어야 한다. [X] 버튼이 없는 창을 접할 일은 극히 드물다. 이는 오늘날처럼 언제라도 task switch가 가능한 선점형 멀티태스킹 환경에서는 더욱 그러하다.

창에 시스템 메뉴 자체를 완전히 없애서 [X]버튼을 없애는 것 말고 저렇게 [X] 버튼을 disable만 시키는 간단한 방법은 시스템 메뉴에서 SC_CLOSE를 없애거나 disable시키는 것이다. 창의 WM_CREATE 메시지에서 이렇게 해 주면 된다.

HMENU h = ::GetSystemMenu(hWnd, FALSE);
::RemoveMenu(h, SC_CLOSE, MF_BYCOMMAND);

요렇게 해 주면 캡션에 달린 [X]버튼도 같이 영향을 받게 된다. [X]버튼뿐만 아니라 시스템 메뉴를 더블클릭해도 창이 닫히지 않는다.

그런데, 외형상 닫기 버튼을 없애는 것은 마우스를 통한 닫기 동작을 차단해 주는 반면, 키보드 Alt+F4를 차단하지는 못한다.
물론, 이런 메시지가 왔을 때 닫는 반응을 안 하도록 WM_CLOSE 메시지나 IDCANCEL을 차단하는 식으로 별도의 처리를 할 수도 있지만, 운영체제 차원에서 창을 닫으려는 시도를 원천차단하는 방법은 따로 있다.

이것은 윈도우의 스타일에 있는 게 아니라, 윈도우 클래스의 스타일에 있다.
바로 CS_NOCLOSE 되시겠다.
아무 창에나 쉽게 쓰이는 속성이 아니라고 판단되었는지 윈도우의 스타일이 아니라 클래스의 스타일로 분류되었다. 뭐, 역사적으로는 [X] 버튼 자체가 윈도 95/NT에서 처음 등장한 것이기 때문에 최소화/최대화 버튼하고는 API가 들어갈 위치가 다르기도 했고 말이다.

윈도우 클래스를 등록할 때 저 스타일을 준 윈도우는 윈도우 프로시저에서 WM_CREATE 때 시스템 메뉴 조작 같은 걸 하지 않아도 시스템 메뉴에 '닫기' 명령이 등재되지 않으며, [X] 버튼이 자동으로 흐리게 표시된다. 그리고 Alt+F4를 눌러도 자동으로 닫히지 않는다.
응용 프로그램이 직접 제공하는 '종료' 명령으로 WM_CLOSE 메시지를 날려 줘야만 닫을 수 있다. 아니면 프로세스를 강제로 죽이든가.

MDI 차일드 윈도우도 이런 스타일이 지정된 클래스에 소속된 놈으로 지정할 수 있다. 그렇기 때문에 MDI 창들 중에도 절대로 닫히지 않고 언제나 떠 있어야 하는 고정 붙박이 윈도우는 요렇게 따로 배치하는 게 가능하다.

화면을 다 차지한 채 Z-순서가 바뀌지도 않고(WS_EX_TOPMOST) 닫히지도 않는 창이 떠 있다면, 거기에다 키보드/마우스/메시지 훅만 추가해서 다른 프로그램으로 작업 전환도 되지 않게 해서 포커스를 특정 프로그램이 사실상 독점할 수도 있다. 특정 프로그램만 뜬 채로 통제를 벗어나지 않아야 하는 공공장소의 특수 목적 PC에서 돌아가는 프로그램은 이런 기능을 활용하면 만들 수 있을 듯하다.

16비트 윈도 시절에는 특정 프로그램이 시스템의 자원을 독점하기가 훨씬 더 쉬웠고 그때는 그냥 modal이 아니라 system modal이라는 기능이 버젓이 존재했다. 이 창을 닫기 전에는 아예 다른 프로그램으로 Alt+Tab 작업 전환도 안 되는 거다.

물론 이런 강압적인 기능은 32비트 이후부터는 공식적으로 삭제되었지만 이것의 영향을 받았는지 윈도 NT 계열과는 달리 9x 계열은 메시지 대화상자에도 그 잔재가 여전히 남아 있었다. 취소 버튼이 없이 '확인'만 있는 메시지 박스는 시스템 메뉴에 '닫기'가 존재하지 않았으며 [X] 버튼이 클릭 가능하지 않았다. 단, 그래도 키보드의 ESC나 Alt+F4는 동작한다.

사용자 삽입 이미지


Posted by 사무엘

2014/02/07 08:38 2014/02/07 08:38
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/928

cursor/caret 이야기

기왕 말이 나온 김에 또 문자 입력과 관련된 사용자 인터페이스 얘기를 좀 계속해 보자.

글자 입력란에서 깜빡거리고 있는 길쭉한 세로줄(|)을 우리는 보통 '커서'라고 부르고 영어로 cursor이라고 한다.
그러나 이 명칭은 우리말로는 용언 '크다'의 활용형으로 보여서 보기가 안 좋고, 영어로는 마우스 포인터조차 cursor이라고 부르는 경우가 있다. 실제로 Windows API에서 사용되는 LoadCursor, ShowCursor 같은 단어는 전부 마우스 포인터를 가리키며, 내부 공식 용어는 캐럿(caret)이다. 함수명도 ShowCaret, HideCaret따위다.
용어가 대단히 혼란스럽다는 점을 인정하지 않을 수 없다. 이 글에서는 편의상 그냥 cursor이라고 적도록 하겠다.

텍스트 모드가 존재하던 도스 시절에는 이 cursor가 반각 폭을 차지하는 밑줄 모양(_)이었다. 그리고 일부 환경에서는 겹침 모드일 때는 cursor가 약간 두툼해지곤 했다. 그 일부 환경 중의 하나로는 GWBASIC의 대화식 환경도 포함돼 있다.
그때도 cursor를 보이게 하거나 감추는 도스 API가 있었다. 그리고 심지어 cursor의 굵기를 바꾸는 기능도 있어서 옛날 노턴 유틸리티의 구성원 중 하나이던 NCC(Norton Control Center)라는 프로그램을 통해 변경을 할 수 있었다.

그러고 보니 정말 옛날이구나.
NCC의 스크린샷이 궁금했는데 구글을 뒤져도 관련 그림 하나 찾을 수 없을 정도로 완전히 역사 속으로 묻혀 버렸다.
얘는 cursor 모양을 포함해서 키보드와 마우스의 속도를 바꾸는 액세서리 기능도 있었다.
지금은 Windows의 제어판을 통해서 키보드의 속도를 바꾸지만 도스 시절에는 외부 명령인 MODE CON을 이용하거나 별도의 그런 유틸리티를 썼다. 그런 프로그램들 역시 내부적으로는 도스 API를 호출하는 형태였겠지만 말이다.

GUI 기반인 Windows에도 cursor는 응당 존재한다.
기술적으로 볼 때 cursor는 특정 시간 간격으로 운영체제가 DC에다 비트맵을 XOR이라는 래스터 연산을 적용하여 그려 주는 동작일 뿐이다. WM_CREATE 때 cursor를 생성하고, WM_DESTROY 때 파괴한다. 그리고 WM_SETFOCUS 때 화면에 표시를 해 주고 WM_KILLFOCUS 때 감춰 주면 된다.

숨김/감춤 요청이 교대가 아니라 중첩해서 발생할 경우, 운영체제는 일종의 reference counting을 해 준다.
하지만 개인적으로는 창이 WM_SETFOCUS와 WM_KILLFOCUS에 대한 처리를 운영체제가 자동으로 하게 API를 설계하는 게 더 나았을 거라는 생각을 한다. 언제나 단 한 프로그램에서만 cursor가 깜빡이는 게 보장되도록 말이다.

cursor만을 위해 문서화되지 않은 전용 타이머 메시지가 쓰인다는 것은 Spy++ 같은 프로그램을 통해 이미 아는 개발자들이 많을 것이다. 0x118인데, 편의상 흔히 WM_SYSTIMER라고 이름을 붙이는 듯하다.

한글을 조합 중일 때 cursor가 조합 중인 한글 전체를 감싸며 깜빡이는 것은, 도스 시절의 자체한글 프로그램들로부터 전해지던 전통이다. 나름 우리나라에서만 볼 수 있는 관행인데 MS가 로컬라이즈 차원에서 이런 시각 피드백을 Windows에다가도 적극 도입했다. MS 워드 6.0이 이를 첫 지원했으며 Windows 95때부터 운영체제의 에디트 컨트롤까지 지원이 확대되었다.
그냥 일본어/중국어를 입력할 때처럼 조합 중인 한글을 대충 밑줄로 표시하는 걸로 때워도 됐을 텐데 이를 특별히 배려한 것이다. Windows 3.x 내지 맥 OS에서는 깜빡이는 네모 cursor를 볼 수 없다.

과거에 훈민정음 워드 프로세서는 한글 모드일 때 cursor가 흰색 배경에 대해서 붉은색으로 변하곤 했다.
그리고 MS 오피스 2010은 수평이 아닌 임의의 각도로 기울어진 텍스트 상자에 글을 입력할 때... 입력란도 실제로 그 기울어진 각도를 반영하여 동작하는 직관적인 UI를 구현해 냈다. 이때 cursor도 당연히 기울어진 상태로 나타난다. 이런 cursor는 어떻게 만들었을까?

사용자 삽입 이미지

이것들도 다 CreateCaret 함수에서 크기만 달랑 지정하는 게 아니라 비트맵을 지정해 줌으로써 구현 가능하다.
비트맵 인자로 NULL을 넣으면 해당 영역의 모든 비트맵의 비트가 1이어서 전체 영역이 반전된다. 즉 InvertRect 함수를 호출하는 것과 동일한 효과가 난다.
그리고 MSDN에서 볼 수 있듯이, (HBITMAP)1을 집어넣어 주면 비트 0과 비트 1이 번갈아가며 나타나는 그 50% gray가 지정된다.

이와 같은 맥락으로, 옥색으로 채워진 비트맵을 지정하면 흰색 바탕에서는 보색인 빨강 cursor가 나타나며
검정 배경에 기울어진 흰색 사각형 모양의 비트맵을 지정하면 기울어진 cursor도 만들 수 있다.
요컨대 운영체제의 caret은 무조건 직교좌표계를 따르는 직사각형만 가능한 게 아니다.
임의의 비트맵과 XOR 연산을 하는 형태로 구현되기 때문에 임의의 모양의 cursor를 만들 수 있다.

다만, 별도의 마스크 비트맵이 존재하지 않기 때문에 마우스 포인터나 아이콘 같은 완전히 opaque한 스프라이트를 깜빡이게 할 수는 없으며, 알파채널 같은 걸 줄 수 없을 뿐이다. 그런 효과를 만들려면 프로그래머가 직접 cursor의 깜빡임을 타이머를 써서 구현해야 할 것이다.

Posted by 사무엘

2014/01/29 19:44 2014/01/29 19:44
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/925

지금 여러분의 PC에는 비트맵 그래픽 에디터로 무엇이 설치되어 있는가?
포토샵, 페인트샵, 페인트 닷넷, 심지어 그림판, 비주얼 스튜디오가 자체 제공하는 그래픽 에디터 등등...
이런 것들을 떠올리면서 각 프로그램들이 텍스트를 삽입하는 텍스트 도구가 어떤 형태로 구현되어 있는지 생각해 보시기 바란다.

보통은 텍스트 도구를 실행하면 텍스트를 삽입할 지점 내지 영역을 지정할 수 있고, 그 뒤에는 어지간해서는 텍스트 입력란이 별도의 대화상자나 창을 통해서 뜨게 된다.
그런데 Windows가 기본 제공하는 그림판은 다소 참신하게 설계되어 있다.

사용자 삽입 이미지

텍스트를 입력받는 영역이 그림 내부에 일체형으로 생긴다. 그림 내부에 cursor가 생겨서 텍스트를 곧바로 입력할 수 있으며 심지어 블록까지 잡을 수도 있는데,
일괄적인 단색이 아니라 기존 그림이 그대로 배경에 깔린다. 즉, 텍스트를 입력했다가 지우면 원래 그림이 도로 보존된다는 뜻이다. 별로 깜빡거리는 현상도 없다. 게다가 윈도 95 시절부터 그림판은 이렇게 동작해 오고 있었다. 참고로 페인트 닷넷이나 과거 윈도 3.1 시절의 페인트는 텍스트가 그림에 바로 삽입은 되지만, 블록까지 잡을 수는 없다.

이건 보통일이 아님을 알 수 있다. 아무래도 운영체제의 일반 에디트 컨트롤로는 불가능한 일인 것 같다.
WS_EX_TRANSPARENT라는 스타일이 있고 자체적으로 배경을 지우지 않게 WM_ERASEBKGND 메시지를 서브클래싱한다 해도, 일단 글자에 가려졌던 배경을 깜빡거림 없이 지능적으로 복구하는 일은 해당 컨트롤이 알아서 해 줘야 하기 때문이다.

Spy++로 살펴보면, 텍스트를 입력받는 동안엔 그림 클라이언트 영역 내부에 리치 에디트 컨트롤이 하나 생기긴 한다.
잘은 모르겠지만 얘는 일반 에디트 컨트롤보다 기능이 더 많고 전문적인 만큼, 옵션을 줌으로써 투명하게 동작하는 것에 대비되어 있는 게 아닌가 싶다.

과거의 그림판은 글꼴이나 크기, 색깔을 바꾸면 그게 모든 텍스트에 일괄 적용되었다. 하지만 7의 그림판은 리치 에디트답게 속성을 글자별로 다 따로 줄 수 있다. 뭐, 일괄 적용되던 시절에도 어차피 리치 에디트 기반인 건 동일했으니 그건 단순히 개발 난이도를 낮추기 위해 사용되었던 정책인 것 같다. 그래픽 에디터는 전문적인 텍스트 에디터가 아니니까 말이다.

상황을 좀 더 일반화해서 생각해 보자.
사실, GUI 위젯의 구성요소로는 각종 버튼들, 리스트 박스, 콤보 박스 등 여러 물건들이 있는데,
그 중 기술적으로 가장 만들기 힘든 것은 단연 에디트 컨트롤이다.
키보드 입력을 가장 정교하게 처리해야 하고, 텍스트의 변경으로 인해 텍스트의 전체 레이아웃이 바뀌는 것을 그때 그때 처리해야 하며 그러면서 화면상으로 바뀐 부분만 다시 그리거나 스크롤해 줘야 한다.

에디트 컨트롤을 만들어야 하는데 이런 어렵고 복잡한 내부 처리는 다른 컴포넌트에다 맡기고, 주어진 레이아웃대로 화면에 글자를 출력하는 것만 사용자가 customize할 수는 없을까?

예를 들어서 게임을 만들 때 말이다. 채팅창이 있는데 글자는 그림자 같은 일반적인 리치 에디트 포맷에 없는 특수한 효과가 적용되고, 배경으로는 게임 배경 화면이 알파 채널로 겹쳐진다. 이런 그래픽 출력을 일반 윈도우 DC를 이용해서 할 수는 없는 노릇이다.

이런 경우, 별 수 없이 게임 내부의 GUI 라이브러리를 개발하는 사람이 야메로 에디트 컨트롤을 직접 구현한다.
직접 만들면 세세한 제어가 가능하니 속 편한 경우도 있지만, 외국 시장까지 생각했을 때 아무래도 높은 완성도를 기대하기 어렵다. 중국어· 일본어 IME의 시각 피드백을 출력한다거나 아랍어가 뒤섞인 텍스트를 제대로 처리하는 에디트 컨트롤을 혼자 다 만든다는 건 불가능하며 그럴 필요도 없다.

본인이 개발한 <날개셋> 타자연습에도 기술적으로 완전 구닥다리이긴 하지만 그래도 DirectDraw surface를 만들어서 동작하는 게임이 있다.
내 원래 계획은 입력 중인 글자는 게임 배경에 같이 오버랩되어 표시되는 것이었다.
하지만 그것까지 구현하는 게 어려워서 그냥 화면 하단에 날개셋 에디트 컨트롤을 때려박아 넣는 형태로 프로그램이 만들어졌다. 에디트 컨트롤의 내부 알고리즘이 내린 지시를 custom 출력 매체에다 효과적으로 임베딩하는 방법이 필요하다.

이런 생각을 마소의 개발자가 안 했을 리가 없다.
그래서 Windowless Rich Edit Control이라는 게 있다. 리치 에디트 컨트롤의 내부 알고리즘을 COM 객체 형태로 만든 것이다. 얘를 이용하면 굳이 독립된 윈도우를 만들지 않고도 리치 에디트 컨트롤처럼 동작하는 객체를 손쉽게 구현할 수 있다.

물론, 스펙을 보면 알겠지만 우리 쪽에서 처리해야 할 요청이 한두 개가 아닌 관계로, 마냥 쉽게만 사용할 수 있는 물건은 아닐 수도 있다.
우리는 ITextHost라는 인터페이스를 구현하여 “어디에다 cursor를 만들어라, 무슨 크기를 얻어 와라” 같은 요청를 처리하면 되고, 운영체제의 기본 서비스가 필요하면 ITextServices 인터페이스를 호출하면 된다. 이들 객체는 CreateTextServices 함수를 통해 주고받으면 된다.

본인은 그렇잖아도 문자 입력과 관련된 프로그래밍 경험이 많은 관계로, 운영체제에 이런 API가 있는 것은 진작부터 알고 있었고, 이걸 실전에서 활용도 몇 차례 해 봤다. 단, 정작 그림판은 이런 windowless 오브젝트를 사용한 게 아니라 내부에 특수 처리된 리치 에디트 컨트롤 윈도우를 직접 생성했다는 게 의외로 놀랍다.
text services라는 단어 자체는 이 때부터 있었던 셈이다. 그러니 IME를 대체하는 Windows의 차세대 문자 입력 프로토콜이 text services framework, 즉 TSF라고 명명된 것은 우연이 아니라 하겠다.

Posted by 사무엘

2014/01/26 19:31 2014/01/26 19:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/924

« Previous : 1 : ... 12 : 13 : 14 : 15 : 16 : 17 : 18 : 19 : 20 : ... 29 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2022/01   »
            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:
1733923
Today:
120
Yesterday:
563