[Info-vax] New CEO of VMS Software
John Dallman
jgd at cix.co.uk
Sat Jan 6 20:01:00 EST 2024
In article <uncd3t$ns66$6 at dont-email.me>, ldo at nz.invalid (Lawrence
D'Oliveiro) wrote:
> Yes, but remember, at the same time, they were able to bring out
> their own Unix OS for the same hardware, and make it fully 64-bit
> from the get-go.
That was a much more straightforward problem, with known solutions.
> Look at how the Linux kernel does it, on platforms (e.g. x86) where
> 32-bit code still matters: it is able to be fully 64-bit
> internally, yet offer both 32-bit and 64-bit APIs to userland.
That isn't the situation with VMS. An individual 64-bit process will
contain calls to APIs that take 64-bit addresses, as you would expect.
But it can also contain code to APIs that take 32-bit addresses, and
their data or buffers must be in the bottom 2GB of the process address
space. This is done with pointer qualifiers in C, like the "near" and
"far" pointers of 16-bit MS-DOS C compilers.
The 32-bit and 64-bit APIs have different names, because the multiplicity
of supported languages makes renaming according to the memory model
impractical
On Linux, a given process is entirely 32-bit, or entirely 64-bit.
The mixture within a process that exists on VMS is very unusual: there
may be other OSes that do it, although I don't know of any. The current
situation is a good example of why nobody should do this in any other OS.
John
More information about the Info-vax
mailing list