Bugs in the E 0.8.7 Distribution on Java2 and WinNT/2000

[Mark S. Miller]

Yesterday, Henry Boreen tested the E 0.8.7 binary distribution for Windows 
using both WinNT & Win2000, and using both Javasoft's Java-1.1 and Java-2.  
Thanks!  His testing revealed six urgent bugs that I am currently in the 
process of fixing.  In the meantime, I'm posting these explanations and 
work-arounds, so no one will get stuck, and so I can get some feedback 
before deploying the fixes I describe.

(As I write this note, I just got email from Mark Shepard with more NT 
installation testing results.  I'll review that before my next email.  
Thanks Mark!)


Bug 1: The Slasher

The installer's default location for the install directory is "C:/Program 
Files/erights.org/".  Unfortunately, another part of the installer assumes 
that this directory name does not end in a slash, so it proceeds to append 
"/bin/jars/..." forming directory names with double slashes.  If you 
encounter this bug, you will see an error-window that shows a path with a 
double slash in it.

Work-around: When the installer (the Setup.exe program) presents the 
proposed installation settings, if the proposed install directory ends in a 
slash, say "n" when it asks you "ok?".  When it then asks for the 
installation directory, retype the name without the terminal slash.  You may 
safely accept all the other defaults, except for "Command Dir" -- see bug #2 
below.

Status: This bug occurs under all versions of Windows.  Fixed in two ways 
in the unreleased next version of the installer: 1) All of the installer's 
directory name handling is now tolerant of names that end in a slash or not.
2) The default install directory path no longer end in a slash.


Bug 2: A Command Performance?  Not.

Prior to Henry's testing, E 0.8.7 had only been tested on Win98.  The Win98 
PATH includes both "C:/Windows/Command" and "C:/Windows/System".  Since I want 
e.exe to be on the user's PATH, I copy it in one of these two, and in the 
corresponding directory on WinNT/Win2000.  Unfortunately, I guessed wrong.  
On Win2000 at least, C:/WinNT/Command is not on the PATH.

Work-around: As explained in the bug#1 workaround, say "n" when the 
installer asks "ok?".  When it asks for a "Command Dir", if you're on 
Win2000/WinNT and you see "C:/WinNT/Command", don't accept this default, but 
type in instead "C:/WinNT/System32".  If you see "C:/Windows/Command", then 
you are probably running Win98 or Win95.  While it's safe to accept this 
default, you will be better prepared for the next release if you enter 
"C:/Windows/System".

Status: This bug occurs under Win2000 and perhaps WinNT.  In the next 
unreleased version of the installer, this is fixed by copying e.exe into the 
"System" directory according to the Windows API GetSystemDirectory() 
function.  Under Win98 this is "C:/Windows/System".  Under Win2000/WinNT, 
this is expected to be "C:/WinNT/System32", but we haven't yet tested this.


Bug 3: I Need My Coffee

Like many of us, E cannot wake up without its coffee.  When Henry started
installing, his machine did not have a Java installed that E knew how to 
use.  (Henry did reasonably object "But I've got Microsoft Java installed, 
it comes with Internet Explorer."  The download pages need to make clear 
that E does not work with Microsoft Java.)

Unfortunately, the E install does not currently check whether there is a 
usable Java or not.  Instead, the install succeeds silently, but then both 
the "e" and "elmer" programs die with a mysterious error, something along 
the lines of "Exit code: -1".  Needless to say, most users will not be able 
to diagnose the problem from this!  By installing a Javasoft Java, the 
problem goes away.  Testing by Terry Stanley reveals that the Java runtime 
as installed by Symantec's Visual Cafe is also perfectly acceptable to e and 
elmer.

Work-around: Install a Java Runtime (or a JDK) from Javasoft.  Because of 
bug #6, install a Java-1.1.

Status: This bug occurs on all versions of Windows.  I haven't done anything 
to fix this yet.  I will be checking to see if there's either a "java.exe" or a 
"jre.exe" on the PATH.  This will also address bug #5 below.


Bug 4: Do You Swing?

E requires a swing library whose package prefix is "javax.swing" rather than 
"com.sun.java.swing".  I was surprised to find out that even the Javasoft 
1.1.8 runtime does not seem to come with such a swing already installed.  
There is a link on the E download page to a swingall.jar file you can 
download, and instructions on how to install it yourself.  However, if you 
don't have such a swing installed, the E install still seems to silently 
succeed, and then "elmer" dies an uninformative death.

Work-around: After installing E, download and install swingall.jar according 
to the instructions on the download page.

Status: This bug occurs in many (perhaps all) versions of Java-1.1.  I 
haven't done anything to fix this yet.  I plan to have "setup.exe" (which is 
written in C) end by executing the not-yet-written "welcome.e" which will be 
written in E.  Since this bug does not prevent E from working, an E program 
is the perfect place to stand to 1) diagnose this problem, and 2) offer to 
repair the problem by downloading swingall.jar from erights, and installing 
it where it needs to go.  This will also test whether E actually runs during 
the installer, allowing Setup.exe to complain if there's a further problem.


Bug 5: The Name of the Code

Javasoft seems to have done something so brain damaged that, despite their 
history, I can hardly believe it.  Unless I am confused (quite possible), it 
seems the Java-1.1 runtime for Windows installs a Java launcher on your PATH 
named "jre.exe", while the Java-2 runtime for Windows installs on your PATH 
a "java.exe" and a "javaw.exe".  Java-1.1 does not install a synonymous 
java.exe, and Java-2 does not install a synonymous jre.exe.  Therefore, 
there's no one name I can assume will work in either configuration.  Not 
anticipating this problem, the E 0.8.7 e.exe command has hard-coded into it 
the name "jre", which breaks under Javasoft's Java-2.

Work-around: Make a copy of your Java launcher named "jre.exe" and put it on 
your PATH.  For example, If you've installed Javasoft's Java-2 on WinNT, you 
will have a "java.exe" in your "C:/WinNT/System32" directory.  Make a copy 
of this file named "jre.exe" and put it in the same directory.

Status: This bug occurs at least in Javasoft's Java-2.  In the unreleased 
next version of the installer, I've added an install option for the name of 
the Java command, and I've extended e.exe to accept a new command-line 
option: "--javacmd <cmd>".  What still needs to be done: check at install 
time whether the user has a "java.exe", "jre.exe", both, or neither on their 
PATH.  If only one, and if it's not the one e.exe uses by default, generate 
the e.lnk and elmer.lnk shortcuts to use the --javacmd to specify the name.  
Alternatively, have the e.exe command always figure this out on each launch, 
or have the installer write a registry entry which e.exe reads.  The 
advantage of the latter two approaches is that "e" command still works 
without extra command line garbage.

If neither are defined, then the installer can address bug #3, and inform 
the user he has no java.  If both are found, things are a bit tricky.  From 
experimenting on my Win98 machine, if you install both Javasoft's Java-1.1 
and Java-2, you will end up with both files on your path.  However, only one 
will work -- the one more recently installed.  Fortunately, there's a 
registry entry which I can read to determine which one I can expect to work. 
Unfortunately, this approach isn't compatible with non-Javasoft 
distributions like Cafe's, which are otherwise perfectly compatible with E.  
Therefore, if both exist on the PATH, I will make the user choose one.


Bug 6:  Too Much Yaccing

To be covered in the next message.  This bug is currently fatal for the use 
of Javasoft's Java-2.  The only known work-around is to use a Java-1.1.  
More later.


         Cheers,
         --MarkM