Mail Archives: cygwin/2003/12/13/14:25:56
At 04:53 PM 12/12/2003, Hannu E K Nevalainen you wrote:
>> From: Larry Hall
>> Sent: Tuesday, December 09, 2003 10:19 PM
>
><SNIP - here and there>
>
>>David A Cobb:
>>> However, I'm
>>> wondering if we could make it easier? How about storing
>>> /HKLM/Cygnus Solutions/Cygwin/DLL_PATH="native:/path/to/cygwin1.dll and
>>> /HKLM/Cygnus
>>> Solutions/Cygwin/DLL_VERSION="1.2.3"
>>>
>>>And providing a simple C routine to return the critical information.
>>>I'm less sure about this piece -- most use things like
>>> InstallShield and I don't know how the scripting works there. Of
>>> course, if they simply looked at the mount point
>>> /HKLM/Cyg.../Cygwin/mounts_v2/bin, they could work it all out!!!
>
>> The prescribed approach is for third parties to not bundle cygwin1.dll
>> but instead point to cygwin.com and say "Install This First".
>
> Not good for users that are unfamiliar with cygwin, uninterested in cygwin
>itself or something else on that "line".
Sure. But it gets the job done and is the "easy" one for the dependent
third party package. It's up to the third party to decide if it's important
enough to their user base to provide something more automated. Either way,
this approach is *far* more maintainable and less troublesome for the user
in the long run.
>> An
>> alternative is a nice automated way in their installer to invoke the
>> Cygwin installer.
>
> Heh... that would IMO require setup.exe to be able to do batch runs. Not
>possible, unless changes has been done very recently.
I think both Chris, Rob, and others have pointed out gap in your setup
knowledge here. 'Nuff said.
>> If they do this, then there's no chance of having
>> more than 1 cygwin1.dll installed and no one needs to check for one.
>> Of course, doing the checking is not hard (FindFirstFile()/FindNextFile())
>> even if it's not necessary.
>
> I'm not keen of seeing this kinds of solutions being run on my computer as
>it is "low spec" to put it mildly.
>
>First of all; The "FindFirstFile()/FindNextFile()" thingie would probably
>run for ten minutes, or even more. I would be sitting there wondering what
>the heck was happening, and I would *not* be polite to the person who
>created this misnomer.
> Second; how is this "FindFirstFile()/FindNextFile()" thing supposed to
>handle the existense of more than one device? i.e:
>
>$ mount | grep -re '^.: .*'
>P: on /dev/dvd type system (binmode)
>Q: on /dev/zip type system (binmode)
>R: on /dev/dcdr type system (binmode)
>S: on /dev/dcds type system (binmode)
>T: on /dev/dcdt type system (binmode)
>U: on /dev/dcdu type system (binmode)
>c: on /cygdrive/c type system (binmode,noumount)
>d: on /cygdrive/d type system (binmode,noumount)
>e: on /cygdrive/e type system (binmode,noumount)
>f: on /cygdrive/f type system (binmode,noumount)
>g: on /cygdrive/g type system (binmode,noumount)
>h: on /cygdrive/h type system (binmode,noumount)
>i: on /cygdrive/i type system (binmode,noumount)
>w: on /cygdrive/w type system (binmode,noumount)
>
>is what I have available currently. Is that thing supposed to look through
>all of it? If I connect my Digicams there will be three more devices to scan
>through. What if it finds more than one cygwin1.dll, is it supposed to erase
>the second one then?
>
>Please, don't even mention this anymore, that's real bad programming IMO.
>Not very likely to end up in something viable.
Ah come on Hannu. I clearly mentioned this as an *option* and merely to
clarify that finding a particular file is supported by the O/S at an API level. I'm sure anyone that implemented this approach would use these APIs to do it the right way and wouldn't adopt your assumed "low spec" way. I
don't understand why you are trolling for flames on this topic.
>There got to be better, future-safe, flexible and extendable aproaches to
>this.
Right. They were discussed and I told you the recommended approach. It
solves the problem and works for others. If it doesn't for you, then
implement the solution you like that is better than the prescribed one
and propose it.
>A good *attempt* at this was presented above IMO.
I can only assume that David wasn't aware of the previous discussions on
this topic and the recommended solution. If not, I don't see the benefit
of providing third parties with yet another solution. It won't make our
job any easier and if they're not taking advantage of the recommended
solution, I can't believe that providing an alternative changes the situation
in any way. You're arguing for a solution on the wrong end of the problem
here IMO. Education/evangelization of the recommended approach is what's
necessary. If you're interested in helping to ease the problem of third
party installation clashes, I'd suggest thinking about what can be done to
"get the word out". That's my point.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -