Imp: Delphi/C++Builder Evangelist

이 문제는 대부분의 개발자들은 겪지 않는 문제인데... 증상을 말하자면, 프로그램을 IDE 안에서 F9를 눌러 디버그 모드로 실행했을 때 어떤 특정 루틴에서 갑자기 어셈블리 화면이 뜨면서 IDE로 돌아오는 문제입니다. 아래 그림을 보시면 DbgBreakPoint라고 표시된 부분과 그 아래의 int 3 호출을 보실수 있을 겁니다.

보통 애플리케이션 실행중에 이렇게 느닷없이 IDE로 제어가 돌아오는 경우는 둘중의 하나인데, 개발자가 코드에 브레이크 포인트를 잡아놨거나, 아니면 뭔가 예외(exception)이 발생한 경우죠. 그런데 이 경우는 개발자가 브레이크 포인트를 잡지 않았는데 IDE로 돌아온 경우이기 때문에, 처음으로 이 현상을 만나게 되면 대부분의 개발자들이 예외라고 간주하고 이것이 뭔가 Delphi/C++Builder의 버그나 문제점이라고 오해를 많이 합니다.

하지만 이것은 Delphi나 C++Builder와는 무관한 문제이며, 실제로 운영 상황에서는 절대로 발생하지 않습니다. 실제로 이 현상이 발생하는 애플리케이션을 동일한 상황에서
IDE 내부가 아닌 별도로 실행하더라도 아무런 문제가 발견되지 않습니다. 정확하게 말하면, 이것은 윈도우 OS의 버그입니다.

DbgBreakPoint 함수는 Win32 API 함수로서, 코딩으로 브레이크 포인트 동작을 할 수 있도록 하는 역할을 합니다. 따라서 IDE 내부에서 디버그 모드로 실행하다가 이 루틴이 실행되면 그것이 Delphi 애플리케이션의 코드이든 아니면 OS에 속한 코드이든 실행을 멈추고 IDE로 돌아가도록 합니다. 그 순간에 자신이 개발한 Delphi의 코드가 아닌 OS의 코드가 실행되고 있었던 거죠.

Delphi/C++Builder IDE는 해당 애플리케이션의 코드를 넘어서서 OS 레벨이나 심지어는 다른 애플리케이션으로 제어권이 넘어간 상태에서도 디버그를 할 수가 있습니다. 해당 소스코드가 없는 경우에는 어셈블리 창으로 보여주죠. (소스가 없는 상태에서는 어셈블리라도 보여주는 것이 최선이니까요)

윈도우 OS의 일부인 ntdll.dll 내부에 이 DbgBreakPoint 함수에 대한 호출이 있는데요. 원래 마이크로소프트 내부의 윈도우 개발팀에서 윈도우 자체에 대한 디버깅을 하면서 집어넣었던 코드인데 미처 삭제하지 않았기 때문에 코드 내부적으로 특정 패턴의 호출이 일어나면 이런 현상이 발생합니다. 아마도 특정 윈도우 버전에서만 발생하는 것으로 생각되는데, 윈도우 비스타나 윈도우 7에서는 이런 문제가 발생했다는 리포트가 전혀 없었던 것으로 봐서 윈도우 XP 이하에서만 있었던 버그 같습니다.

이 문제(?)는 디버그 코드인 관계로 IDE 내부에서 디버깅 모드일 때만 발생하게 되며 실제로 별도로 실행했을 때는 전혀 발생하지 않습니다. 따라서 개발된 애플리케이션과는 아무런 상관이 없게 됩니다만, 다만 개발하고 있는 과정에서는 이 현상이 반복적으로 일어나면 개발자의 입장에서는 상당히 번거로울 것은 당연하겠죠.

그래서, 이 문제가 윈도우 OS의 문제임에도 개발자가 곤란을 겪을 수 있기 때문에, Delphi/C++Builder의 최근 버전들에는 이 문제에 대한 해결 방법이 마련되어 있습니다. IDE 메인 메뉴의 Tools->Options 메뉴 항목을 눌러 Options 다이얼로그를 띄우고, 왼쪽 트리에서 가장 아래의 Debugger Options->Embarcadero Debuggers를 선택한 후, 위에서 세번째에 있는 인 "Ignore non-user breakpoints" 체크박스에 체크하시면 됩니다.

이렇게 하면 이런 브레이크포인트 코드에 걸리지 않고 그대로 실행됩니다. 다만 이 옵션은 Delphi/C++Builder의 2007 버전 이상에만 있습니다.

Delphi/C++Builder 2007에 번들된 RaveReports 7.5에는, Memo에 한글을 출력할 때 한글이 깨지는 버그가 있습니다. Memo에 긴 한글 문자열이 들어갈 때 자동으로 여러 줄로 나누게 되는데요. 이때 2바이트인 한글을 인식하지 못하고 그냥 바이트 단위로 잘라서 한글 한 글자가 각각의 글자로 강제로 쪼개져서 생기는 문제입니다.

이것은 명백한 Rave의 버그인데, 유니코드가 적용된 Delphi/C++Builder 2009, 2010 버전에서는 발생하지 않습니다. 왜냐하면 유니코드 환경에서는 따로 한글을 처리하지 않아도 한글이 바이트 단위가 아닌 한글 그대로의 글자 단위로 처리되기 때문에 중간에서 잘리는 일이 없기 때문입니다.

사실 RaveReports는 엄밀히 말해 단순 번들 제품일 뿐 Delphi, C++Builder의 일부가 아니기 때문에 Rave의 벤더인 Nevrona에서 해결해야 할 문제입니다. (Rave 이외에 TChart, InstallAware 등의 다른 번들 제품도 해당 벤더에서 버그 패치를 내놓습니다) 그런데 최근 Nevrona가 제대로 돌아가지 않는 것으로 보여 문제 해결이 어렵고요. 또 더욱이 2007 버전 자체가 연장 지원까지 지원이 모두 끝난 상태이기 때문에, 어떻게든 공식적인 버그 패치가 나올 수 없는 상태입니다.

이 문제에 대한 근본적인 해결 방법은, 유니코드가 적용되는 2009, 2010 버전으로 업그레이드하는 것입니다. 유니코드가 적용된 상태에서는 기본적으로 서드파티 컴포넌트라고 하더라도 한글 입출력에서 문제가 생길 수가 없습니다. 따라서 잘 알지 못하는 서드파티 컴포넌트를 쓰더라도 적어도 한글 문제는 생기지 않을 거라고 기대할 수 있습니다.

하지만 이 문제는 Delphi/C++Builder 2007 버전을 사용중인 국내 사용자에게는 당장 아주 심각할 수 있기 때문에... 비공식적이지만 제가 해당 버그 루틴을 가진 유닛을 수정해봤습니다. 근데.. 일단 공개하기는 합니다만, 저도 바쁜 일정 중이라 대충 작업한 거고... 또 2007 Rave의 다른 부분에서도 비슷한 한글 문제가 있을 가능성도 있습니다.

아래 압축 파일을 다운받은 후, 압축 파일에 포함된 RpMemo.dcu와 RpMemo.obj 파일을 Delphi/C++Builder 2007 설치 디렉토리 아래의 \RaveReports\Lib 디렉토리에 복사해넣으면 됩니다.

다만, 보다시피 이 패치는 런타임 패키지인 Rave75VCL.bpl을 다 컴파일한 것이 아니라 해당 유닛 하나만 컴파일한 것이므로, Rave75VCL.bpl을 런타임 패키지로 이용하도록 빌드하면 한글 문제가 그대로 나타납니다. 따라서, 혹시 다른 런타임 bpl 들은 따로 배포하더라도 RaveReport 부분은 꼭 정적으로 링크해야 합니다.

아마도, 이 한글 버그는 Rave가 처음 탑재된 Delphi 7이후로 2005, 2006 버전에도 동일하게 발생할 것입니다. 하지만 환경적인 이유로 2007보다 이전 버전들에 대한 패치 제공은 어려울 것 같습니다.

Delphi와 C++Builder의 7 이하 버전에는 DecisionCube라는 컴포넌트들이 있었습니다. 이 DecisionCube는 데이터베이스로부터 읽어들인 데이터를 분석하기 위한 컴포넌트들인데요.

이것이 2005 버전에서 누락되었다가, 2006 버전부터는 컴포넌트 등록 없이 소스만 제공되고 있습니다. 최신 버전인 Delphi/C++Builder 2010에도 이 DecisionCube의 소스가 포함되어 있는데요. 소스는 \RAD Studio\7.0\source\Win32\xtab 디렉토리에 있습니다.

그런데, 이 DecisionCube는 더 이상 정식 지원이 되지 않는 관계로, 2009 버전에서부터 도입된 유니코드에 대한 마이그레이션 작업이 되어 있지 않습니다. 따라서 Delphi/C++Builder 2010에서는 컴파일 및 정상적인 동작이 되지 않습니다.

최근에 Delphi 구버전 기반의 대규모 ERP를 Delphi 2010으로 마이그레이션하는 기업 한군데에서 이 DecisionCube에 대한 마이그레이션을 요청하여, 요 며칠 사이에 이 작업을 진행했습니다. 간단한 데모 애플리케이션을 만들어 동작을 일일이 확인하면서 작업했는데, 단순히 컴파일만 되도록 하면 되는 것이 아니라 제대로 동작하기 위해서는 생각보다 수정할 곳이 많더군요.


Delphi 및 C++Builder 강의를 진행해주시는 저희 김원경 강사님의 테스트 도움으로 작업을 잘 마쳤구요. 또 DecisionCube에서 빈발하는 런타임 에러인 'The DecisionCube Capacity is low'에 대한 수정 작업도 적용했습니다. (제대로 작업이 된 것인지 데이터가 부족해서인지 테스트 과정에서 이 에러가 발생하는 것을 보지 못했습니다)

다만, 이 소스는 엠바카데로 본사에서 더 이상 공식 지원을 하지 않고 있는 것이라, 제가 수정된 버전을 마음대로 배포하기는 좀 걸립니다. 그래서, 필요하신 분들은 제게 따로 메일로 요청해주시면 보내드리겠습니다.

Entera라는 미들웨어 서버가 있습니다. 요즘은 뭐 그닥 대세는 아닙니다만, 90년대 말부터 2000년대 초까지 전세계 미들웨어 서버 시장에서 한 칼(?) 했었던 주요 솔루션들 중 하나였죠. 국내에서도, 관공서와 병원 등에서 아주 많이 사용되었고요. 지금도 행정안전부와 서울시청 등의 기관들과 꽤 여러 병원들에서 사용중입니다.엔테라는 특히 델파이 개발자들에게는 더욱 친숙한데... 물론 파워빌더 등의 다른 툴과도 연동해서 개발하기도 했지만, 델파이로 연동 개발한 경우가 가장 많았습니다. 지금은 아니지만 한때 볼랜드의 제품이었고, 또 델파이에서 개발을 지원하는 전용 컴포넌트가 번들되어 있기도 해서, 델파이에서 엔테라 개발이 가장 편하고 빨랐기 때문입니다.

작년 11월이었던가에 행안부의 민원행정시스템이 V3의 오진으로 뻗었던 사건이 바로 이 엔테라와 관련이 있는데요, 엔테라에서 클라이언트쪽 배포 파일로 midas.dll을 필요로 하는데, V3가 이 midas.dll 파일을 악성코드로 오진해서 일괄 삭제해버렸었죠. 그래서 전국 시군구 행정기관의 민원 시스템이 하루 아침에 몽땅 중지되기도 했었습니다.

제가 현재 컨설팅을 진행중인 건들 중의 하나가 바로 이 엔테라 관련 건인데요. 엔테라 컴포넌트는 델파이 5 부터는 제외되었기 때문에 당연히 최근의 델파이 버전에서는 엔테라 컴포넌트들이 없습니다. 그런데 엔테라와 델파이를 아직 사용하는 모 관공서에서, 델파이 최신 버전으로 업그레이드하기 위해 델파이 2010에서 엔테라 컴포넌트가 지원되도록 해달라는 요청이 들어왔습니다.

Entera 지원 컴포넌트가 번들되어 있었던 것은 아주 제한적인 버전에 제한적인 에디션이었는데, 정확히 말해서 델파이 3, 4 버전의 Enterprise 에디션에서만 지원되었었습니다. 여기서 Enterprise 에디션은 지금의 Enterprise 에디션과는 다른 것이었는데, 델파이 3, 4, 버전 당시의 프로페셔널 상위 에디션은 클라이언트/서버 에디션이었고, 이것이 지금의 엔터프라이즈 에디션에 해당합니다. 그리고 이 클라이언트/서버 에디션보다 더 높은 에디션이 엔터프라이즈 에디션이었고, 따라서 당시의 엔터프라이즈 에디션은 지금으로 치면 아키텍트 에디션에 해당하는 거죠.

어쨌든 이 최상위 에디션에만 엔테라 지원 컴포넌트가 있었기 때문에, 당시에 델파이를 사용하셨던 분이라도 클라이언트/서버 에디션이나 프로페셔널 에디션만 사용해보셨던 분들은 엔테라 지원에 대해 전혀 알지 못하실 겁니다.

이 엔테라 지원 컴포넌트는 TEnteraConnection과 TEnteraProvider 두개로 되어 있었고, 몇개의 델파이 pas 유닛에 포함되어 있습니다. 그리고 디자인타임 지원을 위해 몇개의 파일들이 더 필요하구요. 이 컴포넌트들의 역할은 엔테라 액세스를 TDataSet 방식으로 할 수 있도록 중간에 처리를 해주는 것입니다. 델파이가 아닌 파워빌더나 C++ 등의 다른 언어를 사용할 경우 엔테라와 연동하는 모든 개발 작업을 로우 레벨에서 코딩 삽질을 해야 하는데, 델파이에서 이들 컴포넌트들을 이용하면 데이터셋 방식인 만큼 당연히 코딩 양은 최소화되고 개발 부하가 확 줄어듭니다.
어쨌든, 이 컴포넌트들을 델파이 2010 버전으로 마이그레이션을 진행해왔는데요.

처음 작업을 시작할 때는 이 컴포넌트들의 소스를 구하는데에도 별 어려움이 있을 거라고 생각하지 못했고, 또 기술적으로도 유니코드 지원으로 인한 변경 부분 이외에 큰 작업은 없을 거라고 짐작하고 시작했는데... 델파이 3, 4 시절에도 엔테라 컴포넌트의 소스는 제공되지 않았었다는 것을 뒤늦게 알았습니다. 그래서 저희 엠바카데로 본사로도 수십 차례 문의하고(땡깡을 쓰다시피) 현재의 엔테라 벤더인 eCube Systems로도 여러차례 연락을 했죠. 본사에서도, 워낙 오래전의 파일들이라 당시의 담당자도 불명확하고(12년 정도 되었죠), 하필이면 최근에 본사가 볼랜드 창사 이래 처음으로 이사까지 하는 바람에 오래전 아카이브들을 찾지 못해 진행에 큰 어려움을 겪었습니다.

뭐 여러 번의 우여곡절 끝에 본사로부터 델파이 3 당시의 소스 파일을 받는 데에는 성공했는데, 작어을 시작해보니 예상보다 델파이의 구버전들 사이에서 Provider의 기반 구조가 너무 크게 바뀌었더군요. 그래서, 길어도 1~2주 정도의 작업을 예상했던 것이 결국 거의 두달을 채우고야 마무리하게 되었습니다.

어쨌든, 이게 최근에야 거의 마무리되었고요. 어제 오후에 방문해서 최종 테스트까지 마쳤습니다. 이 일을 의뢰받은 관공서 이외에도 아직 엔테라를 사용하는 곳이 적지 않은 것으로 알고 있는데, 본사와 협의해서 지금까지 작업한 엔테라 지원 컴포넌트들을 배포할지 어떨지 고려하려고 합니다. 주위에 델파이와 엔테라를 사용하는 곳을 아시는 분은 제게 좀 알려주세요~

Delphi/C++Builder 2010 버전의 기능들 중에서 제가 가장 사랑(?)하는 기능은 바로 코드 포매터(Code Formatter) 기능입니다. 제가 하는 업무의 특성상, 다른 개발자의 코드를 리뷰하는 경우가 아주아주 많은데요. 저도 개발자인지라, 사실 제가 쓰는 코딩 스타일과 다른 코드를 보면 스타일이 눈에 자꾸 걸려서 코드의 내용은 잘 안보인답니다. 그래서, 몇시간이나 들여서 수작업으로 코드를 재정렬한 후에야 코드의 내용을 보기 시작하는 경우가 종종 있었는데요.

2010 버전에서는 코드 포매터가 기본 기능으로 포함되어서 이런 삽질을 할 일이 싹 사라졌습니다. 에디터에서 팝업 메뉴를 띄운 후 "Format Source" 항목을 선택하거나 핫키 Ctrl+D 키를 누르면 즉시 현재 유닛의 코딩 스타일이 싹 재정렬됩니다. 더욱 더 좋은 것은, 이런 코딩 포맷이 벤더인 엠바카데로의 입맛대로 고정된 것이 아니라, 각 개인 개발자들이 환경 설정으로 저장해둘 수 있다는 것입니다.

그런데, 여기서 한가지 단점도 있습니다. Ctrl+D 키가 흔히 쓰는 다른 핫키들과 비슷한 위치에 있어서Ctrl+C나 Ctrl+S 등의 흔히 쓰는 다른 핫키를 누르려다 잘못 누르는 경우가 종종 생기기도 합니다. 그러면 코드 포매터가 동작해버려 순식간에 현재 편집하던 코드가 확 달라져버리죠.

물론, 코드 포매터가 동작한 후라도 Ctrl+Z를 누르면 이전으로 돌아가니까 크게 문제가 되는 것은 아닙니다. 하지만 종종 키 타이핑에서 오타를 내거나 하는 개발자분들에게는 이게 꽤 성가실 수도 있습니다.

조금 불행하게도, Delphi/C++Builder IDE의 옵션으로 이 코드 포매터 기능을 중지시킬 방법은 현재로서는 제공되지 않습니다. 하지만 다음과 같은 방법을 쓰면 코드 포매터가 동작하지 않도록 할 수 있스니다.

Delphi/C++Builder 2010의 설치 디렉토리(디폴트는 C:\Program Files\Embarcadero\RAD Studio\7.0\) 아래에 Bin 디렉토리가 있습니다. 여기에 Embarcadero.Modeling.Formatter.dll 이라는 파일이 있는데, 이것이 바로 코드 포매터 기능을 하는 파일입니다. 따라서 이 파일을 삭제하거나 이름을 바꾸시면 코드 포매터 기능이 동작하지 않습니다.

물론, 코드 포매터 기능을 자주 사용하지 않더라도 간혹이라도 쓸 일이 있을 수 있으니, 삭제보다는 이름을 바꾸는 것이 낫겠구요. 이 파일이 없더라도 IDE가 실행되면서 당황스러운 에러가 발생하거나 하지는 않으며, 또 원래대로 다시 이름을 바꿔놓으면 IDE가 실행될 때 이 파일을 불러들여 코드 포매터가 동작하므로 언제든 필요하실 때는 사용할 수 있습니다.

이 에러는 컴파일이나 런타임 에러가 아니라, RAD Studio, 즉 델파이나 C++빌더 IDE의 Welcome Page에 나타나는 에러입니다. 웰컴 페이지에 기존에 열었던 프로젝트 리스트 등이 전혀 나타나지 않고 이 에러 메시지만 달랑 나타나는 현상입니다. (아래 이미지 참조)

이 에러는 델파이 쪽의 에러가 아니라 윈도우 시스템의 에러입니다. 정확하게는, 윈도우 OS에 내장된 VB스크립트/J스크립트 엔진이 등록되지 않았거나 혹은 파일이 없을 때입니다. 이 OS 오류를 해결하시려면 다음과 같이 하시면 됩니다.
 
regsvr32 scrrun.dll
(scrrun.dll 파일이 윈도우 OS에 내장된 스크립트 엔진입니다)
 
만약 이렇게 해서 해결이 안된다면 scrrun.dll 파일이 아예 존재하지 않거나 깨진 경우일 것입니다. 그렇다면 윈도우 스크립트 엔진 자체를 다운받아 설치해야 합니다.
 
아래 링크에서 윈도우 스크립트 엔진 전체 설치 파일을 다운받을 수 있습니다.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=47809025-d896-482e-a0d6-524e7e844d81 (윈도우 XP)

http://www.microsoft.com/downloads/details.aspx?familyid=F00CB8C0-32E9-411D-A896-F2CD5EF21EB4&displaylang=en (윈도우 2003)

현재 정상적으로 판매되고 있는 델파이 버전들은 델파이 2010, 델파이 2009, 델파이 2007, 델파이 7 이렇게 네 가지 버전입니다. 이 글은, 개발자들이 이 네 가지 델파이 버전들 중에서 자신의 상황에 맞는 적절한 델파이 버전을 선택하기 위한 가이드를 드리기 위한 것입니다.


델파이 7
델파이 7이 지금도 정상 판매되고 있는 것은 사실입니다. 하지만 원래 단종되었던 제품을 시장의 상황 때문에 억지로(?) 재판매하고 있는 것이기 때문에, 기술 지원이나 버그 패치 등은 전혀 되지 않습니다.

또한 델파이 7은 2002년에 발표된 제품으로서, 출시된지 8년이나 트렌드에 뒤쳐진 제품입니다. 지원하는 OS는 윈도우 XP까지이며 윈도우 2003도 정식으로 지원하지 않습니다. 크게 변화한 윈도우 OS인 윈도우 비스타나 윈도우 7에서는 당연히 여러가지 문제가 발생합니다.

어떤 개발자분들은, 델파이 7이 가장 좋다, 라는 호의적인 평가를 하는 경우가 많은데, 실상은 별로 그렇지 못합니다. 델파이 7이 선호되는 이유로는, 구버전 IDE의 마지막 버전인 탓이 가장 큽니다. 단지 익숙하기 때문에, 라는 것이죠.

델파이 7은 델파이 6의 마이너 업그레이드에 가깝습니다. 개발자에게 실질적인 도움이 되는 개선 사항이 별로 없고, 그나마 의미가 있는 것이라고 하면 델파이로 WISIWIG 웹 개발을 지원하는 IntraWeb 컴포넌트 라이브러리와 퀵 리포트에 비해 여러 모로 나은 리포트 컴포넌트인 RaveReport가 번들되기 시작했다는 점, 그리고 윈도우 XP 테마를 처음 제대로 지원하기 시작했다는 점 정도입니다.

사실 당시에 델파이 7의 뛰어난 점으로 내세웠던 특징들은 델파이 닷넷 프리뷰 버전의 번들, UML 툴인 모델 메이커의 번들, 아키텍트 에디션에서 MDA 개발을 위한 Bold for Delphi 프레임워크의 번들, 협업을 위한 팀 소스 툴의 번들 등이었는데, 아시겠지만 이 모두가 세월이 흐른 지금 돌이켜보면 간단히 알 수 있듯이 개발자들에게 별 효용이 없는 것들이었습니다. (주요 특징이 모두 '번들'이라는 점을 보시면 실제 델파이 개발에서는 큰 개선이 없다는 것을 역설적으로 알 수 있죠)

델파이 7으로 만들어진 애플리케이션은 윈도우 비스타, 윈도우 7에서 여러가지 문제를 일으킵니다. 지원하지 않는 OS의 문제이므로 그 크고 작은 문제들에 대한 책임은 개발자의 몫입니다. 지금 당장은 사내의 환경이 오직 윈도우 XP 뿐이라고 해도, 바로 몇년 후의 미래를 고려한다면 델파이 7은 답이 아니죠.


델파이 2007
델파이 2007은 델파이 2006 버전과 바이너리 호환이 되는 버전입니다. 그러면서도 델파이 6에서 Windows XP를 지원하기 시작한 이후로 처음으로 새로운 OS인 Windows Vista를 지원하게 되었으며, 따라서 Vista의 새로운 권한 구조(UAC)나 사용자 인터페이스(Aero, Vista 다이얼로그 등)를 지원합니다.

또한 델파이 2007은 델파이 8에서 처음 도입된 새로운 IDE(갈릴레오 IDE)가 2005, 2006 버전을 거쳐 제대로 안정화된 첫 버전이어서, 기동 속도나 반응이 훨씬 빨라졌음은 물론 이상 종료 현상도 발생하지 않습니다.

또 Unicode 도입 이전의 마지막 버전이기 때문에, 오래된 구버전으로부터의 마이그레이션이 상당히 쉽고 빠릅니다. 대신 당연히 Unicode로 인한 이점들은 모두 놓치게 됩니다만, 유니코드가 현재도 장래에도 전혀 필요하지 않다면 별 문제가 되지 않겠지요. 따라서 만약 유니코드가 전혀 필요없고, 또 이전 소스를 최대한 수정 없이 사용하는 것이 가장 큰 이슈라면 델파이 2007을 선택하면 됩니다.

델파이 2007이 더 최신 버전들에 비해 갖는 강점 또 한가지는, 델파이 2007에 퀵 리포트가 기본 포함되어 있지는 않지만 델파이 2007을 구입하면 퀵 리포트가 추가로 제공된다는 것입니다. 퀵 리포트를 따로 구입할 경우 50~60만원 정도이기 때문에, 퀵 리포트가 반드시 필요하다면 델파이 2007을 선택할 경우 그만큼의 액수를 절약할 수 있습니다. (2009, 2010 버전에는 퀵 리포트가 제공되지 않습니다)

델파이 2007은 공식적으로 Windows 7을 지원하지는 않지만, Windows 7이 Windows Vista의 마이너 업그레이드에 가깝기 때문에 대부분의 경우 Windows 7에서 잘 돌아가며 아직 특별한 문제 보고는 없었습니다. (Windows 7에서 일부 디버거 기능이 오동작하는 버그가 있었는데, 비공식적이기는 하지만 문제 해결을 위한 패치가 제공되었습니다)


델파이 2009
델파이 2009를 선택할 필요는 거의 없는데, 그것은 이미 델파이 2010이 나와있기 때문입니다. 델파이 2010은 델파이 2009의 모든 코드가 소스 레벨에서 호환되는 데다 기능이 더욱 더 추가 및 개선되었기 때문에, 델파이 2009의 기능이 메리트가 있다면 가격도 같은 델파이 2010을 두고 델파이 2009를 선택할 필요는 없습니다.

다만, 비용 면에서 구버전으로부터의 업그레이드 할인을 노린다면 좀 따져볼 이유가 있습니다. 델파이 2005 이하의 구버전에서 델파이 델파이 2010으로의 업그레이드 할인 혜택은 지난 1월말 부로 종료되었지만, 여전히 델파이 2009 이하의 버전으로의 업그레이드는 가능합니다. 더 쉽게 말하면, 델파이 2007, 2009는 구입할 때 이전의 구버전으로부터 업그레이드 할인이 가능하다는 말입니다. (업그레이드 제품의 가격은 신규사용자용에 비해 30% 정도가 저렴합니다)


델파이 2010
아시다시피 델파이 2010은 현재 최신 버전입니다. 당연히 가장 많은 기능들을 가지고 있습니다. 특히 델파이 2009로 작성한 코드와 소스 레벨에서 100% 호환됩니다. 따라서 델파이 2009를 구입하려고 고려했다면 델파이 2010을 구입하는 것이 더 좋습니다.

델파이 2009에서부터 처음으로 Unicode를 지원하기 시작했습니다. 업무 개발만을 하는 개발자라면 몰라도, 패키지/솔루션 등을 개발하는 개발자라면 이 Unicode 지원은 대단히 중요한 의미를 갖는데요. Unicode 지원과 번역 지원 기능 덕분에 필요하다면 세계 어느 나라이든 짧게는 몇시간 정도면 현지화된 버전을 만들 수 있습니다.

당장은 해외 판매를 전혀 고려하지 않는 프로그램이라도, 조금만 눈을 돌려보면 우리나라보다 몇백배 더 큰 해외 시장이 있는데 완전히 무시하고 한국에만 팔겠다고 할 필요는 없겠죠.

하지만 이 유니코드 지원 때문에, 구버전으로부터의 마이그레이션이 꽤 많이 어려워지기도 합니다. 이 어려움의 정도는 소스코드에서 사용한 테크닉에 따라 천차만별입니다. 거의 손을 댈 필요가 없을 수도 있고 많이 손을 대어야 할 수도 있는데, 대체로 개발자가 로우 레벨 테크닉을 많이 사용한 경우 작업량이 꽤 올라가고, 반면 일반 폼 작업 정도라면 손댈 부분이 많지 않습니다.

또한 델파이 2010에는 델파이 2009에서 추가된 기능들까지 포함하면 멀티터치/제스처 지원, 빠르고 강력한 그래픽을 위한 Direct2D 지원, 리본 컴포넌트를 비롯한 새로운 UI 컴포넌트들과 속성들, 코드 에디터 지원 기능들, 강력해진 디버거 기능들, 제네릭과 클로져 문법 지원, 컴포넌트 팔레트 지원 및 구버전 IDE 배열 지원 등등등 엄청나게 많은 신기능들이 포함되어 있습니다.

따라서, 미래에 대한 투자를 생각하는 개발자라면 델파이 2010이 최선의 선택일 것입니다.

프로젝트를 델파이로 개발하기로 결정한 상태라면, 여러 델파이의 버전들 중에서 어떤 버전으로 개발할 것이냐가 이슈가 될 것입니다. 또 아주 구버전을 사용하던 개발자들이 더 새로운 버전으로 이동을 고려할 때도 같은 고민을 하게 됩니다.

현재 엠바카데로의 한국 대표인 데브기어에서는 델파이 7, 델파이 2007, 델파이 2009, 델파이 2010 등 총 네 가지의 버전을 판매하고 있습니다. 먼저, 이 이외의 버전이 필요할 경우를 생각해봅시다.


델파이 2006이 필요한 경우
델파이 2006(즉 BDS 2006)의 경우는 아주 간단합니다. 델파이 2007은 델파이 2006과 바이너리 수준까지 완벽하게 호환됩니다. (서로 다른 두 버전 사이에서 바이너리 레벨 호환이 되는 유일한 경우입니다) 따라서 소스 없이 바이너리만으로 사용하던 컴포넌트들까지도 델파이 2007에서 그대로 사용할 수 있습니다.

따라서, Windows 개발에 있어서, 정상적으로 공급되고 있는 델파이 2007를 두고 단종된 델파이 2006이 필요한 경우는 결코 없습니다.

다만, 닷넷의 경우 약간 영향이 있습니다. 델파이 닷넷의 경우, 델파이 닷넷 2006은 닷넷 1.1을 지원하고, 델파이 닷넷 2007은 닷넷 2.0을 지원하므로, 만약 반드시 닷넷 1.1 환경에서 돌려야 하는 상황이 있다면 문제가 될 수도 있겠습니다. 하지만, 1. 일단 닷넷 개발 자체가 별로 일반화되지 못했고, 2. 닷넷 1.1보다 2.0이 그나마 조금이라도 더 낫고, 3. 거기다가 닷넷의 특정 버전을 따져야 할 경우는 더더욱 없으므로, 이것이 문제가 될 가능성은 너무너무 적죠.

게다가, 2006에 비해 2007은 IDE의 기능도 많이 향상되고 안정성도 획기적으로 높아졌으며, 윈도우 비스타 이상까지 지원하는데다 수없이 많은 새로운 기능들이 추가되었습니다. 그러니 2007을 두고 2006을 선택할 아.무.런. 이유도 없습니다.


델파이 6가 필요한 경우
델파이 6는 거의 대부분의 경우 델파이 7으로 대체가 가능합니다. 소스 코드 레벨에서는 거의 문제 없이 아주 스무스하게 호환됩니다. 그럴 수 있는 이유는, 델파이 7이 델파이 6와 비교해서 아주 마이너한 업그레이드이기 때문입니다. (반면, 델파이 5 이하에서 델파이 6로의 업그레이드는 그렇게 아주 만만치는 않습니다)

하지만 역시 버전이 달라 바이너리 레벨에서는 호환되지 않기 때문에, 만약 서드파티 컴포넌트를 소스 없이 바이너리 파일(dcu나 bpl 등)로만 사용해왔다면 곤란해집니다. 컴포넌트 소스 코드가 있어서 델파이 7에서 재 컴파일이 가능하다면 아무 문제가 되지 않습니다.

또 한가지 문제는 BDE의 문제입니다. 델파이 6는 BDE가 전체 기능으로 탑재되었던 마지막 버전이며, 델파이 7부터는 BDE의 로컬 부분만 남고 RDBMS, 즉 오라클이나 MS-SQL, DB2 등으로 연결하는 SQLLinks가 빠졌습니다. 이 이슈에 대한 자세한 내용과 방법은 아래 블로그 글을 참고하세요.
http://blog.devgear.co.kr/imp/entry/델파이-최근-버전에서-BDE로-RDBMS에-연결하는-문제


델파이 5 이하가 필요한 경우
델파이 5는 1999년에 출시된 제품으로, 윈도우 XP조차도 제대로 지원하지 않습니다. 델파이 5 버전은 제품 겉면에 지원 OS가 윈도우 95/98/NT라고 명시되어 있는 제품들입니다. 물론 그 이전 버전들을 더욱 더 그렇구요. 10년이 넘어간 기술, 지금 거의 사용되지도 않는 OS만을 지원하는 개발툴을 계속 사용하는 것은 큰 문제가 있습니다. 또한, 델파이 5 버전 이하는 공식적으로 윈도우 98 이하에서만, 델파이 2006 버전 이하는 윈도우 XP 이하에서만 지원됩니다.

하지만, 이러한 기본 전제에도 불구하고, 업무의 현실상 반드시 필요하다면, 델파이 5 이하 버전을 합법적으로 구입할 방법이 전혀 없는 것은 아닙니다. 델파이의 제품군 중에 ToolCloud라는 제품이 있습니다. 이 툴클라우드는, 현재 일반 판매중인 델파이 2010/2009/2007 버전을 모두 합법적인 라이선스로 사용할 수 있는 형태입니다. (델파이 7은 제외) 가격은 단일 버전 제품에 비해 1.5배 정도구요. (네트워크 네임드 라이선스의 경우)

이 툴클라우드 제품에 대한 프로모션 행사로서, 다음 달인 4월 한달간 델파이 6 이하 구버전에 대해 추가 버전 라이선스 인정을 하게 될 예정입니다. 따라서 4월 말까지 델파이 툴 클라우드를 구입하면, 델파이 2010/2009/2007 등의 구버전 라이선스를 모두 확보하는 것은 물론, 델파이 1~6 버전을 사용할 수 있는 추가 라이선스를 드립니다. (1~6 사이의 모든 버전의 라이선스를 가지는 것은 아니고, 구입 시점에 지정한 특정 한 버전의 라이선스를 부여받게 됩니다)

이 행사는 4월 한달간만 시행됩니다. 이 행사를 시행하는 이유는, 올 4월에 전국적으로 대대적인 불법복제 단속이 있을 예정이기 때문에, 구입할 수 없는 구버전에 대해 정식 라이선스를 구입할 수 있도록 길을 열어드리는 것입니다. 물론 일단 단속되지 않은 업체만 가능합니다. (단속에서 적발된 경우는 손해배상까지 가는 등 문제가 훨씬 복잡해집니다)

최근에 문의받은 내용인데... 스캐너에서 스캔받은 이미지를 델파이 프로그램에서 직접 받으려면 어떻게 할까요, 하는 내용이었습니다. 검색해보니 스캐너 연동을 위한 금방 쓸만한 무료 서드파티 컴포넌트가 있었는데요. Delphi Twain이라는 컴포넌트입니다. (여기서 TWAIN이란 스캐너를 연동하기 위한 표준 인터페이스 및 그 드라이버를 말합니다)

실제로 테스트해보니, 간단한 하나의 컴포넌트만으로 현재 PC에 연결된 스캐너를 동작시키고 그 이미지를 TPicture 객체로 받아와 폼 위의 TImage 컴포넌트에 표시할 수 있었습니다. 고급 설정 기능들도 있는데, 그것까지는 다 테스트해보지 못했구요.

다만, 이 컴포넌트가 2004년에 마지막으로 업데이트된 관계로, 델파이 2010이나 2009등에서는 제대로 컴파일이 되지 않습니다. 그래서, 델파이 2010에서도 컴파일 및 설치가 되도록 코드를 조금 수정했습니다. 아울러 원래 소스는 C++빌더에서 지원하지 않는 델파이 문법을 일부 사용하여 C++빌더에서 컴파일이 안되었는데, 그 부분도 수정했으므로 C++빌더에서도 설치가 가능합니다.

아래 첨부 파일을 다운로드하시면 됩니다.

지난 밤 사이에 Delphi/C++Builder 2009에 대한 핫픽스 3가 올라왔는데...
http://edn.embarcadero.com/article/40331

이건 사실 제가 이미 올렸던 인트라웹 관련 글 두개의 내용과 반복된 내용입니다.
핫픽스 자체는 아래 주소에서 다운로드 받을 수 있습니다.
http://cc.embarcadero.com/item/27563

위 핫픽스를 다운로드 해보시면 아시겠지만, 인트라웹의 한글 문제에 대해 처음 썼던 글(아래 주소)에서 첨부했던 UTF8ContentParser.pas 파일 하나만 달랑 들어있습니다. 이 파일 자체가 핫픽스인 거죠.
http://blog.devgear.co.kr/imp/entry/VCL-for-the-Web에서-한글-깨짐-문제

이 UTF8ContentParser 유닛은 2010 버전에는 dcu, hpp, pas 모두 기본으로 들어있기 때문에 2010에는 필요가 없는 핫픽스이구요. 어쨌든, 이 UTF8ContentParser를 적용하기 위해서는 인트라웹의 최신 업데이트를 설치해야 합니다. 아래 링크의 글을 참고하세요.

http://blog.devgear.co.kr/imp/entry/VCL-for-the-Web-업데이트-한글-문제-해결