The EXPORTS statement is a multi-line statement. An empty statement is valid but trivial. If the statement is to have a definition on the first line, then the statement tag must be followed immediately by a space or tab. There may then be white space before the definition.
For each new definition, the linker examines the text remaining on the line, up to but not including the next space, tab or equals sign. If this token matches a recognised statement keyword, then except in the three cases to be noted shortly, the EXPORTS statement is considered to have ended with the preceding definition (if any), so that instead of being the first argument of another EXPORTS definition, the token is a statement tag to begin the next statement (and for the purpose of parsing that next statement, an equals sign immediately after the tag is effectively a space or tab).
As to the three execptions, it is not clear that any are intended. The first applies only when building VxDs.
If the initial token in what may be a new definition is followed by at least two spaces or tabs and no other characters on the remainder of the line, then the token is not checked against the recognised statement keywords but is instead treated as the first (and only) argument of another EXPORTS definition.
If NAME is found as the initial token where a new definition is permitted, then the remainder of the line is ignored and the linker checks the next line for another EXPORTS definition.
If VERSION is found as the initial token where a new definition is permitted, then the linker interprets the remainder of the line according to a special syntax, intending then to check the next line for another EXPORTS definition. Details are not presented here since the syntax appears to be meaningful only when building for the Motorola 680x0 family (as set through /machine:m68k option on the command line). The best possible outcome when building for other platforms is fatal error LNK1118 because of incorrect syntax. For details of the syntax and for the consequence of following VERSION with text that is syntactically valid for the M68K, see Internal error during ParseVxDDefExport.
A general (but not comprehensive) format for a non-empty definition when building a VxD is:
entryname [@[ordinal]]
where entryname is followed by at least one space or tab. If the next character is an @, there may then be an ordinal, consisting of the decimal digits that follow immediately. All remaining characters on the line are irrelevant and are ignored.
There is a particular case involving the equals sign. If entryname is followed immediately by an equals sign, there is no ordinal. All remaining characters on the line are irrelevant and are ignored.
Without a space, tab or equals sign to follow entryname, the line ends with entryname and it is seemingly trivial that there cannot be an ordinal. The reason for this explicit statement of the trivial is that because of a coding error, the linker continues parsing beyond what would otherwise have been treated as the end of the line. In this way, though admittedly only in a contrived case that has no practical consequence (given that the entryname must begin with an @), an ordinal can be picked up from a comment—or even from previous lines whose characters persist in the relevant buffer.
Each non-empty definition in an EXPORTS statement when building a VxD is translated into a /EXPORTS option for the command-line directive. Discounting the bizarre case in which the linker may continue with characters from previous lines, the form for the equivalent command-line option is:
/EXPORT:entryname[,@ordinal]
The digits that form the ordinal in this command-line directive are copied from the definition character by character without interpretation. If the @ is given in the definition, as if to introduce an ordinal, but no digits follow, then the command-line directive will continue to the @ even though there is no ordinal.
The code for constructing the successive command-line options uses a buffer of 80h bytes on the stack. There are no checks on the string lengths, and so a sufficiently long entryname or ordinal can induce an overrun and corrupt the stack. Among the (better) outcomes are CPU exceptions, reported as
LINK : error : Internal error during ParseDefVxDExport
In practice, of course, the names and numbers are not nearly long enough to exceed these assumed limits and cause this problem.
This page was created on 8th May 1999. The last significant modification was on 13th May 1999.
Copyright © 1999. Geoff Chappell. All rights reserved.
[Home][Programming Samples][Application Notes][Security Notes][Editorial][Consultation][Contacts]