From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23016 invoked by alias); 6 Apr 2008 14:35:27 -0000 Received: (qmail 22998 invoked by uid 22791); 6 Apr 2008 14:35:24 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out2.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 06 Apr 2008 14:34:57 +0000 Received: from localhost (webmail3.netspace.net.au [203.10.110.166]) by mail.netspace.net.au (Postfix) with ESMTP id 8086A707C7; Mon, 7 Apr 2008 00:34:50 +1000 (EST) Received: from 217-133-15-180.b2b.tiscali.it (217-133-15-180.b2b.tiscali.it [217.133.15.180]) by webmail.netspace.net.au (IMP) with HTTP for ; Mon, 7 Apr 2008 00:34:50 +1000 Message-ID: <1207492490.47f8df8aa0c6e@webmail.netspace.net.au> Date: Sun, 06 Apr 2008 14:35:00 -0000 From: klavins@netspace.net.au To: cygwin-apps@cygwin.com Subject: RE: [HEADSUP] Let's start a Cygwin 1.7 release area MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-04/txt/msg00070.txt.bz2 > 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