From Newsgroup: comp.os.vms

Hello,

I begin the year - I hope successfull, happy, and with a good health for everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of
operation to itanium.

What has been done for x86? I know some applications using this sort of libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

G|-rard Calliet
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/13/2026 10:35 AM, gcalliet wrote:

I begin the year - I hope successfull, happy, and with a good health for everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of operation to itanium.

What has been done for x86? I know some applications using this sort of libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

There were VEST (VAX->Alpha) and AEST (Alpha->Itanium),
but no IEST (Itanium->x86-64).

Explicit VSI decision I believe.

But it is not clear to me what you need.

Many years ago, but as I remember it then if you VEST'ed
FOOBAR.EXE then you needed a VEST'ed RTL's, but if you
compiled and linked FOOBAR then you used the normal RTL's.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-01-13, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 1/13/2026 10:35 AM, gcalliet wrote:

I begin the year - I hope successfull, happy, and with a good health for
everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of
library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of
operation to itanium.

What has been done for x86? I know some applications using this sort of
libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

There were VEST (VAX->Alpha) and AEST (Alpha->Itanium),
but no IEST (Itanium->x86-64).

Explicit VSI decision I believe.

But it is not clear to me what you need.

Many years ago, but as I remember it then if you VEST'ed
FOOBAR.EXE then you needed a VEST'ed RTL's, but if you
compiled and linked FOOBAR then you used the normal RTL's.

Indeed. I wonder why Gerard cannot just recompile the application
as normal.

Missing source code ?

Missing Compiler/tools ?

Is this some Ada code he's trying to get working on x86-84 ?

Unless I am mistaken, Arne is correct and this approach stops at Itanium
and cannot be carried forward to x86-64.

Simon.

PS: It took me a minute to realise why he was talking about pictures. :-)
He's clearly taken the french word for "image" and translated it to the
english word "picture". That usually works, but not here... :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 13/01/2026 |a 20:40, Simon Clubley a |-crit-a:

On 2026-01-13, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 1/13/2026 10:35 AM, gcalliet wrote:

I begin the year - I hope successfull, happy, and with a good health for >>> everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of
library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of
operation to itanium.

What has been done for x86? I know some applications using this sort of
libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

There were VEST (VAX->Alpha) and AEST (Alpha->Itanium),
but no IEST (Itanium->x86-64).

Explicit VSI decision I believe.

But it is not clear to me what you need.

Many years ago, but as I remember it then if you VEST'ed
FOOBAR.EXE then you needed a VEST'ed RTL's, but if you
compiled and linked FOOBAR then you used the normal RTL's.

Indeed. I wonder why Gerard cannot just recompile the application
as normal.

Missing source code ?

Missing Compiler/tools ?

Is this some Ada code he's trying to get working on x86-84 ?

Unless I am mistaken, Arne is correct and this approach stops at Itanium
and cannot be carried forward to x86-64.

Simon.

PS: It took me a minute to realise why he was talking about pictures. :-) He's clearly taken the french word for "image" and translated it to the english word "picture". That usually works, but not here... :-)

Simon.

Thanks for the answers. I knew there are been Vest and Aest, and that
VSI said there will not be any "Iest".

These specific RTL were used in the context of rendering picture by
Motif+x11. You needed them in the link phase.

I don't remember why Digital/Compaq/HP created these Vested and Aested
RTL. However the source code of them has never been accessible for
users. I hope Digital/Compaq/HP had the sources but/and I don't know the specific issues which involved their choice of Vesting and Aesting them.

As a technical point, it is a very interesting subject.

But in the term of a port to x86, it could be a blocking point. I'm just
in the beginning of investigation on that. I'm not sure the applications
I have to analyze really use these libraries. I only remember that I
made a port to Itanium of similar applications ten or twenty years ago,
and it has been helpfull getting Aested libraries.

For both these interests, any information is wellcomed.

(And no, no link with Ada, Simon. I have a life beyond Ada :) ).

Thanks,

G|-rard Calliet
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/14/2026 7:25 AM, gcalliet wrote:

Le 13/01/2026 |a 20:40, Simon Clubley a |-crit-a:

On 2026-01-13, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 1/13/2026 10:35 AM, gcalliet wrote:

I begin the year - I hope successfull, happy, and with a good health
for
everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of >>>> library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of
operation to itanium.

What has been done for x86? I know some applications using this sort of >>>> libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

There were VEST (VAX->Alpha) and AEST (Alpha->Itanium),
but no IEST (Itanium->x86-64).

Explicit VSI decision I believe.

But it is not clear to me what you need.

Many years ago, but as I remember it then if you VEST'ed
FOOBAR.EXE then you needed a VEST'ed RTL's, but if you
compiled and linked FOOBAR then you used the normal RTL's.

Indeed. I wonder why Gerard cannot just recompile the application
as normal.

Missing source code ?

Missing Compiler/tools ?

Is this some Ada code he's trying to get working on x86-84 ?

Unless I am mistaken, Arne is correct and this approach stops at Itanium
and cannot be carried forward to x86-64.

Thanks for the answers. I knew there are been Vest and Aest, and that
VSI said there will not be any "Iest".

These specific RTL were used in the context of rendering picture by Motif+x11. You needed them in the link phase.

I don't remember why Digital/Compaq/HP created these Vested and Aested
RTL. However the source code of them has never been accessible for
users. I hope Digital/Compaq/HP had the sources but/and I don't know the specific issues which involved their choice of Vesting and Aesting them.

As a technical point, it is a very interesting subject.

But in the term of a port to x86, it could be a blocking point. I'm just
in the beginning of investigation on that. I'm not sure the applications
I have to analyze really use these libraries. I only remember that I
made a port to Itanium of similar applications ten or twenty years ago,
and it has been helpfull getting Aested libraries.

Still puzzled.

You have a VAX with foobar.c that you compile
and link with vaxcrtl on VAX to produce
foobar.exe.

You copy foobar.exe to Alpha and VEST it. Due to some
incompatibility the new Alpha image is not satisfied
with decc$shr but require a vaxcrtl*tv*.exe.

If you had compiled foobar.c and linked it normally
on Alpha then decc$shr would have been enough.

If you move an Itanium foobar.exe to x86-64 then you
can't IEST it and you therefore do not have a need for
any *tv*.exe.

You have to compile and link normal.

Your Motif application should be able to link on
VMS x86-64 with what is there I think.

$ dir sys$share:decw$*.exe

Directory SYS$COMMON:[SYSLIB]

DECW$AILSHR.EXE;1 DECW$AILSHRR5.EXE;1 DECW$BKRSHR.EXE;1
DECW$BKRSHR12.EXE;1
DECW$D2DXLIBSHR.EXE;1 DECW$DWTLIBSHR.EXE;1 DECW$DXMLIBSHR.EXE;1 DECW$DXMLIBSHR12.EXE;1 DECW$ICELIB.EXE;1 DECW$ICELIB_PTHREAD.EXE;1
DECW$LBXUTIL.EXE;1
DECW$LCNLIBSHR.EXE;1 DECW$LOGINOUT.EXE;1
DECW$MAILSHR.EXE;1
DECW$MAILSHR12.EXE;1 DECW$MRMLIBSHR12.EXE;1 DECW$PRINTWGTSHR.EXE;1 DECW$SECURITY.EXE;1 DECW$SECURITY_VMS.EXE;1
DECW$SESSIONSHRP.EXE;1 DECW$SETSHODISSHR.EXE;1 DECW$SMSHR.EXE;1 DECW$TERMINALSHR.EXE;1
DECW$TERMINALSHR12.EXE;1
DECW$TRANSPORT_COMMON.EXE;1 DECW$TRANSPORT_DECNET.EXE;1 DECW$TRANSPORT_LAT.EXE;1 DECW$TRANSPORT_LOCAL.EXE;1 DECW$TRANSPORT_TCPIP.EXE;1 DECW$UILSHR.EXE;1
DECW$XAUSHR.EXE;1
DECW$XEXTLIBSHR.EXE;1 DECW$XLIBSHR.EXE;1
DECW$XMLIBSHR.EXE;1
DECW$XMLIBSHR12.EXE;1 DECW$XMULIBSHR.EXE;1 DECW$XMULIBSHRR5.EXE;1 DECW$XPORT_PTHREAD.EXE;1 DECW$XPORT_SERVICES.EXE;1 DECW$XTLIBSHRR5.EXE;1 DECW$XTRAPLIBSHR.EXE;1 DECW$XTRAPLIBSHRR5.EXE;1 DECW$XTSHR.EXE;1

What is missing?

Or to recap for x86-64:
* if you do not have the source or the compiler then you
are out of luck
* if you have source and compiler then just compile and
link - dropping anything *tv* from the link
* if you get link errors about missing stuff then start hunting
for those

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-01-14, gcalliet <gerard.calliet@pia-sofer.fr> wrote:

These specific RTL were used in the context of rendering picture by Motif+x11. You needed them in the link phase.

OK. There's a language barrier here and the above "rendering picture"
statement can be taken in one of two ways.

Are you talking about a program which uses these RTLs to draw a picture
onto the screen ? Or are you talking about creating a VMS executable image instead and the RTLs are needed to provide some other functionality to
the application ?

Before I can make further suggestions, I need to know exactly what functionality these RTLs provide. If it is really drawing a picture onto
the screen, then what is the exact picture format, as there could be some alternatives for you to choose from.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-01-14, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 1/14/2026 7:25 AM, gcalliet wrote:

Thanks for the answers. I knew there are been Vest and Aest, and that
VSI said there will not be any "Iest".

These specific RTL were used in the context of rendering picture by
Motif+x11. You needed them in the link phase.

I don't remember why Digital/Compaq/HP created these Vested and Aested
RTL. However the source code of them has never been accessible for
users. I hope Digital/Compaq/HP had the sources but/and I don't know the
specific issues which involved their choice of Vesting and Aesting them.

As a technical point, it is a very interesting subject.

But in the term of a port to x86, it could be a blocking point. I'm just
in the beginning of investigation on that. I'm not sure the applications
I have to analyze really use these libraries. I only remember that I
made a port to Itanium of similar applications ten or twenty years ago,
and it has been helpfull getting Aested libraries.

Still puzzled.

You have a VAX with foobar.c that you compile
and link with vaxcrtl on VAX to produce
foobar.exe.

You copy foobar.exe to Alpha and VEST it. Due to some
incompatibility the new Alpha image is not satisfied
with decc$shr but require a vaxcrtl*tv*.exe.

_If_ I read Gerard correctly, this is not the problem. The problem
_appears_ to be that DEC created some additional VAX-only RTL and so
far Gerard has been able to survive by translating this additional
VAX-only RTL to more recent architectures.

_If_ I understand correctly, then it appears there is no native version
of this additional RTL (whatever it is) available on x86-64.

Gerard needs to give us exact information about this RTL and the
functionality it provides so we can suggest alternatives.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/14/2026 8:26 AM, Simon Clubley wrote:

On 2026-01-14, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 1/14/2026 7:25 AM, gcalliet wrote:

Thanks for the answers. I knew there are been Vest and Aest, and that
VSI said there will not be any "Iest".

These specific RTL were used in the context of rendering picture by
Motif+x11. You needed them in the link phase.

I don't remember why Digital/Compaq/HP created these Vested and Aested
RTL. However the source code of them has never been accessible for
users. I hope Digital/Compaq/HP had the sources but/and I don't know the >>> specific issues which involved their choice of Vesting and Aesting them. >>>
As a technical point, it is a very interesting subject.

But in the term of a port to x86, it could be a blocking point. I'm just >>> in the beginning of investigation on that. I'm not sure the applications >>> I have to analyze really use these libraries. I only remember that I
made a port to Itanium of similar applications ten or twenty years ago,
and it has been helpfull getting Aested libraries.

Still puzzled.

You have a VAX with foobar.c that you compile
and link with vaxcrtl on VAX to produce
foobar.exe.

You copy foobar.exe to Alpha and VEST it. Due to some
incompatibility the new Alpha image is not satisfied
with decc$shr but require a vaxcrtl*tv*.exe.

_If_ I read Gerard correctly, this is not the problem. The problem
_appears_ to be that DEC created some additional VAX-only RTL and so
far Gerard has been able to survive by translating this additional
VAX-only RTL to more recent architectures.

_If_ I understand correctly, then it appears there is no native version
of this additional RTL (whatever it is) available on x86-64.

Gerard needs to give us exact information about this RTL and the functionality it provides so we can suggest alternatives.

Possible.

But the shareable images given in the first post was
VAXCRTL in normal and G-floating edition.

And as a starting point I would assume that everything
in there is in DECC$SHR.

Maybe there is a VAXC$FOOBAR that is not in DECC$SHR,
but then we need more info.

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 1/14/26 7:26 AM, Simon Clubley wrote:

_If_ I understand correctly, then it appears there is no native version
of this additional RTL (whatever it is) available on x86-64.

I think in the days when one could not rely on a CRTL being shipped with
the OS, there were mechanisms to statically link one in so you could
distribute your application. It also probably made it possible to, for example, build on v5.x and deploy to a mix of v4.x and v5.x systems, or
mix VAX C and DEC C modules. This is a vague memory of a mechanism I
never used myself, so this may not be quite right, but something like
that is the origin of the RTLs Gerard is talking about.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/14/26 15:03, Craig A. Berry wrote:

I think in the days when one could not rely on a CRTL being shipped with
the OS, there were mechanisms to statically link one in so you could distribute your application.-a It also probably made it possible to, for example, build on v5.x and deploy to a mix of v4.x and v5.x systems, or
mix VAX C and DEC C modules.-a This is a vague memory of a mechanism I
never used myself, so this may not be quite right, but something like
that is the origin of the RTLs Gerard is talking about.

Obviously there is not enough information about how and for what these translated images are used. They are shareable images, not object
libraries. So it's not about statically linking.

On the other hand, if they are needed in a link operation on Alpha or
IA64, then you have a native object module. From that I conclude, that
some source code was compiled on Alpha/IA64. But then it should be
possible to avoid referencing the translated shareable images at all. At
least I think, it should be possible. But without more information ...

If you link on Alpha or IA64, you can create a map file, which tells you
what is referenced from these shareable images. There are also some
tools that show you what a shareable "Image Exports" and show you the "eXternal Procedure and Data list" of an image. But. analyze/image is
your friend and can help even if you do not have these tools.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 1/14/26 9:39 AM, hb0815 wrote:

On 1/14/26 15:03, Craig A. Berry wrote:

I think in the days when one could not rely on a CRTL being shipped with
the OS, there were mechanisms to statically link one in so you could
distribute your application.-a It also probably made it possible to, for
example, build on v5.x and deploy to a mix of v4.x and v5.x systems, or
mix VAX C and DEC C modules.-a This is a vague memory of a mechanism I
never used myself, so this may not be quite right, but something like
that is the origin of the RTLs Gerard is talking about.

Obviously there is not enough information about how and for what these translated images are used. They are shareable images, not object
libraries. So it's not about statically linking.

Yes, I had conflated a couple of different things. The current relevant
docs seem to be here:

<https://docs.vmssoftware.com/vsi-c-run-time-library-reference-manual-for-openvms-systems/#AXP_SHAREABLE_IMAGE_SEC>

which says, among other things, that the nonexistence of VAXCRTL*.EXE on
newer systems means:

"You must change any existing VAX C link procedures to eliminate any references to the VAXCRTL*.EXE images. An explicit reference to
DECC$SHR.EXE is unnecessary because IMAGELIB.OLB is searched
automatically by the linker (see the VSI OpenVMS Linker Utility Manual)."

If Gerard has object code that he can't recompile and it does not prefix
the CRTL function names, then he's got trouble. But we have no way of
knowing whether that's the problem, and without seeing the exact linker
errors after following the advice above, it's hard to even speculate.

Since we're talking about technical debt that should have been paid 25
years ago, some older docs may also shed light on how the various pieces
fit together:

<http://odl.sysworks.biz/disk$axpdocdec971/progtool/deccv56/5763profile0005.html#linking_multiple>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/15/26 00:12, Craig A. Berry wrote:

If Gerard has object code that he can't recompile and it does not prefix
the CRTL function names, then he's got trouble.-a But we have no way of knowing whether that's the problem, and without seeing the exact linker errors after following the advice above, it's hard to even speculate.

Yes, but speculating is very popular. :-)

If he has such (Alpha/IA64) object modules compiled for whatever reason
with /NOPREFIX then he may work around this with a wrapper that provides
the non-prefixed names and maps them to the appropriate names from
DECC$SHR. This usually works for RTL routines - assuming that the
routines are feature compatible. It's not that easy for non-literal RTL
data. But there is not much of such data in the VAXCRTL* images. Most of
the data symbol vector entries are literals. Such data can be defined in
the wrapper. All in all it should be possible. But the right approach is
to compile without /PREFIX that is to get the code compiling and working
in newer VMS environments.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-01-13 15:35:23 +0000, gcalliet said:

Hello,

I begin the year - I hope successfull, happy, and with a good health
for everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort of library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of operation to itanium.

What has been done for x86? I know some applications using this sort of libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

Gorard Calliet

I remember porting VAX C K&R-era code to DEC C back in the 1980s. More
than a little of that K&R C code my own. Fixing issues. It's
exceedingly rare to find VAX C code that isn't unstable at best, and
bggy, flaky, and crash-prone. Including my own.

The then-new DEC C / ANSI C diagnostics found all sorts of questionable
code and all too often found latent run-time errors. Which for some
developers and some projects meant workarounds were then used to avoid
fixing the informationals and the detected errors.

Here we are, some thirty years on, seemingly preserving that same usually-buggy C code, whether because of budgets or regulations or
whatever, or maybe because the source code was lost.

I'd be surprised "if rendering picture by Motif+x11" was still the case
for DECwindows and its apps on Alpha and later, but can fully believe
some unidentified Motif tools somewhere were translated and never
remediated.

If some VAX C code is linked against VAXCRTLG or its derivatives, run.
Run far away. That's G_Float code, and quite possibly VAX C code
written for MicroVAX I or VAXstation.

If y'all want to discuss which (or whose) DECwindows Motif apps are
involved, and whether the source code is available, have at...
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 13/01/2026 |a 16:46, Arne Vajh|+j a |-crit-a:

On 1/13/2026 10:35 AM, gcalliet wrote:

I begin the year - I hope successfull, happy, and with a good health
for everyone with a somehow prehistoric question.

Some applications, in general using x11, where linked with this sort
of library:
VAXCRTLG_D56_TV_AV.EXE;1
VAXCRTLG_D56_V73_TV_AV.EXE;1
VAXCRTL_D56_TV_AV.EXE;1
VAXCRTL_D56_V73_TV_AV.EXE;1

There are been vesting from VAX to alpha, and doing the same sort of
operation to itanium.

What has been done for x86? I know some applications using this sort
of libraries, and without them it's impossible to go ahead.

What has been done? What can be done?

All information wellcomed.

There were VEST (VAX->Alpha) and AEST (Alpha->Itanium),
but no IEST (Itanium->x86-64).

Explicit VSI decision I believe.

But it is not clear to me what you need.

Many years ago, but as I remember it then if you VEST'ed
FOOBAR.EXE then you needed a VEST'ed RTL's, but if you
compiled and linked FOOBAR then you used the normal RTL's.

Arne

Thanks for all the answers. I'm just beginning my analysis, and
reconstructing my memories.

The question is: why offering a translated RTL when it can be
recompiled? (There are not only _TV (for alpha) and _TV_AV for C RTL,
they existe also for other lnagages RTL).

Today, I think, one of the goals is about mathematical approximations,
which are not exactly the same with a compiled RTL, and for some
applications, and notably to calculate pictures, it could be a problem.

As the name says it, DECmigrate (VEST and after that AEST) is about facilitation of migration. Very helpfull when the program sources are
lost, but also for a long time if you need specific calculs.

It's just for now an hypothesis. I see these translated RTL mentioned in
the .opt for all the links. And also it is the G_FLoat which are used.

Perhaps in our C.O.V some people know more about the rationale for these translated RTL which had to survive until today.

G|-rard Calliet


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 15/01/2026 |a 18:40, Stephen Hoffman a |-crit-a:

I'd be surprised "if rendering picture by Motif+x11" was still the case
for DECwindows and its apps on Alpha and later, but can fully believe
some unidentified Motif tools somewhere were translated and never remediated.

If some VAX C code is linked against VAXCRTLG or its derivatives, run.
Run far away. That's G_Float code, and quite possibly VAX C code written
for MicroVAX I or VAXstation.

I just see your answer. Yes G_float code, and some parts of the pictures calculated via VAX C, before rending then in Motif.

What can be done in a trap? Very difficult to run ):

G|-rard Calliet
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/15/2026 1:23 PM, gcalliet wrote:

Le 13/01/2026 |a 16:46, Arne Vajh|+j a |-crit-a:
Thanks for all the answers. I'm just beginning my analysis, and reconstructing my memories.

The question is: why offering a translated RTL when it can be
recompiled? (There are not only _TV (for alpha) and _TV_AV for C RTL,
they existe also for other-a lnagages RTL).

The translated RTL's are there to support translated executables.

I don't know exactly why, but my guess is that translating executables
to native RTL's would be harder.

Let us take something like:

pushl #456
pushl #123
calls #1,vaxc$something

To use native RTL that would need to be translated to something like:

mov #456,r17
mov #123,r16
mov #1,r25
$CALL decc$something

But if there were a translated RTL using VAX calling convention,
then it could do something like:

subq sp,#8,sp
stl #456,(sp)
subq sp,#8,sp
stl #123,(sp)
subq sp,#8,sp
stl #1,(sp)
$CALL vaxc$something

which is way more 1:1 translation.

Just guessing.

Disclaimer: the above instructions are not tested, so please
consider them "pseudo-instructions".

It's just for now an hypothesis. I see these translated RTL mentioned in
the .opt for all the links. And also it is the G_FLoat which are used.

If you have the source, then then just try compile and link after
removing all those _TV from OPT files.

Perhaps in our C.O.V some people know more about the rationale for these translated RTL which had to survive until today.

Some people have been around for a long time.

:-)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/15/2026 1:29 PM, gcalliet wrote:

Le 15/01/2026 |a 18:40, Stephen Hoffman a |-crit-a:

If some VAX C code is linked against VAXCRTLG or its derivatives, run.
Run far away. That's G_Float code, and quite possibly VAX C code
written for MicroVAX I or VAXstation.

I just see your answer. Yes G_float code, and some parts of the pictures calculated via VAX C, before rending then in Motif.

What can be done in a trap? Very difficult to run ):

The entire F vs S and D vs G vs T thing can be messy.

If we are talking about linking with binaries then it is
essential that your float/double match the library.

But if you can build everything from scratch then most likely
there are no problems.

Yes - D, G and T have slightly different characteristics, but
if that difference matter then I will suggest follow Hoff's
advice: run!

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/15/26 19:23, gcalliet wrote:

The question is: why offering a translated RTL when it can be
recompiled? (There are not only _TV (for alpha) and _TV_AV for C RTL,
they existe also for other-a lnagages RTL).

That's not the question: the answer does not help to solve the problem.
In other words, if the VAX C RTLs, which are more than 30 years old, are
not compiled on Alpha and IA64, they will not be compiled for x86. And,
your code should not rely on such old RTLs.

I see these translated RTL mentioned in
the .opt for all the links. And also it is the G_FLoat which are used.

The question is: What in your object modules - that is in the
corresponding sources - requires something from these translated images?
The answer will help to remove the dependencies and to port the
application to x86.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 1/15/26 13:54, hb0815 wrote:

If he has such (Alpha/IA64) object modules compiled for whatever reason
with /NOPREFIX then he may work around this with a wrapper that provides
the non-prefixed names and maps them to the appropriate names from
DECC$SHR.

Just for fun, on Eisner - yes, you can try this at home ...

$ cre hello.c
f(){printf("world!\n");}
Exit
$ cc/noprefix/tie/warn=dis=implicitfunc hello
$ link hello
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, PRINTF
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
in psect $LINK$ offset %X00000030
in module HELLO file HB_SCRATCH:[HB]HELLO.OBJ;1
$
$ link/nonative_only hello,tt:/opt
sys$share:vaxcrtl_d56_tv/share
Exit
$ r hello
world!
$
$ shiml hello.exe
recursive SHareable IMage dependency List (Alpha), version 1.5
[ -> translated logical name ] required match: ID [ / actual match: ID ]
[ (self) - self reference; (dnf) - duplicate, not followed ]

VAXCRTL_D56_TV - MATLEQ: 4,3 / MATLEQ: 4,3
LIBRTL_TV -> LIBRTL_D56_TV - MATLEQ: 1,14 / MATLEQ: 1,14
LIBRTL - MATLEQ: 1,1 / MATLEQ: 1,1
SYS$PUBLIC_VECTORS
SYS$BASE_IMAGE
TIE$SHARE - MATLEQ: 2,0 / MATLEQ: 2,0
LIBOTS - MATLEQ: 1,3 / MATLEQ: 1,3
SYS$PUBLIC_VECTORS (dnf)
LIBRTL - MATLEQ: 1,1 (dnf)
DECC$SHR -> SYS$SHARE:DECC$SHR_EV56 - MATLEQ: 1,1 / MATLEQ: 1,1
LIBRTL - MATLEQ: 1,1 (dnf)
CMA$TIS_SHR - MATLEQ: 1,5 / MATLEQ: 1,5
CMA$TIS_SHR (self)
LIBRTL - MATLEQ: 1,1 (dnf)
LIBOTS - MATLEQ: 1,3 (dnf)
SYS$PUBLIC_VECTORS (dnf)
LIBOTS - MATLEQ: 1,3 (dnf)
DPML$SHR - MATLEQ: 1,0 / MATLEQ: 1,0
DPML$SHR (self)
LIBOTS - MATLEQ: 1,3 (dnf)
LIBRTL - MATLEQ: 1,1 (dnf)
CMA$TIS_SHR - MATLEQ: 1,5 (dnf)
SYS$PUBLIC_VECTORS (dnf)
SYS$PUBLIC_VECTORS (dnf)
SYS$BASE_IMAGE (dnf)
SYS$PUBLIC_VECTORS (dnf)
MTHRTL_TV -> MTHRTL_D53_TV - MATLEQ: 129,32780 / MATLEQ: 129,32780
LIBRTL_TV - MATLEQ: 1,14 (dnf)
TIE$SHARE - MATLEQ: 2,0 (dnf)
TIE$SHARE - MATLEQ: 2,0 (dnf)
SYS$PUBLIC_VECTORS (dnf)
$
$ xpd hello.exe
eXternal Procedure and Data list (Alpha), version 1.8
VAXCRTL_D56_TV:
offset 0x1f0 maps to VAXC$DPRINTF, type is procedure
$
$ pipe imgexp -v sys$share:VAXCRTL_D56_TV.exe |ggrep VAXC$DPRINTF
VAXC$DPRINTF, PRINTF, type is procedure, offset: 0x1f0, value: 0x304d4
$

and with a wrapper for printf ...

$ cc wrapper/noprefix
$ link/map/full/cross hello,wrapper
$ r hello
world!
$
$ search hello.map printf
DECC$GXPRINTF 000046E0-RX DECC$SHR_EV56 WRAPPER
PRINTF 00010050-R WRAPPER HELLO
000046E0 RX-DECC$GXPRINTF
00010050 R-PRINTF
$
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 16/01/2026 |a 15:02, hb0815 a |-crit-a:

On 1/15/26 19:23, gcalliet wrote:

The question is: why offering a translated RTL when it can be
recompiled? (There are not only _TV (for alpha) and _TV_AV for C RTL,
they existe also for other-a lnagages RTL).

That's not the question: the answer does not help to solve the problem.
In other words, if the VAX C RTLs, which are more than 30 years old, are
not compiled on Alpha and IA64, they will not be compiled for x86. And,
your code should not rely on such old RTLs.

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a I see these translated RTL mentioned
in the .opt for all the links. And also it is the G_FLoat which are used.

The question is: What in your object modules - that is in the
corresponding sources - requires something from these translated images?
The answer will help to remove the dependencies and to port the
application to x86.

I took more information about the application, and it seems the parts
using this translated VAXCRTL is very little. I think they used the
translated RTL because they first translated some image which ned it.

So I'll rewrite the relative small parts concerned.

I have been confused because on another project there are been a larger
use of it, because of the peculiar story of the 56 mantissa for Gfloat
on VAX. And in that other project a lot of pictures were calculated
using that. And because of the differences on approximations, your
pictures were all wrong.

However the very good thing about this research has been to remember the wonderfull project "Dec Migrate". I reread the article about it on
Digital Journal. I remember now how I have been enthousiastic about this
work


And now some dreams. I understand it could be impossible to have
something like that for Itanium. The architectures are so different.

But we know that the initial images (VAX, Alpha) are still present in
the translated images. So it could be possible to use them and translate
the translated images to x86. It is not so un-usefull, because it's
precisely these "historical" translated images which could be necessary
for some port to x86, potentially blocked by their absence.

It could be a very challenging project for some clever student to do the
job. Rediscovering the intelligence of the ancestors, reusing it for the future. It would require making "Dec Migrate" Open Source - yes, yes
it's just a dream -.

However, every information, tools, experiences, discutions about Dec
Migrate are wellcomed. At least for fun.

G|-rard Calliet


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2/4/2026 6:47 AM, gcalliet wrote:

I have been confused because on another project there are been a larger
use of it, because of the peculiar story of the 56 mantissa for Gfloat
on VAX. And in that other project a lot of pictures were calculated
using that. And because of the differences on approximations, your
pictures were all wrong.

G and T are pretty similar. Not identical, but I would say you
really had to be on the edge of randomness to get a difference
between them.

D and G are significantly different in range and precision. But
D died with VAX. Alpha "supported" D by loading and storing D
but doing calculations in G.

Arne

PS: It is D that is 55+1, G is 52+1.
--- Synchronet 3.21b-Linux NewsLink 1.2