Initial implementation of Chrome Early Loading Framework

chrome_elf/README

Index: chrome_elf/README
diff --git a/chrome_elf/README b/chrome_elf/README
new file mode 100644
index 0000000000000000000000000000000000000000..d45207c5845b2dca89a00eb6fc3b39e0879e1cce
--- /dev/null
+++ b/chrome_elf/README
@@ -0,0 +1,15 @@
+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 turning the
+version directory into a private assembly which refers to chrome_elf.dll
+(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. It would also avoid naming
+conflicts (as the WinSxS cache may override the lookup path from a private

[gab, 2013/11/12 18:24:10]

I think it's the GAC and the WInSxS folder (two different things AFAIU) -- they
don't really have the power to "override", they're simply first in the lookup
sequence, so they have the power intercept lookups for private assemblies.

I'm fine with either wording that mentions this more or less...

+assembly). Unfortunately, the probing\privatePath attribute is only supported
+for Windows 7 and later.