On 6/8/2013 8:58 PM, David Froble wrote:
> Arne Vajhøj wrote:
>> On 6/8/2013 4:44 PM, John Wallace wrote:
>>> On Jun 8, 8:53 pm, "Craig A. Berry" <***@mac.com.invalid>
>>>> In article
>>>> John Wallace <***@gmail.com> wrote:
>>>>> On Jun 8, 6:37 pm, Simon Clubley <***@remove_me.eisner.decus.org-
>>>>> Earth.UFP> wrote:
>>>>> "AIUI, not all the source code in VMS is HP's to do with as they wish"
>>>>> Commonly repeated, was certainly true in the past (e.g. Display
>>>>> Postscript? CDE?), but last time I asked here for relevant current
>>>>> examples, none were forthcoming. In the case of those two examples,
>>>>> Display Postscript is now irrelevant and CDE is now GPL.
>>>> CDE may now be GPL, but the GPL version is not what's in VMS. Even
>>>> just updating all the code headers with new copyright and license
>>>> notices could be a fair chunk of work.
>>>> The SSH implementation is from a third party. I *think* it is the
>>>> folks at <http://www.ssh.com> but I'm not 100% sure about that. The
>>>> as-yet-mythical consortium or spin-off company or whatever could
>>>> probably buy the same rights HP has, or could approach Process Software
>>>> for inclusion of their SSH product (at a fair price, of course), or
>>>> could port OpenSSH.
>>>> The C++ compiler for Itanium has an Intel back-end, not GEM. I assume
>>>> HP paid money to Intel for it, or perhaps it was code-pro-quo in the
>>>> various agreements between HP and Intel involving Itanium. I have no
>>>> idea what transferring those rights to another party would involve.
>>>> There have been various device drivers with poison pills in them. I
>>>> remember having an LSI Logic SCSI HBA that was identical to the
>>>> Compaq-branded one (KZPCA?) except for the magic mumbo-jumbo in the
>>>> firmware identifying it as such. SRM recognized it, but VMS spat out
>>>> an unsupported warning and refused to use it. I was told money had
>>>> changed hands to gain porting assistance for the driver and the
>>>> restriction to officially-supported widgets was part of the agreement.
>>>> I've always assumed there were other drivers that had similar
>>>> non-HP-owned bits in them, but this is the only one I know about.
>>>> There are discussions already under way to replace the (now somewhat
>>>> dated) Sun/Oracle Java with OpenJDK. I think one of the open questions
>>>> is whether there is a suitable non-proprietary (or proprietary but
>>>> could be open-sourced) JIT compiler available for the architectures on
>>>> which VMS runs.
>>>> I doubt this is an exhaustive list but it's an indication of how much
>>>> work there would be just to return to status quo even if HP did release
>>>> everything it had the power to release.
>>> OK, let's look at these as a (good) start.
>>> GPL CDE not the same as in VMS: true. Does it matter given that (a)
>>> VMS is seen as a server OS (b) GPL CDE is presumably (!) relatively
>>> clean (eg 32bit safe AND 64bit safe, but possibly not yet VMS-ready).
>>> Probably not a showstopper, yes?
>>> SSH: fair comment. Options are available, effort (or finance) would
>>> indeed be required. How much? I have little idea, others round here
>>> might make better guesses.
>>> IA64 compiler: moving to an existing non-IA64 platform might perhaps
>>> be a bright idea at this point. How much work would be required to
>>> make its existing compiler work in the VMS environment with the VMS
>>> tools (compiler, debugger, etc)? Would VMS Debug be mandatory or would
>>> something layered on e.g. gdb be acceptable (either long term or
>>> Vendor-restricted drivers: moving to an(other) existing platform might
>>> simplify some aspects of that - the HW qual is already done. Drivers
>>> may still be an issue, especially if the vendor likes to provide their
>>> own drivers (hello Adaptec, how ya doing?).
>>> It surely wouldn't trivial, but the only showstopper I'm seeing so far
>>> is time and/or money, rather than lawyers, patents, licences, etc.
>>> It'd have to be a lot more commercially plausible than something like
>> There are certainly solutions.
>> But I think it is important to define what you mean by VMS!
>> Do you want DCL and all LIB$/SYS$ functions?
>> Do you want VMS internals, RMS, driver compatibility, same
>> compilers, same debugger etc.?
> Yes as appropriate, Yes, as required, big Yes, don't know
> Basically, you want to be able to take most applications and put them on
> the ported OS and they should compile and run.
I think that is require for it to be VMS.
But then one can forget about all the shortcuts of using GCC, GDB
mach kernel etc..