This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
RE: [HEADSUP] Let's start a Cygwin 1.7 release area
- From: klavins at netspace dot net dot au
- To: cygwin-apps at cygwin dot com
- Date: Mon, 7 Apr 2008 00:34:50 +1000
- Subject: RE: [HEADSUP] Let's start a Cygwin 1.7 release area
> 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