[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

Phillip Helbig undress to reply helbig at asclothestro.multivax.de
Thu Mar 12 14:29:43 EDT 2020


In article <r4dre4$udc$1 at dont-email.me>, Stephen Hoffman
<seaohveh at hoffmanlabs.invalid> writes: 

> The 32-/64-bit addressing design was the right decision at the time.
> That the design worked as well as it's done, and allowed code 
> coexistence was and is valuable.
> But we're now ~25 years past Eagle/Theta/V7.0.
> Different times. Different tradeoffs. Different hardware. Different 
> expectations.
> If the existing API morass ever gets resolved, flat 64-bit would be preferred.
> Because the whole what-does-it-return and which-call-can-I-use and the 
> size_t/ptrdiff_t mess we ended up with from Eagle/Theta/V7.0 is, well, 
> a mess.
> Yes, that means dragging some apps forward.
> It also means an opportunity to age out the most problematic of the old APIs.
> And it means leaving the old stuff building and running in 32-bit and 
> 32-/64-bit legacy-compatibility mode and for the foreseeable future.
> But any replacement really needs to be further forward than flat 64-bit 
> using previous-millennium API designs and coding practices.
> Which gets into discussions of compiler and API overhauls and other 
> topics for new 64-bit code.
> As for itemlists and descriptors. Good ideas ~40 years ago. Now, not so much.
> All of which have been discussed before.

I was wondering how much effort the above would take, and whether VSI 
has the resources...

> And y'all at VSI have far larger projects.

...but if they have even bigger projects, then presumably they have 
enough resources for the revamp described above, though perhaps not for 
that AND the far larger products, at least not all at once.




More information about the Info-vax mailing list