[sword-devel] BibleCS Installer

DM Smith dmsmith555 at yahoo.com
Tue Feb 7 09:53:32 MST 2006

Thanks Lynn, I really appreciate your response.

L.Allan-pbio wrote:
> Your installer is showing great progress. Good work and thanks for 
> getting involved.
> Some questions and coments:
> * I've got test computers with Win98-FE and WinME installed. Both have 
> HKCU registry hives, so I'm not clear on your comment about they don't 
> have this subhive .... perhaps you (or the nsis page) are referring to 
> the uninstaller info, which may be specific to HKLM. Anyway, this 
> makes me inclined to suggest that you/we rethink which registry 
> entries to use for detecting previous installations .... I would be 
> inclined to advocate maximum usage of HKCU, except that BibleCS 1.5.6 
> used InstallShield and uses:
I was referring to the link I provided. I don't have enough experience 
or accessible machines with earlier OSes. If our minimum target is Win98 
then I think that HKCU is a fine target.

Keep me posted on your findings and suggestions here.

> * I'm not clear how you got the MUI_STARTMENU_PAGE to offer the option 
> to not write shortcuts .... I suppose I need to stare at the MUI 
> documentation closer. Nicely done.
I merely deleted:

I will be adding a page for choosing additional shortcuts:
    Desktop shortcut
    Quick Launch shortcut
    (could do others such as adding links to IE to the project's home 
page, to make the project's home page IE's home page, .... But I am not 
inclined at this time.)

I am really surprised that MUI does not have built-in support for it. 
(At least, I couldn't find it.)

> * You've got an !include for WriteEnvStr.nsh, and a section for that, 
> but no Components page. Is that silently done then? Are you really 
> intending to write the SWORD_PATH environment variable?
Yes that is silent. I think it should always be set. But I could be 
convinced otherwise.
(It is helpful to JSword which as a portable app, does not look at the 
Windows' registry.)

I just heard about SWORD_PATH for the first time yesterday. What is it's 
In JSword we have two notions of path. One is the set of directories 
that contain mods.d and modules and the other is the one directory to 
which the installer should write. For the latter, we allow one per 
install site (e.g. stable, beta, local).
Does SWORD make this distinction?

Should we also back this with a registry key.

Should we allow the user to choose a location for the SWORD_PATH?
> * What is your preference on detecting and possibly over-writing a 
> BibleCS 1.5.6 installation? There is the statement:
> InstallDirRegKey HKLM "${PRODUCT_REGKEY}" Path
> which resolves to HKLM SOFTWARE\CrossWire\The SWORD Project
> sword.exe 1.5.6 used:
> HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\sword.exe" 
> "Path"
Sword 1.5.6's usage is correct, mine is a mistake.
> * I would suggest using more meaningful section names than the Eclipse 
> generated sections
> Section -Main SEC0000  ---> Section -Main SecWriteFiles
> Section -post SEC0001  ---> Section -pose SecWriteRegistryEntries
> Section un.Main UNSEC0000  ---> Section un.Main SecUninstallFiles
> Section un.post UNSEC0001   ---> Section un.post 
> SecUninstallRegistryEntries
Good idea. I am still learning about sections and pages.
> * The MUI_FINISHPAGE might have the text "Run InstallManager" rather 
> than "Run The SWORD Project"
> * I would suggest consideration of having the "Family !define" 
> statements and perhaps some of the "Product !define" statements be in 
> separate .nsh include files ... a'la:
> !include "CrosswireFamilyDefines.nsh"
> !include "LcdProjectDefines.nsh"
This is a good idea.
> * Do you have intentions of eventually detecting a prior installation 
> of BibleStudy, LcdBible, sword.exe 1.5.6 or earlier, JSword? ... the 
> issue is to avoid redundant installation of resources (KJV, WEB, etc.)
(Right now JSword is not nice in this regard: it maintains its own 
download area. I'd be glad to change this if we can get a solid way to 
discover the location.)
I think that the mods.d and modules directory should be retained across 
installs as a shared resource.
During the uninstall the user should be asked whether to remove the 
modules or not.

Right now the uninstaller wacks everything. It is what Troy requested, 
but I may have misunderstood.
> * I'm curious about your thoughts/preferences about a "StarterKit" 
> that includes a Bible so InstallManager isn't requried to be able to 
> commence usage. As it happens now, this SwordSetup installer is 
> "empty" without using InstallManager.
I see having three installers:
API only.
    This installs/upgrades the files that a dependent application uses. 
I don't know what these are. So I need some guidance. (i.e. file list)
    So an LCDBible installer would execute this installer if the API is 
not present (as determined by registry keys).

BibleCS only. (This is what I am working on as this seems to be a good 
starting point)
    This would present the README (if user checked),
    then the InstallMgr followed by sword.exe (if user checked to run 
the app.)

BibleCS starter kit. (This should be an easy add as you have done the 
leg work.)
    This would allow the user to select from several modules (e.g. the 
ones included with 1.5.6, but current).
    Then present the README (if user checked)
    then run sword.exe if checked.

I have read that a single installer script can build multiple 
installers. So, hopefully, I can layer these on.
> * It is possible to have the the MUI_FINISHPAGE reference a function, 
> which can have a sequence of .exe's invoked:
> ; more statements here
> ;--------------------------------
> /*
> * Function: OnFinishPageRun
> * Notes: -
> */
> Function OnFinishPageRun
> SetOutPath $INSTDIR
> ExecWait 'InstallManager.exe'
> Exec 'sword.exe'
> FunctionEnd
The situation is a little more complicated than this. The MUI_FINISHPAGE 
can be defined to allow viewing the README and running the application. 
The user can select one, the other or both of these.

The current behavior is to do these with out waiting and it does the 
application first and then the readme.

We need for the user to see the readme first, if requested and then the 
application, if requested.

How I do this depends upon whether I can get the check box state and 
whether the checkboxes callbacks are run sequentially.

If so I would register the same function to both the README and to the 
application check boxes.

The function would be something like:
done = false
function doit
    if not done then
       done = true;
       if readme checked then
          if run program checked then
              execwait readme
              exec readme
       if run program checked then
          execwait installmgr
          exec sword

I am trying to keep from using string literals as much as possible and 
using default MUI behaviors so that we can ultimately provide an 
installer in the user's own language. The MUI has been internationalized 
into many languages already.
> ----- Original Message ----- From: "DM Smith" <dmsmith555 at yahoo.com>
> To: "SWORD Developers' Collaboration Forum" <sword-devel at crosswire.org>
> Sent: Monday, February 06, 2006 3:33 PM
> Subject: Re: [sword-devel] BibleCS Installer
>> L.Allan-pbio wrote:
>>> From SwordSetup.nis
>>>  ;--------------------------------
>>>   ; Establish and remember the Start MenuGroup info
>>>   ; Remember where it is
>>>  ;--------------------------------
>>> This may be a no-no .... HKLM should apparently not be used with 
>>> installations because it assumes the end-user doing the installation 
>>> has administrator privileges.
>> I thought about that, but according to the NSIS site that HKCU is not 
>> available under Win9x and WinME.
>> See: 
>> http://nsis.sourceforge.net/Add_uninstall_information_to_Add/Remove_Programs 
>> If so and we go the HKCU route then we need to add in OS version 
>> detection.
>> If Win9x then HKLM automatically.
>> Else, it should be a choice in the install to install for the current 
>> user or for all users.
>> But if several users on the same machine install to the current user, 
>> how would that work? I mean where would the program be installed? 
>> Where would the modules be located?
>> In any "home" installation at least one person has administrator 
>> privs. In a company setting, the user may not have admin privs and 
>> may even be shut out from doing any installs even HKCU or 
>> changing/adding environment variables.
>> I'm not sure that it is worth trying to install to HKCU. I think 
>> perhaps we need to go for the lowest common denominator ;)
>>>  Ouch .... I hadn't been aware of this, and have always developed 
>>> installers that assumed the end-user had admin privilege. I'll do 
>>> some more research on this.
>>>  See:
>>> http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx  item 3.3
>>>  http://www.microsoft.com/mspress/books/sampchap/6271.asp
>>> Comment: "You're having trouble installing a program for a user with 
>>> a limited account"
>>>  nsis forum question:
>>> http://forums.winamp.com/showthread.php?s=&threadid=237355 
>>> <http://forums.winamp.com/showthread.php?s=&threadid=237355>

More information about the sword-devel mailing list