Merge pull request #4 from holtrop/master

added an "install" Makefile target
Copy the Unix environment to the Win32 environment in the unix-adapter.

This should fix issue 5.

The copying appeared to be necessary only for Cygwin, not for MSYS.  I'm
not sure why this is.  I added a call to cygwin_internal(CW_SYNC_WINENV)
for both anyway, because I didn't think it would hurt.
unix-adapter: Link statically with cyggcc_s-1.dll and cygstdc++-6.dll.

 * At least for now, I'm shipping Cygwin/MSYS binaries.  On Cygwin (but
   not MSYS), the console.exe executable previously linked dynamically
   to cyggcc_s-1.dll and cygstdc++-6.dll.

   Linking dynamically with cygstdc++-6.dll seems risky for a binary
   not distributed by Cygwin, because G++'s Windows ABI is unstable, at
   least as of G++ 4.7, which turned on the __thiscall calling
   convention.  If a binary I ship ever comes into contact with a
   4.7-versioned cygstdc++-6.dll, then my binary will (very likely)
   segfault.

   So far, I've only observed this ABI incompatibility with MinGW,
   where a sufficiently upgraded MinGW configuration comes with a
   libstdc++-6.dll that is completely incompatible with every previous
   libstdc++-6.dll, so that every program built against the older
   libstdc++-6.dll segfaults immediately.  For now, Cygwin seems stuck
   at G++ 4.5, and my impression (possibly incorrect), is that G++'s
   Windows ABI was stable prior to 4.7.  I think G++'s Linux ABI is
   stable.  Presumably Cygwin will eventually update its compiler,
   though, so it makes sense to fix the problem early.

   I believe I originally chose to dynamically link the libraries
   because it was the default behavior, and I was afraid that a
   non-default option would break something.  It turns out that
   linking statically with cygstdc++-6 *does* break something -- it
   causes linker errors if the code uses std::cerr.  The workaround
   is not to use std::cerr.  This is not a problem for the
   unix-adapter, which already has to put up with MSYS' gimpy G++ 3.4
   compiler.
MSVC compatibility: Deal with snprintf and vsnprintf.

 * When building with MSVC, there is no snprintf function, but there are
   _snprintf, vsnprintf, and _vsnprintf functions (as well as many
   variations on these).  The MSVC _snprintf is not the same as C99's
   snprintf, and in particular, it does not guarantee that the buffer is
   NUL-terminated, whereas C99 does guarantee this.  I want the C99
   behavior, so add a c99_[v]snprintf functions in shared/c99_snprintf.h
   that provide C99 behavior.

 * Details:
   http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010
MSVC compatibility: Remove the {Agent,WinPty}DebugClient.cc hack.

 * With this hack, it's impossible to add all the .cc files to an MSVC
   project, because MSVC understandably thinks that
   agent/AgentDebugClient.cc and shared/DebugClient.cc are two separate
   C++ translation units.  I could rename DebugClient.cc, but it's better
   to just fix the problem with the Makefile.
Add a gyp project that can build winpty-agent and libwinpty.dll with MSVC.

Peter Rekdal submitted the original version of this file.  I made some
minor changes.

Update the .gitignore file to ignore files generated by building winpty
with MSVC.
In winpty-agent, print an error message if the arguments are invalid.

 * Some users might think they could run winpty-agent.exe.

 * Right now, when I run winpty-agent.exe from a cmd.exe command prompt
   window, it looks like winpty-agent.exe is segfaulting.  It *ought* to
   print an assertion failed dialog box.
Remove CRLF line endings from README.rst.

 * None of the other text files in the repository have CRLF line endings.
Actually say which license this is (MIT)
Merge pull request #11 from sschuberth/master

Actually say which license this is (MIT)
Add API to access the process id of the started process

Added new agent message "GetProcessId" and a API "winpty_get_process_id"
to allow access to the process id of the started process. The process id
is needed to integrate "winpty" with Eclipse CDT to launch native Windows
console applications inside the Eclipse UI.
Simplify patch by using GetProcessId

GetProcessId simplifies the code as it avoids to add the additional member variable 'm_childProcessId'. Cleaned up the indentation.
Fixed indentation

Fixed indentation by replacing TABs by 4 spaces.
Merge pull request #14 from ustieber/patch-1-GetProcessId

Add API to access the process id of the started process