[Info-vax] PC/VT Keyboarrd Mapping

[Stephen Hoffman]

On 2016-06-26 20:31:44 +0000, John E. Malmberg said:

> 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.

Ayup, and you're always and inevitably left with a decision in these 
cases.  Compatibility and piling on the technical debt and adding 
arcana and complexity?   Or forward progress for VSI and for customers 
maintaining their applications, and for folks writing new applications? 
  Tough call.    Choosing the former is what got OpenVMS where it is — 
in both senses of that.

> 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.

Wholesale abandonment is certainly viable for this case.  Mark it 
deprecated and — what should happen for these cases, but likely won't — 
announce a schedule for eventual removal.

> 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.

There's also no consistency in the naming; some names are negations, 
some are not.

> * 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.

SSIO, among others.


-- 
Pure Personal Opinion | HoffmanLabs LLC