Im learning to write a DLL in Win32 C++ and I've found that its pretty straightforward :) I just have a few questions:

1.) Do I have to have a DllMain function?
2.) Why do some functions look like this:

void _stdCall bla()
{
...
}

And some look like this:

_declspec (dllexport) void bla()
{
...
}

What are the differences?

Thank you.

Dani AI

Generated

To expand on and with practical, concrete points and common pitfalls.

DllMain: optional, but only for tiny, loader-related work. It receives notifications like DLL_PROCESS_ATTACH / DLL_PROCESS_DETACH and per-thread events. Keep DllMain minimal: do not call LoadLibrary/FreeLibrary, do not create threads, do not wait on synchronization objects, and avoid calling into other DLLs that might not be initialized. For heavier startup/cleanup, expose an explicit Init/Shutdown export and have the host call it after the module is loaded.

Exporting and calling conventions: as said, calling convention (stdcall vs cdecl) controls stack cleanup and symbol decoration on 32‑bit x86; it does not by itself make a function exported or not. On x86 the decoration differs (eg. suffixes like @N), which affects static linking and GetProcAddress lookups. On x64 the Microsoft compiler uses a single ABI so those keywords are effectively ignored. To produce stable, linkable exports use one of:

  • extern "C" to avoid C++ name mangling, or
  • a .def file to control exported names/ordinals, or
  • an import/export macro (see below) so headers are consistent for both DLL and client builds.

C++-specific cautions: Visual C++ runs CRT initialization before your DLL receives DLL_PROCESS_ATTACH and runs CRT cleanup after DLL_PROCESS_DETACH. Exporting C++ classes across module boundaries, sharing heap allocations, or letting exceptions cross the DLL boundary is brittle—especially if the client and DLL use different CRT settings or compiler versions. Prefer a plain C API, opaque handles, and provide DLL-owned alloc/free functions if needed.

Quick checklist

  • Keep DllMain tiny.
  • Match calling conventions in headers.
  • Use extern "C" or .def for stable names.
  • Provide an IMPORT/EXPORT macro for headers.
  • Avoid cross-CRT memory ownership and cross‑module C++ objects.

Example import/export macro:

#ifdef BUILDING_MYLIB
  #define MYLIB_API __declspec(dllexport)
#else
  #define MYLIB_API __declspec(dllimport)
#endif

extern "C" MYLIB_API int WINAPI MyFunction(int arg);

You can have a DLL without DllMain function. Its purpose is for Windows to notify your DLL of various events that might be of interest to it, e.g. whenever another EXE or DLL loads it etc.

_declspec (dllexport) is a Microsoft specific extension for the compiler to tell it to export your function "bla", so that other DLLs and EXEs can link to it and use it. Other way to accompilsh the same is to use the DEF file and specify your exports there.

void _stdcall bla() is just a normal function visible to your DLL only. _stdcall is specifying standard (or PASCAL) calling convention (as opposed to _cdecl or C calling convention).

Ah, thanks. So if i specify _stdCall, then other programs can't use it? And if i use _declspec (dllexport) then other programs can use it? AND THEN if I just make it a function w/o either of those, and put it in a definition file, then its the same as doing _declspec (dllexport)?

Ah, thanks. So if i specify _stdCall, then other programs can't use it? And if i use _declspec (dllexport) then other programs can use it? AND THEN if I just make it a function w/o either of those, and put it in a definition file, then its the same as doing _declspec (dllexport)?

Yes to all. One note, _stdcall has nothing to do with exporting. It specifies the calling convention for your function.

_declspec (dllexport) void _stdcall foo(int a, int b); or
_declspec (dllexport) void _cdecl foo(int a, int b); or
_declspec (dllexport) void foo(int a, int b); - uses compiler default

You should check your compiler documentation for the explanation of calling conventions.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.