This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 21 Oct 2009 18:40:37 +0200
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4ADF3287.8080307@cwilson.fastmail.fm>
- Reply-to: cygwin-developers 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