This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1996-04.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | levitte | programming |
|
|
Archive-Date: Wed, 03 Apr 1996 09:58:23 EST
Sender: owner-free-vms@lp.se
Date: Wed, 03 Apr 1996 09:58:14 EST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: free-vms@lp.se
Message-ID: <009A04CC.89B326E0.8@lp.se>
add/nonotify/norepro/conc Free-VMS lurkers <Free-VMS-lurk@lp.se>
================================================================================
Archive-Date: Wed, 03 Apr 1996 10:12:53 EST
Sender: owner-free-vms@lp.se
Date: Wed, 03 Apr 1996 10:09:25 +0200
From: Richard Levitte - GNU on VMS hacker <levitte@e.kth.se>
Reply-To: Free-VMS@lp.se
To: CCPN@LURE.LATROBE.EDU.AU
CC: hamiltons@comics.enet.dec.com, pmoreau@cenaath.cena.dgac.fr, goathunter@LOKI.COM, free-vms@lp.se
Message-ID: <009A04CE.19963B4E.5@e.kth.se>
Subject: Re: Free VMS.
Paul,
>>Absolutelly. I'm interested in such a project (again, refer to my
>>WWW page about it). I think that Hunter Goatley <goathunter@LOKI.COM>
>>is interested as well, or would at least like to be in touch with the
>>project. Other people that come to mind is Carl Lydick and Pat Rankin
>
>I tried accessing your page on this but it returned an error - could
>you please check the URL for me?
I forgot I had reorganised... Anyway, I have reorganised again last night.
The correct URL is now http://www.lp.se/Free-VMS/
>>I have a mailing list prepared for this: levims@lp.se. And yes, before
>>you ask, I may consider a name change!
>
>If no-one has a better idea I suggest creating a mailing list containing
>the name FreeVMS (possibly FreeVMS@lp.se) which we can then announce in
There is a Free-VMS@lp.se now, that may be announced. The correct way
to subscribe is of course to send the following line in the body of a
message to Free-VMS-request@lp.se:
SUBSCRIBE
I'm archiving that list. That list is only meant for developers. I've
also made a list Free-VMS-lurk@lp.se for those who just want to be
informed. I can at any time create whatever other list may be required.
>resources (people) involved and plan a way to come up with a minimum
>working system ASAP. If we cannot at least a generate 'toy' system
>in a reasonable time frame for people to play with, then interest in
I agree on that.
>It is a real pity that we are so widely spread and cannot get together for
>a good discussion! I guess the next best thing is to make an archive
Eh? Have you never made such a discussion over a private IRC channel?
Hell, I've just had a constituting meeting for a new association using
that media. Works very well. There are others that might be used the
same way, even if it's not really the common way to use it.
>somewhere where we can contribute our ideas. To start with this might
>be simply a definition of what a minimum system would consist of?
Well, since Free-VMS@lp.se is archived...
--
+--------------------------------------------------------------------+
! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 !
! Spannvägen 38, I ! fax: none for the moment !
! S-161 43 Bromma ! Internet: levitte@e.kth.se !
! SWEDEN ! !
+-<a href="http://www.e.kth.se/~levitte/gnu/gnu.html">GNUish VMS</a>-+
You may not add me to a commercial mailing list or send me commercial
advertising without my consent!
See http://www.e.kth.se/~levitte/anti.html for further reference.
================================================================================
Archive-Date: Thu, 04 Apr 1996 00:40:27 EST
Sender: owner-free-vms@lp.se
Date: Thu, 04 Apr 1996 08:36:20 +1000
From: Paul Nankervis <CCPN@LURE.LATROBE.EDU.AU>
Reply-To: Free-VMS@lp.se
Subject: Re: Free VMS.
To: levitte@e.kth.se
CC: hamiltons@comics.enet.dec.com, pmoreau@cenaath.cena.dgac.fr, goathunter@LOKI.COM, free-vms@lp.se
Message-ID: <01I34YH22E9E985Q8Y@LURE.LATROBE.EDU.AU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Fellow VMSers,
I offer the following as a basis for a charter posting to our
new mailing list. Please feel free to modify or comment on any
of it.
Why Free-VMS?
If you have followed comp.os.vms you may have noticed some
disatisfaction with DEC's marketing of VMS. Although DEC has no such
policy many customers seem to feel that DEC would prefer them to run
some other operating system instead. Of course this is probably just
the result of a few over-zealous employees and some biased
advertising, but many VMS customers find it rather frustrating. This
subject is raised periodically but seems to be without resolution.
Free-VMS would not be subject to DEC's marketing.
Wouldn't this hurt DEC?
We believe that a Free-VMS would encourage the use of VMS and that
other vendors may even get behind it. These things would only
increase DEC's sales! Certainly this would be better than DECs
current strategy of selling other vendor's operating systems such as
NT.
Why not Unix?
Unix is a fine operating system but its main advantage has been that
it is portable and therefore supported by many vendors. Not
surprisingly it has become somewhat of a standard. However there are
many who feel that it is not well designed in areas such as program
error checking and that VMS offers worthwhile features such as
clustering and uniform file locking which are missing from most of
the Unix Variants. In short many prefer VMS even in the face of 'The
Unix Standard'!
Which Hardware?
One of the problems with the current VMS is that it is implemented
only on DEC hardware. Of course the explosion in the availability
and power of PCs has meant that there are many cheaper boxes which
meet all the requirements of a sophisticated system like VMS, but it
is simply not available! However it would be foolish to repeat the
mistakes of the past by simply targeting PCs! Any effort such as
this should have portability as a primary goal! It should be made to
run on all current popular 32 and 64 bit architectures as well as
being capable of running on tomorrows 128 bit computers when
required!
How can it be portable?
The main way of acheiving portability is by defining everything in
terms of a HLL. In this case probably C. Previous VMS standards were
rigidly defined in terms of VAX words, longwords, quadwords, etc
which all had set numbers of bits and which didn't always make sense
on other architectures. By defining data structures in a language
such as C, compatibility with VAX can be achieved on 32 bit systems,
and yet other architectures can use more natural sizes. Although
this rules out strict binary compatibility it will be a goal of this
project that HLL program sources can be universal. Naturally we
expect that existing VMS C programs should be portable to this
system with little or no effort!
What is planned?
At this stage we are only trying to define the minimum requirements
for a system such as this. Then we would determine what tools and
resources are available to make a judgement about whether we should
proceed. Of course the plan would be to get even a simple prototype
out the door as soon as possible to raise interest.
What tools?
This is a large project and we recognise that it will only be
possible by using as much existing code as possible. Fortunately
there is software such as the MACH Kernel already written and
debugged which will reduce the load considerably! And it has the
same aims of portability! Undoubtably there is other software with
could be similarly adopted. Examples are DCL emulators, editors,
compilers, Files-11 code and so on.
What would be the minimum?
The absolute mimimum would probably just consist of a core set of
system services built on top of MACH, a file system, RMS, a login
process and some DCL. It would not include many of the features we
have come to know and love like security (!), logical names,
editors, DECnet, queues, run-time libraries, etc. If a core system
could be produced then many of these items would almost certainly
flow on relatively quickly.
How can this project be segmented?
Many of the items required for a minimum system can be developed in
parallel under other systems. For example the AUTHORIZE utility
could be developed and tested on a real VMS system before any other
code was produced. Similarly it should be possible to develop much
of the RMS, linker and other code ahead of time.
What now?
This project can happen if enough people get behind it. However it
is a large project being planned by volunteers only! There is a
reasonable chance a working system will never see the light of day!
Even a sufficient number of negative comments could stop it dead
now! But with enough support this project is sure to get off to a
good start!
How can I help?
Even an encouraging comment will do! But if you are in a position to
contribute ideas, do design work, or write code then your input is
valuable. If you know of potential sponsors or have a scheme to
convince DEC to release source code even better!
Paul Nankervis
Paul@lin.cbl.com.au
Paul.Nankervis@ISSC.ISSC.secv.telememo.au
================================================================================
Archive-Date: Thu, 04 Apr 1996 12:06:08 EST
Sender: owner-free-vms@lp.se
Date: Thu, 04 Apr 1996 12:05:50 EST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A05A7.875F7B60.83@lp.se>
Subject: The charter [ was: Re: Free VMS. ]
Thank you, Paul, for the charter you provided. I have added it to the
Free VMS WWW pages (http://www.lp.se/Free-VMS/Charter-19960404.html).
--
Richard Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma
Tel: +46-8-26 52 47, (via PI) +46-8-783 19 61; Fax: +46-8-783 20 46
PGP Key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://www.lp.se/~levitte for my public key.
================================================================================
Archive-Date: Thu, 04 Apr 1996 15:20:41 EST
Sender: owner-free-vms@lp.se
Date: Thu, 4 Apr 1996 8:21:03 -0500 (EST)
From: Bob Koehler <KOEHLER@bessta.gsfc.nasa.gov>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <960404082103.7df@bessta.gsfc.nasa.gov>
Subject: subscribe
subscribe
================================================================================
Archive-Date: Fri, 05 Apr 1996 11:25:40 EST
Sender: owner-free-vms@lp.se
Date: Fri, 05 Apr 1996 11:25:27 EST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A066B.0DC7B460.1@lp.se>
Subject: silence...
Status of this message: not very serious.
This list isn't sproutling with ideas right now, is it? ' guess it's
the Easter vacations, huh?
Anyway, all I wanted to say is: Happy Easter to you all!
See you back on this channel after the vacations.
--
/Richard Levitte, co-owner and manager of Free-VMS@lp.se
levitte@lp.se
================================================================================
Archive-Date: Fri, 05 Apr 1996 16:10:55 EST
Sender: owner-free-vms@lp.se
Date: Fri, 5 Apr 1996 15:04:51 +0200 (MET DST)
From: Gotfryd Smolik <gotfryd@stanpol.zabrze.pl>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: 386 modes
Message-ID: <Pine.LNX.3.91.960405143044.632A-100000@irys.stanpol.zabrze.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Ok, when list is up...
From Glenn: everhart@star.enet.dec.com
>If the idea were to write something anew, too, it need not have all the
>4 level scheduling dependence. I would suggest you think about the way
... but on 2 level bug in kernel must crash system - then 4 level
architecture MAY be the good way for debug !
I don't love un*x construction...
From: Robert Koehler <rkoehler@csc.com>
>There are 4 useable levels in the Intel architecure. However,
>VMS's memory management by page scheme does not match Intel's memory
>management by segment.
Some elements do: the segment architecture was introduced on '286,
and I don't know of *real* and *good* utilisation of the feature...
Yes, if not other accessible - then this way was generated EMS
emulator - very poor (also because missing switch virtual->real mode).
When the paging scheme was introduced in '386 then apear some real
utilites for it. ONLY paging is the way to make real swap&page mechanism.
Paging on 386 are limited in distinction of mode (only two type:
user and not-user) and access (read and write), ok.
The control access to memory may be supplement if define
segment 386 as the memory section - then the section may be
limited to all four mode and access.
> Interrupt and exception handling, seperated in VMS,
>are mixed togther by Intel's architecture.
> The number of interrupts used by VMS may not be present.
Someone sometime write on info-vax that the *very* big problem
may be (yes, later was the "why not VMS on Intel" thema !)
the not implemented into x86 interrupt vector and his poor solving
in the PC computer (also old Intel's chip CAN serve up to 255
level hierarhical interrupts).
Regards -
Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! GS@stanpol.zabrze.pl
(INFO-VAX & other maillist only, /NONEWS).
=====================================================================
================================================================================
Archive-Date: Fri, 05 Apr 1996 16:37:25 EST
Sender: owner-free-vms@lp.se
Date: Fri, 5 Apr 1996 9:37:58 -0500 (EST)
From: Bob Koehler <KOEHLER@bessta.gsfc.nasa.gov>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <960405093758.d27@bessta.gsfc.nasa.gov>
Subject: RE: 386 modes, DEC copyrights
>From Gotfryd:
>
>From: Robert Koehler <rkoehler@csc.com>
>
>>There are 4 useable levels in the Intel architecure. However,
>>VMS's memory management by page scheme does not match Intel's memory
>>management by segment.
>
> Some elements do: the segment architecture was introduced on '286,
>and I don't know of *real* and *good* utilisation of the feature...
> Yes, if not other accessible - then this way was generated EMS
>emulator - very poor (also because missing switch virtual->real mode).
> When the paging scheme was introduced in '386 then apear some real
>utilites for it. ONLY paging is the way to make real swap&page mechanism.
> Paging on 386 are limited in distinction of mode (only two type:
>user and not-user) and access (read and write), ok.
> The control access to memory may be supplement if define
>segment 386 as the memory section - then the section may be
>limited to all four mode and access.
>
IMHO, a way to handle this is instead of using page protection, protect all
"pages" in a segment by making the linker sort VMS PSECTS according to the
attributes which Intel segments can handle: readable data segments, writeable
data segments, code segments, assigning segment registers as appropriate. Then
map Intel privilege levels 0 through 3 to VMS kernel through user (same
numeric order anyhow). Some of the other PSECT concepts such as OVR vs. CON
are really just passing information from the compiler to the linker and not of
concern to memory management.
The problem with this approach is that it is not a small modification of
existing VMS memory management approach, it is a dramatic change, and it
may have significant implications in preserving the existing API, especially
in the system service routines which interact with memory management.
However, on another topic, I don't think anyone should spend too much time on
any of this unless DEC makes a clear statement reguarding their copyrights.
================================================================================
Archive-Date: Sat, 06 Apr 1996 13:18:02 EST
Sender: owner-free-vms@lp.se
Date: Sat, 06 Apr 1996 21:17:37 +1000
From: Paul Nankervis <CCPN@LURE.LATROBE.EDU.AU>
Reply-To: Free-VMS@lp.se
Subject: Long live Free-VMS!!!
To: Free-VMS@lp.se
Message-ID: <01I38HMM1N3M98658K@LURE.LATROBE.EDU.AU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
My feeling is that a project such as this is best tackled by defining
an absolute minimum requirement and determining if we have the
resources to do it. But I suspect that even the definition of such a
minimum might not reach consensus! For example some folk may
well consider the implementation of a DCL emulator under another
operating system to meet all of their requirements. However I for
one am a programming type - so my requirements go a little
deeper! I would hope that ultimately we could develop something
which would run on my PC more or less the same C sources as
'the big box' at work.
Like all good projects of this type it can probably only result from
the efforts of a small dedicated group who do most of the initial
work for others to develop and improve on further. Whether we even
have the resources to do the initial minimum project is debatable.
I would like to be involved but don't know how much time I can give
as I have heavy work commitments and a real life!! :-) Probably like
most of you! Still...
So what is the minimum? I know that most people who have talked
about this idea assume that it would be based on the Mach Kernel. I
too would hope that this would ultimately be the case as use of the
Mach kernel would make writing the system executive relatively
easy and would produce a portable, efficient and flexible operating
system. But I suspect that a better interim goal might be to build
a system prototype on top of an existing operating system - a sort
of system emulator (anyone remember AME for RSX software?) The
reason I say this is because then we would not have to write and
debug things like the file system from scratch before doing anything
else. Instead our file system could initially just remap calls to
the underlying host system (imagine RMS indexed files implemented
as calls to DBM...:-) ) In this way it might be possible to get a
minimum (OK - primitive) system going ASAP. At least enough to
encourage more development.
Initially I imagine keeping things as simple as possible. This would
mean keeping things functional and not implementing some of the
niceties like privilege checking and multiple modes. In the case of
system services this probably means only the core routines like
$ASSIGN, $QIO[W], $DASSGN, $CREPRC, $DELPRC, $CRETVA, $CRMPSC,
a handful of others and an image activator. There would need to be
enough file system present to create, access and delete files and
enough RMS to handle indexed and sequential files - again probably
initally as calls to an underlying system. Someone would have to
write a decent DCL and a couple of utilities like LOGINOUT and
AUTHORIZE using the above minimal subset of system calls.
For a compiler it might be possible to use the same compiler as the
underlying host and write a linker smart enough to understand
whatever object format it uses to generate system executables.
Now I admit that this idea is a simplistic thumbnail sketch of
a rather large complex piece of work. But I present it as a real
possibility and hope that it will provoke a few more thoughts
out there. What do you think?
Paul Nankervis
paul@lin.cbl.com.au
================================================================================
Archive-Date: Sat, 06 Apr 1996 21:07:17 EST
Sender: owner-free-vms@lp.se
Date: Sat, 06 Apr 1996 21:06:59 EST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A0785.75953AC0.1@lp.se>
Subject: Re: 386 modes
>
>Ok, when list is up...
>
>From Glenn: everhart@star.enet.dec.com
>
>>If the idea were to write something anew, too, it need not have all the
>>4 level scheduling dependence. I would suggest you think about the way
>
>... but on 2 level bug in kernel must crash system - then 4 level
>architecture MAY be the good way for debug !
Well, if we follow the main idea (which is written in the charter posted
not long ago), which is to build everything on top of Mach, we will probably
not need to care at all about CPU levels. On a Mach system, different
servers are quite well separated, and if one dies, the rest of the system
does not necessarelly have to crash. With some luck, the crashing server
can just be restarted. Of course, a server should not crash at all, and
that's the goal we're looking for.
I think the first thing we all should do (or at least those of us who aren't
yet that knowledged in Mach (and I sure need to take a new look at it,
because it's been a long time since I studied it)) is to take a closer
look at Mach. I don't know the URL off-hand, but I know it's quite easy
to find with any search engine on the web today.
> I don't love un*x construction...
That's why we're here, isn't it? :-)
>From: Robert Koehler <rkoehler@csc.com>
>
>>There are 4 useable levels in the Intel architecure. However,
>>VMS's memory management by page scheme does not match Intel's memory
>>management by segment.
>
> Some elements do: the segment architecture was introduced on '286,
>and I don't know of *real* and *good* utilisation of the feature...
Ahem, I don't know what kind of segment you mean, but the Intel
architecture has had had 64K segments since the 8086. What was introduced
with the 286 was protected mode! In any case, since the most probable
way to solve this is STILL with the Mach kernel, what do we have to care
about the x86 segments? Mach on 386 and up uses one 4GB flat memory chunk!
What I have been wondering is if it's possible to make the same split
if memory as VMS does. As you all probably know, there are 3 memory section:
P0 1GB (0x00000000-0x3FFFFFFF, user programs)
P1 1GB (0x40000000-0x7FFFFFFF, DCL, Debugger, other prived
images)
System 2GB (0x80000000-0xFFFFFFFF, System images)
(yes, I know, it looks slightly different on the Alpha) I'm not even sure
we would have to bother about this in reality...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47, (via PI) +46-8-783 19 61; Fax: +46-8-783 20 46
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://www.lp.se/~levitte for my public key.
================================================================================
Archive-Date: Tue, 09 Apr 1996 15:08:42 MET-1MET DST
Sender: owner-free-vms@lp.se
Message-ID: <199604091155.NAA11132@vbormc.vbo.dec.com>
Date: Tue, 9 Apr 96 13:55:39 MET DST
From: "Scott HAMILTON, Digital U.K. CSC, DTN:833 3538" <hamiltons@comics.enet.dec.com>
Reply-To: Free-VMS@lp.se
To: "free-vms@lp.se"@vbormc.vbo.dec.com
Subject: Minimum????
hi ya all,
I'd like to start to expand on the minimum requirements, but I still
have some questions as I don't know the Mach kernel, and only
FTP'd it across this morning!!!! Firstly is this going to use
the same data structures as OpenVMS does at the moment (it does
make sense to use these, since it is an aim to acheive the same
functionality) for example if I have some code that uses a FIB block
and ACP QIO calls, is it intended that this will work????
* System initalisation
So do we have a SYSBOOT.EXE that sizes memory to produce a PFN database,
reads VAXVMSYS.PAR and load's SYS.EXE and all the other required
loadable images?? That provides primitive filesystem and console IO
functions for BUGCHECK crashes???
* Filesystem
To have VMS type file-specifications etc from DCL you need the Files-11
ODS-2 file system and VMS device naming scheme.
The file system is implemented using the Files-11b XQP in P1 space
(F11BXQP.EXE and CTL$_xxxx symbols) it uses
1. AST's
2. distributed lock manager (not necessarily distributed??)
3. device drivers
The distributed lock manager uses;
4. Resource blocks
5. Lock blocks
6. SCS services (optional)
The device drivers need
7. DDB, UCB, IRP, VCB, AQB, WCB, CCB, FCB, PCB
8. SYS$QIO
You also need SYS$IMGACT to merge the F11BXQP.EXE into P1 space, at
process creation (SYS$CREPRC) (PCB and PHD) and memory management
(PFN database, PHD, PCB, the Pagefile FCB etc). I accept that the
Mach kernel will provide us with the memory management facilities, and
then we need just modify the MACH device drivers to look more like VMS device
drivers, but should we use IRP and UCB's etc....
* System services
What are the most needed??
1. $CREPRC
2. $CREVTA
3. $EXPREG
4. $QIO
5. $ASSIGN
6. $ALLOC
7. $CANCEL
8. $CLREF
9. $CMEXEC
10. $CMKRNL
11. $CRELNM
12. $CRELNT
13. $CREMBX
14. $ENQ
15. $DEQ
16. $DCLEXH
17. $DCLCMH
18. $DCLAST
19. $EXIT
20. $HIBER
21. $MOUNT
22. $PUTMSG
23. $SETEF
24. $RESUME
25. $WAKE
26. $READEF
27. $TRNLNM
28. $WAITFR
* RMS
I think firstly getting sequential file organisation that does the
proper thing with FAB and RAB's and supports
$OPEN, $CONNECT, $GET, $PUT, $CLOSE and has NAM, FAB and RAB data structures
and performs shared access with record locking will be enough for quite
a long awhile.
* Login process
To create a interactive process requires JOB_CONTROL process to accept
the unsolicited terminal input... This would not be too difficult once
the above system services and devices where present...
* DCL
This is a little harder, the mysteries of DCL, unless you've read large
chunks of VMS source code, the majority of this little beasty is undocumented
But this has a advantage that it can be implemented anyway desired (now's
the time to redesign all those little bit's people always wanted in
DCL...) again once all the above are in place it shouldn't be that difficult.
Unfortunately I don't have access to 386 blah blah blah machine, so I
haven't had time to "play" with the MACH kernel...
Ciao for now
Scott, Esq.
================================================================================
Archive-Date: Tue, 09 Apr 1996 16:19:59 MET-1MET DST
Sender: owner-free-vms@lp.se
Date: Tue, 09 Apr 1996 16:19:48 MET-1MET DST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A09B8.D63263A0.1@lp.se>
Subject: Re: Long live Free-VMS!!!
>From: Paul Nankervis <CCPN@LURE.LATROBE.EDU.AU>
>My feeling is that a project such as this is best tackled by defining
>an absolute minimum requirement and determining if we have the
The absolute minimum would probably be to have all system routines
(SYS$*) built, since mostly everything can be built on top of them.
This means that the underlying stuff (memory management, paging policies,
...) would have to be written. This can not be done overnight.
>well consider the implementation of a DCL emulator under another
>operating system to meet all of their requirements. However I for
As a matter of fact, this could probably be done in parallell,
just as all the GNU utilities are build on top of Unix, but should
work with Hurd as well...
>one am a programming type - so my requirements go a little
>deeper! I would hope that ultimately we could develop something
>which would run on my PC more or less the same C sources as
>'the big box' at work.
Yep. I want my port of Emacs to compile without change (virtually)
on Free VMS :-).
>I would like to be involved but don't know how much time I can give
>as I have heavy work commitments and a real life!! :-) Probably like
>most of you! Still...
Well, I don't want to live in a world where there's only Unix and
M$ OSes. VMS is part of my life.
>system. But I suspect that a better interim goal might be to build
>a system prototype on top of an existing operating system - a sort
OK, that's going the other way (top-down instead of bottom-up).
What stops us from doing both in parallell? On group working
on the system executable while another works on the user utilities
and the libraries (that's more or less what DCL and RMS are...).
I know a few people who have ideas on how to build a good DCL.
If someone wants to do this, I could create other discussion
lists for you (I would probably take part in most of them).
>minimum (OK - primitive) system going ASAP. At least enough to
>encourage more development.
Most probably.
>niceties like privilege checking and multiple modes. In the case of
>system services this probably means only the core routines like
>$ASSIGN, $QIO[W], $DASSGN, $CREPRC, $DELPRC, $CRETVA, $CRMPSC,
>a handful of others and an image activator. There would need to be
That's approximatelly the way I thought of too. I guess we should
make up a task list.
>enough file system present to create, access and delete files and
Even a DOS system has that :-). There's a problem with file names
though...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47, (via PI) +46-8-783 19 61; Fax: +46-8-783 20 46
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://www.lp.se/~levitte for my public key.
================================================================================
Archive-Date: Fri, 12 Apr 1996 14:36:04 MET-1MET DST
Sender: owner-free-vms@lp.se
Date: Fri, 12 Apr 1996 14:35:38 +0200 (MET DST)
Message-ID: <199604121235.OAA05708@sid1.cenaath.cena.dgac.fr>
From: PMOREAU@CENA.DGAC.FR (Patrick MOREAU, CENA Athis, Tel: (1) 69.57.70.40)
Reply-To: Free-VMS@lp.se
X-MX-Warning: Warning -- Invalid "To" header.
To: SID1::Free-VMS@lp.se
CC: PMOREAU@CENA.DGAC.FR
Subject: Emerald project
Hi all,
I'm trying to find some documentation about Digital's Emerald project (a port
of VMS upon Mach 3.0 kernel on VAX) but Altavista don't seems able to find
useful links.
Are some papers about this project available for the "public" ?
Regards,
Patrick
===============================================================================
pmoreau@cena.dgac.fr (CENA) ______ ___ _ (Patrick MOREAU)
moreau_p@decus.decus.fr(DECUS) / / / / /| /|
CENA/Athis-Mons FRANCE / /___/ / / | / | __ __ __ __
BP 205 / / / / |/ | | | |__| |__ |__| | |
94542 ORLY AEROGARE CEDEX / / :: / / | |__| | \ |__ | | |__|
===============================================================================
================================================================================
Archive-Date: Sun, 14 Apr 1996 03:19:06 MET-1MET DST
Sender: owner-free-vms@lp.se
From: EVERHART@GCE.MV.COM
Reply-To: Free-VMS@lp.se
Date: Fri, 12 Apr 1996 20:40:56 -0400 (EDT)
To: Free-VMS@lp.se
Message-ID: <960412204056.e1@GCE.MV.COM>
Subject: RE: Emerald project
The Emerald project has been rumored to have been a VMS ported to Intel
and made more portable thereby. It is probably true that Digital could
build a macro32 compiler that spit out Intel...but there's nothing
kicking around that I've heard of.
I will add that I believe trying to use Digital code to build an implementation
of the user and system interface is a mistake. Such code is quite unlikely
to be free; rather, a new implementation (possibly along cleaner and possibly
quite different internal lines) is to be desired.
I will look around in case any papers that can be disclosed exist; there
is a papers section in the DecWest lab someplace; I grabbed a bunch of
them for the sig tapes a few times ago. However, there were many more.
Only real old timers seem to remember anything about it though. I've seen
enough to know something existed by that name, but nothing about details.
If anything publishable exists, I'll look...
glenn
================================================================================
Archive-Date: Sun, 14 Apr 1996 19:05:52 MET-1MET DST
Sender: owner-free-vms@lp.se
Date: Sun, 14 Apr 1996 19:05:47 MET-1MET DST
From: levitte@lp.se
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A0DBD.DA74AAA0.1@lp.se>
Subject: RE: Emerald project
>The Emerald project has been rumored to have been a VMS ported to Intel
>and made more portable thereby.
I don't know about the Intel part, but Emerald as a VMS build upon Mach 3.0).
I have copies of a paper describing it, and telling how far they came,
and as far as I remember what the problems were.
>I will add that I believe trying to use Digital code to build an implementation
>of the user and system interface is a mistake. Such code is quite unlikely
>to be free; rather, a new implementation (possibly along cleaner and possibly
>quite different internal lines) is to be desired.
That's my opinion too.
>I will look around in case any papers that can be disclosed exist; there
It exists. I'll try to dig it up (it's somewhere at home), and given time
I will scan the pages and make them available, provided there's nothing
making it illegal to do so.
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47, (via nation.se) +46-8-21 24 90; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://www.lp.se/~levitte for my public key.
================================================================================
Archive-Date: Tue, 16 Apr 1996 08:44:32 MET-1MET DST
Sender: owner-free-vms@lp.se
Message-ID: <199604160712.QAA04608@kekux.kek.jp>
Date: Tue, 16 Apr 96 16:43:39 GMT+9:00
From: "Makoto Shimojima, Univ of Tsukuba/CDF" <mako%utkbp.decnet@kekux.kek.jp>
Reply-To: Free-VMS@lp.se
To: free-vms@lp.se
Subject: RE: Emerald project
> I have copies of a paper describing it, and telling how far they came,
> and as far as I remember what the problems were.
Perhaps, this is it?
| Date: 26 Jul 1994 00:50:24 GMT
| From: mogul@pa.dec.com (Jeffrey Mogul)
| Organization: DEC Western Research
|
| %A Cheryl A. Wiecek
| %A Christopher G. Kaler
| %A Stephen Fiorelli
| %A William C. Davenport, Jr.
| %A Robert C. Chen
| %T A Model and Prototype of VMS Using the Mach 3.0 Kernel
| %P 187 - 204
| %I USENIX
| %B USENIX Workshop on Micro-Kernels and Other Kernel Architectures
| %D April 27-28, 1992
| %C Seattle, WA
| %W Digital Equipment Corporation
|
| According to the paper, the prototype could actually execute
| "some existing VMS non-privileged binary images" (this is on a VAX).
I have not read it, though; I have just asked a University librarian
to get a copy of it. Now, if the authors had an online copy...
mako
(mako%utkbp.decnet@kekux.kek.jp)
PS: While I was browsing through my archives, I came across an interesting
thread (well, only some part of it, as I cannot find the beginning of
the thread and I am not sure where the end is) titled "Alpha vs Pentium
60/90" that took place in comp.os.vms and vmsnet.alpha news groups in
December 1994 and January 1995. Is anyone interested in (re-)reading it?
I have a total of 33 articles, 154 blocks, though I think I can squeeze
it a bit.