Exportar funciones desde una DLL con dllexport

Me gustaría un ejemplo simple de cómo exportar una función desde una DLL de Windows C ++.

Me gustaría ver el encabezado, el .cpparchivo y el .defarchivo (si es absolutamente necesario).

Me gustaría que el nombre exportado no estuviera decorado . Me gustaría usar la convención de llamadas más estándar ( __stdcall?). Me gustaría el uso __declspec(dllexport)y no tengo que usar un .defarchivo.

Por ejemplo:

  //header
  extern "C"
  {
   __declspec(dllexport) int __stdcall foo(long bar);
  }

  //cpp
  int __stdcall foo(long bar)
  {
    return 0;
  }

Estoy tratando de evitar que el enlazador agregue guiones bajos y / o números (¿recuentos de bytes?) Al nombre.

Estoy de acuerdo con no admitir dllimporty dllexportusar el mismo encabezado. No quiero ninguna información sobre la exportación de métodos de clase C ++, solo funciones globales de estilo C.

ACTUALIZAR

Sin incluir la convención de llamada (y el uso extern "C") me da los nombres de exportación que me gustan, pero ¿qué significa eso? ¿Es cualquier convención de llamada predeterminada que obtengo lo que pinvoke (.NET), declare (vb6) y GetProcAddressesperaría? (Supongo GetProcAddressque dependería del puntero de función que creó la persona que llama).

Quiero que esta DLL se use sin un archivo de encabezado, por lo que realmente no necesito tanta fantasía #definespara hacer que el encabezado pueda ser utilizado por una persona que llama.

Estoy de acuerdo con una respuesta que es que tengo que usar un *.defarchivo.

Si desea exportaciones simples de C, use un proyecto de C, no C ++. Las DLL de C ++ se basan en la manipulación de nombres para todos los ismos de C ++ (espacios de nombres, etc.). Puede compilar su código como C yendo a la configuración de su proyecto en C / C ++ -> Avanzado, hay una opción "Compilar como" que corresponde a los modificadores del compilador / TP y / TC.

Si aún desea usar C ++ para escribir los componentes internos de su lib pero exportar algunas funciones sin alterar para usarlas fuera de C ++, consulte la segunda sección a continuación.

Exportación / importación de bibliotecas DLL en VC ++

Lo que realmente quiere hacer es definir una macro condicional en un encabezado que se incluirá en todos los archivos fuente en su proyecto DLL:

#ifdef LIBRARY_EXPORTS
#    define LIBRARY_API __declspec(dllexport)
#else
#    define LIBRARY_API __declspec(dllimport)
#endif

Luego, en una función que desea exportar, usa LIBRARY_API:

LIBRARY_API int GetCoolInteger();

En el proyecto de construcción de su biblioteca, cree una definición, LIBRARY_EXPORTSesto hará que sus funciones se exporten para su construcción DLL.

Dado LIBRARY_EXPORTSque no se definirá en un proyecto que consume la DLL, cuando ese proyecto incluya el archivo de encabezado de su biblioteca, todas las funciones se importarán en su lugar.

Si su biblioteca va a ser multiplataforma, puede definir LIBRARY_API como nada cuando no está en Windows:

#ifdef _WIN32
#    ifdef LIBRARY_EXPORTS
#        define LIBRARY_API __declspec(dllexport)
#    else
#        define LIBRARY_API __declspec(dllimport)
#    endif
#elif
#    define LIBRARY_API
#endif

Cuando utilice dllexport / dllimport, no es necesario utilizar archivos DEF, si utiliza archivos DEF, no es necesario utilizar dllexport / dllimport. Los dos métodos realizan la misma tarea de diferentes maneras, creo que dllexport / dllimport es el método recomendado de los dos.

Exportación de funciones no manipuladas desde una DLL de C ++ para LoadLibrary / PInvoke

Si necesita esto para usar LoadLibrary y GetProcAddress, o tal vez para importar desde otro idioma (es decir, PInvoke desde .NET, o FFI en Python / R, etc.) puede usar en extern "C"línea con su dllexport para decirle al compilador C ++ que no altere los nombres. Y dado que estamos usando GetProcAddress en lugar de dllimport, no necesitamos hacer el baile ifdef desde arriba, solo un simple dllexport:

El código:

#define EXTERN_DLL_EXPORT extern "C" __declspec(dllexport)

EXTERN_DLL_EXPORT int getEngineVersion() {
  return 1;
}

EXTERN_DLL_EXPORT void registerPlugin(Kernel &K) {
  K.getGraphicsServer().addGraphicsDriver(
    auto_ptr<GraphicsServer::GraphicsDriver>(new OpenGLGraphicsDriver())
  );
}

Y así es como se ven las exportaciones con Dumpbin / export:

  Dump of file opengl_plugin.dll

  File Type: DLL

  Section contains the following exports for opengl_plugin.dll

    00000000 characteristics
    49866068 time date stamp Sun Feb 01 19:54:32 2009
        0.00 version
           1 ordinal base
           2 number of functions
           2 number of names

    ordinal hint RVA      name

          1    0 0001110E getEngineVersion = @ILT+265(_getEngineVersion)
          2    1 00011028 registerPlugin = @ILT+35(_registerPlugin)

Entonces este código funciona bien:

m_hDLL = ::LoadLibrary(T"opengl_plugin.dll");

m_pfnGetEngineVersion = reinterpret_cast<fnGetEngineVersion *>(
  ::GetProcAddress(m_hDLL, "getEngineVersion")
);
m_pfnRegisterPlugin = reinterpret_cast<fnRegisterPlugin *>(
  ::GetProcAddress(m_hDLL, "registerPlugin")
);

Para C ++:

Acabo de enfrentar el mismo problema y creo que vale la pena mencionar que surge un problema cuando uno usa tanto __stdcall(o WINAPI) como extern "C" :

Como sabéis extern "C"quita la decoración para que en lugar de:

__declspec(dllexport) int Test(void)                        --> dumpbin : ?Test@@YaHXZ

obtienes un nombre de símbolo sin decorar:

extern "C" __declspec(dllexport) int Test(void)             --> dumpbin : Test

Sin embargo la _stdcall(= macro WINAPI, que cambia la convención de llamada) también decora nombres de modo que si usamos ambos obtenemos:

   extern "C" __declspec(dllexport) int WINAPI Test(void)   --> dumpbin : _Test@0

y extern "C"se pierde el beneficio de porque el símbolo está decorado (con _ @bytes)

Tenga en cuenta que esto solo ocurre para la arquitectura x86 porque la __stdcallconvención se ignora en x64 ( msdn : en arquitecturas x64, por convención, los argumentos se pasan en los registros cuando es posible, y los argumentos subsiguientes se pasan a la pila ).

Esto es particularmente complicado si su objetivo es plataformas x86 y x64.

Dos soluciones

1. Utilice un archivo de definición. Pero esto te obliga a mantener el estado del archivo def.

2. la forma más sencilla: definir la macro (ver msdn ):

#define EXPORT comment (linker, "/ EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)

y luego incluir el siguiente pragma en el cuerpo de la función:

#pragma EXPORT

Ejemplo completo:

 int WINAPI Test(void)
{
    #pragma EXPORT
    return 1;
}

Esto exportará la función sin decorar para los destinos x86 y x64 mientras se conserva la __stdcallconvención para x86. En este caso __declspec(dllexport) no es necesario.

Tuve exactamente el mismo problema, mi solución fue usar el archivo de definición del módulo (.def) en lugar de __declspec(dllexport)definir las exportaciones ( http://msdn.microsoft.com/en-us/library/d91k01sh.aspx ). No tengo idea de por qué esto funciona, pero lo hace

Creo que _naked podría obtener lo que desea, pero también evita que el compilador genere el código de administración de pila para la función. extern "C" provoca la decoración del nombre del estilo C. Elimine eso y eso debería deshacerse de su _. El enlazador no agrega los guiones bajos, el compilador lo hace. stdcall hace que se agregue el tamaño de la pila de argumentos.

Para obtener más información, consulte: http://en.wikipedia.org/wiki/X86_calling_conventions http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

La pregunta más importante es ¿por qué quieres hacer eso? ¿Qué pasa con los nombres destrozados?