Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <5.0.2.1.1.20011019200239.00b07e88@64.71.142.4>
X-Sender: peterk AT 64 DOT 71 DOT 142 DOT 4
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 19 Oct 2001 20:03:07 -0700
To: cygwin AT cygwin DOT com
From: Peter Kennard <peterk AT livingwork DOT com>
Subject: re: propagation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed


Snipped from archive search :)


Thanks for thinking it a good idea - I downloaded the CVS source for cygwin
and am on the trail of it.


As I thought it is a giant "C++ blob" with rafts of dependencies. But the
essence of it is there.  The fundamental seems to be the "Class reg_key"
code which extracts and puts the info into the registry in the appropriate
key slots.  The DLL appears to keep a mirror structure of this internally
which it uses for speed issues.  All reasonable design But highly dependent
on the cygwin internal build-time environment.  I'll take a peek -


How I have handled such things before on large projects is to read the
source and generate specific isolated source which is completely self
contained.


I agree that the symlinks would be good to have unified with the OS but I
see this bit as one evolutionary crusade at a time :).


Re: Propagation
=B7     To: cygwin at cygwin dot com
=B7     Subject: Re: Propagation
=B7     From: Corinna Vinschen <cygwin at cygwin dot com>
=B7     Date: Thu, 18 Oct 2001 13:50:09 +0200
=B7     References: <=B7        5 DOT 0 DOT 2 DOT 1 DOT 1 DOT 20011017190546 DOT 00abd528 AT 64 DOT 71 DOT 142 DOT 4>


On Wed, Oct 17, 2001 at 07:23:42PM -0700, Peter Kennard wrote:
  >
  > I am really pleased now that cygwin is more complete and has the new
  > "mount" virtual file system.  I can now treat all my boxes the same as far
  > as most command line oriented operations are concerned.
  >
  > But a lot of very useful apps open source, and not, written for windows use
  > the C:\blah\file path system
  >
  > A nudge to them could be offering a tiny code snippet that will:
  >
  > detect the presense of cygwin mount registry entries, if they are there
  > translate a path in a buffer from the cygwin path to the associated windows
  > path and return a flag indicating whether cr/lf translation is set on.  Or
  > leave a windows path untouched.
  >
  > ret =3D toCygpath(const char *inbuff,char *outbuf, int maxlen);
  >
  > (the reverse would be nice too :)
  >
  > It should be completely stand alone with no dependencies on cygwin
  > dlls.  This so it could very easily be installed in windows apps that are
  > not presently "cygwin" compatible, but may wish to be without being
  > dependent on it.  This snippet should be commercially usable to encourage
  > it to be included in as many apps as possible.
  >
  > It would be really cool if the cygwin mount system could become a windows
  > environment industry wide shared resource and help get rid of the
  > ^%$$^#^%$^$ colon (outside of a URL) and the backslash.  I know I woudl put
  > it in my code.
  >
  > I would write it if there is a concensus on it, though I'm sure the
  > fictionality is in the cygwin codebase already and it shouydl be used ;^>



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/