This is the mail archive of the 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: Third-party products that include Cygwin

> 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 and say "Install This First".

 Not good for users that are unfamiliar with cygwin, uninterested in cygwin
itself or something else on that "line".

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

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

There got to be better, future-safe, flexible and extendable aproaches to
this. A good *attempt* at this was presented above IMO.

/Hannu E K Nevalainen, B.Sc. EE - 59+16.37'N, 17+12.60'E

** on a mailing list; please keep replies on that particular list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --

Unsubscribe info:
Problem reports:

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