.
Best regards,
James Johnston
--
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
-Original Message-
From: Christopher Faylor
Sent: Wednesday, December 25, 2013 04:13
On Tue, Dec 24, 2013 at 11:01:21PM -, James Johnston wrote:
Hi,
As I have recently mentioned on the main Cygwin mailing list, Cygwin by
default creates FILE_FLAG_OVERLAPPED named pipes
for the consideration of this patch. Here are the change log
entries:
2013-12-24 James Johnston jam...@motionview3d.com
* environ.cc (struct parse_thing): Add pipe_nooverlap option.
* globals.cc (pipe_nooverlap): Declare.
* pipe.cc (fhandler_pipe::create): Honor pipe_nooverlap to create
for WaitForMultipleObjectsEx method... the other
methods have significant performance and/or functional limitations, and they
probably found out from a group within Microsoft that it's ok to wait on a
pipe anyway.
Best regards,
James Johnston
--
Problem reports: http://cygwin.com/problems.html
or
configuration that causes this issue...
Best regards,
James Johnston
--
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
not sure what
the solution should be.
Best regards,
James Johnston
--
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
.
Best regards,
James Johnston
--
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
-Original Message-
Behalf Of Bry8 Star
Sent: Thursday, September 27, 2012 05:14
Subject: Re: include SHA1/MD5 hash/digest of setup.exe, and HTTPS
James, you are right, a combination approach would be better.
But before doing any major changes (on setup.exe), for now, at-least, a
-Original Message-
Sent: Wednesday, September 26, 2012 11:57
Subject: include SHA1/MD5 hash/digest of setup.exe, and HTTPS
Hello,
Please include SHA1/MD5 hash/digest code of setup.exe file, on webpage
next to setup.exe download url-link.
so we can know for sure, if we have a
-Original Message-
Sent: Tuesday, August 28, 2012 07:09
Cc: Aharon Robbins
Subject: Re: stuff running slowly
On 8/27/2012 11:28 PM, Aharon Robbins wrote:
Michael,
Thanks for your note. I understand that process creation on Windows is
slower than on Linux. But what I'm seeing
-Original Message-
Sent: Tuesday, August 21, 2012 14:39
Subject: Re: /etc/profile
Eric Blake eblake at redhat.com writes:
Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL
windows paths from
-Original Message-
Sent: Thursday, August 16, 2012 18:22
To: Cygwin-L
Subject: Re: Promote sqlite 3.7.13-1 from test status?
On 8/16/2012 10:34 AM, Brian Wilson wrote:
is correct, Cygwin is supposed to be a Posix compliant environment
It's also supposed to interoperate with
-Original Message-
Sent: Friday, August 10, 2012 04:13
Subject: Re: running interactive process on xp through cron not working
Any ideas on how to make cron work to allow me run programs
interactively like notepad?
To be honest, making this work is tenuous at best. MS doesn't
-Original Message-
Sent: Friday, July 27, 2012 10:05
Subject: RE: automatically using pipe_byte for certain EXE's
Daniel Colascione wrote:
Since message pipes cause problems _in practice_ and byte pipes (which
Cygwin lived with for many years) don't seem to cause problems _in
-Original Message-
Sent: Friday, July 13, 2012 02:14
Subject: Re: best way to re-install and keep cygwin configuration
So I will just tar up the cygwin directory and put it back after the new
install. If
I download a new copy of setup.exe and point it at the install directory,
will
-Original Message-
Sent: Wednesday, July 11, 2012 20:07
Subject: Re: CTRL+C is not working with java on latest cygwin 1.7.15
Thanks for the reply K Stahl, but it didn't work for me. I ran the same
Test,
then press CTRL+C. But the cygwin terminal did nothing. It did not stop
the
-Original Message-
Sent: Wednesday, July 11, 2012 19:34
Subject: Re: running .bat file in cygwin
Note, fork requires the cygwin1.dll file. Are you prepared for that?
thanks for your response. What got me notice is the above comment?
Would you please elaborate on that? The
-Original Message-
Sent: Friday, June 22, 2012 18:11
Subject: Re: cygwin 1.7.15-1 - .NET console output locks up mintty
I have noticed a problem with the âcygwin: The Unix emulation
engine package, version 1.7.15-1. Output from .NET console does
not show up, the console
-Original Message-
Sent: Friday, June 22, 2012 19:11
Subject: Re: stdout not visible on some programs after upgrading from to
1.7.11-1 to 1.7.15-1
I use cygwin on a windows 7 machine to automate a Visual Studio 10
build from the command line. To do this, I invoke MSBuild.exe
-Original Message-
Sent: Friday, June 22, 2012 02:22
Subject: cygwin 1.7.15-1 - .NET console output locks up mintty
I have noticed a problem with the âcygwin: The Unix emulation engine
package, version 1.7.15-1. Output from .NET console does not show up, the
console
(mintty)
-Original Message-
Sent: Thursday, June 21, 2012 15:55
Subject: Re: Cygwin unstable as hell on Windows7 64bit
On 21/06/2012 11:34 AM, Gerard H. Pille wrote:
I checked the BLODA, but with only the following programs left
running, Cygwin is still getting killed:
$ ps -efW
-Original Message-
Sent: Wednesday, June 20, 2012 16:27
Subject: stdout not visible on some programs after upgrading from to
1.7.11-
1 to 1.7.15-1
Hello,
I use cygwin on a windows 7 machine to automate a Visual Studio 10 build
from the command line. To do this, I invoke
-Original Message-
Sent: Monday, June 18, 2012 16:34
Subject: Re: sshd connections unexpectedly close on windows 2012
5 [main] sshd 180 fhandler_dev_zero::fixup_mmap_after_fork:
requested 0xFEF2 != 0x0 mem alloc base 0x0, state 0x1, size
1179648, Win32 error 487
Red Hat might not have to buy a code signing cert for this. They might
already have one that will work: http://goo.gl/5Hm3C
The Cygwin project is not Red Hat. It wouldn't be Red Hat buying
anything.
What is the Cygwin project then? I honestly thought it was a Red Hat
project... I.e. I've
And only now I've found the messages talking about similar issues after
fruitless Google searches. Same thing happens to me after I buy hardware.
The problem appears fixed in the latest snapshot of cygwin1.dll.
Indeed it was; the problem happened for at least two other people on the
mailing
-Original Message-
Sent: Tuesday, May 22, 2012 06:14
Subject: 1.7.15-1: mintty bash failing to run .NET executables ?
After that, .NET programs failed to launch at all. The mintty bash
terminal just
sits there, no CPU or anything else being used, the .NET .exe failing to
launch
How can 1000 machine instructions of 32 bit be larger than 1000 machine
instructions twice that size! Unless vastly different code generation happens
with 64 bit compilers the number of instructions emitted should be just
about the same yet with 64 bit instructions are obviously twice as big
On 5/18/2012 4:37 PM, JonY wrote:
OK, OK. Tack on for most applications to my statement (I thought it
was assumed).
I believe the same was said when transitioning from 16bit to 32bit.
If so then they were wrong.
Hey, why isn't ls a 16-bit program? Realistically, it does not need anything
64-bit does not make things go any faster than 32-bit.
Not true for some applications. For one of our applications that uses very
large in-memory trees and is therefore heavy on the recursion, simply switching
the compiler to 64-bit provided a 10% performance boost. Other commonly used
On Tue, May 15, 2012 at 06:59:14PM +0200, Pawel Jasinski wrote:
i have discovered something peculiar.
I run my rxvt with the usual:
C:\cygwin\bin\rxvt.exe -bg wheat -fg black -sl 5000 -e /bin/bash -ls
now I try inside to run some *non* cygwin console program rxvt shows
nothing, and
In situations like this, it's useful to examine the .NET Framework and see
how the Microsoft implementation works. Generally, I find that the
implementations in the framework seem good and cover edge cases that I might
not normally think about.
In this case, the System.Console class has a method
- Add CYGWIN=pipe_byte option to force opening of pipes in byte mode
rather than message mode.
I can confirm that setting this fixes the test cases I was having problems
with. Thanks! :)
A suggestion: maybe modify the documentation to state why one would set this?
Current documentation
The cygwin DLL can't intercede here. It's not some superior process
controlling I/O. It's just a DLL used by two programs. cat is writing to
the
stdout that it inherited from the shell.
Good point, I had not thought this through enough. In this case, bash.exe
is asking CYGWIN1.DLL for a
-Original Message-
Sent: Wednesday, May 09, 2012 19:00
Subject: Re: Cygwin passes through null writes to other software when
redirecting standard input/output (i.e. piping)
I can't say with 100% certainty, but I would bet with 90+% confidence that
this
is a bug in MS's libraries --
-Original Message-
Sent: Saturday, April 28, 2012 23:03
Subject: Putting package directory in c:\Cygwin
Putting the packages directly in c:\Cygwin is ill-advised because it shows
up in
the posix directory /. It pollutes the directory with millions of
package
folders. But what if
-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
-Original Message-
Sent: Friday, April 27, 2012 14:38
Subject: Re: Cygwin passes through null writes to other software when
redirecting standard input/output (i.e. piping)
What I don't grok is this:
In your example, A and B are both native (== non-Cygwin) applications.
As I
standard inputs that might have null writes.
Best regards,
James Johnston
--
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
-Original Message-
Sent: Tuesday, April 24, 2012 12:38
Subject: Re: 1.7.10-1.7.13 : output from .NET programs does not get
through
pipeline to a visual c++ program
begin readin.cxx
#include windows.h
int
main(int argc, char* argv[])
{
static_castvoid(argc);
issues causing fork failures: (1)
cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
ASLR-relocated/system DLLs
On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote:
[snip]
... Today this issue came
to a head on one installation of Cygwin 1.7.9,...
[snip]
Thoughts
-Original Message-
Sent: Monday, April 23, 2012 14:51
Subject: Re: Two probable basing issues causing fork failures: (1)
cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
ASLR-relocated/system DLLs
Yes, it is a problem in the first place if DLLs have the
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
on it. And also several Windows XP
system DLLs (i.e. no ASLR) being placed in the 0x6000 range as well
(with an example being shown above).
Thoughts, anyone?
Best regards,
James Johnston
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq
).
I wonder why it worked sometimes but not other times (e.g. running echo
`./HelloCPP | cat` would sometimes work, sometimes not)? With something
like this, I would think it would not work 100% of the time.
Best regards,
James Johnston
-Original Message-
Sent: Monday, March 12, 2012 22:02
You're partially correct, depending on how you look at it... As I wrote
earlier, I reproduced it with a straight Win32 program, too - by doing a
null write that every C# program would do. So I guess it's not specific to
C#, since C++ programs can cause it too. But every C# program would
the test...
Best regards,
James Johnston
-Original Message-
Sent: Monday, March 12, 2012 14:19
Subject: Re: Can't reliably redirect standard output from C# program in recent
Cygwin
On Mar 12 14:05, James Johnston wrote:
You're partially correct, depending on how you look at it... As I
I have also noticed this issue; again it was with the XML serialization
functions like Andres Martinelli originally noted. The root of the problem is
that Windows environment variables are not case sensitive, while they *are* in
a Unix environment. Cygwin passes an environment block with
I can reproduce this:
C:\cygwin\binperl -e 'print abc;'
abc
C:\cygwin\binperl -e 'print abc;' | more
abc
C:\cygwin\binperl -e 'print abc;' | more
abc
C:\cygwin\binperl -e 'print abc;' | more
C:\cygwin\binperl -e 'print abc;' | more
C:\cygwin\binperl -e 'print abc;' | more
I also noticed that
I think this is a regression:
1. Used setup to install Cygwin package 1.7.10. Problem still exists.
2. Since setup did not offer me the ability to go back to 1.7.9, I found my
old archive for that version and extracted the bin files to manually go back
to that version. Problem fixed!
So it
it? (e.g. creating an issue/ticket)
2. Workaround suggestions?
3. Which part of Cygwin do I need to roll back to fix this issue for now?
Best regards,
James Johnston
-Original Message-
Sent: Thursday, March 08, 2012 21:17
Subject: Can't reliably redirect standard output from C# program
50 matches
Mail list logo
