RE: [HEADSUP] Let's start a Cygwin 1.7 release area

[klavins at netspace dot net dot au]

> On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> [snip]
> I don't understand this.  As discussed somewhat later, if the root dir 
> follows automatically from where the DLL itself resides.  Which, btw., 
> the current code doesn't do right.  I called GetModuleFileName(NULL) 
> which returns the path of the current application, not the path of the 
> Cygwin DLL.  I'll fix that.
> 
> [snip]
> Which is too late for cygrunsrv itself, right?  The idea is to avoid 
> having to add the Cygwin bin dir to the system variable %PATH%.  If 
> you want to accomplish that, cygrunsrv itself must be independent of it.
> That's only the case if it shares the bin dir with the Cygwin DLL.
> 
> > > Right now I must admit that I prectically don't care if my 
> > > packages install the binaries in /bin or /usr/bin.
> >
> > /bin should contain programs that should work even if the PATH and
> mounts
> > are screwed up.  So, "kill", "shutdown", etc.
> 
> And cygrunsrv.

>From earlier discussions it seems that there are some "nice to have" features 
in future Cygwin for all sorts of real-life not-only-developer-user reasons:
  - users plugging in possibly more than one USB key each containing possibly 
different Cygwins
  - read-only Samba or Windows shares containing a common Cygwin installation 
for multiple client computers
  - 64-bit Windows installations having both 32-bit and 64-bit Cygwin 
installations

As far as I understand it, the current Cygwin runtime architecture uses shared 
memory for those Cygwin processes attached to the Cygwin DLL, and a static 
registry location for its static mount table.  As already discussed, the static 
mount table could move out into the Cygwin file system, freeing up any registry 
conflict for multiple Cygwins.

Is it feasible to consider that more than one Cygwin shared memory be created, 
one for each of multiple Cygwins?  Each Cygwin could be uniquely identified by 
the UNC path to its Cygwin DLL.  The static registry location, or indeed 
another singleton shared memory, could then be used for mapping from Cygwin DLL 
UNC path to the UNC path to its shared memory.

Given that structure, any process using a Cygwin DLL could at Cygwin DLL attach 
time look in the static registry location or the singleton shared memory to 
locate its shared memory UNC path, then go on from there to locate its dynamic 
mount table, security environment, etc., etc.

What do you think?
------------------------------------------------------------------------
 Peter Klavins                                  klavins@netspace.net.au


------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au