최근에 나는 델파이 작업을 시작했고 많은 패키지가 원래 프로그램에 사용되었다는 것을 알았지 만 항상 무지한 상태에있었습니다. 이 문제를 연구하는 데 약간의 시간이 걸릴 수 있습니다. 따라서 먼저 분석 해야하는 질문을 나열하십시오.
가방이란 무엇입니까? exe 란 무엇입니까? 그들의 구성 차이는 무엇입니까? 패키지와 DCU의 관계는 무엇입니까? DCP는 무엇을합니까? 컴파일 시간 에이 파일들 사이의 관계는 무엇입니까? 어떻게로드됩니까? 로드 후 패키지를 작동하는 방법은 무엇입니까? DLL은 수출을 할 수 있지만 왜 Delphi가 패키지의 내보내기를 제기하지 않도록 도와주지 않지만 일부 코드는 패키지에서 Exprot을 사용합니까?
먼저 델파이의 편집 과정을 살펴 보겠습니다. 델파이에는 패키지와 프로그램의 두 가지 유형이 있습니다. 간단한 것으로 시작하여 DPR부터 시작하겠습니다. Delphi의 도움말 문서에 따르면 일반적인 DPR 파일의 구조는 다음과 같습니다.
1 프로그램 편집기;
2
3 용도
4 형식, {Linux에서 QForms로 변경}
5 'reabout.pas'{aboutbox}의 reabout,
6 '남은'에 남아 있습니다 .pas {mainform};
7
8 {$ r *.res}
9
10 시작
11 Application.title : = '텍스트 편집기';
12 Application.createform (tmainform, mainform);
13 Application.run;
14 종료.
그중 10 ~ 14 줄은 시작… 끝은 당연히 프로그램의 실행 입력입니다. 사용 부분은 프로그램이 사용해야하는 일부 단위를 나타냅니다.이 단위는 소스 코드의 위치를 나타내는 데 약간의 사용이지만 일부는 양식 부품에 추가되었지만 일부는 그렇지 않습니다. 필요? 그러면 각 장치는 다른 장치를 사용 하며이 문제는 점점 더 복잡해지고있는 것 같습니다. 먼저 전체 소스 코드의 구조를 살펴 보겠습니다.
컴파일러의 첫 번째 단계는이 지시 된 그래프를 가로 지르고 각 장치를 컴파일하고 필요한 경우 해당 DCU를 생성하는 것입니다. 이 "필요한"문제에 관해서는, 처음에는 단위 사용 명세서가 있다고 생각했지만 나중에는 그것이 잘못되었다는 것을 알았습니다. 위의 경우 Unit3은 Unit1의 사용 절에서 경로를 지정하지 않지만 해당 DCU 파일은 여전히 올바르게 생성됩니다. 나중에 Filemon은 파일 개방 상황을 모니터링하는 데 사용되며 검색 프로세스는 다음과 같습니다. 그래프의 각 노드에 대해 컴파일러는 현재 디렉토리의 검색 경로에서 해당 노드를 검색합니다. 환경. PAS 파일을 찾지 못하면 다시 수행하지만 이번에는 노드에 해당하는 DCU 파일을 검색했습니다.
컴파일이 완료되었으므로 각 장치 (즉, PAS 파일)가 DCU 파일을 생성했습니다. 연결과 관련하여 문제는 복잡합니다. 정적 연결은 이러한 모든 DCU를 결합하는 것을 의미합니다. 이런 식으로, 한 장치를 다른 장치로 호출하는 것은 프로그램의 내부 문제가됩니다. 이 이점은 빠르고 단순하며 동시 공유와 같은 문제는 다루기 쉽다는 것입니다. 단점은 대상 프로그램이 크고 다른 프로그램을 지금 작성하고 Unit3을 재사용 할 수 있다면 Unit3.dcu가 연결되면 다시 복사됩니다. 이런 식으로, 두 프로그램이 동시에 실행될 때, 두 개의 메모리에 두 개의 Unit3 사본이 있으며, 이는 폐기물입니다. 동적 연결은 두 프로그램이 연결되면 Unit3에 대한 참조 만 유지하고 Unit3의 내용을 복사하지 않음을 의미합니다. 런타임에서 Unit3을 메모리에로드하고 두 프로그램을 공통적으로 만듭니다. DLL 및 BPL은 동적 연결을위한 솔루션입니다. 문제는 Delphi에서 연결을위한 유일한 옵션이 프로젝트 | 옵션 | 패키지 메뉴에 나타나고 문장 "런타임 패키지가 포함 된 빌드"는 너무 모호하다는 것입니다. 그래서 우리는 그것을 다시 공부해야합니다.
프로그램이 실행되면 View | Debug Window | Moudles를 사용하여 메모리에로드되는 물건과 포함 된 콘텐츠를 확인할 수 있습니다.
간단히 말해서, 우리는 다음 구조의 프로그램을 설정합니다.
프로그램 projectexe;
용도
형태,
창문,
'initformmain.pas'{formmain}의 unitformmain;
{$ r *.res}
시작하다
application.initialize;
application.createform (tformmain, formmain);
application.run;
끝.
Unit Unitformmain;
인터페이스
용도
Windows, stdctrls, 양식, Unitformanother, 클래스, 컨트롤;
유형
tformmain = 클래스 (tform)
버튼 1 : tbutton;
절차 버튼 1Click (sender : tobject);
사적인
{개인 선언}
공공의
{공개 선언}
끝;
var
Formmain : tformmain;
구현
{$ r *.dfm}
절차 tformmain.button1click (sender : tobject);
var
lform : tformanother;
시작하다
lform : = tformanother.create (응용 프로그램);
lform.showmodal;
lform.free;
끝;
끝.
단위 단위 공식적인;
인터페이스
용도
형태;
유형
tformanother = class (tform)
사적인
{개인 선언}
공공의
{공개 선언}
끝;
구현
{$ r *.dfm}
끝.
지금 뉴스를 받자. "런타임 패키지가있는 빌드"가 확인되며 이제 런타임 Projectexe.exe 파일에는 4 개의 부분이 포함되어 있습니다 프로세스 트리 : RTL60 및 VCL60에서 해당 내용은 정적 연결에 나타난 단위입니다. Projectexe.exe는 현재 16k에 불과합니다. 다시 말해, 지시 된 그래프의 장치의 일부는 EXE에 배치되고 다른 부분은 BPL에 배치됩니다. 그러나 부서는 무엇을 기반으로합니까? 사용 조항을 기반으로하거나 여기에서 "런타임 패키지가있는 빌드"의 목록을 기반으로합니까? 테스트를 계속하면 목록에 VCL60 만 포함 된 경우 메모리에로드 된 2 개의 BPL과 하나의 exe가 여전히 RTL60 만 포함 된 경우 RTL60과 EXE 만 포함되지만 내용은 포함됩니다. EXE가 변경되었습니다. 내부의 장치 수가 증가했으며 기본적으로 VCL60 패키지에 있습니다. RTL과 VCL 패키지 사이에는 요구 사항 관계가 있어야한다고 생각합니다. 이것은 다음 단계에서 테스트됩니다. 그러나 초기 추정 프로세스 중에 패키지 목록은 EXE의 패키지에 이미 존재하는 단위를 제외하는 데 분명히 사용됩니다.
동적 연결 후에는 또 다른 문제가 있습니다 : 로딩. 델파이로부터 코드를 생성하는 자동으로 알려진 정적로드 전략이 있으며, 다른 사람은 동적, 즉 프로그램이 실행될 때 패키지를 지정하고로드하기 전에 패키지를 자동으로로드합니다. 메모리. 문제는 어떤 상황에서 델파이가 패키지를 자동으로로드하고 어떤 상황에서 어떤 상황에서 델파이가 똑똑하지 않아 패키지를 유연하게 사용할 수 있도록하는 것을 피할 수 있다는 것입니다. 이전 실험에서는 DPR 파일이 시작되기 전에 정적으로 연결된 패키지가 메모리에로드되었음을 알 수 있습니다. 나는 특정 과정을 알지 못합니다. 다음 장이 내 자신의 패키지를 작성하고 실험을 할 때까지 기다립니다.