win: Add implementation of ProcessInfo

util/win/process_info.h

Index: util/win/process_info.h
diff --git a/util/win/process_info.h b/util/win/process_info.h
new file mode 100644
index 0000000000000000000000000000000000000000..0555e4e6cb1261cabc408646aea0e2e15438c3bb
--- /dev/null
+++ b/util/win/process_info.h
@@ -0,0 +1,79 @@
+// Copyright 2015 The Crashpad Authors. All rights reserved.
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+#ifndef CRASHPAD_UTIL_WIN_PROCESS_INFO_H_
+#define CRASHPAD_UTIL_WIN_PROCESS_INFO_H_
+
+#include <sys/types.h>
+#include <windows.h>
+#include <winternl.h>
+
+#include <string>
+#include <vector>
+
+#include "util/misc/initialization_state_dcheck.h"
+
+namespace crashpad {
+
+class ProcessInfo {
+ public:
+  ProcessInfo();
+  ~ProcessInfo();
+
+  //! \brief Initializes this object with information about the given
+  //!     \a process.
+  //!
+  //! This method must be called successfully prior to calling any other
+  //! method in this class. This method may only be called once.
+  //!
+  //! \return `true` on success, `false` on failure with a message logged.
+  bool Initialize(HANDLE process);
+
+  //! \return `true` if the target process is a 64-bit process.
+  bool Is64Bit() const;
+
+  //! \return `true` if the target process is running on the Win32-on-Win64
+  //!     subsystem.
+  bool IsWow64() const;

[Mark Mentovai, 2015/03/05 17:32:23]

IsWoW64() (two capital double-yous)?

[scottmg, 2015/03/05 20:31:07]

I prefer not, but am happy to change it if you like that way better. (The Win32
API functions spell it "Wow64".)

[Mark Mentovai, 2015/03/05 21:53:36]

scottmg wrote:
OK, if that’s what they consistently call it. I checked Wikipedia, which called
it WoW64—wouldn’t be the first time Wikipedia led us astray. ;)

+
+  //! \return The target process's process ID.
+  pid_t ProcessID() const;
+
+  //! \return The target process's parent process ID.
+  pid_t ParentProcessID() const;
+
+  //! \return The command line from the target process's Process Environment
+  //!     Block.
+  bool CommandLine(std::wstring* command_line) const;
+
+  //! \brief Retrieves the modules loaded into the target process.
+  //!
+  //! The modules are enumerated in initialization order as detailed in the
+  //!     Process Environment Block.

[Mark Mentovai, 2015/03/05 17:32:23]

Will the main executable always appear at index 0? Or would that be load order?

Knowing which module is the main executable might be more useful, but maybe
there’s a different way to work that out that doesn’t need to be part of this
class. We stick the main executable at module index 0 in Mac minidumps.

[scottmg, 2015/03/05 20:31:07]

Unfortunately, one drawback of InitializationOrder is that the main executable
doesn't appear in the list. In MemoryOrder it would always be at index 0.

Perhaps we should prepend it to this list to make that true here too?

[Mark Mentovai, 2015/03/05 21:53:36]

scottmg wrote:
That aspect of the design is up to you. Yes, it’d be nice for it to show up in
the minidump at module index 0, but there are other ways to make that happen
outside of this class, and you get to choose how you want to achieve it.

For example, on Mac, I deal with this in ProcessReader::InitializeModules(),
which is in the snapshot layer.

[scottmg, 2015/03/06 00:42:52]

Inserting it at index 0 seems simplest for now.

[Mark Mentovai, 2015/03/06 14:33:30]

scottmg wrote:
Since this is kind of quirky, I was thinking that we should test that the main
executable really doesn’t show up in the list twice. An easy way to do this is
to remember its load address from the first module in the memory-order list and
then check that each module in the initialization-order list doesn’t match the
main executable’s load address. That should be faster and more robust than
filename comparisons or anything else, but since you’re not tracking load
addresses yet, maybe it can wait for that.

+  bool Modules(std::vector<std::wstring>* modules) const;
+
+ private:
+  PROCESS_BASIC_INFORMATION process_basic_information_;
+  std::wstring command_line_;
+  std::vector<std::wstring> modules_;
+  bool is64bit_;

[Mark Mentovai, 2015/03/05 17:32:23]

is_64_bit_, is_wow64_

[scottmg, 2015/03/05 20:31:07]

Done.

+  BOOL iswow64_;
+  InitializationStateDcheck initialized_;
+
+  DISALLOW_COPY_AND_ASSIGN(ProcessInfo);

[Mark Mentovai, 2015/03/05 17:32:23]

#include "base/basictypes.h"

[scottmg, 2015/03/05 20:31:07]

Done.

+};
+
+}  // namespace crashpad
+
+#endif  // CRASHPAD_UTIL_WIN_PROCESS_INFO_H_