Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <01e001c152ac$3e9d8e10$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT cygwin DOT com>, <RCUNNINGHAM AT redlake DOT com>
References: <OF9D4D8BB2 DOT 929166C8-ON88256AE2 DOT 006F89D1 AT redlake DOT com>
Subject: Re: Multiple cygwin installs: I have to do it, but how?
Date: Fri, 12 Oct 2001 09:27:07 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: <RCUNNINGHAM AT redlake DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Friday, October 12, 2001 7:01 AM
Subject: Re: Multiple cygwin installs: I have to do it, but how?


> I've been thinking about it a bit more, and there is a better way to
look
> at this issue:  From an OO perspective.  Right now, Cygwin is a
singleton.
> We need only add an abstraction layer to allow multiple instances.

Uh, to draw an analogy, what you are saying is that the Linux kernel is
a singleton, and with the correct abstraction layer multiple kernels can
coexist at once. Well, actually they cannot - witness user mode linux -
AFAIK the user mode linux is not able to be booted from as the base
kernel, it can only be booted into within Linux.

> First, the Cygwin registry entries must be tied to a specific Cygwin
> instance.  Hopefully, the location of the Cygwin root directory alone
> should be sufficient to make the distinction.  So, under the "Cygnus
> Solutions" key, there should be trees for each install, with the name
of
> the head of each tree being simply the path to the root for that
install.
> All the existing keys would then be replicated within that tree.
Simple?

As Chuck has pointed out, you are not allowing for a bootstrap - how
does each 'instance' identify itself? If your answer is a compile time
switch to cygwin1.dll, well then this ALREADY EXISTS. See the mailing
list and you can build your own cygwin2.dll that uses a different
registry key. See that was easy.

> As for cygwin1.dll, it needs to know which install launched it (or,
> conversely, which install it belongs to), which in turn will let it
> determine if a separate common memory area needs to be allocated and
used.
> This would be independent of the DLL version, which would allow each
> install to be updated independently.  (However, the DLL version *may*
need
> to be saved in the Registry as well, though I'm not at all sure about
> that.)  Would this work?

I suggest you actually grab the cygwin source and read for a little. The
common memory area is *not optional* and *is always used*. Having
different names for that is not *supported* but can be done by
those-who-are-willing-to-support-themselves.

> Still, we may need a way to bind each application installation to a
> specific Cygwin instance.  Again, we can add information to the
Registry to
> handle this, though at this point it will be simpler to build a list
of the
> binaries "belonging" to a given Cygwin installation within a file
located
> under the root for that install (the logical place would be in
/etc/setup).

This is so far off-base I can't believe it. Cygwin1.dll is automatically
loaded by the OS. If you want a binary to use a different cygwin1.dll,
you have only two choices:
1) Use the path luke.
2) Use a different .dll name.

> Let's say an app is started that is not associated with any Cygwin
> installation.  What should be done?  The cygwin1.dll need only make
the
> association by presenting the user with a list of the root points, and
> requesting one of them be selected.  Then the app is added to that
Cygwin
> instance, and it runs under that environment.

This logic is false.
a) Cygwin1.dll is what you want to associate with given .exe's.
b) cygwin1.dll is autoloaded.
c) HOW CAN IT REPLACE ITSELF TRANSPARENTLY?

> This would even allow multiple Cygwin instances to share mount points,
say
> for data or home directories.  Also, there is no reason why a given
program
> can't be "registered" to run with multiple Cygwin instances (to avoid
> redundant installs of apps that work fine under more than one
> installation).

Actually there is a very very very good reason. The windows linker does
not support asking the user which .dll to load with.

> Someone, please tell me this is too simple to work.  (Not necessarily
easy
> to implement, but conceptually simple.)

Conceptually you have missed the ballgame.

Let me point out a few things:
1) Cygwin1.dll takes the place of libc in a linux environment.
2) AFAIK you cannot have two copies of a single libc with the same major
version on a single machine.
3) You can have two copies if the major version is different.
4) With cygwin you can have two copies if the major version is
different. Thus cygwinb19.dll(??) and cygwin1.dll co-exist.
5) Cygwin is not an "environment". Cygwin is a .dll, pure and simple.
It's got no *portable* means to tell a new process what copy of
cygwin1.dll to load, so 80% of your idea won't work.
6) The other 20% IS ALREADY IN PLACE. AND YOU"VE BEEN GIVEN A POINTER.

There is no reason for vendors that distribute copies of cygwin1.dll -
the net release with source - to spend man-weeks fiddling around to make
everything separate. All they need to do is ship the cygwin1.dll with
the cygwin setup program and a local cache dir already created. Then for
their specific apps - say gcc + scripts - all they have to do is
integrate them the *same way* they would on a unix system. No problem,
no fuss.

If they choose not to, that is their problem, and they will lose
customers.

As a part time hacker on cygwin, I've spent far to many hours trying to
tweak performance up to consider adding the sort of overhead you are
proposing simply to allow *software vendors* to get away with sloppy
product integration.

And finally, as for the idea of "want two cygwin's get two PC's"....

AHAHHAAHAHAHAHAHAHHHAHAHAHHAHAHAHAHAHAHA

Rob


--
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/