external 이라는 키워드를 생각해보시길 바랍니다.

C/C++ 과 비교해서 생각해보면 (잘 모르셔두 상관은 없습니다.)
소스코드에서 실행파일을 생성하는 데 다음과 같은 과정을 거칩니다.
소스코드
  |
PreCompile
  |
Compile
  |
Linking
  |
실행 파일
여기서 Compile 과정에서는 실질적인 메모리 주소가 메핑되는 것이 아니라 어디에 있더라 라는 심볼정보가 들어갑니다. Linking 과정에서 정확히 어디~ 라는 것이 매핑되죠.
델파이 PAS 파일의 interface 부분은 C/C++ 의 헤더 파일(*.h)과 관련있고, implementation 부분은 C/C++ 의 소스 파일 (*.c / *.cpp)와 관련 있다고 생각해보면,
interface 부분에서 함수를 선언해주는 것은 다른 유닛에서도 참조할 수 있게 하기 위해서 특성을 타지 않는 것이 좋습니다. 즉, 선언하는 함수가 델파이에서 작성된 전역함수인지 아니면 DLL-exported 함수인지 전혀 관계없다는 것이죠.
implementation 부분은 약간 다른 데, 이 섹션에 들어가는 내용은 위의 생성과정에서 Compile/Linking을 같이 하기 때문입니다. 즉, external 이라는 뜻이 함수의 본체는 현재 정의된 PAS 또는 실행코드 블럭에서 밖에 있다(external 하다, internal 하지 않다)의 뜻으로 해석하시면 될 듯 합니다.
한가지 더,
위에서 interface/implementation 부분을 C/C++ 과 비교 했는 데 정확히 등가는 아닙니다. 위와 같은 경우(DLL-exported 함수를 사용하는 경우)는 interface 부분 역시도 Linking 에 참여하게 됩니다.

예를 들어 comctl32.dll에 들어있는 DllGetVersion 함수를 델파이에서 쓰는 방식은 아래와 같이 3가지나 될 수 있습니다.

  DLLVERSIONINFO = record
    cbSize         :DWORD;
    dwMajorVersion :DWORD;
    dwMinorVersion :DWORD;
    dwBuildNumber  :DWORD;
    dwPlatformID   :DWORD;
  end;
  PDLLVERSIONINFO = ^DLLVERSIONINFO;

1. interface 부분에 모두 몰아넣는 경우,
interface
...
function DllGetVersion(a_PassedPointer:PDLLVERSIONINFO):HRESULT;stdcall;external 'comctl32.dll' name 'DllGetVersion';

2. interface / implementation에 나누어서 넣는 경우
interface
...
function DllGetVersion(a_PassedPointer:PDLLVERSIONINFO):HRESULT;stdcall;

implementation
...
function DllGetVersion; external 'comctl32.dll' name 'DllGetVersion';

3. implementation 부분에 몰아 넣는 경우
implementation
...
function DllGetVersion(a_PassedPointer:PDLLVERSIONINFO):HRESULT;stdcall;external 'comctl32.dll' name 'DllGetVersion';

이 방식들 중에서 1, 2번만 다른 유닛에서 참조하여 사용할 수 있습니다.
델파이 Windows unit의 경우는 2번의 방식만 사용합니다.

개인적으로는 이런 DLL 사용방식 (보통 static-linking 이라고들 하죠... C++에서 *.lib 파일 사용하는 형식)은 권장하고 싶지 않습니다. 해당 DLL이 없는 경우는 아예 프로그램이 뜨질 않기 때문에... 따라서 개인적으로는 고전적인 LoadLibrary/GetProcAddress/FreeLibrary를 권하고 싶습니다.

성의 있는 답변 너무 감사합니다. 이해하는데 많은 도움이되었습니다.
그리구 동적으로 할당한 이유는 이 함수를 타이머에 넣어서 프로그램의
종료시까지 사용하는 이유로 한것이 아닌가 생각합니다.
자주 호출하면 정적으로 할당하는게 맞나요?

음 지나가던 얼큰입다... ㅋㅋ 호접한 답변이 도움이 되었다니 넘 기쁩다.
^_____^
정적할당과 동적할당의 구분은 별로 없습니다.
하지만, 개인적으로는 프로그램의 질의 문제라고 생각합니다.
가령, 어떤 어플리케이션이 10가지의 일을 할 수 있는 데, 각각의 일의 함수들이 서로 다른 DLL로 되어 있어서 나중에 DLL만 바꾸면 자동으로 프로그램이 업그레이드 되는 어플리케이션이 있다고 가정해보겠습니다.
사용자가 실수로 10개의 DLL중에서 3개를 지웠다면, 이 프로그램은 동작하지 말아야 하는 가? 아니면 나머지 7가지 기능들만 동작해야 하는 가? 의 문제를 생각해보면 됩니다.
정적 할당(static linkage)를 사용하는 경우, 위의 예에서 살펴보면, 해당 어플리케이션은 아예 처음부터 동작하지 않습니다. 필요한 DLL을 찾을 수 없다는 빨강 X 표 있는 메시지 박스 띠우고 죽어버립니다.
동적 할당(dynamic linkage)를 사용하는 경우, 위의 예에서 살펴보면, 어플리케이션을 짜는 프로그래머가 조금만 신경써주면, 없어진 DLL3개에 해당하는 작업을 하려고 할 때, 어떤 이유로 인하여 작업할 수 없다는 메시지를 사용자에게 보여 줄 수 있습니다. 나머지 무사한 7개의 작업의 경우는 사용자에게 어떤 말도 보여주지 않고도 계속 작업을 진행할 수 있는 것이죠. 동적 할당의 경우 프로그램 종료시까지 사용해야 하기 때문에 꺼려진다는 것은 의미가 없습니다. 왜냐하면 Win32에서 프로세스 종료시에 자동적으로 올라가 있던 DLL들이 내려오니깐요... ^^ 동적 할당을 사용하실 때, 해당 함수 포인터를 선언해서 initialization section을 이용하여 GetProcAddress 해 주시면 작업이 편리해 집니다. 즉 해당 함수 포인터를 var 항목에 넣고 그 값을 에러시에 실행되는 함수로 일단 메핑 시켜 놓습니다. 그리고 initialization 항목에서 GetProcAddress를 실행해서 성공하면 함수 포인터를 DLL-함수로 치환합니다. 이런식으로 코딩을 하면 밖에서 호출하는 Unit에서는 해당 함수를 매우 범용적으로 사용할 수 있게됩니다. DLL에러에 대한 대책도 되고요... 물론 이런식으로 개발하는 것은 .NET이 선풍적인 인기를 끄는 이 시점에서 매우 구닥다리라고 생각하지만, 어차피 .NET도 안을 파해쳐보면 COM+ 덩어리이고 COM+ 역시 DLL 베이스니깐...(몬 헛소리 호곡!!!)

암튼..... 저 개인적으로는 동적할당식으로 작업하는 것이 맞다고 생각하는 부류중에 한명입니다.