This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]