Re: Problem with cygwin1.dll and xfree

Re: Problem with cygwin1.dll and xfree

[Rasjid Wilcox]

On Tue, 9 Jul 2002 5:26 am, Dr. Wayne Keen wrote:
[Post on cygwin-xfree@cygwin.com]
> I know I have run into problems a couple of times with programs that
> have windows installers that somehow like to assume that you don't
> already have Cygwin on your machine.
>
> The first time I installed Octave, it replaced my Cygwin with some
> minimal installation it needed to support itself.
>
> Something not as severe happended when I ran an Windows installation
> program for Ruby.
>
> Eventually....I learned to just go ahead and build things myself
> within Cygwin.

<rave>

The main reason I stopped distributing the original version of my Minimal 
Cygwin-XFree86 for XDMCP only install was my gradual (and slightly belated) 
understanding of this problem.  And it was only because of discussions on the 
cygwin-xfree mailing list that I discovered this problem at all.

Personally, I think the requirement for there to be only a *single* 
cygwin1.dll needs to be *far* more strongly emphasised on the Cygwin website, 
in somewhere prominent (like on http://www.cygwin.com/index.html).

As the porting of open-source software from Linux/Unix to Windows becomes more 
common, unless things change this problem is only going to get worse.

The problem here is that many developers are going to want to distribute their 
program Windows ports via a Windows installer, not via Setup.exe.  And they 
are going to want their program to install as transparently as possible, so 
they are going to provide their own copy of the cygwin1.dll on the assumption 
that the user probably wont already have one.  This is generally true 
currently, but will become less true as time goes by.

I know that the Windows port of MySQL relies on the cygwin1.dll.  And in my 
wanderings I have seen several others (Ruby and Octave are mentioned above).  
It is no good if each program puts the cygwin1.dll in it own directory, since 
if two of the programs are running at the same time there may be problems.  
It is even worse if they all try and put it in system directory, since then 
who knows what version you will end up with.  And regardless of what happens, 
if the user either has or later installs Cygwin via Setup.exe there will be 
problems.

The only long term solution that I can think of is to make it possible 
(perhaps it already is) for the Windows installer to use an automated version 
of Setup.exe, that without any interaction from the user (unless absolutely 
necessary) will install or update (if required) the cygwin1.dll in a 
Setup.exe compatible way.

That way, if I install program A which depends on the cygwin1.dll, and then 
install program B (which has an older version of cygwin1.dll) it just leaves 
the newer version there.  If I then install program C which requires a newer 
version, the dll is then updated by the automated setup.exe.  If I then 
install Cygwin via Setup.exe, it just notices that I already have the 
cygwin1.dll and only updates it if necessary.

I think that basically what would be required would be to enable Setup.exe to 
be controlled by a config file (similar to a RedHat kickstart file), and have 
its GUI not displayed unless there was a problem and user interaction was 
required.

The other thing required is education.  Existing projects that use the 
cygwin1.dll need to be informed of the issue and encouraged (gently) to help 
do something about it.  And the information about the conflicting dll problem 
needs to be much more 'in the face' of potential cygwin1.dll users.

No doubt, ideally all cygwin based programs should be installed via Setup.exe, 
and then the problem goes away.  Realistically, that is not going to happen.  
'Ordinary' Windows users (as opposed to cygwin users) like Windows 
installers.  And when programs that use the cygwin1.dll start crashing 
randomly due to multiple cygwin1.dll copies, Joe Windows User will simply see 
an open source program failing to work, and decide that he will stay with 
closed source programs after all.  That is what concerns me the most.

Anyway, that is my 2 cents on the issue.  Perhaps this has already been 
discussed in depth before and/or is already implemented or in the process of 
being implemented, and if so my apologies if I'm wasting bandwidth.  I'm not 
subscribed to the cygwin list, only cygwin-xfree.  I'm CC'ing the cygwin 
list, since I think it is fundamentally a cygwin issue, not an Cygwin-XFree 
issue, although of course it effects anything that depends on cygwin.

</rave>

> So, one message that probably should leak out is to avoid Windows
> binaries that mention anything about Cygwin.  :-)

I would be inclined to check anything that was developed on Unix/Linux first 
and then ported to Windows, even if they fail to mention Cygwin, and even if 
it is closed source.  But perhaps I'm just paranoid.  ;-)

Rasjid.



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

Re: Problem with cygwin1.dll and xfree

[Charles Wilson]

Rasjid Wilcox wrote:


> That way, if I install program A which depends on the cygwin1.dll, and then 
> install program B (which has an older version of cygwin1.dll) it just leaves 
> the newer version there.  If I then install program C which requires a newer 
> version, the dll is then updated by the automated setup.exe.  If I then 
> install Cygwin via Setup.exe, it just notices that I already have the 
> cygwin1.dll and only updates it if necessary.
> 
> I think that basically what would be required would be to enable Setup.exe to 
> be controlled by a config file (similar to a RedHat kickstart file), and have 
> its GUI not displayed unless there was a problem and user interaction was 
> required.
> 
>


This is a good idea -- and the skeleton is already there.  What you need is
   1) first, command-line options that can completely control setup's 
behavior from start to finish.  Robert wrote and entirely separate 
GPL'ed option handler in OO C++ (all existing getopt/popt 
implementations are C, or C-dressed-up-as-C++).  There are even a few 
commandline options already implemented.  It just needs fleshing out

   2) Then, add the ability to read all of those options from a config 
file, including pkgs-to-install.  (This may actually already exist as 
part of Roberts GetOpt++ project)

So, help out with #1 above. <g>

--Chuck





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

Re: Problem with cygwin1.dll and xfree

[Charles Wilson]

Rasjid Wilcox wrote:


> That way, if I install program A which depends on the cygwin1.dll, and then 
> install program B (which has an older version of cygwin1.dll) it just leaves 
> the newer version there.  If I then install program C which requires a newer 
> version, the dll is then updated by the automated setup.exe.  If I then 
> install Cygwin via Setup.exe, it just notices that I already have the 
> cygwin1.dll and only updates it if necessary.
> 
> I think that basically what would be required would be to enable Setup.exe to 
> be controlled by a config file (similar to a RedHat kickstart file), and have 
> its GUI not displayed unless there was a problem and user interaction was 
> required.
> 
>


This is a good idea -- and the skeleton is already there.  What you need is
   1) first, command-line options that can completely control setup's 
behavior from start to finish.  Robert wrote and entirely separate 
GPL'ed option handler in OO C++ (all existing getopt/popt 
implementations are C, or C-dressed-up-as-C++).  There are even a few 
commandline options already implemented.  It just needs fleshing out

   2) Then, add the ability to read all of those options from a config 
file, including pkgs-to-install.  (This may actually already exist as 
part of Roberts GetOpt++ project)

So, help out with #1 above. <g>

--Chuck




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

Re: Problem with cygwin1.dll and xfree

[Robert Collins]

"Charles Wilson" <cwilson@ece.gatech.edu> wrote in message
news:3D2B092F.1030606@ece.gatech.edu...

> > I think that basically what would be required would be to enable
Setup.exe to
> > be controlled by a config file (similar to a RedHat kickstart file), and
have
> > its GUI not displayed unless there was a problem and user interaction
was
> > required.
..
> This is a good idea -- and the skeleton is already there.  What you need
is
>    1) first, command-line options that can completely control setup's
> behavior from start to finish.  Robert wrote and entirely separate
> GPL'ed option handler in OO C++ (all existing getopt/popt
> implementations are C, or C-dressed-up-as-C++).  There are even a few
> commandline options already implemented.  It just needs fleshing out

Yup. And the majority are trivial to add. The list-of-packages-to-install
collection is the (slightly) hard one as GetOpt++ has no 'native' interface
for that at the moment. However I've implemented such a collection twice now
using GetOpt++ for other projects, and am about ready to provide a generic
interface in GetOpt++.

>    2) Then, add the ability to read all of those options from a config
> file, including pkgs-to-install.  (This may actually already exist as
> part of Roberts GetOpt++ project)

It's not a deliberate inclusion, but consider that a command collection
takes argc, argv arguments. Parse the file into strings, treating unquoted
spaces and line breaks as new strings. Place pointers to those cstrings in a
vector and it's all done.

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/