[Info-vax] Announcing Ghostscript v9.05 for VMS

[Stephen Hoffman]

On 2012-08-08 17:27:13 +0000, hb said:

> On 08/08/12 17:54, Stephen Hoffman wrote:
>> Sure it is. The image headers and the image activator didn't have the
>> features that the CRTL folks needed, so the CRTL folks hacked together
>> something Really Ugly to get past the immediate requirements.
>> 
>> If the image headers and the activator are not the best spot for this,
>> then what's a better fix than an image header extension and the
>> associated sys$cli callbacks?
>> 
>> You can't patch a shared CRTL per application, and there's no good way
>> to go from the CRTL into the application to rummage around for settings
>> there.
> There is already decc$main, which is called from the __main wrapper, 
> which is generated by the compiler. It's my understanding that 
> decc$main (sets - based on logicals - and) evaluates the features. So 
> there is a call into the CRTL. Naively as I am I would have thought to 
> pass the address of a feature table to decc$main. The table itself can 
> be constructed by the compiler or can be part of a to-be-linked-with 
> object modul (or modules), similar to the init array of lib$initialize.

There isn't always a C main function around, and different hunks of C 
code can have different requirements.  Shareable images don't have a 
main, as you're well aware.  DECC$CRTL_INIT is used (and supposedly 
always called, but whether the programmer adds that into the code or 
not is an open question) when C shareable images are initialized.

Certainly storing this stuff into the image headers doesn't avoid the 
mess that is a per-image-component default settings (gag), and that's 
still a mess that the C environment might want to deal with.  And with 
a global "process-wide" C default setting, which shareable image 
provides the global settings?  AFAIK, there's no documented order for 
shareable image activations; which shareable image wins?

It's likely possible to stuff this into the C environment, yes, but 
then the C tools would have to scan the images to figure out where the 
footprint for the settings is, if you're externally managing the 
settings.   It's simply cleaner to add this data into the image 
headers, and expose this to the higher levels akin to the SET IMAGE 
tools and related.  (But then the whole of the image activation process 
is pretty ugly, too, and there are some ancient uglies lurking here.)

Yes...  It's non-modular, all the way down.

-- 
Pure Personal Opinion | HoffmanLabs LLC