Question about redirecting Cygwin process's I/O to the client side of an Win32 named pipe.
Hi, list
I'm working on a very small software component, that can create a
Cygwin process, and redirect it's I/O to the client side of an Win32
named pipe.
The creating process now have a handle of the server side of the Win32
named pipe. The creating process can then write to/read from the
sub-process through the pipe handle.
This is pretty much like mintty, which spawn bash.exe by redirecting
bash.exe's I/O to the slave side of a pty.
But because the component is intended to be used by Win32 native apps,
like MFC apps, JNI, etc, it is not plausible to use the pty
facilities provided by cygwin1.dll.
It is also not appropriate to dynamically load cygwin1.dll in the
creating process.
The method is below:
1. Win32 native A.exe create a named pipe and own the handle to the
server side.
2. A.exe create a "detached" starter.exe process. This starter.exe get
the name of the pipe and the argvs of the B.exe(the to be created
Cygwin process) through its command line.
3. starter.exe get handle to client side of the pipe, and create
"detached" B.exe process redirecting its I/O to the client side of
pipe.
The idea comes from another open source project.
The use of the intermediate starter.exe is because, Cygwin process
B.exe will inherit all inheritable handles in parent process,
including the client side handle of the named pipe, but we don't know
whether there exist other inheritable handles in parent process. So, a
"clean" process starter.exe that have no handles is created. The
starter.exe executable is even not linked with C run time, and have no
main(). It's entry is specified by compiler command line option. So,
starter.exe is considered clean.
The problem here is that, this method works for "simple" executable
like Windows's cmd.exe and Cygwin's gdb.exe, but does not work for
Cygwin's bash.exe or python.exe.
bash.exe process can be created, but I can't read data from the pipe.
So, what's wrong ?
What's the difference between bash.exe and gdb.exe or cmd.exe ?
What's the difference between Win32 named pipe and Cygwin pty ?
How can I make it work ?
Some code pieces is attached.
Thanks.
--
Chiheng Xu
#include "stdafx.h"
#include "VG-process.h"
bool CommandLine2Argv(CString & cmdline, CArray & argv)
{
//TODO: consider space and double quote
argv.RemoveAll();
cmdline.Trim();
int prev_index = 0;
int current_index;
while(1){
current_index = cmdline.Find(_T(" "), prev_index);
if(current_index != -1){
CString arg = cmdline.Mid(prev_index, current_index - prev_index);
argv.Add(arg);
prev_index = current_index + 1;
}else{
CString arg = cmdline.Mid(prev_index);
argv.Add(arg);
break;
}
}
return true;
}
bool Argv2CommandLine(CArray & argv, CString & cmdline)
{
//TODO: consider space and double quote
cmdline = _T("");
int array_size = argv.GetSize();
if(array_size){
cmdline += argv.GetAt(0);
int i;
for(i = 1; i < array_size; i++){
cmdline += _T(" ");
cmdline += argv.GetAt(i);
}
}
return true;
}
bool EnvironmentBlock2Evnp(CString & envblk, CArray & envp)
{
return true;
}
bool Evnp2EnvironmentBlock(CArray & envp, CString & envblk)
{
return true;
}
CString GetModulePath()
{
TCHAR zsFileName[_MAX_PATH];
//DWORD dwRes = ::GetModuleFileName(NULL, zsFileName, _MAX_PATH);
DWORD dwRes = ::GetModuleFileName(AfxGetInstanceHandle(), zsFileName, _MAX_PATH);
ASSERT(dwRes);
CString csFilePath = zsFileName;
int nFLs = csFilePath.ReverseFind(_T('\\'));
if (nFLs > 0)
{
csFilePath.ReleaseBuffer(nFLs + 1);
}
return csFilePath;
}
bool CreateAndConnectProcess(CArray & argv, CArray & envp, CString & strPipeName, HANDLE & hpipeProcess)
{
CString cmdline;
Argv2CommandLine(argv, cmdline);
CString starter_cmdline;
starter_cmdline += _T('"');
starter_cmdline += GetModulePath();
starter_cmdline += _T("\\starter.exe");
starter_cmdline += _T('"');
starter_cmdline += _T(' ');
starter_cmdline += strPipeName;
starter_cmdline += _T(' ');
starter_cmdline += cmdline;
//create namedpipe server side
hpipeProcess = CreateNamedPipe(
strPipeName,
PIPE_ACCESS_DUPLEX,// | FILE_FLAG_FIRST_PIPE_INSTANCE,
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES,
4096,
4096,
1,
NULL);
if(hpipeProcess == INVALID_HANDLE_VALUE){
//error
TRACE(_T("CreateNamedPipe failed\n"));
goto fail;
}
SetHandleInformation(hpipeProcess, HANDLE_FLAG_INHERIT, 0);
PROCESS_INFORMATION piProcInfo;
STARTUPINFO siStartInfo;
BOOL bFuncRetn = FALSE;
// Set up members of the PROCESS_INFORMATION structure.
ZeroMemory( &piProcInfo, sizeof(PROCESS_INFORMATION) );
// Set up members of the STARTUPINFO structure.
ZeroMe
Sorry for a previous stupid problem reporting
I report a problem before: http://cygwin.com/ml/cygwin/2011-06/msg00069.html To my surprise, recently I found that it is caused by Norton Antivirus 9.0. It worked well with Cygwin before, things may be changed after a live updating. I'm sorry for not having read the FAQ before reporting. a huge fan of Cygwin -- Chiheng Xu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: building and testing GCC, extremely slow in NTFS, fast in FAT32
On Wed, Jun 8, 2011 at 6:36 PM, Andrey Repin wrote: > > mount > ? Not relevant to mount. This problem is stick to NTFS. If I copy the just built cc1.exe/cc1plus.exe to any other place in the file system, even overwrite the original one, it can run efficiently. -- Chiheng Xu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
building and testing GCC, extremely slow in NTFS, fast in FAT32
Recently, in my XP SP3 machine, building and testing GCC in NTFS are extremely slow. The just built cc1.exe seems to have some attributes or security setting set to wrong values, preventing it from running efficiently. The problem will disappear if I build and test it in a FAT32 file system. I need some help to identify this problem. $ uname -a CYGWIN_NT-5.1 garfield1 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin -- Chiheng Xu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mingw-targeted cross-compiler question
>
> make JAVA_HOME="C:\Program Files\Java\jdk1.5.0_22"
>
> or
>
> JAVA_HOME="C:\Program Files\Java\jdk1.5.0_22"
> export JAVA_HOME
> make
correction:
JAVA_HOME='C:\Program Files\Java\jdk1.5.0_22'
JAVA_HOME=`cygpath -m ${JAVA_HOME}`
export JAVA_HOME
make CC=x86_64-w64-mingw32-gcc
--
Chiheng Xu
Wuhan,China
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mingw-targeted cross-compiler question
On Thu, Dec 16, 2010 at 6:03 AM, gviewer wrote: > > Yes, That problem got solved. But now I got a new problem: > "fatal error, jni.h, no such file or directory" > > The jni.h is included in a .h c file. > > What's going on? > > make JAVA_HOME="C:\Program Files\Java\jdk1.5.0_22" or JAVA_HOME="C:\Program Files\Java\jdk1.5.0_22" export JAVA_HOME make -- Chiheng Xu Wuhan,China -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: linux->cygwin cross build environment
On Thu, Aug 26, 2010 at 2:24 PM, Chiheng Xu wrote: > I attached the scripts I used in December, 2009, trying to build a > Cygwin cross toolchain. > Also attcach the MinGW scripts. -- Chiheng Xu Wuhan,China gcc_mingw.tar.bz2 Description: BZip2 compressed data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: linux->cygwin cross build environment
On Thu, Aug 26, 2010 at 10:53 AM, Charles Wilson wrote: > Last weekend I attempted to setup a linux->cygwin cross compiler (and > basic sysroot). However, it didn't work: while a simple C 'Hello World' > app could be compiled, copied over to a win32 system and executed, a C++ > 'Hello World' did not: > I attached the scripts I used in December, 2009, trying to build a Cygwin cross toolchain. This is much like the MinGW cross toolchain build scripts. The scripts seem not to be able complete the build procdure of gcc. The Chinese characters in the scripts is encoded as gb2312. -- Chiheng Xu Wuhan,China gcc_cygwin.tar.bz2 Description: BZip2 compressed data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building a custom cygwin1.dll library
On Tue, Aug 24, 2010 at 2:54 AM, Lee D. Rothstein wrote: > On 8/22/2010 2:30 AM, Christopher Faylor wrote: >> >> On Sat, Aug 21, 2010 at 09:32:47PM -0400, Gregg Levine wrote: >>> >>> Is it possible to build a custom cygwin1.dll library? I'm in the >>> process of setting up a Win2K8 or Win2K3 server, and I would like to >>> install a personalized install of Cygwin there. >> >> No, it's completely impossible. This is software. Once it's written, >> it's cast in stone. Sorry. >> >> cgf > > Hence the phrase: Let he who is without syntax cast the first stone. ;-) > This is really simple, unless you want to cross build it. But why do you want to build a custom cygwin1.dll library ? I'm curious about the features you want to add. -- Chiheng Xu Wuhan,China -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake wrote: > On 08/09/2010 07:19 PM, Chiheng Xu wrote: >> As far as I know, Cygwin now use Windows shortcut to implement >> symlink. This work well with native apps. > > Not true. Cygwin can read windows shortcuts as symlinks, but does not > generate windows shortcuts to hold new symlinks because windows > shortcuts are inherently limited in such a way that they cannot serve as > true POSIX symlinks. > http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links -- Chiheng Xu Wuhan,China -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
On Tue, Aug 10, 2010 at 1:25 AM, Earnie wrote: > Chiheng Xu wrote: >> >> On Fri, Jul 30, 2010 at 10:50 AM, Chiheng Xu >> wrote: >> > >> > Is 64-bits MSYS or Cygwin necessary? >> > >> > MSYS may be not necessary at all. >> > >> > If Cygwin merge the changes done in MSYS, and provide a Win32_Path >> > mode(translating all Unix paths to Win32 paths at fork/exec or >> > spawn) and MinGW transform itself to use binary mode(linking with >> > binmode.o instead of txtmode.o) and slightly patch uname.exe in >> > coreutils, Cygwin has the potential to replace MSYS and provide >> > many tools missing in MSYS, like tcl/tk, expect, dejagnu necessary >> > for the testing of GCC/GDB/BINUTILS. >> > >> >> What I want to say is that, transform Cygwin to be universal POSIX >> command line environment for Windows. >> > > I understood what you meant. > >> Cygwin's default mode is "Unix path mode", so it can't not launch >> native Win32 executable(like MinGW gcc) that require paths in their >> argv[] to be Win32 path. So Cygwin need to provide an optional >> "Win32 path mode", like MSYS do. >> > > And I know this isn't yet going to happen. There are now some MSYS ideas > present in Cygwin but it has been many years in getting that acceptance. > >> But ordinary Win32 executable is linked with txtmode.o, which is not >> compatible with Cygwin's binary mode. So MinGW also need slightly >> transform itself to linked with binmode.o. >> > > Nor MSYS' binary mode. But this won't change either since the default for > Microsoft is text mode. > I must confess that I'm really a newbie of Cygwin and MinGW. As far as I know, Cygwin has dropped text mode in 1.7, only providing binary mode. This make Cygwin more like an real Linux environment. I think this is because many Unix tools can not work perfectly at text mode. When I use Cygwin shell and MinGW gcc to configure gcc, the configure script invoke `gcc -print-multi-os-directory`, the Cygwin shell could not handle the trailing "\r". If the MinGW gcc work in binary mode, the problem will disappear. So, to let MinGW gcc and other tools work in binary mode seems crucial if you want use Cygwin as MinGW's shell. I am more interested in toolchain(GCC/BINUTILS/GDB). I only want MinGW toolchain to compatible with Cygwin. This can let us use Cygwin to build and test MinGW toolchain. >> Cygwin has an CYGWIN environment variable, can set the mode of >> cygwin1.dll . I believe Cygwin maintainer will accept to add an >> "Win32 path mode". >> > > There is more to it than this. Cygwin provides a script or binary to > convert the paths between Windows and POSIX. But it also does funny things > to emulate symlinks and native GCC has no idea what to do with these. > Makefiles contain the creation of symlinks and this causes the native GCC > problems when building a package. It was not an easy decision to fork > Cygwin when I did but I did because of the issues of acceptance of the > patches. If you feel that you can have luck with providing Cygwin with such > patches more power to you. I would be happy to see it and would promote its > use. > As far as I know, Cygwin now use Windows shortcut to implement symlink. This work well with native apps. Last year, I have tried to patch bash-3.2 of Cygwin to let it's "pwd" built-in command to print the Win32 version of current working directory, like "d:/work/gcc" , instead of "/cygdrive/d/work/gcc". I used the patched Cygwin bash(with MSYS's uname.exe)and MinGW gcc to configure and build MinGW gcc in Cygwin. The configure script work well initially. But it choke at `gcc -print-multi-os-directory`. But, finally, I think the method of patching bash may be not necessary. MSYS's method of translating Unix paths to "mixed" Win32 paths may be necessary and optimal. So, you only need to patch cygwin1.dll . -- Chiheng Xu Wuhan,China -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
