Re: Logical device for openVMS implemented

Jouk,

> From: "Jacob (=Jouk) Jansen" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, September 10, 2003 2:20 PM
> Subject: Re: [gs-code-review] Logical device for openVMS implemented

>  Do you have a better idea how to reach the Decode/Unicode. file from the
> installation directory GS_LIB as it use to be?

Please look how GS_LIB_DEFAULT is defined and used in unix-gcc.mak and other
makefiles.
IMO VMS makefiles should do same.
I don't know whethet this idea is better or worse, but it gives an
uniform behavior on various platforms. He had hard discussions about it,
and I can't say that I'm completely happy with this decision.
However the decision has been made.

Particularly on Unix and Windows gs ever tries to open
gs/lib/Decoding/Unicode
and fails, then succeeds with gs/resource/Decoding/Unicode.
Ray had an idea to improve this with defining GS_RESOURCE in parallel to
GS_LIB.
My idea was to move most gs/lib/*.ps files to gs/resource/ProcSet/*,
and move gs/lib/gs_init.ps into gs/resource/gs_init ,
and remove gs/lib at all. IMO the latter is closer to Adobe implementations.
In any case, this problem is general for all platforms,
and a platform-dependent fix isn't a good way.

> >2. You coded :
> >
> >    logical = getenv( buffer );
> >
> >At this moment the buffer contains a file name prefix.
> >You consider it as a name for environment variable,
> >which (I guess) you assume to substitute the prefix.
> >This behavior is too different from one on other platforms.
> >Can you explain a reason why the GS behavior must be so different ?
> The reason is that on OpenVMS one can open a file
GS_LIB:[directory]file.name
> where GS_LIB is a logical (cf. unix environment) while the program opening
> this file does  not know at all that it is a logical.

The statements above look self-contradicting.
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.
I insufficiently know VMS to know ehether it is true, but it looks for me to
be highly probable.
But if it is true, your code appears excessive, and I'm not sure whether it
is fully conforming.

Contrary, there may exist a programming practice, in which ALL
applications should resolve logical devices by own means.
In this case your code may be conforming, but you should refer to this
practice
in comments and in GS documentation, because it is not usual in GS practice.




> However there may be 2 different
> syntaxes and the above statement on logical = getenv( buffer ) is to
> determine which syntax should be used.

This is also inobvious, and I can't guess what syntaxes do you refer,
and what is the logics of the recognition. Please add comments to code.

> >3. (2) requires a clear explanation and change to GS documentation.
> >Actually I strongly against such change.
> Nope. since this GS_LIB was always used on VMS. It can be defined as
> previously, but then the Resource/subdirs cannot be accessed.

If your logics of the GS_LIB interpretation differs from other platforms,
it must be reflected in GS documentation.

Igor.