Re: Avoid collisions between parallel installations of Cygwin

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Tue, Oct 13, 2009 at 12:55:03AM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>>Ok, that wouldn't work for a FAT/FAT32 dll.
>
>What kind of "knowledgable" user would be using a FAT-formatted drive?
>;-)

Someone with a USB stick, unfortunately.

>> So we could allow a little
>> text file right next to cygwin1.dll with a syntax like:
>> 
>> .cygwinrc
>> allow-multiple: yes
>> ntsec: yes
>> tty: yes
>> crlf: yes
>> 
>> and that could be used *by knowledgeable users* to control their cygwin
>> behavior.  Or, we could even create a tool to place that information
>> into a "capabilities" section in the DLL itself.
>
>  Sounds like a job for the resource section to me - is there room in the
>versioninfo to put a capabilities string?

I was thinking that you could actually store some of the variables which
are controlled by the CYGWIN environment variable someplace in an easily
retrievable location in the Cygwin DLL.  Then you could have customized
cygwin DLLs.  You could even customize them via setup.

>That might be kinda neat.  (Might be a potential solution for the guy
>with the setup.exe problem as well: add an empty resource string to the
>build, which gets used instead of the command-line options if it's
>found in the versioninfo and isn't empty at runtime; that way people
>could hack it how they wanted it to be using any simple resource
>editor).

My email was a process of discovery.  I first thought that these could
be ASCII strings but then, I thought that for efficiency's sake it might
be better to have parsing happen just once in some kind of settings
program.  Then the cygwin DLL could continue to just query global
variables.

So, while it might be neat to put these in the resource section, isn't
that normally ASCII data?  Or is it binary too?  It's been too long
since I played with that.

cgf