This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 21 Oct 2009 12:38:31 -0400
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4ADF3287.8080307@cwilson.fastmail.fm>
Charles Wilson wrote:
> Coinna wrote:
>> On Oct 21 05:59, Eric Blake wrote:
^^^^ oops. I should have sniped this header line. Corinna wrote all of
the stuff immedately below.
>> Nice. I created a simple shell script which can do the job. It even
>> allows to replace the cygwin1.dll in /bin on the fly. My script name of
>> choice is "enable-unique-object-names":
>>
>> $ enable-unique-object-names
>> Usage: enable-unique-object-names [show|yes|no] [path-to-cygwin-DLL]
>> $ enable-unique-object-names show
>> Default to /bin/cygwin1.dll
>> yes
>> $ enable-unique-object-names no
>> $ enable-unique-object-names show
>> Default to /bin/cygwin1.dll
>> no
>>
>> Do you think this is sufficient for now?
>
> Unfortunately, I don't.
I take it back. It's okay: BUT I think you should stick with your
original plan of using data in the following self-documenting struct:
struct resource_value
{
#if !defined(CHUCK)
char name[32];
char description[220];
unsigned long value;
#elif
char name[32];
char description[200];
unsigned long type; /* enum: ulong, etc */
union
{
unsigned long ul_value;
signed long sl_value;
double d_value; /* does this need to be 8-aligned? */
char[20] s_value;
} value;
#endif
};
(whether you use instead wchar_t* and L"" strings is up to you).
because of this:
> ...unless the magic ID strings themselves were also each part of the
> struct. In THAT case, I suppose the offsets between beginning of the
> string and the data would depend only on the length of the string, the
> packing options (-ms-struct?, pragma pack?) used during the compile, and
> the specific alignment requirements of the data -- none of which would
> change.
The only requirement would be that each name[32] must be globally
unique...but how can it be, if the reader code *in* cygwin must do
for (p = beginP; p->name != NULL; p++)
if (strcmp(p->name, "SUPPOSEDLY_UNIQUE_STR"))
set value based on p->value
??
Well, this way: require that actual name[] values stored on-disk begin
with "$$", but always do the comparisons this way:
if (strcmp(&(p->name[2]), "SUPPOSEDLY_UNIQUE_STR"))
(I know, I'm glossing over some error-checking for OOB memory access)
Then, the external tool can look for "$$SUPPOSEDLY_UNIQUE_STR" and not
get any false positives (I use '$' because they won't accidentally show
up in symbol names, if anybody ever does
SUPPOSEDLY_UNIQUE_STR(void)
{
}
(which isn't a bad idea for encapsulating access to the value, for use
from other locations in cygwin)
> This isn't a concern for the
> Windows on-disk registry which uses that scheme, but ours requires
> swapped-in RAM storage.
Meh. The original self-documenting proposal was going to do this anyway,
and there aren't really going to be a whole lot of these. One, to start
with.
> but is it wise, this
> "close" to the release, to send the XDR cat after the Mutable mouse
> after the .rsrc spider after the disable-unique-object-names fly?
No, it isn't. I vote for a modifier-script (or program, maybe even
still cygcheck), that "knows" about the offset WITHIN the (packed) struct of
struct resource_value
{
char name[32];
...
<important stuff>
}
from name[] to <important stuff>.
--
Chuck