[Info-vax] VMS process communication

[Ian Miller]

On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote:
> On 3/22/2023 7:18 AM, Ian Miller wrote: 
> > On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote: 
> >> On 3/20/2023 5:37 AM, Andreas Gruhl wrote: 
> >>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1: 
> >>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote: 
> >>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31 
> >>>>> UTC+1: 
> >>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote: 
> >>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html 
> >>>>>> 
> >>>>>> Updated to version 1.0 based on comments. 
> >>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change 
> >>>>> the compiler's treatment of pointers. Interpreting pointers 
> >>>>> as unsigned values has to be provided by the programmer. The 
> >>>>> qualifier only allows for P2 structures to be used as actual 
> >>>>> routine parameters via descriptor, which otherwise would be 
> >>>>> flagged as a compile time error. 
> >>>> So it does not change the treatment of pointers. 
> >>>> 
> >>>> It disables a compiler check.
> >>> That's correct. 
> >> 
> >> I have updated.
> > On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker 
> > but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is 
> > going to cause some issues when porting. For kernel mode code the 
> > recommendation is to change from locking specific parts of the code 
> > into the working set to locking the whole image as this works on I64 
> > and x86 VMS by calling LIB$LOCK_IMAGE.
> So is a function pointer always 64 bit? 
> 
> Arne

from the release notes "The LINKER creates small stub routines in 32-bit P0 space to allow the address of a routine to be stored in a 32-bit variable."