Initial implementation of Chrome Early Loading Framework

chrome_elf/README

+Chrome Early Loading Framework (aka ChromeELF)
+
+chrome_elf.dll is shipped in Chrome's version directory to ease updates,
+and is loaded early in chrome.exe's lifetime. This is done by making it a
+private assembly in a subfolder of chrome.exe's folder (see

[gab, 2013/11/11 20:11:38]

Technically I think the assembly is the manifest, which can have many DLLs.

I would change this last sentence to:

"This is done by turning the version directory into a private assembly which
refers to chrome_elf.dll (http://msdn.microsoft.com/library/aa374224.aspx)."

And I would remove the last two paragraphs (I know I originally proposed them,
but I find your new wording for the first paragraph is better and more succinct,
making the last two paragraphs redundant).

Also consider adding a paragraph between the first one and the current second
one as to the potential naming conflict issues with this approach and why we'd
ideally prefer the approach described in the next paragraph.

[Cait (Slow), 2013/11/12 16:33:54]

Done.

+http://msdn.microsoft.com/library/aa374224.aspx).
+
+In an ideal world, this would be done by embedding an application config in
+chrome.exe that would refer to the proper version directory via a
+probing\privatePath attribute (http://msdn.microsoft.com/library/aa374182.aspx).
+This would allow us to refer to dlls in the version directory without having to
+make the version directory itself into an assembly. Unfortunately, this
+method is only supported for Windows 7 and later.
+
+Instead, we use "Assembly Searching Sequence"
+(http://msdn.microsoft.com/library/aa374224.aspx) which states that private
+assemblies can be placed in a subfolder if that subfolder has the same name as
+the assembly itself, and treat the version directory as a private assembly.
+
+This is the best way to have chrome.exe find chrome_elf.dll at load-time without
+putting it beside chrome.exe in the application directory.