decc$stat() variants on VMS.

[John E. Malmberg]

Since this is discussed on other threads.

From looking at stat.h, it looks like there are at least 7 different
variants of stat() as of VMS 8.4 as Compile time options.

The standard stat() call is probably closest to Unix. The main thing
about the others is that the dev_t returns a pointer to the VMS device
name for the file.

The standard stat returns a unique dev_t number for the device.
Unfortunately VMS does not provide the routines to parse the dev_t
number or translate it to an actual disk device.

Interestingly the non-standard stats() are the easiest way for a C
program to get the device name and fid of a file in order to use the
FID_TO_NAME service to simulate realpath().

The stat() call only returns the correct byte count for stream files.

For VMS text file formats, the only way to get the byte count seen by
reading the file is to actually read the file. VMS ports of Curl now do
this in most cases. While I have not seen a bug reported on this, I am
not certain port of Curl handles all cases of VMS text files everywhere.

For fixed block size files, like .EXE files, which are 512 byte files,
they use the number of blocks to calculate the byte count.

Unfortunately that is the wrong number because .EXE files can have
partial blocks in them.

This is why all the ports of GNU Tar that I know of access violate with
EXE files in the tarball.

The VMS Perl (5.10+) tar has the fix for that so it can deal with VMS
executables and objects properly.

Regards,
-John
wb8...@qsl.net_work

[VAXman-]

In article <nl0i81$qov$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:
>Since this is discussed on other threads.
>
> From looking at stat.h, it looks like there are at least 7 different
>variants of stat() as of VMS 8.4 as Compile time options.
>
>The standard stat() call is probably closest to Unix. The main thing
>about the others is that the dev_t returns a pointer to the VMS device
>name for the file.
>
>The standard stat returns a unique dev_t number for the device.
>Unfortunately VMS does not provide the routines to parse the dev_t
>number or translate it to an actual disk device.
>
>Interestingly the non-standard stats() are the easiest way for a C
>program to get the device name and fid of a file in order to use the
>FID_TO_NAME service to simulate realpath().
>
>The stat() call only returns the correct byte count for stream files.

The DA asks, "Which stream format?"

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[hb]

On 06/29/2016 03:25 PM, John E. Malmberg wrote:
> The stat() call only returns the correct byte count for stream files.

... and for rfm=udf, I assume.

> For fixed block size files, like .EXE files, which are 512 byte files,
> they use the number of blocks to calculate the byte count.
>
> Unfortunately that is the wrong number because .EXE files can have
> partial blocks in them.

... at the end. That's true for VAX/Alpha images, which can have
variable length records for symbols etc. at the end of the file. As far
as I remember I64 images are written in disk blocks, they don't have
partial blocks.

On the other hand, as far as I observed, in any file with rfm=fix the
last record can be partially filled.

[Michael Moroney]

On 06/29/2016 03:25 PM, John E. Malmberg wrote:

> The stat() call only returns the correct byte count for stream files.

> For fixed block size files, like .EXE files, which are 512 byte files,
> they use the number of blocks to calculate the byte count.
>
> Unfortunately that is the wrong number because .EXE files can have
> partial blocks in them.

I thought all VMS executable files, VAX, Alpha and Itanic, were fixed length
512 byte records, meaning all executables were always an exact multiple of
a disk block in size.

(doesn't mean all 512 bytes have to be used each time. I suspect any
HELLO_WORLD.EXE likely has a text psect where only a few bytes are used
but consumes 512 bytes [times page_size?] in the .exe)

[John Reagan]

On Wednesday, June 29, 2016 at 9:25:23 AM UTC-4, John E. Malmberg wrote:
> Since this is discussed on other threads.
>
> From looking at stat.h, it looks like there are at least 7 different
> variants of stat() as of VMS 8.4 as Compile time options.
>
> The standard stat() call is probably closest to Unix. The main thing
> about the others is that the dev_t returns a pointer to the VMS device
> name for the file.
>
> The standard stat returns a unique dev_t number for the device.
> Unfortunately VMS does not provide the routines to parse the dev_t
> number or translate it to an actual disk device.
>
> Interestingly the non-standard stats() are the easiest way for a C
> program to get the device name and fid of a file in order to use the
> FID_TO_NAME service to simulate realpath().

stat() is one of the big areas of ancient backwards compatibility that clogs
up the CRTL. Want me to just keep the standard version and toss the OpenVMS
specifics? I'd like to get to a single stat() if possible but as you noted
standard stat() exposes some of the UNIX-y file system featuers with dev_t
and friends. But I do want to cut some of the stat()s down even if I break
some folks. Anybody want to add their 2cents?

>
> The stat() call only returns the correct byte count for stream files.
>
> For VMS text file formats, the only way to get the byte count seen by
> reading the file is to actually read the file. VMS ports of Curl now do
> this in most cases. While I have not seen a bug reported on this, I am
> not certain port of Curl handles all cases of VMS text files everywhere.

I've avoided the lengthy discussion of what constitutes file size, meta-data vs real-data, etc. So what does "size" really mean? The number of bytes on the "disk"? (what about disk subsystems that might compress or use some other cute scheme) The number of bytes transferred into your memory buffer? The number of bytes that contain useful data vs memory padding? Even on UNIX, you can have mutliple utilities that process the same data. One program only cares about every 10th byte, another program only cares about every 2nd byte. How "big" is the file? Even for EXE files (ignore your case about the partial block at the end - and there are RMS fields to let you get the byte count in that last block) there may be massive alignment holes in between the segments. Does the file size of an ELF EXE file count those holes? Does it count all the extra ELF junk scattered around? In my opinion, the size of a file is the number of bytes it occupies on the storage medium (including RAM disk if so configured). The fact that it might compress the data (ie, eliminate explicit line terminators in favor of using VAR_CR) or use simulate some terminal prompting feature by using FTN format or whatever is just one of those platform specific features. So what if the number of bytes read back to the program doesn't quite add up to the number of blocks on the disk.

There. I feel better now.

[Stephen Hoffman]

On 2016-06-29 17:29:42 +0000, John Reagan said:

> stat() is one of the big areas of ancient backwards compatibility that
> clogs up the CRTL. Want me to just keep the standard version and toss
> the OpenVMS specifics? I'd like to get to a single stat() if possible
> but as you noted standard stat() exposes some of the UNIX-y file system
> featuers with dev_t and friends. But I do want to cut some of the
> stat()s down even if I break some folks. Anybody want to add their
> 2cents?

Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move
on. You're *never* going to be able to remediate a couple of decades'
accumulated cruft^Wcompatibility. *Never*. Not without breaking
something else dependent on the existing bugs^Wbehavior, and not
without further degrading the existing code into yet denser thickets of
cruft^Wconditional compilation.

Give folks something to move forward to, and to look forward to. When
you have to make a choice, make that trade-off facing forward. Not
backward. Preferably — with C — toward C11 and POSIX and better
compatibility. (Going toward OO APIs is probably a bridge too far,
though.)

> I've avoided the lengthy discussion of what constitutes file size,
> meta-data vs real-data, etc. So what does "size" really mean? The
> number of bytes on the "disk"? (what about disk subsystems that might
> compress or use some other cute scheme) The number of bytes
> transferred into your memory buffer? The number of bytes that contain
> useful data vs memory padding? Even on UNIX, you can have mutliple
> utilities that process the same data.

What I wrote out. What the OS then did with it — compression,
chunking it into sectors, sector- or file-level de-duplication,
whatever — is NMP. If I have to deal with padding, sectors, allocated
storage, de-dup'd size or whatever, then I'm writing OS code, and I
probably should use OS code — lib$rename or rename() or lib$delete or
remove() or whatever — to deal with that, or have a look at the blocks
allocated.

The following is a stat.h structure from the local box:
...
off_t st_size; /* file size, in bytes */
blkcnt_t st_blocks; /* blocks allocated for file */
blksize_t st_blksize; /* optimal blocksize for I/O */
...

> One program only cares about every 10th byte, another program only
> cares about every 2nd byte. How "big" is the file? Even for EXE files
> (ignore your case about the partial block at the end - and there are
> RMS fields to let you get the byte count in that last block) there may
> be massive alignment holes in between the segments.

Yeah, and IIRC CMS used to (maybe still does?) store data after the
EOF. That hosed a few tools.


--
Pure Personal Opinion | HoffmanLabs LLC

[John Reagan]

On Wednesday, June 29, 2016 at 3:50:26 PM UTC-4, Stephen Hoffman wrote:
> On 2016-06-29 17:29:42 +0000, John Reagan said:
>
> > stat() is one of the big areas of ancient backwards compatibility that
> > clogs up the CRTL. Want me to just keep the standard version and toss
> > the OpenVMS specifics? I'd like to get to a single stat() if possible
> > but as you noted standard stat() exposes some of the UNIX-y file system
> > featuers with dev_t and friends. But I do want to cut some of the
> > stat()s down even if I break some folks. Anybody want to add their
> > 2cents?
>
> Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move
> on. You're *never* going to be able to remediate a couple of decades'
> accumulated cruft^Wcompatibility. *Never*. Not without breaking
> something else dependent on the existing bugs^Wbehavior, and not
> without further degrading the existing code into yet denser thickets of
> cruft^Wconditional compilation.
>
> Give folks something to move forward to, and to look forward to. When
> you have to make a choice, make that trade-off facing forward. Not
> backward. Preferably — with C — toward C11 and POSIX and better
> compatibility. (Going toward OO APIs is probably a bridge too far,
> though.)
>

But it isn't just breaking a few programs, I think it is breaking most programs. As I mentioned the other day, you can get the current CRTL to be very UNIXy with DECC$UNIX_LEVEL set to 90. It "fixes" the basename() issue for example by flat-out disallowing VMS filespecs. Sound good, eh? Nope.

I do want to toss lots of stuff. We just have to be smart about it. And I have to still worry about users of __VMS_VER and __VMS_VER_OVERRIDE who want to have the current headers behave like they used to behave (I could solve that with dual sets of headers but that has its own set of nightmares).

Besides the headers, there is also the years of stuff in the compiler. I've pointed out /STANDARD=VAXC before as something people need to stop using. Other standard values like MS and MIA are on the chopping block as well. Several of the /ASSUME options don't have value. Who uses /ASSUME=NOTRIGRAPHS for example? /PRECISION? /EXTERN=VAXC? globalref/globaldef/globalvalue? Other /EXTERN models besides strict refdef? Heck, we've even talked about removing VAX floating support? Any takers on that one? Some of these features make the headers/RTL more complicated.

[Stephen Hoffman]

On 2016-06-29 20:20:13 +0000, John Reagan said:

> But it isn't just breaking a few programs, I think it is breaking most
> programs.

Yes. Leave those folks on the old RTL.

> As I mentioned the other day, you can get the current CRTL to be very
> UNIXy with DECC$UNIX_LEVEL set to 90. It "fixes" the basename() issue
> for example by flat-out disallowing VMS filespecs. Sound good, eh?
> Nope.

It'd seem a whole lot better if there were some easier-to-inline
filename conversion routines, and not the wonderfully-named and
artfully-arcane decc$to_vms and decc$from_vms calls.

> I do want to toss lots of stuff. We just have to be smart about it.
> And I have to still worry about users of __VMS_VER and
> __VMS_VER_OVERRIDE who want to have the current headers behave like
> they used to behave (I could solve that with dual sets of headers but
> that has its own set of nightmares).

Leave those folks on the old RTL. Maybe even hint at plans for its
eventual deprecation, just to light a fire under some few posteriors.
Preferably with a shorter expiry for existing code using VAX C RTL.

> Besides the headers, there is also the years of stuff in the compiler.
> I've pointed out /STANDARD=VAXC before as something people need to stop
> using. Other standard values like MS and MIA are on the chopping block
> as well. Several of the /ASSUME options don't have value. Who uses
> /ASSUME=NOTRIGRAPHS for example? /PRECISION? /EXTERN=VAXC?
> globalref/globaldef/globalvalue? Other /EXTERN models besides strict
> refdef? Heck, we've even talked about removing VAX floating support?
> Any takers on that one? Some of these features make the headers/RTL
> more complicated.

There are no easy choices here. Never have been.

There's never enough in the budget, either.

VSI can do what was done before. Or can try some new approaches.

VSI can continue with the strategy that has failed existing OpenVMS
users over the long term — yes, even failing those same users that
repeatedly requested and demanded this compatibility — or VSI can start
to re-think the core tenets, and start to haul those same customers
forward, and can make OpenVMS much more interesting to new customers.
So long as VSI changes stay sufficiently below the effort of an
application port off of OpenVMS — and deliver benefits, and can start
to deliver on the "OpenVMS is secure" message VSI marketing keeps
using, for instance — VSI has some room to work, particularly if the
new system and application code is fundamentally better and more
capable.

OpenVMS started out far closer to the forward edge of computing and
capabilities and user interfaces and consistency, and a better solution
for IBM network connections than even IBM itself, with well-integrated
features including security and networking, with greater ease of
programming, and a number of other positives. It's this legacy that
most folks here remember, too. Now? The future of OpenVMS itself —
and those same customers currently using it, as well as VSI — is
utterly subservient to folks that never want to change their code, even
for good and valid reasons. OpenVMS fundamentally trails other
platforms in many ways — C standard support being one of many such
areas — making it a poor choice for green-field development.

Keep doing what OpenVMS development has always done before, and we
_all_ know where that will end.

Where does this go? Your call.

[David Froble]

John Reagan wrote:

> stat() is one of the big areas of ancient backwards compatibility that clogs
> up the CRTL. Want me to just keep the standard version and toss the OpenVMS
> specifics?

I'm Ok with tossing C ....

:-)

[lawren...@gmail.com]

On Thursday, June 30, 2016 at 7:50:26 AM UTC+12, Stephen Hoffman wrote:
> Give folks something to move forward to, and to look forward to. When
> you have to make a choice, make that trade-off facing forward. Not
> backward. Preferably — with C — toward C11 and POSIX and better
> compatibility.

How about building a VMS API layer on top of a Linux kernel? That would give you immediate access to a whole lot of newer hardware, but it can also run on your existing Alpha and Itanium hardware if you want. It should probably take less work than maintaining your own entire OS.

Like WINE does the same thing for bringing Windows APIs to Linux.

What would we call it?

> (Going toward OO APIs is probably a bridge too far,
> though.)

That option would be available at little or no extra cost.

[Stephen Hoffman]

On 2016-06-29 23:16:33 +0000, lawren...@gmail.com said:

> On Thursday, June 30, 2016 at 7:50:26 AM UTC+12, Stephen Hoffman wrote:
>> Give folks something to move forward to, and to look forward to. When
>> you have to make a choice, make that trade-off facing forward. Not
>> backward. Preferably — with C — toward C11 and POSIX and better
>> compatibility.
>
> How about building a VMS API layer on top of a Linux kernel? That would

> giv0e you immediate access to a whole lot of newer hardware, but it can

> also run on your existing Alpha and Itanium hardware if you want. It
> should probably take less work than maintaining your own entire OS.
>
> Like WINE does the same thing for bringing Windows APIs to Linux.
>
> What would we call it?

Something similar to FreeVMS? http://www.freevms.net

An overhaul of OpenVMS more than a little way toward a wholesale rewrite?

Something that would require careful packaging to stay compliant with
the Linux licensing?

Might want to do some reading on a DEC advanced development project
from ~20 years ago, too: http://labs.hoffmanlabs.com/node/361

>> (Going toward OO APIs is probably a bridge too far, though.)
>
> That option would be available at little or no extra cost.

That "little or no extra cost" for an OO framework for just the central
parts of OpenVMS APIs would be a design and an implementation I'd be
interested in learning more about. Because any approach seems to
involve a whole lot of work rethinking and wrapping the existing APIs,
whether for the overall design or around lower-level details such as
memory management and garbage collection.

[lawren...@gmail.com]

On Thursday, June 30, 2016 at 11:58:07 AM UTC+12, Stephen Hoffman wrote:
> Something that would require careful packaging to stay compliant with
> the Linux licensing?

Only kernel modules would require the GPL. Userland code could use any licence you like. I don’t think WINE needs any kernel modules; why would VMS?

>>> (Going toward OO APIs is probably a bridge too far, though.)
>>
>> That option would be available at little or no extra cost.
>
> That "little or no extra cost" for an OO framework for just the central
> parts of OpenVMS APIs would be a design and an implementation I'd be
> interested in learning more about.

Ah. I was thinking more in terms of using the existing higher-level OO APIs available for userland libraries that already exist on Linux, rather than inventing new, VMS-specific ones.

[Craig A. Berry]

On 6/29/16 2:50 PM, Stephen Hoffman wrote:
> On 2016-06-29 17:29:42 +0000, John Reagan said:
>
>> stat() is one of the big areas of ancient backwards compatibility that
>> clogs up the CRTL. Want me to just keep the standard version and toss
>> the OpenVMS specifics? I'd like to get to a single stat() if possible
>> but as you noted standard stat() exposes some of the UNIX-y file
>> system featuers with dev_t and friends. But I do want to cut some of
>> the stat()s down even if I break some folks. Anybody want to add
>> their 2cents?
>
> Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move
> on. You're *never* going to be able to remediate a couple of decades'
> accumulated cruft^Wcompatibility. *Never*. Not without breaking
> something else dependent on the existing bugs^Wbehavior, and not without
> further degrading the existing code into yet denser thickets of
> cruft^Wconditional compilation.

Yeah, but you have to try. There are two ways to do it that are
definitely wrong. One is to add layer upon layer of backward
compatibility without ever deprecating and removing dead code so that
you end up with mountains of technical debt (more or less what we have
now). The other is to break with the past so abruptly that existing
users have no reason to upgrade or even stay with your product.

Ideally there would be regular releases with deprecation announcements
that have some teeth in them. For example, not just deprecating VAXC,
but announcing a specific lifetime for the /STANDARD=VAXC compatibility
qualifier on DECC (a lifetime that should have come and gone by now). I
don't think OpenVMS Engineering has ever had this sort of thing as part
of the core culture, and all the institutional dislocations and
disruptions of the last decade have certainly not helped. But continuous
refactoring and steady deprecations where necessary is how it's done
now. That does require copious automated tests so you know where you
stand when you scrape off the barnacles.

For the 7 flavors of stat(), try to reduce that to 2 or 3, then further
simplify in a subsequent release. Some things in the CRTL should be
fairly easy to jettison; I'm not sure why we need _DECC_V4_SOURCE now
when v4.x of the compiler hasn't been current for a couple of decades.

It's far from easy to maintain a predictable sliding window of new
features and deprecations, but it's the right way to do it. It's what
the competition does.

[David Froble]

I guess my question is, what would keep a customer that just absolutely cannot
change from continuing to run an old version of the language / compiler? If
that are that limited, I'd guess there is no development, and no changes anyway.

You do have to move, forward, or backward, cause the world is moving and you
cannot stand still.

[John Reagan]

That's my view at this point. You won't need _DECC_V4_SOURCE on x86 or
even Itanium since V4 compilers don't exist on those platforms.

[John Reagan]

If they are on Itanium today, they must be using some "recent" compiler (not V4.anything). And going to x86, the frontend is V7.4 vintage.

[Craig A. Berry]

On 6/30/16 1:07 AM, David Froble wrote:
> Craig A. Berry wrote:

>> For the 7 flavors of stat(), try to reduce that to 2 or 3, then further
>> simplify in a subsequent release. Some things in the CRTL should be
>> fairly easy to jettison; I'm not sure why we need _DECC_V4_SOURCE now
>> when v4.x of the compiler hasn't been current for a couple of decades.
>>
>> It's far from easy to maintain a predictable sliding window of new
>> features and deprecations, but it's the right way to do it. It's what
>> the competition does.
>>
>
> I guess my question is, what would keep a customer that just absolutely
> cannot change from continuing to run an old version of the language /
> compiler? If that are that limited, I'd guess there is no development,
> and no changes anyway.

People can and do run old versions of things, but if it's a library like
the CRTL, you really don't want to be running a version that isn't
getting patches anymore. Most security breaches use exploits that have
been patched a year or more in the past. That means lots of people don't
apply patches in a timely fashion. Running versions of things that
aren't getting patches at all anymore is just irresponsible.

[Stephen Hoffman]

On 2016-06-30 02:29:34 +0000, Craig A. Berry said:

> On 6/29/16 2:50 PM, Stephen Hoffman wrote:
>>
>> Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move
>> on. You're *never* going to be able to remediate a couple of decades'
>> accumulated cruft^Wcompatibility. *Never*. Not without breaking
>> something else dependent on the existing bugs^Wbehavior, and not
>> without further degrading the existing code into yet denser thickets of
>> cruft^Wconditional compilation.
>
> Yeah, but you have to try. There are two ways to do it that are
> definitely wrong. One is to add layer upon layer of backward
> compatibility without ever deprecating and removing dead code so that
> you end up with mountains of technical debt (more or less what we have
> now). The other is to break with the past so abruptly that existing
> users have no reason to upgrade or even stay with your product.

> ...

> It's far from easy to maintain a predictable sliding window of new
> features and deprecations, but it's the right way to do it. It's what
> the competition does.

Ayup. For most cases, I'd agree. If you're going to break
application compatibility — if you're going to wade into any specific
areas of OpenVMS and really start to fix things and to improve OpenVMS
— then change enough of the related pieces in that area to get where
and what you want to have. Don't dribble out the breakage in any
single area. Break it, then dribble out compatible updates and
compatible enhancements.

In this particular case, the accreted layers of compatibility have
solidified such that any incremental migration likely won't finish in
the next decade and probably won't finish in the next quarter-century,
and that's assuming that VSI adopts modern release cycles and
schedules. We'll all be playing Whac-A-Mole with the scale of changes
involved here.

"We're adopting {most of} {C11 / Fortran 2015 / COBOL 2014 / VSI BASIC
PLUS 64 / etc}. Here's why... Here's how you can, too..."

Implementing source code translation tools is likely too far outside of
what VSI has funding and staff for, unfortunately.

Leave the old code on the old RTLs and old standards around. Give'm a
decade to migrate, or some such.

Precedent: K&R C to ANSI C, FORTRAN to Fortran, etc. The old bits were
never expunged, though.

If VSI doesn't or won't or can't change OpenVMS fast enough to become
competitive, then it'll never get where VSI can change OpenVMS fast
enough to keep competitive. Which means new adoptions and new
partners and wholly new deployments will be limited at best. Which
means apps age out. Which ends badly for those folks that want and
need OpenVMS, and for VSI.

[John E. Malmberg]

On 6/29/2016 8:49 AM, VAX...@SendSpamHere.ORG wrote:
> In article <nl0i81$qov$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:

>> The stat() call only returns the correct byte count for stream files.
>
> The DA asks, "Which stream format?"

I would have to look at documentation for the exact list of stream
formats. And I forgot the undefined format that HB pointed out.

In general though with a stream format, the stream type is just telling
the application stop when reading a record. The number of bytes read by
a C program is the same.

Regards,
-John
wb8...@qsl.net_work

[John E. Malmberg]

That macro was not to support the V4 compilers it was to allow newer
compilers to support code that assumed the old behavior.

It looks like VSI should probably conduct a survey with their paying
customers, possibly bootcamp fodder about how best to clean up the CRTL.


It will probably depend on how much people want to go through and fix
their C source code that is dependent on broken behavior.

And the broken original decc$stat() is still used along side the fixed
decc$stat() code because of bugs/omissions in other parts of the CRTL.

The new standard stat() provides a dev_t number, but did not provide any
way to convert that dev_t number to a physical device, which means when
I need the physical device name, for a UNIX format path, the fastest way
to code it is to call the original decc$stat(), with the alternative
calling a bunch of name translations and then RMS services.

You are going to have to provide a way to run translated program, and
unless the solution is to cluster an emulator, you are going to need the
older CRTL.

The method with the least risk of breaking existing code is:

* Triage what routines are broken/obsolete and provide fixed
versions if needed.
* Note all routines that do not handle sockets and file
numbers the same are broken.
* Generally having non file structured devices opened BY RMS in
EXEC mode instead of SYS$ASSIGN in user mode is the wrong thing
to do. It is especially bad to do this with stdin/stdout as
it makes adding routines missing from the CRTL more clunky.
* Mailboxes used in pipes are one way. Set the IO modifier for
that direction on them.
... List could go on a bit.

* Make using them a non-default compile/link time option.

* Split the CRTL shared image up to segregate the entry points and
as much of the broken code.

As you mentioned, the old CRTL and its replacement need to talk to
each other. So the old DECC$SHR.exe will need to be linked against
the fixed decc$vsi_shr or what ever it is named, and have common
routines. That is a bit harder than starting with a clean slate,
but it would eventually allow you to freeze the old CRTL code
and features.

Programs needing ANSI C behavior would link only against the
new library.

You may also need two sets of header files, a cleaned up version that
works with the fixed CRTL and the old header files. SDL or equivalent
generated files can be more accurate than they currently are for new code.

If you do not split up the CRTL shared image, you will probably need to
maintain all the entry points in it forever.

Regards,
-John
wb8tyw@qsl_network

[Paul Sture]

On 2016-06-29, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> Give folks something to move forward to, and to look forward to.

This.

For many years I worked with third party software which would typically
require at least a relink for major upgrades. Often enough the third
party compiler(s) were key to getting access to new functionality (e.g.
new build toolchain & IDE capability), so we set things up for a full
recompile and relink.[1]

Yes, that sometimes broke things, but given an upgrade which contained
"desirable enough" goodies, the effort would be considered worthwhile.

Give folks a tangible reward for moving forwards and they will be keen
to do so. This is made easier if an upgrade brings tangible
deliverables which are easily understood by management.

[1] full recompile/link/testing capability made things like changing
application file layouts substantially easier too; i.e. the
benefits extended beyond an upgrade exercise

--
A sure cure for sea-sickness is to sit under a tree.
-- Spike Milligan