> -----Original Message-----
> Sent: Friday, April 27, 2012 00:17
> Subject: Re: Cygwin passes through null writes to other software when
> redirecting standard input/output (i.e. piping)
>
> Nope, it won't always be that because I get what's expected. I built the
C++
> files using mingw g++. Although I actually expected the reader to honor
the
> null byte, it did not. Perhaps you are using a different version of
Windows
> than I am or a different runtime.
As I stated, I did two demo programs using Visual C++ 2008 and .NET
Framework 3.5. I did not test mingw. This is on Windows 7 64-bit, fully
up-to-date. Perhaps your mingw runtime doesn't have this bug, in which
case, good for them! But that doesn't change the fact that not many people
use mingw in comparison to Visual C++ or .NET Framework 3.5. And I'm not
sure how you can complain that you can't reproduce it if you don't use
similar tools to what was used to originally reproduce the issue. (Did I
really need to preface my phrase of "will always be" with conditions that
you use Visual C++ / .NET Framework? I thought it would be obvious,
especially since I was referring to bugs in their runtimes...)
If you don't want to install a full Visual Studio environment, you can use
the C# compiler on any computer with the .NET Framework installed. For
example, framework 3.5's compiler is at
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe. The free Windows SDK
contains a Visual C++ compiler in it. And there are free express versions
of Visual Studio available if you want an IDE. You can test these sorts of
things without forking over big bucks for paid Visual Studio licenses.
> What you are seeing may be because Cygwin was changed to use message-
> type pipes a couple of revisions ago. This is not going to change. The
change
> was adopted to fix a problem with Cygwin programs and those are obviously
> our #1 priority.
In which case, it would be a shame for Cygwin to break compatibility with
the vast majority of Windows programs out there, which are probably using
the two most common development platforms on Windows: Visual C++ and the
.NET Framework. That sounds insane; I can't believe the developers would
make that call. It seems crazy that they would not even regularly test with
software compiled using non-free compilers. (May as well rip out the
cygpath tool and friends; why make pretenses about supporting
interoperability with Windows programs?)
I liked Cygwin since I thought it offered compatibility with software
designed for both Linux and Windows. Apparently the fine print is that it's
now only supporting compatibility with stuff linked to cygwin1.dll, and
standard Windows software need not apply - since compatibility with Windows
software is not a real goal? Unfortunately, now I can't think of any good
solutions that support both Linux and Windows software, whose developers
place a priority on compatibility with both. If Cygwin doesn't support
Windows software compiled using very common platforms like Visual C++/.NET,
then nobody really does that I can think of. (Sure, there is Windows
Services for UNIX, but we all know the mess that brings - we're using Cygwin
for a reason... And MSYS isn't really a replacement for Cygwin either; they
don't pretend to be "UNIX on Windows".)
More to the point, I didn't have these problems with Cygwin 1.7.9. What
"problem with Cygwin programs" are you referring to? Because I never had
any - 1.7.9 worked great. All I know, is I upgraded to a more recent
version and boom - everything stopped working. Why were message pipes used?
And what source code files exactly are you talking about? Cygwin has a lot
of source code, but if I knew exactly where to look or better understood
what it is doing and why, maybe I could offer some more constructive ideas -
having done some low-level programming with pipes on Windows myself. (At
first glance, I don't really see how message pipes vs byte pipes would make
a difference.)
And from a practical standpoint - again, while ideally it would be nice for
Microsoft to go back and fix every single version of Visual C++ and .NET
Framework that have this bug (which probably dates back to when these
products were first created), and for Windows app developers to then
redeploy their apps with these fixed runtimes - I think the chances of that
happening in the next few years are zero. I'm a practical/pragmatic person,
which is why I suggested working around their bugs. (As a regular reader of
Raymond Chen's blog, apparently Windows works around app bugs, too...)
> There's no way that Cygwin could know to "skip" a call to WriteFile().
> Cygwin doesn't interpose itself in the middle of a pipe. That would be
truly
> disastrous. If it somehow looked at every pipe read/write rather than
just
> allowing I/O to flow from one end to the other, the mailing list would be
> even more filled with people complaining that Cygwin is slow.
If there is no other way, then maybe it should. Better to be functional and
sacrifice a couple milliseconds, rather than be fast and broken. Given that
I've never seen pipes in the Windows command prompt or Cygwin 1.7.9 run
"disastrously slow", I'm sure there is a solution.
James
--
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
