API 호환성
요약: 이 문서는 애드온 호환성과 관련된 이슈들에 대해 논의합니다.
0. 소개
(C++) 호환성에 대한 좋은 요약본은 KDE 사이트의 이 페이지를 보십시오. 그들이 저 페이지에서 정의한 대로 binary와 source compatible이라는 용어를 사용하겠습니다. 당신 쪽에서 해야 할 일이 없기 때문에 개발자의 관점에서는 처음 타입이 우월합니다. (그리고 물론 더 가치 있습니다)
ArchiCAD 8의 등장과 함께 이전 애드온의 바이너리 호환성은 상실되었습니다. (예. 이전 버전들에 대한 ArchiCAD의 컴파일된 애드온의 로드하고 실행하는 기능 -- 즉, 버전 6.0, 6.5, 그리고 7.0) 한편으로는 등록 메커니즘의 현대화 때문이었고, 반면에 이런 종류의 호환성을 유지하는 것에는 엄청난 노력을 요구하기 때문입니다.
ArchiCAD 8, 8.1, 9와 10 사이에는 여러 모듈(예를 들면, InputOutput 또는 GSRoot 등)의 인터페이스 변경으로 인해 바이너리 호환성을 보장하지 않으므로 4.x DevKits로 컴파일된 애드온은 ArchiCAD 8.1 또는 ArchiCAD 10에서 로드될 수 없습니다. ArchiCAD 10에서 실행하려면 ArchiCAD 8 또는 8.1을 위해 개발된 애드온들은 이 DevKit으로 다시 컴파일되어야 합니다.
이 문서는 애드온 개발자의 관점에서 호환성이 무엇을 의미하는지, 그리고 그것에 대해 당신이 무엇을 할 수 있는지 설명합니다.
1. API 호환성
아래부터 우리는 이것이 문제가 될 수 있는 API의 다른 영역을 살펴보겠습니다.
1.a 인터페이스
정의에 따르면 라이브러리에 대한 인터페이스는 소스 레벨 호환성만 충족할 수 있습니다. 이는 API의 기능을 새로운 기능으로만 확장할 수 있으며, 이전 기능은 변경되어서는 안 된다는 것을 의미합니다.
API(그 자체)는 C 인터페이스만 제공합니다. (ArchiCAD 8부터는 더 이상 사실이 아니라는 것을 인정해야 합니다) 이 C 인터페이스는 소스와 바이너리 호환성을 유지하기가 더 쉽습니다. 왜냐하면 다른 컴파일러들이 동일한 인터페이스에 대해 동일한 코드를 생성하기 때문입니다. 또한, ACAP_STAT.lib에는 함수 테이블이 포함되어 있으며, 여기서 우리는 새로운 함수의 도입을 위해 많은 장소를 떠났습니다.
만약 오래된 기능이 더 이상 관련이 없다면, 그것은 여전히 자기 자리를 지키며 이전 버전에서 제공한 행동을 모방해야 합니다. 이것은 상당한 내부 프로그래밍 노력이 필요할 수 있습니다. 왜냐하면 새로운 내부 인터페이스 집합을 통해 내부적으로 오래된 기능을 구현해야 하기 때문입니다. If the old functionality is still viable, just requires extra parameters to provide the functionality available in the actual version of ArchiCAD, then we can introduce a new function (much like the ...Ex functions in the Windows platform SDK). 만약 기존 기능이 여전히 실행 가능하면, ArchiCAD의 실제 버전에서 사용할 수 있는 기능을 제공하기 위해 단지 추가 파라미터들을 요구할 수 있습니다. 그러면 우리는 새로운 기능을 도입할 수 있습니다. (대부분 ...윈도우 플랫폼 SDK의 Ex 기능) C 인터페이스에서, 과거에 우리는 함수 테이블의 filler place를 사용하여 이러한 함수의 주소를 저장했습니다.
C++ 세계에서는, 컴파일러에 의해 (가상) 함수 테이블이 생성됩니다. 그리고 filler 'place'가 더 이상 존재하지 않습니다. 따라서 이 인터페이스에 새로운 기능을 도입하면 이 C++ 라이브러리에 연결된 모든 코드가 갑자기 사용할 수 없게 되고 당신의 애드온은 ArchiCAD에서 로드되지 않게 됩니다.
권고: 바이너리 호환성을 유지하려면 C 인터페이스를 고수하십시오. 이것은 DG 모듈의 파일/폴더 다이얼로그와 같은 다른 모듈에도 적용됩니다. 이것을 달성할 수 없지만 (가장 주목할 만한 InputOutput 모듈), 새로운 (유지관리) 버전 ArchiCAD가 시장에 도달함에 따라 당신의 애드온을 컴파일할 것으로 기대되는 특정 장소가 있습니다.
InputOutput 모듈의 CIO 인터페이스는 더 이상 지원되지 않으며, 대신 C++ IO 인터페이스를 사용한다는 것을 참고하십시오.
1.b 라이브러리
API Development Kit에는 API 라이브러리인 ACAP_STAT.lib과 ACAP_DLL.apx의 두 가지 버전이 포함되어 있습니다. 대부분의 경우, 당신은 당신의 코드를 애드온(DLL/공유 라이브러리)의 주요 엔트리 지점을 제공하는 정적 라이브러리에 링크하고 사용 가능한 함수의 모든 주소를 저장하는 내부 함수 테이블을 구축합니다. 이 정적 라이브러리는 또한 ArchiCAD의 API 인터페이스에 대한 버전 번호를 제공하며, 후속 유지관리 릴리즈가 나타나면 애드온에 대한 애플리케이션의 예상 행동을 제공하기 위해 내부적으로 사용될 수 있습니다.
다른 ACAP_DLL.apx는 당신이 직접 초기화를 할 수 있게 해줍니다. 이렇게 하면 당신만의 함수 테이블을 구축할 수 있으며, 당신의 DLL의 초기화 및 종료에 대한 제어도 더 많이 할 수 있다. 이것은 API 자체와 바이너리 호환성을 유지하는 가장 쉬운 방법이지만, 당신 측에서 훨씬 더 많은 작업이 필요합니다. DLL_Test 예제를 보십시오.
버전 제어 프로세스에서 매우 중요한 점은 의무적인 CheckEnvironment 함수입니다:
// -----------------------------------------------------------------------------
// Dependency definitions
// -----------------------------------------------------------------------------
API_AddonType __ACENV_CALL CheckEnvironment (API_EnvirParams* envir)
{
// for tool-type add-ons: skip if not in ArchiCAD
if (envir->serverInfo.serverApplication != APIAppl_ArchiCADID)
return APIAddon_DontRegister;
ACAPI_Resource_GetLocStr (envir->addOnInfo.name, 32000, 1);
ACAPI_Resource_GetLocStr (envir->addOnInfo.description, 32000, 2);
return APIAddon_Normal;
} // CheckEnvironment
API_EnvirParams structure는 서버 애플리케이션의 메인/유지관리 버전을 포함하고 있습니다.
이 정보를 기반으로 당신의 애드온은 현재 서버 애플리케이션에서 실행할지 여부를 결정할 수 있습니다.
예를 들면, ArchiCAD 8.1의 R2/v2 버전에서 수정된 버그는 ArchiCAD 8.1 R1/v1에서 애드온의 동작을 막았습니다.
이 경우 당신은 CheckEnvironment () 함수에서 서버 애플리케이션의 버전을 테스트해보고,
만약 envir->serverInfo.releaseVersion < 2이면 APIAddon_DontRegister를 리턴할 수 있습니다.
