Why are the 32- and 64-bit cygwin1.dlls incompatible?

Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Warren Young]

If you try something like this from a Cygwin 64 install:

     $ /cygdrive/c/cygwin32/bin/ls

you get an error like this:

     3 [main] ls (8168) C:\cygwin32\bin\ls.exe: *** fatal error -
     cygheap base mismatch detected - 0x0/0x612A0950.

It goes on to explain that this is due to trying to load an incompatible 
cygwin1.dll.

My best guess is that this happens because the standard Windows DLL 
search logic[1] says "oh, I already have a CYGWIN1 module loaded, I will 
use that one."  And boom.

Yet, if that were truly what's going on, DLL redirection[2] should fix 
it.  From Cygwin 64 again:

     $ touch /cygdrive/c/cygwin32/bin/ls.exe.local
     $ /cygdrive/c/cygwin32/bin/ls
     same complaint as before

Another oddity is that the inverse test succeeds.  From Cygwin 32:

     $ /cygdrive/c/cygwin64/bin/ls
     all   my   base
     $

In another forum[3], Yaakov told me that Windows is supposed to be 
taking CPU bitness into account here, which should be another way for it 
to work without special help.  I don't see mention of such a rule in 
[1], however.

What is really going on here?

Understand, I'm not asking because I want it fixed.  I mean, it'd be 
*nice* if it were fixed, but I'm more interested in knowing why it is 
the way it is.



[1] http://goo.gl/j2g1EL
[2] http://goo.gl/IVI6CE
[3] http://goo.gl/2HcAZk

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

On Aug 22 09:22, Warren Young wrote:
> If you try something like this from a Cygwin 64 install:
> 
>     $ /cygdrive/c/cygwin32/bin/ls
> 
> you get an error like this:
> 
>     3 [main] ls (8168) C:\cygwin32\bin\ls.exe: *** fatal error -
>     cygheap base mismatch detected - 0x0/0x612A0950.
> 
> It goes on to explain that this is due to trying to load an
> incompatible cygwin1.dll.
> 
> My best guess is that this happens because the standard Windows DLL
> search logic[1] says "oh, I already have a CYGWIN1 module loaded, I
> will use that one."  And boom.
> 
> Yet, if that were truly what's going on, DLL redirection[2] should
> fix it.  From Cygwin 64 again:
> 
>     $ touch /cygdrive/c/cygwin32/bin/ls.exe.local
>     $ /cygdrive/c/cygwin32/bin/ls
>     same complaint as before
> 
> Another oddity is that the inverse test succeeds.  From Cygwin 32:
> 
>     $ /cygdrive/c/cygwin64/bin/ls
>     all   my   base
>     $
> 
> In another forum[3], Yaakov told me that Windows is supposed to be
> taking CPU bitness into account here, which should be another way
> for it to work without special help.  I don't see mention of such a
> rule in [1], however.
> 
> What is really going on here?
> 
> Understand, I'm not asking because I want it fixed.  I mean, it'd be
> *nice* if it were fixed, but I'm more interested in knowing why it
> is the way it is.

When execveing a Cygwin process, a lot of data is submitted via shared
memory, via data copying, and via a special parameter to the
CreateProcess call with the mysterious name "lpReserved2".

One problem is the differences in basic datatypes, which results in
incompatible datastructures between 32 and 64 bit.  While this could be
worked around, this doesn't help for the shared memory stuff, which
depends on the installation path of the cygwin DLL.  The Cygwin DLL in
C:\cygwin1 would use a different name for the shared mem regions than
the Cygwin DLL installed into C:\cygwin2, independent of the target
architecture.  This is by design since Cygwin 1.7.  One effect:  No tty
sharing.

Therefore, interaction between the 32 and 64 bit DLLs is not supported.
This was an early design goal when we discussed the 64 bit DLL on the
cygwin-developers list two years ago, but I was almost the only one
favoring this approach, AFAIR.  It also turned out that the complexity
of this approach was pretty high, so we discussed it again early 2013
and I dropped it, otherwise we would very likely not have a 64 bit
distro at this time.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Earnie Boyd]

On Thu, Aug 22, 2013 at 1:14 PM, Corinna Vinschen wrote:
>
> When execveing a Cygwin process, a lot of data is submitted via shared
> memory, via data copying, and via a special parameter to the
> CreateProcess call with the mysterious name "lpReserved2".
>
> One problem is the differences in basic datatypes, which results in
> incompatible datastructures between 32 and 64 bit.  While this could be
> worked around, this doesn't help for the shared memory stuff, which
> depends on the installation path of the cygwin DLL.  The Cygwin DLL in
> C:\cygwin1 would use a different name for the shared mem regions than
> the Cygwin DLL installed into C:\cygwin2, independent of the target
> architecture.  This is by design since Cygwin 1.7.  One effect:  No tty
> sharing.
>

Since you know that the DLL regions are different what about execing
the process as if it were a windows native process?  I know you loose
the ability to do the parent/child relationship but it isn't any worse
than spawning a native process.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Warren Young]

On 8/22/2013 14:46, Earnie Boyd wrote:
> On Thu, Aug 22, 2013 at 1:14 PM, Corinna Vinschen wrote:
>>
>> When execveing a Cygwin process, a lot of data is submitted via shared
>> memory, via data copying...
>
> Since you know that the DLL regions are different what about execing
> the process as if it were a windows native process?

That was my thought.

I assume this data sharing stuff occurs only for Cygwin-to-Cygwin 
exec()s, which is why -- as I recently learned -- cygwin1.dll already 
checks the DLL dependency graph of a process it's about to exec to see 
if it's a Cygwin process.

Couldn't it use this same info to detect that it's about to launch a 
Cygwin program of a different bitness, and fall back to the "native 
Windows program" case?  No attempt to interoperate, just launch it and 
hope for the best.  Fire and forget.

 >> Therefore, interaction between the 32 and 64 bit DLLs is not
 >> supported.

I'd expect it to behave no better than launching a native Win32 console 
program from Cygwin today.

The thing is, that's good enough for a lot of cases.

Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't. 
  Does it really do any kind of interop that would require a "native" 
Cygwin 64 port?

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Aug 22 16:46, Earnie Boyd wrote:
> On Thu, Aug 22, 2013 at 1:14 PM, Corinna Vinschen wrote:
> >
> > When execveing a Cygwin process, a lot of data is submitted via shared
> > memory, via data copying, and via a special parameter to the
> > CreateProcess call with the mysterious name "lpReserved2".
> >
> > One problem is the differences in basic datatypes, which results in
> > incompatible datastructures between 32 and 64 bit.  While this could be
> > worked around, this doesn't help for the shared memory stuff, which
> > depends on the installation path of the cygwin DLL.  The Cygwin DLL in
> > C:\cygwin1 would use a different name for the shared mem regions than
> > the Cygwin DLL installed into C:\cygwin2, independent of the target
> > architecture.  This is by design since Cygwin 1.7.  One effect:  No tty
> > sharing.
> >
> 
> Since you know that the DLL regions are different what about execing
> the process as if it were a windows native process?  I know you loose
> the ability to do the parent/child relationship but it isn't any worse
> than spawning a native process.

Actually, Cygwin alread did that.  When checking the executable to run
for being a Cygwin process, executables with the wrong bitsize were
treated as non-Cygwin executables.

The actual problem was that we always propagate a child_info_spawn
structure to the child via STARTUPINFOW::lpReserved2, no matter what
kind of executable we execute.  The header of this structure is
identical on 32 and 64 bit, so the child process recognized it as a
child_info_spawn block, regardless of the target size of parent and
child.  But then the rest of this child_info_spawn differs a lot due to
different datasizes.

Since it neither makes sense to propagate the Cygwin-specific
child_info_spawn block to native processes, nor to Cygwin processes
with a different bitsize, I just disabled this, so you can now start
32 bit Cygwin processes from 64 bit Cygwin processes and vice versa,
starting with the snapshots I'm just generating.

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.  Here's a typical 32 bit bash started from 64 bit
tcsh in a 64 bit mintty, for instance:

  tcsh-64$ /cygdrive/c/cygwin/bin/bash -i
  bash: cannot set terminal process group (-1): Inappropriate ioctl for device
  bash: no job control in this shell

  $


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Andrew Schulman]

> Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't.

Hah!  Another Orpie user!

I love Orpie, but sometimes I've wondered if I was the only one.

Andrew


--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Warren Young]

On 8/23/2013 03:49, Corinna Vinschen wrote:
>
> Since it neither makes sense to propagate the Cygwin-specific
> child_info_spawn block to native processes, nor to Cygwin processes
> with a different bitsize, I just disabled this, so you can now start
> 32 bit Cygwin processes from 64 bit Cygwin processes and vice versa,
> starting with the snapshots I'm just generating.

Beautiful!

I just tried this snapshot:

   http://cygwin.com/snapshots/x86_64/cygwin1-20130823.dll.bz2

and my 'ls' test succeeded.

Alas, my Orpie test failed:

   $ PATH=/cygdrive/c/cygwin32/lib/lapack /cygdrive/c/cygwin32/bin/orpie
   Fatal error: exception Assert_failure("main.ml", 30, 3)

Line 30 of main.ml is:

   assert (cbreak ());

So....ncurses isn't working correctly across the exec() boundary?

> 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.

I'm hoping this new behavior will simply serve to let more people move 
to Cygwin 64 before absolutely everything is ported.

To my mind, the biggest negative consequence of this improvement is that 
it might delay the porting of some packages by removing an incentive.

--
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: Orpie love (was: Why are the 32- and 64-bit cygwin1.dlls incompatible?)

[Warren Young]

On 8/23/2013 06:42, Andrew Schulman wrote:
>> Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't.
>
> Hah!  Another Orpie user!
>
> I love Orpie, but sometimes I've wondered if I was the only one.

Everyone who appreciates HP RPN calculators should try Orpie.

A decent PC keyboard is far more pleasant to use than even the vaunted 
HP 48GX keyboard.  The only advantage to a handheld calculator is 
portability.

That's true even without considering the pain of alpha mode.

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Achim Gratz]

Warren Young writes:
> Line 30 of main.ml is:
>
>   assert (cbreak ());
>
> So....ncurses isn't working correctly across the exec() boundary?

I don't think ncurses can work without a tty interface and that's one of
the things you've lost through the "foreign" exec.  You'd need something
like starting a 32bit mintty or rxvt-native to run orpie in, I suppose.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Warren Young]

On 8/23/2013 11:53, Achim Gratz wrote:
> Warren Young writes:
>> Line 30 of main.ml is:
>>
>>    assert (cbreak ());
>>
>> So....ncurses isn't working correctly across the exec() boundary?
>
> I don't think ncurses can work without a tty interface

Orpie runs in a cmd.exe window.  ncurses must have some fall-back mode.

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Larry Hall (Cygwin)]

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. :-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Achim Gratz]

Warren Young writes:
> Orpie runs in a cmd.exe window.  ncurses must have some fall-back mode.

IIUC, orpie won't find a tty/pty interface in your situation and it
won't be able to use the cmd.exe interface because it isn't run from
cmd.exe.  What do you expect it to do?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Christopher Faylor]

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

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Charles Wilson]

On 8/23/2013 2:12 PM, Warren Young wrote:
>> I don't think ncurses can work without a tty interface
>
> Orpie runs in a cmd.exe window.  ncurses must have some fall-back mode.

When you launch a cygwin program in a cmd.exe window, cygwin sets up a 
tty-like interface (the TERM=cygwin terminal), and (cygwin)ncurses uses 
that.

--
Chuck


--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Warren Young]

On 8/23/2013 13:16, Christopher Faylor wrote:
> 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.

I don't want this to end up being a bigger problem than the original 
behavior, either.

If you do end up deciding to block cross-Cygwin exec()s, shouldn't 
32-bit Cygwin refuse to run 64-bit Cygwin exes, too?

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Christopher Faylor]

On Fri, Aug 23, 2013 at 06:56:53PM -0600, Warren Young wrote:
>On 8/23/2013 13:16, Christopher Faylor wrote:
>> 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.
>
>I don't want this to end up being a bigger problem than the original 
>behavior, either.

How would that end up being a bigger problem?  It's basically just a
different error message with a way to turn it on and off.

>If you do end up deciding to block cross-Cygwin exec()s, shouldn't 
>32-bit Cygwin refuse to run 64-bit Cygwin exes, too?

"and vice versa"

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

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Earnie Boyd]

On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
>
> 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"

What about CYGWIN=32bitCygwinExec or some such?  And what about the
other direction?

It is clear that some operations cannot occur especially pty but that
is still true with execing any Windows program.  I don't see this
being too big an extra burden on support.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Christopher Faylor]

On Sun, Aug 25, 2013 at 11:05:06AM -0400, Earnie Boyd wrote:
>On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
>>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.

>What about CYGWIN=32bitCygwinExec or some such?

Yes, we were talking about a CYGWIN environment variable.  It would
probably be something like "arch_mismatch".  However, you're jumping to
implementation when it isn't even clear if this is something that we
want to do.

>And what about the other direction?

Apparently "vice versa" is not a universally understood term.

>It is clear that some operations cannot occur especially pty but that
>is still true with execing any Windows program.  I don't see this
>being too big an extra burden on support.

If people don't understand why their Windows programs don't understand
Cygwin ptys I'm sure that they won't understand why their Cygwin
programs don't understand Cygwin ptys.  We just, in fact, already saw
this confusion, mainly because the error was even more confusing than
normal.

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

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On Aug 25 13:26, Christopher Faylor wrote:
> On Sun, Aug 25, 2013 at 11:05:06AM -0400, Earnie Boyd wrote:
> >On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
> >>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.
> 
> >What about CYGWIN=32bitCygwinExec or some such?
> 
> Yes, we were talking about a CYGWIN environment variable.  It would
> probably be something like "arch_mismatch".  However, you're jumping to
> implementation when it isn't even clear if this is something that we
> want to do.

We shouldn't overburden the CYGWIN env var with lots of tiny, nagging
settings which are just as easy to keep in all the time.  Letting the
32 bit version of Cygwin run 64 bit apps...

> >And what about the other direction?
> 
> Apparently "vice versa" is not a universally understood term.

...and vice versa doesn't cost us anything.  We add a FAQ people can be
pointed to and that's it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Christopher Faylor]

On Mon, Aug 26, 2013 at 11:04:06AM +0200, Corinna Vinschen wrote:
>On Aug 25 13:26, Christopher Faylor wrote:
>> On Sun, Aug 25, 2013 at 11:05:06AM -0400, Earnie Boyd wrote:
>> >On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
>> >>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.
>> 
>> >What about CYGWIN=32bitCygwinExec or some such?
>> 
>> Yes, we were talking about a CYGWIN environment variable.  It would
>> probably be something like "arch_mismatch".  However, you're jumping to
>> implementation when it isn't even clear if this is something that we
>> want to do.
>
>We shouldn't overburden the CYGWIN env var with lots of tiny, nagging
>settings which are just as easy to keep in all the time.  Letting the
>32 bit version of Cygwin run 64 bit apps...
>
>> >And what about the other direction?
>> 
>> Apparently "vice versa" is not a universally understood term.
>
>...and vice versa doesn't cost us anything.  We add a FAQ people can be
>pointed to and that's it.

When I said "vice versa", I meant that we might need the same clear
warning for 64-bit programs running on 32-bit platforms.  I'm still not
clear on why this requires so much clarification.  But that's all right.
No need to enlighten me.  I'll just chalk this up to the Cygwin mailing
list confusion vortex.

You know I'm not a big fan of adding options to the CYGWIN environment
variable but I'm less of a fan of having people whine about something
not working, indignantly telling them to read the FAQ, and then having
them whine that there is no workaround.

This could all be a non-issue.  I was just trying to brainstorm and
think ahead.  But there's always that pesky vortex.

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

Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Larry Hall (Cygwin)]

On 8/26/2013 9:51 AM, Christopher Faylor wrote:
> On Mon, Aug 26, 2013 at 11:04:06AM +0200, Corinna Vinschen wrote:
>> On Aug 25 13:26, Christopher Faylor wrote:
>>> On Sun, Aug 25, 2013 at 11:05:06AM -0400, Earnie Boyd wrote:
>>>> On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
>>>>> 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.
>>>
>>>> What about CYGWIN=32bitCygwinExec or some such?
>>>
>>> Yes, we were talking about a CYGWIN environment variable.  It would
>>> probably be something like "arch_mismatch".  However, you're jumping to
>>> implementation when it isn't even clear if this is something that we
>>> want to do.
>>
>> We shouldn't overburden the CYGWIN env var with lots of tiny, nagging
>> settings which are just as easy to keep in all the time.  Letting the
>> 32 bit version of Cygwin run 64 bit apps...
>>
>>>> And what about the other direction?
>>>
>>> Apparently "vice versa" is not a universally understood term.
>>
>> ...and vice versa doesn't cost us anything.  We add a FAQ people can be
>> pointed to and that's it.
>
> When I said "vice versa", I meant that we might need the same clear
> warning for 64-bit programs running on 32-bit platforms.  I'm still not
> clear on why this requires so much clarification.  But that's all right.
> No need to enlighten me.  I'll just chalk this up to the Cygwin mailing
> list confusion vortex.
>
> You know I'm not a big fan of adding options to the CYGWIN environment
> variable but I'm less of a fan of having people whine about something
> not working, indignantly telling them to read the FAQ, and then having
> them whine that there is no workaround.
>
> This could all be a non-issue.  I was just trying to brainstorm and
> think ahead.  But there's always that pesky vortex.

Indeed.  I can feel the vortex tugging at my brain. ;-)

I'm wondering if we going to go the interop route with the CYGWIN
environment variable switch and such if it doesn't make sense
to have the option be off by default but "detection" be on.  In
this case, the user would be warned about what's going on and
could be pointed to more info on how to turn on interop if that's
desirable.  I'm only proposing this in hopes that it would help avoid
lots of confusion about why things do and don't work in interop mode.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

OCaml on cygwin-64 (was: Orpie love (was: Why are the 32- and 64-bit cygwin1.dlls incompatible?))

[Damien Doligez]

Hi all,

On 2013-08-23, at 18:50, Warren Young wrote:

> On 8/23/2013 06:42, Andrew Schulman wrote:
>>> Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't.
>> 
>> Hah!  Another Orpie user!
>> 
>> I love Orpie, but sometimes I've wondered if I was the only one.
> 
> Everyone who appreciates HP RPN calculators should try Orpie.

I don't like RPN calculators but I want to report that I'm making good
progress on porting OCaml to cygwin-64.

Unfortunately, a package will probably have to wait until October when
I come back from my "summer" vacation.

-- Damien


--
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: OCaml on cygwin-64 (was: Orpie love

[Warren Young]

On 8/30/2013 08:15, Damien Doligez wrote:
>
> I don't like RPN calculators

Infidel!

:)

> I'm making good progress on porting OCaml to cygwin-64.

Would you care to summarize the problem?  OCaml is already portable to 
other x86_64 *ix targets, so a lot of the work has to have been done 
already.  What are the remaining blocking issues?

I note your inria.fr address.  I assume you're part of the official 
OCaml team at INRIA, or at least in close contact with them?

--
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: OCaml on cygwin-64 (was: Orpie love

[Damien Doligez]

Hi,

On 2013-08-31, at 00:31, Warren Young wrote:
>> I'm making good progress on porting OCaml to cygwin-64.
> 
> Would you care to summarize the problem?  OCaml is already portable to other x86_64 *ix targets, so a lot of the work has to have been done already.  What are the remaining blocking issues?

Absolutely, although the port shares more code with the mingw-64 version than the Linux version (because the assembler and linker are a bit different from the Linux ones). It was rather easy to make the compiler work, but now I'm waiting for Alain Frisch to port FlexDLL. He said it should be easy.

> I note your inria.fr address.  I assume you're part of the official OCaml team at INRIA, or at least in close contact with them?

I happen to be the release manager of OCaml, so it's quite easy for me to get patches integrated upstream :-) OTOH I'm really busy now with the next OCaml release, so cygwin will have to wait a little bit.

-- Damien


--
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: OCaml on cygwin-64 (was: Orpie love

[Florent Monnier]

2013/08/31, Warren Young wrote:
[...]
> I note your inria.fr address.  I assume you're part of the official
> OCaml team at INRIA, or at least in close contact with them?

http://en.wikipedia.org/wiki/OCaml
http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/

-- 
Regards

--
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