Re: E 0.8.7 & NT Mark Shepard (mns-e-lang@MetaThink.COM)
Thu, 27 Jan 2000 01:06:52 -0800

MarkM -

Mark S. Miller said:
> At 12:31 PM 1/25/00 , Mark Shepard wrote:
> >Okay, I tried installing 0.8.7 on NT (NT4SP5). The new Setup seems to work
> >where it counts but (1) the default "Command Dir" of %systemroot%/command" is
> >not correct for NT and (2) Setup.exe did crash once on me -- I suspect this
> >was due to the fact that I had enabled the "SendTo Dir" installation option.
>
> On #1, I'm having trouble figuring out what the right directory is. It
> seems it's "C:/Windows" on Win95/98 and "C:/WinNT/System32" on WinNT &
> Win2000. Is this right? Should I figure this out by switching on the OS?
> This would have the unpleasant advantage that I could refuse to install on
> versions of Windoze that I didn't know about. (When I sent my previous
> message, I had thought that "C:/Windows/System" was also on the Win95/98
> PATH, but I was wrong.)

In .bat scripts you can switch on %OS%, however, if you're writing a full-fledged .exe, GetVersionEx() will let you more clearly determine the platform and version (in case there are version-dependencies or, say, minimum service-pack requirements.)

However, is it actually necessary to automatically install E.exe along the path? If not, this issue is moot...

Python and TCL, AFAIK, do not copy their binaries into a Windows system directory -- doing so seems to be less and less common these days, partly because of problems managing multiple versions of a tool installed on one system (E 0.8.4 and 0.8.7 for instance) and partly because this has been abused in the past leading to the "dumping ground" description. E's Setup could simply create a .bat script, as an example for the user, which when run updates PATH... This is the approach used by VisualC++ (which creates msvc/bin/vcvars32.bat) and Microsoft's SDK and DDK tools. Or E's Setup could, as part of displaying release-notes, inform the user of the actions to take _if_ they wish to have E.exe along their path -- the advantage being E's Setup doesn't have to know how to edit the NT environment variables in the registry or the Win9x env. vars in autoexec.bat.

An alternative way to hook E into the system would be associate E source files (I believe the term is "UpDoc"?) with E.exe, such that double-clicking an E script invokes E.exe passing it the name of script, just as double-clicking an .html file invokes a browser or double-clicking a .txt file invokes Notepad. E.exe doesn't need to be along the path for this behavior. Of course, registering E.exe as a handler for E scripts should be optional -- some people may prefer to have their E scripts associated with their favorite editor.

Example: Python created these associations: 

.py -> Python File
.pyc -> Compiled Python File
.pyo -> Compiled Python File
.pyw -> Python File (no console)

which all map to t:/tools/python.152/python.exe on my system)

And TCL created these:

.tcl -> TclScript (t:/tools/Tcl.805/bin/wish80.exe on my system)

> On #2, I'm very curious if this crash is reproducible. If so, I need to
> figure out what's going on. Obviously, Setup shouldn't crash under any
> reasonable conditions. Uninformative errors? Ok for now. Crashes? Bad.
>
> >After the crash, the installation of E nevertheless seemed to work -- so
> >the crash must have occurred fairly late in the Setup procedure. I cleaned
> >up the install and re-ran Setup leaving the SendTo, RootMenu, Desktop and
> >Quick Launch options disabled and Setup worked fine.
> >
> >If you like you can send me a debug version of Setup and I'll try running it
> >again to capture more debug information.
>
> That's a great idea. I'll build some debug diagnostics into the next version of Setup.

Here's an idea: Have Setup.exe write a log of it's activities in the form of a .bat script of commands to undo each installation-step; this would only require adding a printf() before each "install-operation". You'd then have both an install log and a simple uninstall mechanism. Call the install log "Uninstall.bat". Setup could install "REM"-prefixed comments with additional information in the install-log/uninstall-script. If you keep the format simple and regular, eventually an Uninstall program could read this script to perform an Uninstall when triggered from the ControlPanel's Add/Remove Programs widget.

> >Details on (1) - NT has no "Command" dir:
> >
> >Unlike Win9x, NT doesn't have a "Command" directory. The NT equivalent is
> >the %SystemRoot%\System32 directory, which is where all of the Microsoft-
> >supplied command line utilities reside (e.g., more.com, find.exe, sort.exe) and
> >is also the dumping ground for Microsoft and third-party DLLs -- my System32
> >contains 1,196 files :-)
>
> So I had thought that I should use the result of getSystemDirectory(), which
> is probably C:\WinNT\System32 on WinNT/Win2000, and is C:\Windows\System in
> Win98/95. Unfortunately, the latter is not on the default path. Is there a
> corresponding dumping ground on Win98/95? Is there a version independent
> way to calculate the location of the dumping ground (so that we might have a
> chance of working on Microsoft's next gift to humanity as well)?

See comment above avoiding the "dumping-ground" altogether.

> >Details on (2) - Setup crash:
> >
> >I then ran Setup.exe. Setup presented me with these default values:
> >
> > > E Install Dir c:/Program Files/erights.org/
> > > Working Dir C:/NT/Profiles/shepard/Desktop
> > > Menu Dir C:/NT/Profiles/shepard/Start Menu/Programs/erights.org
> > > Command Dir C:/NT/Command
> > > Bash Cmd Dir c:/usr/local/bin
> > > No RootMenu Dir
> > > No Desktop Dir
> > > Quick Launch Dir C:/Windows/Application Data/Microsoft/Internet Explorer/Quick Launch
> > > No SendTo Dir
> >
> >And after editing I arrived at these values:
> >
> > > E Install Dir c:/Program Files/erights.org
> > > Working Dir c:/nt/profiles/All Users/Desktop
> > > Menu Dir c:/nt/profiles/All Users/Start Menu/Programs/erights.org
> > > Command Dir c:/nt/system32
> > > Bash Cmd Dir c:/usr/local/bin
> > > RootMenu Dir c:/nt/profiles/All Users/Start Menu
> > > Desktop Dir c:/nt/profiles/All Users/Desktop
> > > Quick Launch Dir C:/TEMP/e087/quick-launch
> > > SendTo Dir c:/nt/profiles/default user
>
> By doing this editing, you managed to fortuitously avoid the bug I reported
> as "The Slasher". Notice that your post-edit E Install Dir no longer has a
> terminal "/". (I mention this only for curiosity. The Slasher is already
> fixed in the sources.)
>
> >Notice that the default Quick Launch directory, "c:/windows/Application
> >Data/..." was incorrect on my NT system; I try to avoid IE, so my purpose in
> >setting this directory to c:/temp/e087/quick-launch was merely to
> >verify that the shortcuts were created.
>
> I wasn't even aware that the quick launch bar was tied to IE. I figured it
> had "Internet Explorer" in the path only for some obscure historical reason.
>
> What's the right thing for me to do here? A proposal: If the path I
> calculate doesn't exist, then this option is default off.

Sounds reasonable.

How frequently is this particular hook used? (I obviously have never used it). Is it worth implementing, or would it be better to just skip it?

> >I then gave the final confirmation to Setup, and it crashed during the install
> >process:
> >
> > >----------------------------------------------------------------------------
> >[... lots of hex-dump-level information that *really* makes you appreciate Java's stack traceback. ...]
> > >----------------------------------------------------------------------------
> >
> >Nevertheless it appeared that most of the Setup process had been correctly
> >completed. Searching drive c:/ for e.lnk and elmer.lnk showed that Setup
> >created {e,elmer} shortcuts in:
> > c:/nt/profiles/all users/desktop (correct)
> > c:/nt/profiles/all users/start menu (correct)
> > c:/nt/profiles/all users/start menu/programs/erights.org (correct)
> > c:/temp/e087/quick-launch/ (correct - dummy directory as a test)
> >and that's it.
> >
> >Setup created c:\program files\erights.org and appears to have copied files
> >correctly. Setup also copied e.exe to c:/nt/system32 and c:/usr/local/bin/
> >correctly.
> >
> >Setup did not create shortcuts in any SendTo folder -- which is why I suspect
> >the crash may be related to this. As far as I can tell, this was the only
> >action Setup failed to perform correctly.
>
> Any idea what might be special about the SendTo folder on WinNT?

AFAIK, "it's just a directory" -- no magic involved.

> Thanks tremendously! I'd love to have a robust E download posted by FC'00,
> for which I'm leaving on Feb18th. This should be an important publicizing
> event for E. But if people get stuck trying to get started, it will be
> harder to get their attention again. This kind of help makes a huge
> difference. Thanks again!

Not to be under-appreciative of the new "console" installer (which is a big improvement over the .bat script) but a GUI installer would be very nice... it'd give E more of a finished appearance and be easier to use. Is the current Setup.exe built with gcc or VisualC++? If you've already taken the plunge of using VisualC++ in your build process writing a simple GUI installer isn't that much of a stretch. (Oops... I'm getting dangerously close here to accidentally "volunteering" to write one... :-) What about existing Installer kits? Have they been investigated? Is it just lack of time for Installer-research or were there licensing/open-source issues?

Mark Shepard