Mail Archives: cygwin-developers/2000/06/20/22:11:22
On Tue, Jun 20, 2000 at 09:53:37PM -0400, Andrew Patrzalek wrote:
>I am concerned that future development may start to rely on the
>registry more. For instance, one distribution of Cygwin used a canned
>install program that when used on such a workstation would not allow
>installation to progress since it had to install to C:\ as the root
>directory and not allow installs to another partition, D:\. I realize
>this is not due to cygwin1.dll just the install programs rigidity, but
>it demonstrates a hazardous mindset.
I think that you are mistaken. If there was ever an install program
that insisted on only installing to c:\ it must have been before I
started working on the project (about three years ago). This certainly
is not the direction in which we are moving. The recent setup program
allows the user to specify a root directory so I'm not sure why you
would think that we were trying to make things more rigid.
>Just to re-iterate, this is somewhat a question involving the goals of
>cygwin. I have recently read postings, such as one just recently,
>about altering the registry to extend cygwin's applicability.
Again, specifics would be appreciated. If you are responding to
Corinna's message about recent changes to Cygwin which allow it to load
a registry hive when changing to a new user ID then I don't see this as
at odds with what you are talking about, even though, I must admit I'm
still not entirely clear on what you're asking for.
>If cygwin is an exercise in developing the MSWindows environment that
>is one thing. If cygwin is allowing more exposure the *nix world,
>that's another. There are benefits in either environment, but "long
>live the difference".
Cygwin is primarily an environment to emulate UNIX on Windows to the
fullest extent possible. That means that it often must play tricks on
Windows to accomplish things like fork, exec, and suid. If these tricks
mean playing with a process's memory or manipulating the registry then
we'll do that.
If, in the process of bending Windows beyond recognition, we run into
situations where we've broken it's usability for a recognizable group
of people then we'll endeavor to provide workarounds or CYGWIN= options
to get things working properly.
Cygwin is also used by many people to develop on Windows and that is a
goal that we need to keep in sight, too. Many of Red Hat's customers
could care less about things like mount tables and symbolic links. They
just want a tool chain that is similar to what they are used to on
Solaris.
So, we also, as a secondary goal, try to not to arbitrarily break things
that get in the way of using cygwin as a native build environment. It's
not always possible to do things the Windows way and still maintain a
UNIX feel, so sometimes we suprise people who are unfamiliar with UNIX.
GDB's use of the '\' character is a case in point. However, we still
try to allow gcc and other tools to, as much as possible understand
backslash paths.
>The short answer is that if you don't see Cygwin invading the registry
>more than it already has, this, to me, is a good thing. If this is not
>true then I see problems ahead.
The short answer is that I am not going to put limits on anything. If
we have problems with a certain group of users who are using the Registry
in a certain way, we'll try to accomodate them.
Again, I would be interested in the specifics of your perceived problem.
What software are you running to lock out specific users? Is this a
built-in capability of Windows? Have you purchased this software? Is
the software "home grown"?
Maybe someone else will chime in who is more familiar with what you're
talking about. I am really not familiar with the scenario that you're
describing at all.
cgf
- Raw text -