[bt-devel] Some pictures

[Matthew Talbert]

I was hoping I was going to be able to report a successful
installation as well, but not so. During installation (on Windows 7,
which is essentially the same as Vista), I get this message:

Product: bibletime-installer -- Error 1935. An error occurred during
the installation of assembly
'Microsoft.VC90.DebugMFC,version="9.0.21022.8",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"'.
Please refer to Help and Support for more information. HRESULT:
0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit,
component: {342BA686-A9E6-3FB4-AFC0-7034FF188D52}

As as aside, I know from personal experience that the Visual Studio
installer is extremely limited in capability.

As far as setting SWORD_PATH goes, Xiphos does not set it during
installation although we have discussed setting it then. Currently it
is set during application startup, only if not already set, and only
for the duration of the program. Our default location for SWORD_PATH
is C:\Documents and Settings\All Users\Application Data; on Vista,
this evaluates to C:\Users\AppData. As engine support has recently
been added for this location (at least for modules), I personally
think this should be the standard SWORD_PATH on Windows, ie where
locales.d is located. I should note as well that "Application Data" is
localized, so you will need some method of getting the correct name.
glib provides a function for that. If QT doesn't, you can look at the
last directory in the %APPDATA% environment variable.

As another thing, I have been meaning to write my findings on libsword
Unicode support on Windows, but haven't had a chance yet. The short
summary is that libsword will not handle Unicode paths (it is possible
that some will work, but certainly not all). A word to test for this
is Žibřický (who is one of the Xiphos developers). If this occurs
anywhere in SWORD_PATH, libsword will fail to read anything located
there. To get around this, I patched sword with glib-provided i/o
functions (in particular, open, mkdir, getenv, access, and
directory-traversing functions), as glib uses Windows wide-character
API which always returns the correct filenames. If you are using open
and friends in your own code, you will probably have to switch to QT
functions for those. In addition, you will have to patch sword if you
want to properly handle these scenarios (the previously discussed
dirent.h also will not handle this, I believe). I suggest you
thoroughly test Unicode scenarios before you release :)

Matthew