On 9/23/2010 21:38, NightStrike wrote:
> On Tue, Sep 21, 2010 at 5:13 PM, Andy Koppe<andy.ko...@gmail.com>  wrote:
>> On 21 September 2010 12:51, Earnie wrote:
>>> Andy Koppe wrote:
>>>>> Cygwin isn't strictly obliged to provide an interface to Windows.
>>>>
>>>> No, but then it wouldn't really be Cyg*win* anymore. It would
>>>> effectively be Interix with a particularly slow fork(). That's
>>>> unless it moved into its own subsystem, which of course would mean a
>>>> major redesign. Also, it would be good-bye to cygutils, mintty,
>>>> rxvt-native, Xwin and anything else that mixes POSIX with the Windows
>>>> API.
>>>
>>> Which isn't going to sell.  No one will want the changes.
>>
>> I'm sure there are a fair few people who'd trade a faster fork() for
>> reduced Windows integration, although I'm not among them.
>
> Are you suggesting that assuming long == pointer size results in a
> fast fork?  Because that was the root of the discussion, if I'm
> following properly.
>

Hi,

I don't think Earnie is saying that. If we still want some integration 
with Windows within Cygwin/MSYS, ABI needs to be the same.

I just thought that with so many LP64 assumptions being made, it might 
be easier to "fix" Cygwin than to fix every single program one by one.

Of course, fast fork() is a nice bonus if it works.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to