On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>

Yes, I do. Then I remember it was written in the 1970s. :-) :-)

Simon.

PS: Sorry David, but you left yourself open to _that_ one. :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-01-31, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> And, it's irrelevant anyway. Your comment was that Fortran was
> unsuitable and the fact that all of the userland and all of the
> primitives needed to make this possible were, in fact, written
> in Fortran.
>

No. I said it's not suitable for writing userland tools today.

I also said that Fortran could be made to work, and I gave an example
of that, but I also said that when C came along, it was clearly a
far better choice.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/1/2022 8:17 AM, Bill Gunshannon wrote:
> On 1/31/22 21:37, Arne Vajhøj wrote:
>> On 1/31/2022 8:26 PM, Bill Gunshannon wrote:
>>> On 1/31/22 19:04, Dave Froble wrote:
>>>> On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
>>>>> On 1/31/22 14:33, Dave Froble wrote:
>>>>>> What about a "jack of all trades" that can do any job?
>>>>>
>>>>> Like choosing the wrong language for a task a "jack of all trades"
>>>>> is famous for doing everything, but none of the tasks well.  It is
>>>>> not a compliment to be called one.
>>>>
>>>> Why do you ass-u-me that just because a language is versatile, that
>>>> it cannot do things well?  Do you have examples?  Any real facts?
>>>> Or just bullshit?
>>>
>>> I don't assume it.  At one time, when languages were more domain
>>> specific, it was a known factor of program development.
>>
>>>                                            One would have hoped
>>> that the formalization of "Software Engineering" would have kept
>>> the idea in vogue, but, alas, no.
>>
>> I see lots of specialization.
>>
>> Most languages are only a big language within a few areas. And
>> even if a language is used within multiple areas then the
>> libraries/frameworks used are often very different).
>>
>> OS - C/C++
>> containers - Go
>> servers (web, app, DB, MQ and Cache) - C/C++ or Java
>> client side web - JavaScript
>> Windows desktop apps - C# or C++
>> Mac desktop apps - Objective-C or Swift
>> iPhone and iPads - Swift
>> Android phones - Java or Kotlin
>> server side web - PHP, Python, Ruby, JavaScript, Java or C#
>> backend processing - Java, C++, C# or Python
>> data analysis - Python, R
>
> Don't confuse use for design intention.  Most of those languages
> had no particular purpose when designed and were just general
> purpose languages.

I think that picture is a bit more blurred.

Some languages were designed for their specific
purpose (from the above list JavaScript, Swift,
PHP, R).

Some languages were designed for specific purposes
but ended up being used in many other contexts
(C, Java, Python).

Some languages were designed for general usage
(C++, C#, Kotlin).

Arne

On 2022-02-01 02:31, Bill Gunshannon wrote:
> On 1/31/22 19:53, Johnny Billquist wrote:
>> Actually, making use of hardware specific features can be a big issue.
>> With RSX, plenty use is made of the MMU and you have basically no
>> chance of "porting" RSX to anything that don't have a very similar MMU.
>> Instead you will then need to do a reimplementation where some things
>> needs to be done rather differently.
>
> But if you moved to a system with a large address space would
> an MMU even be necessary?  BSD on the PDP_11 uses overlays,
> the VAX does not.

An MMU is not strictly necessary, but when you don't have one, you are
in a pretty ugly place. You miss the whole concept of virtual memory.
And a lot of things become very different, very complicated, and very
convoluted.

I bet you haven't actually looked at RSX run without an MMU. It's called
an unmapped system. And every program needs to be linked to the actual
physical addresses it will use, you can only run one program at a time,
if they make use of the same address space, you cannot have shared,
position independent libraries, memory protection does not exist, and
god knows what kind of mess you end up with.
(Even knowing what address to link to is a bit of an effort, and the
whole handling of the memory layout becomes a tedious manual process.)

You really want to have an MMU. And RSX have some very specific design
choices made that tie intimately into how the PDP-11 works, and how the
MMU works.

A prime example: system calls in RSX is done with an EMT instruction.
The argument is on the stack. The argument can either be an address or a
function. All functions have odd values, since addresses basically have
to be even values on a PDP-11 (odd addresses can only address bytes),
while the arguments are supposed to be a bunch of words.

Now, that concept don't translate/work on a CPU that don't have this
idea that addresses have to be even.

Johnny

On 2022-02-01 02:36, Bill Gunshannon wrote:
> On 1/31/22 19:48, Johnny Billquist wrote:
>> On 2022-01-31 18:39, Bill Gunshannon wrote:
>>>
>>> The same is probably true of just about any OS.  All it takes is
>>> access to the source and a desire by someone to do the work.  Why
>>> do you think I would still like to see the source to RSTS released
>>> into the wild.  RSX which was very PDP-11 specific now has a version
>>> running on later Z80 family processors.  I have it running here at
>>> my home and it works quite well.
>>
>> The Z80 RSX implementation has pretty little to do with the PDP-11 RSX
>> sources. So I think it's pretty incorrect to claim you need the
>> sources of X to do some implementation giving similar functionality on
>> different hardware.
>
> That's true, but it would make it a lot easier.  All you really need
> is very good documentation of the internals (which is what I assume
> the writer of RSX-120 used).  I have never seen even that for RSTS
> or RT-11.

It might make things easier, but then again, I suspect you are putting
to much faith into that idea. When you get down to it, and actually
start writing code, you realize how much you need to throw out.

A bit like what I figured when writing my TCP/IP for RSX. A lot of
common networking API concepts I had to throw out the window. But it
took some time to figure things out.

>> But you are right that it does require the desire to do the work.
>> Linux is an example of this. Linus wanted something Unix like, but
>> couldn't use the existing software, so he rewrote it based on the
>> public APIs. User applications compile and work fine (usually) on both
>> Linux and Unix, even though the internals sometimes are rather different.
>
> Yeah, I never understood his reasoning.  The BSD lawsuit was well
> known to be DOA and development of BSD never paused.  And then there
> was MINIX with source published and even available on floppies.  I
> still have both my disk sets as well as the book.

There is some quote from Linus somewhere about if BSD (I think it was)
had been free at the time, he would never have started Linux. But right
at that time, the whole lawsuit was going on, and Linus certainly did
not have access. That was all that was needed.

Johnny

On 2/1/2022 8:22 AM, Bill Gunshannon wrote:
> On 1/31/22 21:31, Dave Froble wrote:
>> On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
>>> On 1/31/22 19:53, Johnny Billquist wrote:
>>
>>>> We covered this a long time ago. You don't need the RSTS/E sources to write a
>>>> new implementation of it. You just need time and energy.
>>
>> I really have to wonder, would anyone actually devote the time and resources
>> to re-implement RSTS/E?
>
> I would. :-)

I'm not convinced, it would not be a trivial effort.

>> What hardware would one choose?
>
> Ideally, I would make it portable but initially probably PC Class
> machines and a certain 6809 I have.

So some more hackery to run on x86, huh? Why not ARM?

>> What implementation language would one choose?
>
> Probably C as that is the language I am most likely to find compilers
> for on different machines.

C is so disgusting. Ok, I'll admit that it's just about everywhere.

>> What would one do with it?
>
> What do Hobbyists today do with any of the old OSes and systems they
> have. I would play with it. I would look into adding networking and
> probably X11.

That statement makes me wonder. To me, "adding networking" isn't an extra, it's
part of the OS, and should not be an "add-on".

Would you be targeting earlier versions, such as V4, V5, or V6, or V10 or so?"

With the later versions, DCL is part of RSTS/E, you ready to re-implement DCL,
TCP/IP, DECnet, and all the rest that was RSTS/E?

> It's all for fun anyway.

Ok, then perhaps one good way to get started, is to get ahold of some design
documentation to allow a decent start. If I was to consider such an attempt,
I'd want a decent design to start with.

John Santos and EG&H developer ROSS/V way back in the day. In case you don't
know what that is/was, it is software that used the PDP-11 compatibility mode to
implement a RSTS/E "look and feel" on early VAXs. In order to do so, I'd think
that they had a decent design to start with. Perhaps such documentation still
exists. Perhaps they might provide you with a copy, if you asked nicely.

Still having "fun" ?????????????????????

--
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/1/2022 9:01 AM, Simon Clubley wrote:
> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>
>
> Yes, I do. Then I remember it was written in the 1970s. :-) :-)

What does that have to do with anything?

DEC software people had RSX. When they needed an OS for the new VAX computer,
would it not be obvious that they'd basically start with the concepts in RSX?

> Simon.
>
> PS: Sorry David, but you left yourself open to _that_ one. :-)

I'm at a real loss as to just what I was "open" to? All I did was mention that
VMS sort of grew out of RSX. You choose to clip that part of my post. Why is that?

--
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/1/22 11:45, Dave Froble wrote:
> On 2/1/2022 8:22 AM, Bill Gunshannon wrote:
>> On 1/31/22 21:31, Dave Froble wrote:
>>> On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
>>>> On 1/31/22 19:53, Johnny Billquist wrote:
>>>
>>>>> We covered this a long time ago. You don't need the RSTS/E sources
>>>>> to write a
>>>>> new implementation of it. You just need time and energy.
>>>
>>> I really have to wonder, would anyone actually devote the time and
>>> resources
>>> to re-implement RSTS/E?
>>
>> I would.  :-)
>
> I'm not convinced, it would not be a trivial effort.

Guess I would have to give up some of the time I currently devote
to writing things for Rosetta Code. :-)

>
>>> What hardware would one choose?
>>
>> Ideally, I would make it portable but initially probably PC Class
>> machines and a certain 6809 I have.
>
> So some more hackery to run on x86, huh?  Why not ARM?

If I wanted others to be able to look at what I have done it would
have to be something others might have. Because the only Arm I have
at the moment is the Pi 1 Model B. I have no development tools for
it and I am rapidly finding out that contrary to the idea that things
will live forever on the web most software that ran on these boxes
has vanished.

>
>>> What implementation language would one choose?
>>
>> Probably C as that is the language I am most likely to find compilers
>> for on different machines.
>
> C is so disgusting.

Personal opinion. I have been doing C for over 40 years and have
never had a problem with it.

> Ok, I'll admit that it's just about everywhere.

That, too.

>
>>> What would one do with it?
>>
>> What do Hobbyists today do with any of the old OSes and systems they
>> have.  I would play with it.  I would look into adding networking and
>> probably X11.
>
> That statement makes me wonder.  To me, "adding networking" isn't an
> extra, it's part of the OS, and should not be an "add-on".

Sorry, when I said networking I meant usable networking. RSTS had
DECNET but that is of very limited usefulness today. There was
never TCP/IP for RSTS that I was aware of and I ran it right up to
the last release.

>
> Would you be targeting earlier versions, such as V4, V5, or V6, or V10
> or so?"

I would be targeting what ever version I could get usable data for.
At this point that is none of them.

>
> With the later versions, DCL is part of RSTS/E, you ready to
> re-implement DCL, TCP/IP, DECnet, and all the rest that was RSTS/E?

Sure, but there was no TCP/IP.

>
>> It's all for fun anyway.
>
> Ok, then perhaps one good way to get started, is to get ahold of some
> design documentation to allow a decent start.  If I was to consider such
> an attempt, I'd want a decent design to start with.
>
> John Santos and EG&H developer ROSS/V way back in the day.  In case you
> don't know what that is/was, it is software that used the PDP-11
> compatibility mode to implement a RSTS/E "look and feel" on early VAXs.
> In order to do so, I'd think that they had a decent design to start
> with.  Perhaps such documentation still exists.  Perhaps they might
> provide you with a copy, if you asked nicely.

I doubt any of it still exists and if previous experience holds true
even if it did they would not release it. RSTS has been dead for how
many years now? And none of it has been released for any purpose at
all. I have the two volume Software Resources book for the PDP-11.
I have attempted to track down some of the products in the hope of
actually salvaging something from them. Most don't exist and of those
that do I have yet to find one that still has copies of that old
software. I find this to be quite common not only with DEC Stuff
but just about anything old in the IT world. Frequently upon inquiry
I am told "We threw all that out ages ago."

bill

>
> Still having "fun" ?????????????????????
>
>

On 2/1/2022 12:27 PM, Bill Gunshannon wrote:
> On 2/1/22 11:45, Dave Froble wrote:
>> On 2/1/2022 8:22 AM, Bill Gunshannon wrote:
>>> On 1/31/22 21:31, Dave Froble wrote:
>>>> On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
>>>>> On 1/31/22 19:53, Johnny Billquist wrote:
>>>>
>>>>>> We covered this a long time ago. You don't need the RSTS/E sources to write a
>>>>>> new implementation of it. You just need time and energy.
>>>>
>>>> I really have to wonder, would anyone actually devote the time and resources
>>>> to re-implement RSTS/E?
>>>
>>> I would. :-)
>>
>> I'm not convinced, it would not be a trivial effort.
>
> Guess I would have to give up some of the time I currently devote
> to writing things for Rosetta Code. :-)
>
>>
>>>> What hardware would one choose?
>>>
>>> Ideally, I would make it portable but initially probably PC Class
>>> machines and a certain 6809 I have.
>>
>> So some more hackery to run on x86, huh? Why not ARM?
>
> If I wanted others to be able to look at what I have done it would
> have to be something others might have. Because the only Arm I have
> at the moment is the Pi 1 Model B. I have no development tools for
> it and I am rapidly finding out that contrary to the idea that things
> will live forever on the web most software that ran on these boxes
> has vanished.
>
>>
>>>> What implementation language would one choose?
>>>
>>> Probably C as that is the language I am most likely to find compilers
>>> for on different machines.
>>
>> C is so disgusting.
>
> Personal opinion. I have been doing C for over 40 years and have
> never had a problem with it.
>
>
>> Ok, I'll admit that it's just about everywhere.
>
> That, too.
>
>>
>>>> What would one do with it?
>>>
>>> What do Hobbyists today do with any of the old OSes and systems they
>>> have. I would play with it. I would look into adding networking and
>>> probably X11.
>>
>> That statement makes me wonder. To me, "adding networking" isn't an extra,
>> it's part of the OS, and should not be an "add-on".
>
> Sorry, when I said networking I meant usable networking. RSTS had
> DECNET but that is of very limited usefulness today. There was
> never TCP/IP for RSTS that I was aware of and I ran it right up to
> the last release.
>
>>
>> Would you be targeting earlier versions, such as V4, V5, or V6, or V10 or so?"
>
> I would be targeting what ever version I could get usable data for.
> At this point that is none of them.
>
>>
>> With the later versions, DCL is part of RSTS/E, you ready to re-implement DCL,
>> TCP/IP, DECnet, and all the rest that was RSTS/E?
>
> Sure, but there was no TCP/IP.
>
>>
>>> It's all for fun anyway.
>>
>> Ok, then perhaps one good way to get started, is to get ahold of some design
>> documentation to allow a decent start. If I was to consider such an attempt,
>> I'd want a decent design to start with.
>>
>> John Santos and EG&H developer ROSS/V way back in the day. In case you don't
>> know what that is/was, it is software that used the PDP-11 compatibility mode
>> to implement a RSTS/E "look and feel" on early VAXs. In order to do so, I'd
>> think that they had a decent design to start with. Perhaps such documentation
>> still exists. Perhaps they might provide you with a copy, if you asked nicely.
>
> I doubt any of it still exists and if previous experience holds true
> even if it did they would not release it.

Well, that tells me that you're not serious. I just gave you a pointer to some
people who know RSTS rather well. If you're not willing to contact John, then
you're not serious.

Another thing I thought about, two actually.

RSTS/E had the RSX stuff that allowed for BP2, and other things. You gonna
re-implement the RSX stuff?

Can it really be RSTS/E without Basic+? You gonna re-implement the language?

> RSTS has been dead for how
> many years now? And none of it has been released for any purpose at
> all. I have the two volume Software Resources book for the PDP-11.
> I have attempted to track down some of the products in the hope of
> actually salvaging something from them. Most don't exist and of those
> that do I have yet to find one that still has copies of that old
> software. I find this to be quite common not only with DEC Stuff
> but just about anything old in the IT world. Frequently upon inquiry
> I am told "We threw all that out ages ago."
>
> bill
>
>
>>
>> Still having "fun" ?????????????????????
>>
>>
>

--
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/1/22 12:33, Dave Froble wrote:
> On 2/1/2022 12:27 PM, Bill Gunshannon wrote:
>> On 2/1/22 11:45, Dave Froble wrote:
>>> On 2/1/2022 8:22 AM, Bill Gunshannon wrote:
>>>> On 1/31/22 21:31, Dave Froble wrote:
>>>>> On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
>>>>>> On 1/31/22 19:53, Johnny Billquist wrote:
>>>>>
>>>>>>> We covered this a long time ago. You don't need the RSTS/E
>>>>>>> sources to write a
>>>>>>> new implementation of it. You just need time and energy.
>>>>>
>>>>> I really have to wonder, would anyone actually devote the time and
>>>>> resources
>>>>> to re-implement RSTS/E?
>>>>
>>>> I would.  :-)
>>>
>>> I'm not convinced, it would not be a trivial effort.
>>
>> Guess I would have to give up some of the time I currently devote
>> to writing things for Rosetta Code.  :-)
>>
>>>
>>>>> What hardware would one choose?
>>>>
>>>> Ideally, I would make it portable but initially probably PC Class
>>>> machines and a certain 6809 I have.
>>>
>>> So some more hackery to run on x86, huh?  Why not ARM?
>>
>> If I wanted others to be able to look at what I have done it would
>> have to be something others might have.  Because the only Arm I have
>> at the moment is the Pi 1 Model B.  I  have no development tools for
>> it and I am rapidly finding out that contrary to the idea that things
>> will live forever on the web most software that ran on these boxes
>> has vanished.
>>
>>>
>>>>> What implementation language would one choose?
>>>>
>>>> Probably C as that is the language I am most likely to find compilers
>>>> for on different machines.
>>>
>>> C is so disgusting.
>>
>> Personal opinion.  I have been doing C for over 40 years and have
>> never had a problem with it.
>>
>>
>>>                      Ok, I'll admit that it's just about everywhere.
>>
>> That, too.
>>
>>>
>>>>> What would one do with it?
>>>>
>>>> What do Hobbyists today do with any of the old OSes and systems they
>>>> have.  I would play with it.  I would look into adding networking and
>>>> probably X11.
>>>
>>> That statement makes me wonder.  To me, "adding networking" isn't an
>>> extra,
>>> it's part of the OS, and should not be an "add-on".
>>
>> Sorry, when I said networking I meant usable networking.  RSTS had
>> DECNET but that is of very limited usefulness today.  There was
>> never TCP/IP for RSTS that I was aware of and I ran it right up to
>> the last release.
>>
>>>
>>> Would you be targeting earlier versions, such as V4, V5, or V6, or
>>> V10 or so?"
>>
>> I would be targeting what ever version I could get usable data for.
>> At this point that is none of them.
>>
>>>
>>> With the later versions, DCL is part of RSTS/E, you ready to
>>> re-implement DCL,
>>> TCP/IP, DECnet, and all the rest that was RSTS/E?
>>
>> Sure, but there was no TCP/IP.
>>
>>>
>>>> It's all for fun anyway.
>>>
>>> Ok, then perhaps one good way to get started, is to get ahold of some
>>> design
>>> documentation to allow a decent start.  If I was to consider such an
>>> attempt,
>>> I'd want a decent design to start with.
>>>
>>> John Santos and EG&H developer ROSS/V way back in the day.  In case
>>> you don't
>>> know what that is/was, it is software that used the PDP-11
>>> compatibility mode
>>> to implement a RSTS/E "look and feel" on early VAXs.  In order to do
>>> so, I'd
>>> think that they had a decent design to start with.  Perhaps such
>>> documentation
>>> still exists.  Perhaps they might provide you with a copy, if you
>>> asked nicely.
>>
>> I doubt any of it still exists and if previous experience holds true
>> even if it did they would not release it.
>
> Well, that tells me that you're not serious.  I just gave you a pointer
> to some people who know RSTS rather well.  If you're not willing to
> contact John, then you're not serious.

Serious? None of this is serious. I'm retired with too much time
on my hands. It would be fun to do. I may contact him but I don't
like annoying other people for my pet projects.

>
> Another thing I thought about, two actually.
>
> RSTS/E had the RSX stuff that allowed for BP2, and other things.  You
> gonna re-implement the RSX stuff?
>
> Can it really be RSTS/E without Basic+?  You gonna re-implement the
> language?

Well, personally, I never used BASIC other than maybe to play
around. You seem to think I am looking at a commercially viable
product here. It's just for fun. I'll probably die long before
I had more than a bootable kernel if I even got that far.

>
>> RSTS has been dead for how
>> many years now?  And none of it has been released for any purpose at
>> all.  I have the two volume Software Resources book for the PDP-11.
>> I have attempted to track down some of the products in the hope of
>> actually salvaging something from them.  Most don't exist and of those
>> that do I have yet to find one that still has copies of that old
>> software.  I find this to be quite common not only with DEC Stuff
>> but just about anything old in the IT world.  Frequently upon inquiry
>> I am told "We threw all that out ages ago."
>>
>> bill
>>
>>
>>>
>>> Still having "fun" ?????????????????????
>>>
>>>
>>
>
>

bill

On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>
>>
>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>
> What does that have to do with anything?
>

What makes some things about VMS so limiting in the 21st century is
as a direct result of it being designed in the 1970s instead of it
being designed around more modern techniques and concepts.

I believe I may have expressed some opinions in this area previously. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> …
> Fortran and COBOL are not suitable for writing operating system userland tools.

Not that I would encourage it as an implementation language these days, but
Fortran has been used as such in the past. I believe the Fortran H Extended
optimising compiler for the IBM 360/370 was written largely in Fortran H
Extended.

—
Paul Hardy
Web: http://pghardy.net

On 2022-02-01 19:28, Simon Clubley wrote:
> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>
>>>
>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>
>> What does that have to do with anything?
>>
>
> What makes some things about VMS so limiting in the 21st century is
> as a direct result of it being designed in the 1970s instead of it
> being designed around more modern techniques and concepts.
>
> I believe I may have expressed some opinions in this area previously. :-)

This kind of argument always have the same problem that Unix is even
older. Does that mean Unix have an even larger problem?

Or is this in fact not a factor in there?

Johnny

In article <stbefv$rre$2@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
> >
> > Don't people ever wonder what DEC people were thinking when they wrote VMS?
> >
>
> Yes, I do. Then I remember it was written in the 1970s. :-) :-)

There are two major products to come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence.

---Tim Jacques

On 2/1/2022 1:28 PM, Simon Clubley wrote:
> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>
>>>
>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>
>> What does that have to do with anything?
>>
>
> What makes some things about VMS so limiting in the 21st century is
> as a direct result of it being designed in the 1970s instead of it
> being designed around more modern techniques and concepts.
>
> I believe I may have expressed some opinions in this area previously. :-)
>
> Simon.
>

You really like to change what people are saying, don't you?

--
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 <stc4nj$2b8$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> In article <stbefv$rre$2@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
> > On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
> > >
> > > Don't people ever wonder what DEC people were thinking when they wrote VMS?
> > >
> >
> > Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>
> There are two major products to come out of Berkeley: LSD and UNIX. We
> don't believe this to be a coincidence.
>
> ---Tim Jacques

Once I saw an old (even 20 years ago it was old) ad from DEC from the
late 1970s which showed some people in an old-style computer room. The
captions was something like "|d|i|g|i|t|a|l| architecture for the
1980s". Beneath it, someone had written "and fashions for the 1970s".

On 2/1/2022 2:56 PM, Johnny Billquist wrote:
> On 2022-02-01 19:28, Simon Clubley wrote:
>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>
>>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>>
>>>>
>>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>>
>>> What does that have to do with anything?
>>>
>>
>> What makes some things about VMS so limiting in the 21st century is
>> as a direct result of it being designed in the 1970s instead of it
>> being designed around more modern techniques and concepts.
>>
>> I believe I may have expressed some opinions in this area previously. :-)
>
> This kind of argument always have the same problem that Unix is even older. Does
> that mean Unix have an even larger problem?
>
> Or is this in fact not a factor in there?
>
> Johnny

It is a factor, when Simon wants it to be. It is not a factor when Simon does
not want it to be.

He is also good at partially quoting what someone writes, when he wants to
change the message to what he wants to respond to.

--
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 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> ?
>> Fortran and COBOL are not suitable for writing operating system userland tools.
>
> Not that I would encourage it as an implementation language these days, but
> Fortran has been used as such in the past. I believe the Fortran H Extended
> optimising compiler for the IBM 360/370 was written largely in Fortran H
> Extended.
>

You are correct about past use. In the context of the discussion,
I meant they are not suitable for writing userland tools _today_
and I gave an example of where I had seen Fortran used in the
distant past while I was still in school and before before C got
established outside of Unix.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-01, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-02-01 19:28, Simon Clubley wrote:
>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>
>>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>>
>>>>
>>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>>
>>> What does that have to do with anything?
>>>
>>
>> What makes some things about VMS so limiting in the 21st century is
>> as a direct result of it being designed in the 1970s instead of it
>> being designed around more modern techniques and concepts.
>>
>> I believe I may have expressed some opinions in this area previously. :-)
>
> This kind of argument always have the same problem that Unix is even
> older. Does that mean Unix have an even larger problem?
>
> Or is this in fact not a factor in there?
>

No. It means that the Unix creators were _very_ insightful and _very_
forward looking in the early 1970s when they rewrote Unix, including
the kernel, in a mostly portable language that mostly decoupled the
implementation from the architecture it ran on, while most other people
still wrote their kernels, and maybe good portions of their userland
as well, in assembly language.

They were also very insightful in that the minimum application programming
language they supported was also C. These factors laid the groundwork
for the future use of Unix across a large range of architectures and
was directly responsible for its rise to the position it gained.

They were a good 10 years earlier with these moves than when these ideas
started to become mainstream.

DEC OTOH, took the traditional approach for the time and wrote their VMS
kernel in an assembly language that was directly tied to the architecture
and also allowed assembly language to be used as an application programming
language, which directly impacted how the VMS APIs were designed.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>
> It is a factor, when Simon wants it to be. It is not a factor when Simon does
> not want it to be.
>
> He is also good at partially quoting what someone writes, when he wants to
> change the message to what he wants to respond to.
>

No, it means that the Unix developers had a level of insight and
forward thinking that DEC lacked when the Unix developers chose to
rewrite Unix in a mostly portable programming language from top to
bottom long before such ideas became mainstream.

It's a pity that the move to what was essentially a portable version
of VMS in Pillar 10 years after VMS was created was cancelled. That
could have _really_ opened up the future use of VMS in the same way
that the use of a mostly portable language did for Unix.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wednesday, February 2, 2022 at 1:41:08 PM UTC-5, Simon Clubley wrote:
> On 2022-02-01, Johnny Billquist <b...@softjar.se> wrote:
> > On 2022-02-01 19:28, Simon Clubley wrote:
> >> On 2022-02-01, Dave Froble <da...@tsoft-inc.com> wrote:
> >>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
> >>>> On 2022-01-31, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>>>
> >>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
> >>>>>
> >>>>
> >>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
> >>>
> >>> What does that have to do with anything?
> >>>
> >>
> >> What makes some things about VMS so limiting in the 21st century is
> >> as a direct result of it being designed in the 1970s instead of it
> >> being designed around more modern techniques and concepts.
> >>
> >> I believe I may have expressed some opinions in this area previously. :-)
> >
> > This kind of argument always have the same problem that Unix is even
> > older. Does that mean Unix have an even larger problem?
> >
> > Or is this in fact not a factor in there?
> >
> No. It means that the Unix creators were _very_ insightful and _very_
> forward looking in the early 1970s when they rewrote Unix, including
> the kernel, in a mostly portable language that mostly decoupled the
> implementation from the architecture it ran on, while most other people
> still wrote their kernels, and maybe good portions of their userland
> as well, in assembly language.
>
> They were also very insightful in that the minimum application programming
> language they supported was also C. These factors laid the groundwork
> for the future use of Unix across a large range of architectures and
> was directly responsible for its rise to the position it gained.
>
> They were a good 10 years earlier with these moves than when these ideas
> started to become mainstream.
>
> DEC OTOH, took the traditional approach for the time and wrote their VMS
> kernel in an assembly language that was directly tied to the architecture
> and also allowed assembly language to be used as an application programming
> language, which directly impacted how the VMS APIs were designed.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
You realize that both the VAX and VMS were collaborative projects such that there were architectural elements to make VMS work better right?
VAX had queue instructions for this reason for example.

MACRO 32 was not "designed" to be an application language any more than IBMs assembly was even though both platforms had applications entirely written in their respective assembly languages.

On 2/2/2022 1:41 PM, Simon Clubley wrote:
> On 2022-02-01, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-02-01 19:28, Simon Clubley wrote:
>>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>
>>>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>>>
>>>>>
>>>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>>>
>>>> What does that have to do with anything?
>>>>
>>>
>>> What makes some things about VMS so limiting in the 21st century is
>>> as a direct result of it being designed in the 1970s instead of it
>>> being designed around more modern techniques and concepts.
>>>
>>> I believe I may have expressed some opinions in this area previously. :-)
>>
>> This kind of argument always have the same problem that Unix is even
>> older. Does that mean Unix have an even larger problem?
>>
>> Or is this in fact not a factor in there?
>>
>
> No. It means that the Unix creators were _very_ insightful and _very_
> forward looking in the early 1970s when they rewrote Unix, including
> the kernel, in a mostly portable language that mostly decoupled the
> implementation from the architecture it ran on, while most other people
> still wrote their kernels, and maybe good portions of their userland
> as well, in assembly language.

The idea of an OS mostly written in a HLL is not invented by Unix.

But I agree that they made the right decision.

> They were also very insightful in that the minimum application programming
> language they supported was also C. These factors laid the groundwork
> for the future use of Unix across a large range of architectures and
> was directly responsible for its rise to the position it gained.

I believe that assembler has always been supported on Unix.

With the traditional Unix C tool chain of compiler driver calling
preprocessor, actual compiler, assembler and loader then it is
not even possible to compile on a system without the assembler.

And null terminated strings are not harder to do in assembler
than descriptor strings.

> They were a good 10 years earlier with these moves than when these ideas
> started to become mainstream.
>
> DEC OTOH, took the traditional approach for the time and wrote their VMS
> kernel in an assembly language that was directly tied to the architecture

I believe a good chunk of VMS was not written in Macro-32 but in Bliss.

In hindsight C would have been better than Bliss.

In hindsight more Bliss/C and less Macro-32 would have been good.

But 20/20 hindsight is easy.

Arne

On 2022-02-02 19:41, Simon Clubley wrote:
> On 2022-02-01, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-02-01 19:28, Simon Clubley wrote:
>>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>
>>>>>> Don't people ever wonder what DEC people were thinking when they wrote VMS?
>>>>>>
>>>>>
>>>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>>>
>>>> What does that have to do with anything?
>>>>
>>>
>>> What makes some things about VMS so limiting in the 21st century is
>>> as a direct result of it being designed in the 1970s instead of it
>>> being designed around more modern techniques and concepts.
>>>
>>> I believe I may have expressed some opinions in this area previously. :-)
>>
>> This kind of argument always have the same problem that Unix is even
>> older. Does that mean Unix have an even larger problem?
>>
>> Or is this in fact not a factor in there?
>>
>
> No. It means that the Unix creators were _very_ insightful and _very_
> forward looking in the early 1970s when they rewrote Unix, including
> the kernel, in a mostly portable language that mostly decoupled the
> implementation from the architecture it ran on, while most other people
> still wrote their kernels, and maybe good portions of their userland
> as well, in assembly language.
>
> They were also very insightful in that the minimum application programming
> language they supported was also C. These factors laid the groundwork
> for the future use of Unix across a large range of architectures and
> was directly responsible for its rise to the position it gained.
>
> They were a good 10 years earlier with these moves than when these ideas
> started to become mainstream.
>
> DEC OTOH, took the traditional approach for the time and wrote their VMS
> kernel in an assembly language that was directly tied to the architecture
> and also allowed assembly language to be used as an application programming
> language, which directly impacted how the VMS APIs were designed.

You are ignoring Bliss?
Heck, even parts of RSX is written in Bliss.

(But with that said, you are certainly right that portability was not on
DECs mind...)

But now we're talking about implementation details.

You said above:
"What makes some things about VMS so limiting in the 21st century is
as a direct result of it being designed in the 1970s instead of it
being designed around more modern techniques and concepts."

The implementation language have pretty much nothing to do with the design.

Maybe what you actually meant is that the problem with VMS was that the
implementation was done in a very 70s non-portable way?

Johnny

On 2/2/2022 1:54 PM, Simon Clubley wrote:
> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> It is a factor, when Simon wants it to be. It is not a factor when Simon does
>> not want it to be.
>>
>> He is also good at partially quoting what someone writes, when he wants to
>> change the message to what he wants to respond to.
>>
>
> No, it means that the Unix developers had a level of insight and
> forward thinking that DEC lacked when the Unix developers chose to
> rewrite Unix in a mostly portable programming language from top to
> bottom long before such ideas became mainstream.
>
> It's a pity that the move to what was essentially a portable version
> of VMS in Pillar 10 years after VMS was created was cancelled. That
> could have _really_ opened up the future use of VMS in the same way
> that the use of a mostly portable language did for Unix.
>
> Simon.
>

Ok, simple question. I posted the following when RSX was being discussed.

"There is a system that runs RSX without overlays. It's called VAX/VMS."

"Don't people ever wonder what DEC people were thinking when they wrote VMS?"

So, now, tell me, how did that get transformed into another rant about Unix?

--
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/2/22 13:21, Simon Clubley wrote:
> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> ?
>>> Fortran and COBOL are not suitable for writing operating system userland tools.
>>
>> Not that I would encourage it as an implementation language these days, but
>> Fortran has been used as such in the past. I believe the Fortran H Extended
>> optimising compiler for the IBM 360/370 was written largely in Fortran H
>> Extended.
>>
>
> You are correct about past use. In the context of the discussion,
> I meant they are not suitable for writing userland tools _today_

Why? Just because there are other languages doesn't obsolete their
use for the task. If that were true we never needed anything after
C was created. After all the first Open Source compilers for many
of the languages in use were just x-to-C translators. P2C, F2C,
heck even GNAT was originally just an Ada to C translator. And some
are still that way and work just fine. GnuCOBOL for example.

> and I gave an example of where I had seen Fortran used in the
> distant past while I was still in school and before before C got
> established outside of Unix.

Ind I have seen Fortran used for this stuff long after C escaped
into the wild. There really is no legitimate reason why languages
Pascal, Modula, Fortran, PL/I, or anything else is unsuitable as
long as it is available on the system and there is a programmer
willing to work with it. After all, in the nd it's all just ones
and zeroes.

bill