델파이

VMProtect

lain — Sat, 15 Jan 2011 17:01:28 +0900

실행파일을 패킹 해주는 프로그램으로 x64비트를 지원합니다.

Delphi에서 인라인 어셈블리 사용하기

훅크선장 — Tue, 19 Oct 2010 16:37:29 +0900

자유게시판에 비슷한 내용이 올려져 있길래, 최근에 제 블로그에 포스팅한 내용을 올려봅니다.

델파이(Delphi 2010)에서 인라인 어셈블리(inline Assembly) 사용하기

얼마전 받은 교육이 “악성코드 분석” 이었는데, 교육중에 주로 악성코드보다는 초급자를 위한 Crackme 나 KeygenMe 프로그램을 주로 분석하있다.

간단하게 Keygen을 만들려고 하니, 일일히 어셈블리 코드를 분석해서, C 언어나 Python 으로 변환하기가 너무 귀찮은 경우가 생겨서, 델파이에 인라인 어셈블리를 적용하는 방법을 찾아내었다.

알고보니 너무 간단하고, 참 쉽다.

asm

...

end;

지시어 안에, 어셈코드를 넣기만 하면 된다.

그러나, 올리디버거(OllyDbg v1.10)에서 가져온 어셈블리 코드를 델파이에 적용하는 경우에 반드시 주의하여야 하는 사항은 다음과 같다.

1. 함수 인자값들은 반드시 레지스터에 저장해서 연산하여야 한다. 함수 인자는 바로 연산문에 사용할 수 없다. (지역변수는 변수명으로 바로 사용할 수 있다.)

* 참고: var 지정(내부에서 변하는 변수)이 아닌 일반 함수 인자들은 EBP를 기준으로 접근할 수 있습니다. 인자값이 변하지 않는 상수라면, 레지스터에 복사하지 않고 바로 사용할 수 있습니다. 문자열을 인자로 주었다면, 꼭 레지스터에 복사해야 합니다.

함수인자는 뒤에서 부터 차례로 DWORD PTR [EBP-04h], DWORD PTR [EBP-08h, DWORD PTR [EBP-0Ch] 로 접근 가능합니다.

2. 어셈블리 코드안에서 사용하는 모든 레지스터는 반드시 사용전에 PUSH 하고, 사용후에 POP 해야한다. (레지스터를 초기화하는 것도 오류를 없애기 위해서는 당연히 사용해야 한다.)

3. 올리디버거에서 추출된 어셈블리 코드안의 숫자값은 모두 16진수 이므로, 인라인 어셈블리 코드로 사용하려면, 모든 숫자값에는 16진수 임을 알리는 “h” 문자를 추가하여야 한다. (MOV EAX, 20 이렇게 되어 있다면, 반드시 MOV EAX, 20h 로 바꾸어야 한다.)

4. 문자열은 주소값으로 연산되므로, 포인터 연산에 주의를 해야한다.(너무나도 당연한 말이다.)

예제 코드를 보여본다. (함수내에서 인자값을 바꾸는, 포인터 연산도 포함되어 있다.)

-------------------------------------------------------------------------

function TMainForm.keygen1(aStr: AnsiString; aStr_len: Integer; var ret:Integer):Cardinal;

var

ret2 : Integer;

begin

asm

PUSH EDX // Safe Store before use

PUSH ECX

PUSH EBX

PUSH EAX

PUSH ESI

PUSH EDI

XOR EDI, EDI // init value := 0

XOR ESI, ESI

XOR EDX, EDX

XOR ECX, ECX // ecx := 0, init value

XOR EBX, EBX // ebx := 0, init value

XOR EAX, EAX

MOV EDX, aStr_len // copy string length

MOV ESI, [aStr] // load string address

MOV EDI, [ret] // load integer value address

@@LOOP: // Label

MOV AL, BYTE PTR [ESI+ECX]

INC ECX

XOR EAX, ECX

ADD EBX, EAX

CMP ECX, EDX

JNZ @@LOOP // conditional jump to Label

IMUL EAX, EAX, 6h

MOV DWORD PTR [EDI], EBX // pointer variable value copy

SHL EBX, 7h

MOV ret2, EBX // local variable value copy

ADD EAX, EBX

MOV @Result, EAX // return value : Result

POP EDI // restore value

POP ESI

POP EAX

POP EBX

POP ECX

POP EDX

end;

Doc-O-Matic

lain — Thu, 30 Sep 2010 09:32:34 +0900

http://www.doc-o-matic.com/

소스코드를 문서화해주는 프로그램으로 장난아니게 좋습니다.

상용이며 독시즌쓰시는 분들은 한 번 이거 써보시면 매우 만족하실듯합니다. ㅎㅎ

화면 UI는 다음과 같구요..

결과물은 다음과 같이 MSDN형태로 나오게 해봤습니다.

결과물은 탬플릿으로 선택할 수 있어서 다양한 결과물 도출이 가능합니다.

ImageEn - 그래픽 라이브러리

lain — Sun, 05 Sep 2010 11:24:49 +0900

요번에 dcu 형태로 풀린 라이브러리로 엄청나게 많은 이미지 포맷을 지원합니다.

개인적으로 좀 마음에 안드는 부분은 데모에 있는 예제들에 UI가 넘 허접해보입니다.-_-

http://www.hicomponents.com/main/

GLScene 3D Controls (GL3DC)

lain — Mon, 30 Aug 2010 21:27:19 +0900

http://sourceforge.net/projects/glscene3dcontro/

델파이로 3D 컨트롤을 구현합니다. 제가 해당 프로젝트를 정확히 보질 않아서 그 외에 어떤 기능들이 있는지는 모르겠네요. ㅎㅎ

PortableApps.com: Portable Software/USB

lain — Mon, 30 Aug 2010 21:17:56 +0900

http://sourceforge.net/projects/portableapps/

포타블 프로그램들을 관리해주는 프로그램으로 해당 스크린샷에 UI만 델파이로 만들어져 있습니다.

PeaZip - 압축 프로그램

lain — Mon, 30 Aug 2010 20:40:26 +0900

https://sourceforge.net/projects/peazip/

이 글을 올리는 시점에 SourceForge에 Backup 카테고리에서 2위를 달리고 있는 프로그램입니다.

크로스 플랫폼을 위해서 프리파스칼과 라자루스에서 개발되고 있습니다.

( 델파이는 아니지만 올리겠습니다. )

Ares Galaxy - 음악, 영화 공유

lain — Mon, 30 Aug 2010 20:22:36 +0900

http://sourceforge.net/projects/aresgalaxy/

TurboPower Async Professional - 시리얼 제어 등..

lain — Mon, 30 Aug 2010 20:20:04 +0900

http://sourceforge.net/projects/tpapro/

Async Professional (AsyncPro)컴포넌트는 시리얼 제어, TAPI(전화 및 팩스), 터미널 개발 등의 기능을 개발하기에 좋은 것이니 참고 바랍니다.

TurboPower Abbrevia - 압축 컴포넌트

lain — Mon, 30 Aug 2010 18:22:53 +0900

http://sourceforge.net/projects/tpabbrevia/

데브기어 블로그에도 있어서 이곳에 올립니다.

ThinVNC- HTML5 Remote Desktop

lain — Sat, 28 Aug 2010 20:27:29 +0900

http://sourceforge.net/projects/thinvnc/

서버는 ics 컴포넌트 기반에 델파이로 작성되어 있으며 클라이언트는 HTML5를 지원하는 웹브라우저를 사용하는

원격 데스크톱 프로젝트입니다. 상당히 기대가 되는 프로젝트로 GPL 라이센스입니다.

Andorra 2D - 2D 그래픽엔진

lain — Sat, 28 Aug 2010 20:13:50 +0900

http://andorra.sourceforge.net/

위에 주소로 가시면 좋은 샘플들이 있습니다.

Auto-increment build number

lain — Sat, 28 Aug 2010 19:40:50 +0900

위에 그림처럼 체크를 하면 빌드 시마다 자동으로 빌드넘버가 올라갑니다.

지금까지 이런게 있는줄도 몰랐네요.

RAD Studio XE 프리뷰 #3 - 멀티 티어, 클라우드 및 웹

esniper — Thu, 26 Aug 2010 10:24:23 +0900

-멀티 티어 개발을 더욱 확장해주는 새로운 위저드들, 새로운 프로토콜 지원, 암호화 및 압축, 클라우드 서버, PHP/자바스크립트 클라이언트

-Windows Azure 서비스에 대한 클라우드 컴퓨팅 액세스

-Amazon EC2 클라우드 서버에 빠르게 배포 가능

-RadPHP, IP*Works, IntraWeb XI 등으로 웹 애플리케이션 개발의 새로운 방법들을 제시

Base64 Encoding & Decoding 소스

훅크선장 — Mon, 23 Aug 2010 12:52:11 +0900

Base64 Encoding & Decoding 소스 입니다.

남의 것을 가져다가, 수정했습니다. (출처: http://www.delphipraxis.net/991-base64-mime-en-decoding.html)

Delphi 2009 & 2010 에서 사용할 수 있도록 소스 수정하였습니다.

Delphi 2010 에서 테스트하였습니다.

그러나, 아직 Ansi 용입니다.

Unicode용은 어떻게 Base64 인코딩, 디코딩하는지 알아보는 중입니다. (아시는 분 있으면 알려주세요~.)

Base64 Encoding과 Decoding을 델파이 내장 모듈을 이용해서 다음과 같이 쉽게 할 수도 있습니다. (출처 : http://strcpy.com/294)

uses IdCoder, IdCoder3to4, IdCoderMIME, jpeg;

function Base64Decode(const Text : ansiString): ansiString;
var
Decoder : TIdDecoderMime;
begin
Decoder := TIdDecoderMime.Create(nil);
try
Result := Decoder.DecodeString(Text);
finally
FreeAndNil(Decoder)
end
end;

function Base64Encode(const Text : ansiString): ansiString;
var
Encoder : TIdEncoderMime;
begin
Encoder := TIdEncoderMime.Create(nil);
try
Result := Encoder.EncodeString(Text);
finally
FreeAndNil(Encoder);
end
end;

하지만, 첨부된 소스와 같이, 어셈블러를 사용하는 것이 속도가 훨씬 빠르다고 합니다. (원 저자의 주장에 의하면...)

쓸모가 있다고 생각하시면 사용하시고, 아니면 어쩔 수 없습니다.

눈팅만 하기 머해서, 최근에 설치한 Delphi 2010 에서 처음 시도해 본 소스 수정이라, 함 올려봤습니다.

감사합니다~.

WinLicense - 소프트웨어 보호 및 라이센스 적용

lain — Fri, 20 Aug 2010 20:01:54 +0900

http://www.themida.com/winlicense.php

Delphi 입니다.

사내 인트라넷용 후이즈 화상회의

kazankros — Fri, 20 Aug 2010 13:29:38 +0900

http://whoisdesk.net/

델마당에 4000king님이신 4NB에서도 화상회의를 델파이로 제작 하셨지만,

( 4NB는 전문 화상회의 업체입니다. :) )

급하게 오픈하느라 버그는 좀 많지만 후이즈 메신저가 소개된김에.. 하나 더 소개합니다.

최대한 간단하면서도, 소규모 기업을 대상으로 개발된것이며,

UDP Hole Punching의 기술이 들어갔으며(구현 어렵거나 중요한 기술은 아닙니다)

이는 이미 델마당 자료실에 소스 통채로 (TCP/UDP) 공개는 해 두었습니다 ^^; (델마당 닉 : 무대뽀)

버그는 사용자가 그리 많지는 않아서 ...

이외에도, 후이즈 그룹웨어에 사용되는 모든 ActiveX, 어플리케이션,

그리고 그룹웨어 이외에도 웹서버로 구현할 수 없는 서버단 및 어플은 모두 델파이로 개발되어 있습니다 ^^;

FreeCommander - 파일관리툴

esniper — Fri, 20 Aug 2010 00:36:34 +0900

http://www.freecommander.com/

정말 편리한 파일관리툴입니다. 탐색기를 대응하는 그런 툴이죠.

한글화도 되어있어서 쓰기 편리합니다.

주요기능은 아래와 같습니다.

Dual-panel technology - horizontal and vertical
Tabbed interface
Optional tree view for each panel
Built in file viewer to view files in hex, binary, text or image format
File viewer inside archives too
Built in archive handling: ZIP (read, write), CAB (read, write), RAR (read)
Nested archive handling
Built in FTP client
Easy access to system folders, control panel, desktop and start menu
Copy, move, delete, rename files and folders
Multi rename tool
Wipe files
Create and verify MD5 checksums
File splitting
File properties and context menu
Calculation of folder size
Folder comparison / synchronization
Modification of file date and attributes
Folder / program favorites
File searching (inside archive too)
File filters for display
User defined columns for detailed view
DOS command line
Multiple language support

RAD Studio XE 프리뷰 #2 - 최적화와 자동화

lain — Thu, 19 Aug 2010 14:49:03 +0900

- FinalBuilder 툴(엔터프라이즈/아키텍트)로 빌드 프로세스를 자동화
- 커맨드라인 오딧, 메트릭, 문서 생성으로 자동화된 빌드에 이전보다 더욱 많은 기능을 추가
- AQTime 프로파일링 기능으로 고성능 애플리케이션 개발 가능
- CodeSite 로깅 툴로 고품질 애플리케이션 개발

JSON delphi library 1.07 - 한글 및 다국어 지원

lain — Wed, 18 Aug 2010 10:16:59 +0900

lkJSON-1.07.7z

JSON delphi library 1.07 버전에 다국어 지원이 제대로 안되서 임의로 제가 수정하였습니다.

다음과 같은 사항이 수정되었습니다.

* 델파이 2010 이상에서만 지원합니다. 그 이하버전에서는 테스트를 하지 않았습니다.

* sample1에 TlkJSON.ParseText 함수를 사용 시 한글로 된 문자열이 있으면 깨지는
* 문제점 수정
*
* TlkJSONstreamed 클래스가 제거되었습니다. 대신 TlkJSONFile 클래스가 추가되었습니다.
* 기존에 TlkJSONstreamed는 유니코드를 제대로 지원하지 않아서 TlkJSONFile에서
* 저장이나 로드 시 유니코드를 제대로 지원하도록 하였으며, 기본으로 UTF8 인코딩을 따릅니다
* 인코딩을 추가적으로 다른걸 사용하려면 함수를 오버로드해서 만들면 됩니다.
* 스트림을 지원하려면 기존에 TlkJSONstreamed를 추가하셔서 따로 만들어야 합니다.
*
* LkJSON에 새로운 버전이 나오면 위에 버그들이 수정되었을 수도 있으니 해당 버전을
* 사용하시면 됩니다.

NativeXml - XML 파싱

lain — Wed, 18 Aug 2010 09:47:56 +0900

http://www.simdesign.nl/xml.html

OmniXML - XML 파싱

lain — Wed, 18 Aug 2010 09:47:11 +0900

http://www.omnixml.com/

C++ Builder 저널

lain — Wed, 18 Aug 2010 09:46:12 +0900

http://bcbjournal.org/?loc=home

JSON delphi library

lain — Tue, 17 Aug 2010 14:58:38 +0900

http://sourceforge.net/projects/lkjson/

델파이용 json 라이브러리입니다.

uTrace.pas - MFC에 TRACE와 동일한 역할을 합니다.

lain — Mon, 16 Aug 2010 20:54:12 +0900

uTrace.pas

MFC에는 있는데 델파이에는 없어서 만들었습니다.

MFC에 Trace랑은 완전히 동일하여 포맷 문자열을 지원하며 릴리즈로 빌드 시 디버그뷰에 출력되지 않습니다.

즉, 다음과 코드를 작성하여 디버그뷰에 출력할 수 있습니다.

Trace('여기가 실행되었습니다.');
Trace('값 : %d', [100]);

소스는 매우 간단합니다.

ISSkin - InnoSetup 스킨입혀주는 툴

lain — Mon, 16 Aug 2010 17:38:41 +0900

http://isskin.codejock.com/

codejock 에서 만든걸로 InnoSetup에 부가적인 스킨을 입혀줍니다.

Delphi/C++Builder XE 발표 세미나 - 9월 2일

esniper — Mon, 16 Aug 2010 10:36:17 +0900

Delphi/C++Builder의 새로운 버전인 XE에 대한 발표 세미나가 9월 2일 목요일에 열립니다. 장소는 삼성동 섬유센터 3층이구요. 오전 9시 30분부터 시작합니다.

XE 버전은 2011 버전으로 알려졌던 것으로, 코드 프로파일링/최적화와 자동화, 데이터베이스 지원 강화, 에디터 기능 및 UML 모델링 기능 등 IDE 기능 강화, 웹/클라우드 개발 지원, 빌드 지원 강화 등의 최신 기능을 갖추었습니다.

발표자는 저희 본사의 Delphi/C++Builder 관련 아키텍트인 존 캐스터(John Caster), 저희 데브기어의 델파이 전담 강사님이신 김원경 강사님, 애자일 전도사로 유명하신 애자일컨설팅의 김창준 대표님, 그리고 저 임프 이렇게 네 명입니다.

자세한 내용은 아래 저희 데브기어 홈페이지의 세미나 안내 페이지에서 보실 수 있습니다.
http://www.devgear.co.kr/rad-studio-xe-preview/seminar_radstudio_xe.html

많은 개발자분들이 참석해서 최신 기술 동향을 살펴보시길 바랍니다.

ImageFileLib - 특정 포맷에 이미지를 읽고 쓰기

lain — Mon, 16 Aug 2010 10:11:55 +0900

http://logicnet.dk/lib/

오픈캡쳐에서 쓰고 있는 라이브러리로 좀 오래 된 라이브러리이지만 만족하면서 쓰고 있습니다.

다음과 같은 포맷을 읽고 쓸 수 있습니다.

BMP, JPEG, JPEG 2000, PNG, MNG, TIFF, ICO, CUR, PCX

다음과 같은 포맷을 읽을 수 있습니다.

RAS, PNM, PGM, PPM, HIPS

Indy - 네트워크 컴포넌트

lain — Mon, 16 Aug 2010 10:08:37 +0900

http://www.indyproject.org/index.en.aspx

너무 당연해서 게시물에 올라오지 않았나봅니다.

그래서 올립니다.

정말 혹시나 해서 말씀드리는데 델파이에 기본으로 포함되어 있습니다.

JSON – SuperObject

lain — Sun, 15 Aug 2010 20:13:54 +0900

http://www.progdigy.com/?page_id=6

Delphi 에서 Json을 사용할 수 있게 하는 라이브러리입니다.

물론 최신에 델파이 2010에서는 기본으로 들어가 있지만 아무튼 이 라이브러리는 매우 강력합니다.

다음 동영상은 SuperObject와 RTTI을 통한 클래스에 정보를 json포맷으로부터 읽어오고 또는 저장하는 방법을 보여줍니다.

대단하죠. 이 정도 수준이라면 소켓으로 클래스 자체를 보낼 수도 있을 정도입니다.-_-

OAuth for Delphi

lain — Sun, 15 Aug 2010 20:09:50 +0900

http://sourceforge.net/projects/oauthdelphi/files/

델파이용 OAuth 인증 라이브러리입니다. 물론 인증할때만 쓰는거는 아니고 Get, Post 할때도 쓰입니다.

현재 프로젝트는 진행중이며 릴리즈 된 버전이 없기 때문에 svn에서 받아서 사용하셔야 합니다.

그래도 사용하는데에는 크게 문제가 없습니다.

dxgettext - 델파이 다국어개발 라이브러리

lain — Sun, 15 Aug 2010 18:50:25 +0900

http://dxgettext.po.dk/

회사에서 쓰고 있는데 아주 좋습니다.

델파이에서 다국어버전을 이용하여 개발을 할 때 이 라이브러리를 사용하면 손쉽게 개발이 가능합니다.

사실 라이브러리라기보다는 pas 파일하나와 기본으로 제공하는 툴과 poedit에 조합이라고 볼 수 있습니다.

Delphi 2009 이상에 사용자분은 컴파일이 안될 수 있으므로 아래에 주소에서 pas만 받으시면 됩니다.

Delphi 2009 compatible gnugettext.pas

AggPas - C++용 Agg를 오브젝트 파스칼용으로 컨버팅

lain — Sun, 15 Aug 2010 18:46:48 +0900

http://www.crossgl.com/aggpas/index.html

2D 그래픽 관련 라이브러리인 Agg를 파스칼로 포팅한 새로운 라이브러리로 매우 강력합니다.

정말 대단한 라이브러리입니다.

Delphi 2009 GDI+ Library

lain — Sun, 15 Aug 2010 18:42:05 +0900

http://www.bilsen.com/gdiplus/index.shtml

델파이에서 GDI+ 를 사용하기 위한 라이브러리로써 엠바카데로 사이트에서도 링크가 걸려있으니 괞찮은 라이브러리로 보입니다.

사이트를 둘러 보시면 다른 좋은 예제도 있습니다.

TJvThread를 절대로 쓰면 안되는 이유

lain — Sun, 15 Aug 2010 10:39:36 +0900

회사에서 작업을 하다가 TJvThread 라는 Jedi에서 제공해주는 매우 편리한 클래스가 있어서 계속해서 사용하고
있었는데 끝에가서는 매우 심각한 문제를 하나 발견하였습니다.
그래서 결국에는 기본 스레드 라이브러리로 바꿔야 할 상황이 발생하였는데 이에 대해서 설명을 해볼까 합니다.
( 아무래도 Jedi 라이브러리가 좀 오래되다보니 이제는 기본 VCL 클래스가 훨씬 구현이 잘 되어 있습니다. )

문제가 발생하는 코드는 다음과 같습니다.

type
TForm2 = class(TForm)
    JvBackgroundWorkThread: TJvThread;

   ................................

procedure TForm2.FormCreate(Sender: TObject);
begin
ReportMemoryLeaksOnShutdown := True;

Application.Terminate;
JvBackgroundWorkThread.Execute(Nil);
end;

procedure TForm2.FormDestroy(Sender: TObject);
begin
JvBackgroundWorkThread.Terminate;
JvBackgroundWorkThread.WaitFor;
end;

procedure TForm2.JvBackgroundWorkThreadExecute(Sender: TObject; Params: Pointer);
var
dwOldTime: DWORD;
begin
while True do
begin
    dwOldTime := GetTickCount;
    while True do
    begin
      if (GetTickCount - dwOldTime) >= 1000 then
        break;

      if JvBackgroundWorkThread.Terminated then
      begin
        Exit;
      end;

    end;
end;

end;

일단 JvBackgroundWorkThreadExecute 메소드를 보면 if (GetTickCount - dwOldTime) >= 1000 then 에서
break를 하긴 하지만 결과적으로 또 중첩 while문에 의해 다시 저 루프안으로 또 들어가게 되어 있습니다.
사실 1초당 어떠한 작업을 해주는 코드가 들어가 있었는데 공개적으로 소스를 올려야 하기 때문에 제가
일부분에 내용을 지운것이구요.

FormCreate 부분에 ReportMemoryLeaksOnShutdown := True; 를 주목하셔야 됩니다.
프로그램 종료 시 메모리릭을 체크하도록 하였습니다.
그 다음에는 Application.Terminate;를 호출합니다. 조금 어색해보일수 있지만 이 작업은 매우 안전합니다.
단순히 내부적으로 PostQuiteMessage를 날리기만 하며 바로 폼이 종료되도록 요청하게 됩니다.

그리고 그 다음에는 JvBackgroundWorkThread.Execute(Nil); 함수를 호출하여 실제 스레드를 호출합니다.

이제 스레드는 동작할것이며 스레드는 JvBackgroundWorkThread.Terminated 를 멤버변수를 계속해서 체크하여
종료할지 여부를 결정합니다.

이제 FormDestroy로 가봅니다.
JvBackgroundWorkThread.Terminate; 를 처음에 호출합니다.
이 작업은 TJvThread가 가지고 있는 스레드목록들에 대해서 모두 Terminated 변수를 True로 바꿔주는 역할을 합니다.
( TJvThread는 싱글스레드만 고려한게 아니라 스레드를 리스트로 관리하는 클래스임을 알 수 있습니다. )

단순히 Terminated 변수만 True로 바꿔서 이제 종료를 알리는 체크를 할뿐입니다.
그 외에 작업을 하지 않습니다.

이제 가장 중요하고 가장 위험한 함수인 JvBackgroundWorkThread.WaitFor; 를 호출하고 있습니다.
바로 여기가 문제입니다.
Jedi에 WaitFor에 내부구현은 다음과 같습니다.

procedure TJvThread.WaitFor;
begin
while OneThreadIsRunning do
    Application.HandleMessage;
end;

참으로 황당하게 구현이 되어 있죠?
OneThreadIsRunning 은 다음과 같이 구현됩니다.

function TJvThread.GetOneThreadIsRunning: Boolean;
var
I: Integer;
List: TList;
begin
Result := False;
List := FThreads.LockList;
try
    for I := 0 to List.Count - 1 do
    begin
      Result := not TJvBaseThread(List[I]).Finished;
      if Result then
        Break;
    end;
finally
    FThreads.UnlockList;
end;
end;

스레드 목록을 순회해서 Finished 멤버변수를 체크하여 다 종료되기까지 기다리고 있습니다.
그럼 Finished 멤버변수는 언제 True로 셋팅이 되는지 봐야 됩니다.

바로 아래에 함수에서 True로 셋팅하게 됩니다.
또한 리스트에서 스레드 오브젝트를 삭제하고 있습니다. ( 객체가 Free되지는 않고 리스트에서만 삭제됩니다. )

procedure TJvThread.DoTerminate(Sender: TObject);
begin
TJvBaseThread(Sender).FExecuteIsActive := False;
if Assigned(FOnFinish) then
    try
      FOnFinish(Sender);
    except
      // DoTerminate is part of destructor; destructor should not raise exceptions
    end;

if TJvBaseThread(Sender).FreeOnTerminate then
    FThreads.Remove(Sender);
TJvBaseThread(Sender).FFinished := True;

if Count = 0 then
begin
    CloseThreadDialogForm;
    if Assigned(FOnFinishAll) then
      try
        FOnFinishAll(Self);
      except
      // DoTerminate is part of destructor; destructor should not raise exceptions
      end;
end;
end;

그럼 이제 DoTerminate는 어디서 호출이 되는지 봐야 합니다.

여기서부터 델파이에 내부적인 스레드 생성 개념에 대해서 어느정도 이해를 하고 있어야 합니다.
델파이에서는 내부적으로 TThread로 스레드를 생성할때 스레드가 중지 된 상태로 실행하게 됩니다.

TThread에 생성자를 보면 다음과 같습니다.
constructor TThread.Create(CreateSuspended: Boolean);
{$IFDEF LINUX}
var
ErrCode: Integer;
{$ENDIF}
begin
inherited Create;
FSuspended := CreateSuspended and not FExternalThread;
FCreateSuspended := CreateSuspended and not FExternalThread;
if not FExternalThread then
begin
{$IFDEF MSWINDOWS}
    FHandle := BeginThread(nil, 0, @ThreadProc, Pointer(Self), CREATE_SUSPENDED, FThreadID);
    if FHandle = 0 then
      raise EThread.CreateResFmt(@SThreadCreateError, [SysErrorMessage(GetLastError)]);
{$ENDIF}
{$IFDEF LINUX}
    sem_init(FCreateSuspendedSem, False, 0);
    ErrCode := BeginThread(nil, @ThreadProc, Pointer(Self), FThreadID);
    if ErrCode <> 0 then
      raise EThread.CreateResFmt(@SThreadCreateError, [SysErrorMessage(ErrCode)]);
{$ENDIF}
end else
begin
{$IFDEF MSWINDOWS}
    FHandle := Windows.GetCurrentThread;
    FThreadId := Windows.GetCurrentThreadId;
{$ENDIF}
end;
end;

BeginThread는 System.pas에 내부적으로 정의 된 함수입니다.
CREATE_SUSPENDED를 넣어주고 있는데 이게 결과적으로 WINAPI에 스레드 생성옵션이 되게 됩니다.
저렇게 하드코딩이 된 상태로 중지 된 상태로 스레드가 만들어집니다.
그렇다면 스레드가 실제로 어디서 실행되는지를 알아야 하는데 TThread에 생성자가 호출되어서 그 생성자에 코드가 실행
된 후에 end;를 만나는 지점에서 실행됩니다. 조금 이해가 안 가실수도 있는데 이것은 AfterConstruction 함수를 오버라이드
함으로써 구현되며 다음과 같은 코드가 생성됩니다.

Classes.pas.11074: end;
0043DEDB 33C0             xor eax,eax
0043DEDD 5A               pop edx
0043DEDE 59               pop ecx
0043DEDF 59               pop ecx
0043DEE0 648910           mov fs:[eax],edx
0043DEE3 68F8DE4300       push $0043def8
0043DEE8 8D45F0           lea eax,[ebp-$10]
0043DEEB E88489FCFF       call @UStrClr
0043DEF0 C3               ret
0043DEF1 E9BE78FCFF       jmp @HandleFinally
0043DEF6 EBF0             jmp $0043dee8
0043DEF8 8BC6             mov eax,esi
0043DEFA 807DFF00         cmp byte ptr [ebp-$01],$00
0043DEFE 740F             jz $0043df0f
0043DF00 E84374FCFF       call @AfterConstruction
0043DF05 648F0500000000   pop dword ptr fs:[$00000000]
0043DF0C 83C40C           add esp,$0c
0043DF0F 8BC6             mov eax,esi
0043DF11 5E               pop esi
0043DF12 5B               pop ebx
0043DF13 8BE5             mov esp,ebp
0043DF15 5D               pop ebp
0043DF16 C3               ret
0043DF17 90               nop

함수에 맨 끝에서 AfterConstruction를 호출하게 되고 결과적으로 다음과 같은 코드에 의해 스레드가 실행되게 됩니다.
procedure TThread.AfterConstruction;
begin
if not FCreateSuspended and not FExternalThread then
    InternalStart(True);
end;

그러나 이 경우에는 실제 TThread를 생성할 때 스레드가 중지되어 있는 상태로 실행할지 아니면 실행중인 상태로
될지에 대해 결정하게 되는데 TJvThread에 경우에는 중지된 상태로 실행되도록 강제하며 AfterConstruction이 아닌
function TJvThread.Execute(P: Pointer): TJvBaseThread; 함수에서
    if FRunOnCreate and Assigned(BaseThread) then
      Resume(BaseThread);
와 같이 스레드를 실행하게 됩니다.

또한 BeginThread는 내부적으로 ThreadWrapper라는 전역으로 정의 된 System.pas를 스레드 엔트리 포인트로 받아서
실제 사용자에 스레드시작 루틴이 아니라 저 루틴부터 스레드가 실행되며 저기서 다시 Classes.ThreadProc 전역 메소드를
호출하게 되어 실제 사용자에 스레드 루틴을 호출하게 되는 것입니다.

그럼 다시 아까에 원래의 코드로 돌아가봅니다.
TJvThread에 WaitFor 구문을 이전에 보고 있었고 DoTerminate는 언제 호출되는지 알아야 합니다.
이 함수가 호출 될 때 WaitFor 구문이 끝나게 되기 때문입니다. ( Finished 멤버변수에 값을 여기서 바꾸기 때문에.. )
이 함수는 이전에 말한 ThreadProc에서 호출됩니다.

다음과 같이 생겼습니다.
function ThreadProc(Thread: TThread): Integer;
var
FreeThread: Boolean;
begin
TThread.FCurrentThread := Thread;
{$IFDEF LINUX}
if Thread.FSuspended then sem_wait(Thread.FCreateSuspendedSem);
{$ENDIF}
try
    if not Thread.Terminated then
    try
      Thread.Execute;
    except
      Thread.FFatalException := AcquireExceptionObject;
    end;
finally
    FreeThread := Thread.FFreeOnTerminate;
    Result := Thread.FReturnValue;
    Thread.DoTerminate;
    Thread.FFinished := True;
    SignalSyncEvent;
    if FreeThread then Thread.Free;
{$IFDEF MSWINDOWS}
    EndThread(Result);
{$ENDIF}
{$IFDEF LINUX}
    // Directly call pthread_exit since EndThread will detach the thread causing
    // the pthread_join in TThread.WaitFor to fail. Also, make sure the EndThreadProc
    // is called just like EndThread would do. EndThreadProc should not return
    // and call pthread_exit itself.
    if Assigned(EndThreadProc) then
      EndThreadProc(Result);
    pthread_exit(Pointer(Result));
{$ENDIF}
end;
end;

Thread.Execute; 한 후에 finally 구문에서 DoTerminate 호출해주는것을 볼 수 있습니다.
그리고 멀티스레드에 안전한 작업을 위해 Synchronize를 통해 내부적으로 메인 스레드에게 알리게 됩니다.

이전에 WaitFor를 하는 함수는 내부적을 HandleMessage 함수를 호출하고 이 함수는 싱크로나이즈 된 함수가
큐잉되었는지 체크하고 ( 내부적으로 리스트로 가지고 있습니다. ) CheckSynchronize를 계속 호출하며
결과적으로 procedure TJvThread.DoTerminate(Sender: TObject); 함수가 호출되어 이 때, FFinished에 멤버변수가 바뀌게
되는 것입니다.

바로 이 부분이 문제입니다. 싱크로나이즈 된 함수가 호출되었고 FFinished에 멤버변수를 바꾸게 되는데
이 변수를 바꿨지만 실제로 이 상황에서는 스레드가 종료 된 상태가 아니라는 것입니다.
( 싱크로나이즈 함수를 호출한 스레드는 아직 종료가 되지 않을 수 있습니다. 이것은 엄청난 타이밍 문제로
발견하기가 매우 힘듭니다.-_- )

스레드는 계속해서 실행중이며 종료가 되지 않았습니다. 그러나 Jedi에 스레드 라이브러리는 이렇게 종료가 되었다라고
체크를 하고 있습니다.
고로 WaitFor;를 호출한 프로그래머입장에서는 이 WaitFor; 함수에 호출이 끝나는 순간 스레드는 종료가 되어 있다라고
가정해야 하는데 실제로는 함수에 호출이 끝나고 스레드는 계속 실행중인 경우가 생길 수 있습니다.
실제로 WaitFor; 함수를 호출후에 스레드 목록을 보면 Jedi 스레드는 계속 해서 남아있습니다.
( 이건 시스템 상황에 따라 다릅니다. 방금 말햇듯이 타이밍 문제가 있기 때문입니다. )

심지어 Jedi에 TJvThread는 소멸자에서 조차 스레드에 종료시점을 저런식으로 체크하고 있습니다.
이러한 방법은 스레드에 완벽한 종료시점을 알 수가 없게 되며 타이밍에 의해서 스레드는 계속 해서 실행 된 상태가 될 수가
있고 폼을 종료 시 다음과 같은 치명적인 오류가 랜덤하게 날 수 있습니다.
( 그러나 물리 PC에서는 이것이 보기가 힘듭니다. 제 VMWare PC에서는 해당 예제가 Windows 7에서 동작 시
에러가 발생할 확률이 매우 높습니다. 물론 랜덤입니다. )

위에 에러는 타이밍에 의해 스레드가 종료되지 않았고 메인 스레드가 종료되면서 맨 마지막으로 FastMM으로
메모리릭을 리포팅해주었으며 메모리릭을 리포팅해주는 그 순간에 스레드가 종료되면서 자기자신을 소멸하게 되는데
이 때 겹쳐서 발생하는 문제로 보입니다.

스레드가 종료 시 자기자신을 소멸시키는것은
function ThreadProc(Thread: TThread): Integer; 에서 if FreeThread then Thread.Free; 를 통해 소멸시키게 됩니다.

따라서 어떠한 경우 메모리릭에 대한 리포팅이 안 나고 바로 정상적으로 종료 된 경우에는 메모리릭을 체크하는 루틴이
실행되기전에 운 좋게 스레드가 종료되었으며 ( 이러한 경우가 거의 99%입니다. ) 메모리릭을 체크하는 루틴이
실행되는 경우에는 아직 스레드 루틴에 if FreeThread then Thread.Free; 가 호출되지 않았기 때문입니다.

델파이에서 기본으로 제공해주는 스레드 라이브러리는 WaitFor 시 메인 스레드에 한해서 MsgWaitForMultipleObjects
로 스레드 종료를 대기하고, 다른 스레드일 경우 WaitForSingleObject로 대기함으로 완벽한 스레드 종료를 체크하기 때문에
전혀 문제가 없습니다.

IOCP를 이용한 멀티스레드에 동시접근가능한 제네릭 큐

lain — Sun, 15 Aug 2010 10:38:40 +0900

제가 델파이 2010을 사용하면서 언어적으로 마음에 들었던 부분이 Delphi 2009부터 추가 된 제네릭 문법 지원이었습니다.
이와 관련해서 기본적인 제네릭 클래스들이 추가가 되었는데 안타깝게도 멀티 스레드에 안전한 제네릭 큐가 없어서
임의로 가장 빠르고 쉽게 구현할 수 있는 IOCP를 이용하여 간단한 큐를 만들어보았습니다.
( VC++를 사용하고 계시다면 탬플릿 기반하에 만들어진 Intel TBB에 concurrent_queue와 concurrent_bounded_queue
를 이용하시면 매우 편하게 동시접근가능한 큐를 사용하실 수 있습니다.
Delphi에 경우에는 OTL - OmniThreadLibrary 이라는 라이브러리가 있는데 아직 잘 알려지지 않았고 어떻게 생겨먹었는
지도 잘 모릅니다. )

클래스에 모든 메소드 접근은 멀티 스레드에 안전합니다.
제가 딱 필요로 하는 코드만 들어갔기 때문에 최소한에 기능만 있고 Count가 필요하다면 Interlock 함수로 직접 추가해
넣으셔야 합니다.

메소드 이름이 Inteltbb에 concurrent_bounded_queue와 매우 흡사다하는것을 알 수 있습니다.-_-

{
동시 접근가능한 큐를 구현하기 위해서 간단하게
IOCP를 사용하여 큐잉을 구현하였습니다.
}
unit IOCPQueue;

interface

uses Windows, Messages, SysUtils, Variants, Classes;

type
TIOCPQueue<T> = class(TObject)
private
    FIOCPHandle: THandle;
    FItemSize: Integer;
public
    constructor Create; virtual;
    destructor Destroy; override;

    procedure Push(Item: T);

    procedure Pop(var Item: T);
    function TryPop(var Item: T): Boolean;

    procedure Clear;
end;

implementation

{ TIOCPQueue }

procedure TIOCPQueue<T>.Clear;
var
Item: T;
begin
while True do
begin
    if TryPop(Item) = False then
      break;
end;
end;

constructor TIOCPQueue<T>.Create;
begin
FIOCPHandle := CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, 1);
if FIOCPHandle = 0 then
    RaiseLastOSError;

FItemSize := SizeOf(T);
end;

destructor TIOCPQueue<T>.Destroy;
begin
Clear;
CloseHandle(FIOCPHandle);

inherited;
end;

function TIOCPQueue<T>.TryPop(var Item: T): Boolean;
var
NumberOfBytes: DWORD;
CompletionKey: ULONG_PTR;
OverlappedData: POVERLAPPED;

P: Pointer;
begin
if GetQueuedCompletionStatus(FIOCPHandle, NumberOfBytes, CompletionKey,
    OverlappedData, 0) = True then
begin
    Result := True;

    P := Pointer(CompletionKey);
    CopyMemory(@Item, P, FItemSize);

    FreeMem(P);
end
else
    Result := False;
end;

procedure TIOCPQueue<T>.Pop(var Item: T);
var
NumberOfBytes: DWORD;
CompletionKey: ULONG_PTR;
OverlappedData: POVERLAPPED;

P: Pointer;
begin
if GetQueuedCompletionStatus(FIOCPHandle, NumberOfBytes, CompletionKey,
    OverlappedData, INFINITE) = True then
begin
    P := Pointer(CompletionKey);
    CopyMemory(@Item, P, FItemSize);

    FreeMem(P);
end
else
    RaiseLastOSError;
end;

procedure TIOCPQueue<T>.Push(Item: T);
var
P: Pointer;
begin
GetMem(P, FItemSize);
CopyMemory(P, @Item, FItemSize);

if PostQueuedCompletionStatus(FIOCPHandle, 0, Integer(P), nil) = False then
    RaiseLastOSError;
end;

end.

메소드는 간단히 다음과 같이 이루어져 있습니다.

Clear = 큐에 리스트를 모두 삭제합니다.
TryPop = 큐에 데이터가 있는지 체크하여 있으면 큐에서 꺼내오고 없다면 함수가 실패합니다.
Pop = 큐에 데이터가 있는지 체크하여 있으면 큐에서 꺼내오고 없으면 큐에 데이터가 있을때까지 기다린 후
         데이터가 들어오면 꺼내옵니다.
Push = 큐에 데이터를 넣습니다. 실패 시 예외를 발생시킵니다.

다시 말씀드리다시피 위에 메소드들은 모두 멀티스레드 안전합니다.
또한 메모리할당과 해제는 FastMM을 Delphi에서 기본으로 사용하게 되겠죠.

Modal Form에서 ModalResult := 에 값을 넣으면 창이 닫히는 이유

lain — Sun, 15 Aug 2010 10:36:15 +0900

사실 예전부터 그냥 그려러니 하고 아무 생각없이 모달대화상자를 띄우고 창을 닫을 때에는
ModalResult 에다가 값을 넣어서 창을 닫았었습니다. 그런데 특이하게도 property로 들어가서 어떠한 함수가
호출되어서 창이 닫히겠지하고 생각했는데 실제로 보니 그냥 변수에 값만 바꾸는 것이었습니다.
그런데 변수에 값이 바꼈는데 자동으로 창이 닫히더군요.-_-

다음은 그 코드입니다.
어셈에서 빨간색으로 된 부분 바로 밑에가 실제 값인 $2를 넣는 부분입니다.

어셈으로 보아도 단순히 값만 바꾸더군요.
혹시나 해서 ShowModal 코드를 보니 바로 답이 보이더군요..

function TCustomForm.ShowModal: Integer;
에 VCL코드중에서 다음과 같은 부분이 있습니다.

위에 코드에서 보시면 repeat ~ until 부분이 있는데 이 부분이 제일 중요합니다.
바로 여기서 계속 루프를 돌면서 메세지를 처리하게 되어 있습니다.
그리고 ModalResult를 계속해서 체크를 하죠. 따라서 변수에 값이 바뀌는 순간 타이밍에 의해서 ( 바로 창이 닫히는게 아니라 )
창이 닫히게 되는 것입니다.
또한 코드를 보면 알다시피 모달대화상자에 OnActivate에서 Close 또는 ModalReuslt := ;를 하게 되면
당연히 창이 안 닫힐것입니다. 참고로 Close 함수도 모달대화상자에서는 단순히 내부적으로 ModalReuslt 에 값만 바꿉니다.

어떻게 보면 그냥 그려러니 하는데 참 신기하게 구현이 되어 있네요.

TBitmap32 비트맵이 서로 같은지 비교

lain — Sun, 15 Aug 2010 10:35:10 +0900

매우 간단합니다. 32Bit 비트맵을 핸들링해보신 분이라면 바로 나오는 코드죠.

function CompareBitmap32(Bitmap1, Bitmap2: TBitmap32;): Boolean;
var
P1, P2: PByteArray;
begin
P1 := PByteArray(Bitmap1.Bits);
P2 := PByteArray(Bitmap2.Bits);

Result := CompareMem(P1, P2, (Bitmap1.Width * Bitmap1.Height * 4));
end;

오픈캡쳐에서 그 동안 for 문돌면서 매우 비효율적으로 비트맵을 비교했는데 추가적으로 위에 코드에서
Y좌표부터 스캔하는게 필요해서 다음과 같은 루틴이 만들어졌습니다.

function CompareBitmap32(Bitmap1, Bitmap2: TBitmap32; YPosition: Integer): Boolean;
var
StartRange: Integer;
P1, P2: PByteArray;
begin
Result := False;

if Bitmap1 = nil then
    Exit;

if Bitmap2 = nil then
    Exit;

if Bitmap1.Width <> Bitmap2.Width then
    Exit;

if Bitmap1.Height <> Bitmap2.Height then
    Exit;

P1 := PByteArray(Bitmap1.Bits);
P2 := PByteArray(Bitmap2.Bits);

if (P1 = nil) or (P2 = nil) then
    Exit;

StartRange := Bitmap1.Width * YPosition * 4;

Inc(P1, StartRange);
Inc(P2, StartRange);

Result := CompareMem(P1, P2, (Bitmap1.Width * Bitmap1.Height * 4) - StartRange);
end;

쓸 때 마다 느끼는거지만 Graphics32 정말 대단한 컴포넌트입니다. 안정성도 뛰어나구요.

JEDI 제거 후 Delphi 2010 실행 시 Illegal characters in path. 나오는 버그

lain — Sun, 15 Aug 2010 10:34:28 +0900

JEDI를 본격적으로 써보고 있는데 쓸때마다 버그가 계속 발견이 되는군요-_-
JEDI를 제거하면 아마 아래와 같은 메세지가 뜨시는 분들이 있을것입니다.

위에 에러메세지가 뜨는 근본적인 이유는 JEDI를 설치할 때 경로에 한글이 들어가 있기 때문입니다.
Delphi 2010 메뉴에 Tools - Options 에 갑니다. 그리고 아래 그림에 주황색으로 표시 된 부분에 주목하세요.

위에 주황색으로 표시 된 패스로 설정하는 부분이 3개 있습니다.
그 중에 하나를 고르셔서 클릭해보시면 다음과 같이 경로에 ?? 가 있는거를 볼 수 있습니다.

바로 위에 저 경로가 문제인데 저 ??로 되어 있는거를 다 삭제해주시면 됩니다.
제가 그림에서 주황색으로 표시한 패스를 설정하는 부분에 물음표가 있는지 일일이 다 체크하여서 Delete를 해야 합니다.

결론은 JEDI를 설치할때에는 한글경로가 포함되는 위치에서는 설치하지 않도록 해야 됩니다.

Delphi 2010 도움말 위키

lain — Sun, 15 Aug 2010 10:32:32 +0900

아래에 주소에서 볼 수 있습니다. Delphi 2010을 설치해도 도움말이 있긴 한데 웹에서 보는게 더 편하더군요.
( Delphi 2010 도움말과 이 위키에 내용은 동일합니다. )
http://docwiki.embarcadero.com/RADStudio/en/Main_Page

추가로 간략하게 코드샘플도 아래에 주소에서 제공합니다. ( 제가 제네릭 관련 클래스를 쓰다가 참고한 주소입니다. )
물론 도움말에도 있긴 한데 웹에서 보여주는거는 좀 더 문법색상강조가 더 깔끔하게 되어 있습니다.
http://docwiki.embarcadero.com/CodeSamples/en/Category:Delphi

제가 델파이 기초가 많이 부족해서 시간이 날때 심심하면 한 번씩 도움말을 훓어보는데
상당히 많은 도움이 되는 것 같네요.

TJvIPAddress 포커스 입력 및 겹쳐져서 그리는 문제 수정

lain — Sun, 15 Aug 2010 10:31:52 +0900

Delphi 2010을 사용하고 있는데 Delphi 2010에서만 나타나는 현상인지는 모르겠습니다.
JEDI에서 제공하는 TJvIPAddress 컴포넌트를 폼에 얹으면 우선 포커스 입력이 되지 않는 문제가 있습니다.
또한 포커스가 입력이 되도록 JVCL 코드를 수정을 하여도 이번에는 아이피를 입력할 때 숫자가 겹쳐져서 나타나는
현상이 있는데 이 모든 사항를 수정하는 방법입니다.

현재 사용하고 있는 JEDI 버전은 JVCL339CompleteJCL211-Build353입니다.

아래는 이에 대한 Bug Fixed입니다.
이를 위해서 JVCL 코드를 수정해야 하며 수정해야 하는 파일은
JVCL339CompleteJCL211-Build3536\jvcl\run\JvComCtrls.pas 입니다.

procedure TJvIPEditControlHelper.WndProc(var Msg: TMessage);
함수에 맨 마지막줄을 다음과 같이 주석처리합니다.

//with Msg do
// Result := DefWindowProc(Handle, Msg, WParam, LParam);

그리고 주석처리한 코드 대신에 다음 코드를 넣습니다. 이로써 포커스를 입력받을 수 있습니다.
Dispatch(Msg);

수정 된 전체 코드는 다음과 같습니다.
procedure TJvIPEditControlHelper.WndProc(var Msg: TMessage);
begin
case Msg.Msg of
    WM_ENABLE:
      if csDesigning in FIPAddress.ComponentState then
        Exit
      else
      begin
        {$IFDEF JVCLThemesEnabled}
        if not FIPAddress.Enabled and ThemeServices.ThemesEnabled then
        begin
          EnableWindow(Handle, True);
          Exit;
        end;
        {$ENDIF JVCLThemesEnabled}
      end;
    WM_DESTROY:
      Handle := 0;
    WM_KEYFIRST..WM_KEYLAST:
      begin
        FIPAddress.Dispatch(Msg);
        if Msg.WParam = VK_TAB then
          Exit;
      end;
    // mouse messages are sent through TJvIPAddress.WMParentNotify
end;
// Fixed bug : Delphi 2010에서 사용 시 마우스 입력 및 키 입력을 받지 못 하는 버그
Dispatch(Msg);
//with Msg do
// Result := DefWindowProc(Handle, Msg, WParam, LParam);
end;

아이피를 입력할 때 숫자가 겹쳐서 나오는 문제는 윈도우즈 테마가 폼에 적용되어 있을때에만 나타나는 현상으로
procedure TJvIPAddress.WMCtlColorEdit(var Msg: TWMCtlColorEdit);
함수에 있는 코드를 다음에 코드로 변경합니다.

procedure TJvIPAddress.WMCtlColorEdit(var Msg: TWMCtlColorEdit);
begin
inherited;
// Fixed Bug : 폼에 XP 테마가 활성화되어 있을 때 아이피를 입력 시 숫자가 겹쳐서
// 보이는 버그 수정
{DC := GetDC(Handle);
try
    Brush.Color := ColorToRGB(Color);
    Brush.Style := bsSolid;
    SetTextColor(DC, ColorToRGB(Font.Color));
    SetBkColor(DC, ColorToRGB(Brush.Color));
    SetTextColor(Msg.ChildDC, ColorToRGB(Font.Color));
    SetBkColor(Msg.ChildDC, ColorToRGB(Brush.Color));
    SetBkMode(Msg.ChildDC, TRANSPARENT);
finally
    ReleaseDC(Handle, DC);
end;                      }
Msg.Result := Brush.Handle;
end;

WIndows 2000 Server, Windows XP SP3, Windows Vista 64Bit, Windows 7 에서 다 테스트 되었으므로
정상적으로 동작한다라고 보시면 됩니다.