[Info-vax] PC/VT Keyboarrd Mapping

[John Reagan]

On Sunday, June 26, 2016 at 4:31:41 PM UTC-4, John E. Malmberg wrote:
> On 6/26/2016 12:20 PM, John Reagan wrote:
> > On Sunday, June 26, 2016 at 12:20:56 PM UTC-4, Stephen Hoffman wrote:
> >> On 2016-06-26 15:39:57 +0000, John Reagan said:
> >>
> >>> It might have to do with some DECC$ logicals I set.
> >>
> >> Nuke those from orbit.  It's the only way to be sure those logical
> >> names won't continue to derail unrelated applications.
> >>
> >
> > We are doing some CRTL work right now (adding stdint.h, adding
> > missing  stuff to other headers, untangling the mess inside math.h,
>  > etc.). There are about 1/3rd of the logicals that I'm tempted to
>  > remove and pick a 'mandatory default'. I don't think anybody would
>  > know (but then again, those probably aren't the ones screwing people 
> over).
> >
> > And some, like this one being discussed, should have never seen the
> > light of day. A new feature was added to the CRTL to make access()
> > smarter. Most folks might even call it a bug fix (I would). Why make it
> > default to 'off'? Why give you the option to return to the old behavior?
> > We don't invent logical names in other areas to selectively un-do a bug
> > fix! At the minimum, I'll make sure the default for this one turns into
> > 'enabled' (which is what I assumed it would be all along).
> 
> The issue is probably that many times a buggy behavior got fixed in the 
> VMS CRTL, it broke some significant customer code that was depending on 
> that bug.
> 
> After a few rounds of that, a team can get gun shy at making a fixed 
> behavior a default.
> 
> There is a big mess there.  And the thing do do might be to freeze 
> decc$shr and create a new decc$vsi_shr that is expected to follow the C 
> standards and not use run-time feature settings.
> 
> The big transition issue for this is that there are a number of really 
> bad VMS CRTL behaviors that should be fixed if you are splitting off a 
> fixed copy.
> 
> * Some feature and compile time defines are to enable fixed behaviors 
> that default to broken.
> 
> * Some feature and compile time defines are to enable broken behaviors 
> that default to fixed.
> 
> * And there are some a few that are needed to change from Unix to VMS 
> behaviors that rarely need to be run-time behaviors, but are not 
> available as compile time behaviors.
> 
> Regards,
> -John
> wb8tyw at qsl.net_work

The trouble with two RTLs is that they will never be separate.  People will demand that you can fopen() with one RTL but fprintf() with the other.  Same for setenv()/getenv().  The two RTLs would have to have a private channel between each other.