Some common utilitiy functions were moved out of _pslinux into _common.

Most of cygwin's Process implementation is directly copied from the
linux Proces, minus a few very Linux-specific parts.  I hope to
eliminate the code duplication later with further refactoring.

Most tests fail due to some key Process methods not having
implementations yet (mostly because their implementations for Linux do
not work on Cygwin).

I left this unimplemented originally just because I wanted to take the
time to understand what I was doing before continuing.  Turns out it can
be implemented almost the same as on Linux, except that the process
start time is in the 22nd field of /proc/<pid>/stat instead of the 21st.
I can't find enough documentation for Cygwin's /proc filesystem, but I
confirmed this in the source.  Other than that the semantics are the
same as on Linux.

So much of this was copied agained from the Linux module, but I will
refactor later.

module.

These are much simpler than on Linux, and effectively the same as the
existing Windows implementations of these functions, though easier to
implement on Cygwin via /proc/meminfo

expect to find.

Currently it is identical to pmem; will return later to seeing what
additional memory info we can provide on Cygwin

Later this should be able to share its implementation with the Linux
module but we'll come back around to that.

Cygwin

Copied almost verbatim from the Linux module.

cygwin module so that the functions in it can be reused there.

This required some tweaks to ntextapi.h, since a few of the
types defined there are already included in the winimpl.h included
with Cygwin.

This includes are own implementation of PyErr_SetFromWindowsErr which
is not defined in Python for Cygwin.

TODO: Because this PyErr_SetFromWindowsErr is lifted, only slightly
modified, from the Python source it should include a copyright notice
to the effect.  This implementation probably does not work quite right
on Python 2 either--it should return an actual WindowsError there.

module for now.

Will refactor later.

… this later.

Copied exactly from the Linux module and seems to work; will refactor
later.

Using the posix implementation directly seems to just work.

The only obvious issue currently is that rather than the human-friendly interface
names returned by this function in the normal Windows implementation, the
interface names are instead some UUID looking things for each interface (the same
as appear in the registry in various places to represent the interface).  This is
fine for now, but not ideal.  Should be able to map these to friendlier names.

renaming it to 'encode', for symmetry with the 'decode' utility.

This utility may also be useful in the Cygwin module, and is otherwise
not Windows-specific, having more to do with Py2/3 compatibility.

This is mostly copied from the Windows module with a few small tweaks, but compiling this
is a bit of a pain and somewhat fragile.  Will have to come back to this for a closer look
later, but for now I just want to get all of the API implemented as best I can.

As with net_if_stats, this is a bit of a mess right now to compile, and copies from the Windows module, but will clean up later.

Once again, mostly copied from the Windows module, with much refactoring needed.

…ited) API.

This will allow methods that return paths to return Cygwin paths instead of native Windows paths.
I have yet to go through and determine all the places this should be used, but there are probably
at least a few.

Whenever calling a C extension method that calls out to the Windows API make sure to use
the Windows PID.  This should fix a lot of issues where the wrong PID was being used.

Most of this is copied from the windows module with a few minor tweaks, necessitating later
refactoring.

This is also the first method to make proper use of the new winpath_to_cygpath function.

… implementations from the windows module (rather than the linux module) but using the winpid.

…verbatim from the windows module.

…module.

This is copied mostly from the Linux module, though it needs to use the utmpx APIs.  This seems to 'work'
insofar as the API is available on cygwin, but it's not clear to me that the information returned is fully
correct or useful.  Will return to this if needed.

…d net_connections.

…ows module

(The linux module's method of looking in /proc doesn't work on cygwin's more limited /proc namespace)

…itches, mostly

supported by the proc_info function copied from the windows module.

(This is just a thin wrapper around proc_info())

Copy/pasted from windows module, so this carries the usual admonition about refactoring.

…uld fail gracefully on AccessDenied errors.

If we get an AccessDenied trying to get the ppid of a process, it's *probably* not a child process of the process in
question anyways.

instead of going through Cygwin's /proc which turns out to be a bit buggy and
for this purpose.

This allows us to expose more information anyways such as USS in memory_info_full,
just unfortunate that the Cygwin interface can't be relied on here.

to get the process environment on Cygwin.  So we remove the
functionality for now.

See https://cygwin.com/ml/cygwin/2016-11/msg00205.html

…ossible to enumerate UNIX sockets on Cygwin

Cygwin emulates UNIX sockets as a INET socket.  Although it does list them in /proc/<pid>/fd as some 'socket:[N]' like on Linux, the 'N' here is only of internal meaning to Cygwin (this is true on Linux as well), but there is nothing resembling /proc/net/unix or anything else that allows one to map that number N to an actual socket file (such a file *does* exist, and in theory we could find it be enumerating ALL files on the system until it is found, but this is not practical).  I can't find any other obvious way to do that.  The only practical solution would be if Cygwin had an equivalent to /proc/net/unix.

…t may prove useful later

…n when trying to query processes for ppid that one does not have access to (TODO: it may be possible to get the ppid by some other means in this case though)

…inpid.

platform-specific differences between how ps is called.

Also implements significant support for Cygwin, where the built-in ps
lacks many of the features of ps on other systems.

This fixes a number of test errors on Cygwin (it also exposes a few new
failures but those will be addressed separately).

…n terminal, so

'who' can return empty--this fix allows the test to work even when there are no utmp entries.

does not actually exist.

This happened to be affecting my test runs.

relied on in Cygwin, due to a rounding error there which can cause it to
return fluctuating results over time.

This is really bad because process creation time is part of the
'identity' psutil util uses for a process when comparing it for equality
to another process.

This once again copies code from the windows module into the cygwin
module, which I intend to refactor later.  I also plan to address the
upstream bug in Cygwin, but until that's fixed this workaround is
needed.

Windows with processes not being truly destroyed quickly enough.

…t getting the

'friendly name' as opposed to the fixed UUID-based name of an interface.  This is more consistent
with the other network APIs on Windows/Cygwin which return the interface friendly names

…_addrs()--kind of a hack for now.

…e one extra process for ps itself.

(I'm not sure how this test worked on Linux since it normally includes ps itself too...)

…hich is not uncommon on Cygwin)

…gher privilege than the test runner

…than POSIX

…-unicode strings

…p from net_connections() results to file descriptors

…e a process is in the zombie state but its /proc/<pid>/stat file can no longer be read.

See https://www.cygwin.com/ml/cygwin/2017-02/msg00187.html

…the comments

…th the functionality in the Windows interface.

This allows the test_nic_names test from the Windows tests to be reused
and to pass on Cygwin.

I'm worried it still might be a bit flakey though.

…er exist

…the .exe right here

(Copied directly from the Windows module for now)

…mlinks

They are failing persistently due to fork errors.  No matter how I rebase the affected DLLs it seems
to have problems on these. I have given up trying to find out why for now.

…king

… AppVeyor

…ld (this did not happen before).

Try a rebaseall immediately before setup.py build.

…ason

(previously this would mistakenly convert something like 'python2.7' to just 'python2'--if the latter
is a symlink this can break things)

It seems that random fork errors can occur here on Cygwin, but not *always*. Retrying usually works.

more time figuring out what the problem is.

…ndent

… on running a subprocess

or cmd.exe.

Doesn't return the build number unfortunately, but we're not using that right now anyways.

…rror

handling from Python wrappers for Windows APIs.

Instead of attempting to reimplement PyErr_SetFromWindowsError, on Cygwin we just
replace those calls with a macro wrapping PyErr_SetFromErrno which uses the
cygwin_internal API to map Windows error codes to POSIX error codes just in the same
way Cygwin would.

This appears to work correctly (for example trying to get info on a non-existent
process returns errno ESRCH (No such process).

their pure Python implementations replaced with more efficient (and less
racy) C implementations.

Although I considered adding a new module for this purpose, for now it
suffices to use the _common module for this (albeit a bit hackishly).

In this case the C wrapper for this function makes sense to put in
arch/windows.