1년 반동안 방치해 오던 프로젝트를 오랜만에 업데이트했다. 그동안 버그도 몇 개 발견되었고 많지는 않지만 몇몇 사용자분들께서 개선 사항을 지적해 주어 치명적인 몇 가지만 수정했다. 자주 신경쓰고 싶지만 그간 닷넷 프로그래밍 정복이라는 책을 저술하고 먹고 살기 위해 프로젝트 몇 건 뛰고 하다 보니 도저히 시간을 낼 수가 없었다. 2008년 3월 1일 현재 원고를 출판사로 넘기고 교정본이 오기를 기다리는 동안 잠시 짬이 나서 작업 시간을 확보하였다.
막상 작업해 보면 하루 이틀 일거리밖에 안되는 것을 보면 시간이 없다는 말은 언제나 핑계에 불과하다. 시간이 없다기 보다는 솔직히 경황이 없었고 다른 데 신경을 쓰다 보면 프로젝트에 소홀해질 수밖에 없는 문제인 것 같다. 머리속에 온통 원고만 들어 있는 상태에서는 코드가 비집고 들어갈 자리가 없는 것이다. 당근 1.20의 소스(Dangeun29)를 다운로드받은 상태에서 다음 순서대로 프로젝트를 수정하면 1.21이 만들어진다. 너무 상세한 문서화는 하지 않고 작업 과정을 간략하게 기록으로 남기기만 한다.
비주얼 스튜디오가 드디어 2008로 업그레이드되었다. 새 컴파일러가 나왔으니 프로젝트도 컴파일러에 맞게 변환하는 것이 마땅할 것이다. 비주얼 스튜디오를 실행해 놓고 당근의 솔루션 파일을 열면 변환 마법사가 나타난다. 이전 버전과 솔루션 파일이 호환되지 않으므로 변환하라는 뜻인데 지시대로 변환하면 된다. 단, 이전 버전의 소스는 따로 있으므로 백업은 하지 않았다.
변환 직후 컴파일하면 하나의 경고와 여러 개의 에러가 발생한다. 아무리 잘 짜여진 소스도 컴파일러가 바뀌면 어느 정도의 문제점은 있기 마련인데 당근의 경우는 그래도 비교적 양호한 편이다. 먼저 제일 첫 줄의 경고부터 수정해 보자. 경고가 발생한 줄은 ToolBar.cpp의 SetStatusText 함수 내부에 있는 다음 코드이다.
if (mask & (1 << 2+1)) {
경고의 내용은 << 연산자와 + 연산자의 우선 순위가 모호해 보여 잠재적인 문제가 발생할 수 있다는 뜻이다. 이 문장은 다음 두 가지 경우로 생각할 수 있어 약간 모호해 보인다.
if (mask & ((1 << 2)+1)) {
if (mask & (1 << (2+1))) {
전자는 1을 두 칸 민 후 1을 더하라는 뜻이고 후자는 1을 세칸 밀어라는 뜻이므로 연산 결과가 달라진다. 그러나 사실 이 문장은 문법적으로 전혀 모호하지 않다. 연산 순위표를 보면 +가 4위이고 <<가 5위이므로 1을 세칸 밀면 된다. 설사 우선 순위가 같더라도 결합 순서가 왼쪽 우선이므로 에러로 처리될 문장은 아니다.
하지만 보는 사람에 따라 헷갈릴 소지가 있으므로 괄호를 분명히 싸서 명확하게 지정하라는 권고를 하는 것이다. 문법상 아무 문제가 없는 문장임에도 가급적 읽기 쉬운 소스를 만들라는 의도로 이해하면 된다. 비주얼 스튜디오가 갈수록 잔소리가 심해지는 것 같은데 이 경고에 대한 잔소리는 합당한 것 같다. 이 경우는 후자가 맞으므로 경고 방지를 위해 2+1을 괄호로 싸주면 된다.
에러는 여러 개가 생기는데 모두 타겟 윈도우즈의 버전이 맞지 않아서 발생한 것이다. 다중 모니터가 NT 5.0 즉 윈도우즈 2000부터 지원되었으므로 HMONITOR 식별자가 0x500 이상일 때만 정의된다. 이전 버전에서는 플랫폼 SDK만 깔면 이 식별자를 정의했었으나 좀 더 버전 관리가 엄격해졌다. stdafx.h에 다음 선언문을 추가한다.
#define _WIN32_WINNT 0x400
#define _WIN32_WINDOWS 0x401
#define WINVER 0x500
WINVER 매크로가 0x500으로 정의되었으므로 당근은 윈도우즈 2000 이상에서만 정상적으로 실행될 것이다. 그렇다고 해서 98에서 실행되지 않는다는 뜻은 아니고 다중 모니터 기능이 제대로 동작하지 않는다. 이제 컴파일해 보면 에러와 경고없이 잘 컴파일된다. 그러나 막상 실행해 보면 버퍼 오버런이 발생한다. 이대로도 실행은 가능하지만 문제가 발생했으므로 원인을 분석하고 해결해야 한다. 오버런이 발생한 위치는 Dangeun.cpp의 훅 프로시저이다.
LRESULT CALLBACK DgCbtHookProc(int nCode,WPARAM wParam,LPARAM lParam)
{
CBT_CREATEWND *pCbt;
HWND hWnd;
TCHAR szClassName[128];
WNDPROC OldProc;
szClassName 버퍼가 크기 32로 선언되어 있었는데 윈도우 클래스명이 32를 넘는 경우가 있어 스택이 침범을 당한 것이다. 이전에는 윈도우 클래스명이 32자면 비교적 충분했는데 최근 닷넷 윈도우들은 윈도우 클래스명으로 GUID를 쓰기 때문에 32자로는 부족해졌다. 버퍼 크기를 128로 충분히 늘려주면 문제가 해결된다.
컴파일러가 이런 잠재적인 문제까지 지적해 준다는 점은 상당히 감동스럽다. 사실 이 버그를 무시하고 계속 실행해도 돌아는 간다. 하지만 메모리가 깨지면 언제 어디서 잘못될 지 알 수 없으므로 문제를 알고 있다면 바로 수정해야 한다. 이 부분 외에도 당근에는 정적 버퍼를 쓰는 곳이 많이 있는데 이런 부분들이 언제 말썽을 일으킬지는 알 수 없다. 그러고 보면 정적 버퍼는 정말 위험한 것이고 본질적으로 C의 배열 자체가 위험하다. 자동적으로 메모리를 관리하는 닷넷이나 자바가 부러운 대목이다.
당근 1.20에는 비스타에서 한글 모드로 전환되지 않는 문제가 있다. 애초에 영문으로만 입력되며 한글 IME 자체가 나타나지 않는다. 한글을 전혀 쓸 수 없으니 아주 치명적인 문제이다. XP에서는 모든 것이 잘 돌아가는데 유독 비스타에서만 한글 전환이 안되었다. 최초 이 버그를 목격했을 때 IME 메시지 시스템에 변화가 생긴 것으로 추측했으나 원인은 바로 위에서 수정한 버퍼 오버런이었다.
스택을 깨 먹었으니 언제 어떤 사고가 발생할 지 예측하기 힘든 것이다. 아뭏든 이제 비스타에서도 한글 전환이 잘 된다. 아마 이 버퍼 오버런으로 인해 다른 곳에서도 문제가 발생하는 경우가 더 있었을 것이다. 똑같은 문제가 있음에도 운영체제가 달라지면 그 문제가 보이기도 하고 안 보이기도 한다. 그래서 가급적 많은 환경에서 테스트해봐야 한다.
파일창과 상용구 창의 보기 상태가 제대로 저장되지 않는 문제가 있다. 숨겨도 다시 시작하면 항상 나타나며 폭과 비율을 조정해도 언제나 디폴트로 돌아가 버린다. 레지스트리에 기록하는 코드에 문제가 있는 줄 알았는데 원인은 베타1의 최적화에 있었다. 실행을 종료할 때마다 레지스트리에 불필요하게 저장하지 않음으로써 종료 속도를 높이려는 의도로 옵션창을 열어서 확인 버튼을 누를 때만 저장하도록 최적화를 했었다.
그러나 옵션창을 통하지 않고 조정되는 옵션들도 있다는 것을 간과했던 것이다. 파일창과 상용구창만 문제가 되는 것이 아니라 툴바나 상태란의 보기 상태도 마찬가지이다. 이 옵션들은 메인창에서 바로 조정 가능하므로 옵션 대화상자와는 상관없이 수정되기도 한다. 다행히 MRU나 윈도우 위치는 옵션과 상관없이 저장하는 코드가 따로 작성되어 있었다. 베타1의 최적화를 잠시 정지시키면 문제가 해결된다.
void OnDestroy(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
/*if (Option.bModified)*/ Option.Save(KEY);
if (DgMacro.bModified) DgMacro.SaveToReg(KEY);
if (DgShortCut.bModified) DgShortCut.Save(KEY);
옵션의 수정 여부와 상관없이 무조건 옵션을 저장하도록 수정했다. 매번 레지스트리를 액세스하는 것이 좀 마음에 안들지만 어차피 레지스트리는 운영체제가 캐시하므로 부담없이 액세스하는 것이 더 나은 것 같다. 최적화에 의한 부작용이라고 할 수 있다. 보기 상태가 바뀔 때마다 bModified를 수정하는 것도 해결 방법이기는 하지만 솔직히 체력이 달려서 더 못하겠다.
1.20버전의 가장 큰 문제점은 유니코드 문서를 제대로 지원하지 못한다는 점이다. UTF-16 문서나 BOM 있는 UTF-8 문서는 잘 읽고 쓰지만 BOM이 없는 문서를 제대로 포맷 판별하지 못한다. 최초 개발시에는 BOM 없는 포맷이 비정상이라고 판단했고 빈도도 높지 않았으나 이 포맷이 웹과 XML의 가장 흔한 포맷이다 보니 문제가 되었다. 최근에는 UTF-8로 인코딩된 문서를 흔하게 볼 수 있다. 환경이 바뀐 것이다.
XML 문서를 열면 한글이 깨져 보이고 저장도 제대로 하지 못한다. 문제를 해결하려면 BOM이 없는 UTF-8 문서를 정확하게 판별해야 하는데 이게 그리 간단하지 못하다. 운영체제 차원의 지원이 없으므로 직접 판별 루틴을 만들어 써야 한다. 인터넷을 검색해 보면 이 문제에 대한 질문은 많아도 답변은 없기에 그냥 직접 만들었다. ApiEdit.cpp에 다음 멤버 함수를 추가한다.
BOOL CApiEdit::AnalyzeFormatUtf8(TCHAR *Text, int dwSize)
{
TCHAR *p;
BOOL bFind;
bFind=FALSE;
for (p=Text;p-Text < dwSize;p++) {
if ((*p & 0x80) == 0x80) {
bFind=TRUE;
// 상위 비트가 110이고 다음 문자의 상위 비트가 10이면 UTF8맞음
// p가 문서 끝을 넘거나 중간에 하나라도 규칙에 맞지 않으면 UTF8이 아님
if ((*p & 0xe0) == 0xc0) {
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
continue;
}
// 상위 비트가 1110일 때는 다음 두 문자의 상위 비트가 10이어야 한다.
if ((*p & 0xf0) == 0xe0) {
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
continue;
}
// 상위 비트가 11110일 때는 다음 세 문자의 상위 비트가 10이어야 한다.
if ((*p & 0xf8) == 0xf0) {
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
p++;if (p-Text >= dwSize) return FALSE;
if ((*p & 0xc0) != 0x80) return FALSE;
continue;
}
// 0x80을 넘었는데 상위 비트가 110, 1110, 11110 중 하나가 아니면
// UTF-8 문서가 아니다.
return FALSE;
}
}
// 0x80 넘는 값이 하나도 없으면 ANSI로 취급한다.
if (bFind == FALSE) {
return FALSE;
}
// 0x80을 넘는 모든 값이 UTF-8의 조건을 만족하면 UTF-8문서이다.
return TRUE;
}
판별 원리는 단순하다. 처음부터 끝까지 문자들을 읽으면서 모든 문자가 UTF-8의 인코딩 규칙에 맞는지 확인해 보면 된다. UTF-8은 0x80 미만은 ASCII와 호환되며 그 이상의 코드는 2~4바이트에 나눠 넣되 상위 비트에 고정된 헤더를 배치하므로 이 규칙대로 문자들을 점검하면 된다. 모든 문자가 0x80 미만이거나 그 이상의 코드가 있더라도 규칙에 맞으면 UTF-8문서이다. 앞으로도 재사용할 경우가 있을 것 같아 별도의 함수로 만들어 두었는데 아직 검증까지 마친 것은 아니지만 기본 골격은 이 형태를 크게 벗어나지 않을 것이다. ApiEdit.h에 포맷 매크로 상수들의 값을 조정한다.
#define AE_FORMAT_WIN 0
#define AE_FORMAT_UNIX 1
#define AE_FORMAT_MAC 2
#define AE_FORMAT_UNICODE 3
#define AE_FORMAT_UNIBIG 4
#define AE_FORMAT_UTF8BOM 5
#define AE_FORMAT_UTF8 6
#define AE_FORMAT_BINARY 7
기존의 UTF8을 UTF8BOM으로 이름을 바꾸고 BOM없는 UTF8 포맷을 UTF8이라는 이름으로 정의했다. 중간에 하나가 끼어 들었으므로 BINARY는1 밀리는데 어디까지나 내부적인 포맷 식별자이므로 값이 바뀌어도 상관없다. ConverFormat 함수는 다음과 같이 수정한다.
switch (from) {
....
case AE_FORMAT_UTF8BOM:
// 임시 버퍼에 유니코드로 먼저 변환한다.
need=MultiByteToWideChar(CP_UTF8,0,src+3,srclen-3,NULL,0);
t=(LPWSTR)malloc(need*sizeof(wchar_t));
num=MultiByteToWideChar(CP_UTF8,0,src+3,srclen-3,t,need);
// 유니코드를 안시로 변환한다.
need=WideCharToMultiByte(CP_ACP,0,(LPCWSTR)t,num,NULL,0,0,0);
dest=(TCHAR *)malloc(need);
WideCharToMultiByte(CP_ACP,0,(LPCWSTR)t,num,dest,need,0,0);
free(t);
return need;
case AE_FORMAT_UTF8:
// 임시 버퍼에 유니코드로 먼저 변환한다.
need=MultiByteToWideChar(CP_UTF8,0,src,srclen,NULL,0);
t=(LPWSTR)malloc(need*sizeof(wchar_t));
num=MultiByteToWideChar(CP_UTF8,0,src,srclen,t,need);
// 유니코드를 안시로 변환한다.
need=WideCharToMultiByte(CP_ACP,0,(LPCWSTR)t,num,NULL,0,0,0);
dest=(TCHAR *)malloc(need);
WideCharToMultiByte(CP_ACP,0,(LPCWSTR)t,num,dest,need,0,0);
free(t);
return need;
}
기존 코드는 UTF8BOM으로 case문의 상수만 수정하고 이 코드를 그대로 case UTF8로 복사하고 BOM을 위해 +3하던 것만 삭제하면 된다. BOM이 없으므로 문자 코드를 바로 변환하기만 하면 된다. 반대쪽 변환도 비슷하다.
switch (to) {
....
case AE_FORMAT_UTF8BOM:
// 안시를 유니코드로 먼저 변환한다.
need=MultiByteToWideChar(CP_ACP,0,src,srclen,NULL,0);
t=(LPWSTR)malloc(need*sizeof(wchar_t));
num=MultiByteToWideChar(CP_ACP,0,src,srclen,t,need);
// 유니코드를 UTF-8로 변환한다.
need=WideCharToMultiByte(CP_UTF8,0,t,num,NULL,0,0,0);
need+=3;
dest=(TCHAR *)malloc(need);
dest[0]=(TCHAR)0xEF;
dest[1]=(TCHAR)0xBB;
dest[2]=(TCHAR)0xBF;
WideCharToMultiByte(CP_UTF8,0,t,num,dest+3,need,0,0);
free(t);
return need;
case AE_FORMAT_UTF8:
// 안시를 유니코드로 먼저 변환한다.
need=MultiByteToWideChar(CP_ACP,0,src,srclen,NULL,0);
t=(LPWSTR)malloc(need*sizeof(wchar_t));
num=MultiByteToWideChar(CP_ACP,0,src,srclen,t,need);
// 유니코드를 UTF-8로 변환한다.
need=WideCharToMultiByte(CP_UTF8,0,t,num,NULL,0,0,0);
dest=(TCHAR *)malloc(need);
WideCharToMultiByte(CP_UTF8,0,t,num,dest,need,0,0);
free(t);
return need;
}
파일 선두에 BOM 기록을 하지 않으면 된다. 다음은 호스트 프로그램인 당근을 수정한다. 포맷을 표시 및 판별하는 UI가 File 메뉴에 있으므로 이 메뉴에 UTF-8(BOM), UTF-8(BOM 없음) 항목을 작성한다. 기존의 UTF-8이 둘로 세분화된 것이다. 새로 추가된 항목이 연속적인 번호를 가질 수 있도록 resource.h도 정리해야 한다.
#define IDM_FILE_UNICODE 412
#define IDM_FILE_UNIBIG 413
#define IDM_FILE_UTF_8BOM 414
#define IDM_FILE_UTF_8 415
#define IDM_FILE_READONLY 416
....
리소스를 그냥 편집하면 비주얼 스튜디오가 ID를 마음대로 배치해 버리므로 사람 손이 필요하다. 이전 백업에서 resource.h만 읽어서 UTF_8BOM과 UTF_8을 삽입하고 그 뒤쪽의 메뉴 항목들의 ID는 모두 1씩 더한다. 아직까지도 ID를 직접 관리할 때는 수작업을 해야 한다. 다음은 추가된 메뉴 항목들의 명령 핸들러를 작성한다.
void OnCommand(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
case IDM_FILE_UTF_8BOM:
pSi->Ae.SetFormat(AE_FORMAT_UTF8BOM);
SetStatusText(0x10);
break;
case IDM_FILE_UTF_8:
pSi->Ae.SetFormat(AE_FORMAT_UTF8);
SetStatusText(0x10);
break;
ApiEdit에게 포맷이 바뀌었음을 알려 주어야 한다. 포맷 변경 사실만 기록해 놓으면 저장할 때 지정된 포맷으로 변환하도록 되어 있다. 메뉴의 체크 표시도 관리한다.
void OnInitMenu(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
// 문서 포맷 표시
switch (pSi->Ae.GetFormat()) {
case AE_FORMAT_WIN:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_WIN,MF_BYCOMMAND);
break;
case AE_FORMAT_UNIX:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNIX,MF_BYCOMMAND);
break;
case AE_FORMAT_MAC:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_MAC,MF_BYCOMMAND);
break;
case AE_FORMAT_UNICODE:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNICODE,MF_BYCOMMAND);
break;
case AE_FORMAT_UNIBIG:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNIBIG,MF_BYCOMMAND);
break;
case AE_FORMAT_UTF8BOM:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UTF_8BOM,MF_BYCOMMAND);
break;
case AE_FORMAT_UTF8:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UTF_8,MF_BYCOMMAND);
break;
}
이 코드가 제대로 동작하기 위해서는 포맷을 지정하는 메뉴 항목들의 ID가 반드시 연속적이어야 한다. 그래서 resource.h의 ID들을 수작업으로 관리해야 하는 것이다. 마지막으로 상태란의 문자열 표시 함수를 수정한다. 새로 추가된 포맷도 상태란에 출력되어야 한다.
void SetStatusText(int mask,LPCTSTR Mes/*=NULL*/)
{
....
case 3:
switch (pSi->Ae.GetFormat()) {
case AE_FORMAT_WIN:
lstrcpy(Text,"WIN 포맷");
break;
case AE_FORMAT_UNIX:
lstrcpy(Text,"UNIX 포맷");
break;
case AE_FORMAT_MAC:
lstrcpy(Text,"MAC 포맷");
break;
case AE_FORMAT_UNICODE:
lstrcpy(Text,"UNICODE");
break;
case AE_FORMAT_UNIBIG:
lstrcpy(Text,"UNICODE(Big Endian)");
break;
case AE_FORMAT_UTF8BOM:
lstrcpy(Text,"UTF-8(BOM)");
break;
case AE_FORMAT_UTF8:
lstrcpy(Text,"UTF-8(BOM없음)");
break;
case AE_FORMAT_BINARY:
lstrcpy(Text,"이진 파일");
break;
}
break;
리소스가 바뀌었으므로 프로젝트를 전체 빌드해야 한다. 실행해 보면 BOM이 없는 UTF-8 문서도 잘 판별해서 읽으며 편집한 후 저장도 잘 된다. 그러나 아직 완벽하다고 할 수는 없다. 영문만 있는 UTF-8 문서는 ANSI 문서와 전혀 구분되지 않는데 당근은 이런 문서를 ANSI로 연다. 왜냐하면 내부 포맷이 ANSI로 되어 있기 때문이다.
이대로 편집해서 저장해도 어차피 UTF-8과 ANSI는 호환 가능하므로 무방하다. 그러나 한글을 추가 입력한 후 저장했을 때는 두 포맷의 인코딩 방식이 달라 혼란을 초래할 수 있다. BOM없는 UTF-8 문서를 열어 한글을 입력한 후 저장할 때 ANSI로 인코딩이 바뀌어 버리는 것이다. 그렇다면 영문만 있을 때 UTF-8을 디폴트로 인식하면 되지 않을까 싶겠지만 이것도 마찬가지 문제가 있다.
문제는 원본의 인코딩 방식을 정확하게 알 수 없다는 점인데 논리적으로 이 문제를 해결할 수 있는 방법이 전혀 없다. 결국 영문으로만 된 문서는 사용자가 인코딩 방식을 직접 지정하여 저장해야 한다. 당근에는 이런 장치가 있지만 문제는 파일 입출력 대화상자가 아닌 File 메뉴에 있다는 점이다. 좀 더 깔끔하게 해결하려면 Open As 명령을 만들든가 아니면 파일 저장 대화상자에 인코딩 방식을 선택하는 콤보 박스를 배치해야 한다.
게시판을 통해 몇 분이 버그 및 불편 사항을 보고해 주셨는데 그 중 고치기 쉬운 것만 수정했다. FixedSys 글꼴을 기본으로 지정하고 싶다는 요청이 있었는데 이 문제는 파일 열거 함수의 다음 한 줄만 수정하면 된다.
int CALLBACK EnumFamCallBack(ENUMLOGFONT FAR *lpelf, NEWTEXTMETRIC FAR *lpntm,
int FontType, LPARAM lParam)
{
if (FontNum < 500) {
if (lpelf->elfLogFont.lfFaceName[0]!='@'/* && FontType==TRUETYPE_FONTTYPE*/) {
arFont[FontNum] = lpelf->elfLogFont;
FontNum++;
}
return TRUE;
}
else {
return FALSE;
}
}
이전 버전에서는 품질을 위해 트루타입 폰트만 열거하도록 했는데 굳이 트루타입만 강요할 필요는 없는 것 같다. 비트맵은 크기를 키우면 굉장히 보기 싫어지지만 어쨌거나 사용자가 원한다면 선택할 수 있어야 한다. 이외에도 몇 가지 버그 보고가 있었는데 재현이 안되거나 너무 어렵거나 해서 일단 제외해 두었다.
마지막으로 도움말과 타이틀 바의 버전을 1.21로 수정했다. 조금이라도 바뀐 것이 있으면 버전을 높여 혼란을 없애야 한다. 이 버전이 이제 1.21이며 당분간은 최신 버전이 될 것이다. 어쩌면 최종 버전이 될 지도 모른다. 아직도 당근은 더 많은 기능을 추가할 필요가 있지만 응용 프로그램이라기보다는 교육용으로 제작했고 나름대로의 목적으로 달성했기 때문이다. 아마 다음에 더 시간이 허락된다면 당근이 아니라 워드 프로세서를 만들려고 덤빌지도 모르겠다.