Re: Avoid collisions between parallel installations of Cygwin

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Oct 21 12:10, Charles Wilson wrote:
> Coinna wrote:
> > Do you think this is sufficient for now?
> 
> Unfortunately, I don't.  First, because of alignment issues, it's almost
> a given that the offset from the start of the string to the data you
> want to change will be different in each build of the DLL, if it's just

Which would speak against using resources.

> >  In theory, if we use a specific
> > layout of the datastructure using unambiguous magic entry strings, there
> > wouldn't be a reason to use the .rsrc section at all.
> 
> ...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.

Indeed.  That was the sole idea.

> > The DLL could
> > simply read the values from a global datastructure in the .data section.
> > That would speed up the code in init_installation_root() a lot since it
> > won't need this FindResource/LoadResource/LockResource stuff.
> 
> Hmm.  Well, that IS a benefit -- can we quantify how much of one?

No.  But accessing a global int is almost certainly a lot faster than
calling three Win32 functions.

> Using a global data struct for configuration settings that a fixed at
> compile time, but theoretically mutable by an outside manipulation tool,
> just seems...wrong, to me somehow.  It seems that a resource section is
> exactly the Right Place for this -- even if we put a big blinking
> warning comment in the source code about "Don't Even Think About Using
> BeginUpdateResource/UpdateResource/EndUpdateResource with this data".

I think you're making this too complicated, really.  If I have to
tweak the DLL in any binary fashion, it does not the least matter
at which point in the binary blob the data is.  And the advantage of
using a global structure with defined, *simple* content should be quite
clear, compared to some resource layout which is not exactly under
our control.

> not that large, THEN perhaps the best choice is a combined approach:
>   1) the data is persistently stored in the .rsrc section
>   2) cygwin, on initial load in a particular process tree, retrieves the
> data and populates a global [*] struct. THAT struct is what is used by
> all the rest of the cygwin functions -- so there's only one
> FindResource/LoadResource/LockResource episode per process tree.

Huh?  That's the case anyway with my code, I thought that's clear from
the way the shared memory initilization works.  What suffers is only the
startup of the first process in a process tree, or, in other words,
running Cygwin appications from a non-Cygwin parent.

>   3) An external tool can be used to manipulate the .rsrc section in
> exactly the way you describe -- by brute force, as it were -- IF we take
> care of a few items (below).
> 
> [*] how do you access a "global" data struct if the names of global
> items are keyed by the value of that data struct?  Well, this need not

Sorry, but I really don't understand what's the problem.  This is the
global datastructure:

  struct cygwin_props_t
  {
    char magic_string[158];
    unsigned long version_number;
    unsigned long disable_key;
    [...]
  } cygwin_props = {
    "This is a magic string value which can be used by any external tool "
    "to find the values to change in the global Cygwin properties structure, "
    "really, I mean it",
    1,
    0,
    [...]
  };

It's pretty simple to find the location searchin for the magic string
and it's as simple to find the subsequent data.

> The big concern about brute force manipulation of binary (packed?) data
> structs is keeping track of the offsets, and the data sizes of each
> element

What's the problem with the above structure?

-- whether they are in the .rsrc section or anywhere else. Using
> explicit unique string keys bloats the structure unnecessarily if the
> number or kind of data stored grows. This isn't a concern for the
> Windows on-disk registry which uses that scheme, but ours requires
> swapped-in RAM storage.

The size of the DLL is > 1 Meg and growing as we add functionality.
What's the problem to add a couple of bytes

> I hesitate to suggest Yet Another Addition before 1.7.1 -- and cgf is
> gonna kill me [...]

Not only cgf.  I have absolutely no idea what XDR has to do with
a simple piece of DLL data.  Sledgehammer - nail?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat