L.Allan-pbio wrote:
Some comments:
* Very good progress.
* Nice implementation of the sword url link with WriteIniStr used to
create the link ....
* HKLM SOFTWARE\Classes\sword ???
Seems to be set by running sword.exe .... whole series of registry
entries. Perhaps these should be removed also?
These are being created by the OS. Not by the installer or the executable.
Try installing and running 1.5.6 and then search for registry entries.
There are a bunch that are managed under some notion of shared library.
In looking at where these extra entries show up, I also see a bunch for
stuff that I have uninstalled from other applications.
I think that the installer and uninstaller should be responsible only
for the entries that are directly managed by by the installer and the
application. As far as I know, the application doesn't do anything with
writing registry keys.
* The InstallManger.exe and related files are deleted during
UNSEC0000, so aren't available for -un.post UNSEC0001
I would suggest not removing the InstallManager .... handle it as a
different/separate uninstall .... it should be left available for
other "family apps"
Good catch
(I would suggest renaming SEC000# and UNSEC000# to more meaningful
names)
This is on the "cleanup" the code set of final tasks. Same with breaking
out the defines at the top.
* Still using SWORD_HOME rather than SWORD_PATH?
Still haven't gotten to look at this.
* I have some concerns about over-writing an existing SWORD_PATH
environment variable setting. That seems appropriate for a
"Components" page decision (this installer doesn't use any
"Components" page)
I didn't think about overwriting. I'll see about adding a check to see
if it is currently defined and pointing to an existing directory. If it
is not then I think it should be set.
This should be in a separate nsh file so all SWORD family applications
can use it.
* Uninstaller may not want to remove SWORD_PATH environment variable.
Leave it around for other "sword-api family apps" to make use of.
* May not want to get rid of mods.d and leave it for other "family
apps" that are making use of SWORD_PATH. I think the
InstallManager.exe is the appropriate way to get rid of mods.d files
(to keep them sync'ed ok with contents of subdirectory modules?)
I think that there should be a dialog asking the user whether the sword
modules should be removed, if this is the last application in the SWORD
family to be removed. If the answer is yes then the modules and env var
are removed. Otherwise they are left intact.
This will be part of the final solution. OK?
This should be in a separate nsh file so all SWORD family applications
can use it.
* Baffled by what is happening in the SwordUtil::AllDone function to
read Field 4 and Field 5 of ioSpecial.ini. I only see 3 fields in
ioSpecial.ini
Its baffling because it relies upon the actual execution of what should
be "black box" code.
I studied the code in NSIS/contrib/Modern UI/system.nsh
It uses the ioSpecial.ini (which has only the 3 fields as you noted) as
a starting point.
This file is copied to $NSISPLUGINDIR (generally in temp) and then
manipulated by the various MUI macros.
The check boxes on the Finish page can either be reboot or it can have
one, the other or both of "run" and "readme".
Based upon this Field 4 is for reboot, and if reboot is not specified,
then run and if run is not specified then readme.
If run and readme are specified then these become fields 4 and 5
respectively.
Now if the MUI changes, then all bets are off. These could be fields 6
and 10. Or have meaningful names.
I should probably put a check in against MUI_VERSION and abort the
compile if it is otherwise.
What the AllDone done is called after the user (un)checks the RUN and
README options and then clicks on "Finish" (I think that's the button label)
So at this time, the MUI code is checking for Field 4 and 5. It then
sequentially runs the RUN action followed by the README action.
The run action is executed using Exec, which is non-blocking or Call, in
the case of a function.
The readme action is executed using ExecShell on "open", which is
non-blocking or Call, in the case of the function.
So I created a function AllDone that is called by both the RUN and
README callbacks. This function is a run once.
Since ExecShell is non-blocking, I changed the execution of the readme
to explicitly use notepad and to use ExecWait. The significant
difference here is that if the user has set emacs, vim or some other
text editor as their default *.txt open action, it will not be used. And
it now waits until the user is done.
If the user chose to run the application, I bring up the installmgr and
then the application. (using the code you supplied)
I think a simpler solution ... would let the readme.txt and the
InstallManager show up at the same time ...
It might be useful to be able to see the readme.txt instructions
for using InstallManager at the same time that InstallManager appears.
Would use ExecWait for InstallManager, then Exec for sword.exe
(in other words, standard handling of readme.txt, and special
function for InstallManager and then sword.exe)
Troy has requested that the readme precede the installer as it is in the
current 1.5.6 installer. (See the original request at the bottom of this
e-mail)
Let me say, I don't like my solution, but I don't know another way to
satisfy Troy's request. I don't have a problem with Troy's request, I
just don't like using internals of a "black box" to create a solution.
The other solution would be to create a custom page that would execute
the AllDone function once and use variable under that page's control. My
take is that I would want to use the internationalized strings that the
MUI provides and that would require digging into MUI's internals and
also duplicate a lot of code that is already provide by MUI. It's a
matter of trade offs. I can add more comments to the function if that
would help.
The primary purpose of the readme is to let users in countries hostile
to believers know that the installer is going to connect in an insecure
manner to the internet.
The problem that I have with running both at the same time is that
sometimes the readme is on top and sometimes it is on the bottom. The
user may not see the readme until after they use the InstallMgr.
As an aside, the way we handle this in JSword is that the application
looks to see if there are any modules installed and if not then prompts
the user to install some. At this time we don't warn the user, because
JSword was delivered initially via WebStart.
* Uninstaller leaves registry entry App Paths\Sword.exe (maybe ok?)
It wasn't supposed to.
But if we leave the modules, we should leave some key regarding them
behind. See below for a suggestion that the key SOFTWARE/CrossWire be used.
* Overall, the installer is using three registry "subhives" (and
sword.exe uses another one). Perhaps it could settle on one, and have
all the applicable information there? I/we/you could check with the
nsis forum to see what is "best practice".
HKLM SOFTWARE\CrossWire\The SWORD Project
This is part of at least two installer generators. NSIS Eclipse plugin
and one other, I don't remember.
This is also in many of the examples as a place to keep configuration
information.
This is fairly standard. Lots of other apps under SOFTWARE.
The idea here is that if all the other apps like LCDBible put stuff
under SOFTWARE/CrossWire, then we can discover whether the application
is the last to be uninstalled. If it is not the last then the
uninstaller shouldn't delete mods.d and modules or even offer the user a
choice.
I didn't know that the Sword executables are statically linked except
for the icudtXX.dll, which only contains data. This means that sharing
is limited to mods.d, modules and possibly icudtXX.dll.
So I think that this as a mechanism should work for the LCD bible.
HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Sword.exe
This is standard and follows what was done previously.
The NSIS command InstallDirRegKey goes after this key as a prior
installation and uses that as the new default INSTDIR.
Lots of other stuff under Apps Paths to model after.
HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\The SWORD
Project
This is standard and follows what was done previously.
Also this is where Add/Remove Programs looks for uninstallers.
HKLM SOFTWARE\Classes\sword (used by sword.exe for icon and perhaps
file association?)
See above.
WriteRegDWord HKLM "${PRODUCT_REGKEY}\Components" Main 1
WriteRegStr HKLM "${PRODUCT_INST_KEY}" Path $INSTDIR
WriteRegStr HKLM "${PRODUCT_UNINST_KEY}" DisplayName "${PRODUCT_TITLE}"
* I'd like to do some more testing of Win2000 and WinXp in "limited
user" privilege mode, or did we decide not to be concerned about that?
I suspect that use of HKLM by the installer (and sword.exe itself) may
make it difficult or impossible for a "limited user" to be able to
install and run.
I've been looking for an example of a page that presents radio buttons
for two options:
O Install for everyone that uses this machine (requires administrator
priveledges)
O Install only for me.
The result of this page would be to call:
SetShellVarContext all
or
SetShellVarContext current
Then everywhere HKLM is used, it would be replaced with SHCTX.
The only trick to doing this is the detection of a prior release.
One would need to check both HKLM and HKCU.
Based upon the results of this check the default for the page would be set.
If it did exist under HKLM and not HKCU and the user chose HKCU, then we
would need to delete the HKLM registry entries. (and visa versa)
If you can get this working fairly quickly, I'd be glad to use it, but I
am running out of time and there is a sense of urgency to getting
something working.
According to Troy there are about 20 requests for CDs each month and it
takes time to master another batch. Since we are close to a release, it
would make sense to wait on new CD requests. But not too long.
And for this CD, I would like to put JSword/BibleDesktop on it. So I
have some work to do in that arena.
Also, the KJV that's distributed as part of the starter pack for 1.5.6
has known problems. While the current KJV module also has problems it is
much better. With 4000+ downloads of the starter pack each month, it
would be good to get the installer in place very soon.
----- Original Message ----- From: "DM Smith" <[EMAIL PROTECTED]>
To: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Sent: Thursday, February 09, 2006 5:56 AM
Subject: Re: [sword-devel] BibleCS Installer
I have updated the installer as before.
This now launches readme (if requested) and then the InstallMgr
followed by Sword.exe (if program run requested)
I think that all the registry keys are correct.
I think that all the links are correct.
I fixed a problem where the InstallMgr --uninstall was called even if
the user chose to cancel the uninstall.
I added the splash screen to the uninstall.
So, while it does it differently internally, we now have the same
functionality of the simple installer. StarterPack is next.
There may be a little more that needs to be done along with code
commenting and simple refactoring, Then I think this is sufficient to
get a first release out.
Monday, should be a reasonable milestone.
Lynn, I think there are enough hooks in the registry for the
discovery of Sword to use its files in another project. I am still
trying to figure out SWORD_PATH and SWORD_HOME.
Troy, please take a critical look at it and see what else must be
done before a release.
DM Smith wrote:
I have uploaded a current copy of the installer script that I am
working on to:
http://www.crosswire.org/bibledesktop/biblecs/biblecs/installer/SwordSetup.nsi
I have also uploaded the installer:
http://www.crosswire.org/bibledesktop/biblecs/biblecs/installer/SwordSetup.exe
Give it a try and let me know what what you think.
I will be adding the ability to chose whether to create a Start Menu
Group (may already be present), a desktop shortcut and a Quick
Launch shortcut. And the launching of the executable and the readme
at the end don't work right.
DM Smith wrote:
Troy,
Lynn and I have been working on this. Our approach has been a
little different. My goal is to get a basic installer for just
BibleCS and his has been to create a family of installers for all
derivative Sword API Windows applications. These are not at odds
with each other and I think we are nearly there with at least a
first pass.
To finish the first pass, we need a couple of things:
1) All the compile artifacts of the build (e.g. dlls, exes, ...) as
I don't have a C++ compile environment. Preferably, these should be
what will be used by the installer. Also, if you could give me the
paths for these using the checkout scheme below that would be
great. Currently, I am stubbing this with 1.5.6.
I am now stubbing with the latest betas in the alpha download area.
These require icudt28L.dll and not icudt34dll. The latter is what is
in source code control.
2) What are the other files that must be included? And for dlls,
what versions?
(For 1 and 2, if you could create an directory layout of what the
final install should be like that might be easier. Essentially,
this would be a zip of what the installation directory would
contain right after installation when no modules are installed.)
Rooted at http://www.crosswire.org/bibledesktop/biblecs is the
"image" of what the installer uses.
This is a subset of the checkout Troy mentioned below. However, I
used a tag for checking out Sword, not trunk.
I am not sure of the placement of sword.exe or InstallManager.exe.
I have placed sword.exe in biblecs/stage and InstallManager.exe in
apps/InstallMgr
3) What is the minimum set of files to provide the Sword API for
other applications? (I want to create a SwordAPI installer that
will install the absolute minimum that a derivative application
must have present. This will then be called by those applications
installers, if the SwordAPI has not been installed.) Does it need
icudt34.dll? Does it need the install manager? How about all the
subdirectories in biblecs/.../stage/?
4) In an earlier note, Lynn gave a path to a patch to allow for the
modules to be located elsewhere. Is this something that can be
included in 1.5.8 or should it wait for a later release.
5) NSIS needs (un)installer icons that work. I am terrible at
artwork, so I am not the one to do it. NSIS requires that the size
of the installer and uninstaller icons be the same.
I found that the installer icons were taken from NSIS. I am using
these directly now and have fixed the mismatch problem. I also have
fully branded the installer with the "orange" theme.
Can you give me check in privs for the installer directory? Then I
can work in there. I think that the following addition to the svn
authorization file, would work:
[biblecs:/trunk/installer]
dmsmith=rw
Right now this is where the installer is at:
1) Offers the user a choice as to where to install the program and
what Start Menu Group to create.
It defaults to the same default locations that 1.5.6 uses.
2) The installation
a) Installs the files
b) creates the registry entries
i) The uninstaller is listed in Add/Remove Programs
ii) Keys and values are created so that other programs can
discover where Sword is installed.
It still needs to create a couple of keys.
c) creates a desktop shortcut
Does not offer the user a choice about this one.
Should also probably install to the Quick Start task bar.
And it should be a choice, too.
I have not added the choice for these.
d) creates shortcuts in the Start Menu for
i) the Sword program
ii) the Sword Install Manager
iii) the website
iv) the uninstaller
It probably should also create a shortcut to help.
Shortcut for help now present.
e) It adds/changes SWORD_HOME environment variable to point to
the installation directory.
The installer assumes that prior versions have been deleted.
This may be bad.
Are there any files that *must* be removed for the install to
the same directory to be successful?
For example, is it bad to have icudtXX.dll and icudtYY.dll in
the same directory?
It appears that the executables require a particular version, so
this won't be a problem.
However, it may still be best to do a "clean" upgrade.
3) It creates an uninstaller that
a) runs InstallManager -uninstall
currently, this is broken
This now works, but both the readme and the installer come up at the
same time rather than serially.
I think I know a way to fix this.
b) Removes all files that the installer installed. Leaving all
files that the program or user created.
c) Removes all shortcuts (that have not been moved)
c) Removes empty folders
d) Removes registry entries.
The uninstaller does not determine whether there are any
dependent, derivative applications and act appropriately.
These will have a registry key located under
HKLM\software\CrossWire.
It should be the responsibility of the last removed derivative
application to remove the SwordAPI.
Is there anything missing from the above? Must haves? Should haves?
Nice to have?
The last thing needed before the installer(s) is(are) released is
robust testing. I know there are somethings that don't work yet and
some of the paths are wrong. And there may be some things, I won't
find because I always test the same small set of paths! So after I
get the bugs out that I know, testing help would be appreciated.
In His Service,
DM
Troy A. Griffitts wrote:
Hey guys,
I spend today trying to build a new installer for the upcoming
release of BibleCS. I'm abandoning the commercial InstallShield
installer we currently use and am trying to make everything work
using the free NullSoft installer. I gave up after trying to
learn the scripting language and downloaded Eclipse and the
NullSoft Installer plugin for Eclipse. I used a wizard and got it
pretty far. Had to hand edit the generated script to get it to
compile.
There are a few things missing:
Launch Readme.txt and wait for close BEFORE launching
InstallManager.exe
Registry keys correct so Windows Module self-installers
(website, module download, windows) know where to unzip themselves.
Uninstaller successfully launching "$INSTDIR/InstallManager.exe
-uninstall" to uninstall all modules
I've checked everything in:
https://crosswire.org/svn/biblecs/trunk/installer so if you'd
like to give it a shot, please help yourself! It expects the
normal: sword, icu-sword, biblecs directories all checked out at
the same level.
svn co https://crosswire.org/svn/sword/trunk sword
svn co https://crosswire.org/svn/icu-sword/trunk icu-sword
svn co https://crosswire.org/svn/biblecs/trunk biblecs
I'd really welcome the help with this.
-Troy.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
