This is the mail archive of the
mailing list for the Cygwin project.
RE: 1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program
I ran into similar issues, which seemed to be fixed in 1.7.12 - but if you
are still having issues even on the current Cygwin version of 1.7.13, I'd be
interested to know if they can be resolved. If it's anything like the issue
I found, it has to do with erroneous pipe handling in Cygwin and nothing
directly to do with .NET.
Have you read this thread yet that I started last month?
The technique I found useful was to use Reflector to decompile the .NET
Framework's Console class. You could also refer to the framework's source
code, which Microsoft has made publicly available (believe it or not!).
(But for me, decompiled results from Reflector are often faster than trying
to obtain and then find the exact set of C# source files used to compile the
class in question. Also, Reflector provides convenient hyperlinks to jump
from one related function to another.)
After decompiling, I traced the code so I knew exactly what Win32 API calls
were being made to read/write the console. I was then able to isolate and
reproduce the issue in a straight Win32 app, taking .NET out of the equation
- which I then posted to the mailing list:
1. I simplified C# code to smallest / simplest size possible that still
reproduces the issue.
2. I decompiled each function call I made to the framework, and followed
the framework's code to see what API calls it made. I took notes and made a
list of API calls that it made in chronological order.
3. Using my notes, wrote a simple C++ program that reproduced the issue.
4. Simplified the C++ program as much as possible while reproducing the
Sent: Friday, April 20, 2012 10:27
Subject: Re: 1.7.10->1.7.13 : output from .NET programs does not get through
pipeline to a visual c++ program
Strange, I am using mintty and tcsh. It also fails for me in cmd/bash,
It does work with straight forward cmd prompt, no cygwin shells. I am using
32bit windows 7 though, not sure if that helps.
$ uname -a
CYGWIN_NT-6.1 F1N6LQ1 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin
Perhaps a little bit more about development environment?
Using VS2010 C# 4.0 (VS2008 fails to work as well using C# 3.0 and C# 2.0)
OK, while writing this I did test this on a 64bit windows and I get the same
result, no output from readin.
My original post has the cygcheck output, is there any major difference
between your configuration and mine there? I am more than happy to try out
various options that might fix or even help work out what is going on.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple