Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just as
good) PL/M went the opposite direction from C, making it very annoying for
a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
Michael S Hines wrote:
When
Dana Epp wrote...
[...snip...]
For those of us who write kernel mode / ring0 code, what language are
you suggesting we write in? Name a good typesafe language that you have
PRACTICALLY seen to write kernel mode code in. Especially on Windows and
the Linux platform. I am not trying to fuel
Andreas Saurwein wrote:
Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just
as good) PL/M went the opposite direction from C, making it very
annoying for a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
No,
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.
Many of our Operating Systems seem to have evolved out of the old DEC RSTS
system. For example, CP/M had a PIP command. Later renamed to COPY in DOS.
For those of us who write kernel mode / ring0 code, what language are
you suggesting we write in? Name a good typesafe language that you
have PRACTICALLY seen to write kernel mode code in.
Lisp. I used Lisp Machines back when I worked in academia, and almost
everything was in Lisp, including
At 9:16 AM -0500 6/11/04, Michael S Hines wrote:
IBM had Language Environment (LE) before .NET come along.
What is Language Environment (for either of those) ?
Michael S Hines wrote:
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.
If PL/M is the language I am remembering from an embedded systems class
back in the 1980s, then it is not at all like PL/1. Rather,
Damir Rajnovic wrote:
While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).
This is true in
* Kenneth R. van Wyk:
There's an interesting article out on Net-Security.org (see the full article
at http://www.net-security.org/article.php?id=697) that addresses why
software development organizations adopt (or do not adopt) a Software
Security development methodology. Check it out --
