On 5 Mar 2003 at 2:30, Frank Heckenbach wrote:
[...]
AFAIK, under "plain" Windows (i.e. without Cygin/Mingw or similar) there are no static libs (.a), so DLLs are the only kind of libraries (correct me if I'm wrong),
There are static libs - ".lib" (I believe in a standard Intel format). MS tools use this format, and so does Virtual Pascal for unit implementation sections (VP uses the .lib format in cases where BP/Delphi would use .tpu/.dcu and GPC would use .o). Someone on the Mingw list said that the Mingw ".a" files are in the same format as Microsoft's ".lib" - but I wouldn't know for sure.
I guess that, theoretically, you can link VP .libs with MS stuff and vice versa, and someone said you can (theoretically) link MS .libs into Mingw programs, and vice versa.
and a BP/Delphi library naturally creates a DLL.
Yes - and so does VP.
But that's an implementation detail and should not be considered part of the language definition.
For an example about units -- the BP manuals state something like the compiled unit is placed in a file whose name consists of the first 8 letters of the unit name (maybe they even said, converted to upper case) plus the extension `.TPU' (in real mode). Surely, everyone who is familiar with the issues would see that the former is a property of the FAT file system, and would not expect a BP compatible compiler to truncate unit file names after 8 characters on systems that allow longer file names.
True. There is no restriction as to the length of the names in Delphi or VP.
(And even the extension `.TPU' is certainly implementation-specific; GPC and FPC (and probably also other more or less BP compatible compilers) use different names.)
True again. Delphi uses .dcu.
[...]
I presume you are talking about the BP/Delphi syntax for "libraries". Here is an example:
library foobar; uses bar, baz;
function bar1 : integer; stdcall; begin { blah, blah } end;
function foo : integer; stdcall; begin { blah, blah } end;
exports bar1 index 1 name 'myBar'; {IIRC, "index n" and "name x" are optional} foo index 2 name 'foo';
begin { optional } [...] { optional } end.
Do you have to list all exports explicitly? I.e., they don't re-export everything from the units used automatically?
I believe so - these snippets are from the Delphi 7 help file:
"Libraries can be built from multiple units. In this case, the library source file is frequently reduced to a uses clause, an exports clause, and the initialization code."
"You can put exports clauses in the interface or implementation section of a unit. Any library that includes such a unit in its uses clause automatically exports the routines listed the unit's exports clauses-- without the need for an exports clause of its own."
"An exports clause can appear anywhere and any number of times in the declaration part of a program or library, or in the interface or implementation section of a unit. Programs seldom contain an exports clause."
BTW: the Delphi 7 help file also discourages the use of "index". This is a new one (at least, to me): "Use of index specifiers, which are supported for backward compatibility only, is discouraged and may cause problems for other development tools."
Well then, it actually doesn't seem to have much to do with unit inheritance as I thought ...
Well, it can - sort of - if you have exports clauses in the units themselves. I also came across something:
"Type Switch Syntax {$ObjExportAll On} or {$ObjExportAll Off} Default {$ObjExportAll Off} Scope Global The {$ObjExportAll On} directive exports all symbols in the unit file in which it occurs. This allows the C++ compiler to create packages containing Delphi-generated object files."
Might this be a way to avoid having to declare exports clauses in units in order to simplify unit inheritance in libraries? This might of course be very difficult to implement, but it seems a clear way out of all the problems we have been discussing;
* a library that tries to propagate other units would need to have an exports section listing each thing that it wants to propagate (meaning no accidental propagation)
* but, where you want to propagate everything from a particular unit (i.e., from its interface section), you either have an exports clause in that unit, or you use the (new) directive "{$ObjExportAll On}" in that unit. The latter is obviously the more convenient for the programmer. So any library that uses such unit does not need to have its own exports clause. But this also has the advantage that the programmer would have somewhere taken a deliberate decision as to what should be propagated from his/her units.
I have to say that, for me, none of this is a priority - but it seems that others want it.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/