[fpc-pascal] -Twin32 linker woes

[Marco van de Voort]

In our previous episode, Adriaan van Os said:
> >> Well, then the linker complains about unresolved symbols.
> > 
> > You have to mention the name of the dll in the procedure declaration:
> > 
> > procedure test; stdcall; external 'dllname';
> 
> I assume ".dll" is added only if "dllname" doesn't have an extension ? 

yes. Also microsoft distributes dlls (+something extra) with different
extensions, winspool.drv, hhctrl.ocx (not purely an activex interface, also
contains normal procedures) etc.

> For example, Apple's QuickTIme SDK for Windows is distributed with .lib
> files to link with and if I look up the corresponding ddl in the WIndows
> system32 directory, it is "QuickTime.qts", not "QuickTime.dll".

In that case I think the dllname should be complete, IOW 'quicktime.qts',
casing doesn't matter.

> It looks like the dll is not checked at link-time to see if e.g. the
> stdcall-mangled names match and the routine is present ?

That's correct. FPC probably does so out of Delphi compatibility.

Borland faced probably the following issues with Delphi:
* If they choose microsoft's importlib format, they would be exposed to
  breakage and catch-up issues if MS broke it. Keep in mind that VS didn't
  have the same dominant position then that it has now.
* if they introduced an own format, the problem would be
  chose an own format, but then have the trouble that most 3rd party dlls
  would be without borland specific import lib
* don't use importlibs, generate the necessarily tables, but don't try to 
  match signatures.

Delphi apparantly chose the 3rd option, probably because it is the easiest
supportable.

The problem with importlibs is first and for all that there are several
formats, MSVC's (SDKs seem to come with a .lib per MSVC version, so multiple
versions) and the various GCCs (*.a, but potentially dependant on the exact
gcc/windows flavour (mingw,cygwin,other))