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?
* 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"
(I would suggest renaming SEC000# and UNSEC000# to more meaningful names)
* Still using SWORD_HOME rather than SWORD_PATH?
* 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)
* 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?)
* 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
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)
* Uninstaller leaves registry entry App Paths\Sword.exe (maybe ok?)
* 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
HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Sword.exe
HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\The SWORD Project
HKLM SOFTWARE\Classes\sword (used by sword.exe for icon and perhaps file
association?)
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.
----- 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