This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?
- From: Warren Young <warren at etr-usa dot com>
- To: Cygwin-L <cygwin at cygwin dot com>
- Date: Thu, 22 Aug 2013 14:53:55 -0600
- Subject: Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?
- References: <52162CA9 dot 9080002 at etr-usa dot com> <20130822171419 dot GQ2562 at calimero dot vinschen dot de> <CA+sc5mnedD0hOfzwTWYzy0QVhKC9gg-C68Nxfska-HG0HFOpLQ at mail dot gmail dot com>
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