Re: Binary COnfigurations

[hyc@hanauma.jpl.nasa.gov]

  ==============================
  Ofcourse some sort of standard configuration tool to modify the hardcoded
  paths (and other things as well) is very welcome. It enhances the flexibi-
  lity of the system. And I don't mean make+compiler+assembler+linker+...,
  but one simple tool, that doesn't need a lot of resources.
  ==============================
  
  It should be possible, with GNU anyway, to modify the executable by
  using the symbol-table.  It wouldn't work once the symbol table was
  stripped, but once configured on your personal system you could then
  strip the symbol table if you like.
  
  A simple utility to just list string variables and allow them to be
  edited, with perhaps a fancy GEM interface to make things easier.  By
  choosing standard identifier names one could quickly find the right
  variable to change.
  
  The problem here is that you would need one binary configuration program
  for GNU C, one for Lattice, one for DRI, or whatever other symbol-table
  formats there are, because I think they are all different.
  
No, when you're dealing with a TOS executable, the various symbol-table
formats really don't come into play. The GNU linker outputs DRI format
symbols, or optionally GST format, which is only a minor extension to
allow 22-character symbol names. No big deal.

Hm. You could construct an array of pointers, and store the actual
configuration strings somewhere else, like the end of the text or data
segments. The difficulty would be in correcting the segment size info in
the program header (easy) and correcting any relocation info (more tedious,
but also pretty easy...) Yes, a binary config tool could be done as described
here.

I'm still more inclined to an environment variable approach, since that really
is what they're for, and the Unix precedent already exists. (e.g., TMPDIR,
TERMCAP, etc...)

re: previous message, MiNT bug - perhaps the program you are trying to run,
which always crashes again after crashing the first time, is a shared-text
program that has over-written its text segment. Usually shared-text code is not
cached, i.e., after the last process executing it exits, the shared region is
released, but if the process is dying in some unusual manner, perhaps MiNT
doesn't get to mark the region as free. Then, the next time you try to execute
the program, you get the bad in-memory copy... You could verify this by first
checking to see if the problem program is a sharable file, and then, after it
has crashed once, touch the file (update its timestamp) and try to run it again.
MiNT *should* notice that the timestamp is different, and load the "new" file
instead of re-using the in-memory image. (I say should, it's been a while and
I haven't checked. At one time MiNT only checked the pathname, not the time
stamp of the file...)