Add a chrome_elf_unittest ChromeElfLoadSanityTest which validates that loading chrome_elf does not …

base/message_loop/message_pump_win.cc

Index: base/message_loop/message_pump_win.cc
diff --git a/base/message_loop/message_pump_win.cc b/base/message_loop/message_pump_win.cc
index 44bd463baa64df1743771dd9d538f70fcb13bd9a..d3a762ad59834d31256e15fa804c3049d96ed4c0 100644
--- a/base/message_loop/message_pump_win.cc
+++ b/base/message_loop/message_pump_win.cc
@@ -122,7 +122,6 @@ static const int kMessageFilterCode = 0x5001;
 // MessagePumpWin public:
 
 MessagePumpWin::MessagePumpWin() {
-  InitUser32APIs();

[Lei Zhang, 2016/06/21 20:40:14]

Can you elaborate on why MessagePumpForIO doesn't need this?

[ananta, 2016/06/21 21:57:07]

Thanks. I updated the description on the patch set. This is what I added

Call the InitUser32APIs in MessagePumpForUI and MessagePumpForGpu constructors
instead of the base MessagePumpWin constructor. Reason being that class is also
the base class for the MessagePumpForIO class which may be used by consumers who
don't initialize user32.

 }
 
 void MessagePumpWin::Run(Delegate* delegate) {
@@ -175,6 +174,7 @@ int MessagePumpWin::GetCurrentDelay() const {
 
 MessagePumpForUI::MessagePumpForUI()
     : atom_(0) {
+  InitUser32APIs();
   InitMessageWnd();
 }
 
@@ -511,7 +511,9 @@ bool MessagePumpForUI::ProcessPumpReplacementMessage() {
 // MessagePumpForGpu public:
 
 MessagePumpForGpu::MessagePumpForGpu()
-    : event_(CreateEvent(nullptr, FALSE, FALSE, nullptr)) {}
+    : event_(CreateEvent(nullptr, FALSE, FALSE, nullptr)) {
+  InitUser32APIs();
+}
 
 MessagePumpForGpu::~MessagePumpForGpu() {
   CloseHandle(event_);