The WebViewLoader.dll is embedded in the source code and then loaded into memory as if it was loaded via LoadLibrary() or by Windows .exe loader which loads referenced .dll automatically.
Granted, he re-implemented LoadLibrary() to load from memory, which can potentially break if Microsoft changes the details of how LoadLibrary() is implemented.
This is one of my pet peeves with Microsoft API design. LoadLibrary() only works with files from disk.
It should be implemented as a trivial wrapper around LoadLibraryFromMemory() but Microsoft didn't implement LoadLibraryFromMemory so we have to resort to re-implementing LoadLibrary when we want this very useful functionality.
IIRC it was either because there wasn't support for it back then, or the static version didn't support older Windows versions, or somesuch Microsoft nonsense.
But for whatever reason it was, they strongly push people to use the DLL, and deploying DLLs in installers is a PITA, so...
I suppose this would break the "Nothing needs adding to your build system to use any of this stuff.", but that doesn't seem true now that Boost is a dependency for the server stuff.