It determines:
- whether the program has a console
- whether that console has a window
- whether that window is on the current window station
It's motivated by the IntelliJ clipboard/winpty bug.
* Rename QueryFont.exe to GetFont.exe -- it's shorted. Make font table
output shorter. Make the program work on XP.
* Add IsNewConsole.exe
* Add GetBufferInfo.exe
* Clear the executable bit on some .cc files
My motivation at the moment is that I'm trying to share a
git checkout between multiple VMs using VirtualBox's Shared
Folders feature. git in the guest VM isn't able to see the
executable bits from the host due to the VirtualBox/SMB/CIFS
layer. Instead, it thinks text files are non-executable,
unless they have a shebang line. That's a sensible way to
set the flags anyway, so set them like that.
With this commit, there's still one file that isn't handled:
src/shared/GetCommitHash.cmd. It's still marked executable,
but it lacks a shebang line, so the guest thinks it's
non-executable. I'm not sure it should be changed.
So far, I've only tested it on Windows 7. The test passed on that OS:
creating a screen buffer isn't blocked by selection, but writing to an
inactive buffer *is* blocked, regardless of whether the buffer was created
before or after selection began. The use of Mark or SelectAll doesn't
affect behavior.
* 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.
Prior to Windows 7, the undocumented NtQuerySystemInformation API did
not return valid handle information when called by a WOW64 process. To
work around this problem, the 32-bit test program connects to a 64-bit
worker and uses the existing RPC mechanism, issuing LookupKernelObject
commands, which call NtQuerySystemInformation in a native 64-bit
environment.
Even on Windows 7, the NtQuerySystemInformation API returns truncated
kernel object pointers, so, AFAIK, we still need to do this work. Maybe
not, though, if the lower 32 bits are guaranteed to be unique.
On Windows 10, there is a CompareObjectHandles API that works in WOW64
mode.
It seems that this bug was fixed in WOW64 prior to its fixing in the
normal environment.
It makes no sense to run Test_CreateProcess_Duplicate_PseudoHandleBug_IL
on OS's that don't have inherit lists.
