From the readme:
> Internally, some absolutely hideous shenanegans are involved to make this possible!
Yeah, like literally embedding a dll in the header file.
Pretty cool, but seems kinda fragile.
> Internally, some absolutely hideous shenanegans are involved to make this possible!
Yeah, like literally embedding a dll in the header file.
Pretty cool, but seems kinda fragile.
(In fact, it's less fragile than a loose DLL, because you don't run the risk of your DLL failing to install/being moved/accidentally loading some other random version of the same DLL etc)
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.