[bt-devel] Some pictures

[Greg Hellings]

Just to throw this out there -

2009/2/26 Troy A. Griffitts <scribe at crosswire.org>:
> Regarding Unicode support on Windows.  Not to shift blame here, but I am
> fully convinced the issue is with the MinGW compile toolchain.

I changed the BibleCS installation directory to C:\Program Files
(x86)\Žibřický\The SWORD Project and updated SWORD_HOME.  My drive is
NTFS formatted.  BibleCS still finds the modules properly (granted, it
is located in that directory), but BibleTime now does not find any
modules.  So the problems lies somewhere outside of the MinGW
toolchain, since MinGW has not had anything to do with my BibleTime
build.  I'm pretty agnostic when it comes to most UNICODE issues in
coding, so placing the blame isn't my expertise - but VC doesn't seem
to handle this issue any better than MinGW.

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

Probably Borland has a self-implemented version of the runtime, but
with people also using MinGW and VC, both of which fail to do this
properly, it seems that onus is on us developers to at least find
workarounds until Microsoft decides to patch its libraries.

--Greg

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