Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <3D07C4E0.2050603@ece.gatech.edu>
Date: Wed, 12 Jun 2002 18:02:08 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Conrad Scott <Conrad DOT Scott AT dsl DOT pipex DOT com>
CC: Robert Collins <robert DOT collins AT syncretize DOT net>,
   cygwin-developers AT cygwin DOT com
Subject: Re: System-wide mutexes and pthreads
References: <005401c2124e$7cb91a90$0200a8c0 AT lifelesswks> <028001c21252$e92c7ba0$6132bc3e AT BABEL>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Conrad Scott wrote:

> I know all about the "I used it 'cos I could" feeling. It's a shame that the
> daemon isn't a pure win32 program, but I get the feeling that it will depend
> more on cygwin features as it develops, rather than fewer; for example,
> configuration or log files should obey cygwin naming rather than raw win32.


This reminded me of something....

Robert -- once upon a time the idea was bandied about to create a 
"subcygwin" static library that used only native, non-cygwin calls to 
directly access the cygwin mount table and sort of duplicate the 
functionality of (only) these two functions from cygwin.dll:

   cygwin_conv_to_full_win32_path
   cygwin_conv_to_posix_path

[I'm sure this code is already in setup.exe's codebase -- somewhere]. 
The idea being so that non-cygwin programs -- like setup.exe and perhaps 
the eventual rebase utility -- could understand cygwin paths, while 
remaining "non-cygwin".  [I'm license agnostic here; if we want 
non-open-soure progs to interoperate with cygwin, then the above two 
functions must be re-engineered by someone who hasn't seen cygwin's 
code; that's a lot of work.  Personally, I'm only worried about 
open-source progs, so IMO the chinese firewall is unnecessary: use 
cygwin-inspired code, put it in a GPL'ed static library -- this way Red 
Hat's license is satisfied, and we get a *static* library that enables, 
for instance:
   setup.exe and rebase.exe to understand cygwin paths -- but without 
relying on cygwin1.dll itself.  This is a good and necessary thing for 
these two specialized programs.
   Ditto maybe strace.exe, cygcheck.exe (cygwin programs which do not 
depend on cygwin1.dll)

Now, OTOH, cygserver *could* use this library for path access, but why? 
  cygserver, by its very nature, will depend on cygwin1.dll -- so why 
not use it's path conversion routines.  No need to rely on setup's 
subcygwin.a.  I don't see why using cygwin1.dll from cygserver is a bad 
thing...

Anyway, I lost track of what happened with this proposal.  Was it 
decided that this was a bad idea, and that
   setup
   rebase
   strace
   cygcheck
should all continue to duplicate cygwin-like path translation 
independently, or did the idea just fizzle for lack of volunteers?

--Chuck