We're about to have an official release of E 0.8.8 (!!), which I refer to below in the present tense.
At 11:55 PM 2/3/00 , Mark Shepard wrote:
> > But this all assumes we can figure out which dumping ground to dump E into.
> > There's no end to plausible ugly algorithms that will work well enough in
> > practice now, and probably break eventually. For example: "Enumerate the
> > PATH looking for C:\WinNT\System32 and C:\Windows\Command. Whichever
> > appears first, make this the default choice. Otherwise, just ask the user."
> > We just gotta pick one.
>
>BTW, below is a quote from Microsoft's docs for the Win32
>CreateProcess() API, which shows that some APIs do more than just
>``search the PATH.'' ... However, a quick test from a DOS Command
>Prompt showed that if the PATH was unset, .exe's in the Windows
>directory wouldn't be found ...
After getting responses back from
Mark Shepard,
Lucky Green,
Marc Stiegler, and
Henry Boreen
(Thanks!!) on the output of my winfo.exe program on their various systems
Win95
Win98 single user
Win98 multi-user
WinNT & Win2000 Administrator
WinNT & Win2000Beta regular user
Should Microsoft release a Windows that corresponds to their Win2000 documentation, then, if the GetWindowsDirectory() of that system is on that system's PATH, then my default will still work. Otherwise, the user will have to override the default until I release a new version of E whose default calculation works on that system as well. For the world of Windows, this seems *good enough*.
Where I did end up enumerating the PATH is in accumulating a set of plausible choices for Java VMs. I search the PATH for all occurrences of either "jre.exe" or "java.exe". The first I find is the default, but the rest are displayed if the user goes through the choices manually. If none are found, the user still has the option of typing one in manually. I avoided scanning the user's disk to find other alternatives. This also seems *good enough*.
>See, I knew I was getting too close! :-)
>
>I'll check out Mozart; Any others?
Yes! Halcyon Software has just open sourced their Java "Instant Installer" http://www.halcyonsoft.com/news/release/iinstaller_pr122499.htm . Fortunately, it does things from Java I have no idea how to do from Java, like make Windows shortcuts. Unfortunately (being as diplomatic as I can stand), it is not a quality piece of work. At least it should be something to learn from. And it does have the kind of GUI one expects from an installer.
Btw, don't bother trying to download from the above URL -- they shut the download host down cause it got hacked. I should shortly be getting a working URL ("within a day or so"), at which time I'll send that out.
It's released under a modified Mozilla license. Once I've posted the alternate URL, I'd love opinions about this license. Is it really open source? Is it safe? Their FAQ about the license does not seem to me to correspond to the text of their license.
>MarkM, what are the issues you see for an E-installer (and uninstaller)?
>
>I see these [ feel free to correct ]:
>
>1. Basic functionality -- like the existing console Setup.exe, +
>uninstallation... but with a GUI.
Yup. Both an uninstaller & a GUI are high priority.
>2. When you say you "want E to be platform for installable applications"
>I assume that means, in this context, having a Setup which anyone can
>use to not only install the standard E dev kit, but to create and
>distribute their own installable E-based applications -- without writing
>their own Setup from scratch, correct?
Exactly!
>3. Tool-dependency issue: it seems unavoidable that the Windows
>installation process needs to call specialized Microsoft APIs (the Shell
>Shortcut APIs) and use Microsoft headers/structs, which implies that, if
>the end user is going to be able to customize Setup (minimal
>customizations would certainly be nice...) either any needed MS headers
>must be made available for use with cygwin/gcc (reversed-engineered?
>typed in from published docs?), or a binary-version of the Setup engine
>(for instance, as a library) must be available (at it's simplest, this
>could be function-wrappers for any needed Setup functions, compiled with
>MSVC but linkable with gcc-compiled object-code). Otherwise anyone who
>wished to tweak E's Setup for use with their own E-app would need to buy
>MSVC... hardly desireable.
Well analyzed. Here's my fantasy:
Once we've succeeded at wrestling with the issues of installing E on each of the platforms (Win*, Unix/Linux(Kde,Gnome), Mac), we build an installation-amenable abstraction layer for the installation-relevant APIs of each of the platforms. This abstraction layer would support such things as
We implement this layer separately for each platform. The implementation for the Win* platform may well require Microsoft proprietary header files. If someone wants to modify or enhance that implementation, they may very well have to buy MSVC. That's unfortunate, but not fatal. The key is that new apps will normally stand above this abstraction layer, which they can do without proprietary dependencies. (I'm surprised Javasoft hasn't already done something like this as part of their platform-independence charter.)
I don't expect any of this to happen for a long time, but by keeping sight of our long term goals, we can better manage to stay on trajectory.
>4. The dependence on a non-Microsoft JVM seems to place a lower-limit on
>E's ease of installation. I suppose a sufficiently advanced Setup could
>orchestrate downloading and installing a JVM. (Such a Setup would, of
>course, be indistinguishable from magic :-)
I did indeed try once again to get E working with the Microsoft JVM, but no luck. It would be nice to orchestrate getting and installing one automatically, but which? Right now, the installer detects that there isn't one on the PATH. It should probably show the URL of the download page which gives info on getting a suitable JVM. Similarly, if they specify a Java 1.1 that doesn't have a suitable Swing, the installer complains, and shows a URL from which to get it. In this latter case it's more plausible for the fetch-and-install of swingall.jar to be automated.
Cheers,
--MarkM