+/*
+ * Support for Windows DLLs.
+ *
+ * When external source code includes header files for dynamic libraries,
+ * the external source code is "importing" DLL symbols into its resulting
+ * object code. On Windows, symbols imported from DLLs must be explicitly
+ * indicated in header files with the __declspec(dllimport) directive.
+ * This is not totally necessary for functions because the compiler
+ * (gcc or MSVC) will generate stubs when this directive is absent.
+ * However, this is required for imported variables.
+ *
+ * The LDAP libraries, i.e. liblber and libldap, can be built as
+ * static or shared, based on configuration. Just about all other source
+ * code in OpenLDAP use these libraries. If the LDAP libraries
+ * are configured as shared, 'configure' defines the LDAP_LIBS_DYNAMIC
+ * macro. When other source files include LDAP library headers, the
+ * LDAP library symbols will automatically be marked as imported. When
+ * the actual LDAP libraries are being built, the symbols will not
+ * be marked as imported because the LBER_LIBRARY or LDAP_LIBRARY macros
+ * will be respectively defined.
+ *
+ * Any project outside of OpenLDAP with source code wanting to use
+ * LDAP dynamic libraries should explicitly define LDAP_LIBS_DYNAMIC.
+ * This will ensure that external source code appropriately marks symbols
+ * that will be imported.
+ *
+ * The slapd executable, itself, can be used as a dynamic library.
+ * For example, if a backend module is compiled as shared, it will
+ * import symbols from slapd. When this happens, the slapd symbols
+ * must be marked as imported in header files that the backend module
+ * includes. Remember that slapd links with various static libraries.
+ * If the LDAP libraries were configured as static, their object
+ * code is also part of the monolithic slapd executable. Thus, when
+ * a backend module imports symbols from slapd, it imports symbols from
+ * all of the static libraries in slapd as well. Thus, the SLAP_IMPORT
+ * macro, when defined, will appropriately mark symbols as imported.
+ * This macro should be used by shared backend modules as well as any
+ * other external source code that imports symbols from the slapd
+ * executable as if it were a DLL.
+ *
+ * Note that we don't actually have to worry about using the
+ * __declspec(dllexport) directive anywhere. This is because both
+ * MSVC and Mingw provide alternate (more effective) methods for exporting
+ * symbols out of binaries, i.e. the use of a DEF file.
+ *
+ * NOTE ABOUT BACKENDS: Backends can be configured as static or dynamic.
+ * When a backend is configured as dynamic, slapd will load the backend
+ * explicitly and populate function pointer structures by calling
+ * the backend's well-known initialization function. Because of this
+ * procedure, slapd never implicitly imports symbols from dynamic backends.
+ * This makes it unnecessary to tag various backend functions with the
+ * __declspec(dllimport) directive. This is because neither slapd nor
+ * any other external binary should ever be implicitly loading a backend
+ * dynamic module.
+ *
+ * Backends are supposed to be self-contained. However, it appears that
+ * back-meta DOES implicitly import symbols from back-ldap. This means
+ * that the __declspec(dllimport) directive should be marked on back-ldap
+ * functions (in its header files) if and only if we're compiling for
+ * windows AND back-ldap has been configured as dynamic AND back-meta
+ * is the client of back-ldap. When client is slapd, there is no effect
+ * since slapd does not implicitly import symbols.
+ *
+ * TODO(?): Currently, back-meta nor back-ldap is supported for Mingw32.
+ * Thus, there's no need to worry about this right now. This is something that
+ * may or may not have to be addressed in the future.
+ */