Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!necntc!dandelion!ulowell!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: DOMAIN/OS Questions
Message-ID: <3a79abb4.c366@apollo.uucp>
Date: 24 Feb 88 14:04:00 GMT
References: <5400014@iuvax>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 99

In article <5400014@iuvax> jec@iuvax.cs.indiana.edu writes:

>	1.  Will 'stty' work the way it works under UNIX?

Yes.  In fact, the whole TTY code has been modified/rewritten to support
standard Unix functionality.

>	2.  Will a.out.h exist (and make sense) to programs
>            that depend on this sort of thing (Andrew from
>	    CMU seems to need this, for instance)?

The compilers that ship with DOMAIN/OS generate object files in System
V COFF format.  This is not "a.out" format, but it is standard, and we
needed/wanted the flexibility it offers.

>	3.  Will there be a /vmunix type of file so that
>	    programs like xload will work?

As I'm sure most people know, our kernel is not derived from either the
AT&T or BSD Unix kernel source.  Thus, while we have a file that fills
exactly the same role as "/vmunix", it's likely not to be what you want.
This feature falls into the same category as "/dev/kmem".  We don't do
it, but we have, or intend to have, procedural interfaces for doing the
same thing.

>	4.  Will there be an assembler?

Answered elsewhere.

>	5.  Will you be able to disable dynamic libraries
>	    so that things like 'undump' will work (TeX
>	    distribution)?

Not something that I know of that we've considered.  I imagine that
one could always have bound in global libraries with programs, but
perhaps that results in large object files.  Seems like it'd be easy
for us to make the global libraries available in "ar" format, but
I don't think that's currently in our plans.                    

>	6.  Will source code be available to universities?

Someone else answered this, but I don't know if that answer is correct.
You'd have to check with someone who understand this sort of policy.

>	7.  Will NFS allow files to be compiled and executed
>	    from remote non-Apollo filesystems?

This limitation persists.  The former (compilation) is conceptually easier
to fix; the problem arises from the fact that the library that generates
object files using mapping, rather than Stream I/O to do I/O.  The latter
(execution) is harder to deal with since programs are executed by mapping
(parts of) the object file into the address space.  Not an insurmountable
problem, but one that can't be easily solved without some efficiency
penalty (e.g. making the program loader copy the executable to a local
temp file first).

>	8.  Will the /etc/passwd file be the real source of
>	    account information and will it be in a readable
>	    form?   Will the password field contain the
>	    encrypted password?

Yes and yes.  However, modifying the information will still not be done
by editing "/etc/passwd".  In short, this is the case because in networks
of the size we support, such a scheme for maintaining account information
is simply inappropriate.  DOMAIN/OS supports a distributed, replicated
Registry which contains all the logical contents of "/etc/passwd" (plus
some more things, like information about who's allowed to change what
account information).  The Registry is implemented using NCS.  Access
and update of account information is done via NCS/RPC.  The standard
"getpw" calls have been reimplemented to make remote calls to Registry
servers.

>	9.  Will prsvr be replaced in favor of lpd (for
>	    Berkeley printing) instead of lpd having to
>	    rely on prsvr?

I don't have the answer here.

>	10. Will Pascal handle Berkeley pascal syntax?

Not that I know of.  Will Berkeley Pascal support Apollo Pascal syntax :-)

>	11. Will subnetworking work?

Subnetting works and has worked for some time.

>	12. Will NeWS/X be available?

X will be at the core of the new DOMAIN/OS user environment.  (The DM
features/environment will continue to be supported, coexistent with X,
for compatibility.) I have heard nothing about any plans to support NeWS,
although if it's as wonderful, portable, and open as everyone says (I'm
being serious, not cynical), I'm sure someone else could get it running
on Apollos, if they haven't already.

-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin