https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf

15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.

John

Den 2021-08-20 kl. 18:58, skrev John Dallman:
> https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
>
> 15 total fixes, if I understand the documentation correctly. Packaged as
> a PCSI kit, but cannot be removed once installed.
>
> John
>

It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.

On 8/20/2021 5:51 PM, Jan-Erik Söderholm wrote:
> Den 2021-08-20 kl. 18:58, skrev John Dallman:
>> https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
>>
>> 15 total fixes, if I understand the documentation correctly. Packaged as
>> a PCSI kit, but cannot be removed once installed.
>>
>> John
>>
>
> It doesn't say, but this is not the 9.1A kit announced for August?
> It doesn't look like that, more of an UPDATE-2 kit for V9.1.

This is NOT V9.1-A; that will be in late September.

--

-- Rob

Robert A. Brooks brought next idea :
> On 8/20/2021 5:51 PM, Jan-Erik Söderholm wrote:
>> Den 2021-08-20 kl. 18:58, skrev John Dallman:
>>> https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
>>>
>>> 15 total fixes, if I understand the documentation correctly. Packaged as
>>> a PCSI kit, but cannot be removed once installed.
>>>
>>> John
>>>
>>
>> It doesn't say, but this is not the 9.1A kit announced for August?
>> It doesn't look like that, more of an UPDATE-2 kit for V9.1.
>
> This is NOT V9.1-A; that will be in late September.

Is this the one that will be an ISO image instead of an appliance ?

--
Marc Van Dyck

On Saturday, August 21, 2021 at 6:34:54 AM UTC-4, Marc Van Dyck wrote:
> Robert A. Brooks brought next idea :
> > On 8/20/2021 5:51 PM, Jan-Erik Söderholm wrote:
> >> Den 2021-08-20 kl. 18:58, skrev John Dallman:
> >>> https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
> >>>
> >>> 15 total fixes, if I understand the documentation correctly. Packaged as
> >>> a PCSI kit, but cannot be removed once installed.
> >>>
> >>> John
> >>>
> >>
> >> It doesn't say, but this is not the 9.1A kit announced for August?
> >> It doesn't look like that, more of an UPDATE-2 kit for V9.1.
> >
> > This is NOT V9.1-A; that will be in late September.
> Is this the one that will be an ISO image instead of an appliance ?
>
> --
> Marc Van Dyck

V9.1 is a standard VMS ISO installation kit. Updates 1 and 2 are PCSI patch kits. V9.1-A will be an ISO installation kit. We stopped providing appliances as of the last V9.0 EAK.

Clair

On Saturday, August 21, 2021 at 8:18:48 PM UTC+2, Clair Grant wrote:
> On Saturday, August 21, 2021 at 6:34:54 AM UTC-4, Marc Van Dyck wrote:
> > Robert A. Brooks brought next idea :
> > > On 8/20/2021 5:51 PM, Jan-Erik Söderholm wrote:
> > >> Den 2021-08-20 kl. 18:58, skrev John Dallman:
> > >>> https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
> > >>>
> > >>> 15 total fixes, if I understand the documentation correctly. Packaged as
> > >>> a PCSI kit, but cannot be removed once installed.
> > >>>
> > >>> John
> > >>>
> > >>
> > >> It doesn't say, but this is not the 9.1A kit announced for August?
> > >> It doesn't look like that, more of an UPDATE-2 kit for V9.1.
> > >
> > > This is NOT V9.1-A; that will be in late September.
> > Is this the one that will be an ISO image instead of an appliance ?
> >
> > --
> > Marc Van Dyck
> V9.1 is a standard VMS ISO installation kit. Updates 1 and 2 are PCSI patch kits. V9.1-A will be an ISO installation kit. We stopped providing appliances as of the last V9.0 EAK.
>
> Clair

Is there any defined date when x86 version of VMS can be available to non-customer i.e hobbyist or similar?

In the meantime, can someone please provide a VMS x86 binary for analysis?

Regards, Peter

On 8/22/21 7:24 AM, ^P wrote:
> Is there any defined date when x86 version of VMS can be available to
> non-customer i.e hobbyist or similar?

All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
> In the meantime, can someone please provide a VMS x86 binary for
> analysis?

Not legally, no.

On Sunday, August 22, 2021 at 3:07:52 PM UTC+2, Craig A. Berry wrote:
> On 8/22/21 7:24 AM, ^P wrote:
> > Is there any defined date when x86 version of VMS can be available to
> > non-customer i.e hobbyist or similar?
> All of the field test docs refer only to "customers" so my unofficial
> guess would be that the v9.2 production release is the earliest that's
> likely to be available under the community license. You can read the
> roadmap yourself for when that's scheduled to happen.
> > In the meantime, can someone please provide a VMS x86 binary for
> > analysis?
> Not legally, no.

I already read the roadmap, nothing mentions the availability by "community license", why I asked openly

Thought so

Regards, Peter

On 22/8/21 10:37 pm, Craig A. Berry wrote:
>
> On 8/22/21 7:24 AM, ^P wrote:
>> Is there any defined date when x86 version of VMS can be available to
>> non-customer i.e hobbyist or similar?
>
> All of the field test docs refer only to "customers" so my unofficial
> guess would be that the v9.2 production release is the earliest that's
> likely to be available under the community license.  You can read the
> roadmap yourself for when that's scheduled to happen.
>> In the meantime, can someone please provide a VMS x86 binary for
>> analysis?
>
> Not legally, no.

Binaries are provided all the time, e.g. freeware ...

https://www.theberrymans.com

How is x86-64 any different?

https://wasd.vsm.com.au/wasd_tmp/

Usual disclaimers apply.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On Sunday, August 22, 2021 at 3:45:07 PM UTC+2, Mark Daniel wrote:
> On 22/8/21 10:37 pm, Craig A. Berry wrote:
> >
> > On 8/22/21 7:24 AM, ^P wrote:
> >> Is there any defined date when x86 version of VMS can be available to
> >> non-customer i.e hobbyist or similar?
> >
> > All of the field test docs refer only to "customers" so my unofficial
> > guess would be that the v9.2 production release is the earliest that's
> > likely to be available under the community license. You can read the
> > roadmap yourself for when that's scheduled to happen.
> >> In the meantime, can someone please provide a VMS x86 binary for
> >> analysis?
> >
> > Not legally, no.
> Binaries are provided all the time, e.g. freeware ...
>
> https://www.theberrymans.com
>
> How is x86-64 any different?
>
> https://wasd.vsm.com.au/wasd_tmp/
>
> Usual disclaimers apply.
>
> --
> Anyone, who using social-media, forms an opinion regarding anything
> other than the relative cuteness of this or that puppy-dog, needs
> seriously to examine their critical thinking.

Many thanks you for the links, I haven't seen any x86 freeware until now

> How is x86-64 any different?

This is the question I want to know the answer to.

If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.

Regards., Peter

On 8/22/21 8:45 AM, Mark Daniel wrote:
> On 22/8/21 10:37 pm, Craig A. Berry wrote:
>>
>> On 8/22/21 7:24 AM, ^P wrote:

>>> In the meantime, can someone please provide a VMS x86 binary for
>>> analysis?
>>
>> Not legally, no.
>
> Binaries are provided all the time, e.g. freeware ...
>
> https://www.theberrymans.com
>
> How is x86-64 any different?

He asked for a VMS binary, which I took to mean a binary kit for the
operating system. If he just means any piece of software compiled for
VMS x86-64, then of course that's up to whoever builds the binary.
What's available now wouldn't be terribly informative for analysis
purposes, though, since it would be built with a cross-compiler having
all optimizations turned off using an older version of LLVM that will be
superseded in the process of producing the native compilers.

On Sunday, August 22, 2021 at 10:12:42 AM UTC-4, ^P wrote:
> On Sunday, August 22, 2021 at 3:45:07 PM UTC+2, Mark Daniel wrote:
> > On 22/8/21 10:37 pm, Craig A. Berry wrote:
> > >
> > > On 8/22/21 7:24 AM, ^P wrote:
> > >> Is there any defined date when x86 version of VMS can be available to
> > >> non-customer i.e hobbyist or similar?
> > >
> > > All of the field test docs refer only to "customers" so my unofficial
> > > guess would be that the v9.2 production release is the earliest that's
> > > likely to be available under the community license. You can read the
> > > roadmap yourself for when that's scheduled to happen.
> > >> In the meantime, can someone please provide a VMS x86 binary for
> > >> analysis?
> > >
> > > Not legally, no.
> > Binaries are provided all the time, e.g. freeware ...
> >
> > https://www.theberrymans.com
> >
> > How is x86-64 any different?
> >
> > https://wasd.vsm.com.au/wasd_tmp/
> >
> > Usual disclaimers apply.
> >
> > --
> > Anyone, who using social-media, forms an opinion regarding anything
> > other than the relative cuteness of this or that puppy-dog, needs
> > seriously to examine their critical thinking.
> Many thanks you for the links, I haven't seen any x86 freeware until now
> > How is x86-64 any different?
> This is the question I want to know the answer to.
>
> If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.
>
> Regards., Peter
We use the base AMD64 calling convention

call->setCallingConv(CallingConv::X86_64_SysV);

In LLVM-speak.

On top of that, we use the AH register for an arg-count. Only AL is used in the base calling convention so our use of AH should be upward compatible.

Our memory model is a blend. It isn't exactly "short", "medium", or "large". Since we have static data and stacks in 32-bit space but code in 64-bit space, we access all static data through the GOT (which is more than what "medium" would suggest). And since routines in the same module might be in PSECTs that are far apart, we always go through the GOT for that as well. Same with literal pools (we move them into the code psect since our linker doesn't do SHT_MERGE).

But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).

I gave a presentation at an LLVM conference a few years back. https://www.youtube.com/watch?v=fiZwCLbJNSI

We only support PIC, use sse2.1 and higher for floating.

If you have questions, ask.

John Reagan wrote:
>
> But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).

Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
happens if you compile a fork implementation on linux and link it on
OpenVMS?

Jouk

On Monday, August 23, 2021 at 2:00:45 AM UTC+2, xyzz...@gmail.com wrote:
> On Sunday, August 22, 2021 at 10:12:42 AM UTC-4, ^P wrote:
> > On Sunday, August 22, 2021 at 3:45:07 PM UTC+2, Mark Daniel wrote:
> > > On 22/8/21 10:37 pm, Craig A. Berry wrote:
> > > >
> > > > On 8/22/21 7:24 AM, ^P wrote:
> > > >> Is there any defined date when x86 version of VMS can be available to
> > > >> non-customer i.e hobbyist or similar?
> > > >
> > > > All of the field test docs refer only to "customers" so my unofficial
> > > > guess would be that the v9.2 production release is the earliest that's
> > > > likely to be available under the community license. You can read the
> > > > roadmap yourself for when that's scheduled to happen.
> > > >> In the meantime, can someone please provide a VMS x86 binary for
> > > >> analysis?
> > > >
> > > > Not legally, no.
> > > Binaries are provided all the time, e.g. freeware ...
> > >
> > > https://www.theberrymans.com
> > >
> > > How is x86-64 any different?
> > >
> > > https://wasd.vsm.com.au/wasd_tmp/
> > >
> > > Usual disclaimers apply.
> > >
> > > --
> > > Anyone, who using social-media, forms an opinion regarding anything
> > > other than the relative cuteness of this or that puppy-dog, needs
> > > seriously to examine their critical thinking.
> > Many thanks you for the links, I haven't seen any x86 freeware until now
> > > How is x86-64 any different?
> > This is the question I want to know the answer to.
> >
> > If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.
> >
> > Regards., Peter
> We use the base AMD64 calling convention
>
> call->setCallingConv(CallingConv::X86_64_SysV);
>
> In LLVM-speak.
>
> On top of that, we use the AH register for an arg-count. Only AL is used in the base calling convention so our use of AH should be upward compatible..
>
> Our memory model is a blend. It isn't exactly "short", "medium", or "large". Since we have static data and stacks in 32-bit space but code in 64-bit space, we access all static data through the GOT (which is more than what "medium" would suggest). And since routines in the same module might be in PSECTs that are far apart, we always go through the GOT for that as well. Same with literal pools (we move them into the code psect since our linker doesn't do SHT_MERGE).
>
> But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
>
> I gave a presentation at an LLVM conference a few years back. https://www..youtube.com/watch?v=fiZwCLbJNSI
>
> We only support PIC, use sse2.1 and higher for floating.
>
> If you have questions, ask.

Thank you for a very detailed answer, I've found a few more executables to study until I can generate my own, I've ported a few things to VMS on VAX, Alpha and I64 earlier and plan to do so also for x86_64, reason for my interest, always study the result, to understand the content.
We've actually met, I visited Nashua in 2007 with Anders J who was at Bugcheck at the time, I think.
I did a week of crash dump analysis with Rob Eulenstein
What days it were!

On Monday, August 23, 2021 at 6:39:20 AM UTC-4, Joukj wrote:
> John Reagan wrote:
> >
> > But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
> Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
> happens if you compile a fork implementation on linux and link it on
> OpenVMS?
>
> Jouk
A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".

The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).

You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.

Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.

On Tuesday, August 24, 2021 at 1:51:10 PM UTC+2, xyzz...@gmail.com wrote:
> On Monday, August 23, 2021 at 6:39:20 AM UTC-4, Joukj wrote:
> > John Reagan wrote:
> > >
> > > But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
> > Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
> > happens if you compile a fork implementation on linux and link it on
> > OpenVMS?
> >
> > Jouk
> A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".
>
> The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).
>
> You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.
>
> Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute..

It is still default capitals?
Else using /name=as_is

On Tuesday, August 24, 2021 at 8:13:11 AM UTC-4, ^P wrote:
> On Tuesday, August 24, 2021 at 1:51:10 PM UTC+2, xyzz...@gmail.com wrote:
> > On Monday, August 23, 2021 at 6:39:20 AM UTC-4, Joukj wrote:
> > > John Reagan wrote:
> > > >
> > > > But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
> > > Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
> > > happens if you compile a fork implementation on linux and link it on
> > > OpenVMS?
> > >
> > > Jouk
> > A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".
> >
> > The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).
> >
> > You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.
> >
> > Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.
> It is still default capitals?
> Else using /name=as_is
Yes, you would use /names=as_is to keep "print" as "print".