[bt-devel] Windows Module Install bug

[Greg Hellings]

Gentlemen,

(sorry for top-posting, but it just seems simpler in this case).

Thanks for looking into that, Troy.  What intrigues me the most is
that I had set SWORD_HOME to point at the CrossWire folder and it
works, but pointing it to a different folder refused to work.  Either
way, we don't intend to go public with a beta (let alone final)
version of BibleTime for Windows until 1.6.1 fixes the UTF16 issues,
at which time we hope this new and improved engine code will handle
making Xiphos, BibleTime and BibleCS use the same in-engine code to do
the searching.

After the 1.6 branch and we get the 1.6.1 with the Windows API calls
worked out, I'll be sure we coordinate with Xiphos to cross-pollinate
our installations to be sure we're all drawing from the same
collections.  That should allow everyone to rest easy that all the
apps behave in the same manner, provided we're not using custom paths
hard coded into BibleTime.

That's something I'll have to take a look at in the code when we go to
1.6 integration and are working with the other teams.

--Greg

On Tue, Apr 21, 2009 at 3:31 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
> Thanks Matthew, updated to use APPDATA in getHomeDir().  From all you've
> read, is this env variable available on all versions of Windows back to 98?
>  Or at least on as many versions of windows as HOMEDRIVE and HOMEPATH?
>
>   -Troy.
>
>
>
> Matthew Talbert wrote:
>>>
>>>  SWBuf homeDir = getenv("HOME");
>>>  if (!homeDir.length()) {
>>>      // silly windows
>>>      homeDir = getenv("HOMEDRIVE");
>>>      if (homeDir.length()) {
>>>          homeDir += getenv("HOMEPATH");
>>>          homeDir += "/Application Data";
>>>      }
>>>
>>
>>
>> There is a much simpler and more correct way of getting this directory:
>>
>> homeDir = getenv("APPDATA")
>>
>> It is more correct, because "Application Data" is localized, and thus
>> won't appear in localized versions of Windows, while APPDATA always
>> contains the localized version. Of course, getenv is wrong because it
>> really needs to be using the Windows API calls to get the correct
>> value, but hopefully that will be fixed sometime.
>>
>> (There are two problems with getenv; the first is that if the
>> environment variable contains symbols that aren't representable in the
>> encoding used by the C runtime, it will not get the correct result.
>> The second is that environment variables on Windows can be nested, so
>> you should either use the Windows methods or carefully look at the
>> return values to make sure that they don't contain variables
>> themselves.)
>>
>> All of this should ideally be discussed on sword-devel as there are
>> other considerations as well. I have been waiting until after 1.6 is
>> released to bring it up.
>>
>> 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
>