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.
* 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.
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.
* 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.
* 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
* 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.
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.
* Quoting is needed for empty arguments (i.e. put double-quotes in the
command line) and for arguments containing tabs because both spaces and
tabs can separate arguments.
* A double-quote in the argument doesn't by itself necessitate quoting.
* As of this change, argvToCommandLine quotes an argument in the same
cases as Python's subprocess module.
If I run a GUI program inside mintty using winpty, the GUI's window should
appear on the same desktop as mintty, not on the hidden desktop containing
the winpty console.
Even though STARTUPINFO.lpDesktop's type is LPTSTR (instead of LPCTSTR),
the documentation doesn't say anything about CreateProcess modifying the
lpDesktop string, so I didn't bother making a copy of desktop.c_str().
This lets libwinpty.dll read the WINPTYDBG environment variable that the
unix adapter sets using SetEnvironmentVariable. If DebugClient.cc calls
getenv, then it seems to read a copy of the Win32 environment that the
MSVCRT initializes at startup.
The latter doesn't work when:
* I'm using mintty.
* I invoke python.exe directly, passing it the path to the script.
This came up on Windows XP testing where I installed CPython, but
python.exe wasn't in my PATH, so I couldn't run the script directly.
* The intent of having the length variable was to avoid sending trailing
whitespace for each line, but the previous code never read the variable.
Instead, every line it sent was the width of the terminal window.
* There was a bug where running console.exe inside a TERM=cygwin terminal
resulted in excessive line feeds. This change mitigates that bug, but
doesn't fix it. The problem is that the agent assumes that after it
writes to the last column of a line, the cursor is still on the same
line, but this isn't true for the TERM=cygwin terminal.
* Move the Cygwin/MSYS detection logic from config-*.mk into this new
script.
* Recognize either the 32-bit MinGW or the 32-bit MinGW-w64 compiler
driver for Cygwin.
* This avoids a name conflict with an existing unrelated project.
* I think winpty is a better name anyway. (i) It's more obviously
Windows-related. (ii) I think it more accurately describes what it
does. A "pseudo-console" ought to mirror the console API and allow
replacing the implementation built-in to Windows. This project is only
trying to provide functionality similar to using the master interface of
a Unix pty, but for native console programs.
* Work around UNICODE deficiencies:
- MSYS does not have wstring.
- mbstowcs(NULL, text, 0) returns 0 on MSYS instead of returning the
length of the converted string.
- printf("%ls") does not work on MSYS.
It doesn't work because it leaves in the Cygwin-style paths in variables
like PATH and TMP.
(Also, it doesn't build with MSYS because MSYS's old G++ toolchain lacks
std::wstring.)
I suspect that the library API (pconsole_open) should not be calling exit
if it can't start the agent process, but I don't want to deal with that
right now.
* Also propagate the UNIX environment to Win32. This code doesn't really
work because variables like PATH need path-translation, but I'd like to
save a record of it before killing it off.
