Currently, when a header file is removed (or renamed), there is a stale
dependency file still referring to the header, and GNU make aborts, because
the header is missing. Attempt to work around this by adding a pattern
rule to generate any header in `src/`. The rule prints a warning message.
The C source file whose header was missing will be recompiled because a
dependency was rebuilt. Once it is, the removed header should be removed
from the dependency file.
(Aside: FWIW, the "ninja" build tool knows directly about depfiles, and it
does not have this problem.)
* Set the PIPE_REJECT_REMOTE_CLIENTS flag on Vista and up.
* Set a DACL on named pipes that gives full control to the built-in
administrators, the local system account, and the current security
token's owner SID. This is the same DACL that is used by default,
except that the default also grants read access to the Everyone group
and the anonymous account.
* Also define WINVER=0x0501, because MinGW's sddl.h only defines
ConvertSidToStringSidW and ConvertStringSidToSidW if WINVER is defined.
(Ordinarily, defining _WIN32_WINNT is sufficient, and it's even
sufficient with the i686-pc-mingw32-g++ compiler packaged with Cygwin.)
* The createSecurityDescriptorOwnerFullControlEveryoneWrite function is
not currently used (or tested), but I think I'll use it in the debug
server to allow collecting trace output from other accounts on the
machine. (I think I'll make that behavior optional.)
I tested this commit with all of the supported compilers: MSYS1 MinGW,
Cygwin MinGW, MSYS2 MinGW-w64, Cygwin MinGW-w64, MSVC2013, and MSVC2015.
The code compiles and runs in all of them. I also examined the DACL
attached to the control pipe, and its SDDL string looked correct.
This bug was already fixed 5 months ago, but AFAICT MinGW.org hasn't
released it yet. MinGW-w64 is unaffected, as is the MinGW compiler
packaged with Cygwin.
The new API improves upon the old API in a number of ways:
* The old API provided a single data pipe for input and output, and it
provided the pipe in the form of a HANDLE opened with
FILE_FLAG_OVERLAPPED. Using a bare HANDLE is difficult in higher-level
languages, and overlapped/asynchronous I/O is hard to get right.
winpty_close closed the data pipe, which also didn't help things, though
I think the handle could have been duplicated.
Using a single handle for input and output complicates shutdown. When
the child process exits, the agent scrapes the final output, then closes
the data pipe once its written. It's possible that a winpty client will
first detect the closed pipe when it's writing *input* rather than
reading output, which seems wrong. (On the other hand, the agent
doesn't implement "backpressure" for either input or output (yet), and
if it did, it's possible that post-exit shutdown should interrupt a
blocked write into the console input queue. I need to think about it
more.)
The new API splits the data pipe into CONIN and CONOUT pipes, which are
accessed by filename. After `winpty_open` returns, the client queries
pipe names using `winpty_conin_name` and `winpty_conout_name`, then
opens them using any mechanism, low-level or high-level, blocking or
overlapped.
(There are still many open design issues in this part of the API.)
* The old libwinpty handled errors by killing the process. The new
libwinpty uses C++ exceptions internally and translates exceptions at
API boundaries using:
- a boolean error result (e.g. BOOL, NULL-vs-non-NULL)
- a potentially heap-allocated winpty_error_t object returned via an
optional winpty_error_ptr_t parameter. That parameter can be NULL.
If it isn't, then an error code and message can be queried from the
error object. The winpty_error_t object must be freed with
winpty_error_free.
* winpty_start_process is renamed to winpty_spawn. winpty_open and
winpty_spawn accept a "config" object which holds parameters. New
configuration options can be added without disturbing the source or
binary API. There are various flags I'm planning to add, which are
currently documented but not implemented.
* The winpty_get_exit_code and winpty_get_process_id APIs are removed.
The winpty_spawn function has an out parameter providing the child's
process and thread HANDLEs (duplicated from the agent via
DuplicateHandle). The winpty client can call GetExitCodeProcess and
GetProcessId (as well as the WaitForXXX APIs to wait for child exit).
As of this libwinpty rewrite, all code outside the UNIX adapter uses a
subset of C++11. The code will build with MSVC2013 or newer. The oldest
MinGW G++ I see on my machine is the somewhat broken MinGW (not MinGW-w64)
compiler distributed with Cygwin. That compiler is G++ 4.7.3, which is
new enough.
There is a "version suffix" that defaults to "-dev". A maintainer could
change the suffix (or remove it) by invoking make:
make BUILD_SUFFIX=-foo
make BUILD_SUFFIX=
It can also be changed in gyp builds:
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=-foo
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=
If git cannot be executed, the string "none" is used for the commit hash.
* This change reduces the total build time from about 14 seconds to about
9 seconds on my computer.
Also:
* Consolidate all the intermediate files into the build directory to
reduces clutter.
* Allow specifying UNIX_ADAPTER_EXE to make. Perhaps this will be helpful
to the MSYS2 fork, which renames console.exe to winpty.exe. (I like
the renaming, but I don't know about the other winpty users. Maybe
I'll make the change after I've put out another stable release...)
* Rename the WINPTY define to COMPILING_WINPTY_DLL define. The longer
name is clearer. I define the macro inside libwinpty/winpty.cc, so the
build system no longer needs to. (I removed the define from
winpty.gyp.)
* Consolidate config-unix.mk and config-mingw.mk into config.mk. The
separation was previously necessary because each file had a conflicting
definition of CXX.
* Rename the UNIX_LDFLAGS_STATIC_LIBSTDCXX macro to UNIX_LDFLAGS_STATIC,
because libstdc++ isn't the only thing I'm linking statically.
* Previously, "make tests install" would also copy trivial_test.exe and
trivial_test.d to /usr/local/bin.
* The `install` tool seems to be the conventional way of installing files.
Setting permissions when copying to /usr/local/bin seems like a good
idea.
* Invoke install with -s to strip the symbol tables when they're
installed.
* 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.
My plan now is to integrate the PseudoConsole with Cygwin and MSYS ptys,
with initial focus on Cygwin. I think I'll keep the separate Agent and DLL
binaries, and they'll continue to be native Win32 binaries. I don't want
to have two build systems (qmake vs whatever MSYS/Cygwin uses), and since
I'd like to remove the Qt dependency anyway, I'm trying to switch to
makefiles.
