Dela via


Importera med DEF-filer

Om du väljer att använda __declspec(dllimport) tillsammans med en .def-fil bör du ändra .def-filen till att använda DATA i stället för CONSTANT för att minska sannolikheten för att felaktig kodning orsakar ett problem:

// project.def
LIBRARY project
EXPORTS
   ulDataInDll   DATA

Följande tabell visar varför.

Nyckelord Genererar i importbiblioteket Export
CONSTANT _imp_ulDataInDll, _ulDataInDll _ulDataInDll
DATA _imp_ulDataInDll _ulDataInDll

Med hjälp av __declspec(dllimport) och CONSTANT visas både imp versionen och det odekorerade namnet i .lib DLL-importbiblioteket som skapas för att tillåta explicit länkning. Med hjälp av __declspec(dllimport) och DATA visas bara versionen imp av namnet.

Om du använder CONSTANT kan någon av följande kodkonstruktioner användas för att komma åt ulDataInDll:

__declspec(dllimport) ULONG ulDataInDll; /*prototype*/
if (ulDataInDll == 0L)   /*sample code fragment*/

-eller-

ULONG *ulDataInDll;      /*prototype*/
if (*ulDataInDll == 0L)  /*sample code fragment*/

Men om du använder DATA i .def-filen kan endast kod som kompileras med följande definition komma åt variabeln ulDataInDll:

__declspec(dllimport) ULONG ulDataInDll;

if (ulDataInDll == 0L)   /*sample code fragment*/

Att använda CONSTANT är mer riskabelt eftersom om du glömmer att använda den extra indirekta nivån kan du eventuellt komma åt importadresstabellens pekare till variabeln – inte själva variabeln. Den här typen av problem kan ofta visas som en åtkomstöverträdelse eftersom importadresstabellen för närvarande görs skrivskyddad av kompilatorn och länkaren.

Den aktuella MSVC-länkaren utfärdar en varning om den ser CONSTANT i .def-filen för att ta hänsyn till det här fallet. Den enda verkliga orsaken till att använda CONSTANT är om du inte kan kompilera om en objektfil där huvudfilen inte finns med __declspec(dllimport) i prototypen.

Se även

Importera till ett program