Download by Platforms & Versions

Earlier versions of E have
been tested and run on MSWindows (95, 98 FE, 98 SE, NT, 2K), Linux, Solaris,
FreeBSD, and now Mac OS X (which is really a FreeBSD platform with its
own GUI toolkit and JDK). 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 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.

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 a "complete" release of E.
"complete" is in quotes, because both the persistence and the
distribution leave much to be desired, as explained here
and here.
However, these are close enough that this 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.

Note:
E does not install correctly
when using JDK1.4beta on Windows2000 -- it fails to exec the "winfo.exe"
executable, used during install time to gather info about your Windows
system. It seems to be a more general problem in execing executables.
If you experience this problem, we suggest you install using a JDK1.3.*
or a JDK >= JDK1.4.0-rc. ("rc" means "release candidate"
and is post-beta.) Once installed, E
should work fine with any JDK >= 1.3.1, except for the inability to
exec other programs if you're using the 1.4 beta.

Obtaining Bash

To build E requires a bash
available as "/bin/bash". If bash is unavailable for
your platform, it seems to work better than it should to make a symbolic
link from "/bin/bash" to "/bin/sh".
If you try this and run into problems, please report these problems.

To run the E driver script
"rune" requires a bash >= 2.01 available on your
PATH, and the env program available as /usr/bin/env.
The E driver script is required
(and must also be on your PATH) in order to be able to run E
scripts (*.e files) directly as executables. To check your bash
version, type

On Windows, both bash and env are available as part
of the Cygwin distribution, as explained below.

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.3.12.

BYacc/Java (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. The sources to byaccj are bundled with the
E sources, and byaccj
is optionally made as part of making E.

BYacc/Java is only needed if you wish to remake the parsers as part of
making E. Usually, this is
only necessary of you wish to edit the *.y files in the source
tree (term.y and e.y). Since BYacc/Java is a C program,
it was causing porting headaches, and most people interested in rebuilding
E won't need to rebuild the
parsers anyway. So we've added a switch: If you set the environment variable
"MAKE_PARSERS" to "true" before
running "make", then make will try to build
BYacc/Java on your system, and then use it to rebuild the parsers. Otherwise,
it will just use the parsers included in the source tree.

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.

Environment Variables

The following are the main environment variables controlling building,
and normally the only ones you will need to be aware of if something goes
wrong. Others variables are documented in the various makefiles, especially
makerules.mk.

OSTYPE - To determine whether we are compiling on
the Cygwin platform, we check whether this is set to either "cygwin"
or "cygwin32" (both have been encountered). If
so, we set CYGWINOS to "1". All other
conditionals test CYGWINOS.

CYGWINOS - See above. If you actually are on a Cygwin
environment, but OSTYPE has yet a different value, you probably
shouldn't change it for fear of screwing something else up. So just
set CYGWINOS to "1" yourself.

JAVA_HOME - If set, it should be set to the directory
where the JDK is installed. This is used to find certain executables
and jar files that come with the JDK distribution.

If not set, then the needed executables (eg, "java")
are assumed to be on the PATH, and the jar files directly known to
the makefiles are assumed to be adequate for building. This is known
to work when compiling with javac, and known not to work
when compiling with jikes 1.15 and jikes 1.16. See
below.

JAVAC - If set, should be set to executable for the
Java compiler. The Java compiler is assumed to be command line compatible
with javac or jikes. If the executable is on the
PATH, then simple names (like "javac")
can be used rather than full pathnames. This can also include some
initial compiler options to appear before the others. I often build
with JAVAC set to "jikes +E +F".
If you use jikes, please use at least version 1.15. E
is known not to compile with jikes 1.05. I'm using Jikes 1.16 (download),
and at least that version needs to be provided with the JDK's rt.jar
file as an explicit component of the -classpath argument.
The makefiles do this automatically if JAVA_HOME is set to
the JDK's install directory.

If not set, JAVAC defaults to either "javac"
or "$(JAVA_HOME)/bin/javac", depending on whether
JAVA_HOME is set.

The makefiles are set up to fail if the layering of the sources is
violated. However, at least E
0.8.17 through 0.8.18 violated this layering in a way that I didn't
detect when I built these releases using these makefiles. The problem
was that I was compiling with jikes, and jikes is
too aggressive at finding and compiling files the other files depend
on. Before building a release for others to use, you should build
with javac in order to ensure that these upwards dependencies
are caught. I will do so from not on as well. Thanks to Darius Bacon
and James Freddy for reporting this bug, and to Dean Tribble for diagnosing
it.

JAVACMD - If set, should be set to an executable
for running Java that's command-line compatible with the JDK's "java"
executable.

If not set, this defaults to either "java" or
"$(JAVA_HOME)/jre/bin/java" depending on whether
JAVA_HOME is set.

JAVADOC - If set, should be set to an executable
for generating Javadoc documentation that's command-line compatible
with the JDK's "javadoc" executable.

If not set, this defaults to either "javadoc"
or "$(JAVA_HOME)/bin/javadoc" depending on whether
JAVA_HOME is set.

MAKE_PARSERS - E
contains a small number (two as of this writing) of *.y files,
which are compiled into parsers written in Java using BYacc/Java
(see above). The generated parsers are included in the source distribution
as sources, even though technically they are not, because most
people interested in rebuilding E
will not care to rebuild these parsers.

Those that do wish to rebuild these parsers should set MAKE_PARSERS
to "true". This will cause the BYacc/Java executable,
byaccj, to be rebuilt from sources, and will cause these
parsers to be rebuild from their *.y files using byaccj.
The BYacc/Java sources seem to have problems compiling on some platforms.
If you encounter such problems, and especially if you figure out how
to fix it, please let us know.

If not set, this defaults to not rebuilding byaccj or the parsers,
but just using the generated parsers included in the source distribution
as sources.

If there are better or more conventional ways to control these building
issues, please let us know.

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