#ifndef _DEFINED_uniqueheadername  //---------------1---------------+
#define _DEFINED_uniqueheadername  //---------------1---------------+
                                                                 // |
  #if _MSC_VER > 1000  //--------------2---------------+            |
    #pragma once                                    // |            |
  #endif //----------------------------2---------------+            |
                                                                 // |
  #ifdef __cplusplus  //---------------3---------------+            |
  extern "C" {                                      // |            |
  #endif // __cplusplus  //------------3---------------+            |
                                                                 // |
  #ifdef _COMPILING_uniqueheadername  //-----------4-----------+    |
    #define LIBSPEC __declspec(dllexport)                   // |    |
  #else                                                     // |    |
    #define LIBSPEC __declspec(dllimport)                   // |    |
  #endif // _COMPILING_uniqueheadername  //--------4-----------+    |
                                                            // |    |
  LIBSPEC linkagetype resulttype name(parameters);          // |    |
  // ... more declarations as needed                        // |    |
  #undef LIBSPEC   //------------------------------4-----------+    |
                                                                 // |
  #ifdef __cplusplus    //----------------5---------------+         |
  }                                                    // |         |
  #endif // __cplusplus  //---------------5---------------+         |
#endif // _DEFINED_uniqueheadername //-----------------1------------+


The explanation of the "contour lines" is as follows

If the header file is actually processed, this is the traditional C idiom to keep it from being
processed twice. The first time the file is included, the symbol _DEFINED_uniqueheadername
is not defined, so the file is processed. The first thing it does is declare that symbol, so
that in subsequent inclusions, the entire body of the file is skipped. 
This is a #pragma which is defined only for C compilers version 10.00 and later (note that the
C compiler version and the VC++ version are not related numbers). If this #pragma is
implemented, the inclusion of this file in a compilation creates an entry in an "included files
table" for that compilation. Subsequent attempts to include this file in the same compilation
first check this table, and if the filename is the same, the compiler doesn't even bother to open
the file. However, you can't eliminate the contour 1 test, because this #pragma, for reasons best
known only to its implementor, is case sensitive in the file name, even though the file name of
the underlying operating system is case insensitive. It seems utterly silly that we should have
two discrete behaviors, but since when has rationality and common sense affected what some
programmers do? 
This contour is required to make the header file compatible with both C and C++. It assumes
that you want C compatibility, and therefore that the function names should not have C++ "name
mangling" applied. The downside of this is that you lose the ability to overload functions based
on parameter types. If you are doing a C++-only DLL, you would not use this contour, and you
would also eliminate contour 5. The __cplusplus symbol is defined for a C++ compilation but
undefined for a C compilation. 
This is a funny contour. The #if/#else/#endif contour decides which form of __declspec to use for
the declaration. The scope of the effect of this contour actually projects beyond the conditional
and extends to the #undef, during which the symbol LIBSPEC is defined. Strictly speaking, you do
not need to do the __declspec(dllimport); you could just define LIBSPEC as an empty macro. However,
declaring __declspec(dllimport) does same one or two instructions on the linkage when it is
finally resolved. Since, using this method, it costs nothing to add this slight efficiency, why
not? Note that contour 4 is not needed for non-DLL files. 
This is the matching close brace to the structure created in contour 3. If you are doing a C++-only
DLL, you would eliminate this as well as contour 3.