Mail Archives: cygwin/1997/12/03/15:09:29
In article <199712021608 DOT JAA04416 AT chorus DOT dr DOT lucent DOT com>,
<marcus AT bighorn DOT dr DOT lucent DOT com> wrote:
>Jason Zions <jazz AT softway DOT com> wrote:
>>It strikes me that the best place for per-binary attributed like this
>>would be in the binary itself. I don't know how closely cygwin's exec()
>>looks at the program being exec'd; if it looks at the program header,
>>there should be a way to squirrel the attributes away there someplace.
>
>If there isn't anyplace in the file header that can be used to store this
>info away in that doesn't upset NT/W95, or if it is costly to open the object
>file whenever a program starts execution, perhaps it would be possible to
>provide some global variables in the crt0.o module for controlling various
>attributes. The tool to set the attributes would have to go through the
>name list to find the variables, then find the section to modify. Shouldn't
>be too bad, and the performance of the attribute setting program isn't
>critical anyway, but it would require that the file not be fully stripped.
Hmm. You're right. It should be possible to store an identifying string
in the binary for the options setting program to look for and then modify
the settings in the .exe.
I feel like I've been arguing out of both sides of my mouth, but the
only problem I see with this is for the people who want to set up various
symbolic links to the file and then set different registry options for
each link. If we modify the binary, then this wouldn't work.
Thanks for this suggestion.
>Other issues with using name:
>
>The full path name must be unambiguously stored with the attribute and expanded
>for execution. Otherwise, some peculiar things may not work correctly, such
>as invoking the program as "../bin/program", using a symbolic link to a
>directory "symlinktobin/program", etc. If the attributes are not consistently
>found whenever a program is run, the program will have inconsistent behaviour.
This shouldn't be an issue since, in the current scheme, only the MS-DOS
path spec retrieved from GetModuleFilename is used.
>If attributes are set for a program, then the program is moved to
>another location or given another name, it looses the attributes.
>Furthermore, if a new program is created (perhaps months later) with
>the same name and location, it will mysteriously gain the attributes.
>These problems do apply to symbolic links currently, so they aren't
>new, but they can be confusing particularly since they may have subtle
>effects on the execution of the program instead of a hard failure to
>follow a link.
Well put. You're right. I hate to set something up like this which
requires that you "remember" to remove the registry option when you
remove the file. Of course, you could have cygwin recognize when a
program has been deleted and delete it from the registry, I guess.
I think I like the binary modification idea better, though.
--
http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal
VMS=>UNIX Solutions Boston Business Computing the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -