winpty/README.md

152 lines
5.4 KiB
Markdown
Raw Normal View History

2016-03-30 07:59:32 +00:00
# winpty
2016-06-14 05:03:47 +00:00
[![Build Status](https://tea-ci.org/api/badges/rprichard/winpty/status.svg)](https://tea-ci.org/rprichard/winpty)
winpty is a Windows software package providing an interface similar to a Unix
pty-master for communicating with Windows console programs. The package
consists of a library (libwinpty) and a tool for Cygwin and MSYS for running
Windows console programs in a Cygwin/MSYS pty.
2016-03-30 07:59:32 +00:00
The software works by starting the `winpty-agent.exe` process with a new,
hidden console window, which bridges between the console API and terminal
input/output escape codes. It polls the hidden console's screen buffer for
changes and generates a corresponding stream of output.
The Unix adapter allows running Windows console programs (e.g. CMD, PowerShell,
2016-03-30 07:59:32 +00:00
IronPython, etc.) under `mintty` or Cygwin's `sshd` with
properly-functioning input (e.g. arrow and function keys) and output (e.g. line
buffering). The library could be also useful for writing a non-Cygwin SSH
server.
## Supported Windows versions
winpty runs on Windows XP through Windows 10, including server versions. It
can be compiled into either 32-bit or 64-bit binaries.
## Cygwin/MSYS adapter (`winpty.exe`)
### Prerequisites
You need the following to build winpty:
* A Cygwin or MSYS installation
* GNU make
2016-03-30 07:59:32 +00:00
* A MinGW g++ toolchain capable of compiling C++11 code to build `winpty.dll`
and `winpty-agent.exe`
* A g++ toolchain targeting Cygwin or MSYS to build `winpty.exe`
Winpty requires two g++ toolchains as it is split into two parts. The
2016-03-30 07:59:32 +00:00
`winpty.dll` and `winpty-agent.exe` binaries interface with the native
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
Windows command prompt window so they are compiled with the native MinGW
toolchain. The `winpty.exe` binary interfaces with the MSYS/Cygwin terminal so
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
it is compiled with the MSYS/Cygwin toolchain.
MinGW appears to be split into two distributions -- MinGW (creates 32-bit
binaries) and MinGW-w64 (creates both 32-bit and 64-bit binaries). Either
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
one is generally acceptable.
#### Cygwin packages
The default g++ compiler for Cygwin targets Cygwin itself, but Cygwin also
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
packages MinGW-w64 compilers. As of this writing, the necessary packages are:
2016-03-30 07:59:32 +00:00
* Either `mingw64-i686-gcc-g++` or `mingw64-x86_64-gcc-g++`. Select the
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
appropriate compiler for your CPU architecture.
2016-03-30 07:59:32 +00:00
* `gcc-g++`
* `make`
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
As of this writing (2016-01-23), only the MinGW-w64 compiler is acceptable.
2016-03-30 07:59:32 +00:00
The MinGW compiler (e.g. from the `mingw-gcc-g++` package) is no longer
Remove support for the MinGW compiler packaged with Cygwin. MinGW-w64 is still supported, as is the MinGW compiler distributed by mingw.org. Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by default, which appears to correspond to the "WSL-4" 4.x version of the MinGW project's mingwrt packages. (The version numbers in the /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also consistent with this theory.) The WSL-4 branch was repudiated by the MinGW project as a mistake [1]. The MinGW project claims no responsibility for Cygwin's MinGW packages [2]. There were several releases in short succession [3]: 4.0.3 2013-09-22 4.0.2 2013-09-15 4.0.1 2013-09-14 4.0.0 2013-08-23 There have been no 4.x releases since then, though there have been more 3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug that this project has worked around was fixed in 4.0.3 [4], which was never propagated to the Cygwin package. The MinGW packages were apparently orphaned on 2014-09-18 [5] and are still orphaned [6]. The g++ compiler in this package is still 4.7.3 (released on 2013-04-11), which is almost three three years old. While writing the "GenRandom" module, I hit a bug where a non-static data member initializer of pointer-to-function-type segfaulted the compiler. (gcc seemed to have confused the field with a pure virtual method.) [1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec [2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4 [3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ [4] http://sourceforge.net/p/mingw/bugs/2050/ [5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html [6] https://cygwin.com/cygwin-pkg-maint
2016-02-26 06:10:53 +00:00
maintained and is too buggy.
#### MSYS packages
2016-03-30 07:59:32 +00:00
For the original MSYS, use the `mingw-get` tool (MinGW Installation Manager),
and select at least these components:
2015-09-30 09:18:22 +00:00
2016-03-30 07:59:32 +00:00
* `mingw-developer-toolkit`
* `mingw32-base`
* `mingw32-gcc-g++`
* `msys-base`
* `msys-system-builder`
2016-03-30 07:59:32 +00:00
When running `./configure`, make sure that `mingw32-g++` is in your
`PATH`. It will be in the `C:\MinGW\bin` directory.
#### MSYS2 packages
2016-03-30 07:59:32 +00:00
For MSYS2, use `pacman` and install at least these packages:
2015-09-30 09:18:22 +00:00
2016-03-30 07:59:32 +00:00
* `msys/gcc`
* `mingw32/mingw-w64-i686-gcc` or `mingw64/mingw-w64-x86_64-gcc`. Select
the appropriate compiler for your CPU architecture.
2016-03-30 07:59:32 +00:00
* `make`
MSYS2 provides three start menu shortcuts for starting MSYS2:
* MinGW-w64 Win32 Shell
* MinGW-w64 Win64 Shell
* MSYS2 Shell
To build winpty, use the MinGW-w64 {Win32,Win64} shortcut of the architecture
matching MSYS2. These shortcuts will put the g++ compiler from the
`{mingw32,mingw64}/mingw-w64-{i686,x86_64}-gcc` packages into the `PATH`.
Alternatively, instead of installing `mingw32/mingw-w64-i686-gcc` or
`mingw64/mingw-w64-x86_64-gcc`, install the `mingw-w64-cross-gcc` and
`mingw-w64-cross-crt-git` packages. These packages install cross-compilers
into `/opt/bin`, and then any of the three shortcuts will work.
### Building the Unix adapter
In the project directory, run `./configure`, then `make`, then `make install`.
By default, winpty is installed into `/usr/local`. Pass `PREFIX=<path>` to
`make install` to override this default.
### Using the Unix adapter
2016-03-30 07:59:32 +00:00
To run a Windows console program in `mintty` or Cygwin `sshd`, prepend
`winpty` to the command-line:
$ winpty powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:\rprichard\proj\winpty> 10 + 20
30
PS C:\rprichard\proj\winpty> exit
## Embedding winpty / MSVC compilation
See `src/include/winpty.h` for the prototypes of functions exported by
`winpty.dll`.
Only the `winpty.exe` binary uses Cygwin; all the other binaries work without
it and can be compiled with either MinGW or MSVC. To compile using MSVC,
download gyp and run `gyp -I configurations.gypi` in the `src` subdirectory.
This will generate a `winpty.sln` and associated project files. See the
`src/winpty.gyp` and `src/configurations.gypi` files for notes on dealing with
MSVC versions and different architectures.
Compiling winpty with MSVC currently requires MSVC 2013 or newer.
2016-03-30 07:59:32 +00:00
## Debugging winpty
winpty comes with a tool for collecting timestamped debugging output. To use
it:
2016-03-30 07:59:32 +00:00
1. Run `winpty-debugserver.exe` on the same computer as winpty.
2. Set the `WINPTY_DEBUG` environment variable to `trace` for the
`winpty.exe` process and/or the process using `libwinpty.dll`.
2016-03-30 07:59:32 +00:00
winpty also recognizes a `WINPTY_SHOW_CONSOLE` environment variable. Set it
to 1 to prevent winpty from hiding the console window.
2016-03-30 07:59:32 +00:00
## Copyright
2016-03-30 07:59:32 +00:00
This project is distributed under the MIT license (see the `LICENSE` file in
the project root).
By submitting a pull request for this project, you agree to license your
contribution under the MIT license to this project.