[Info-vax] OpenVMS Development Annoyances

[Arne Vajhøj]

On 4/21/2019 11:05 AM, seasoned_geek wrote:
> On Sunday, February 10, 2019 at 12:00:09 PM UTC-6, Arne Vajhøj wrote:
>> On 2/10/2019 12:30 PM, johnwallace4 at yahoo.co.uk wrote:
>>> Would there be more return on investment for some circumstances
>>> if (e.g.) relevant bits of something like Qt [0] were to be
>>> reborn on VSIVMS?
>>>
>>> Why Qt? No particular reason, except it's something which exists
>>> and is in use today (albeit maybe not on today's VSIVMS, but Qt
>>> was built with platform independence in mind, and it did even
>>> exist in a VMS flavour for a while).
>>>    
>>> E.g. for a preferences store maybe there's the Qsettings class
>>> which may or may not map on to what's being called "preferences"
>>> in this discussion.
>>>
>>> If not (e.g.) Qt, fair enough (it's total overkill just for
>>> settings), then what else might come close?
>>>
>>> And who would have to develop+support it for it to be widely
>>> acceptable in the (VMS?) marketplace?
>>
>> Having Qt on VMS would be great.
>>
>> But I don't think it would solve a general problem.
>>
>> Qt is very much its own.
>>
>> It is C++ and it a very specific way of C++.

> Well, speaking as someone who does a lot of Qt development,
> currently working on the touch screen interface for a new infusion pump I can tell
> you Qt is not just C++ anymore. They added a train wreck called QML
> which is basically a layer meshed together with a JavaScript engine.

QML is just declarative UI definition. Everybody wants that today.
Adobe Flex got MXML. .NET got XAML. Java got FXML. Etc..

> While I'm sure, for the correct amount of dollars, Qt company (I
 > think that is Digia's new name) would be willing to port, but it would
 > require a valid C++ compiler and rather current JavaScript. Since VMS
 > on x86-64 is going to be server only it would require a highly
 > restricted Qt core be ported and QtCreator to be given cross
 > compile support for VMS.

And will probably not happen. Too much work = too many dollars. :-(

> Adding insult to injury would be the required database driver
> modifications. Qt would gain no traction without support for RDB,
> Oracle and any other major database which is still running a
> production system even if the vendor abandoned support for VMS.
Qt SQL does support Oracle and MySQL/MariaDB. Adding support for RDB
should not be that hard to add.

I don't think there are many Sybase users left after almost 20 years.

> The one would have to build an entire QioDevice based set of classes
> for RMS indexed files because millions of those are still used in
> production today.

Calling RMS from C++ is not a problem. Obviously a super rich
encapsulation take more effort than a minimum encapsulation. But
it should not be a showstopper.

Arne