[bt-devel] Some pictures

[Troy A. Griffitts]

Regarding Unicode support on Windows.  Not to shift blame here, but I am 
fully convinced the issue is with the MinGW compile toolchain.

Here is my reasoning:

char *getenv(const char *);
int open(const char *);

However your toolchain implements these methods in a unicode aware 
world, just from sheer consistency, whatever you receive from getenv, 
you should be able to pass to open.

I just tried BibleCS (Borland's impl) and it works fine with SWORD_PATH 
set to d:/Žibřický

This should really be fixed in MinGW and I would suspect VC would work 
fine, as well.

Not to say anything against what Matthew has done to get things working; 
until the toolchain gets its act together, patching is necessary and 
Matthew has done great investigative work to figure out how to Get 
Things Done (tm).

    -Troy.



Matthew Talbert wrote:
> 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
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>