Avoid collisions between parallel installations of Cygwin

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Oct 21 19:47:00 GMT 2009

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


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?


> > 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list