This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Proposal] Moving user mount information to HKLM


On Sat, Sep 28, 2002 at 07:47:28PM -0700, Doru Carastan wrote:
>>..  I expect that, as time progresses, there will be more checks to
>>ensure that doesn't happen.  1.3.13 has new checks for this, in fact.
>
>This makes sense only if RH views Cygwin as an Microsoft Windows OS
>UNIX extension and not as a standalone UNIX emulator or VM running on
>top of Windows.

It makes sense in the context of many many many people having problems with
two versions of cygwin in their path or even just on the system.

Their problems aren't due to the fact that I'm being mean.  The problems
are due to the fact that cygwin makes some assumptions about the layout
of areas passed between processes, both in shared memory and as part of
the "cygheap".

>>You don't install two versions of linux on your system and expect them
>>to> interoperate at the same time.  Ditto, cygwin.

>It is like comparing apples with oranges.  I have not seen yet Linux
>running directly on top of a win32 host, nontheless cygwin running
>naked without a win32 host.

The point is that cygwin is essentially an "OS" in the context in which
it is being used.  You don't run two OS's on the system at the same time
unless you're running some kind of micro-kernel or something.

I am trying to set the mind set here.  As the person responsible for cygwin
development, that's how we are progressing.  Now that you understand, by
way of analogy, how we are progressing, it should be easier for you
to comprehend.

If you want to use a Windows analogy, think "two versions of
msvcrt.dll".  Having two of those in the path can also cause problems.

>Everybody who read the code knows that a debug cygwin1.dll or regular
>one built for a different shared memory and registry can coexist with
>other versions.

Actually, it doesn't work all that well, even in this context.  We have a
problem with this RIGHT NOW, in fact.  Getting this working reliably is
a constant battle.  It was actually quite broken for months.  It's only
a little broken now.

>What's wrong in having the latest 'stable' version of Cygwin and also
>experimenting with the latest net release installed on the same computer.

Nothing at all.  Do it all the time.  I switch back and forth.  I actually
keep two versions on my system, since I know how to do that.  I just am
careful not to run both at the same time or to do so in contexts that I
know won't cause problems.

>One can use the stable one and switch to the most recent one when percieved
>as stable.  Or get back to the version on which things where working fine.

Sure, switch away.  Copy the cygwin DLLs, using windows utilities, into your
cygwin bin directory.

You realize that I, and any other person who develops cygwin, has to do
this all of the time, right?  I'm managing quite well without having to
run two versions at the same time.

>It is all about freedom.  Why to deliberately restrict this?

Because getting it working reliably is hard and having two versions of the
DLL on the system is a technical support nightmare.  You obviously are not
reading the cygwin mailing list.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]