On Fri, Aug 23, 2013 at 02:23:30PM -0400, Larry Hall (Cygwin) wrote: >On 8/23/2013 12:33 PM, Warren Young wrote: > ><snip> > >>> I just hope this won't lead to more confusion if 32 bit processes >>> started from 64 bit (or vice versa) don't act as expected in some >>> circumstances. >> >> Oh, it probably will, but a cygcheck dump will tell us when this is probably >> happening, because both Cygwin bins will be in the PATH. > >Probably but I think we need to keep a close eye on how much this adds to >the support load and user confusion. If it is more than a small amount, I >think it's worth considering a sunset clause on this or perhaps a switch >(ugh) to turn this on for those that know, love, and want it. :-)
I was having a private chat with Corinna about this. Her doubts above mirror mine. I wonder if this will add to the traffic from people who, e.g., expect their java apps to understand Cygwin ptys. Now we will have people who don't understand why their 32-bit screen doesn't work under 64-bit Cygwin mintty. The original error message was certainly not clear but maybe we need to have something like: "Can't run 32-bit Cygwin programs in a 64-bit Cygwin environment" and vice versa with a, as you say, (ugh) way to turn this on and off. FWIW, I just made some modifications to Corinna's previous change. The latest snapshot reverts the behavior of not passing Cygwin blocks to windows programs since that can subtly break cygcheck and strace. Instead the process block magic number for 32/64 bit cygwin processes has changed so that they don't think that they've received information from a cygwin process. It should have the same effect as the previous change, with less modifications to code flow and without breaking longstanding Cygwin dll behavior. cgf -- 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
