<p>I am currently using this for checking processes</p>
<pre><code>func checkForProc(proc string) bool {
cmd := exec.Command("tasklist.exe", "/fo", "csv", "/nh")
cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
out, _ := cmd.Output()
if bytes.Contains(out, []byte(proc)) {
return true
}
return false
}
</code></pre>
<p>But i am wanting to use Windows API, I already use AllenDang/w32 in my project, so i can use its built in functions. I need to get a full list of all the process names, The only ones i could find that use API only give you there PID....</p>
<hr/>**评论：**<br/><br/>jugalator: <pre><p>Heh, this led me down to a bit of a rabbit hole...</p>
<p>One commonly recommended way of getting to the process name from a Win32 process handle is by using <a href="https://msdn.microsoft.com/en-us/library/ms683217(v=VS.85).asp" rel="nofollow">GetProcessImageFileName</a>. However, this one doesn't seem to be covered by AllenDang/w32. There are other ways too, but I couldn't really find a good and clean way of enumerating all process <em>names</em> using any combo of functions in that library. It seems to hit a roadblock due to not implementing any Win32 function taking you to the final step of getting to the actual process name.</p>
<p>So you could maybe <a href="https://github.com/golang/go/wiki/WindowsDLLs" rel="nofollow">implement it yourself</a>?</p>
<p>However, then things got a bit interesting. Read uluorta's comment on GetProcessImageFileName:</p>
<blockquote>
<p>We had an issue with GetProcessImageFileName() on WinXP: When you change the name of the folder containing an executable and then run the executable, GetProcessImageFileName() gives the previous folder name. This happens on a single session [it works fine after restart].
Then we used GetModuleFileNameEx() which overcame this problem, but it somehow has WOW64 issues [noted in its own page]. The final solution we have found is querying WMI with WQL:</p>
<p>Check out: <a href="http://msdn.microsoft.com/en-us/library/aa390423(VS.85).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/aa390423(VS.85).aspx</a></p>
<p>Likewise, you can query WMI like "SELECT * FROM Win32_Process WHERE ProcessId = ####" and this method probably works on all distributions.</p>
<p>Check Win32_Process class too: <a href="http://msdn.microsoft.com/en-us/library/aa394372(VS.85).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/aa394372(VS.85).aspx</a></p>
</blockquote>
<p>I think "WOW64 issues" above is that <code>GetModuleFileNameEx</code> can only get names of 32 bit processes in a 32 bit application, and 64 bit processes on 64 bit applications. So from a normal 64 bit application, you'd probably miss out swathes of still common 32 bit processes.</p>
<p>So, basically the WMI query <code>SELECT Name from Win32_Process</code> ought to give you what you want. See also <a href="https://msdn.microsoft.com/en-us/library/aa394372(v=vs.85).aspx" rel="nofollow">Win32_Process</a>.</p>
<p>WMI is a high level API "on top of" Win32 which you query like a database, only it's about the system state. And there are Go libraries for WMI support. With that support, you could reach a crapload of functionality other than enumerating processes alone. So, while WMI is a bit higher level than pure Win32 calls, it may be good enough, and besides very powerful and flexible in many other ways, while still only using a single Go library.</p>
<p>See this for a WMI library for Go? <a href="https://godoc.org/github.com/StackExchange/wmi" rel="nofollow">https://godoc.org/github.com/StackExchange/wmi</a></p>
<p>The sample even has what you want. ;-)</p></pre>SaturnsVoid: <pre><p>Thanks! I will look into using WMI. </p></pre>globalgobble: <pre><p>Hi you could use wmi or check mitchellh's go-ps for inspiration.</p></pre>JHunz: <pre><p>You can use CreateToolhelp32Snapshot and then use Process32First and Process32Next to iterate through them. Looks like w32 already supports this.</p></pre>
