[E-Lang] Announcing the Interim Internal E stl-0.8.9p Release

[Mark S. Miller]

This release was sponsored by openCOLA.  THANKS!

Available at http://www.erights.org/download/stl-0-8-9-p/index.html .

The driving purpose of this release is to overhaul the process for 
installing and running E, to segregate the platform dependencies, to make it 
easier to get going on a new platform, and to move as much of the 
installation process into E itself as we can manage.

(Chris, I'm especially interested in your feedback as to how this relates to 
the Mac porting effort.  And, of course, we need to reconcile.  Maybe 
sometime the week of the 19th?  And btw, I can't believe I forgot to say 
this.  You got it working on the Mac, Congratulations!)

Previous releases, evolved from the Java 1.1 days, required an unpleasantly 
long command line to invoke E.  This in turn forced the creation of a 
command line driver, e.exe, which forced the creation of an installer, 
setup.exe, written in C, to get everything installed so the command line 
driver could find everything it needed to work.  But only on MSWindows of 
course.  We had a different procedure for Linux based on some bash scripts.  
(With much thanks to several, especially Danfuzz, for help with these scripts.)

Now that we require Java >= 1.2, I turned e.jar into a self-launching jar 
and got rid of setup.exe and e.exe.  After unpacking, if you just double 
click on e.jar, it should figure out that it's not yet properly installed, 
and it'll run the E script "setup.e".

setup.e will check what platform it seems to be on, and dispatch to 
platform-dependent E installation code.  The only such platform currently 
supported is MSWindows, which means that shortcuts and file-extension 
associations will be created on MSWindows, but not yet elsewhere.  (File 
extension associations give a file double-click launching and right button 
menu behavior based on its extension.)  To create these from E on MSWindows, 
I broke the old C install code into a bunch of separate executable commands 
(see bin/win32/*.exe), and I invoke these commands using java.lang.Process.

Outside of MSWindows currently, you don't have these, but this is no longer 
fatal.  However, it's not yet pleasant.  See the README.txt file in the 
binary distributions to find out about the manual procedure currently 
required.  This will improve rapidly.

Anyone know how to create file extension associations from KDE or Gnome?  Is 
it per desktop environment, or is there a more widely accepted way to do 
this?  Can it be done from Java?  What do people actually do about the 
inevitable name space conflicts in this tiny name space?  On MSWindows I 
grab the extensions *.e, *.emaker, *.updoc, *.vat, and *.cap.  I'd like to 
do the same in general.

Thanks to Dean for a conversation about the old installer that helped me 
figure out how to structure the new one.

        Cheers,
        --MarkM