Download by Platforms & Versions

Earlier versions of E have
been tested and run on MSWindows (95, 98 FE, NT, 2K), and Linux. It should
run on other UNIX platforms as well, given an adequate version of Java
and bash (see below). It should also run without problems on MSWindows
98 SE and on ME, but as far as we are aware, no one has tried this. If
you experience any problems, or have any other informative experiences,
please let me know, or report
a bug.

The Installing links below describe how to install, and run various
forms of the binary distribution. The Building links describe how
to build E from the source release. The Download links will download
each corresponding form of the release to your machine.

Highlights of this Version

As each of these issues are discussed in email or in the bug tracking
system, we will link the paragraphs below to the relevant roots.

E 0.8.10alpha1 is
the first version of E to simultaneously be

Distributed (hence no "sl-" prefix, as explained
below). This version implements the 2vat subset of the much improved
CapTP protocol that's
been on the drawing board for so long. Chief among the CapTP improvements:
We now have full promise
pipelining. Since we've postponed making the 3vat introduction
cases work, we have instead made them fail clean, and verified that
they do so.
( Track
this issue... )

This version also incorporates Bill Frantz's improvements to VatTP,
merged from the branch release 0.8.9.1b. Between the new VatTP and
the new CapTP, we are more confident than ever in our distributed
security. (And so this is an "E" rather than a "daffE",
as explained below.)
( Track
this issue... )

Persistent (hence no "tl-"
prefix). The version has an early, experimental preliminary form of
support for identity persistence. With identity persistence,
the application still has to do all the "manual" work to
save an restore object state, but the app can now securely reassociate
old persistent identities (as designated by exported SturdyRefs and
<cap:...> URI strings) with the manually revived objects. To
aid in this manual work, E programs can use the new Serializer
and Unserializer,
which default to rules suitable for checkpointing and reviving persistent
object state. Not yet ready for prime time.
( Track
this issue... )

Confining (hence no "otc-" prefix). As with 0.8.9t
and 0.8.9t.1a, *.emakers are imported with no real authority to affect
the world outside themselves. All authority must be granted, and so
can be granted according to POLA.
Nothing new here, but we've never had this in a distributed version
of E before.( see Mark Seaborn's thoughts on a module
system for E )

This issue appears again at a higher layer: Marc Stiegler is preparing
an all out assault on the caplet environment -- gui support
for interactive POLA authorization of untrusted applications (themselves
represented as emakers).( Track
this issue... )

Many tool improvements:

The evalServer enables remote evaluation of expressions, and
the reporting back of the results. This is suitable for remote Elmer-like
command line interaction (though Elmer hasn't yet been changed to
use it), simulated command line interaction (as in the new Updoc),
or those needing to bootstrap up multi-vat computation (ie, it should
replace eBrowser's current use of the vatMaker).
( Track
this issue... )

Updoc has been
extended to do multi-vat testing, and to properly obey blockAtTop(),
continueAtTop(), and exitAtTop() messages sent by the scripts being
tested. In combination, this has enabled us to write replayable regression
tests of CapTP functionality. Unfortunately, in the process, we've
temporarily lost the ability to iterate of a directory tree.
( Track
this issue... )

It now does intelligent indentation based on the lexical structure
of the language. (Actually, it currently parses as well as lexes,
but it should only need to lex.) (Note: Elmer now uses this indenter
also, but neither properly unindents closing brackets.)

The first syntax error causes the offending code to be selected
in the editor, leading to a more Smalltalk-like rapid correction
loops.

It spins off a separate vat to calculate the left and right outline
panes in the background whenever the source has changed. Even though
the panes are, at any moment, often slightly stale, the effect works
amazingly well.

Just coming in under the wire, eBrowser now supports drag-n-drop.
Both among eBrowsers, and also between eBrowser and the rest of
the desktop.

Bug
Tracking. As you can see from all these "Track this issue..."
annotations, due to Steve Jenson (Thanks!), starting with this release,
we are making extensive use of the bug tracking system. He had us
try several before we selected the SourceForge bug tracking software.
We selected this one because it made life easiest for someone who
had just encountered a bug and wanted to report it, without having
encountered the bug tracking system before: new bugs can be entered
without reading any documentation or starting an account. So, everyone,
please make use of this convenience and report problems as you find
them.

Language improvements:

The new, much improved, Seaborn-Karp when-catch-finally expression:

In "when (x) -> done(y) {...", the success
case will only see a y that's the same as x.
Further, a remote promise only resolved once per vat, and so we
can't get an intra-vat divergent resolution inconsistency. (We all
agree that we can't prevent a malicious vat from causing an inter-vat
inconsistency.) (*** need to find email link)

The syntax and semantics are now more parallel to try-catch-finally:
there can be a chain of catch clauses followed by an optional finally
clause. These catch not just a broken resolution, but any problems
thrown by the success clause. (*** need to find email link)

The when-catch-finally expression evaluates to a promise for the
value its done function will return. (The done function is the result
of expanding everything to the left of the "->".)
(*** need to find email link)

Swinging Vats. We figured out and solved (due to Dean, thanks!)
a terrible lurking concurrency conflict between E's vat-scheduling
assumptions vs AWT/Swing. We now have front-end ("fe") vats,
that execute in the AWT-Event thread and use the AWT Event queue for
their turns, and back-end ("be") vats, that have their own
thread and queue. All synchronous interaction with AWT and Swing widgets
should happen only in fe vats.( Track
this issue... )

getOptMeta(brand).
CapTP is now correctly using getOptMeta(brand) for opaque rights amplification
so that a given instance of a CapTP system will recognize and see into
its own remote pointers, but the remote pointers of another instance
(or of a different CapTP-like system) will be as opaque to it as a local
promise. (*** need to find email link)

Variants and Subsets of E

A complete E system is persistent,
distributed, and capability-secure both within and between processes.
Incomplete variants of E
are tagged by which of these features are left out.

Feature

Prefix if
feature is absent

What it stands for

Persistent

tl-

Time-Local

Distributed

sl-

Space-Local

Local
capability security

otc-

Only-Trusted-Code

Distributed
capability security

daffE

Distributed Application FrameworkForsaking Encryption

A non-persistent E is called
time-local since an object only exist as long as its hosting process
does. A non-distributed E
is called space-local if an object and all references to it only
exist within its hosting process.

Eby definition provides
distributed capability-security -- the ability for objects in mutually
suspicious processes to safely cooperate. If it looks like E
and it quacks like E, it
might be a duck; but if it doesn't provide distributed capability security,
it's not E. A system that's
otherwise equivalent to E,
but doesn't provide distributed capability security, is called daffE.
A distributed E can only
be implemented by means of strong crypto, of course, for which we are
using code derived from the Cryptix
library (in accord with the terms of their open-source license). In a
space-local system, no distributed insecurity can arise, so such a system
would be an sl-E rather than
an sl-daffE.

E is designed to provide
local capabillity-security -- the ability for mutually suspicious objects
hosted by the same process to safely cooperate, and the use of capability
discipline to determine which of its hosting process's authorities it
may exercise. Such objects could be executing untrusted code --
code that the hosting process (or its owner) doesn't need to fully trust.

This is the first "complete" release of E. "complete"
is in quotes, because both the persistence and the distribution leave
much to be desired, as explained above. However, these are close enough
that this is the first release that doesn't need qualifiers in its name.

Dependencies

Versions & Types of Java

In refering to various versions of Java, we follow Sun's terminology
and numbering. A Java Runtime, or jre, is adequate to run standard
Java binary programs (class files & resources). A Java Development
Kit, or jdk, is adequate both to build a program from sources and
to run it. A jdk is a superset of the corresponding jre, and their version
numbers are always in synch. Each successive version of the jdk/jre from
Sun effectively defines a new version of the Java & JVM standards,
except that Sun has introduced a numbering
inconsistency: The Java/JVM 2.x standard corresponds to Sun's jdk/jre
1.2.x. We ignore this inconsistency and refer to both as 1.2.x.

This version of E requires
a jre >= 1.3.1. E no longer supports Java < 1.3.1. To build E
from sources, a corresponding jdk is required.

Build-Only Dependencies

If you are only installing E
from a binary distribution, or only rebuilding the Java portion for your
own use, you can ignore this section. However, if you wish to build an
E distribution from sources,
then you will need the equivalent of the following tools as well.

The E building process relies
on a number of UNIX tools. These are available for Windows from Cygnus
Support as the Cygwin package. If you wish to build E
on Windows, you should download
and install a version >= 1.0.

BYacc/J (Berkeley Yacc for Java)

The E source distribution contains the executable binary program byaccj.exe
for Windows, and byaccj for Linux/386/glibc. These are actually
BYacc/Java
from Bob Jamison and others.
BYacc/Java is the Berkeley Yacc program extended with a "-j"
flag and others for producing Java output. BYacc/Java is covered by the
Berkeley License. If you are on a Unix system other than glibc Linux,
you need to download your own version of byaccj and overwrite
the one in src/bin/linux-386-glibc that our Makefile is using.

Note: The website at the above link, http://www.lincom-asg.com/~rjamison/byacc/,
seems to have disappeared. If you know where it may have gone to, or know
how to contact Bob Jamison, please let me know. In the meantime, starting
with the 0.8.10alpha1 release, the sources to byaccj are bundled with
the E sources, and byaccj is made as part of making E.

Zip Files

Our build process packs up the *.zip files in the distribution
by using Info-Zip's
highy portable, and highly ported, zip program. Info-Zip's
zipping tools are open-sourced with a license that seems to resemble the
X11 license, but before redistributing it, you should read it for yourself.
The E distributions do not
bundle in these tools.

Unless stated otherwise, all text on this page which is either unattributed
or by Mark S. Miller is hereby placed in the public domain.