On 2/20/23 6:11 AM, Dan Cross wrote:

> There is an ongoing effort to port LLVM to VMS to get native
> compiler support, but with the existing language front-ends in
> addition to clang etc, correct? Where is that work happening?

At VSI, obviously. There have been numerous public presentations about
what is being done and how it is being done. The head of the compiler
group chimes in here pretty frequently with updates and explanations. I
believe the clang++ port is in field test. The customer portal now has
a download of "VSI C X7.4-725" (a different compiler from the clang++
compiler). I forget exactly what the "X" stands for, but if it's not a
"V" in that position it's not a production-quality release. As far as I
know, this is the first release of a native compiler based on the
GEM-to-LLVM conversion. I don't think they could open source this one
if they wanted to because they don't own the intellectual property to
the front end.

> Is there an open source repository where an outside contributer
> can work _on that port_? If this is happening in the open, it
> does not appear to be in the LLVM repository.
> (for ref: https://groups.google.com/g/llvm-dev/c/MYfZW2DOU2I/m/q8oDU0UTAAAJ
> and https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf)

As has been said many times, there will be some changes to LLVM
submitted upstream eventually. Anyone who expected all the compiler
work to be done completely in the open hasn't been paying attention.
You can't contribute to the next version of Apple's XCode just because
it's based on LLVM and the VSI compilers likely won't be any different.
Would it be nice if there were one compiler example available in source
form, even just for a toy language, that people could use as a template
for producing there own LLVM-based compilers? Sure. I'd love to see
it. That's obviously not going to be VSI's highest priority, but it
could happen.

> Similarly with contributions to the operating system itself.
> ARM is gaining ground in the server space, and it seems that a
> VMS port to ARM is likely at some point, if VMS survives. How
> does an independent third-party contribute to that, beyond just
> asking VSI? As Arne said earlier, VMS needs things to be done,
> but what if those things require, or would be significantly
> aided, by open sourcing the OS or large parts of the
> infrastructure?

Many, many open source projects do not have enough contributors. This
usually only makes the news when some critical piece of infrastructure
such as ntp or OpenSSL has a vulnerability that gets noticed, but the
basic problem is ubiquitous in open source. Having the doors wide open
was completely ineffective at keeping those projects adequately
resourced. So it's hard to see how open sourcing VMS would magically
allow more OS development to get done.

Consider the case of Ada, which a very few people really, really want,
but no one can make a business case to VSI that it's worth their time to
do it. Most of the important pieces are already there in the GCC
toolchain, so interested parties could retrace the steps of ACT (who
also didn't think there was a business case to continue supporting Ada
on VMS) and produce an open source Ada compiler for VMS. There is no
waiting on VSI or anybody else. Anyone with the interest, the time, and
the skill can do it right now. Why haven't they?

> Without that native clang++ port, which they don't
> seem to be able to contribute to as prerequisite, the upside for
> the OSS folks to port to VMS just doesn't seem to be there.

The availability of clang++ looks like it's happening, if much later
than anyone wanted it to be. It remains to be seen whether there will
be sufficient pieces included that someone could port Rust or Swift or
GNAT-LLVM on top of it.

There are other things VSI can and should do (and in some cases is
already doing) to enable open source ports. I believe there is a cmake
port expected at some point, and there has been mention of updates to
GNV. There is ongoing work on the CRTL that needs to continue (someone
from VSI mentioned adding posix_spawn() not long ago).

> If open-sourcing VMS has been tried, then can anyone share the
> story? And note the context now: just because it didn't work
> before doesn't mean it can't be done now.

Search for "Clair Grant" and "open source" in the archives of this
newsgroup. I think he said "We can't open source it because we don't
own it." I believe he also said he'd tried to open source it more than
once and it wasn't going to happen.

So if you have sufficient millions burning a hole in your pocket, feel
free to approach HPE to obtain the intellectual property so you can then
give it away for free. I don't see the context now being much different
from what it was five or ten or twenty years ago. I'd be happy to see
it happen, but it doesn't seem very realistic and it's not a panacea for
the dwindling VMS ecosystem.

On 2/20/2023 9:35 AM, Craig A. Berry wrote:
> On 2/20/23 6:11 AM, Dan Cross wrote:
>> Similarly with contributions to the operating system itself.
>> ARM is gaining ground in the server space, and it seems that a
>> VMS port to ARM is likely at some point, if VMS survives.  How
>> does an independent third-party contribute to that, beyond just
>> asking VSI?  As Arne said earlier, VMS needs things to be done,
>> but what if those things require, or would be significantly
>> aided, by open sourcing the OS or large parts of the
>> infrastructure?
>
> Many, many open source projects do not have enough contributors.  This
> usually only makes the news when some critical piece of infrastructure
> such as ntp or OpenSSL has a vulnerability that gets noticed, but the
> basic problem is ubiquitous in open source.  Having the doors wide open
> was completely ineffective at keeping those projects adequately
> resourced.  So it's hard to see how open sourcing VMS would magically
> allow more OS development to get done.
>
> Consider the case of Ada, which a very few people really, really want,
> but no one can make a business case to VSI that it's worth their time to
> do it.  Most of the important pieces are already there in the GCC
> toolchain, so interested parties could retrace the steps of ACT (who
> also didn't think there was a business case to continue supporting Ada
> on VMS) and produce an open source Ada compiler for VMS.  There is no
> waiting on VSI or anybody else.  Anyone with the interest, the time, and
> the skill can do it right now.  Why haven't they?

Exactly.

I previously in this thread posted these two quotes which I think
are sort of relevant:

Benjamin Franklin - Well done is better than well said

John F Kennedy - Ask not what your country can do for you – ask what you
can do for your country

And that is really what it boils down to. The open source
world is not created by people:
- demanding closed source to be open sourced
- complaining that closed is not being open sourced
- demanding somebody else port some open source to ones favorite platform
- complaining that nobody port some open source to ones favorite platform

The open source world is created by people actually producing
open source software.

Linux has been mentioned numerous times in this thread.

Go back to 1991. Linus Torvalds had two options:
A) complain loudly about Minix not being open source (per
later definition) and try to push Tannenbaum to change
the license
B) create Linux

We know what he chose.

Arne

On 2/20/2023 6:17 AM, Dan Cross wrote:
> In article <tsui1g$hia4$6@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Oh? How do you figure? Please be specific. Or is that just
>>> idle speculation?
>>
>> Before open sourcing Solaris was one the worlds major OS'es.
>>
>> After open sourcing it was a niche OS.
>
> Correlation is not causation.

No. But you should read the lines following that line
to get the point.

>> That should prove that open sourcing did not solve its
>> problems.
>
> I never said that it did.

No.

But you want VSI to do the same as SUN.

>> Maybe it even made it worse.
>
> This is unsubstantiated nonsense.

The substantiation was in the following line, so you
should have read ahead.

>> Oracle decision to close
>> source it again indicate that Oracle believed so. Given
>> that it was their money, then they must be the expert.
>
> Oracle: famous for making great decisions.

If we limit "great decisions" to being "decisions maximizing profit",
then Oracle is doing way better than average.

Arne

On 2/20/2023 6:09 AM, Dan Cross wrote:
> In article <tsug6g$hia4$4@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/19/2023 4:35 PM, Dan Cross wrote:
>>> What's ironic is that the people making these decisions didn't
>>> quite understand the AT&T lawsuit, which was about _trade secret
>>> status_ of Unix, not copyright. AT&T was trying to say that it
>>> was the system interface that was the real intellectual property
>>> that was being violated, not the specific expression of that
>>> interface. This would have affected Linux, too, despite being
>>> an independent reimplementation.
>>
>> Do you use CharGPT to create this type of fiction?
>
> Wow, rude.
>
>> It was both copyright and trade secrets. Plus breach of contract
>> and trademark.
>>
>> From the judges ruling:
>>
>> https://law.justia.com/cases/federal/district-courts/FSupp/832/790/1428569/
>>
>> [snip]
>
> Tell me you weren't there without telling me that you weren't
> there.

I was not there.

But that does not change that the court document
proves that what you posted was pure fiction.

Arne

On 2/20/2023 6:28 AM, Dan Cross wrote:
> In article <tsuep3$hia4$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/19/2023 4:48 PM, Dan Cross wrote:
>>> In article <tst9dd$dhc4$1@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>>>> In article <tsrpoc$5qhq$2@dont-email.me>,
>>>>>> It is problematic to find people to maintain the ifdefs
>>>>>> and build scripts of for VMS in many open source projects.
>>>>>
>>>>> Have you ever stopped to wonder why that is, and how one might
>>>>> go about changing it?
>>>>
>>>> It is not obvious to me why VMS being open source should
>>>> make it more attractive to develop open source on VMS.
>>>
>>> It's prohibitively expensive to do so today. Should commercial
>>> vendors port to OpenVMS using the hobbyist program? How about
>>> open source vendors?
>>
>> ????
>>
>> Commercial vendors can use VSI's excellent ISV program.
>>
>> Open source developers can use either same ISV program
>> or hobbyist program.
>>
>> Minimum cost = zero.
>
> Too bad there are no native compilers for x86_64 yet,
> which means using a different platform, which comes back
> to cost.
>
> Do you...really not understand this?

The compilers are available for VMS Alpha.

The native compilers for VMS x86-64 are available for
development for some languages and the remaining languages
will become available soon.

Not really a cost problem.

(most certainly a timing problem for those waiting for
those native compilers)

>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
>
> How does one contribute to the work porting LLVM to VMS, then?

If someone has a strong interest in working with VSI on
LLVM on VMS, then I think they should contact John Reagan.

A more practical approach would be to look at one of other few
hundred thousand possible open source project and put LLVM
on hold until VSI release their changes (later this year or next year).

>>> Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code? Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
>
> You are not even consistent within your own post. There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
>
> Which is it?

The problem is that the statement "no one is doing that work"
is again pure fiction you behalf.

What I actually wrote was:

#I can tell you: two handful of people are doing all the
#work.

And while you fictitious "no one" can't contact VSI, then
the "two handful of people" certainly can in some cases do.

Arne

On 2/20/2023 6:28 AM, Dan Cross wrote:
> In article <tsuep3$hia4$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/19/2023 4:48 PM, Dan Cross wrote:
>>> In article <tst9dd$dhc4$1@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>>>> In article <tsrpoc$5qhq$2@dont-email.me>,
>>>>>> It is problematic to find people to maintain the ifdefs
>>>>>> and build scripts of for VMS in many open source projects.
>>>>>
>>>>> Have you ever stopped to wonder why that is, and how one might
>>>>> go about changing it?
>>>>
>>>> It is not obvious to me why VMS being open source should
>>>> make it more attractive to develop open source on VMS.
>>>
>>> It's prohibitively expensive to do so today. Should commercial
>>> vendors port to OpenVMS using the hobbyist program? How about
>>> open source vendors?
>>
>> ????
>>
>> Commercial vendors can use VSI's excellent ISV program.
>>
>> Open source developers can use either same ISV program
>> or hobbyist program.
>>
>> Minimum cost = zero.
>
> Too bad there are no native compilers for x86_64 yet,
> which means using a different platform, which comes back
> to cost.
>
> Do you...really not understand this?

The compilers are available for VMS Alpha.

The native compilers for VMS x86-64 are available for
development for some languages and the remaining languages
will become available soon.

Not really a cost problem.

(most certainly a timing problem for those waiting for
those native compilers)

>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
>
> How does one contribute to the work porting LLVM to VMS, then?

If someone has a strong interest in working with VSI on
LLVM on VMS, then I think they should contact John Reagan.

A more practical approach would be to look at one of other few
hundred thousand possible open source project and put LLVM
on hold until VSI release their changes (later this year or next year).

>>> Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code? Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
>
> You are not even consistent within your own post. There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
>
> Which is it?

The problem is that the statement "no one is doing that work"
is again pure fiction you behalf.

What I actually wrote was:

#I can tell you: two handful of people are doing all the
#work.

And while you fictitious "no one" can't contact VSI, then
the "two handful of people" certainly can in some cases do.

Arne

Den 2023-02-20 kl. 15:35, skrev Craig A. Berry:
>
> On 2/20/23 6:11 AM, Dan Cross wrote:
>
>> There is an ongoing effort to port LLVM to VMS to get native
>> compiler support, but with the existing language front-ends in
>> addition to clang etc, correct?  Where is that work happening?
>
> At VSI, obviously.  There have been numerous public presentations about
> what is being done and how it is being done.  The head of the compiler
> group chimes in here pretty frequently with updates and explanations.  I
> believe the clang++ port is in field test.  The customer portal now has
> a download of "VSI C X7.4-725" (a different compiler from the clang++
> compiler).

Note that the whole WASD web server now has been built native
using that C compiler. No major issues, as far as I undestood
from the post from the maintainer about it.

On 2/20/2023 11:18 AM, Jan-Erik Söderholm wrote:
> Den 2023-02-20 kl. 15:35, skrev Craig A. Berry:
>> On 2/20/23 6:11 AM, Dan Cross wrote:
>>> There is an ongoing effort to port LLVM to VMS to get native
>>> compiler support, but with the existing language front-ends in
>>> addition to clang etc, correct?  Where is that work happening?
>>
>> At VSI, obviously.  There have been numerous public presentations about
>> what is being done and how it is being done.  The head of the compiler
>> group chimes in here pretty frequently with updates and explanations.  I
>> believe the clang++ port is in field test.  The customer portal now has
>> a download of "VSI C X7.4-725" (a different compiler from the clang++
>> compiler).
>
> Note that the whole WASD web server now has been built native
> using that C compiler. No major issues, as far as I undestood
> from the post from the maintainer about it.

Yes.

VSI is getting there.

Maybe not as fast as many of us wished for.

But steady progress.

Arne

On 2/18/2023 9:24 PM, Arne Vajhøj wrote:
> On 2/18/2023 8:55 PM, Single Stage to Orbit wrote:
>> On Sat, 2023-02-18 at 19:45 -0500, Arne Vajhøj wrote:
>>> On 2/18/2023 6:17 PM, Single Stage to Orbit wrote:
>>>> On Sat, 2023-02-18 at 14:30 -0500, Arne Vajhøj wrote:
>>>>> And honestly I don't see Ada make the cut.
>>>>
>>>> I don't think that will be an issue, as the GNU compiler suite has
>>>> that, and once it's been ported, that will be good enough.
>>>
>>> But will GCC be ported to VMS (again)?
>>>
>>> The last GCC version I have seen run on VMS is 2.8.0
>>> (on VMS Alpha).
>>>
>>> And that is a let us call it "not latest and greatest".
>>
>> Wow, jsut wow. 2.8.0? I remember my first time with Linux and GCC
>> 2.7.2.3! And that was the late 90s!
>
> 2.8.0 is indeed from around that time (I don't remember exact year,
> but some of the files are timestamped 1998).
>
> $ typ test.c
> #include <stdio.h>
>
> int main()
> {
>     printf("Hello world from C!\n");
>     return 0;
> }
>
> $ gcc test.c
> $ gcclink test
> $ r test
> Hello world from C!
>
> If anybody has something newer then I am interested.
>
> C++ seems to be broken. Not sure if it always has been
> so or some update did that.

Does anybody remember whether GXX 2.8.0 worked
on VMS Alpha back then?

I consistently get:

%LINK-W-NUDFSYMS, 4 undefined symbols:
%LINK-I-UDFSYM, _vt$7istream$3ios
%LINK-I-UDFSYM, _vt$7ostream$3ios
%LINK-I-UDFSYM, _vt$8iostream$3ios
%LINK-I-UDFSYM, _vt$8stdiobuf

now. But maybe it worked back then with different VMS version,
different linker etc..

I know positively that C++ worked on VMS VAX back in version 1.42
a decade earlier (I used that extensively).

Arne

On Saturday, February 18, 2023 at 5:41:04 AM UTC-5, John Dallman wrote:
> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
> (Jan-Erik Söderholm) wrote:
>
> > English version of the meeting notes:
> The license news is good. The ADA news is not, but is hardly unexpected.
>
> Bare metal is a question of market segments, as far as I understand it.
> Enterprise IT shops in the US tend to be strongly in favour of
> virtualising everything. What is the compelling use case for bare metal?
>
> The costs of bare metal are considerable, since x86 hardware has a vast
> range of designs. There are probably 50-100 times more x86-64 server
> designs than the total numbers of Alpha and Itanium server designs
> produced by DEC, Compaq and HP for running VMS. Supporting it requires
> writing enormous numbers of VMS device drivers, a skill that is not at
> all common today. The VSI staff who can do it can do other things which
> will be more valuable to the company.
>
> Running under virtualisation needs only a few VMS device drivers. The
> actual hardware is managed by device drivers for the virtualisation
> software. Those are written by the hardware manufacturers so that
> virtualisation software can be run on their machines. Those hardware
> manufacturers are not going to start writing VMS device drivers unless
> VMS becomes /much/ more widely used.
>
> This view may seem negative, but it reflects the commercial reality that
> VSI need to cope with.
>
> John

how about so software developers can write apps for small and mid size customers who don't want to run virtual ...

they don't have to support all x86 platforms how about just one like HP bladeservers they are doing now?

WITHOUT A BARE METAL PLATFORM AND LIMITING OPENVMS TO VIRTUAL PLATFORMS ONLY, IT WILL NEVER GROW ...

On Saturday, February 18, 2023 at 9:49:41 PM UTC-5, Dan Cross wrote:

> >There is a huge server market that are very cost
> >sensitive (the people that prefer Ubuntu Server
> >or RockyLinux over RHEL).
> >
> >There is also a huge market where the cost of VMS is
> >not a problem - there are still sold a lot
> >of expensive software.
> >
> >VSI probably find the second market more attractive
> >than the first.
> Right now, VSI doesn't seem to have any real market.
>
> I'll be sad when VMS dies because people couldn't see beyond the
> way it's always been done.
>
> - Dan C.

AND WITHOUT BARE METAL SUPPORT AND AFFORDABLE LICENSING FOR THE SMALL/MEDIUM MARKET IT NEVER WILL ...

On Sunday, February 19, 2023 at 3:17:07 PM UTC-5, Scott Dorsey wrote:
> Dave Froble <da...@tsoft-inc.com> wrote:
> >
> >A question I'd ask, is, would Linux have done so well, if it was nothing more
> >than "free Unix"?
> When Linux was new, that was all it was. There were some competitors like
> xinu and minix, but Linux actually provided a full functional system. Because
> it was unixlike, there was plenty of existing software for it (including the
> whole gnu back catalogue). Because it was free, the barriers to entry were
> very low.
>
> One might ask if VMS would have done so well if it hadn't come with the Vax.
> Lots of folks bought VMS because of the hardware, not because of the software.
> Those folks were the first to abandon ship when the cheap and fast workstations
> came out in the eighties. (I'm talking here of mostly development folks and
> scientific computing folks who weren't so tied to architecture and who were
> very sensitive to price/performance.)
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

WHICH IS WHY YOU NEED AN INEXPENSIVE BARE METAL PLATFORM ...

On 2/20/2023 12:44 PM, ultr...@gmail.com wrote:
> On Saturday, February 18, 2023 at 5:41:04 AM UTC-5, John Dallman wrote:
>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>> English version of the meeting notes:
>> The license news is good. The ADA news is not, but is hardly unexpected.
>>
>> Bare metal is a question of market segments, as far as I understand it.
>> Enterprise IT shops in the US tend to be strongly in favour of
>> virtualising everything. What is the compelling use case for bare metal?
>>
>> The costs of bare metal are considerable, since x86 hardware has a vast
>> range of designs. There are probably 50-100 times more x86-64 server
>> designs than the total numbers of Alpha and Itanium server designs
>> produced by DEC, Compaq and HP for running VMS. Supporting it requires
>> writing enormous numbers of VMS device drivers, a skill that is not at
>> all common today. The VSI staff who can do it can do other things which
>> will be more valuable to the company.
>>
>> Running under virtualisation needs only a few VMS device drivers. The
>> actual hardware is managed by device drivers for the virtualisation
>> software. Those are written by the hardware manufacturers so that
>> virtualisation software can be run on their machines. Those hardware
>> manufacturers are not going to start writing VMS device drivers unless
>> VMS becomes /much/ more widely used.
>>
>> This view may seem negative, but it reflects the commercial reality that
>> VSI need to cope with.
>
> how about so software developers can write apps for small and mid size customers who don't want to run virtual ...
>
> they don't have to support all x86 platforms how about just one like HP bladeservers they are doing now?

Most small and mid size customers also run virtual (VMWare on prem,
or IaaS cloud).

Yes - some will prefer physical.

And VSI previously had a relevant specific HP Proliant model
on the target list.

But VSI are prioritizing what gives most bang for the buck right
now - and that is virtual.

Those that are current or potential future customers for
VSI and have a strong preference for physical should contact
VSI and let their voice be heard.

Arne

On Sunday, February 19, 2023 at 7:27:18 PM UTC-5, Arne Vajhøj wrote:
> On 2/19/2023 4:48 PM, Dan Cross wrote:
> > In article <tst9dd$dhc4$1...@dont-email.me>,
> > Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 2/18/2023 10:06 PM, Dan Cross wrote:
> >>> In article <tsrpoc$5qhq$2...@dont-email.me>,
> >>>> It is problematic to find people to maintain the ifdefs
> >>>> and build scripts of for VMS in many open source projects.
> >>>
> >>> Have you ever stopped to wonder why that is, and how one might
> >>> go about changing it?
> >>
> >> It is not obvious to me why VMS being open source should
> >> make it more attractive to develop open source on VMS.
> >
> > It's prohibitively expensive to do so today. Should commercial
> > vendors port to OpenVMS using the hobbyist program? How about
> > open source vendors?
> ????
>
> Commercial vendors can use VSI's excellent ISV program.
>
> Open source developers can use either same ISV program
> or hobbyist program.
>
> Minimum cost = zero.
> >> There is no (non-religious) reason for an open source developer
> >> to not develop open source on a closed source OS.
> >
> > Cost.
> Practically all software vendors has developer programs.
>
> Including VSI.
>
> Cost is not an issue.
> >> Open source simply requires people developing
> >> open source.
> >
> > ...which requires an incentive, which no one has for VMS. Very
> > few people in the open source world are running it, so why would
> > they develop for it? What incentive does anyone have to develop
> > for a closed proprietary platform controlled by a single, small
> > company?
> It is an observable fact that open source is developed for
> closed source platforms.
> >> A couple of well known quotes:
> >>
> >> Benjamin Franklin - Well done is better than well said
> >>
> >> John F Kennedy - Ask not what your country can do for you – ask what you
> >> can do for your country
> >
> > So I know a lot about OS implementation on x86, but have no
> > practical way to contribute to getting OpenVMS running. Oh
> > well.
> There are a few hundred thousand open source projects
> to get running on VMS.
> >> VMS does not need people that say:
> >> - VSI please open source VMS
> >> - someone please port GNAT to VMS
> >> - someone please port Rust to VMS
> >> - someone please port XYZ to VMS
> >>
> >> VMS need people that say:
> >> - I have ported XYZ to VMS
> >> - I have created ABC on VMS
> >
> > How, pray tell, is one going to cooperate in, say, porting GNAT
> > or Rust or LLVM to VMS, when all that development is being done
> > in a highly proprietary context that by its very nature
> > precludes collaboration?
> Close source does not preclude collaboration.
> > Suppose somebody finds a latent bug in
> > the OS that's tickled by the new compiler; how does one help get
> > that fixed without the source code? Sure, provide a really good
> > bug report, but none of that helps people do what you claim VMS
> > needs above.
> The people that actually do port open source to or develop
> open source for VMS does not seem to have that problem.
>
> They report it. VSI engineering responds.
>
> Not really that different from open source for the vast majority
> of developers that don't want to do OS fixes themselves.
>
> Recent example: Mark Daniels and the link time issue.
>
> Arne

YOU FORGOT PROVIDING THEM AN INEXPENSIVE BARE METAL BOX W/LICENSE TO SELL TO THE CUSTOMER TO RUN THE APP ...

On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
> %LINK-W-NUDFSYMS, 4 undefined symbols:
> %LINK-I-UDFSYM,         _vt$7istream$3ios
> %LINK-I-UDFSYM,         _vt$7ostream$3ios
> %LINK-I-UDFSYM,         _vt$8iostream$3ios
> %LINK-I-UDFSYM,         _vt$8stdiobuf

Smells like ABI issues. It depends on what linker is being used, I
guess. Mayvbe GCC should use its linker instead of the VMS linker.
--
Tactical Nuclear Kittens

On Monday, February 20, 2023 at 7:02:17 PM UTC+1, Single Stage to Orbit wrote:
> On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
> > %LINK-W-NUDFSYMS, 4 undefined symbols:
> > %LINK-I-UDFSYM, _vt$7istream$3ios
> > %LINK-I-UDFSYM, _vt$7ostream$3ios
> > %LINK-I-UDFSYM, _vt$8iostream$3ios
> > %LINK-I-UDFSYM, _vt$8stdiobuf
> Smells like ABI issues. It depends on what linker is being used, I
> guess. Mayvbe GCC should use its linker instead of the VMS linker.
> --
> Tactical Nuclear Kittens

It only shows that objects, object libraries or shareable images, which define theses symbols, are not included in the link operation.

On 2/20/2023 6:28 AM, Dan Cross wrote:
> In article <tsuep3$hia4$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/19/2023 4:48 PM, Dan Cross wrote:
>>> In article <tst9dd$dhc4$1@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>>>> In article <tsrpoc$5qhq$2@dont-email.me>,
>>>>>> It is problematic to find people to maintain the ifdefs
>>>>>> and build scripts of for VMS in many open source projects.
>>>>>
>>>>> Have you ever stopped to wonder why that is, and how one might
>>>>> go about changing it?
>>>>
>>>> It is not obvious to me why VMS being open source should
>>>> make it more attractive to develop open source on VMS.
>>>
>>> It's prohibitively expensive to do so today. Should commercial
>>> vendors port to OpenVMS using the hobbyist program? How about
>>> open source vendors?
>>
>> ????
>>
>> Commercial vendors can use VSI's excellent ISV program.
>>
>> Open source developers can use either same ISV program
>> or hobbyist program.
>>
>> Minimum cost = zero.
>
> Too bad there are no native compilers for x86_64 yet,
> which means using a different platform, which comes back
> to cost.
>
> Do you...really not understand this? No wait, nevermind.
>
>>> ...which requires an incentive, which no one has for VMS. Very
>>> few people in the open source world are running it, so why would
>>> they develop for it? What incentive does anyone have to develop
>>> for a closed proprietary platform controlled by a single, small
>>> company?
>>
>> It is an observable fact that open source is developed for
>> closed source platforms.
>
> How do you think that's relevant to the text that you quoted?
> No wait, nevermind.
>
>>> So I know a lot about OS implementation on x86, but have no
>>> practical way to contribute to getting OpenVMS running. Oh
>>> well.
>>
>> There are a few hundred thousand open source projects
>> to get running on VMS.
>
> How do you think that's relevant to participating in the port?
> No wait, nevermind.
>
>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
>
> How does one contribute to the work porting LLVM to VMS, then?
> No wait, nevermind.
>
>>> Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code? Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
>
> You are not even consistent within your own post. There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
>
> Which is it?
>
> No wait, nevermind.
>
> - Dan C.
>

I like to keep an open mind, but I'm wondering if I should ask, are you one of
Stallman's advocates?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/20/2023 12:44 PM, ultr...@gmail.com wrote:
> On Saturday, February 18, 2023 at 5:41:04 AM UTC-5, John Dallman wrote:
>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>
>>> English version of the meeting notes:
>> The license news is good. The ADA news is not, but is hardly unexpected.
>>
>> Bare metal is a question of market segments, as far as I understand it.
>> Enterprise IT shops in the US tend to be strongly in favour of
>> virtualising everything. What is the compelling use case for bare metal?
>>
>> The costs of bare metal are considerable, since x86 hardware has a vast
>> range of designs. There are probably 50-100 times more x86-64 server
>> designs than the total numbers of Alpha and Itanium server designs
>> produced by DEC, Compaq and HP for running VMS. Supporting it requires
>> writing enormous numbers of VMS device drivers, a skill that is not at
>> all common today. The VSI staff who can do it can do other things which
>> will be more valuable to the company.
>>
>> Running under virtualisation needs only a few VMS device drivers. The
>> actual hardware is managed by device drivers for the virtualisation
>> software. Those are written by the hardware manufacturers so that
>> virtualisation software can be run on their machines. Those hardware
>> manufacturers are not going to start writing VMS device drivers unless
>> VMS becomes /much/ more widely used.
>>
>> This view may seem negative, but it reflects the commercial reality that
>> VSI need to cope with.
>>
>> John
>
> how about so software developers can write apps for small and mid size customers who don't want to run virtual ...
>
> they don't have to support all x86 platforms how about just one like HP bladeservers they are doing now?
>
> WITHOUT A BARE METAL PLATFORM AND LIMITING OPENVMS TO VIRTUAL PLATFORMS ONLY, IT WILL NEVER GROW ...
>

Bob's back ....

Would a single x86 configuration be sufficient? I doubt it.

Otherwise, VSI would have to provide device drivers for many devices, and that
just ain't going to happen.

At least one thing a VM environment does is provide device drivers for selected
environments, and not even VMs support all possible devices. So using a VM an
OS does not have to worry about device drivers, or other issues trying to work
on "bare metal".

In the x86 world, I doubt anybody supports all possible devices. Just too many,
and constantly changing.

I don't really like the added layer of a VM, but I do realize, in the x86 world,
it is the least bad of a bunch of bad options. VMs also have some good features.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <tt0m40$s1co$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>[snip 99 lines]
>I like to keep an open mind, but I'm wondering if I should ask, are you one of
>Stallman's advocates?

Assuming you are asking in good faith....

No, absolutely not. Stallman is a pig with a long history of
abusive and harassing behavior.

I proudly signed the open letter calling for his ouster from
leadership positions after he reinstated into the leadership of
the FSF (which I do not support, financially or otherwise).
https://rms-open-letter.github.io/

- Dan C.

On Mon, 2023-02-20 at 11:35 -0800, hb@end.of.inter.net wrote:
> On Monday, February 20, 2023 at 7:02:17 PM UTC+1, Single Stage to
> Orbit wrote:
> > On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
> > > %LINK-W-NUDFSYMS, 4 undefined symbols:
> > > %LINK-I-UDFSYM,         _vt$7istream$3ios
> > > %LINK-I-UDFSYM,         _vt$7ostream$3ios
> > > %LINK-I-UDFSYM,         _vt$8iostream$3ios
> > > %LINK-I-UDFSYM,         _vt$8stdiobuf
> > Smells like ABI issues. It depends on what linker is being used, I
> > guess. Mayvbe GCC should use its linker instead of the VMS linker.
>
> It only shows that objects, object libraries or shareable images,
> which define theses symbols, are not included in the link operation.

Which kinda begs the question; what has it forgotten to link? These are
iostream routines.
--
Tactical Nuclear Kittens

On Monday, February 20, 2023 at 11:02:18 PM UTC+1, Single Stage to Orbit wrote:
> On Mon, 2023-02-20 at 11:35 -0800, h...@end.of.inter.net wrote:
> > On Monday, February 20, 2023 at 7:02:17 PM UTC+1, Single Stage to
> > Orbit wrote:
> > > On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
> > > > %LINK-W-NUDFSYMS, 4 undefined symbols:
> > > > %LINK-I-UDFSYM, _vt$7istream$3ios
> > > > %LINK-I-UDFSYM, _vt$7ostream$3ios
> > > > %LINK-I-UDFSYM, _vt$8iostream$3ios
> > > > %LINK-I-UDFSYM, _vt$8stdiobuf
> > > Smells like ABI issues. It depends on what linker is being used, I
> > > guess. Mayvbe GCC should use its linker instead of the VMS linker.
> >
> > It only shows that objects, object libraries or shareable images,
> > which define theses symbols, are not included in the link operation.
>
> Which kinda begs the question; what has it forgotten to link? These are
> iostream routines.
> --
> Tactical Nuclear Kittens

Only the user/developer knows. There is no link command or map file posted. For linking the C example the command/symbol gcclink is used, whatever that is/was. But for C++, nothing is said.

On Mon, 2023-02-20 at 21:23 +0000, Dan Cross wrote:
> > I like to keep an open mind, but I'm wondering if I should ask, are
> > you one of Stallman's advocates?
>
> Assuming you are asking in good faith....
>
> No, absolutely not.  Stallman is a pig with a long history of
> abusive and harassing behavior.
>
> I proudly signed the open letter calling for his ouster from
> leadership positions after he reinstated into the leadership of
> the FSF (which I do not support, financially or otherwise).
> https://rms-open-letter.github.io/

Well done. RMS needs to fuck off. For good.

Single-handedly he's driven a lot of women out of computing.

Fortunately things are changing for the better now. No thanks to creeps
like him.
--
Tactical Nuclear Kittens

On 2/20/2023 5:31 PM, hb@end.of.inter.net wrote:
> On Monday, February 20, 2023 at 11:02:18 PM UTC+1, Single Stage to
> Orbit wrote:
>> On Mon, 2023-02-20 at 11:35 -0800, h...@end.of.inter.net wrote:
>>> On Monday, February 20, 2023 at 7:02:17 PM UTC+1, Single Stage
>>> to Orbit wrote:
>>>> On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
>>>>> %LINK-W-NUDFSYMS, 4 undefined symbols: %LINK-I-UDFSYM,
>>>>> _vt$7istream$3ios %LINK-I-UDFSYM, _vt$7ostream$3ios
>>>>> %LINK-I-UDFSYM, _vt$8iostream$3ios %LINK-I-UDFSYM,
>>>>> _vt$8stdiobuf
>>>> Smells like ABI issues. It depends on what linker is being
>>>> used, I guess. Mayvbe GCC should use its linker instead of the
>>>> VMS linker.
>>>
>>> It only shows that objects, object libraries or shareable
>>> images, which define theses symbols, are not included in the link
>>> operation.
>>
>> Which kinda begs the question; what has it forgotten to link? These
>> are iostream routines.
>
> Only the user/developer knows. There is no link command or map file
> posted. For linking the C example the command/symbol gcclink is used,
> whatever that is/was. But for C++, nothing is said.

More info.

$ gxx test.cpp
$ gxxlink test
%LINK-W-NUDFSYMS, 4 undefined symbols:
%LINK-I-UDFSYM, _vt$7istream$3ios
%LINK-I-UDFSYM, _vt$7ostream$3ios
%LINK-I-UDFSYM, _vt$8iostream$3ios
%LINK-I-UDFSYM, _vt$8stdiobuf
%LINK-W-USEUNDEF, undefined symbol _vt$7istream$3ios referenced
in psect $LINK$ offset %X00000028
in module IOSTREAM file
DISK2:[ARNE.gcc.gcc.ALPHA-PROGIS-VMS_8_4.2_8_0]LIBSTDCXX.OLB;1
%LINK-W-USEUNDEF, undefined symbol _vt$7ostream$3ios referenced
in psect $LINK$ offset %X000005A0
in module IOSTREAM file
DISK2:[ARNE.gcc.gcc.ALPHA-PROGIS-VMS_8_4.2_8_0]LIBSTDCXX.OLB;1
%LINK-W-USEUNDEF, undefined symbol _vt$8iostream$3ios referenced
in psect $LINK$ offset %X00000748
in module IOSTREAM file
DISK2:[ARNE.gcc.gcc.ALPHA-PROGIS-VMS_8_4.2_8_0]LIBSTDCXX.OLB;1
%LINK-W-USEUNDEF, undefined symbol _vt$8stdiobuf referenced
in psect $LINK$ offset %X00000030
in module STDSTRBUFS file
DISK2:[ARNE.gcc.gcc.ALPHA-PROGIS-VMS_8_4.2_8_0]LIBSTDCXX.OLB;1

gxx is:
$GNU_ROOT:[BIN]GCC.EXE/PLUS

gxxlink is:

$ link/exe=TEST gnu_cc_library:crtbegin.obj, -
DISK2:[ARNE]TEST.obj;, -
gnu_cc_library:libstdcxx.olb/lib, -
gnu_cc_library:libiostream.olb/lib, -
gnu_cc_library:libio.olb/lib, -
gnu_cc_library:libgccplus.olb/lib, -
gnu_cc_library:libgcc.olb/lib, -
gnu_cc_library:crtend.obj, -
sys$library:vaxcrtl.olb/lib, -
gnu_cc_library:gxx_main.obj

That COM file is from 1998.

I have added libiostream and libio as part of troubleshooting now.

These missing symbols are nowhere to be found:

$ pipe libr/obj/list/name gnu_cc_library:libstdcxx.olb | search
sys$input vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ pipe libr/obj/list/name gnu_cc_library:libiostream.olb | search
sys$input vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ pipe libr/obj/list/name gnu_cc_library:libio.olb | search sys$input
vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ pipe libr/obj/list/name gnu_cc_library:libgccplus.olb | search
sys$input vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ pipe libr/obj/list/name gnu_cc_library:libgcc.olb | search sys$input
vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ sear sys$library:*.olb vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched
$ sear sys$library:*.exe vt$8stdiobuf
%SEARCH-I-NOMATCHES, no strings matched

But as I said then:
* maybe it has never worked - I do not remember what worked 25 years ago
* maybe it broke due to newer VMS version
* maybe it broke due to something else

The reference to sys$library:vaxcrtl.olb look highly suspicious.
But 1998 is a long time ago.

Arne

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <tsu14t$g5l7$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:

>> And then there is the vendor independence. With Linux you
>> were not tied to SUN/IBM/HP/DEC. Some companies liked that.

> "Sun" not "SUN"

The first product from Sun Microsystems was built around the SUN-1 processor
board, in which "SUN" was an acronym for "Stanford University Network".

Andy Bechtolsheim built (did not design) the "4M" processor board[1] designed
by the manager of the Computer Science Department Computer Facility, who was
better known in those days as the author of the Digital Press book on
programming the DECSYSTEM-20 in assembler language. His buddy from the
Graduate School of Business saw an opportunity, and the rest, as they say, is
history.

[1] "4M": 1 MIPS, 1MB, 1 million pixels, 1Mbps Ethernet. The design originated
c. 1979, when even the 3Mbps Ethernet was experimental, and the DIX standard
for 10Mbps did not yet exist.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2/20/2023 7:03 PM, Arne Vajhøj wrote:
> On 2/20/2023 5:31 PM, hb@end.of.inter.net wrote:
>> On Monday, February 20, 2023 at 11:02:18 PM UTC+1, Single Stage to
>> Orbit wrote:
>>> On Mon, 2023-02-20 at 11:35 -0800, h...@end.of.inter.net wrote:
>>>> On Monday, February 20, 2023 at 7:02:17 PM UTC+1, Single Stage
>>>> to Orbit wrote:
>>>>> On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
>>>>>> %LINK-W-NUDFSYMS, 4 undefined symbols: %LINK-I-UDFSYM,
>>>>>> _vt$7istream$3ios %LINK-I-UDFSYM,         _vt$7ostream$3ios
>>>>>> %LINK-I-UDFSYM,         _vt$8iostream$3ios %LINK-I-UDFSYM,
>>>>>> _vt$8stdiobuf
>>>>> Smells like ABI issues. It depends on what linker is being
>>>>> used, I guess. Mayvbe GCC should use its linker instead of the
>>>>> VMS linker.
>>>>
>>>> It only shows that objects, object libraries or shareable
>>>> images, which define theses symbols, are not included in the link
>>>> operation.
>>>
>>> Which kinda begs the question; what has it forgotten to link? These
>>> are iostream routines.
>>
>> Only the user/developer knows. There is no link command or map file
>> posted. For linking the C example the command/symbol gcclink is used,
>> whatever that is/was. But for C++, nothing is said.
>
> More info.
>
> $ gxx test.cpp
> $ gxxlink test
> %LINK-W-NUDFSYMS, 4 undefined symbols:
> %LINK-I-UDFSYM,         _vt$7istream$3ios
> %LINK-I-UDFSYM,         _vt$7ostream$3ios
> %LINK-I-UDFSYM,         _vt$8iostream$3ios
> %LINK-I-UDFSYM,         _vt$8stdiobuf

I got lucky.

First I found an old COM file from 1998 showing that I
did use GXX back then. So it had to work.

Then I found the old disk with the old stuff. And voila.
I had both a GCC280 and a GCCBETA. I was testing with the GCC280.

Get GCCBETA ready. And it works.

$ type test.c
#include <stdio.h>

int main()
{ printf("Hello world from C!\n");
return 0;
} $ gcc test.c
$ gcclink test
$ run test
Hello world from C!
$ type test.cpp
#include <iostream.h>

int main()
{ cout << "Hello world from C++!" << endl;
return 0;
} $ gxx test.cpp
$ gxxlink test
$ run test
Hello world from C++!

Arne

PS: If anyone want a copy I can ZIP it up.