Geoff Chappell - Software Analyst
The NAME and VXD statements are essentially the same, except that a VXD statement is supported only if LIB was given the /vxd switch. Even when the VXD statement is supported, warnings and errors are described as coming from a NAME statement. The LIBRARY statement differs from the others on just a few points.
Only one LIBRARY, NAME or VXD statement is permitted for the file. Each additional such statement causes a warning (LNK4017) about being not supported, and is then ignored.
LIBRARY, NAME and VXD are single-line statements. An empty statement is valid. If the statement is to have any arguments, then the statement tag must be followed immediately by a space or tab. There may then be any amount of white space, including none, before the first argument. An overview of the syntax is:
tag pathname [attributes]
where tag is one of LIBRARY, NAME or VXD.
The pathname extends to the next white space that does not appear between successive pairs of double-quotes. All double-quotes in the pathname, whether paired or not, are discarded.
The pathname is treated as a drive, path, file name and file extension. Although syntactically valid, the drive and path are not supported. Their presence results in a warning (LNK4093) that the drive and path are ignored. To be free of warnings, the pathname argument must have the form:
In the absence of an extension, LIB defaults to VXD when building for a VxD (whatever the statement tag), else to EXE for a NAME statement (with no default for a LIBRARY statement).
The remainder of the line is interpreted as the attributes argument. This argument is compound. Each attribute may be preceded by white space. Each extends to the next white space that does not appear between successive pairs of double-quotes. All double-quotes are discarded.
Attributes are case-insensitive. It is a fatal error (LNK1118) to have an unrecognised keyword among the attributes or to have a recognised attribute in unsuitable circumstances. Some keywords are recognised, but then ignored after a warning (LNK4017).
|BASE=address||fatal error if building a VxD|
|DYNAMIC||fatal error unless building a VxD|
|INITINSTANCE||fatal error if building a VxD;
|LONGNAMES||fatal error if building a VxD;
|NEWFILES||fatal error if building a VxD;
|WINDOWAPI||fatal error if building a VxD|
|WINDOWCOMPAT||fatal error if building a VxD|
The BASE attribute requires an equals sign and an argument. The equals sign must follow immediately. There can be spaces between the equals sign and the address if enclosed between double-quotes. The address is interpreted numerically, in decimal, hexadecimal or octal notation, with a sign prefix permitted, but evaluated as an unsigned integer truncated to 64 bits. It is a fatal error (LNK1118) not to provide the equals sign and an address. Curiously, this error is described as a syntax error in a NAME statement, even if the statement has a LIBRARY tag.
A non-empty LIBRARY statement translates into /dll and /out options for the export-file command line. A non-empty NAME or VXD statement translates into /out and /name options. All three may add a /base, /exetype or /subsystem option, depending on what attributes appear in the definition.
The /dll option, emitted only for a LIBRARY statement, is simply:
The /out option has the form:
where extension may be a default (as described above) and the /out argument is enclosed in double-quotes if pathname contains at least one pair of double-quotes (even if the double-quotes are in the drive or path components that are otherwise ignored).
NAME and VXD, but not LIBRARY, produce a /name option:
with no enclosure in double-quotes, even if filename contains white space.
Each occurrence of the BASE attribute translates to a /base option. The form is:
where address in the command-line option is a hexadecimal representation of the address in the attribute.
Each occurrence of any other supported attribute translates as follows:
|Attribute||Export-File Command Line|
The code for generating the /out and /name options uses a 128-byte buffer on the stack but does not check the lengths of the strings it copies there. A sufficiently long filename can therefore induce an overrun. However, in the version studied for these notes, namely 7.00.9466, the placement of buffers is such that the overrun does not corrupt anything that can still be needed.