[Info-vax] OT: news from the trenches (re: Solaris)

[Stephen Hoffman]

On 2015-03-13 21:52:11 +0000, John Reagan said:

> Just as soon as 64-bit descriptors become the default, all the code 
> that handles descriptors today gets updated, all the languages do 
> 64-bit pointers, etc.  Makes the whole 'recompile and go' rather nasty 
> especially in a mixed-architecture cluster.

I am very well aware of the differences in the code.

I'd generally suggest that the 32-bit path be the ugly source code path 
and the ugly and complex build procedures, with the pragmas and the 
qualifiers that are necessary to allow the folks to "compile and go" 
their old code,  code with old ptrdiff_t and size_t dependencies, and 
preferably with diagnostics around any eventual deprecation when and if 
that's planned.   Need compatibility?  Need that 32-bit ptrdiff_t?  
Need strcpy or strcat or other unsafe calls?   Then set the #pragma 
WILL_BE_DEPRECATED and/or use the 
/FIRST_INCLUDE=your-pragma-deprecated-file-here.h qualifier, or require 
that the build-procedure DCL code be tweaked to use the 
/STANDARD=32_BIT_DEPRECATED or some such, or go set this forest of 
DECC$ logical names.

Put another way, don't clutter up the 64-bit code, and don't clutter up 
the 64-bit APIs for compatibility with the existing source code.   
Don't clutter up your future environment.  Make the "proper" folks work 
for more to keep the old crufty code.   Sure, they won't be happy.  
Don't make the folks that are doing your leading-edge work more, and 
don't require the new code be more gnarly and more twisty.

This is obviously a complete reversal of the longstanding practice, 
which is why I don't expect it to happen.

Why reverse this practice?  Hopefully, at least some of the folks with 
the old source code that run into this then start to learn where to 
update their code and how to update their code, and maybe to migrate to 
and use your newer and better APIs, and to 64-bit native.  This also to 
give VSI a path to eventually deprecate and remove the worst of the old 
code where that's appropriate; the worst of the old cruft and the 
support headaches, that you and the other engineers would really like 
to nuke and pave, but politically cannot.  Certainly stay compatible 
over the vast majority of the source code, but look for and select 
specific areas of the compiler — 64-bit support, ptrdiff_t and size_t, 
C11 support, whatever — and also specific areas of OpenVMS beyond the 
compilers — the way-too-fast password hash, or LDAP integration — where 
you can clean up the existing mess for future users, rather than 
preserving it all into a museum of hackery for retired source code.

Move the need for the cruft and the conditionals from the new code to 
the old code.

n.b: I am NOT suggestion deprecating everything, nor deprecating pieces 
and parts at all arbitrarily, nor requiring arbitrary source code 
changes.  Specific and targeted areas such as improved security, or 
that involve longstanding customer requests that have been blocked by 
upward-compatibility requirements, or in areas that are making it 
harder for VSI to move VMS forward.  This with documentation and a 
schedule and a migration plan for the existing customers, and 
preferably with compiler or run-time warnings logged where that's 
feasible.

TL;DR: Given a choice of a customer having to tweak some existing 
source code to get to the new environment or over to OpenVMS on x86-64 
(and maybe then updating it?), as compared with the effort and costs 
involved in porting elsewhere, don't set the VSI "bar" too low here — 
don't get too good at making OpenVMS source-compatible, while making 
the future source code more hideous and more complex and more arcane.  
Don't sell the future of OpenVMS OS and application development short.  
Don't make future work harder.


-- 
Pure Personal Opinion | HoffmanLabs LLC