Delphi/C++Builder 트라이얼이 설치된 상태에서 정품을 구입해서 정품을 재설치하려고 하는 경우가 종종 있습니다. 이런 경우에 굳이 트라이얼을 언인스톨하고 다시 재설치할 필요가 없구요. 다음과 같은 절차를 따르면 간편하게 기존 설치본이 정품으로 업그레이드됩니다.
이 방법은, Delphi나 C++Builder의 단품만 설치된 상태에서 다른 하나를 추가로 설치하는 경우, RAD Studio로 업그레이드하는 경우에도 똑같이 적용됩니다. 쉽게 말해서, 트라이얼이든 정품이든 이미 설치된 상태에서 '다른 정품을 추가'하는 절차가 되겠습니다.
1. 시작 메뉴 "Embarcadero RAD Studio 2010" 프로그램 그룹에서 "Modify, Repair, Uninstall"을 클릭합니다.
바로 며칠전에 엠바카데로 DN 사이트에 "RAD Studio Roadmap"이 올라왔습니다. 그런데 사실 Delphi Prism에 대한 내용이 빠져 있기 때문에 엄밀하게 말하면 Delphi와 C++Builder에 대한 로드맵이라고 할 수 있구요.
Project "Commodore" - 64비트 네이티브 개발
컴파일러, RTL, VCL에 대한 64비트 지원
- IDE의 옵션에서 64비트 혹은 32비트 개발을 설정
멀티코어/멀티쓰레드 애플리케이션 개발 지원
RTL의 병렬화(parallelization) 지원
Delphi "X" - 크로스플랫폼 Windows / MacOS / Linux 개발
dbExpress 및 DataSnapX를 이용한 GUI 애플리케이션의 개발에 중점
크로스플랫폼 컴포넌트 라이브러리 - 제한적인 하위 호환성
Windows / MacOS / Linux / Web에서 DataSnapX 서버 및 클라이언트 개발Project "Chromium" - 품질 개선 및 생산성 프로젝트
개발자 생산성에 중점
- 사용 편의성 개선
- 오랫동안 지연된 문제점들의 해결 : 최대한 많은 버그 수정에 중점
- 신뢰성의 새로운 표준을 설정
가벼운 O/R 매핑
팀 작업 편의
OTA의 문서화
컨트롤의 거의 모든 프로퍼티에 연결 가능한 데이터 바인딩 모델
데이터베이스 툴들과의 통합 강화
이들과 동시에 추진되는 기능들
클라우드 컴퓨팅
웹 3.0++
RIA 이상
장비
소프트웨어 어플라이언스
보안
표준 준수
그외 현재 고려중인 기능들
Functional 프로그래밍
Declarative 프로그래밍
내츄럴 인풋
더 많은 플랫폼들
내용이 많고 연도별 일정이 나와 있지 않아서 좀 헷갈릴 수 있겠는데요. 사실 여기에 나와 있는 모든 프로젝트들은 연도별 구분 없이 거의 동시에 추진되는 것들입니다. 여기서 "Commodore"가 바로 Delphi/C++Builder의 직접적인 차기 버전이구요.
현재로서는 특별한 차질이 없다는 가정 하에, Delphi "X"는 차기 버전인 Commodore이 실제로 출시될 때 통합되어 발표될 가능성이 높고요. "Chromium"은 별개의 프로젝트 팀이기는 하지만 생산성과 품질에 중점을 두는 것이므로 그 프로젝트의 결과는 향후 버전들에 쭈욱 계속 반영될 것입니다.
모바일 개발 지원
여기에는 몇가지 빠진 것이 있는데... (의도적인 것은 아니고 아마도 실수인 것 같습니다) 모바일에 대한 것입니다. 일단 iPhone 개발 기능은 사실상 확정적입니다. 정확한 발표 시기는 장담하기 어렵지만, 일단 iPhone에 대한 지원은 바로 다음 버전에서 지원될 가능성이 대단히 높은 상태구요.
또한 Windows Mobile에 대한 지원도 될 전망입니다. 하지만 이것은 iPhone보다는 순위가 밀려 있는 상태이며, 따라서 iPhone 지원 기능 개발에 시간이 모자라게 되면 Windows Mobile 지원은 그 다음 버전으로 밀리게 될 것입니다.
크로스플랫폼의 구현 방식
Delphi/C++Builder에서의 크로스플랫폼 지원을 말하면, 예전의 리눅스 개발툴 Kylix를 떠올릴 분이 적지 않으실 겁니다. 그리고 Kylix를 기억하시는 분들 중 많은 분들은, 리눅스용 Delphi/C++Builder라는 혁신적인 개념에도 불구하고 개발된 프로그램이 QT 기반의 둔한 동작을 하던 기억에 고개를 절레절레 흔드시는 분들도 있을 겁니다. (사실 저도 그중 한 사람입니다)
저번에 David I와 간담회를 가졌을 때, 이에 대한 질문을 하고, 명확한 답변을 받았습니다.
당시의 QT 버전은 느리고 굼떴던 것이 사실이다. QT의 최신 버전은 성능에 있어서 혁신적으로 발전했고, 그래서 우리도 관심있게 테스트중이다. 물론 이 최신 QT도 충분히 좋지 않을 것에 대비하여, 현재 완전히 네이티브 방식의 리눅스/MacOS 개발도 QT와 함께 함께 개발 테스트 중이다. 성능을 빼고 얘기할 때에는 QT를 기반으로 하는 것이 여러 모로 유리한 점들이 있기 때문에, 성능을 비롯한 여러 스펙들에 대한 비교를 해보고 최종적으로 결정할 것이다.
뭐, 이런 정도의 자세라면 안심해도 될 것 같습니다. ^^
어쨌든, 지금 이 순간에도 Delphi와 C++Builder는 끊임없이 발전해나가고 있습니다. 바로 지금 Delphi/C++Builder로 개발한 애플리케이션들은, 머지 않아 MacOS와 리눅스로 포팅할 수 있게 될 것이며, 심지어는 iPhone과 Windows Mobile까지도 (아무래도 모바일로는 포팅에 약간의 제한은 있겠지만) 포팅이 가능할 것입니다. 또한 개발툴 자체의 기능들도 끊임없이 추가되고 개선될 것이구요. 멋지지 않습니까? ^^
데브기어 블로그에 델파이,C++빌더 로드맵에 올라왔다. 64비트 네이티브나 크로스 플랫폼 개발환경은 장비 제어 개발 업계의 특성상 그다지 관심이 가지는 않지만 개발자 생산성 향상을 위한 별개의 프로젝트(Chromium)가 운영중이라는것이 반갑니다. 업그레이드 될수록 좀서좋은 개발 환경에서 작업할 수 있을 거라고 기대해본다. SVN이나 CVS등의
function Post(AURL: string; ASource: TStrings): string; overload;
function Post(AURL: string; ASource: TStream): string; overload;
function Post(AURL: string; ASource: TIdMultiPartFormDataStream): string; overload;
procedure Post(AURL: string; ASource: TIdMultiPartFormDataStream; AResponseContent: TStream); overload;
procedure Post(AURL: string; ASource: TStrings; AResponseContent: TStream); overload;
procedure Post(AURL: string; ASource, AResponseContent: TStream); overload;
var
rbstr: RawByteString;
HTML: String;
MemoryStream: TMemoryStream;
StringStream: TStringStream;
slPost: TStringList;
begin
slPost := TStringList.Create;
slPost.Add('student_info=박지훈');
slPost.Add('reserve_purpose=임프');
StringStream := TStringStream.Create(slPost.Text);
slPost.Free;
MemoryStream := TMemoryStream.Create;
IdHTTP1.Request.ContentType := 'application/x-www-form-urlencoded';
IdHTTP1.Post('http://주소', StringStream, MemoryStream);
StringStream.Free;
SetLength(rbstr, MemoryStream.Size);
StrLCopy(PAnsiChar(rbstr), PAnsiChar(MemoryStream.Memory), MemoryStream.Size);
MemoryStream.Free;
if Pos('utf-8', IdHTTP1.Response.ContentType)=0 then
SetCodePage(rbstr, 949, false)
else
SetCodePage(rbstr, 65001, false);
Memo1.Lines.Text := rbstr;
end; TStringList *slPost = new TStringList;
slPost->Add("student_info=박지훈");
slPost->Add("reserve_purpose=임프");
TStringStream *StringStream = new TStringStream(slPost->Text);
delete slPost;
TMemoryStream *MemoryStream = new TMemoryStream;
IdHTTP1->Request->ContentType = "application/x-www-form-urlencoded";
IdHTTP1->Post("http://주소", StringStream, MemoryStream);
delete StringStream;
RawByteString rbstr;
rbstr.SetLength(MemoryStream.Size);
strncpy(rbstr.c_str(), (char *)(MemoryStream->Memory), MemoryStream->Size);
delete MemoryStream;
if(Pos("utf-8", IdHTTP1->Response->ContentType)==0)
SetCodePage(rbstr, 949, false);
else
SetCodePage(rbstr, 65001, false);
String HTML = rbstr;그저께부터 Delphi/C++Builder 2009/2010 버전에서 Indy가 한글과 관련하여 오작동하는 문제에 대해 파헤치고 있습니다. 2009/2010 Indy의 한글 버그는 2009와 2010이 양상이 좀 다르고, 또 idHTTP와 idFTP, IdTCPClient에서 각각 원인도 좀 다르고 수정해야 할 포인트도 좀 다른 것 같습니다. 따라서 완벽한 해결책을 마련해서 공개해드리려면 1~2주 정도가 더 걸릴 것 같고요. 하지만 당장 답답한 분들이 많을 것이므로 작업 중간중간에 상태를 알려드리려고 합니다.
당장은, 일단 idHTTP와 관련하여 라이브러리 소스들을 수정하지 않고 피해가는 회피책, 즉 workaround 방법을 먼저 알려드리겠습니다. 간단히 말하면, idHTTP에서 Get을 호출해서 한글이 포함된 html 페이지를 한글 깨짐 없이 받아오려면, 다음과 같은 코드를 사용하면 됩니다.
Delphi 코드
var
rbstr: RawByteString;
HTML: String;
MemoryStream: TMemoryStream;
begin
MemoryStream := TMemoryStream.Create;
IdHTTP1.Get('http://blog.devgear.co.kr/imp', MemoryStream);
rbstr := PAnsiChar(MemoryStream.Memory);
MemoryStream.Free;
if (Pos('utf-8', IdHTTP1.Response.ContentType)=0) and (AnsiPos('charset=utf-8', rbstr)=0) then
SetCodePage(rbstr, 949, false)
else
SetCodePage(rbstr, 65001, false);
HTML := rbstr;
end; TMemoryStream *MemoryStream = new TMemoryStream();
IdHTTP1->Get("http://blog.devgear.co.kr/imp", MemoryStream);
RawByteString rbstr = (char *)(MemoryStream->Memory);
delete MemoryStream;
if(Pos("utf-8", IdHTTP1->Response->ContentType)==0 && (Pos("charset=utf-8", rbstr)==0))
SetCodePage(rbstr, 949, false);
else
SetCodePage(rbstr, 65001, false);
String HTML = rbstr;
여기서 한가지 짚고 넘어갈 것이 있습니다. idHTTP를 사용했을 때 한글이 항상 깨지는 것은 아니라는 것입니다. 2009 버전에 번들된 Indy 버전에서는 받아오려는 HTML 페이지의 charset이 'utf-8'일 경우 깨지지 않고 'euc-kr'이나 'ks_c_5601-1987'인 경우에만 깨집니다. 2010 버전에 번들된 Indy의 경우, HTTP 헤더에서 charset을 지정된 경우에는 'utf-8'이 아닌 'euc-kr'이나 'ks_c_5601-1987'인 경우라도 깨지지 않으며 charset 지정이 없는 경우에만 깨집니다. (물론 위 코드를 사용하면 어떤 경우에든 안깨집니다)
한글이 깨어졌던 이유를 간단히 말씀드리자면, Indy 코드가 html 텍스트를 받아오는 과정에서 charset(인코딩)을 제대로 인식하지 못해서 엉뚱한 인코딩으로 풀어버린 것입니다. 그래서 메모리스트림으로 받아서 Indy 라이브러리가 인코딩을 직접 해석하지 않도록 강제한 후, 다시 스트림의 메모리 포인터를 코드페이지를 가지지 않는 무변환 스트링 타입인 RawByteString 타입으로 받아서 강제로 코드페이지를 한글인 949(euc-kr)로 지정합니다.
Delphi/C++Builder 2009 버전에 번들된 Indy에서는 이 charset에 대한 고려가 제대로 되어 있지 않습니다. 반면 2010 버전에서는 charset에 대한 처리가 아주 훌륭하게 되어 있는데요, 그럼에도 한글이 깨어지는 것은, HTTP 헤더에서 charset이 지정되지 않은 경우 기본 디폴트 charset 값의 처리 때문입니다. 그래서 2010 버전에서는 charset을 제대로 지정하면 한글 페이지라도 깨지지 않는 것이구요.
또 한가지 중요한 것. idHTTP로 받아오는 html 페이지가 'utf-8'로 되어 있는 경우, 코드페이지 949로 강제해버리면 당연히 깨져버립니다. 그래서 charset이 'utf-8'로 지정된 경우에는 'utf-8'의 코드페이지인 65001을 지정합니다.
참고로, 이 블로그의 charset은 'utf-8' 이고, 볼랜드포럼의 경우 charset이 'ks_c_5601-1987' 이지만 HTTP 헤더에서 넘겨주지 않구요. 델마당의 경우 charset이 'euc-kr' 이면서 역시 HTTP 헤더에서 charset을 넘겨주지 않습니다. (따라서 위와 같은 회피책을 사용하지 않고 idHTTP를 써서 볼랜드포럼과 델마당의 페이지를 Get 하면 깨지지만 이 블로그의 페이지들은 깨지지 않을 것입니다)
오늘 저녁쯤에는, idHTTP의 Post를 사용했을 때의 문제를 해결하는 코드를 보여드리도록 하겠습니다.
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
comment