This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding MSYS functionality to Cygwin

On Tue, Jun 18, 2013 at 10:40:36PM +0400, ??????? ?????? wrote:
>Hi everybody!
>I want to add MSYS functionality to Cygwin.
>More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
>MSYS is very old and don't has any support for it.
>Primary goal of MSYS is to provide environment with GNU utilities for
>building application using native Mingw compilers. The main
>differences from original Cygwin is working with native Win32
>So I create new MSYS based on last Cygwin and it works good I think.
>But I think that the right way is to implement MSYS functionality in
>Cygwin sources directly because in this case we don't need to do many
>copies of different Cygwin dll with other names. And we always has
>latest work from Cygwin guys.
>I can write next tasks that need to be in MSYS mode:
>1. The correct definition of executables belonging to Cygwin DLL.
>2. Translating paths in arguments and environment variables to Windows
>form for pure Win32 applications.
>3. In MSYS mode Cygwin need to be very portable: do not use registry
>to store any info, do not use /etc/passwd and /etc/group, all mount
>points need to be with noacl option to avoid problems with permission
>4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>5. Use shorted mount point options in /etc/fstab - only win32_path and
>6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>used in all situations. From the other side - Win32 applications
>doesn't understand Cygwin symlinks. As fallback option we need to
>create copies of files and directories instead symlinks.
>I want to hear your opinions about how it can be implemented in Cygwin codebase.

Corinna and I have been discussing this in private and I thought
someone (you?) was going to bring this up in the cygwin-developers

However, since you mention it here, my opinion is that we should add
hooks in the DLL which allow certain operations like path translation,
symlinks, and command line substitution to be short-circuited or
modified.  In that scenario, you'd still have a MSYS.dll but it would
rely on cygwin1.dll for most of the heavy lifting.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]