Re: Logical device for openVMS implemented

Jouk,

>  Presently on OpenVMS GS_LIB_DEFAULT is defined as GS_LIB. On other
systems
> GS_LIB_DEFAULT contains a hard-codes search list. In principle for these
> other systems is coded within gs what is included in the VMS inteaction
with
> filesystem. By opening GS_LIB:<filename> all directories are searched.
This
> is much more effecient than the software emulation of gs.
> Another advantage is that the "resource" path's are not hard-coded in the
> executable. This should be a feature for other platforms too.
> This will ensure that the makefiles do not need any editing before running
> them.

I'm unclear why VMS implementation should use a different rule for building
and
running Ghostscript. I can't approve it. Please resolve with Raph, who is
responsible
for the architecture.

> No, but why use a software emulation when the OS does it more efficient.

To provide the platform independency of the documentation, code, build
process and behavior.

> >I understand "the program opening this file does  not know at all that it
is
> >a logical"
> >so that the operating system resolves a logical device automatically.
> true

Well, since this is true, I don't see a special need for the platform
dependent code.
I wrote :

> >But if it is true, your code appears excessive, and I'm not sure whether
it
> >is fully conforming.

> The problem is the dual syntax.

I was (and still is) unclear why do you need getenv to substitute logical
devices,
since the operating system does that.

>  However, if it is not well documented: Which file should contain this
info?

GS_LIB is mentioned in
doc\gs-vms.hlp
doc\Install.htm
doc\Lib.htm
doc\Make.htm
doc\Release.htm
doc\Use.htm

Probably you should patch all them and comments in makefiles
(I'm sorry, I had no time to check details).

Igor.