Both, DllMain and DllEntryPoint are merely symbolic names of the same concept. They even share the same prototype. But they aren't the same:
The function must be defined with the __stdcall calling convention.
The parameters and return value must be defined as documented in the
Win32 API for WinMain (for an .exe file) or DllEntryPoint (for a DLL).
It is recommended that you let the linker set the entry point so that
the C run-time library is initialized correctly, and C++ constructors
for static objects are executed.
(MSDN Library from Visual Studio 2005)
The entry point in a DLL is the same as in an EXE technically, but with different semantics and prototype (EXE vs. DLL). Both are to be found at IMAGE_OPTIONAL_HEADER::AddressOfEntryPoint. However, in a DLL this entry point is optional (although usually supplied by the runtime library). The entry point isn't explicitly exported through the export directory (although IDA for example shows them under "Exports"). Most of the time there is no public name attached to this entry point, which is why the documentation refers to it as DllEntryPoint. If you find this name in the export directory of the PE file it's probably not the actual entry point from the PE optional header (this would have to be confirmed by looking at the exact sample, though). The last point, btw, holds for DllMain as well.
DllMain is the name the runtime library (ATL, MFC ...) implementation expects you to supply. It's a name the linker will see referenced from the default implementation of DllEntryPoint which is named _DllMainCRTStartup in the runtime implementations. See the CRT source files crtdll.c and dllcrt0.c if you have Visual Studio.
This means that DllEntryPoint calls DllMain - assuming default behavior. The runtime-implemented entry point function (_DllMainCRTStartup) does other initialization.
You can override this name by using the /entry command line switch to the linker. Again, it's just a name and you can choose whatever you fancy. The limitations (not being able to load another DLL using LoadLibrary from within the entry point and so on) are independent of the name you give the function.
Side-note: in an EXE the TLS callbacks run before the entry point code, which can be dangerous in malware research. I don't think this is relevant to DLLs, though, but if someone has more knowledge in that area I'm interested to see pointers to material.
Peter Ferrie, a distinguished reverser and malware analyst, pointed out in a comment to this answer:
TLS callbacks always run in statically-linked DLLs, and since Vista,
they also run in dynamically-linked DLLs! For more information, see my
TLS presentations, and of
course my "Ultimate" Anti-Debugging Reference
Thanks Peter.
