Discussion:
[Announce] FreeVMS 0.1.3
(too old to reply)
JKB
2005-03-16 18:18:51 UTC
Permalink
Hello,

New FreeVMS release available at
http://www.systella.fr/~bertrand/FreeVMS

A new bliss compiler is available in this release (bliss 0.0.5).

Regards,

JKB
Tom Linden
2005-03-17 02:23:42 UTC
Permalink
On Wed, 16 Mar 2005 18:18:51 +0000 (UTC), JKB <***@koenigsberg.fr>
wrote:

> Hello,
>
> New FreeVMS release available at
> http://www.systella.fr/~bertrand/FreeVMS
>
> A new bliss compiler is available in this release (bliss 0.0.5).
>
> Regards,
>
> JKB
I note that you are writing it in C, just what we need VMS with buffer
overrun
exploits. If you are serious about writing an OS, use a high-level
language.
Roar Thronæs
2005-03-17 08:47:00 UTC
Permalink
Tom Linden <***@kednos.com> wrote:

: I note that you are writing it in C, just what we need VMS with buffer
: overrun

Is not OpenVMS itself, to an increasing degree, written in C, too?
And neither Bliss nor Macro are secure against buffer overruns,
unless you use mechanisms like descriptors (descriptors and related
functions are builtin in Bliss, but they have to be used explicitly).

: exploits. If you are serious about writing an OS, use a high-level
: language.

You are suggesting C++? :)

--
-Roar Thronæs
Tom Linden
2005-03-17 13:28:07 UTC
Permalink
On Thu, 17 Mar 2005 08:47:00 +0000 (UTC), Roar Thronæs <***@nvg.ntnu.no>
wrote:

> Tom Linden <***@kednos.com> wrote:
>
> : I note that you are writing it in C, just what we need VMS with buffer
> : overrun
>
> Is not OpenVMS itself, to an increasing degree, written in C, too?
> And neither Bliss nor Macro are secure against buffer overruns,
> unless you use mechanisms like descriptors (descriptors and related
> functions are builtin in Bliss, but they have to be used explicitly).
>
> : exploits. If you are serious about writing an OS, use a high-level
> : language.
>
> You are suggesting C++? :)
God no. PL/I.

BTW, did you ever succeed getting emacs ported to VMS?
>
Roar Thronæs
2005-03-17 14:17:18 UTC
Permalink
Tom Linden <***@kednos.com> wrote:

: BTW, did you ever succeed getting emacs ported to VMS?

It was working and I could edit with it, but I have not done any
development in a couple of years, but someone else picked it up and have
improved on it.
There is also someone with Emacs CVS access who have made a couple of
branches for it, so we might actually see something "soon".

--
-Roar Thronæs
Tom Linden
2005-03-17 14:31:37 UTC
Permalink
On Thu, 17 Mar 2005 14:17:18 +0000 (UTC), Roar Thronæs <***@nvg.ntnu.no>
wrote:

> Tom Linden <***@kednos.com> wrote:
>
> : BTW, did you ever succeed getting emacs ported to VMS?
>
> It was working and I could edit with it, but I have not done any
> development in a couple of years, but someone else picked it up and have
> improved on it.
> There is also someone with Emacs CVS access who have made a couple of
> branches for it, so we might actually see something "soon".
>

Do you mean Thi?

Tom
Bob Koehler
2005-03-17 13:36:53 UTC
Permalink
In article <d1bg64$l34$***@orkan.itea.ntnu.no>, Roar =?iso-8859-1?Q?Thron=E6s?= <***@nvg.ntnu.no> writes:
> Tom Linden <***@kednos.com> wrote:

> Is not OpenVMS itself, to an increasing degree, written in C, too?
> And neither Bliss nor Macro are secure against buffer overruns,
> unless you use mechanisms like descriptors (descriptors and related
> functions are builtin in Bliss, but they have to be used explicitly).

While you can set up a buffer overrun in BLISS and you can do
anything in Macro, C puts together a unique environment where a
carefull coder could let just one slip by.
Michael Kraemer
2005-03-17 09:54:01 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
> On Wed, 16 Mar 2005 18:18:51 +0000 (UTC), JKB <***@koenigsberg.fr>
> wrote:
>
> I note that you are writing it in C, just what we need VMS with buffer
> overrun
> exploits.

I just don't get it why coding in plain C should provoke buffer overruns
by default. Use calloc() and friends to allocate as much as you need
rather than assuming fixed max aggregate sizes, and that's (almost) it.

> If you are serious about writing an OS, use a high-level
> language.

Let me guess - PL/I ?
But even in this language you can play tricks with array and string
descriptors, so it's not that much safer inherently.
Anyway, you would need "stringsize" and "subscriptrange"
(or whatever it's called these days) options to benefit from descriptors,
probably not such a good idea for an OS when one looks at the
performance issues.
Tom Linden
2005-03-17 13:32:10 UTC
Permalink
On Thu, 17 Mar 2005 09:54:01 +0000 (UTC), Michael Kraemer
<***@gsi.de> wrote:

> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
> writes:
>> On Wed, 16 Mar 2005 18:18:51 +0000 (UTC), JKB <***@koenigsberg.fr>
>> wrote:
>>
>> I note that you are writing it in C, just what we need VMS with buffer
>> overrun
>> exploits.
>
> I just don't get it why coding in plain C should provoke buffer overruns
> by default. Use calloc() and friends to allocate as much as you need
> rather than assuming fixed max aggregate sizes, and that's (almost) it.
>
>> If you are serious about writing an OS, use a high-level
>> language.
>
> Let me guess - PL/I ?
> But even in this language you can play tricks with array and string
> descriptors, so it's not that much safer inherently.

Show me how you do that.

> Anyway, you would need "stringsize" and "subscriptrange"
> (or whatever it's called these days) options to benefit from descriptors,
> probably not such a good idea for an OS when one looks at the
> performance issues.

I don't think that it would have a significant impact on performance and
in some
sense the performance hit you take you may rightly regard as the price you
pay for
doing it right in the first place. Never heard of a buffer overrun on
VOS, for
example.
Michael Kraemer
2005-03-17 14:27:30 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
> On Thu, 17 Mar 2005 09:54:01 +0000 (UTC), Michael Kraemer
> <***@gsi.de> wrote:
> >
> > Let me guess - PL/I ?
> > But even in this language you can play tricks with array and string
> > descriptors, so it's not that much safer inherently.
>
> Show me how you do that.

Well, my memory is certainly a bit rusty on this one,
and based on IBMs mainframe PL/I more than a decade ago.
But I remember you could pass a subroutine an array,
which is passed as a reference to a descriptor.
If the callee has declared a corresponding POINTER parameter
in its argument listi, you were free to manipulate the
descriptor using that pointer. We used this trick to
deliberately modify the properties of multidim arrays, i.e.
reshape them or even change their dimensionality.
Nice trick, worked perfectly back then, but of course
you exactly had to now what you were doing.

Now of course things might have changed since then,
a stronger prototyping would have prevented that,
as well as a better protection of the descriptors,
but this is part of a particular implementation,
not the language itself.



> > Anyway, you would need "stringsize" and "subscriptrange"
> > (or whatever it's called these days) options to benefit from descriptors,
> > probably not such a good idea for an OS when one looks at the
> > performance issues.
>
> I don't think that it would have a significant impact on performance and
> in some
> sense the performance hit you take you may rightly regard as the price you
> pay for
> doing it right in the first place.


Well, stepping through an array and checking against its bounds
every time an element is accessed could be a performance degrader
if this is a hot spot of a program.


> Never heard of a buffer overrun on
> VOS, for
> example.
>


Never heard of VOS at all :-)
Tom Linden
2005-03-17 14:36:21 UTC
Permalink
On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
<***@gsi.de> wrote:

> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
> writes:
>> On Thu, 17 Mar 2005 09:54:01 +0000 (UTC), Michael Kraemer
>> <***@gsi.de> wrote:
>> >
>> > Let me guess - PL/I ?
>> > But even in this language you can play tricks with array and string
>> > descriptors, so it's not that much safer inherently.
>>
>> Show me how you do that.
>
> Well, my memory is certainly a bit rusty on this one,
> and based on IBMs mainframe PL/I more than a decade ago.
> But I remember you could pass a subroutine an array,
> which is passed as a reference to a descriptor.
> If the callee has declared a corresponding POINTER parameter
> in its argument listi, you were free to manipulate the
> descriptor using that pointer. We used this trick to
> deliberately modify the properties of multidim arrays, i.e.
> reshape them or even change their dimensionality.
> Nice trick, worked perfectly back then, but of course
> you exactly had to now what you were doing.

That is quite different from the usual C buffer overun
playing havoc with the stack
>
> Now of course things might have changed since then,
> a stronger prototyping would have prevented that,
> as well as a better protection of the descriptors,
> but this is part of a particular implementation,
> not the language itself.
>
>
>
>> > Anyway, you would need "stringsize" and "subscriptrange"
>> > (or whatever it's called these days) options to benefit from
>> descriptors,
>> > probably not such a good idea for an OS when one looks at the
>> > performance issues.
>>
>> I don't think that it would have a significant impact on performance and
>> in some
>> sense the performance hit you take you may rightly regard as the price
>> you
>> pay for
>> doing it right in the first place.
>
>
> Well, stepping through an array and checking against its bounds
> every time an element is accessed could be a performance degrader
> if this is a hot spot of a program.
>
>
>> Never heard of a buffer overrun on
>> VOS, for
>> example.
>>
>
>
> Never heard of VOS at all :-)
The OS on Stratus

Quoted from someone at UBS

First some background. Our Stratus application went live in 1990,
now has 750,000 lines of code, and has been maintained by a dozen
people in that time. It processes 5%-10% of all the shares traded
in UK and Europe plus some derivatives amounting to >$10 billion
per day.
Michael Kraemer
2005-03-17 14:56:17 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
> On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
> <***@gsi.de> wrote:
>
> > Nice trick, worked perfectly back then, but of course
> > you exactly had to now what you were doing.
>
> That is quite different from the usual C buffer overun
> playing havoc with the stack
> >

Sure, but the marginal inherent safety advantage PL/I
seems to offer is based on descriptors, and my example
shows that these may be vulnerable themselves.
While we're at it: how about AREAs, these large pieces
of memory, do they have descriptors as well ?
Tom Linden
2005-03-17 15:44:56 UTC
Permalink
On Thu, 17 Mar 2005 14:56:17 +0000 (UTC), Michael Kraemer
<***@gsi.de> wrote:

> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
> writes:
>> On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
>> <***@gsi.de> wrote:
>>
>> > Nice trick, worked perfectly back then, but of course
>> > you exactly had to now what you were doing.
>>
>> That is quite different from the usual C buffer overun
>> playing havoc with the stack
>> >
>
> Sure, but the marginal inherent safety advantage PL/I
> seems to offer is based on descriptors, and my example

It is more than marginal and it is based on more than
descriptors. Now there are certainly ways to get into
trouble with PL/I (e.g. use of SUBSTR pseudo function);
however, as I think Bob K pointed out elsewhere in this thread,
"C puts together a unique environment where a
careful coder could let just one slip by. "
By comparison that could not happen in PL/I


> shows that these may be vulnerable themselves.
> While we're at it: how about AREAs, these large pieces
> of memory, do they have descriptors as well ?

Descriptors will be created if you specify it, or by usage,
but these are transparent to the user. Areas have control
blocks which are used internally by the compiler. PL/I on
VMS is used somewhat differently than on MVS. I would say
that the essential difference is in the level of abstraction.
On MVS you tend to think like an assembler programmer, always
concerned with a variety of control blocks, and therefore the
ability to manipulate them, which is both good and bad.
CONTROLLED variables, for example, have rather complicated
internal houskeeping with linked lists of control blocks
representing the different generations. But none of these
structures are published, and in my view rightly so, since
there is no good reason for the user to manipulate them. If
you look through the PL/I documentaion for VMS, nowhere will you
find a layout of the descriptors, because there is no reason to
manipulate them.
Michael Kraemer
2005-03-21 16:59:13 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
>
> PL/I on
> VMS is used somewhat differently than on MVS. I would say
> that the essential difference is in the level of abstraction.

Huh ? I always thought HL languages should be used somewhat
independent from the platform it runs on.
So the level of abstraction is always the same.

> On MVS you tend to think like an assembler programmer, always
> concerned with a variety of control blocks, and therefore the
> ability to manipulate them, which is both good and bad.

Most PL/I users I remember those days didn't even know
what a control block is.

> CONTROLLED variables, for example, have rather complicated
> internal houskeeping with linked lists of control blocks
> representing the different generations. But none of these
> structures are published, and in my view rightly so, since
> there is no good reason for the user to manipulate them. If
> you look through the PL/I documentaion for VMS, nowhere will you
> find a layout of the descriptors, because there is no reason to
> manipulate them.
>

I don't see anything bad in publishing some of
the innards of the compiler's runtime.
Note that back in the 80's it was common practice
(and sometimes a must) to replace HLL subroutines
with assembler code, eg for reasons of performance.
Nothing wrong with that, provided the vendor supplied
proper information (which IBM did).
Larry Kilgallen
2005-03-21 18:27:29 UTC
Permalink
In article <d1muh1$lnl$***@lnx107.hrz.tu-darmstadt.de>, ***@gsi.de (Michael Kraemer) writes:
> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
>>
>> PL/I on
>> VMS is used somewhat differently than on MVS. I would say
>> that the essential difference is in the level of abstraction.
>
> Huh ? I always thought HL languages should be used somewhat
> independent from the platform it runs on.
> So the level of abstraction is always the same.

Certainly the use of PL/I in Multics was different from that on VMS,
since on Multics it was used to write the innards of the operating
system.

>> On MVS you tend to think like an assembler programmer, always
>> concerned with a variety of control blocks, and therefore the
>> ability to manipulate them, which is both good and bad.
>
> Most PL/I users I remember those days didn't even know
> what a control block is.

So those Tom knows apparently did. Since Tom has been in the PL/I
compiler development business for years, he has lots of opportunity
to be contacted by those PL/I programmers who care about control
blocks. Due to the nature of VMS PL/I, those would be only the
control blocks useful from user mode. FABs, RABs, FIBs etc. come
to mind, and I infer from what Tom says that PL/I programmers on
VMS are mainly using PL/I built-in IO to access RMS.

That seems to be the way VMS programmers for _other_ languages
mostly do things as well.
Michael Kraemer
2005-03-21 19:07:01 UTC
Permalink
In article <***@eisner.encompasserve.org>, ***@SpamCop.net (Larry Kilgallen) writes:
>
> Certainly the use of PL/I in Multics was different from that on VMS,
> since on Multics it was used to write the innards of the operating
> system.

At this point it would be interesting to learn what
"the use of PL/I"
actually means.
BTW: Which language was the PL/I compiler written in ?


> So those Tom knows apparently did. Since Tom has been in the PL/I
> compiler development business for years, he has lots of opportunity
> to be contacted by those PL/I programmers who care about control
> blocks. Due to the nature of VMS PL/I, those would be only the
> control blocks useful from user mode. FABs, RABs, FIBs etc. come
> to mind, and I infer from what Tom says that PL/I programmers on
> VMS are mainly using PL/I built-in IO to access RMS.
>
> That seems to be the way VMS programmers for _other_ languages
> mostly do things as well.


Sorry, I can't follow this logic (if there is any).
The reason to use a HL language for app development
is not to be bothered with low level tasks.
That shouldn't depend too much on the platform one works on.
If users on VMS use(d) mainly PL/I builtin I/O,
then why do they bother with control blocks ?
If PL/I I/O capabilities are weak, then why bother with PL/I at all ?
Tom Linden
2005-03-21 20:06:34 UTC
Permalink
On Mon, 21 Mar 2005 19:07:01 +0000 (UTC), Michael Kraemer
<***@gsi.de> wrote:

> In article <***@eisner.encompasserve.org>,
> ***@SpamCop.net (Larry Kilgallen) writes:
>>
>> Certainly the use of PL/I in Multics was different from that on VMS,
>> since on Multics it was used to write the innards of the operating
>> system.
>
> At this point it would be interesting to learn what
> "the use of PL/I"
> actually means.
Not sure what you are asking, it can certainlly be used for
systems programming as well as applications, and in the former, it
will certainly need access to contol blocks, but what I was referring
to was applications programs that, perhaps for reasons of preceived
efficiency, manipilated such structures
> BTW: Which language was the PL/I compiler written in ?
>
It is written in PL/I.
>
>> So those Tom knows apparently did. Since Tom has been in the PL/I
>> compiler development business for years, he has lots of opportunity
>> to be contacted by those PL/I programmers who care about control
>> blocks. Due to the nature of VMS PL/I, those would be only the
>> control blocks useful from user mode. FABs, RABs, FIBs etc. come
>> to mind, and I infer from what Tom says that PL/I programmers on
>> VMS are mainly using PL/I built-in IO to access RMS.
>>
>> That seems to be the way VMS programmers for _other_ languages
>> mostly do things as well.
>
>
> Sorry, I can't follow this logic (if there is any).
> The reason to use a HL language for app development
> is not to be bothered with low level tasks.
> That shouldn't depend too much on the platform one works on.
> If users on VMS use(d) mainly PL/I builtin I/O,
> then why do they bother with control blocks ?
> If PL/I I/O capabilities are weak, then why bother with PL/I at all ?
Which is not the case, since it has a very rich I/O
>
John Santos
2005-03-18 23:48:07 UTC
Permalink
Michael Kraemer wrote:
> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
>
>>On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
>><***@gsi.de> wrote:
>>
>>
>>>Nice trick, worked perfectly back then, but of course
>>>you exactly had to now what you were doing.
>>
>>That is quite different from the usual C buffer overun
>>playing havoc with the stack
>>
>
> Sure, but the marginal inherent safety advantage PL/I
> seems to offer is based on descriptors, and my example
> shows that these may be vulnerable themselves.
> While we're at it: how about AREAs, these large pieces
> of memory, do they have descriptors as well ?

You can write safe code in C (or macro or...) and you can write
unsafe code in PL/I or BASIC or Java or anything else. The
question isn't "What is possible?" but "What pitfalls are likely
when using the easiest and most natural methods in a given language?"

This is where C loses. To write safe code in C, you have to
bounds-check everything, and verify all string and buffer lengths
and do it religiously.

If all your code is reviewed and you always parameterize *everything*
(so e.g. when someone changes the maximum size of a variable, every
thing uses the correct new size automatically) and you have a good
version control system so everything gets recompiled when it needs
to be, and your subroutines are all prepared to deal with the
memory faults they might get when someone passes a null-terminated
string and forgets to add the null at the end, etc. etc., then you
can use C safely. But isn't it easier to use a language that does
this for you and never forgets to check something, "because it's
just a little 1-byte local temp string and what can possibly go
wrong?"

That being said, I'm not too worried about VMS engineering using C
because DEC and successors have traditionally been very disciplined,
but sometimes things do fall through the cracks.

--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Tom Linden
2005-03-19 00:09:58 UTC
Permalink
On Fri, 18 Mar 2005 23:48:07 GMT, John Santos <***@egh.com> wrote:

> Michael Kraemer wrote:
>> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
>> writes:
>>
>>> On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
>>> <***@gsi.de> wrote:
>>>
>>>
>>>> Nice trick, worked perfectly back then, but of course
>>>> you exactly had to now what you were doing.
>>>
>>> That is quite different from the usual C buffer overun
>>> playing havoc with the stack
>>>
>> Sure, but the marginal inherent safety advantage PL/I
>> seems to offer is based on descriptors, and my example
>> shows that these may be vulnerable themselves.
>> While we're at it: how about AREAs, these large pieces
>> of memory, do they have descriptors as well ?
>
> You can write safe code in C (or macro or...) and you can write
> unsafe code in PL/I or BASIC or Java or anything else. The
> question isn't "What is possible?" but "What pitfalls are likely
> when using the easiest and most natural methods in a given language?"
>
> This is where C loses. To write safe code in C, you have to
> bounds-check everything, and verify all string and buffer lengths
> and do it religiously.
>
> If all your code is reviewed and you always parameterize *everything*
> (so e.g. when someone changes the maximum size of a variable, every
> thing uses the correct new size automatically) and you have a good
> version control system so everything gets recompiled when it needs
> to be, and your subroutines are all prepared to deal with the
> memory faults they might get when someone passes a null-terminated
> string and forgets to add the null at the end, etc. etc., then you
> can use C safely. But isn't it easier to use a language that does
> this for you and never forgets to check something, "because it's
> just a little 1-byte local temp string and what can possibly go
> wrong?"
>
> That being said, I'm not too worried about VMS engineering using C
> because DEC and successors have traditionally been very disciplined,
> but sometimes things do fall through the cracks.

Probably true. Of course, it is three times as much work
>
Dave Froble
2005-03-19 02:26:33 UTC
Permalink
John Santos wrote:
> Michael Kraemer wrote:
>
>> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
>> writes:
>>
>>> On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
>>> <***@gsi.de> wrote:
>>>
>>>
>>>> Nice trick, worked perfectly back then, but of course
>>>> you exactly had to now what you were doing.
>>>
>>>
>>> That is quite different from the usual C buffer overun
>>> playing havoc with the stack
>>>
>>
>> Sure, but the marginal inherent safety advantage PL/I
>> seems to offer is based on descriptors, and my example
>> shows that these may be vulnerable themselves.
>> While we're at it: how about AREAs, these large pieces
>> of memory, do they have descriptors as well ?
>
>
> You can write safe code in C (or macro or...) and you can write
> unsafe code in PL/I or BASIC or Java or anything else. The
> question isn't "What is possible?" but "What pitfalls are likely
> when using the easiest and most natural methods in a given language?"
>
> This is where C loses. To write safe code in C, you have to
> bounds-check everything, and verify all string and buffer lengths
> and do it religiously.
>
> If all your code is reviewed and you always parameterize *everything*
> (so e.g. when someone changes the maximum size of a variable, every
> thing uses the correct new size automatically) and you have a good
> version control system so everything gets recompiled when it needs
> to be, and your subroutines are all prepared to deal with the
> memory faults they might get when someone passes a null-terminated
> string and forgets to add the null at the end, etc. etc., then you
> can use C safely. But isn't it easier to use a language that does
> this for you and never forgets to check something, "because it's
> just a little 1-byte local temp string and what can possibly go
> wrong?"
>
> That being said, I'm not too worried about VMS engineering using C
> because DEC and successors have traditionally been very disciplined,
> but sometimes things do fall through the cracks.
>

My perspective is, my job is to come up with the ideas, and the
computer's job is to do the grunt work. If I have to do the grunt work,
then there are fewer ideas, applications, solutions ....
Larry Kilgallen
2005-03-19 03:34:48 UTC
Permalink
In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com> writes:

> This is where C loses. To write safe code in C, you have to
> bounds-check everything, and verify all string and buffer lengths
> and do it religiously.
>
> If all your code is reviewed and you always parameterize *everything*
> (so e.g. when someone changes the maximum size of a variable, every
> thing uses the correct new size automatically) and you have a good
> version control system so everything gets recompiled when it needs
> to be, and your subroutines are all prepared to deal with the
> memory faults they might get when someone passes a null-terminated
> string and forgets to add the null at the end, etc. etc., then you
> can use C safely. But isn't it easier to use a language that does
> this for you and never forgets to check something, "because it's
> just a little 1-byte local temp string and what can possibly go
> wrong?"

Ultimately, the problem is how does one _prove_ that all the proper
steps were taken in a giant program ?

Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel
for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
in order to support mathematical proof of code correctness.
Bill Gunshannon
2005-03-19 14:07:40 UTC
Permalink
In article <***@eisner.encompasserve.org>,
***@SpamCop.net (Larry Kilgallen) writes:
> In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com> writes:
>
>> This is where C loses. To write safe code in C, you have to
>> bounds-check everything, and verify all string and buffer lengths
>> and do it religiously.
>>
>> If all your code is reviewed and you always parameterize *everything*
>> (so e.g. when someone changes the maximum size of a variable, every
>> thing uses the correct new size automatically) and you have a good
>> version control system so everything gets recompiled when it needs
>> to be, and your subroutines are all prepared to deal with the
>> memory faults they might get when someone passes a null-terminated
>> string and forgets to add the null at the end, etc. etc., then you
>> can use C safely. But isn't it easier to use a language that does
>> this for you and never forgets to check something, "because it's
>> just a little 1-byte local temp string and what can possibly go
>> wrong?"
>
> Ultimately, the problem is how does one _prove_ that all the proper
> steps were taken in a giant program ?
>
> Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel
> for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
> in order to support mathematical proof of code correctness.

And, did the code reviews include looking at the source for the Pascal
compiler as well? If not, then you had no "mathematical proof of code
correctness". Some things can not be "proven" to any real degree off
certainty.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Tom Linden
2005-03-19 15:11:49 UTC
Permalink
On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:

> In article <***@eisner.encompasserve.org>,
> ***@SpamCop.net (Larry Kilgallen) writes:
>> In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com>
>> writes:
>>
>>> This is where C loses. To write safe code in C, you have to
>>> bounds-check everything, and verify all string and buffer lengths
>>> and do it religiously.
>>>
>>> If all your code is reviewed and you always parameterize *everything*
>>> (so e.g. when someone changes the maximum size of a variable, every
>>> thing uses the correct new size automatically) and you have a good
>>> version control system so everything gets recompiled when it needs
>>> to be, and your subroutines are all prepared to deal with the
>>> memory faults they might get when someone passes a null-terminated
>>> string and forgets to add the null at the end, etc. etc., then you
>>> can use C safely. But isn't it easier to use a language that does
>>> this for you and never forgets to check something, "because it's
>>> just a little 1-byte local temp string and what can possibly go
>>> wrong?"
>>
>> Ultimately, the problem is how does one _prove_ that all the proper
>> steps were taken in a giant program ?
>>
>> Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel
>> for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
>> in order to support mathematical proof of code correctness.
>
> And, did the code reviews include looking at the source for the Pascal
> compiler as well? If not, then you had no "mathematical proof of code
> correctness". Some things can not be "proven" to any real degree off
> certainty.

There is still the Trojan horse issue as we have discussed before
http://www.acm.org/classics/sep95/ by Ken Thompson
>
> bill
>
Bill Gunshannon
2005-03-19 16:50:26 UTC
Permalink
In article <***@hyrrokkin>,
"Tom Linden" <***@kednos.com> writes:
> On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:
>
>> In article <***@eisner.encompasserve.org>,
>> ***@SpamCop.net (Larry Kilgallen) writes:
>>> In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com>
>>> writes:
>>>
>>>> This is where C loses. To write safe code in C, you have to
>>>> bounds-check everything, and verify all string and buffer lengths
>>>> and do it religiously.
>>>>
>>>> If all your code is reviewed and you always parameterize *everything*
>>>> (so e.g. when someone changes the maximum size of a variable, every
>>>> thing uses the correct new size automatically) and you have a good
>>>> version control system so everything gets recompiled when it needs
>>>> to be, and your subroutines are all prepared to deal with the
>>>> memory faults they might get when someone passes a null-terminated
>>>> string and forgets to add the null at the end, etc. etc., then you
>>>> can use C safely. But isn't it easier to use a language that does
>>>> this for you and never forgets to check something, "because it's
>>>> just a little 1-byte local temp string and what can possibly go
>>>> wrong?"
>>>
>>> Ultimately, the problem is how does one _prove_ that all the proper
>>> steps were taken in a giant program ?
>>>
>>> Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel
>>> for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
>>> in order to support mathematical proof of code correctness.
>>
>> And, did the code reviews include looking at the source for the Pascal
>> compiler as well? If not, then you had no "mathematical proof of code
>> correctness". Some things can not be "proven" to any real degree off
>> certainty.
>
> There is still the Trojan horse issue as we have discussed before
> http://www.acm.org/classics/sep95/ by Ken Thompson

That has already been mentioned here inthe recent past but I
also meant it is possible for the compiler to make mistakes
too. And the more complex the language the more possible it
becomes for an error to sit silently by waiting for the right
combination of code to bring it to the surface.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Karsten Nyblad
2005-03-20 09:32:27 UTC
Permalink
Bill Gunshannon wrote:
> In article <***@hyrrokkin>,
> "Tom Linden" <***@kednos.com> writes:
>
>>On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:
>>
>>
>>>In article <***@eisner.encompasserve.org>,
>>> ***@SpamCop.net (Larry Kilgallen) writes:
>>>
>>>>In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com>
>>>>writes:
>>>>
>>>>
>>>>>This is where C loses. To write safe code in C, you have to
>>>>>bounds-check everything, and verify all string and buffer lengths
>>>>>and do it religiously.
>>>>>
>>>>>If all your code is reviewed and you always parameterize *everything*
>>>>>(so e.g. when someone changes the maximum size of a variable, every
>>>>>thing uses the correct new size automatically) and you have a good
>>>>>version control system so everything gets recompiled when it needs
>>>>>to be, and your subroutines are all prepared to deal with the
>>>>>memory faults they might get when someone passes a null-terminated
>>>>>string and forgets to add the null at the end, etc. etc., then you
>>>>>can use C safely. But isn't it easier to use a language that does
>>>>>this for you and never forgets to check something, "because it's
>>>>>just a little 1-byte local temp string and what can possibly go
>>>>>wrong?"
>>>>
>>>>Ultimately, the problem is how does one _prove_ that all the proper
>>>>steps were taken in a giant program ?
>>>>
>>>>Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel
>>>>for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
>>>>in order to support mathematical proof of code correctness.
>>>
>>>And, did the code reviews include looking at the source for the Pascal
>>>compiler as well? If not, then you had no "mathematical proof of code
>>>correctness". Some things can not be "proven" to any real degree off
>>>certainty.
>>
>>There is still the Trojan horse issue as we have discussed before
>>http://www.acm.org/classics/sep95/ by Ken Thompson
>
>
> That has already been mentioned here inthe recent past but I
> also meant it is possible for the compiler to make mistakes
> too. And the more complex the language the more possible it
> becomes for an error to sit silently by waiting for the right
> combination of code to bring it to the surface.
>
> bill

Actually this goes beyond the compiler. You also have to prove the
correctness of the computer, including firmware and microcode. Let us
assume that you have actually proved that. Then you have to ensure that
the computer always work correctly no matter what, e.g., there may not
be a single gate in some chips, that fails every 10**20 times.

Such proofs are so big that no human can carry them out without errors.
Thus you have to have computer programs to check the proofs and then
you have to prove the correctness of the theorem provers. But Kurt
Gödel proved in 1931 that in order to prove the consistency of a logic
you need a more powerful logic. There are theorem provers that are
build to have a small trusted core that does the logical inferences, but
even those small cores have been subject to errors.

Then there is an other issue. Somehow you have to convert your
requirement specification into logical formals before you can attempt to
prove that these formulas are theorems, but there is no 100% safe way of
to carry out that conversion. To me that is a much more severe problem
than the problem of the correctness of the tools. Besides, once we have
a method for developing correct programs, that method can also be
applied to compilers and other tools.

However, people tend to say that because there is no way of making the
perfect system to guarantee the correctness of computer systems, the
idea should be abandoned. I do not think so. We have to live with
technology that fails. I cannot be 100% sure that the building, I am
sitting in while writing this, will not collapse. I cannot be sure that
the computer screen in front of me will not implode and spray me with
glass splinter. Why not use these methods an get the orders of
magnitude of better correctness that could most likely gained that way?
Tom Linden
2005-03-20 15:28:39 UTC
Permalink
On Sun, 20 Mar 2005 10:32:27 +0100, Karsten Nyblad <***@nospam.nospam>
wrote:

> Bill Gunshannon wrote:
>> In article <***@hyrrokkin>,
>> "Tom Linden" <***@kednos.com> writes:
>>
>>> On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:
>>>
>>>
>>>> In article <***@eisner.encompasserve.org>,
>>>> ***@SpamCop.net (Larry Kilgallen) writes:
>>>>
>>>>> In article <XMJ_d.4266$***@trnddc06>, John Santos
>>>>> <***@egh.com> writes:
>>>>>
>>>>>
>>>>>> This is where C loses. To write safe code in C, you have to
>>>>>> bounds-check everything, and verify all string and buffer lengths
>>>>>> and do it religiously.
>>>>>>
>>>>>> If all your code is reviewed and you always parameterize
>>>>>> *everything*
>>>>>> (so e.g. when someone changes the maximum size of a variable, every
>>>>>> thing uses the correct new size automatically) and you have a good
>>>>>> version control system so everything gets recompiled when it needs
>>>>>> to be, and your subroutines are all prepared to deal with the
>>>>>> memory faults they might get when someone passes a null-terminated
>>>>>> string and forgets to add the null at the end, etc. etc., then you
>>>>>> can use C safely. But isn't it easier to use a language that does
>>>>>> this for you and never forgets to check something, "because it's
>>>>>> just a little 1-byte local temp string and what can possibly go
>>>>>> wrong?"
>>>>>
>>>>> Ultimately, the problem is how does one _prove_ that all the proper
>>>>> steps were taken in a giant program ?
>>>>>
>>>>> Looking at a not-so-giant program, when DEC wrote an A1 Security
>>>>> Kernel
>>>>> for the high-end VAX, they wrote it in Pascal, with no RTL allowed,
>>>>> in order to support mathematical proof of code correctness.
>>>>
>>>> And, did the code reviews include looking at the source for the Pascal
>>>> compiler as well? If not, then you had no "mathematical proof of code
>>>> correctness". Some things can not be "proven" to any real degree off
>>>> certainty.
>>>
>>> There is still the Trojan horse issue as we have discussed before
>>> http://www.acm.org/classics/sep95/ by Ken Thompson
>> That has already been mentioned here inthe recent past but I
>> also meant it is possible for the compiler to make mistakes
>> too. And the more complex the language the more possible it
>> becomes for an error to sit silently by waiting for the right
>> combination of code to bring it to the surface.
>> bill
>
> Actually this goes beyond the compiler. You also have to prove the
> correctness of the computer, including firmware and microcode. Let us
> assume that you have actually proved that. Then you have to ensure that
> the computer always work correctly no matter what, e.g., there may not
> be a single gate in some chips, that fails every 10**20 times.
>
> Such proofs are so big that no human can carry them out without errors.
> Thus you have to have computer programs to check the proofs and then
> you have to prove the correctness of the theorem provers. But Kurt
> Gödel proved in 1931 that in order to prove the consistency of a logic
> you need a more powerful logic. There are theorem provers that are
> build to have a small trusted core that does the logical inferences, but
> even those small cores have been subject to errors.
>
> Then there is an other issue. Somehow you have to convert your
> requirement specification into logical formals before you can attempt to
> prove that these formulas are theorems, but there is no 100% safe way of
> to carry out that conversion. To me that is a much more severe problem
> than the problem of the correctness of the tools. Besides, once we have
> a method for developing correct programs, that method can also be
> applied to compilers and other tools.
>
> However, people tend to say that because there is no way of making the
> perfect system to guarantee the correctness of computer systems, the
> idea should be abandoned. I do not think so. We have to live with
> technology that fails. I cannot be 100% sure that the building, I am
> sitting in while writing this, will not collapse. I cannot be sure that
> the computer screen in front of me will not implode and spray me with
> glass splinter. Why not use these methods an get the orders of
> magnitude of better correctness that could most likely gained that way?

Somewhat reminiscent of Hilbert's response to the Russell Paradox.
http://plato.stanford.edu/entries/russell-paradox/
Tom Linden
2005-03-19 15:16:37 UTC
Permalink
On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:

> And, did the code reviews include looking at the source for the Pascal
> compiler as well? If not, then you had no "mathematical proof of code
> correctness". Some things can not be "proven" to any real degree off
> certainty.

Follow on story.

http://www.dmst.aueb.gr/dds/pubs/jrnl/2003-CACM-Reflections2/html/reflections2.html
Michael Kraemer
2005-03-21 19:28:06 UTC
Permalink
In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com> writes:
> This is where C loses. To write safe code in C, you have to
> bounds-check everything, and verify all string and buffer lengths
> and do it religiously.

Bashing C for allowing buffer overruns is missing the point, IMHO.
Buffer overruns detectable only at run time may occur
in *any* language, it's just the penalty which is different.
However, I don't see the real advantage of eg a PL/I program
(let alone a complete OS) crashing with a "Subscriptrange condition raised"
over a C program simply segfaulting.
Writing beyond an array's boundaries is
incorrect in *any* language, so you should not bash the
language but the programmer's education or working style.
It's as simple as this: ensure you do not write over areas you do not own.

> If all your code is reviewed and you always parameterize *everything*
> (so e.g. when someone changes the maximum size of a variable, every
> thing uses the correct new size automatically) and you have a good
> version control system so everything gets recompiled when it needs
> to be,

All this you would have to do with other languages as well.
Tom Linden
2005-03-21 20:27:06 UTC
Permalink
On Mon, 21 Mar 2005 19:28:06 +0000 (UTC), Michael Kraemer
<***@gsi.de> wrote:

> In article <XMJ_d.4266$***@trnddc06>, John Santos <***@egh.com>
> writes:
>> This is where C loses. To write safe code in C, you have to
>> bounds-check everything, and verify all string and buffer lengths
>> and do it religiously.
>
> Bashing C for allowing buffer overruns is missing the point, IMHO.
> Buffer overruns detectable only at run time may occur
> in *any* language, it's just the penalty which is different.
> However, I don't see the real advantage of eg a PL/I program
> (let alone a complete OS) crashing with a "Subscriptrange condition
> raised"
But there is a very big difference, In PL/I you have the opportunity to
write a fail-safe program, for example consider the snippet, located in
some invocation,

ON STRINGRANGE BEGIN;
if oncode() = PLI$_STRRANGE then do;
...
end;
else ifoncode() = PLI$_SUBSTR2 then do;
...
end;
else ifoncode() = PLI$_SUBSTR3 then do;
...
end;
else ifoncode() = PLI$_BIFSTAPOS then do;
...
end;
end;

Of course it doesn't mean you will be able to do it, but you have the
opportunity. This may not have been the best example for recovery, more
likely you would use it for I/O operations, fault keys and the like.

> over a C program simply segfaulting.
> Writing beyond an array's boundaries is
> incorrect in *any* language, so you should not bash the
> language but the programmer's education or working style.
> It's as simple as this: ensure you do not write over areas you do not
> own.
I agree that there are safer ways of writing C, e.g. use strn* instead
of str* functions, but you may still clobber that stack. Will it happen
to C code written by a good programmer? Probably not, but it could.
>
>> If all your code is reviewed and you always parameterize *everything*
>> (so e.g. when someone changes the maximum size of a variable, every
>> thing uses the correct new size automatically) and you have a good
>> version control system so everything gets recompiled when it needs
>> to be,
>
> All this you would have to do with other languages as well.
Michael Kraemer
2005-03-21 19:39:43 UTC
Permalink
> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
> writes:
>> On Thu, 17 Mar 2005 09:54:01 +0000 (UTC), Michael Kraemer
>> <***@gsi.de> wrote:
>> We used this trick to
>> deliberately modify the properties of multidim arrays,

> That is quite different from the usual C buffer overun
> playing havoc with the stack

Sure, but it shows that with intimate knowledge one
can fool around even in PL/I. Likewise one needs intimate
knowlegde to maliciously exploit C buffer overruns.
Bob Koehler
2005-03-17 13:37:51 UTC
Permalink
In article <d1bk3p$ujq$***@lnx107.hrz.tu-darmstadt.de>, ***@gsi.de (Michael Kraemer) writes:
>
> I just don't get it why coding in plain C should provoke buffer overruns
> by default. Use calloc() and friends to allocate as much as you need
> rather than assuming fixed max aggregate sizes, and that's (almost) it.
>

It's because buffers in C default to stack storage and C I/O routines
mostly have no idea how long the buffer is.
Michael Kraemer
2005-03-17 14:12:29 UTC
Permalink
In article <***@eisner.encompasserve.org>, ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
> It's because buffers in C default to stack storage and C I/O routines
> mostly have no idea how long the buffer is.
>

huh ?
the functions I use, such as

fgets( pcBuf, ncBuf, fp )

fread( buffer, 1, length, fp );

read ( handle, addr, length );

all have proper length specified.

And buffers in C have the storage class
the programmer wishes, stack, static or calloc'ed.
Bob Koehler
2005-03-17 18:13:20 UTC
Permalink
In article <d1c38d$49g$***@lnx107.hrz.tu-darmstadt.de>, ***@gsi.de (Michael Kraemer) writes:
>
> huh ?
> the functions I use, such as
>
> fgets( pcBuf, ncBuf, fp )
>
> fread( buffer, 1, length, fp );
>
> read ( handle, addr, length );
>
> all have proper length specified.
>
> And buffers in C have the storage class
> the programmer wishes, stack, static or calloc'ed.

Yes, if you restrict yourself to functions which DO know the length
of the buffer you definitely reduce the likelyhood of buffer
overrun.

And if you don't let your buffers be auto then you reduce the
likelyhood that a buffer overrun will lead to a successful exploit.

But if you program in other languages it can be hard to code a
buffer overrun, which is the way it should be.
Thierry Dussuet
2005-03-17 18:53:04 UTC
Permalink
On 2005-03-17, Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
> In article <d1c38d$49g$***@lnx107.hrz.tu-darmstadt.de>, ***@gsi.de (Michael Kraemer) writes:
>>
>> huh ?
>> the functions I use, such as
>>
>> fgets( pcBuf, ncBuf, fp )
>>
>> fread( buffer, 1, length, fp );
>>
>> read ( handle, addr, length );
>>
>> all have proper length specified.
>>
>> And buffers in C have the storage class
>> the programmer wishes, stack, static or calloc'ed.
>
> Yes, if you restrict yourself to functions which DO know the length
> of the buffer you definitely reduce the likelyhood of buffer
> overrun.

Well, then it's easy: You take a baseball bat and use the following algorithm
for every C coder who doesn't use them:
1. Hit him on the head.
2. Ask him to promise never to do this ever ever ever again --
If he promises, go to point 3.
Else, go back to 1.
3. Hit him some more times on the head to be sure.

(n.b. You are allowed to use something else than a baseball bat for repetitive
cases)

Thierry
Bill Gunshannon
2005-03-18 00:21:45 UTC
Permalink
In article <5IVLsW$***@eisner.encompasserve.org>,
***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
> But if you program in other languages it can be hard to code a
> buffer overrun, which is the way it should be.

But if you program in other languages it can also be hard to code
the task at hand. Ever try to code an OS in Fortran or COBOL?
(Although COBOL is also not immune to buffer overrun.) And we
were talking about writting an OS.

I will admit that PLI would probably be a good candidate except for
the dearth of programmers who actually know it well enough to write
or maintain an OS.

I am still waiting for someone to take on the project of re-writing
Unix in something other than C in order to prove what a tremendous
improvement it would be. (I have had many people suggest that
Unix would be so much better if it were written in Ada but no one
ever takes on the task. Personally, I don't believe it.)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@instantwhip.com
2005-03-18 00:48:49 UTC
Permalink
no matter how you rewrite unix ... it still comes out garbage ... :)
Bill Gunshannon
2005-03-18 01:40:48 UTC
Permalink
In article <***@g14g2000cwa.googlegroups.com>,
***@instantwhip.com writes:
> no matter how you rewrite unix ... it still comes out garbage ... :)
>

Bob, go jump in a lake.

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Dave Froble
2005-03-18 04:54:31 UTC
Permalink
***@instantwhip.com wrote:
> no matter how you rewrite unix ... it still comes out garbage ... :)
>

boob shows his ignorance again.
Tom Linden
2005-03-18 01:01:30 UTC
Permalink
On 18 Mar 2005 00:21:45 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:

> In article <5IVLsW$***@eisner.encompasserve.org>,
> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>> But if you program in other languages it can be hard to code a
>> buffer overrun, which is the way it should be.
>
> But if you program in other languages it can also be hard to code
> the task at hand. Ever try to code an OS in Fortran or COBOL?
> (Although COBOL is also not immune to buffer overrun.) And we
> were talking about writting an OS.

A good portion of Primos was in Fortran.
>
> I will admit that PLI would probably be a good candidate except for
> the dearth of programmers who actually know it well enough to write
> or maintain an OS.
>
> I am still waiting for someone to take on the project of re-writing
> Unix in something other than C in order to prove what a tremendous
> improvement it would be. (I have had many people suggest that
> Unix would be so much better if it were written in Ada but no one
> ever takes on the task. Personally, I don't believe it.)

About 20 years ago I rewrote portions of the BSD4.3 kernel in PL/I
that had previously been in assembler!

Well there are probably 25 PL/I programmers for every Ada programmer,
if not more.
>
> bill
>
Bill Gunshannon
2005-03-18 01:50:58 UTC
Permalink
In article <***@hyrrokkin>,
"Tom Linden" <***@kednos.com> writes:
> On 18 Mar 2005 00:21:45 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:
>
>> In article <5IVLsW$***@eisner.encompasserve.org>,
>> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>
>>> But if you program in other languages it can be hard to code a
>>> buffer overrun, which is the way it should be.
>>
>> But if you program in other languages it can also be hard to code
>> the task at hand. Ever try to code an OS in Fortran or COBOL?
>> (Although COBOL is also not immune to buffer overrun.) And we
>> were talking about writting an OS.
>
> A good portion of Primos was in Fortran.

Not any significant portions of code that are unique to
operating systems. Of course, none of it was in C, which
should make a lot of people here happy. Actually, like
VMS, it was written in a collection of languages including
native assembler.

>>
>> I will admit that PLI would probably be a good candidate except for
>> the dearth of programmers who actually know it well enough to write
>> or maintain an OS.
>>
>> I am still waiting for someone to take on the project of re-writing
>> Unix in something other than C in order to prove what a tremendous
>> improvement it would be. (I have had many people suggest that
>> Unix would be so much better if it were written in Ada but no one
>> ever takes on the task. Personally, I don't believe it.)
>
> About 20 years ago I rewrote portions of the BSD4.3 kernel in PL/I
> that had previously been in assembler!

Like I said above, I would love to see Unix re-written in some other
language. It might be fun to write it in PLI. It is probably the
best language to do the job in if your not going to use C.

>
> Well there are probably 25 PL/I programmers for every Ada programmer,
> if not more.

Actually, I would expect it to be the other way around (depending on
your definition of "programmer"). Why do I say that? Because while
we stopped making PLI programmers a long time ago lots of schools,
my own included, spent a number of years not so long ago turning out
Ada programmers. And then you have all those people that groups like
DOD turned into Ada Programmers when they thought it would take over
the computing world.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
JF Mezei
2005-03-18 03:35:55 UTC
Permalink
Bill Gunshannon wrote:
> operating systems. Of course, none of it was in C, which
> should make a lot of people here happy. Actually, like
> VMS, it was written in a collection of languages including
> native assembler.


Funny how people would balk at the use of C due to buffer overflows, but
think it OK to use assembler.
Bill Gunshannon
2005-03-18 04:37:27 UTC
Permalink
In article <***@teksavvy.com>,
JF Mezei <***@teksavvy.com> writes:
> Bill Gunshannon wrote:
>> operating systems. Of course, none of it was in C, which
>> should make a lot of people here happy. Actually, like
>> VMS, it was written in a collection of languages including
>> native assembler.
>
>
> Funny how people would balk at the use of C due to buffer overflows, but
> think it OK to use assembler.

Had it been available I would imagine C would have been used. But,
the first C Compiler for Primos I saw was written by Garth Conboy
and we didn't see it til Primos was already at Rev 19. Who knows,
if it had been it might have led to doing somethings differently
that would have avoided many of the things that made Primos as
incompatable with the Unix Freeware world as VMS is. Primos was
a nice OS. It could have been really great had it been given the
chance to mature. It used a security model that would probably
have been much more to the liking of people here.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Tom Linden
2005-03-18 13:16:23 UTC
Permalink
On 18 Mar 2005 04:37:27 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:

> In article <***@teksavvy.com>,
> JF Mezei <***@teksavvy.com> writes:
>> Bill Gunshannon wrote:
>>> operating systems. Of course, none of it was in C, which
>>> should make a lot of people here happy. Actually, like
>>> VMS, it was written in a collection of languages including
>>> native assembler.
>>
>>
>> Funny how people would balk at the use of C due to buffer overflows, but
>> think it OK to use assembler.
>
> Had it been available I would imagine C would have been used. But,
> the first C Compiler for Primos I saw was written by Garth Conboy
> and we didn't see it til Primos was already at Rev 19. Who knows,
> if it had been it might have led to doing somethings differently
> that would have avoided many of the things that made Primos as
> incompatable with the Unix Freeware world as VMS is. Primos was
> a nice OS. It could have been really great had it been given the
> chance to mature. It used a security model that would probably
> have been much more to the liking of people here.

IIRC, garth wrote that in PL/I (or it may have been PLP at that point),
at least inused the PL/I backend that was common to all of the compilers
on Primos. Prime was full of ex-Multicians starting with Poduska.
>
> bill
>
Bob Koehler
2005-03-18 14:20:39 UTC
Permalink
In article <***@teksavvy.com>, JF Mezei <***@teksavvy.com> writes:
>
> Funny how people would balk at the use of C due to buffer overflows, but
> think it OK to use assembler.

Few assembler programmers depend on the C I/O routines, or forget
how long they made thier buffers.
JF Mezei
2005-03-18 17:00:38 UTC
Permalink
Bob Koehler wrote:
> > Funny how people would balk at the use of C due to buffer overflows, but
> > think it OK to use assembler.
>
> Few assembler programmers depend on the C I/O routines, or forget
> how long they made thier buffers.

And a good C programmer on VMS will use the native VMS way of doing
things. C itself isn't a bad language. It is the Unix run time which is bad.

If you are writing system services or kernel mode stuff, you can't use
the C unix RTL anyways, so you can code very robust C.

In fact, I would say that a C programme that has the discipline to code
defensively is better than some programmer that uses a lnaguage that
hides all the buffer checking code under the table with the programmer
never spotting techniques he uises which are not inherently safe.

This under the table boundary checking is like a safety net for
acrobats. The real goal is not to fall. If you fall and the safety net
catches you and you don't even notice the initial failure (your
falling), that is also a problem.
Bob Koehler
2005-03-18 18:24:15 UTC
Permalink
In article <***@teksavvy.com>, JF Mezei <***@teksavvy.com> writes:
> This under the table boundary checking is like a safety net for
> acrobats. The real goal is not to fall. If you fall and the safety net
> catches you and you don't even notice the initial failure (your
> falling), that is also a problem.

Using a safety net, and knowing you're using a safety net, is better
than falling without a safety net.
Dave Froble
2005-03-18 04:53:36 UTC
Permalink
Bill Gunshannon wrote:
> In article <5IVLsW$***@eisner.encompasserve.org>,
> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
>> But if you program in other languages it can be hard to code a
>> buffer overrun, which is the way it should be.
>
>
> But if you program in other languages it can also be hard to code
> the task at hand. Ever try to code an OS in Fortran or COBOL?
> (Although COBOL is also not immune to buffer overrun.) And we
> were talking about writting an OS.

Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
times you need to do something that the language isn't suited for. My
own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
re-entrant code, threads, and such, things an OS demands. That's a
compiler issue, I think, and surmountable. Only problem is, how many
types of system will the compiler run on?

> I will admit that PLI would probably be a good candidate except for
> the dearth of programmers who actually know it well enough to write
> or maintain an OS.

I don't know PL/I, but I'm aware that it's been used for system
programming on multiple occasions, so I'd give it credit for being suitable.

> I am still waiting for someone to take on the project of re-writing
> Unix in something other than C in order to prove what a tremendous
> improvement it would be. (I have had many people suggest that
> Unix would be so much better if it were written in Ada but no one
> ever takes on the task. Personally, I don't believe it.)

To what purpose? It could only be built on systems that support the
selected language. It seems that C is supported in some manner on
almost everything still being built. While I don't like it, it's reality.

I still think many OS tasks are best written in assembler, but that's
not real portable, even VAX MACRO-32, which has made it to 3
architechures. People willing to accept the job of writing in assembler
aren't real numerous either.

Dave
Larry Kilgallen
2005-03-18 12:22:10 UTC
Permalink
In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
> Bill Gunshannon wrote:
>> In article <5IVLsW$***@eisner.encompasserve.org>,
>> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>>> But if you program in other languages it can be hard to code a
>>> buffer overrun, which is the way it should be.
>>
>>
>> But if you program in other languages it can also be hard to code
>> the task at hand. Ever try to code an OS in Fortran or COBOL?


Did you ever try to write a payroll package in Scheme ? Certainly
that is a higher level language, but it is necessary to choose the
_right_ higher level language.

> Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
> times you need to do something that the language isn't suited for. My
> own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
> re-entrant code, threads, and such, things an OS demands.

But other high level languages are quite capable of that.

>> I will admit that PLI would probably be a good candidate except for
>> the dearth of programmers who actually know it well enough to write
>> or maintain an OS.

Nobody should attempt to write an operating system using programmers
who are too dumb to learn another language. A few lead developers
with extensive experience is a good idea, but those are available
if you are willing to pay the price. Nobody should attempt to write
an operating system on the cheap.

> I don't know PL/I, but I'm aware that it's been used for system
> programming on multiple occasions, so I'd give it credit for being suitable.

PL/I was the implementation language for Multics, the grand-daddy of
operating system security models. Where do people think the name
"Unix" came from ? Certainly none of the developers had a dog named
Unix.

>> I am still waiting for someone to take on the project of re-writing
>> Unix in something other than C in order to prove what a tremendous
>> improvement it would be. (I have had many people suggest that
>> Unix would be so much better if it were written in Ada but no one
>> ever takes on the task. Personally, I don't believe it.)

"Unix" has a definition inextricably intertwined with that of "C",
full of null-terminated strings, pointer arithmetic and other such
practices which are (properly) forbidden in reliable software.

> I still think many OS tasks are best written in assembler, but that's
> not real portable, even VAX MACRO-32, which has made it to 3
> architechures.

Really low level operating system code, like memory management, does
not need to be portable since it depends on the hardware.

VMS would be better off if more of it were written in Bliss and less
in Macro, but that is not what compiler availability permitted. Note
that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
Channel) linkage.

> People willing to accept the job of writing in assembler
> aren't real numerous either.

While I don't agree with much use of assembly language in this day
and age, operating systems should not be written on the cheap.
Tom Linden
2005-03-18 13:31:07 UTC
Permalink
On 18 Mar 2005 06:22:10 -0600, Larry Kilgallen <***@SpamCop.net>
wrote:

> In article <***@corp.supernews.com>, Dave Froble
> <***@tsoft-inc.com> writes:
>> Bill Gunshannon wrote:
>>> In article <5IVLsW$***@eisner.encompasserve.org>,
>>> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>
>>>> But if you program in other languages it can be hard to code a
>>>> buffer overrun, which is the way it should be.
>>>
>>>
>>> But if you program in other languages it can also be hard to code
>>> the task at hand. Ever try to code an OS in Fortran or COBOL?
>
>
> Did you ever try to write a payroll package in Scheme ? Certainly
> that is a higher level language, but it is necessary to choose the
> _right_ higher level language.
>

BTW, speaking of choosing the right language for the job, Wim de Boer's
post on his
pascal problem looks to me as if it would have been easier in PL/I since it
supports entry variable and a generic type. A second example, comes from
UBS
who wrote their code in Cobol ca. 1990 and now supports about 5-10% of all
shares traded in Europe, and because cobol lacks a scaled fixed decimal
appropriate precision, they used comp-2 (same as G-Float)which means that
they have
add .000005 everywhere to overcome the rounding errors. I am not sure if
this is
sufficient. The point is simple, choose the language for the task at hand.

>> Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
>> times you need to do something that the language isn't suited for. My
>> own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
>> re-entrant code, threads, and such, things an OS demands.
>
> But other high level languages are quite capable of that.
>
>>> I will admit that PLI would probably be a good candidate except for
>>> the dearth of programmers who actually know it well enough to write
>>> or maintain an OS.
>
> Nobody should attempt to write an operating system using programmers
> who are too dumb to learn another language. A few lead developers
> with extensive experience is a good idea, but those are available
> if you are willing to pay the price. Nobody should attempt to write
> an operating system on the cheap.
>
>> I don't know PL/I, but I'm aware that it's been used for system
>> programming on multiple occasions, so I'd give it credit for being
>> suitable.
>
> PL/I was the implementation language for Multics, the grand-daddy of
> operating system security models. Where do people think the name
> "Unix" came from ? Certainly none of the developers had a dog named
> Unix.
>
>>> I am still waiting for someone to take on the project of re-writing
>>> Unix in something other than C in order to prove what a tremendous
>>> improvement it would be. (I have had many people suggest that
>>> Unix would be so much better if it were written in Ada but no one
>>> ever takes on the task. Personally, I don't believe it.)
>
> "Unix" has a definition inextricably intertwined with that of "C",
> full of null-terminated strings, pointer arithmetic and other such
> practices which are (properly) forbidden in reliable software.
>
>> I still think many OS tasks are best written in assembler, but that's
>> not real portable, even VAX MACRO-32, which has made it to 3
>> architechures.
>
> Really low level operating system code, like memory management, does
> not need to be portable since it depends on the hardware.
>
> VMS would be better off if more of it were written in Bliss and less
> in Macro, but that is not what compiler availability permitted. Note
> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
> Channel) linkage.
>
>> People willing to accept the job of writing in assembler
>> aren't real numerous either.
>
> While I don't agree with much use of assembly language in this day
> and age, operating systems should not be written on the cheap.
Mark Buda
2005-03-19 00:28:32 UTC
Permalink
"Tom Linden" <***@kednos.com> wrote in message
news:***@hyrrokkin...

> The point is simple, choose the language for the task at hand.

Just don't use ADA, too bad it was used in a couple major places within
VMS...

mark
Dave Froble
2005-03-18 19:25:38 UTC
Permalink
Larry Kilgallen wrote:
> In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:

>>Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
>>times you need to do something that the language isn't suited for. My
>>own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
>>re-entrant code, threads, and such, things an OS demands.
>
>
> But other high level languages are quite capable of that.

<snip>

> VMS would be better off if more of it were written in Bliss and less
> in Macro, but that is not what compiler availability permitted. Note
> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
> Channel) linkage.

Larry, the above seems (to me) to be contradictory? While I didn't
specifically mention WFIKPC I was in general saying that HLLs didn't
support some capabilities it would be nice to have when coding an OS.

Sure, the capabilities of various HLLs may make them candidates for
writing an OS, but >usually< only assembler will give the programmer the
full range of the capabilities of the architechure.

Dave
Larry Kilgallen
2005-03-18 19:53:51 UTC
Permalink
In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
> Larry Kilgallen wrote:
>> In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
>
>>>Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
>>>times you need to do something that the language isn't suited for. My
>>>own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
>>>re-entrant code, threads, and such, things an OS demands.
>>
>>
>> But other high level languages are quite capable of that.
>
> <snip>
>
>> VMS would be better off if more of it were written in Bliss and less
>> in Macro, but that is not what compiler availability permitted. Note
>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>> Channel) linkage.
>
> Larry, the above seems (to me) to be contradictory? While I didn't
> specifically mention WFIKPC I was in general saying that HLLs didn't
> support some capabilities it would be nice to have when coding an OS.
>
> Sure, the capabilities of various HLLs may make them candidates for
> writing an OS, but >usually< only assembler will give the programmer the
> full range of the capabilities of the architechure.

If DEC had given a higher priority to use of Bliss for VMS internals,
supplying a WFIKPCH linkage would have been an easy task for those
who maintained the Bliss compiler. Certainly Bliss-36 (which I never
used) did not omit the skip-return linkages, did it ?

What other construct used in VMS besides WFIKPCH can you think of that
cannot be done from any higher level language ? (Finding one language
that lacks a feature is not sufficient.)
Dave Froble
2005-03-18 22:43:43 UTC
Permalink
Larry Kilgallen wrote:
> In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
>
>>Larry Kilgallen wrote:
>>
>>>In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
>>
>>>>Doing an OS in a HLL isn't the best of ideas, due to capabilities. Many
>>>>times you need to do something that the language isn't suited for. My
>>>>own favorite, VAX/DEC BASIC isn't, as far as I know, capable of
>>>>re-entrant code, threads, and such, things an OS demands.
>>>
>>>
>>>But other high level languages are quite capable of that.
>>
>><snip>
>>
>>>VMS would be better off if more of it were written in Bliss and less
>>>in Macro, but that is not what compiler availability permitted. Note
>>>that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>>>Channel) linkage.
>>
>>Larry, the above seems (to me) to be contradictory? While I didn't
>>specifically mention WFIKPC I was in general saying that HLLs didn't
>>support some capabilities it would be nice to have when coding an OS.
>>
>>Sure, the capabilities of various HLLs may make them candidates for
>>writing an OS, but >usually< only assembler will give the programmer the
>>full range of the capabilities of the architechure.
>
>
> If DEC had given a higher priority to use of Bliss for VMS internals,
> supplying a WFIKPCH linkage would have been an easy task for those
> who maintained the Bliss compiler. Certainly Bliss-36 (which I never
> used) did not omit the skip-return linkages, did it ?

Didn't use Bliss on the DEC System 10. Actually, never have used Bliss.
But you're right, any capability >>CAN<< be implemented in any
language. That's not today's reality.

> What other construct used in VMS besides WFIKPCH can you think of that
> cannot be done from any higher level language ? (Finding one language
> that lacks a feature is not sufficient.)

It's not so much whether it can be done, but whether it can be done in
an obvious manner. For example, bits in a structure can be shifted by
multiple and divide, but that's not as obvious of the intention as a
shift instruction would be, if the intent was to shift bits. Not saying
that's an overwhelming consideration. And I agree, finding missing
capabilities isn't sufficient to disqualify a language. If it was, we
wouldn't have any languages.
Rob Brooks
2005-03-19 03:06:39 UTC
Permalink
Larry Kilgallen wrote:

> VMS would be better off if more of it were written in Bliss and less
> in Macro, but that is not what compiler availability permitted. Note
> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
> Channel) linkage.

This topic is, uh, topical. Several of us in VMS Engineering were just
lamenting the fact that the "founding fathers" did not choose BLISS over
MACRO-32 as the language of choice for most of the kernel of VAX/VMS.

If BLISS had been used wherever possible, the ports to both Alpha and I64 would
have taken substantially less time.

The increased use of C within OpenVMS Alpha did greatly reduce the time and
effort to port to I64.

--

Rob Brooks VMS Engineering -- I/O Exec Group brooks!cuebid.zko.dec.com
Tom Linden
2005-03-19 03:35:27 UTC
Permalink
On 18 Mar 2005 22:06:39 -0500, Rob Brooks <***@cuebid.zko.dec.nospam>
wrote:

> Larry Kilgallen wrote:
>
>> VMS would be better off if more of it were written in Bliss and less
>> in Macro, but that is not what compiler availability permitted. Note
>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>> Channel) linkage.
>
> This topic is, uh, topical. Several of us in VMS Engineering were just
> lamenting the fact that the "founding fathers" did not choose BLISS over
> MACRO-32 as the language of choice for most of the kernel of VAX/VMS.
>
> If BLISS had been used wherever possible, the ports to both Alpha and
> I64 would
> have taken substantially less time.
>
> The increased use of C within OpenVMS Alpha did greatly reduce the time
> and
> effort to port to I64.
>
Ah, what might have been. Had you written it in PL/I, instead of 30
Million
or so lines of code, it would only have been 10 Million. I have seen many
examples of projects in the last 40 years where a seemlingly innocuous
decision
at some point in time had repercussions that lasted long afterwards. The
key to
writing successful code is to choose the highest level abstraction
appropriate
to the problem to be addressed. Macro is too low, bliss is too low and
likewise
C. Obviously it can be done, as demonstrated, but the cost is too high,
maintainability is too arduous and extensibility is a challenge. It is a
far
better paradigm to choose a language like PL/I or Ada for that matter, and
put in
the extensions need to obviate the need to use assembler, that is what
IBM did
with PLS ans PL8. Burroughs wrote there OS in Algol, that would have
been another
good choice.
Jay Maynard
2005-03-19 03:43:59 UTC
Permalink
On 2005-03-19, Tom Linden <***@kednos.com> wrote:
> It is a far better paradigm to choose a language like PL/I or Ada for that
> matter, and put in the extensions need to obviate the need to use
> assembler, that is what IBM did with PLS ans PL8.

Now I know you're full of prunes. PL/S is only superficially related to
PL/I. There are major structural differences, as well as differences in code
generation. Essentially, PL/S is at the same level of abstraction as C.
Tom Linden
2005-03-19 03:54:49 UTC
Permalink
On Sat, 19 Mar 2005 03:43:59 GMT, Jay Maynard
<***@thebrain.conmicro.cx> wrote:

> On 2005-03-19, Tom Linden <***@kednos.com> wrote:
>> It is a far better paradigm to choose a language like PL/I or Ada for
>> that
>> matter, and put in the extensions need to obviate the need to use
>> assembler, that is what IBM did with PLS ans PL8.
>
> Now I know you're full of prunes. PL/S is only superficially related to
> PL/I. There are major structural differences, as well as differences in
> code
> generation. Essentially, PL/S is at the same level of abstraction as C.

Last I looked at a PL/S ref manual ca. 1980 it had strong typing, which C
does
not, it supported many of the PL/I constructs. What structural
differences are
you referring to? I can believe it used a different code generator since
it came
from a different group (was it Yorktown?) whereas I think at the time PL/I
was
level F, but that is not germane to discussions of the language definition.
Michel HERRSCHER
2005-03-19 08:38:35 UTC
Permalink
Hell to all,

1) YOOOOOWW, please change subject....when messages are completly outside
subject, it helps to follow the discussion.


2) What a troll ... This reminds me discussions over RSX11M and First VMS
pro and con.... in the late seventies.


A thing is , imho, the work done by the FREEVMS team must be encouraged as
it is the only Open Source one regarding building a VMS like OS to Intel

Not sure that this troll is in this way.....and it may discourage any effort
on that project...

Regards to you all,
Michel HERRSCHER
singing on VMS sweet melodies .... since1978...


Dans un message Tom Linden disait :

> On Sat, 19 Mar 2005 03:43:59 GMT, Jay Maynard
> <***@thebrain.conmicro.cx> wrote:
>
>> On 2005-03-19, Tom Linden <***@kednos.com> wrote:
>>> It is a far better paradigm to choose a language like PL/I or Ada
>>> for that
>>> matter, and put in the extensions need to obviate the need to use
>>> assembler, that is what IBM did with PLS ans PL8.
>>
>> Now I know you're full of prunes. PL/S is only superficially related
>> to PL/I. There are major structural differences, as well as
>> differences in code
>> generation. Essentially, PL/S is at the same level of abstraction as
>> C.
>
> Last I looked at a PL/S ref manual ca. 1980 it had strong typing,
> which C does
> not, it supported many of the PL/I constructs. What structural
> differences are
> you referring to? I can believe it used a different code generator
> since it came
> from a different group (was it Yorktown?) whereas I think at the
> time PL/I was
> level F, but that is not germane to discussions of the language
> definition.

--
Tom Linden
2005-03-19 14:10:53 UTC
Permalink
On Sat, 19 Mar 2005 09:38:35 +0100, Michel HERRSCHER <***@herrscher.fr>
wrote:

> Hell to all,
>
> 1) YOOOOOWW, please change subject....when messages are completly outside
> subject, it helps to follow the discussion.
>
>
> 2) What a troll ... This reminds me discussions over RSX11M and First VMS
> pro and con.... in the late seventies.
>
>
> A thing is , imho, the work done by the FREEVMS team must be encouraged
> as
> it is the only Open Source one regarding building a VMS like OS to Intel
>
> Not sure that this troll is in this way.....and it may discourage any
> effort
> on that project...

Wasn't trying to discourage it at all, on the contrary. I was hoping to
get
them to think about the appopriateness of using a low level language known
to
be defective. I might even be convinced to license them PL/I for $1/year
if
I were convinced it was going somewhere. In fact, the extensions I put in
for the Tru64 PL/I makes it suitable for writing device drivers.

--- snip ---
Tom Linden
2005-03-22 03:19:01 UTC
Permalink
On Sat, 19 Mar 2005 03:43:59 GMT, Jay Maynard
<***@thebrain.conmicro.cx> wrote:

> On 2005-03-19, Tom Linden <***@kednos.com> wrote:
>> It is a far better paradigm to choose a language like PL/I or Ada for
>> that
>> matter, and put in the extensions need to obviate the need to use
>> assembler, that is what IBM did with PLS ans PL8.
>
> Now I know you're full of prunes. PL/S is only superficially related to
> PL/I. There are major structural differences, as well as differences in
> code
> generation. Essentially, PL/S is at the same level of abstraction as C.

Well prune juice is better than eating crow:-) I tried to find a copy
of the ref man but only found a guide. Around 1980-81 Nixdorf gave me a
ref man and asked me if I would build them a PL/S compiler. I remember at
the time thinking that I would just adapt PL/I to support PL/S. Now you
are quite right about the abstarction level. But what I don't recall is
whether it had lexical scoping. BTW, I declined to do the project for what
I perceived as some serious legal issues and returned the documentation.
Jay Maynard
2005-03-22 11:53:30 UTC
Permalink
On 2005-03-22, Tom Linden <***@kednos.com> wrote:
>> PL/S is at the same level of abstraction as C.
> Well prune juice is better than eating crow:-) I tried to find a copy
> of the ref man but only found a guide. Around 1980-81 Nixdorf gave me a
> ref man and asked me if I would build them a PL/S compiler. I remember at
> the time thinking that I would just adapt PL/I to support PL/S. Now you
> are quite right about the abstarction level. But what I don't recall is
> whether it had lexical scoping. BTW, I declined to do the project for what
> I perceived as some serious legal issues and returned the documentation.

You're not alone...The RAND Corporation, for a very brief time, put out a
PL/S compatible compiler, until IBM made them withdraw it and recall all
copies in existence.

For another very brief time, IBM made PL/AS (a later version, since
superseded by PL/X) available to development partners, with serious
nondisclosure requirements and usage restrictions. Even that wasn't
available long.

In general, IBM treats PL/S and its descendants like the crown jewels. The
closest they've come to generally available documentation is presentations
at the SHARE user group on how to read its listings, and that so systems
programmers at customer sites can understand the few modules whose source is
still distributed.
Bill Gunshannon
2005-03-19 14:23:45 UTC
Permalink
In article <***@hyrrokkin>,
"Tom Linden" <***@kednos.com> writes:
> On 18 Mar 2005 22:06:39 -0500, Rob Brooks <***@cuebid.zko.dec.nospam>
> wrote:
>
>> Larry Kilgallen wrote:
>>
>>> VMS would be better off if more of it were written in Bliss and less
>>> in Macro, but that is not what compiler availability permitted. Note
>>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>>> Channel) linkage.
>>
>> This topic is, uh, topical. Several of us in VMS Engineering were just
>> lamenting the fact that the "founding fathers" did not choose BLISS over
>> MACRO-32 as the language of choice for most of the kernel of VAX/VMS.
>>
>> If BLISS had been used wherever possible, the ports to both Alpha and
>> I64 would
>> have taken substantially less time.
>>
>> The increased use of C within OpenVMS Alpha did greatly reduce the time
>> and
>> effort to port to I64.
>>
> Ah, what might have been. Had you written it in PL/I, instead of 30
> Million
> or so lines of code, it would only have been 10 Million. I have seen many
> examples of projects in the last 40 years where a seemlingly innocuous
> decision
> at some point in time had repercussions that lasted long afterwards. The
> key to
> writing successful code is to choose the highest level abstraction
> appropriate
> to the problem to be addressed. Macro is too low, bliss is too low and
> likewise
> C. Obviously it can be done, as demonstrated, but the cost is too high,
> maintainability is too arduous and extensibility is a challenge. It is a
> far
> better paradigm to choose a language like PL/I or Ada for that matter, and
> put in
> the extensions need to obviate the need to use assembler, that is what
> IBM did
> with PLS ans PL8. Burroughs wrote there OS in Algol, that would have
> been another
> good choice.

I was wondering when Algol would turn in up in these frequent
arguments^H^H^H^H^H^H^H^H^Hdiscussions about "the right language".
I just assumed I was the only one old enough to remember it. :-)
(My daughter used to say, "When my mom was young she played with
Barbies. When my dad was young he played with dinosaurs." She
didn't mean toys.)

Personally, if we are going to talk about older languages with a
long history, I would have to agree with Tom that PL/I would be
the best for doing systems programming. It has proven it's worth
many time over. I often wonder why C was created to write Unix
instead of just using PL/I. But I would guiess it had more to do
with politics or copyright issues than technical merit.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Tom Linden
2005-03-19 15:02:24 UTC
Permalink
On 19 Mar 2005 14:23:45 GMT, Bill Gunshannon <***@cs.uofs.edu> wrote:

> In article <***@hyrrokkin>,
> "Tom Linden" <***@kednos.com> writes:
>> On 18 Mar 2005 22:06:39 -0500, Rob Brooks <***@cuebid.zko.dec.nospam>
>> wrote:
>>
>>> Larry Kilgallen wrote:
>>>
>>>> VMS would be better off if more of it were written in Bliss and less
>>>> in Macro, but that is not what compiler availability permitted. Note
>>>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>>>> Channel) linkage.
>>>
>>> This topic is, uh, topical. Several of us in VMS Engineering were just
>>> lamenting the fact that the "founding fathers" did not choose BLISS
>>> over
>>> MACRO-32 as the language of choice for most of the kernel of VAX/VMS.
>>>
>>> If BLISS had been used wherever possible, the ports to both Alpha and
>>> I64 would
>>> have taken substantially less time.
>>>
>>> The increased use of C within OpenVMS Alpha did greatly reduce the time
>>> and
>>> effort to port to I64.
>>>
>> Ah, what might have been. Had you written it in PL/I, instead of 30
>> Million
>> or so lines of code, it would only have been 10 Million. I have seen
>> many
>> examples of projects in the last 40 years where a seemlingly innocuous
>> decision
>> at some point in time had repercussions that lasted long afterwards.
>> The
>> key to
>> writing successful code is to choose the highest level abstraction
>> appropriate
>> to the problem to be addressed. Macro is too low, bliss is too low and
>> likewise
>> C. Obviously it can be done, as demonstrated, but the cost is too high,
>> maintainability is too arduous and extensibility is a challenge. It is
>> a
>> far
>> better paradigm to choose a language like PL/I or Ada for that matter,
>> and
>> put in
>> the extensions need to obviate the need to use assembler, that is what
>> IBM did
>> with PLS ans PL8. Burroughs wrote there OS in Algol, that would have
>> been another
>> good choice.
>
> I was wondering when Algol would turn in up in these frequent
> arguments^H^H^H^H^H^H^H^H^Hdiscussions about "the right language".
> I just assumed I was the only one old enough to remember it. :-)
> (My daughter used to say, "When my mom was young she played with
> Barbies. When my dad was young he played with dinosaurs." She
> didn't mean toys.)
> Personally, if we are going to talk about older languages with a
> long history, I would have to agree with Tom that PL/I would be
> the best for doing systems programming. It has proven it's worth
> many time over. I often wonder why C was created to write Unix
> instead of just using PL/I. But I would guiess it had more to do
> with politics or copyright issues than technical merit.

I think you are right on that point. But another factor was the hardware
they were using (initially PDP 8, I believe) with teletypes as the
interface,
and also may hvae inspired them to make the language terse. MIT certainly
had the rights to Multics PL/I, in fact, they licensed to Telefunken in
1972(?)
for use on the TR440, of which we had one down the street at the Deutches
RechenZentrum in Darmstadt when I work at the European Space Agency. We
used
a 360/65 and coded mainly in Fortran and some PL/I
>
> bill
>
Jay Maynard
2005-03-19 15:37:37 UTC
Permalink
On 2005-03-19, Bill Gunshannon <***@cs.uofs.edu> wrote:
> Personally, if we are going to talk about older languages with a
> long history, I would have to agree with Tom that PL/I would be
> the best for doing systems programming. It has proven it's worth
> many time over. I often wonder why C was created to write Unix
> instead of just using PL/I. But I would guiess it had more to do
> with politics or copyright issues than technical merit.

I believe it's more of a philosophical difference. One common comment among
the C folks who come from Bell Labs is "If you want PL/I, you know where to
find it." in response to feature requests. THey felt that PL/I was far
larger and more complex than necessary. When considered in light of the
dictum that computers should not try to stop you from doign stupid things
because that also prevents you from doing clever things, this makes sense.
Whether or not time has proven them right (and, as we can see, there's
considerable disagreement on the subject), it's pretty clear that their
viewpoint has carried the day.
Larry Kilgallen
2005-03-19 20:46:58 UTC
Permalink
In article <***@individual.net>, ***@cs.uofs.edu (Bill Gunshannon) writes:

> Personally, if we are going to talk about older languages with a
> long history, I would have to agree with Tom that PL/I would be
> the best for doing systems programming. It has proven it's worth
> many time over. I often wonder why C was created to write Unix
> instead of just using PL/I. But I would guiess it had more to do
> with politics or copyright issues than technical merit.

I believe the first C compiler was considerably simpler that PL/I
compilers of the time.

C was developed for research work.
Larry Kilgallen
2005-03-19 09:38:14 UTC
Permalink
In article <423be527$0$810$***@news.wanadoo.fr>, "Michel HERRSCHER" <***@herrscher.fr> writes:
> Hell to all,
>
> 1) YOOOOOWW, please change subject....when messages are completly outside
> subject, it helps to follow the discussion.

Welcome to Usenet.

> A thing is , imho, the work done by the FREEVMS team must be encouraged as
> it is the only Open Source one regarding building a VMS like OS to Intel

If you care about a project called FreeVMS, you should care about the
quality (or lack thereof) of their process and their product. Blind
allegiance is as bad as the way some people are loyal to C, despite all
the evidence of its shortcomings.
Larry Kilgallen
2005-03-19 03:31:06 UTC
Permalink
In article <***@corp.supernews.com>, Dave Froble <***@tsoft-inc.com> writes:
> Larry Kilgallen wrote:

>> What other construct used in VMS besides WFIKPCH can you think of that
>> cannot be done from any higher level language ? (Finding one language
>> that lacks a feature is not sufficient.)
>
> It's not so much whether it can be done, but whether it can be done in
> an obvious manner. For example, bits in a structure can be shifted by
> multiple and divide, but that's not as obvious of the intention as a
> shift instruction would be, if the intent was to shift bits.

Yes, languages to do bit twiddling should provide shift operators,
even if the compiler has to direct the hardware to do it via divide
and multiply.

> Not saying
> that's an overwhelming consideration. And I agree, finding missing
> capabilities isn't sufficient to disqualify a language.

That was not what I meant to say.

What I meant was that finding _one_ higher level language without
sufficient versatility to do such things does not mean that _all_
higher level languages are inadequate. My own favorite for a
capable language is Ada, while Tom would nominate PL/I. Meanwhile
C will not even guarantee where a specified bit gets stored in a
record (talking about guarantees, not "happens to work with the
proper brand of compiler").
Dave Weatherall
2005-03-21 06:51:33 UTC
Permalink
On Sat, 19 Mar 2005 03:31:06 UTC, ***@SpamCop.net (Larry
Kilgallen) wrote:

<Snip>

> What I meant was that finding _one_ higher level language without
> sufficient versatility to do such things does not mean that _all_
> higher level languages are inadequate. My own favorite for a
> capable language is Ada, while Tom would nominate PL/I. Meanwhile
> C will not even guarantee where a specified bit gets stored in a
> record (talking about guarantees, not "happens to work with the
> proper brand of compiler").

I wouldn't disagree with that at all but I do remember an Ada
programming colleague explaining a problem that arose in their system
precisely because Ada compilers placed a bit in a 'different position'
on different endian machines. i.e. VAX and MC68020. The code worked on
VAX where they developed it but not on the Motorola that they were
later asked to use.

--
Cheers - Dave W.

PS Are we still talking VMS :-)
Karsten Nyblad
2005-03-21 08:33:21 UTC
Permalink
Dave Weatherall wrote:
> On Sat, 19 Mar 2005 03:31:06 UTC, ***@SpamCop.net (Larry
> Kilgallen) wrote:
>
> <Snip>
>
>>What I meant was that finding _one_ higher level language without
>>sufficient versatility to do such things does not mean that _all_
>>higher level languages are inadequate. My own favorite for a
>>capable language is Ada, while Tom would nominate PL/I. Meanwhile
>>C will not even guarantee where a specified bit gets stored in a
>>record (talking about guarantees, not "happens to work with the
>>proper brand of compiler").
>
>
> I wouldn't disagree with that at all but I do remember an Ada
> programming colleague explaining a problem that arose in their system
> precisely because Ada compilers placed a bit in a 'different position'
> on different endian machines. i.e. VAX and MC68020. The code worked on
> VAX where they developed it but not on the Motorola that they were
> later asked to use.
>
You can write code like that in Ada, but you would have to use
constructs that makes it clearly visible that this code misses around
with bits. The problem with C, BLISS, assembler and C++ is not that you
can write code that does dirty things. The problem is that you can do
it without getting a warning from the language and in such a way that it
is not obvious to people reading the code that this code misses around
with bits and is intended to use features that are not defined in the
language.

PL/I has its own problems, e.g., its automatic type conversions may
result in code that fails in some cases.

The fans of Ada claim that only half as many errors slip through to the
final product when using Ada compared to, e.g., C.

I think that there is one aspect that has been ignored in this
discussion. That is that you need a compiler that generates efficient
code when writing operating systems. At least that was an important
aspect when the operating systems popular today were designed. Don't
use bandwidth telling me that in many cases you would get a better
efficiency by using your programmer resources on implementing better
algorithms in stead fitting a low level language. I know.
Tom Linden
2005-03-21 14:33:54 UTC
Permalink
On Mon, 21 Mar 2005 09:33:21 +0100, Karsten Nyblad <***@nospam.nospam>
wrote:

> Dave Weatherall wrote:
>> On Sat, 19 Mar 2005 03:31:06 UTC, ***@SpamCop.net (Larry
>> Kilgallen) wrote:
>> <Snip>
>>
>>> What I meant was that finding _one_ higher level language without
>>> sufficient versatility to do such things does not mean that _all_
>>> higher level languages are inadequate. My own favorite for a
>>> capable language is Ada, while Tom would nominate PL/I. Meanwhile
>>> C will not even guarantee where a specified bit gets stored in a
>>> record (talking about guarantees, not "happens to work with the
>>> proper brand of compiler").
>> I wouldn't disagree with that at all but I do remember an Ada
>> programming colleague explaining a problem that arose in their system
>> precisely because Ada compilers placed a bit in a 'different position'
>> on different endian machines. i.e. VAX and MC68020. The code worked on
>> VAX where they developed it but not on the Motorola that they were
>> later asked to use.
>>
> You can write code like that in Ada, but you would have to use
> constructs that makes it clearly visible that this code misses around
> with bits. The problem with C, BLISS, assembler and C++ is not that you
> can write code that does dirty things. The problem is that you can do
> it without getting a warning from the language and in such a way that it
> is not obvious to people reading the code that this code misses around
> with bits and is intended to use features that are not defined in the
> language.
>
> PL/I has its own problems, e.g., its automatic type conversions may
> result in code that fails in some cases.

Unless it is turned off you will be warned about the conversion.

>
> The fans of Ada claim that only half as many errors slip through to the
> final product when using Ada compared to, e.g., C.
>
> I think that there is one aspect that has been ignored in this
> discussion. That is that you need a compiler that generates efficient
> code when writing operating systems. At least that was an important
> aspect when the operating systems popular today were designed. Don't
> use bandwidth telling me that in many cases you would get a better
> efficiency by using your programmer resources on implementing better
> algorithms in stead fitting a low level language. I know.
p***@prep.synonet.com
2005-03-21 20:19:13 UTC
Permalink
Karsten Nyblad <***@nospam.nospam> writes:

> The fans of Ada claim that only half as many errors slip through to
> the final product when using Ada compared to, e.g., C.

The study I have seen showed a 3:1 minimum difference against C..

> I think that there is one aspect that has been ignored in this
> discussion. That is that you need a compiler that generates
> efficient code when writing operating systems. At least that was an
> important aspect when the operating systems popular today were
> designed. Don't use bandwidth telling me that in many cases you
> would get a better efficiency by using your programmer resources on
> implementing better algorithms in stead fitting a low level
> language. I know.

You need to be able to exert fine control over the code, and to
included assembly type code with out destroying optimisation or
causing unwanted side effect due to extra calls/jsrs etc.

Your coment is historically wrong BTW. Unix in C used compilers
that could hardly tie their laces. VMS used macro, no opimisation
there at all, and BLISS.

What compilers did MICA use?

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Larry Kilgallen
2005-03-19 03:37:46 UTC
Permalink
In article <O8nKrSNEM+***@cuebid.zko.dec.com>, ***@cuebid.zko.dec.nospam (Rob Brooks) writes:
> Larry Kilgallen wrote:
>
>> VMS would be better off if more of it were written in Bliss and less
>> in Macro, but that is not what compiler availability permitted. Note
>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep
>> Channel) linkage.
>
> This topic is, uh, topical. Several of us in VMS Engineering were just
> lamenting the fact that the "founding fathers" did not choose BLISS over
> MACRO-32 as the language of choice for most of the kernel of VAX/VMS.

I believe the Bliss compiler was not production-ready in time.

By the time VMS V4 came out, LOGINOUT could be rewritten in Bliss.
Larry Kilgallen
2005-03-21 12:48:04 UTC
Permalink
In article <DTiotGxQ0bj6-pn2-***@dave2_os2.home.ours>, "Dave Weatherall" <djw-***@nospam.nohow> writes:
> On Sat, 19 Mar 2005 03:31:06 UTC, ***@SpamCop.net (Larry
> Kilgallen) wrote:
>
> <Snip>
>
>> What I meant was that finding _one_ higher level language without
>> sufficient versatility to do such things does not mean that _all_
>> higher level languages are inadequate. My own favorite for a
>> capable language is Ada, while Tom would nominate PL/I. Meanwhile
>> C will not even guarantee where a specified bit gets stored in a
>> record (talking about guarantees, not "happens to work with the
>> proper brand of compiler").
>
> I wouldn't disagree with that at all but I do remember an Ada
> programming colleague explaining a problem that arose in their system
> precisely because Ada compilers placed a bit in a 'different position'
> on different endian machines. i.e. VAX and MC68020. The code worked on
> VAX where they developed it but not on the Motorola that they were
> later asked to use.

In that case, they failed to specify a "representation clause" for
their data structure. I have made that mistake myself, between VAX
and Alpha.

The fact that a language is versatile does not excuse the programmer
from taking care.
Bill Gunshannon
2005-03-23 02:40:03 UTC
Permalink
In article <d1$***@eisner.encompasserve.org>,
***@SpamCop.net (Larry Kilgallen) writes:
>
> The fact that a language is versatile does not excuse the programmer
> from taking care.

I've been saying that about C for years.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Larry Kilgallen
2005-03-21 12:54:33 UTC
Permalink
In article <423e86d1$0$78288$***@dreader1.cybercity.dk>, Karsten Nyblad <***@nospam.nospam> writes:

> You can write code like that in Ada, but you would have to use
> constructs that makes it clearly visible that this code misses around
> with bits. The problem with C, BLISS, assembler and C++ is not that you
> can write code that does dirty things. The problem is that you can do
> it without getting a warning from the language and in such a way that it
> is not obvious to people reading the code that this code misses around
> with bits and is intended to use features that are not defined in the
> language.

In particular, there is an Ada package called Unchecked_Conversion.
Instantiating it goes something like:

function Apples_from_Oranges is new
Unchecked_Conversion ( A: Apple_Count; B: Orange_Count );

and use looks like:

My_Apple_Count := Apples_from_Oranges ( My_Orange_Count );

But lately I have taken to naming the instantiation like:

function Unchecked_Apples_from_Oranges is new
Unchecked_Conversion ( A: Apple_Count; B: Orange_Count );

and use looks like:

My_Apple_Count := Unchecked_Apples_from_Oranges ( My_Orange_Count );

making the "unchecked" nature obvious everywhere it is used.
Larry Kilgallen
2005-03-21 16:50:14 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:
> On Mon, 21 Mar 2005 09:33:21 +0100, Karsten Nyblad <***@nospam.nospam>
> wrote:

>> PL/I has its own problems, e.g., its automatic type conversions may
>> result in code that fails in some cases.
>
> Unless it is turned off you will be warned about the conversion.

Tom, is that required by the standard or just a feature of some compilers ?
Tom Linden
2005-03-21 19:55:05 UTC
Permalink
On 21 Mar 2005 10:50:14 -0600, Larry Kilgallen <***@SpamCop.net>
wrote:

> In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com>
> writes:
>> On Mon, 21 Mar 2005 09:33:21 +0100, Karsten Nyblad
>> <***@nospam.nospam>
>> wrote:
>
>>> PL/I has its own problems, e.g., its automatic type conversions may
>>> result in code that fails in some cases.
>>
>> Unless it is turned off you will be warned about the conversion.
>
> Tom, is that required by the standard or just a feature of some
> compilers ?

It is an implementation decision. There are two distinct genetically
different PL/I lines that have survived the IBM line and the Multics
line from which VMS and Tru64 PL/I genes derive. This has always been
a feature in this line. I believe IBM also has copious warnings, but
I am less familiar withits behaviour that its definition. Example I
recently posted elsewhere:

FREJA> type pr.pli
tt: proc options(main);
dcl a fixed dec(10);
dcl f float bin(53);
a = 1 + '5';
put skip list(a);
f = 1.0 + '5.0';
put skip list(f);
f = 1.0 + '5.fluff';
end;
FREJA> pli pr

a = 1 + '5';
........^
%PLIG-W-NOTARITH, Implicit conversion. A nonarithmetic expression,
a constant '5', has been used in a context
requiring an arithmetic value.
at line number 4 in file SYS$SYSDEVICE:[TOM.SCRATCH]PR.PLI;4

f = 1.0 + '5.0';
..........^
%PLIG-W-NOTARITH, Implicit conversion. A nonarithmetic expression,
a constant '5.0', has been used in a context
requiring an arithmetic value.
at line number 6 in file SYS$SYSDEVICE:[TOM.SCRATCH]PR.PLI;4

f = 1.0 + '5.fluff';
..........^
%PLIG-W-NOTARITH, Implicit conversion. A nonarithmetic expression,
a constant '5.fluff', has been used in a context
requiring an arithmetic value.
at line number 8 in file SYS$SYSDEVICE:[TOM.SCRATCH]PR.PLI;4

%PLIG-I-SUMMARY, Completed with 0 errors, 3 warnings, and
0 informational messages.
FREJA> link pr
%LINK-W-WRNERS, compilation warnings
in module TT file SYS$SYSDEVICE:[TOM.SCRATCH]PR.OBJ;5
FREJA> run pr

6
6.000000000000000E+00
%PLI-F-ERROR, PL/I ERROR condition.
-PLI-F-CONVERSION, PL/I CONVERSION condition.
-PLI-I-ONSOURCE, The conversion source is '5.fluff'.
-PLI-I-ONCNVPOS, The erroneous character is at position 3.
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DPLI$RTLSHR 0 000000000006ADA4
00000000000ACDA4
DPLI$RTLSHR 0 000000000005413C
000000000009613C
DPLI$RTLSHR 0 0000000000054014
0000000000096014
DPLI$RTLSHR DPLI_UTL_MAIN_HANDLER DPLI$UTL_MAIN_HANDLER
2211 0000000000000028
00000000000B1DF8
----- above condition handler called with exception 001E8324:
%PLI-F-CONVERSION, PL/I CONVERSION condition.
-PLI-I-ONSOURCE, The conversion source is '5.fluff'.
-PLI-I-ONCNVPOS, The erroneous character is at position 3.
----- end of exception message
0 FFFFFFFF800A1E5C
FFFFFFFF800A1E5C
DPLI$RTLSHR 0 000000000006A04C
00000000000AC04C
DPLI$RTLSHR 0 0000000000052294
0000000000094294
PR TT TT 8 00000000000002E0
00000000000302E0
0 FFFFFFFF802553D4
FFFFFFFF802553D4
FREJA>
Bob Koehler
2005-03-22 16:12:21 UTC
Permalink
In article <gPpBCJf+$***@eisner.encompasserve.org>, ***@SpamCop.net (Larry Kilgallen) writes:

> If DEC had given a higher priority to use of Bliss for VMS internals,
> supplying a WFIKPCH linkage would have been an easy task for those
> who maintained the Bliss compiler. Certainly Bliss-36 (which I never
> used) did not omit the skip-return linkages, did it ?

Don't know about BLISS-36, the only things I'm sure DEC wrote in
BLISS-36 were the Fortran compiler and EDT.

BLISS-10, which was on the equivalent of "freeware" tape, did not
include the skip-return linkage. But you could put inline the
necessary JRST in assembly language right after you put in the UUO
or JSYS.
Bob Koehler
2005-03-18 14:19:37 UTC
Permalink
In article <***@individual.net>, ***@cs.uofs.edu (Bill Gunshannon) writes:
> In article <5IVLsW$***@eisner.encompasserve.org>,
> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>> But if you program in other languages it can be hard to code a
>> buffer overrun, which is the way it should be.
>
> But if you program in other languages it can also be hard to code
> the task at hand.

Seeing how MacOS was written in Pascal prior to OS X, I hardly think
writing an OS requires one to write in C. There are, and should be,
many tools in the box. There is quite likely a tool more suitable
to the job.
Bill Gunshannon
2005-03-18 17:23:08 UTC
Permalink
In article <***@eisner.encompasserve.org>,
***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <***@individual.net>, ***@cs.uofs.edu (Bill Gunshannon) writes:
>> In article <5IVLsW$***@eisner.encompasserve.org>,
>> ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>
>>> But if you program in other languages it can be hard to code a
>>> buffer overrun, which is the way it should be.
>>
>> But if you program in other languages it can also be hard to code
>> the task at hand.
>
> Seeing how MacOS was written in Pascal prior to OS X, I hardly think
> writing an OS requires one to write in C. There are, and should be,
> many tools in the box. There is quite likely a tool more suitable
> to the job.

And how many non-standard features did they use? Does their compiler
support things like the UCSD-Pascal -R option? While Pascal is a nice
language, it was never intended for uses like that and it usually takes
breaking the features (like strong type casting) in order to use it for
serious systems programming.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bob Koehler
2005-03-17 13:35:31 UTC
Permalink
In article <***@hyrrokkin>, "Tom Linden" <***@kednos.com> writes:

> I note that you are writing it in C, just what we need VMS with buffer
> overrun
> exploits. If you are serious about writing an OS, use a high-level
> language.

No, use BLISS. Since they now have a compiler and it solves earlier
issues with variable length LIB$ RTL calls they should go ahead and
use it.

I'm doing some socket work in BLISS specifically because it's easier
for me to _know_ I'm not coding up buffer overruns that will be
exposed directly to the internet (and my only other licensed compiler
on the system is Fortran). I could do it in C, but then I'd have to
spend a ton of time searching for the one I might have missed.
Roar Thronæs
2005-03-17 14:22:30 UTC
Permalink
Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:

: No, use BLISS. Since they now have a compiler and it solves earlier

It can be used for very few things (and has lots of bugs), as you can
expect from the version number.

--
-Roar Thronæs
Tom Linden
2005-03-17 14:38:55 UTC
Permalink
On Thu, 17 Mar 2005 14:22:30 +0000 (UTC), Roar Thronæs <***@nvg.ntnu.no>
wrote:

> Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
>
> : No, use BLISS. Since they now have a compiler and it solves earlier
>
> It can be used for very few things (and has lots of bugs), as you can
> expect from the version number.
>

What is the hardware you are using for development?
JKB
2005-03-17 15:04:21 UTC
Permalink
Le 17-03-2005, à propos de
Re: [Announce] FreeVMS 0.1.3,
Tom Linden écrivait dans comp.os.vms :
> On Thu, 17 Mar 2005 14:22:30 +0000 (UTC), Roar Thronæs <***@nvg.ntnu.no>
> wrote:
>
>> Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
>>
>> : No, use BLISS. Since they now have a compiler and it solves earlier
>>
>> It can be used for very few things (and has lots of bugs), as you can
>> expect from the version number.
>>
>
> What is the hardware you are using for development?

x86 in a first time (my PWS500 is dead :-( ) and Bochs (x86
emulator).

Regards,

JKB

--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Bob Koehler
2005-03-17 18:14:23 UTC
Permalink
In article <d1c3r6$r7$***@orkan.itea.ntnu.no>, Roar =?iso-8859-1?Q?Thron=E6s?= <***@nvg.ntnu.no> writes:
> Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
>
> : No, use BLISS. Since they now have a compiler and it solves earlier
>
> It can be used for very few things (and has lots of bugs), as you can
> expect from the version number.

Maybe it can be used to write a less buggy version.
Soterro
2005-03-17 12:23:18 UTC
Permalink
JKB wrote:
> New FreeVMS release available at
> http://www.systella.fr/~bertrand/FreeVMS

Any reason for this project to not get some more exposure through
SourceForge?

S
Bob Koehler
2005-03-17 13:38:17 UTC
Permalink
In article <423975fa$0$6580$***@read.news.ch.uu.net>, Soterro <soterroatyahoocom> writes:
> JKB wrote:
>> New FreeVMS release available at
>> http://www.systella.fr/~bertrand/FreeVMS
>
> Any reason for this project to not get some more exposure through
> SourceForge?

You have a SourceForge client and/or server for VMS?
Andreas Davour
2005-03-20 21:42:36 UTC
Permalink
***@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> In article <423975fa$0$6580$***@read.news.ch.uu.net>, Soterro <soterroatyahoocom> writes:
> > JKB wrote:
> >> New FreeVMS release available at
> >> http://www.systella.fr/~bertrand/FreeVMS
> >
> > Any reason for this project to not get some more exposure through
> > SourceForge?
>
> You have a SourceForge client and/or server for VMS?

Sourceforge is a place to host your software project, not a tool.

/andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Bob Koehler
2005-03-22 16:18:05 UTC
Permalink
In article <***@Psilocybe.Update.UU.SE>, Andreas Davour <***@update.uu.se> writes:
>
> Sourceforge is a place to host your software project, not a tool.
>

Yes, but doens't it assume CVS or some such?

Do you think they could actually take VMS INSTAL'able save sets and
not break them?
Jay Maynard
2005-03-22 16:22:43 UTC
Permalink
On 2005-03-22, Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
> In article <***@Psilocybe.Update.UU.SE>, Andreas Davour <***@update.uu.se> writes:
>> Sourceforge is a place to host your software project, not a tool.
> Yes, but doens't it assume CVS or some such?

No. They provide a CVS repository for the project, but don't require that
you use it.

> Do you think they could actually take VMS INSTAL'able save sets and
> not break them?

I would expect so, as long as it could be transferred via binary FTP or HTTP
download.
Bob Koehler
2005-03-22 17:42:38 UTC
Permalink
In article <***@thebrain.conmicro.cx>, Jay Maynard <***@thebrain.conmicro.cx> writes:
> On 2005-03-22, Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:

>> Do you think they could actually take VMS INSTAL'able save sets and
>> not break them?
>
> I would expect so, as long as it could be transferred via binary FTP or HTTP
> download.

I would expect not, unless they have both a VMS system as their server
and an FTP server that implements STRU VMS.
Thierry Dussuet
2005-03-22 17:45:32 UTC
Permalink
On 2005-03-22, Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
> In article <***@thebrain.conmicro.cx>, Jay Maynard <***@thebrain.conmicro.cx> writes:
>> On 2005-03-22, Bob Koehler <***@eisner.nospam.encompasserve.org> wrote:
>
>>> Do you think they could actually take VMS INSTAL'able save sets and
>>> not break them?
>>
>> I would expect so, as long as it could be transferred via binary FTP or HTTP
>> download.
>
> I would expect not, unless they have both a VMS system as their server
> and an FTP server that implements STRU VMS.

You could always package it in a ZIP

Thierry
Andreas Davour
2005-03-22 20:32:22 UTC
Permalink
***@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> In article <***@Psilocybe.Update.UU.SE>, Andreas Davour <***@update.uu.se> writes:
> >
> > Sourceforge is a place to host your software project, not a tool.
> >
>
> Yes, but doens't it assume CVS or some such?

It's one of the available features, but not something you'll have to
use.

> Do you think they could actually take VMS INSTAL'able save sets and
> not break them?

Packaged as a ZIP or a tarball, yes I think so.

/andreas


--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
JKB
2005-03-22 16:46:21 UTC
Permalink
Le 22-03-2005, à propos de
Re: [Announce] FreeVMS 0.1.3,
Bob Koehler écrivait dans comp.os.vms :
> In article <***@Psilocybe.Update.UU.SE>, Andreas Davour <***@update.uu.se> writes:
>>
>> Sourceforge is a place to host your software project, not a tool.
>>
>
> Yes, but doens't it assume CVS or some such?

Sure, but we have both ftp _and_ CVS... and a mailing list.

Regards,

JKB

--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Soterro
2005-03-23 08:37:08 UTC
Permalink
JKB wrote:
> Sure, but we have both ftp _and_ CVS... and a mailing list.

Being on SourceForge doesn't exclude using your own tools.
Anyway, I didn't mean asking 'why don't you use the CVS' or similar, I
was asking why don't you use the exposure that you can get by being on
SourceForge. I'm pretty sure that would attract some rookies to your
project, or at least make them aware there's such a thing like VMS. You
know, that goes a little bit in hand with VMS (lack of) promotion. The
OS really needs some touch with the young, and as in universities nobody
knows about it anymore the pool of enthusiasts named SourceForge might
be of some help. Yeah, how about building somehow a community around it?

The quality of the software written might be not exactly the best fit
for VMS... 'might be' I say. It's not a rule. But for sure it will
attract people to the brand called VMS.

S
JKB
2005-03-17 14:37:39 UTC
Permalink
Le 17-03-2005, à propos de
Re: [Announce] FreeVMS 0.1.3,
Soterro écrivait dans comp.os.vms :
> JKB wrote:
>> New FreeVMS release available at
>> http://www.systella.fr/~bertrand/FreeVMS
>
> Any reason for this project to not get some more exposure through
> SourceForge?

You can find it on freshmeat.net.

JKB

--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Loading...