Try to use a TrueType font rather than a raster font. The strategy is:
- [NEW] Try to use 6pt Consolas, then
- [NEW] Try to use 6pt Lucida Console, then
- Try to use the smallest font using SetCurrentConsoleFontEx, then
- Try to use the smallest font using the undocumented SetConsoleFont
XP API.
When a raster font is active, the console turns most/all non-ASCII
characters into '?' characters. We need to select a TrueType font to
preserve these characters.
By calling `setlocale(LC_ALL, "");`, we give the user a chance to
override the ASCII-only default so that non-ASCII arguments are
converted into UTF-16 properly, which is required to pass them
correctly to the actual Win32 executable.
This is necessary because POSIX dictates that we start up with the C
locale, ignoring all environment variables, until that `setlocale()`
call.
This fixes https://github.com/git-for-windows/git/issues/412
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Apparently the non-w64 mingw32 does not have an swprintf function, though
it does have an snwprintf function. In any case, the function takes a
second argument which is a buffer size.
Also include cwchar and cctype.
Print a message when building the test.
* If a new window station can't be created, keep going anyway. I *think*
this is what IntelliJ's fork is doing. Perhaps the window should be
marked SW_HIDE in this case?
* Rename WINPYDBG to WINPTY_DEBUG.
* Add an environment variable WINPTY_SHOW_CONSOLE. If non-empty, the
console window is placed on the same window station and is visible.
It's intended for testing purposes.
If a process is running under control of winpty, the output of the process is decorated with ESC sequences to control a terminal to print the process output nicely. In some environments however, the client showing the output to the user is not a full terminal emulation, the Eclipse CDT debug console view in example, and the ESC sequences are printed as output additional to the real process output. This commit is adding an API function to switch into a mode where winpty is not decorating the process output with ESC sequences. The console mode is designated to pass on the process output to the client as is.
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.
