[bt-devel] Some pictures

[Greg Hellings]

2009/2/26 Matthew Talbert <ransom1982 at gmail.com>:
> 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:

Mmm, running alpha-release applications on beta-release OSes is bound
to give lots of happy results.

>
> 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}

Going off of my almost non-existent knowledge of Windows Development
error messages, it almost seems like Windows 7 doesn't have support
for running applications which were compiled in Vista.  Seems strange.
 I suppose I'll have to Google that HRESULT to see if it's an error
message or what.  After having tested Vista Betas back when they were
around, I must say I don't ever want to go the route of Windows Beta
testing again - release versions I am happy to play with, but their
beta products are often very beta.

>
> 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.

This is an issue that the whole BibleTime team probably needs to
tackle in a big discussion (and perhaps along with the Library
developers, Bible Desktop, Xiphos and BPBible developers as well).  I
know some discussion about what to do in Windows has been made in the
past, but I don't remember if any final decisions were made.  But
supporting current BibleCS installations, handling future
installations, dealing with all possible permutations of install
order, dealing with per-user installations, etc all need to be worked
out.  Hopefully SWORD_PATH does (or at least should) support multiple
semi-colon delimited entries (or colon-delimited for Unix
environments) so that each app doesn't have to remember all possible
locales?

>
> 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 :)

I don't use any non-ASCII in my daily life (the curse of being from an
Anglo heritage in the United States), so I have very little actual use
experience to test this with.  But I know many of the BibleTime team
are based in Europe and probably have far more experience with Unicde
files, paths and the like.  Hopefully they can test and report back
with what they find.  Building on VS may have gotten rid of some of
that nuisance, but I don't know if SWORD's build in VS that claims to
have ICU actually has it or not.  There are no ICU DLLs or libraries
floating around my build folder that I've seen, and I didn't link
against an external ICU library - so that could be the root cause of
the module-related UNICODE crashes I've seen.  I will keep pushing
that as a testing topic for other people as well as myself.  Thanks
for the heads up.

>
> Matthew
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>