From roart at nvg.ntnu.no  Tue Jul  2 09:21:00 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 09:21:00 +0200
Subject: [FreeVMS] pager question
In-Reply-To: <2017497.RiuaGyRr4O@kermit>
References: <2017497.RiuaGyRr4O@kermit>
Message-ID: <20130702072100.GA11052@sabre-wulf.nvg.ntnu.no>

On Fri, Jun 28, 2013 at 08:59:45PM +0200, Guido wrote:
> lead to allocation of a new page for the process that generated the page 
> fault. Maybe I'm missing something, but it seems to me that that is not 
> desired behavior. Buggy or malicious software in user space should not be able 
> to acquire resources simply by accessing invalid memory addresses. In stead 
> this should lead to an access violation and termination of the originating 
> process.

VMS memory management is covered in detail in the OpenVMS Internal books,
one of the latest is a dedicated book for memory management.

-- 
-Roar Thron??s

From roart at nvg.ntnu.no  Tue Jul  2 09:57:17 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 09:57:17 +0200
Subject: [FreeVMS] Question
In-Reply-To: <CAA_SOw_ho5SD9J29GjsxjA5HtTCFg-7UmzmftJuhPVKtsWd03A@mail.gmail.com>
References: <000f01ce6f87$4a81c610$df855230$@gmail.com>
 <CAA_SOw_ho5SD9J29GjsxjA5HtTCFg-7UmzmftJuhPVKtsWd03A@mail.gmail.com>
Message-ID: <20130702075717.GB11052@sabre-wulf.nvg.ntnu.no>

On Sun, Jun 23, 2013 at 04:43:24AM +0000, Johann 'Myrkraverk' Oskarsson wrote:
> On Sat, Jun 22, 2013 at 8:30 PM, Renee <rmctwo at gmail.com> wrote:
> > And the embarrassing thing is that I may have asked it before. Obviously we
> > are not building a VAX. We can make this thing ?source compatible? to be
> > recompiled. And I don?t think a privileged or even a CMKRNL task would work.
> > With that in mind, I?ll ask again?.what are we building? Certainly some form
> > of DCL can and must be built.
> 
> And that task is quite independent of the kernel.  DCL is a shell and
> can be written in C on top of Posix interfaces.  I'm not advocating
> that, only pointing out it's an option.
> 
> In between DCL and the kernel are the LIB$ and other VMS interfaces.
> These interfaces can be written on top of pretty much any kernel.   At
> least when we have the option to modify the kernel too.

DCL is not a shell like bash.
It is a command language interpreter, and runs in a higher kernel mode,
supervisor mode. It is covered in the VMS Internal books.
FreeVMS 0.3 had DCL with a lot of features, and it could be booted into.
(But it seems to have been deliberately forgotten.)

-- 
-Roar

From roart at nvg.ntnu.no  Tue Jul  2 10:10:14 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 10:10:14 +0200
Subject: [FreeVMS] DCL
In-Reply-To: <51BF85FB.1010902@gmail.com>
References: <00cb01ce6b5f$9d013410$d7039c30$@gmail.com>
 <51BF82DF.4020804@systella.fr> <51BF85FB.1010902@gmail.com>
Message-ID: <20130702081014.GC11052@sabre-wulf.nvg.ntnu.no>

On Mon, Jun 17, 2013 at 10:56:11PM +0100, remi.chateauneu at gmail.com wrote:
> Le 17.06.2013 22:42, BERTRAND Jo?l a ?crit :
> >Renee a ?crit :
> >>Has anyone considered DCL or is it too early in the process?
> >
> >To early in the process. We need to obtain a running kernel with some IO
> >capabilities before trying to wrtie a shell.
> 
> Indeed. On the other hand it might be possible to write the highest 
> level part of a DCL interpreter:
> * Commands parsing (Options etc...)

Libraries for this exist.

> Also, some part of Record Management Services ( 
> http://en.wikipedia.org/wiki/Record_Management_Services ) could be 
> written (And used) independently of OpenVMS. At least prototyped.

That has already been done, and was integrated into FreeVMS 0.3 many
years ago, with some additions of write capabilities.
(But it seems to have been deliberately forgotten.)

-- 
-Roar

From roart at nvg.ntnu.no  Tue Jul  2 10:46:22 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 10:46:22 +0200
Subject: [FreeVMS] Wanted
In-Reply-To: <51B99499.6010106@systella.fr>
References: <51B99499.6010106@systella.fr>
Message-ID: <20130702084622.GD11052@sabre-wulf.nvg.ntnu.no>

On Thu, Jun 13, 2013 at 11:44:57AM +0200, BERTRAND Jo?l wrote:
> stuff to obtain a usable operating system (Bliss, Macro32 and 64 have to 
> be ported on new architectures). I'm not sure that rewrite a new OS is 
> more difficult.

These 3, Bliss included, would be too lowlevel to be worth continuing.
I did make sufficient parts of a Bliss compiler to compile the telnet
client from CMUIP and run that in FreeVMS 32-bit, but the source would
not work with 64-bit FreeVMS.

-- 
-Roar

From roart at nvg.ntnu.no  Tue Jul  2 10:46:22 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 10:46:22 +0200
Subject: [FreeVMS] Wanted
In-Reply-To: <51B99499.6010106@systella.fr>
References: <51B99499.6010106@systella.fr>
Message-ID: <20130702084622.GD11052@sabre-wulf.nvg.ntnu.no>

On Thu, Jun 13, 2013 at 11:44:57AM +0200, BERTRAND Jo?l wrote:
> stuff to obtain a usable operating system (Bliss, Macro32 and 64 have to 
> be ported on new architectures). I'm not sure that rewrite a new OS is 
> more difficult.

These 3, Bliss included, would be too lowlevel to be worth continuing.
I did make sufficient parts of a Bliss compiler to compile the telnet
client from CMUIP and run that in FreeVMS 32-bit, but the source would
not work with 64-bit FreeVMS.

-- 
-Roar

From mhc at herrscher.fr  Tue Jul  2 11:14:53 2013
From: mhc at herrscher.fr (Michel Herrscher)
Date: Tue, 2 Jul 2013 11:14:53 +0200
Subject: [FreeVMS] Wanted
In-Reply-To: <20130702084622.GD11052@sabre-wulf.nvg.ntnu.no>
References: <51B99499.6010106@systella.fr>
 <20130702084622.GD11052@sabre-wulf.nvg.ntnu.no>
Message-ID: <002601ce7704$9d222c00$d7668400$@herrscher.fr>

Hello from a silent FreeVMS observer!!!

Is there a freeware compiler ( Macro ( or equivalent), Fortran etc..)
available in 64bits ?
This would help to quickly write parts of FreeVMS.

May be I am too much optimist ...

Regards,
Michel Herrscher 
N'imprimez ce message que si vraiment obligatoire...

-----Message d'origine-----
De?: FreeVMS [mailto:freevms-bounces at rayleigh.systella.fr] De la part de
Roar Thron?s
Envoy??: mardi 2 juillet 2013 10:46
??: FreeVMS mailing list
Cc?: freevms at systella.fr
Objet?: Re: [FreeVMS] Wanted

On Thu, Jun 13, 2013 at 11:44:57AM +0200, BERTRAND Jo?l wrote:
> stuff to obtain a usable operating system (Bliss, Macro32 and 64 have 
> to be ported on new architectures). I'm not sure that rewrite a new OS 
> is more difficult.

These 3, Bliss included, would be too lowlevel to be worth continuing.
I did make sufficient parts of a Bliss compiler to compile the telnet client
from CMUIP and run that in FreeVMS 32-bit, but the source would not work
with 64-bit FreeVMS.

--
-Roar
_______________________________________________
FreeVMS mailing list
FreeVMS at rayleigh.systella.fr
https://www.systella.fr/cgi-bin/mailman/listinfo/freevms



From roart at nvg.ntnu.no  Tue Jul  2 11:41:30 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 11:41:30 +0200
Subject: [FreeVMS] FreeVMS
In-Reply-To: <6823d292689a27b0003aec2c0ee9d374@systella.fr>
References: <001401ce67b9$7e464c30$7ad2e490$@ccsscorp.com>
 <6823d292689a27b0003aec2c0ee9d374@systella.fr>
Message-ID: <20130702094130.GE11052@sabre-wulf.nvg.ntnu.no>

On Thu, Jun 13, 2013 at 07:43:37AM +0200, BERTRAND Jo?l wrote:
> 
> FreeVMS project was created a long time ago. First kernels (until 0.3) 
> were derivated from Linux kernel (2.4.15 if I remember) and were 
> monolithic. These kernels were bootable but not easely maintenable.

Yes, I know, but it was small enough with few hardware drivers,
since qemu supported only a few.
I would consider it small enough to be further changable/convertible/
transformable, to something non-monolithic, but gave it low priority.
I gave it low priority, because:

For a user who is downloading an image and running it with qemu,
does not see whether it is monolithic or not.
The user will only notice features like logicals, type, dir, show system etc.
For developers of userland utilities/libraries and parts of the kernel,
it would not matter either whether the kernel was monolithic or not.

> 0.4 is rewritten from scratch on a L4 (like Hurd is written on a Mach 
> kernel or MacOS X on NVU). L4 is choosen because it deos not contains 
> unixism. It boots, it contains first memory management subroutines, but 
> pager is missing.

This will be a bit harder than transforming the 0.3 kernel
(but probably a more interesting/rewarding learning process).
It will be interesting to see how ASTs and IPLs will be implemented now.

Will you actually write everything from scratch?
I integrated/took a lot from various places.
(Some libraries/rtl/starlet and userland ODS-2/RMS from the very first
FreeVMS project, if my memory serves me right.
DFU from DEC with open (enough?) source.
The CMUIP TCP/IP stack.
Something for DCL and EDT from Ozone from www.o3one.org.
Probably more.)

-- 
-Roar

From joel.bertrand at systella.fr  Tue Jul  2 13:02:27 2013
From: joel.bertrand at systella.fr (=?ISO-8859-1?Q?BERTRAND_Jo=EBl?=)
Date: Tue, 02 Jul 2013 13:02:27 +0200
Subject: [FreeVMS] FreeVMS
In-Reply-To: <20130702094130.GE11052@sabre-wulf.nvg.ntnu.no>
References: <001401ce67b9$7e464c30$7ad2e490$@ccsscorp.com>
 <6823d292689a27b0003aec2c0ee9d374@systella.fr>
 <20130702094130.GE11052@sabre-wulf.nvg.ntnu.no>
Message-ID: <51D2B343.1040700@systella.fr>

Roar Thron?s wrote:
> On Thu, Jun 13, 2013 at 07:43:37AM +0200, BERTRAND Jo?l wrote:
>>
>> FreeVMS project was created a long time ago. First kernels (until 0.3)
>> were derivated from Linux kernel (2.4.15 if I remember) and were
>> monolithic. These kernels were bootable but not easely maintenable.
>
> Yes, I know, but it was small enough with few hardware drivers,
> since qemu supported only a few.

	Right, but we need to think about future and portability.

> I would consider it small enough to be further changable/convertible/
> transformable, to something non-monolithic, but gave it low priority.
> I gave it low priority, because:
>
> For a user who is downloading an image and running it with qemu,
> does not see whether it is monolithic or not.
> The user will only notice features like logicals, type, dir, show system etc.
> For developers of userland utilities/libraries and parts of the kernel,
> it would not matter either whether the kernel was monolithic or not.

	Maybe, but I think that stability and maintainability are both crucial 
to have new developers.

>> 0.4 is rewritten from scratch on a L4 (like Hurd is written on a Mach
>> kernel or MacOS X on NVU). L4 is choosen because it deos not contains
>> unixism. It boots, it contains first memory management subroutines, but
>> pager is missing.
>
> This will be a bit harder than transforming the 0.3 kernel
> (but probably a more interesting/rewarding learning process).
> It will be interesting to see how ASTs and IPLs will be implemented now.
>
> Will you actually write everything from scratch?
> I integrated/took a lot from various places.

	No. You have done some years ago a very huge work. All code you have 
written will be reused.

> (Some libraries/rtl/starlet and userland ODS-2/RMS from the very first
> FreeVMS project, if my memory serves me right.
> DFU from DEC with open (enough?) source.
> The CMUIP TCP/IP stack.
> Something for DCL and EDT from Ozone from www.o3one.org.
> Probably more.)

	Regards,

	JKB


From roart at nvg.ntnu.no  Tue Jul  2 16:56:33 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 16:56:33 +0200
Subject: [FreeVMS] Documentation...
In-Reply-To: <004101ce6c6c$0a28b1f0$1e7a15d0$@ccsscorp.com>
References: <004101ce6c6c$0a28b1f0$1e7a15d0$@ccsscorp.com>
Message-ID: <20130702145633.GF11052@sabre-wulf.nvg.ntnu.no>

On Tue, Jun 18, 2013 at 05:37:31PM -0400, Bill Pedersen wrote:
> 
>                 "Yes, we have to write some specifications. But we need to
> design a maintainer that collects all documentations and specifications."

Speaking on which...

I am a bit surprised that no one has mentioned this online documentation yet,
to be found on:
http://bitsavers.trailing-edge.com/pdf/dec/vax/, more specifically
http://bitsavers.trailing-edge.com/pdf/dec/vax/vms/training/
http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/

Here we can find downloadable books, the most interesting may be:
EY-C171E-DP VMS Internals and Data Structures 5.2 1991
EY-F575E-DP VMS File System Internals 1990
EL-00032-00-decStd32 Jan90, an internal Vax Architecture Reference Manual

And to lesser degree:
EY-0016E-ID-0001 VMS Internals Source Listings 1982

Plus, on the web:
http://daviddeley.com/programming/docs/rmsinternals.htm
http://www.sture.ch/vms/rmsint2.txt

-- 
-Roar

From roart at nvg.ntnu.no  Tue Jul  2 16:56:33 2013
From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=E6s?=)
Date: Tue, 2 Jul 2013 16:56:33 +0200
Subject: [FreeVMS] Documentation...
In-Reply-To: <004101ce6c6c$0a28b1f0$1e7a15d0$@ccsscorp.com>
References: <004101ce6c6c$0a28b1f0$1e7a15d0$@ccsscorp.com>
Message-ID: <20130702145633.GF11052@sabre-wulf.nvg.ntnu.no>

On Tue, Jun 18, 2013 at 05:37:31PM -0400, Bill Pedersen wrote:
> 
>                 "Yes, we have to write some specifications. But we need to
> design a maintainer that collects all documentations and specifications."

Speaking on which...

I am a bit surprised that no one has mentioned this online documentation yet,
to be found on:
http://bitsavers.trailing-edge.com/pdf/dec/vax/, more specifically
http://bitsavers.trailing-edge.com/pdf/dec/vax/vms/training/
http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/

Here we can find downloadable books, the most interesting may be:
EY-C171E-DP VMS Internals and Data Structures 5.2 1991
EY-F575E-DP VMS File System Internals 1990
EL-00032-00-decStd32 Jan90, an internal Vax Architecture Reference Manual

And to lesser degree:
EY-0016E-ID-0001 VMS Internals Source Listings 1982

Plus, on the web:
http://daviddeley.com/programming/docs/rmsinternals.htm
http://www.sture.ch/vms/rmsint2.txt

-- 
-Roar