[kjksf]

In case you're not just riffing: no, it's not statically linked.

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.

[rovingeye]

I still don't see a reason to re-implement this functionality when you can just.. statically link the loader. CHOC is great though!

[julesrms]

I wrote this a year or two ago and have forgotten the details, but there was definitely some reason why you couldn't "just statically link" it, otherwise that's exactly what I would have done, and saved myself some hassle.

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...

[rovingeye]

That's about when they added the capability, yeah. They've dropped support for win 7/8, not sure if CHOC goes back that far.

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.