[sword-devel] is vista a problem?
dmsmith555 at yahoo.com
Sun Dec 9 06:46:45 MST 2007
On Dec 9, 2007, at 7:37 AM, Wolfgang Schultz wrote:
> Sword for windows seems to run without problems, but the install
> manager requires administrator privileges which should be changed
> because of security considerations.
I may have the paths slightly wrong as I am writing this from memory
while on a Mac
Modules traditionally go to C:\Program Files\Crosswire\The SWORD
Project for Windows\ in mods.d and modules
This design allows all users to share the installation. But it means
that all user's need to have administrator permission to do an install.
On Windows XP this isn't a problem because it is so frustrating to be
a "regular" user that almost everyone is granted "administrator".
Perhaps, Vista is an improvement. I have no plans to upgrade as XP
suits me just fine. And with service pack 3 coming out soon, I have
even less reason. And the cost for Ultimate (I need to be able to run
it in a Virtual Machine) is too high. So I am not able to test.
Both Mac OSX and Windows OS (as of ME) now have the notion of the
location of per user application data. On Mac this is ~/Library/
Application Support and on Windows it is ~/Application Data (or
something like that). BibleDesktop tries to use these areas. MacSword
is planning to use it.
On another compatibility note, I have had a few problem reports with
BibleDesktop under Vista. Turns out that Java has a bug (now fixed)
that prevents BibleDesktop from starting or from showing a native file
The second report is that we use NSIS (Nullsoft Installer) to launch
the program and Vista has code to recognize the binaries and always
complain to the user that the application is being installed, or
something like that. Not exactly sure what people are doing to work
around it (e.g. click through the dialogs or turning off the Vista
Like was suggested before, help from others is appreciated.
> 2007/12/8, Chris Little <chrislit at crosswire.org>:
>> Sword isn't the kind of software that would have any problems
>> running on
>> one flavor of Windows vs. another, simply because so much of the
>> underlying engine operates in non-Windowsy ways and independent of
>> but the most fundamental Windows APIs.
>> Sword for Windows works fine.
More information about the sword-devel