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 21:47:35 +0200
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4ADF4FBA.3020505@cwilson.fastmail.fm>
- Reply-to: cygwin-developers at cygwin dot com
On Oct 21 14:15, Charles Wilson wrote:
> To sum up: I think Corinna's approach is fine -- one big struct
> containing all the resources, and a single magic string, so long as
>
> (1) the script or binary tool that modifies the properties checks the
> version of the properties structure, and prints an error if doesn't
> match the specific version that the script knows about.
IMHO too complicated again. Think of some Windows structures. They
don't have a version number, just a sizeof member. This sizeof member
tells the OS which version of the struct the application uses in the OS
call. See, for instance
http://msdn.microsoft.com/en-us/library/ms686331%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms686329%28VS.85%29.aspx
where the sizeof member is called "cb".
Same here. Assume the struct looks like this:
struct props {
char magic[PROPS_MAGIG_LEN];
size_t cb;
ulong disable_key;
[...]
};
If the cb value is 4, we only support the disable_key value. The tool
script of the same age only supports the disable_key value either. So
no worry.
If the cb value is 8, we also support the foo_bar value. The old tool
script version still only allows to change the disable_key value. The
new tool supports to set the foo_bar value if the cb value in the DLL
is >= 8. Still no worry.
If the cb value is 12, ... you get the idea.
> (2) I don't think it's a good idea to encourage people to modify the
> cygwin DLL's properties while other cygwin apps are running. Hence,
> avoid the cmd / trick in the script.
Well, maybe. In that case the tool just creates a copy with changed
settings and asks the user to "stop all Cygwin processes and rename
/bin/cygwin1.dll.NEW to /bin/cygwni1.dll to activate the new setting".
However, I don't think there are lots of people out there who really use
this tool, let alone understand the setting.
> Newer tools would need to know which elements were safe to touch, in
> older DLLs.
It's really simple, IMHO. See above. There should never be a reason to
change the layout of the props. Simply add new stuff at the end and
change the cb member accordingly.
> > What's the problem with the above structure?
>
> IF you want to allow tools from one cygwin release to manipulate the
> properties of a different cygwin release, THEN:
> as long as the struct definition never changes, and we never add
> any new values or change the semantics of old values, nothing.
See above.
> But that's a pretty big if. And you can't completely solve it by
> including a whole bunch of
> char reserved[XXX]
> buffers.
See above.
> OTOH, do we really need to be THAT paranoid about protecting malicious
> users from themselves? So long as the stock script DOES contain the
> version check?
ACK.
> > Not only cgf. I have absolutely no idea what XDR has to do with
> > a simple piece of DLL data. Sledgehammer - nail?
>
> Right. We don't need it now; but it could be something to think about
> for later just in general (XDR is a fairly useful facility; I'd like to
> see it in newlib someday).
Nothing really keeps you from providing a newlib patch adding this
functionality ;)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat