> Despite Microsoft documentation to the contrary,
> this is always C:\Windows on Win95/98 and always C:\WinNT on WinNT &
> Win2000. Also, for all these systems, their GetWindowsDirectory() is on
> their PATH.
| Btw, testing on my Win98 laptop reveals | | >This is the only directory | >guaranteed to be private to a user running a shared version of the | >operating system. | | to be a lie. In order to do just this kind of testing, my laptop is | configured with 4 users: alice, bob, carol, and markm. For all 4 | getWindowsDirectory() returns the same "C:\Windows". Oh well, but that | doesn't invalidate it for my purposes.
MarkM - Re: your earlier comment "|"-quoted above, I think "shared version of the OS" in this case is referring to a diskless (aka server-based) installaion of Windows, shared by multiple machines on a LAN. I wouldn't expect logging in as different Win9x users on a single machine to count, in this context, as multiple users sharing a version of the OS. And as you say, even in this case, your default should still work and if not it can be overridden. I'd watch out for read-only directories though, either the GetWindowsDirectory() one or, say, any temp. directories you might try to use for unpacking files (I once traced a failure of another project's Setup to the GetTempDirectory API returning a path, c:\temp, which didn't actually exist... the user had apparently deleted or renamed the temp directory but Windows didn't check existence before returning it :-)
> >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
>
> * "make-a-shortcut" and
Make a shortcut from where to where? A better abstraction might be: "add-this-executable-to-the-user's-menu" (which may mean adding to a
command-menu or creating a desktop icon, or both depending on the platform).
> * "associate .foo with this mime type, which is in turn associated with
> this launching behavior & new right-button menu items".
Some other abstractions that come to mind:
This is very platform specific. The free Unix's follow either the SysV or the BSD model for starting daemons at boot; NT has it's ServiceController APIs for registering/starting/stopping services; Win9x _doesn't_ have the SC APIs, but instead as a set of registry hooks... and of course Windows allows simple servers to be started when the user logs in by placing shortcuts in the user's Startup folder (which may be more appropriate for something like "echat"). In some situations it may be desireable to hook into whatever web server happens to be in use (Apache, IIS, ...) Can E operate as a servlet?
This would allow an E-app to be notified when the system was not just idle but unattended, to allow writing SETI@home or rc5des in E :-) I don't know how desireable this feature would be but it's something _I'd_ like. Now that I consider it, this isn't just an installion issue: A SETI@home-type program might also like to be notified in a portable way of other, system-dependent events:
This might be very handy for completing installation of distributed services, if at some point during installation it's necessary to register with a server, open an account or whatever. This obviously requires the JVM installation to have been completed.
None of this is trivial and it's not even obvious to me if it's desireable. The abstractions I suggest are basing it on how I imagine using E. Initially I'd favor a few simple abstractions (such as "install-this-E-code-such-that-it-runs-when-the-user-logs-on", which on Windows would just put a shortcut in the appropriate Startup folder) and a general hook to allow layering custom code as installer extensions for the complex cases.
> Yes! Halcyon Software has just open sourced their Java "Instant Installer"
Question: Is there any advantage to an Installer written in Java over one written in C/C++?
On the one hand, a Java installer simplifies 'porting of the installer between Windows and Unix-like platforms -- only the "platform-abstraction layer" would be different. The GUI code could be identical.
However do you expect most Linux/Unix users will already have a JVM installed? Also, most platforms have their own preferred method of installation and package management: RedHat and other Linux's use RPMs. Debian has a similar scheme (.deb files). FreeBSD has it's "ports" collection -- and FreeBSD's "ports" collection automatically downloads and installs any dependencies, and registers them for uninstallation. I'm not an RPM expert but I've read it has some ability to automatically resolve dependencies also. So, does it make sense to try to build an Installer which duplicates this platform specific functionality? Or would it be better to concentrate on Windows (and the Mac) -- which I'd guess will have the greatest concentration of novice users. One approach would be to factor the Installer into two parts: the first would be concerned with unpacking files (or self-extracting), selecting directories, guiding installation of any dependencies and finally actually installing E... this first part would need to be written (or borrowed :-) for Windows, but for the Linuxes or *BSD's, the existing package scheme could be used. The second part would be any custom-application setup which may be needed -- since at this point the core E would be installed, this could be an E script, or it could be something system specific.
> >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.
Ideas for the long-term Setup:
It seems best to ensure the Novice user has a known-good combination of E, JVM and supporting java extensions (swing, cryptix, etc.) by either guiding them in selecting which JVM and other components to install, or by verifying what they already have installed and possibly suggesting an upgrade. Self-declared "Experts" could override the recommendations or ignore dependencies altogether.
Setup could implement this by "scanning" the system (NOT necessarily a disk scan, perhaps just a PATH scan) for dependencies, obtaining the versions of any that are found (Microsft has APIs to query version resources [which aren't always set correctly]; or you might try to recognize a particular version of an executable by it's MD5 signature.) Setup could then consult a table of known-good configurations, or if the user's configuration wasn't recognized, Setup could encode the user's configuration as a URL and open a browser window -- a server-based CGI could provide the latest details of which combinations of platforms and dependencies had been verified to actually work and where to get 'em. (Of course, there are privacy concerns here so you'd want to ask permission.)
Mark Shepard