Re: [sword-devel] Win32 FileMgr Subclass

[David Haslam]

Thanks Greg,

I have just downloaded the two Xiphos builds and successfully installed the x32 
edition of Xiphos.

I observe afterwards that the Sword utilities all have the filedate 2020-04-26 
07:26
Was this to be expected?
And is this commensurate with the issue that this new build addressed?
i.e. The scope of the fix was entirely within the SWORD API and nothing in the 
utilities themselves also required fixing to cope with UTF-8 filenames and 
paths.

While it's still fresh in my mind, I have a further question. My Win7 PC is an 
x64 machine.
When I first installed Xiphos therein back in 2010 there was only the 32-bit 
edition available.
Are there any special considerations or precautions advised for a user wishing 
to install the x64 edition in place of an already installed x32 edition?

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, 27 July 2020 15:24, Greg Hellings  wrote:

> On Mon, Jul 27, 2020 at 4:42 AM Troy A. Griffitts  
> wrote:
>
>> That crazy cmake line certain did work to configure a cross-compile. Someone 
>> needs to write that one down somewhere.
>
> That line was taken from my RPM build script. Most of it is the standard 
> MinGW cross-compile macro used, then a few extra options were my specific 
> addons for Sword options.
>
>> So, I've included  in filemgr.cpp and this seems to resolve this 
>> for mingw. I get a bunch of .EXEs in utilities, so I think it worked.
>
> Worked beautifully for me, as well.
>
>> I'll commit, and then go back and be sure I haven't broken the build on BCB. 
>> I trust Microsoft VC++ has wchar.h available so it shouldn't break with the 
>> new change.
>>
>> And now I think we have 3 Microsoft compilers building (I hesitate to say 
>> "working" until we get confirmation that app using pristine SWORD can indeed 
>> work in paths above UTF-8 single byte on Windows.
>
> Fedora 30 and 31 cross-compile builds are here: 
> http://dl.thehellings.com/sword/ (Xiphos still uses Fedora 30 to build the 
> Windows versions due to needing GtkHTML). If any other Xiphos developers want 
> to do testing, or if BibleTime does any cross compiling from Fedora. You can 
> also find Xiphos installers building the latest Xiphos head against this 
> latest Sword head. I'm very far from any Windows machine I can use as a test, 
> so if anyone else has a Windows machine to test this on - preferably one with 
> a username that includes non-ASCII characters in it - then feel free to grab 
> that. If the BibleTime Windows builder (Gary?) wants to generate builds 
> against the latest SVN HEAD and test in the same manner, it would be a huge 
> help.
>
> Yes, David, this is the very latest set of Sword Utility builds you can 
> currently find for Windows, as well. It represents the exact State Of The Art 
> SVN HEAD built for Windows. It will be the ones installed at the root of the 
> Xiphos binary instead of my standalone pack. And no, it's still not 
> officially supported. 😋
>
>> Thanks for your help Greg and Tobias. It was great to have support through 
>> this long dreaded task.
>
> Thank you for the dedication to get it working and remove that patch point.
>
> --Greg
>
>> Happy Monday!
>>
>> Troy
>>
>> On 7/27/20 7:57 AM, Greg Hellings wrote:
>>
>>> If you're missing dependencies you should be able to do, "dnf builddep 
>>> mingw-sword".
>>>
>>> --Greg
>>>
>>> On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings  
>>> wrote:
>>>
 On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:

> Hi Troy,
>
> The latest version builds successfully.
>
> I created a new intermediate release of sword-build-win32 for further 
> testing on Windows:

 It's still failing for me trying to do a cross-compile with MinGW:

 [ 6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
 /usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE 
 -DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
 -DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
 -DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT 
 -D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp 
 -D_ICUSWORD_ -g3 -Wall -O0 -D_ICUSWORD_ -o 
 CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
 /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
 /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member 
 function 'static int sword::FileMgr::createParent(const char*)':
 /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error: 
 '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
 439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
 | ^~~
 | mkdir
 make[2]: *** [CMakeFiles/sword.dir/build.make:282: 
 CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
 make[2]: Leaving directory 
 '/builddir/build/BUILD/sword-1.8.900/build_win32'
 make[1]: 

Re: [sword-devel] Win32 FileMgr Subclass - BibleTime

[Greg Hellings]

On Mon, Jul 27, 2020 at 3:22 PM Tobias Klein  wrote:

> Maybe it helps: This is how I build bzip2 on Windows with the Visual
> Studio compiler based on their Git repo *git://sourceware.org/git/bzip2.git
> <http://sourceware.org/git/bzip2.git>*.
>
>
>
>
> https://github.com/tobias-klein/sword-build-win32/blob/master/build_bzip2.bat
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Gary Holmlund 
> *Sent: *Montag, 27. Juli 2020 21:01
> *To: *SWORD Developers' Collaboration Forum ; Greg
> Hellings 
> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass - BibleTime
>
>
>
>
>
> On 7/27/2020 7:24 AM, Greg Hellings wrote:
>
> >
>
> > If any other Xiphos developers want to do testing, or if BibleTime
>
> > does any cross compiling from Fedora. You can also find Xiphos
>
> > installers building the latest Xiphos head against this latest Sword
>
> > head. I'm very far from any Windows machine I can use as a test, so if
>
> > anyone else has a Windows machine to test this on - preferably one
>
> > with a username that includes non-ASCII characters in it - then feel
>
> > free to grab that. If the BibleTime Windows builder (Gary?) wants to
>
> > generate builds against the latest SVN HEAD and test in the same
>
> > manner, it would be a huge help.
>
>
>
> Greg,
>
>
>
> I tried to build BibleTime with the latest sword svn, but I ran into a
>
> build issue. We don't build with bzip2 because it is not well supported
>
> on Windows. I used the cmake var SWORD_NO_BZIP2=Yes, but the sword build
>
> still required bzip2. Can you fix this?
>

Interesting. I was sitting here trying to figure out what you could be
possibly running into. I don't do my builds with bzip2 installed from MinGW!

Turns out CMakeLists.txt has:

IF(MSVC)
 FIND_PACKAGE(BZIP2 REQUIRED)
 FIND_PACKAGE(XZ REQUIRED)
 FIND_PACKAGE(ICU REQUIRED)
 FIND_PACKAGE(CURL REQUIRED)
ELSE(MSVC)
 FIND_PACKAGE(BZIP2 QUIET)
 FIND_PACKAGE(XZ QUIET)
 FIND_PACKAGE(ICU
COMPONENTS data i18n io uc)
 FIND_PACKAGE(CURL QUIET)
ENDIF(MSVC)

No issues taking that out, but why would I have make BZip2, XZ, and cURL
required on MSVC but not for any builds with gcc, even on Windows?

As for its support, I imagine you can use vcpkg to install it? Then you
don't have to mess with maintaining your own builds.

--Greg

>
>
> Gary Holmlund
>
>
>
> ___
>
> sword-devel mailing list: sword-devel@crosswire.org
>
> http://www.crosswire.org/mailman/listinfo/sword-devel
>
> Instructions to unsubscribe/change your settings at above page
>
>
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass - BibleTime

[Gary Holmlund]

On 7/27/2020 7:24 AM, Greg Hellings wrote:


If any other Xiphos developers want to do testing, or if BibleTime 
does any cross compiling from Fedora. You can also find Xiphos 
installers building the latest Xiphos head against this latest Sword 
head. I'm very far from any Windows machine I can use as a test, so if 
anyone else has a Windows machine to test this on - preferably one 
with a username that includes non-ASCII characters in it - then feel 
free to grab that. If the BibleTime Windows builder (Gary?) wants to 
generate builds against the latest SVN HEAD and test in the same 
manner, it would be a huge help.


Greg,

I tried to build BibleTime with the latest sword svn, but I ran into a 
build issue. We don't build with bzip2 because it is not well supported 
on Windows. I used the cmake var SWORD_NO_BZIP2=Yes, but the sword build 
still required bzip2. Can you fix this?


Gary Holmlund

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

Just to confirm. The VS-based build still works fine after the latest commit 
(svn rev 3771).

Best regards,
Tobias

From: Troy A. Griffitts
Sent: Montag, 27. Juli 2020 10:42
To: SWORD Developers' Collaboration Forum
Subject: Re: [sword-devel] Win32 FileMgr Subclass

That crazy cmake line certain did work to configure a cross-compile.  Someone 
needs to write that one down somewhere.
So, I've included  in filemgr.cpp and this seems to resolve this for 
mingw.  I get a bunch of .EXEs in utilities, so I think it worked.
I'll commit, and then go back and be sure I haven't broken the build on BCB.  I 
trust Microsoft VC++ has wchar.h available so it shouldn't break with the new 
change.
And now I think we have 3 Microsoft compilers building (I hesitate to say 
"working" until we get confirmation that app using pristine SWORD can indeed 
work in paths above UTF-8 single byte on Windows.
Thanks for your help Greg and Tobias.  It was great to have support through 
this long dreaded task.
Happy Monday!
Troy

On 7/27/20 7:57 AM, Greg Hellings wrote:
If you're missing dependencies you should be able to do, "dnf builddep 
mingw-sword".

--Greg

On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings  wrote:


On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:
Hi Troy,
The latest version builds successfully.
I created a new intermediate release of sword-build-win32 for further testing 
on Windows:
It's still failing for me trying to do a cross-compile with MinGW:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE -DCURLSFTPAVAILABLE 
-DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT -D_ICU_ 
-Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_ -g3 -Wall 
-O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member 
function 'static int sword::FileMgr::createParent(const char*)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error: '_wmkdir' 
was not declared in this scope; did you mean 'mkdir'?
  439 |     _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
      |     ^~~
      |     mkdir
make[2]: *** [CMakeFiles/sword.dir/build.make:282: 
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'

Commands to do the build, from Fedora 32, include this lovely invocation of 
CMake from within a subfolder of the source (build_win32 for the above):
/usr/bin/cmake -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake 
-DBUILD_SHARED_LIBS:BOOL=ON 
-DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share 
-DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw 
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib 
-DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin 
-DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include 
-DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared 
-DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug 
-DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_MINGW32=TRUE ..

Followed by

make

--Greg
https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26
Best regards,
Tobias
On 7/26/20 8:37 PM, Troy A. Griffitts wrote:
Thanks Tobias,
I've made these updates and should have fixed the error in filemgr.cpp on line 
410. I appreciate the feedback.  Please update and try this out and let me 
know.  Thanks for testing your compiler.
Troy

On 7/26/20 8:25 PM, Tobias Klein wrote:
To address the errors below I had to add the include for  both in 
src/mgr/filemgr.cpp and in src/modules/commons/zipmgr.cpp.
After that I'm getting the next error:
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): error 
C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot convert argument 
2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): note: 
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style 
cast or function-style cast
Best regards,
Tobias
On 7/26/20 4:44 PM, Troy A. Griffitts wrote:
Can one of you guys try simply including  at the top of filemgr.cpp 
and see if this fix

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Mon, Jul 27, 2020 at 4:42 AM Troy A. Griffitts 
wrote:

> That crazy cmake line certain did work to configure a cross-compile.
> Someone needs to write that one down somewhere.
>
That line was taken from my RPM build script. Most of it is the standard
MinGW cross-compile macro used, then a few extra options were my specific
addons for Sword options.

> So, I've included  in filemgr.cpp and this seems to resolve this
> for mingw.  I get a bunch of .EXEs in utilities, so I think it worked.
>
Worked beautifully for me, as well.

> I'll commit, and then go back and be sure I haven't broken the build on
> BCB.  I trust Microsoft VC++ has wchar.h available so it shouldn't break
> with the new change.
>
> And now I think we have 3 Microsoft compilers building (I hesitate to say
> "working" until we get confirmation that app using pristine SWORD can
> indeed work in paths above UTF-8 single byte on Windows.
>
Fedora 30 and 31 cross-compile builds are here:
http://dl.thehellings.com/sword/ (Xiphos still uses Fedora 30 to build the
Windows versions due to needing GtkHTML). If any other Xiphos developers
want to do testing, or if BibleTime does any cross compiling from Fedora.
You can also find Xiphos installers building the latest Xiphos head against
this latest Sword head. I'm very far from any Windows machine I can use as
a test, so if anyone else has a Windows machine to test this on -
preferably one with a username that includes non-ASCII characters in it -
then feel free to grab that. If the BibleTime Windows builder (Gary?) wants
to generate builds against the latest SVN HEAD and test in the same manner,
it would be a huge help.

Yes, David, this is the very latest set of Sword Utility builds you can
currently find for Windows, as well. It represents the exact State Of The
Art SVN HEAD built for Windows. It will be the ones installed at the root
of the Xiphos binary instead of my standalone pack. And no, it's still not
officially supported. 😋

> Thanks for your help Greg and Tobias.  It was great to have support
> through this long dreaded task.
>
Thank you for the dedication to get it working and remove that patch point.

--Greg

> Happy Monday!
>
> Troy
>
>
> On 7/27/20 7:57 AM, Greg Hellings wrote:
>
> If you're missing dependencies you should be able to do, "dnf builddep
> mingw-sword".
>
> --Greg
>
> On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings 
> wrote:
>
>>
>>
>> On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:
>>
>>> Hi Troy,
>>>
>>> The latest version builds successfully.
>>>
>>> I created a new intermediate release of sword-build-win32 for further
>>> testing on Windows:
>>>
>> It's still failing for me trying to do a cross-compile with MinGW:
>>
>> [  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
>> /usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
>> -DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
>> -DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
>> -DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
>> -D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
>> -g3 -Wall -O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
>> -c /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
>> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
>> function 'static int sword::FileMgr::createParent(const char*)':
>> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error:
>> '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
>>   439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
>>   | ^~~
>>   | mkdir
>> make[2]: *** [CMakeFiles/sword.dir/build.make:282:
>> CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
>> make[2]: Leaving directory
>> '/builddir/build/BUILD/sword-1.8.900/build_win32'
>> make[1]: Leaving directory
>> '/builddir/build/BUILD/sword-1.8.900/build_win32'
>> make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
>> make: *** [Makefile:152: all] Error 2
>> make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
>>
>> Commands to do the build, from Fedora 32, include this lovely invocation
>> of CMake from within a subfolder of the source (build_win32 for the above):
>> /usr/bin/cmake
>> -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
>> -DBUILD_SHARED_LIBS:BOOL=ON
>> -DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
>> -DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
>> -DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
>> -DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
>> -DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin
>> -DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
>> -DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared
>> -DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug
>> -DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_M

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

That crazy cmake line certain did work to configure a cross-compile.  
Someone needs to write that one down somewhere.


So, I've included  in filemgr.cpp and this seems to resolve 
this for mingw.  I get a bunch of .EXEs in utilities, so I think it worked.


I'll commit, and then go back and be sure I haven't broken the build on 
BCB.  I trust Microsoft VC++ has wchar.h available so it shouldn't break 
with the new change.


And now I think we have 3 Microsoft compilers building (I hesitate to 
say "working" until we get confirmation that app using pristine SWORD 
can indeed work in paths above UTF-8 single byte on Windows.


Thanks for your help Greg and Tobias.  It was great to have support 
through this long dreaded task.


Happy Monday!

Troy


On 7/27/20 7:57 AM, Greg Hellings wrote:
If you're missing dependencies you should be able to do, "dnf builddep 
mingw-sword".


--Greg

On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings > wrote:




On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein mailto:cont...@tklein.info>> wrote:

Hi Troy,

The latest version builds successfully.

I created a new intermediate release of sword-build-win32 for
further testing on Windows:

It's still failing for me trying to do a cross-compile with MinGW:

[  6%] Building CXX object
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE
-D_FTPLIB_NO_COMPAT -D_ICU_ -Dsword_EXPORTS
@CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_ -g3 -Wall -O0
-D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static
member function 'static int sword::FileMgr::createParent(const
char*)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5:
error: '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
  439 |     _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
      |     ^~~
      |     mkdir
make[2]: *** [CMakeFiles/sword.dir/build.make:282:
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
make[2]: Leaving directory
'/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: Leaving directory
'/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all]
Error 2
make: *** [Makefile:152: all] Error 2
make: Leaving directory
'/builddir/build/BUILD/sword-1.8.900/build_win32'

Commands to do the build, from Fedora 32, include this lovely
invocation of CMake from within a subfolder of the source
(build_win32 for the above):
/usr/bin/cmake
-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
-DBUILD_SHARED_LIBS:BOOL=ON
-DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
-DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
-DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin
-DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
-DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared
-DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug
-DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_MINGW32=TRUE ..

Followed by

make

--Greg


https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26

Best regards,
Tobias

On 7/26/20 8:37 PM, Troy A. Griffitts wrote:


Thanks Tobias,

I've made these updates and should have fixed the error in
filemgr.cpp on line 410. I appreciate the feedback.  Please
update and try this out and let me know.  Thanks for testing
your compiler.

Troy


On 7/26/20 8:25 PM, Tobias Klein wrote:


To address the errors below I had to add the include for
 both in *src/mgr/filemgr.cpp* and in
*src/modules/commons/zipmgr.cpp*.

After that I'm getting the next error:

1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
error C2664: 'BOOL
FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot convert
argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
note: Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast

Best regards,
Tobias

On 7/26/20 4:44 PM, Troy A. Griffitts wrote:


Can one of you guys t

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

If you're missing dependencies you should be able to do, "dnf builddep
mingw-sword".

--Greg

On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings 
wrote:

>
>
> On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:
>
>> Hi Troy,
>>
>> The latest version builds successfully.
>>
>> I created a new intermediate release of sword-build-win32 for further
>> testing on Windows:
>>
> It's still failing for me trying to do a cross-compile with MinGW:
>
> [  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
> /usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
> -DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
> -DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
> -DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
> -D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
> -g3 -Wall -O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
> -c /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
> function 'static int sword::FileMgr::createParent(const char*)':
> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error:
> '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
>   439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
>   | ^~~
>   | mkdir
> make[2]: *** [CMakeFiles/sword.dir/build.make:282:
> CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
> make[2]: Leaving directory
> '/builddir/build/BUILD/sword-1.8.900/build_win32'
> make[1]: Leaving directory
> '/builddir/build/BUILD/sword-1.8.900/build_win32'
> make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
> make: *** [Makefile:152: all] Error 2
> make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
>
> Commands to do the build, from Fedora 32, include this lovely invocation
> of CMake from within a subfolder of the source (build_win32 for the above):
> /usr/bin/cmake
> -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
> -DBUILD_SHARED_LIBS:BOOL=ON
> -DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
> -DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
> -DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
> -DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin
> -DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
> -DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared
> -DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug
> -DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_MINGW32=TRUE ..
>
> Followed by
>
> make
>
> --Greg
>
>>
>> https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26
>>
>> Best regards,
>> Tobias
>> On 7/26/20 8:37 PM, Troy A. Griffitts wrote:
>>
>> Thanks Tobias,
>>
>> I've made these updates and should have fixed the error in filemgr.cpp on
>> line 410. I appreciate the feedback.  Please update and try this out and
>> let me know.  Thanks for testing your compiler.
>>
>> Troy
>>
>>
>> On 7/26/20 8:25 PM, Tobias Klein wrote:
>>
>> To address the errors below I had to add the include for  both
>> in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.
>>
>> After that I'm getting the next error:
>>
>> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
>> error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot
>> convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
>> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
>> note: Types pointed to are unrelated; conversion requires reinterpret_cast,
>> C-style cast or function-style cast
>>
>> Best regards,
>> Tobias
>> On 7/26/20 4:44 PM, Troy A. Griffitts wrote:
>>
>> Can one of you guys try simply including  at the top of
>> filemgr.cpp and see if this fixes it for you?
>>
>>
>> On 7/26/20 4:01 PM, Tobias Klein wrote:
>>
>> I'm getting similar error messages with Visual Studio 2019. Note that I'm
>> also generating the make files via CMake.
>>
>> First couple of error messages:
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2):
>> error C2065: 'WIN32_FIND_DATAW': undeclared identifier
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
>> error C2146: syntax error: missing ';' before identifier 'fileData'
>>
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
>> error C2065: 'fileData': undeclared identifier
>>
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2):
>> error C2065: 'HANDLE': undeclared identifier
>>
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
>> error C2146: syntax error: missing ';' before identifier 'findIterator'
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
>> error C2

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:

> Hi Troy,
>
> The latest version builds successfully.
>
> I created a new intermediate release of sword-build-win32 for further
> testing on Windows:
>
It's still failing for me trying to do a cross-compile with MinGW:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
-D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
-g3 -Wall -O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
-c /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
function 'static int sword::FileMgr::createParent(const char*)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error:
'_wmkdir' was not declared in this scope; did you mean 'mkdir'?
  439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
  | ^~~
  | mkdir
make[2]: *** [CMakeFiles/sword.dir/build.make:282:
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'

Commands to do the build, from Fedora 32, include this lovely invocation of
CMake from within a subfolder of the source (build_win32 for the above):
/usr/bin/cmake
-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
-DBUILD_SHARED_LIBS:BOOL=ON
-DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
-DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
-DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin
-DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
-DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared
-DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug
-DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_MINGW32=TRUE ..

Followed by

make

--Greg

>
> https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26
>
> Best regards,
> Tobias
> On 7/26/20 8:37 PM, Troy A. Griffitts wrote:
>
> Thanks Tobias,
>
> I've made these updates and should have fixed the error in filemgr.cpp on
> line 410. I appreciate the feedback.  Please update and try this out and
> let me know.  Thanks for testing your compiler.
>
> Troy
>
>
> On 7/26/20 8:25 PM, Tobias Klein wrote:
>
> To address the errors below I had to add the include for  both
> in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.
>
> After that I'm getting the next error:
>
> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
> error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot
> convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
> note: Types pointed to are unrelated; conversion requires reinterpret_cast,
> C-style cast or function-style cast
>
> Best regards,
> Tobias
> On 7/26/20 4:44 PM, Troy A. Griffitts wrote:
>
> Can one of you guys try simply including  at the top of
> filemgr.cpp and see if this fixes it for you?
>
>
> On 7/26/20 4:01 PM, Tobias Klein wrote:
>
> I'm getting similar error messages with Visual Studio 2019. Note that I'm
> also generating the make files via CMake.
>
> First couple of error messages:
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2):
> error C2065: 'WIN32_FIND_DATAW': undeclared identifier
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
> error C2146: syntax error: missing ';' before identifier 'fileData'
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
> error C2065: 'fileData': undeclared identifier
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2):
> error C2065: 'HANDLE': undeclared identifier
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
> error C2146: syntax error: missing ';' before identifier 'findIterator'
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
> error C2065: 'findIterator': undeclared identifier
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51):
> error C2065: 'fileData': undeclared identifier
>
>
> Best regards,
> Tobias
>
> On 7/26/20 3:00 PM, Greg Hellings wrote:
>
>
>
> On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
> wrote

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

Hi Troy,

The latest version builds successfully.

I created a new intermediate release of sword-build-win32 for further 
testing on Windows:


https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26

Best regards,
Tobias

On 7/26/20 8:37 PM, Troy A. Griffitts wrote:


Thanks Tobias,

I've made these updates and should have fixed the error in filemgr.cpp 
on line 410. I appreciate the feedback.  Please update and try this 
out and let me know.  Thanks for testing your compiler.


Troy


On 7/26/20 8:25 PM, Tobias Klein wrote:


To address the errors below I had to add the include for  
both in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.


After that I'm getting the next error:

1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot 
convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
note: Types pointed to are unrelated; conversion requires 
reinterpret_cast, C-style cast or function-style cast


Best regards,
Tobias

On 7/26/20 4:44 PM, Troy A. Griffitts wrote:


Can one of you guys try simply including  at the top of 
filemgr.cpp and see if this fixes it for you?



On 7/26/20 4:01 PM, Tobias Klein wrote:


I'm getting similar error messages with Visual Studio 2019. Note 
that I'm also generating the make files via CMake.


First couple of error messages:

2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2): 
error C2065: 'WIN32_FIND_DATAW': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2146: syntax error: missing ';' before identifier 'fileData'


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2065: 'fileData': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2): 
error C2065: 'HANDLE': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2146: syntax error: missing ';' before identifier 
'findIterator'
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2065: 'findIterator': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51): 
error C2065: 'fileData': undeclared identifier



Best regards,
Tobias

On 7/26/20 3:00 PM, Greg Hellings wrote:



On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
mailto:scr...@crosswire.org>> wrote:


I've just committed the last bit for fixing the WIN32 Unicode
issues.  If anyone can try compiling and running Xiphos
without the Xiphos patch or any other projects for Windows,
and let me know if things work for them in folders which
include Unicode character, I would appreciate it.  I've tested
BibleCS and it now works with a SWORD_PATH defined to
/books/χαρις.  I've tested using and installing modules in
this configuration and believe all the bugs are squashed, but
I would love confirmation from other projects.

Thanks for any feedback,

Troy

During cross-compile I'm getting the following errors:

[  6%] Building CXX object 
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE 
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE 
-D_FTPLIB_NO_COMPAT -D_ICU_ -Dsword_EXPORTS 
@CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_ -g3 -Wall -O0 
-D_ICUSWORD_   -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static std::vector 
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: 
error: 'WIN32_FIND_DATAW' was not declared in this scope

  395 |  WIN32_FIND_DATAW fileData;
      |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: 
error: 'HANDLE' was not declared in this scope

  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
      |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: 
error: 'findIterator' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: 
error: 'INVALID_HANDLE_VALUE' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |                      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: 
error: 'fileData' was not declared in this scope

  401 |    SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
      |                                   ^~~~
/builddir/bui

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

Thanks Tobias,

I've made these updates and should have fixed the error in filemgr.cpp 
on line 410. I appreciate the feedback.  Please update and try this out 
and let me know.  Thanks for testing your compiler.


Troy


On 7/26/20 8:25 PM, Tobias Klein wrote:


To address the errors below I had to add the include for  
both in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.


After that I'm getting the next error:

1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot 
convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
note: Types pointed to are unrelated; conversion requires 
reinterpret_cast, C-style cast or function-style cast


Best regards,
Tobias

On 7/26/20 4:44 PM, Troy A. Griffitts wrote:


Can one of you guys try simply including  at the top of 
filemgr.cpp and see if this fixes it for you?



On 7/26/20 4:01 PM, Tobias Klein wrote:


I'm getting similar error messages with Visual Studio 2019. Note 
that I'm also generating the make files via CMake.


First couple of error messages:

2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2): 
error C2065: 'WIN32_FIND_DATAW': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2146: syntax error: missing ';' before identifier 'fileData'


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2065: 'fileData': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2): 
error C2065: 'HANDLE': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2146: syntax error: missing ';' before identifier 'findIterator'
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2065: 'findIterator': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51): 
error C2065: 'fileData': undeclared identifier



Best regards,
Tobias

On 7/26/20 3:00 PM, Greg Hellings wrote:



On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
mailto:scr...@crosswire.org>> wrote:


I've just committed the last bit for fixing the WIN32 Unicode
issues.  If anyone can try compiling and running Xiphos without
the Xiphos patch or any other projects for Windows, and let me
know if things work for them in folders which include Unicode
character, I would appreciate it.  I've tested BibleCS and it
now works with a SWORD_PATH defined to /books/χαρις.  I've
tested using and installing modules in this configuration and
believe all the bugs are squashed, but I would love
confirmation from other projects.

Thanks for any feedback,

Troy

During cross-compile I'm getting the following errors:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE 
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE 
-D_FTPLIB_NO_COMPAT -D_ICU_ -Dsword_EXPORTS 
@CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_ -g3 -Wall -O0 
-D_ICUSWORD_   -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static std::vector 
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: 
error: 'WIN32_FIND_DATAW' was not declared in this scope

  395 |  WIN32_FIND_DATAW fileData;
      |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: 
error: 'HANDLE' was not declared in this scope

  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
      |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: 
error: 'findIterator' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: 
error: 'INVALID_HANDLE_VALUE' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |                      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: 
error: 'fileData' was not declared in this scope

  401 |    SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
      |                                   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: 
error: 'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 |     i.isDirectory = fileData.dwFileAttributes & 
FILE_ATTRIBUTE_DIRECTORY;

      |   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40:

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

To address the errors below I had to add the include for  
both in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.


After that I'm getting the next error:

1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot 
convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410): 
note: Types pointed to are unrelated; conversion requires 
reinterpret_cast, C-style cast or function-style cast


Best regards,
Tobias

On 7/26/20 4:44 PM, Troy A. Griffitts wrote:


Can one of you guys try simply including  at the top of 
filemgr.cpp and see if this fixes it for you?



On 7/26/20 4:01 PM, Tobias Klein wrote:


I'm getting similar error messages with Visual Studio 2019. Note that 
I'm also generating the make files via CMake.


First couple of error messages:

2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2): 
error C2065: 'WIN32_FIND_DATAW': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2146: syntax error: missing ';' before identifier 'fileData'


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2065: 'fileData': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2): 
error C2065: 'HANDLE': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2146: syntax error: missing ';' before identifier 'findIterator'
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2065: 'findIterator': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51): 
error C2065: 'fileData': undeclared identifier



Best regards,
Tobias

On 7/26/20 3:00 PM, Greg Hellings wrote:



On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
mailto:scr...@crosswire.org>> wrote:


I've just committed the last bit for fixing the WIN32 Unicode
issues.  If anyone can try compiling and running Xiphos without
the Xiphos patch or any other projects for Windows, and let me
know if things work for them in folders which include Unicode
character, I would appreciate it.  I've tested BibleCS and it
now works with a SWORD_PATH defined to /books/χαρις.  I've
tested using and installing modules in this configuration and
believe all the bugs are squashed, but I would love confirmation
from other projects.

Thanks for any feedback,

Troy

During cross-compile I'm getting the following errors:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE 
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE 
-D_FTPLIB_NO_COMPAT -D_ICU_ -Dsword_EXPORTS 
@CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_ -g3 -Wall -O0 
-D_ICUSWORD_   -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static std::vector 
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: 
error: 'WIN32_FIND_DATAW' was not declared in this scope

  395 |  WIN32_FIND_DATAW fileData;
      |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: 
error: 'HANDLE' was not declared in this scope

  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
      |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: 
error: 'findIterator' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: 
error: 'INVALID_HANDLE_VALUE' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |                      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: 
error: 'fileData' was not declared in this scope

  401 |    SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
      |                                   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: 
error: 'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 |     i.isDirectory = fileData.dwFileAttributes & 
FILE_ATTRIBUTE_DIRECTORY;

      | ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40: 
error: 'fileData' was not declared in this scope

  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
      |                                        ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:12: 
error: 'FindNextFile' was not 

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

Can one of you guys try simply including  at the top of 
filemgr.cpp and see if this fixes it for you?



On 7/26/20 4:01 PM, Tobias Klein wrote:


I'm getting similar error messages with Visual Studio 2019. Note that 
I'm also generating the make files via CMake.


First couple of error messages:

2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2): 
error C2065: 'WIN32_FIND_DATAW': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2146: syntax error: missing ';' before identifier 'fileData'


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2065: 'fileData': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2): 
error C2065: 'HANDLE': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2146: syntax error: missing ';' before identifier 'findIterator'
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2065: 'findIterator': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51): 
error C2065: 'fileData': undeclared identifier



Best regards,
Tobias

On 7/26/20 3:00 PM, Greg Hellings wrote:



On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
mailto:scr...@crosswire.org>> wrote:


I've just committed the last bit for fixing the WIN32 Unicode
issues.  If anyone can try compiling and running Xiphos without
the Xiphos patch or any other projects for Windows, and let me
know if things work for them in folders which include Unicode
character, I would appreciate it.  I've tested BibleCS and it now
works with a SWORD_PATH defined to /books/χαρις.  I've tested
using and installing modules in this configuration and believe
all the bugs are squashed, but I would love confirmation from
other projects.

Thanks for any feedback,

Troy

During cross-compile I'm getting the following errors:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE 
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT 
-D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp 
-D_ICUSWORD_ -g3 -Wall -O0 -D_ICUSWORD_   -o 
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static std::vector 
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: error: 
'WIN32_FIND_DATAW' was not declared in this scope

  395 |  WIN32_FIND_DATAW fileData;
      |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: error: 
'HANDLE' was not declared in this scope

  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
      |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: error: 
'findIterator' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: 
error: 'INVALID_HANDLE_VALUE' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |                      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: 
error: 'fileData' was not declared in this scope

  401 |    SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
      |                                   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: 
error: 'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 |     i.isDirectory = fileData.dwFileAttributes & 
FILE_ATTRIBUTE_DIRECTORY;

      | ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40: 
error: 'fileData' was not declared in this scope

  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
      |                                        ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:12: 
error: 'FindNextFile' was not declared in this scope

  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
      |            ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:410:3: error: 
'FindClose' was not declared in this scope; did you mean '_findclose'?

  410 |   FindClose(findIterator);
      |   ^
      |   _findclose
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:397:17: 
warning: unused variable 'wcharPath' [-Wunused-variable]
  397 |  const wchar_t *wcharPath = (const wchar_t 
*)wcharBuf.getRawData();

      |                 ^
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In stat

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

I'm getting similar error messages with Visual Studio 2019. Note that 
I'm also generating the make files via CMake.


First couple of error messages:

2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2): 
error C2065: 'WIN32_FIND_DATAW': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2146: syntax error: missing ';' before identifier 'fileData'


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19): 
error C2065: 'fileData': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2): 
error C2065: 'HANDLE': undeclared identifier


2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2146: syntax error: missing ';' before identifier 'findIterator'
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9): 
error C2065: 'findIterator': undeclared identifier
2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,51): 
error C2065: 'fileData': undeclared identifier



Best regards,
Tobias

On 7/26/20 3:00 PM, Greg Hellings wrote:



On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
mailto:scr...@crosswire.org>> wrote:


I've just committed the last bit for fixing the WIN32 Unicode
issues.  If anyone can try compiling and running Xiphos without
the Xiphos patch or any other projects for Windows, and let me
know if things work for them in folders which include Unicode
character, I would appreciate it.  I've tested BibleCS and it now
works with a SWORD_PATH defined to /books/χαρις.  I've tested
using and installing modules in this configuration and believe all
the bugs are squashed, but I would love confirmation from other
projects.

Thanks for any feedback,

Troy

During cross-compile I'm getting the following errors:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE 
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ 
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\" 
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT 
-D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp 
-D_ICUSWORD_ -g3 -Wall -O0 -D_ICUSWORD_   -o 
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c 
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static std::vector 
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: error: 
'WIN32_FIND_DATAW' was not declared in this scope

  395 |  WIN32_FIND_DATAW fileData;
      |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: error: 
'HANDLE' was not declared in this scope

  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
      |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: error: 
'findIterator' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: error: 
'INVALID_HANDLE_VALUE' was not declared in this scope

  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
      |                      ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: error: 
'fileData' was not declared in this scope

  401 |    SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
      |                                   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: error: 
'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 |     i.isDirectory = fileData.dwFileAttributes & 
FILE_ATTRIBUTE_DIRECTORY;

      | ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40: error: 
'fileData' was not declared in this scope

  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
      |                                        ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:12: error: 
'FindNextFile' was not declared in this scope

  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
      |            ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:410:3: error: 
'FindClose' was not declared in this scope; did you mean '_findclose'?

  410 |   FindClose(findIterator);
      |   ^
      |   _findclose
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:397:17: 
warning: unused variable 'wcharPath' [-Wunused-variable]
  397 |  const wchar_t *wcharPath = (const wchar_t 
*)wcharBuf.getRawData();

      |                 ^
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static 
member function 'static int sword::FileMgr::createParent(const char*)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:436:5: error: 
'

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
wrote:

> I've just committed the last bit for fixing the WIN32 Unicode issues.  If
> anyone can try compiling and running Xiphos without the Xiphos patch or any
> other projects for Windows, and let me know if things work for them in
> folders which include Unicode character, I would appreciate it.  I've
> tested BibleCS and it now works with a SWORD_PATH defined to /books/χαρις.
> I've tested using and installing modules in this configuration and believe
> all the bugs are squashed, but I would love confirmation from other
> projects.
>
> Thanks for any feedback,
>
> Troy
>
During cross-compile I'm getting the following errors:

[  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
/usr/bin/i686-w64-mingw32-g++  -DCLUCENE2 -DCURLAVAILABLE
-DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
-DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
-DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
-D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
-g3 -Wall -O0 -D_ICUSWORD_   -o
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj -c
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
function 'static std::vector
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: error:
'WIN32_FIND_DATAW' was not declared in this scope
  395 |  WIN32_FIND_DATAW fileData;
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: error:
'HANDLE' was not declared in this scope
  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, &fileData);
  |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: error:
'findIterator' was not declared in this scope
  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: error:
'INVALID_HANDLE_VALUE' was not declared in this scope
  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: error:
'fileData' was not declared in this scope
  401 |SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
  |   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: error:
'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 | i.isDirectory = fileData.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY;
  |
^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40: error:
'fileData' was not declared in this scope
  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
  |^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:12: error:
'FindNextFile' was not declared in this scope
  409 |   } while (FindNextFile(findIterator, &fileData) != 0);
  |^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:410:3: error:
'FindClose' was not declared in this scope; did you mean '_findclose'?
  410 |   FindClose(findIterator);
  |   ^
  |   _findclose
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:397:17: warning:
unused variable 'wcharPath' [-Wunused-variable]
  397 |  const wchar_t *wcharPath = (const wchar_t *)wcharBuf.getRawData();
  | ^
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
function 'static int sword::FileMgr::createParent(const char*)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:436:5: error:
'_wmkdir' was not declared in this scope; did you mean 'mkdir'?
  436 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
  | ^~~
  | mkdir
make[2]: *** [CMakeFiles/sword.dir/build.make:283:
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1

I'm assuming there's a new package or macro I need to define? On my system
the WIN32_FIND_DATAW struct is defined in both minwinbase.h and shtypes.h.
I'm building with MinGW which might have a different header structure than
your compilers, if you're using Borland?

--Greg

>
> On 7/20/20 7:18 PM, Greg Hellings wrote:
>
> Sorry for the previous blank email - user error when I tried to reply:
>
> On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:
>
>> Thanks for giving me the background on this, Karl! I appreciate it!
>>
>> Is Xiphos the only frontend that has been patching Sword for this
>> purpose? Then I suppose all other frontends suffer from this issue, huh?
>>
>
> When I first encountered this patch in Xiphos I tested with BibleTime and
> The Sword Project for Windows and both of them do crash under these
> circumstances.
>
> Yes, other toolkits such as Qt do have wrappers for this shortcoming
> already, but none of the other front ends I've worked w

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

I've just committed the last bit for fixing the WIN32 Unicode issues.  
If anyone can try compiling and running Xiphos without the Xiphos patch 
or any other projects for Windows, and let me know if things work for 
them in folders which include Unicode character, I would appreciate it.  
I've tested BibleCS and it now works with a SWORD_PATH defined to 
/books/χαρις.  I've tested using and installing modules in this 
configuration and believe all the bugs are squashed, but I would love 
confirmation from other projects.


Thanks for any feedback,

Troy


On 7/20/20 7:18 PM, Greg Hellings wrote:

Sorry for the previous blank email - user error when I tried to reply:

On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein > wrote:


Thanks for giving me the background on this, Karl! I appreciate it!

Is Xiphos the only frontend that has been patching Sword for this
purpose? Then I suppose all other frontends suffer from this
issue, huh?


When I first encountered this patch in Xiphos I tested with BibleTime 
and The Sword Project for Windows and both of them do crash under 
these circumstances.


Yes, other toolkits such as Qt do have wrappers for this shortcoming 
already, but none of the other front ends I've worked with have 
bothered to put in the effort to produce a patched version of Sword to 
fix the crash.


--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

Sorry for the previous blank email - user error when I tried to reply:

On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:

> Thanks for giving me the background on this, Karl! I appreciate it!
>
> Is Xiphos the only frontend that has been patching Sword for this purpose?
> Then I suppose all other frontends suffer from this issue, huh?
>

When I first encountered this patch in Xiphos I tested with BibleTime and
The Sword Project for Windows and both of them do crash under these
circumstances.

Yes, other toolkits such as Qt do have wrappers for this shortcoming
already, but none of the other front ends I've worked with have bothered to
put in the effort to produce a patched version of Sword to fix the crash.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:

> Thanks for giving me the background on this, Karl! I appreciate it!
>
> Is Xiphos the only frontend that has been patching Sword for this purpose?
> Then I suppose all other frontends suffer from this issue, huh?
>
> Thanks for putting in the work to make Sword behave well with non-ascii
> path names!
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Karl Kleinpaste 
> *Sent: *Sonntag, 19. Juli 2020 15:23
> *To: *SWORD Developers' Collaboration Forum 
> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass
>
>
>
> On 7/18/20 1:53 PM, Tobias Klein wrote:
>
> No, I have not tested my code properly with non-ascii characters in paths
> / file names.
>
>
> The original cause for the Xiphos patch to Sword was because, 11 years ago
> when we introduced the Win32 port, as GnomeSword was renamed Xiphos, one of
> our first new Windows users was a fellow in Spain who wanted to review it.
> His name was Reuvén, and that was his login name on his Windows machine.
> So of course the path C:\Users\Reuvén was involved, and that 'é' is what
> killed us.
>
> What dies here is Sword itself.  Xiphos was fine, being already based on
> glib, but Sword's collapse came as soon as Xiphos made its first filesystem
> call.  The patch glib-ifies Sword, where glib works rather hard at hiding
> the UTF16 boundary from the application.
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Karl Kleinpaste]

On 7/19/20 3:40 PM, Tobias Klein wrote:
> Is Xiphos the only frontend that has been patching Sword for this
> purpose? Then I suppose all other frontends suffer from this issue, huh?

As far as I know, yes to both questions, though JSword apps are of
course differently insulated.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

Thanks for giving me the background on this, Karl! I appreciate it!
Is Xiphos the only frontend that has been patching Sword for this purpose? Then 
I suppose all other frontends suffer from this issue, huh?
Thanks for putting in the work to make Sword behave well with non-ascii path 
names!

Best regards,
Tobias

From: Karl Kleinpaste
Sent: Sonntag, 19. Juli 2020 15:23
To: SWORD Developers' Collaboration Forum
Subject: Re: [sword-devel] Win32 FileMgr Subclass

On 7/18/20 1:53 PM, Tobias Klein wrote:
No, I have not tested my code properly with non-ascii characters in paths / 
file names.

The original cause for the Xiphos patch to Sword was because, 11 years ago when 
we introduced the Win32 port, as GnomeSword was renamed Xiphos, one of our 
first new Windows users was a fellow in Spain who wanted to review it.  His 
name was Reuvén, and that was his login name on his Windows machine.  So of 
course the path C:\Users\Reuvén was involved, and that 'é' is what killed us.

What dies here is Sword itself.  Xiphos was fine, being already based on glib, 
but Sword's collapse came as soon as Xiphos made its first filesystem call.  
The patch glib-ifies Sword, where glib works rather hard at hiding the UTF16 
boundary from the application.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Karl Kleinpaste]

On 7/18/20 1:53 PM, Tobias Klein wrote:
>
> No, I have not tested my code properly with non-ascii characters in
> paths / file names.
>

The original cause for the Xiphos patch to Sword was because, 11 years
ago when we introduced the Win32 port, as GnomeSword was renamed Xiphos,
one of our first new Windows users was a fellow in Spain who wanted to
review it.  His name was Reuvén, and that was his login name on his
Windows machine.  So of course the path C:\Users\Reuvén was involved,
and that 'é' is what killed us.

What dies here is Sword itself.  Xiphos was fine, being already based on
glib, but Sword's collapse came as soon as Xiphos made its first
filesystem call.  The patch glib-ifies Sword, where glib works rather
hard at hiding the UTF16 boundary from the application.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[David Haslam]

Paths and filenames may in theory include all manner of characters from 
non-Roman scripts.
AFAIK, Only a few special characters are not allowed in the various file 
systems.

We ought to avoid a systemic bias to the English language or even the Latin 
script when we design software.

Easy to agree in principle but not so easy to implement successfully.

Localisation of the UI is only part of the task.

I wish you every success, Tobias.

Best regards,

David

Sent from ProtonMail Mobile

On Sat, Jul 18, 2020 at 18:53, Tobias Klein  wrote:

> Thanks Greg & Troy for pointing out these potential issues. No, I have not 
> tested my code properly with non-ascii characters in paths / file names.
>
> I suppose this would particularly be an issue if the username has certain 
> characters that cause issues? (applicable for the ~/.sword directory). And 
> then also, when arbitrary folders are added to SWMgr?!
>
> I’ll do some testing in this area!
>
> I wonder whether libraries like Qt or Boost have solved these kind of issues 
> somehow …
>
> Best regards,
> Tobias
>
> From: [Greg Hellings](mailto:greg.helli...@gmail.com)
> Sent: Samstag, 18. Juli 2020 15:58
> To: [SWORD Developers' Collaboration Forum](mailto:sword-devel@crosswire.org)
> Subject: Re: [sword-devel] Win32 FileMgr Subclass
>
> Tobias,
>
> Has this been tested with file paths that contain characters outside of the 
> basic ASCII code range? That's where current Sword fails. Not in fetching the 
> data for the paths themselves, but the actual calls to fopen and friends, on 
> Windows, do not understand non ASCII data.
>
> It looks like your code would suffer similar to other Sword code, which 
> eventually passes through the library's fopen calls.
>
> On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:
>
>> Maybe not a full-fledged FileMgr class, but at least everything I need in 
>> Ezra Project at the moment:
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>>
>> It works on Windows, macOS and Linux.
>>
>> Best regards,
>> Tobias
>>
>> From: [Troy A. Griffitts](mailto:scr...@crosswire.org)
>> Sent: Samstag, 18. Juli 2020 14:42
>> To: [SWORD Developers' Collaboration Forum](mailto:sword-devel@crosswire.org)
>> Subject: [sword-devel] Win32 FileMgr Subclass
>>
>> I know Greg has sent me a link to the patch you guys apply to get Xiphos
>>
>> to run well on Win32, but I have searched through all my past emails
>>
>> with every relevant term I can thing of, and still can't find it. I am
>>
>> sorry, Could you possibly sent that again? I think you guys were using
>>
>> glib routines. If possible, I'd like to include something in SWORD more
>>
>> generic, possibly using native Win32 calls. I've done something similar
>>
>> for a couple projects in the past and need to find all that code. The
>>
>> only one I keep thinking of off the top of my head is swordreader's
>>
>> wince layer, which I believe is similar to win32 methods, but might need
>>
>> some adapting.
>>
>> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>>
>> The Xiphos code would be very helpful, if not just for finding
>>
>> everyplace you needed to make a modification. Thanks for any help
>>
>> finding it,
>>
>> Troy
>>
>> ___
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>
>> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

For Xiphos we use the MinGW compiler and library from Xiphos. You should be
able to grab them via Cygwin as well, if you prefer? I haven't run actual
Windows in a life age to know, though.

Greg

On Sat, Jul 18, 2020, 16:57 Tobias Klein  wrote:

> I'm using the Visual Studio compilers. All modern VS compilers are
> available via GitHub Actions! I'm most of the time letting GitHub build my
> Windows binaries, but I do have Visual Studio 2017 installed in a Windows
> 10 VM for debugging.
>
> Tobias
>
> Am 18. Juli 2020 22:53:23 schrieb "Troy A. Griffitts" <
> scr...@crosswire.org>:
>
>> OK guys, another question.
>>
>> What exactly does your build environment look like these days for win32?
>> I just tried to boot one of my old Windows VMs with
>> Borland/Inprise/Embarcadero build tools and it is in such a sad state, I am
>> not even going to attempt to recover that world right now.  I'd rather
>> support your build environments.  What are you using? cygwin? MicrosoftVS?
>> Something else?
>>
>> Troy
>>
>>
>> On 7/18/20 7:53 PM, Tobias Klein wrote:
>>
>> Thanks Greg & Troy for pointing out these potential issues. No, I have
>> not tested my code properly with non-ascii characters in paths / file names.
>>
>>
>>
>> I suppose this would particularly be an issue if the username has certain
>> characters that cause issues? (applicable for the ~/.sword directory). And
>> then also, when arbitrary folders are added to SWMgr?!
>>
>>
>>
>> I’ll do some testing in this area!
>>
>>
>>
>> I wonder whether libraries like Qt or Boost have solved these kind of
>> issues somehow …
>>
>>
>>
>> Best regards,
>> Tobias
>>
>>
>>
>> *From: *Greg Hellings 
>> *Sent: *Samstag, 18. Juli 2020 15:58
>> *To: *SWORD Developers' Collaboration Forum 
>> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass
>>
>>
>>
>> Tobias,
>>
>>
>>
>> Has this been tested with file paths that contain characters outside of
>> the basic ASCII code range? That's where current Sword fails. Not in
>> fetching the data for the paths themselves, but the actual calls to fopen
>> and friends, on Windows, do not understand non ASCII data.
>>
>>
>>
>> It looks like your code would suffer similar to other Sword code, which
>> eventually passes through the library's fopen calls.
>>
>>
>>
>> On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:
>>
>> Maybe not a full-fledged FileMgr class, but at least everything I need in
>> Ezra Project at the moment:
>>
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>>
>>
>>
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>>
>>
>>
>> It works on Windows, macOS and Linux.
>>
>>
>>
>> Best regards,
>> Tobias
>>
>>
>>
>> *From: *Troy A. Griffitts 
>> *Sent: *Samstag, 18. Juli 2020 14:42
>> *To: *SWORD Developers' Collaboration Forum 
>> *Subject: *[sword-devel] Win32 FileMgr Subclass
>>
>>
>>
>> I know Greg has sent me a link to the patch you guys apply to get Xiphos
>>
>> to run well on Win32, but I have searched through all my past emails
>>
>> with every relevant term I can thing of, and still can't find it.  I am
>>
>> sorry,  Could you possibly sent that again? I think you guys were using
>>
>> glib routines.  If possible, I'd like to include something in SWORD more
>>
>> generic, possibly using native Win32 calls.  I've done something similar
>>
>> for a couple projects in the past and need to find all that code.  The
>>
>> only one I keep thinking of off the top of my head is swordreader's
>>
>> wince layer, which I believe is similar to win32 methods, but might need
>>
>> some adapting.
>>
>>
>>
>> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>>
>>
>>
>> The Xiphos code would be very helpful, if not just for finding
>>
>> everyplace you needed to make a modification.  Thanks for any help
>>
>> finding it,
>>
>>
>>
>> Troy
>>
>>
>>
>>
>>
>> ___
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>>
>> http://w

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

I'm using the Visual Studio compilers. All modern VS compilers are 
available via GitHub Actions! I'm most of the time letting GitHub build my 
Windows binaries, but I do have Visual Studio 2017 installed in a Windows 
10 VM for debugging.


Tobias

Am 18. Juli 2020 22:53:23 schrieb "Troy A. Griffitts" :

OK guys, another question.
What exactly does your build environment look like these days for win32?  I 
just tried to boot one of my old Windows VMs with 
Borland/Inprise/Embarcadero build tools and it is in such a sad state, I am 
not even going to attempt to recover that world right now.  I'd rather 
support your build environments.  What are you using? cygwin? MicrosoftVS? 
Something else?

Troy

On 7/18/20 7:53 PM, Tobias Klein wrote:
Thanks Greg & Troy for pointing out these potential issues. No, I have not 
tested my code properly with non-ascii characters in paths / file names.


I suppose this would particularly be an issue if the username has certain 
characters that cause issues? (applicable for the ~/.sword directory). And 
then also, when arbitrary folders are added to SWMgr?!


I’ll do some testing in this area!

I wonder whether libraries like Qt or Boost have solved these kind of 
issues somehow …


Best regards,
Tobias

From: Greg Hellings
Sent: Samstag, 18. Juli 2020 15:58
To: SWORD Developers' Collaboration Forum
Subject: Re: [sword-devel] Win32 FileMgr Subclass

Tobias,

Has this been tested with file paths that contain characters outside of the 
basic ASCII code range? That's where current Sword fails. Not in fetching 
the data for the paths themselves, but the actual calls to fopen and 
friends, on Windows, do not understand non ASCII data.


It looks like your code would suffer similar to other Sword code, which 
eventually passes through the library's fopen calls.


On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:
Maybe not a full-fledged FileMgr class, but at least everything I need in 
Ezra Project at the moment:


https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp

https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp

It works on Windows, macOS and Linux.

Best regards,
Tobias
From: Troy A. Griffitts
Sent: Samstag, 18. Juli 2020 14:42
To: SWORD Developers' Collaboration Forum
Subject: [sword-devel] Win32 FileMgr Subclass

I know Greg has sent me a link to the patch you guys apply to get Xiphos
to run well on Win32, but I have searched through all my past emails
with every relevant term I can thing of, and still can't find it.  I am
sorry,  Could you possibly sent that again? I think you guys were using
glib routines.  If possible, I'd like to include something in SWORD more
generic, possibly using native Win32 calls.  I've done something similar
for a couple projects in the past and need to find all that code.  The
only one I keep thinking of off the top of my head is swordreader's
wince layer, which I believe is similar to win32 methods, but might need
some adapting.

http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/

The Xiphos code would be very helpful, if not just for finding
everyplace you needed to make a modification.  Thanks for any help
finding it,

Troy


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

OK guys, another question.

What exactly does your build environment look like these days for 
win32?  I just tried to boot one of my old Windows VMs with 
Borland/Inprise/Embarcadero build tools and it is in such a sad state, I 
am not even going to attempt to recover that world right now.  I'd 
rather support your build environments.  What are you using? cygwin? 
MicrosoftVS? Something else?


Troy


On 7/18/20 7:53 PM, Tobias Klein wrote:


Thanks Greg & Troy for pointing out these potential issues. No, I have 
not tested my code properly with non-ascii characters in paths / file 
names.


I suppose this would particularly be an issue if the username has 
certain characters that cause issues? (applicable for the ~/.sword 
directory). And then also, when arbitrary folders are added to SWMgr?!


I’ll do some testing in this area!

I wonder whether libraries like Qt or Boost have solved these kind of 
issues somehow …


Best regards,
Tobias

*From: *Greg Hellings <mailto:greg.helli...@gmail.com>
*Sent: *Samstag, 18. Juli 2020 15:58
*To: *SWORD Developers' Collaboration Forum 
<mailto:sword-devel@crosswire.org>

*Subject: *Re: [sword-devel] Win32 FileMgr Subclass

Tobias,

Has this been tested with file paths that contain characters outside 
of the basic ASCII code range? That's where current Sword fails. Not 
in fetching the data for the paths themselves, but the actual calls to 
fopen and friends, on Windows, do not understand non ASCII data.


It looks like your code would suffer similar to other Sword code, 
which eventually passes through the library's fopen calls.


On Sat, Jul 18, 2020, 08:24 Tobias Klein <mailto:cont...@tklein.info>> wrote:


Maybe not a full-fledged FileMgr class, but at least everything I
need in Ezra Project at the moment:


https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp


https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp

It works on Windows, macOS and Linux.

Best regards,
Tobias

*From: *Troy A. Griffitts <mailto:scr...@crosswire.org>
*Sent: *Samstag, 18. Juli 2020 14:42
*To: *SWORD Developers' Collaboration Forum
<mailto:sword-devel@crosswire.org>
*Subject: *[sword-devel] Win32 FileMgr Subclass

I know Greg has sent me a link to the patch you guys apply to get
Xiphos

to run well on Win32, but I have searched through all my past emails

with every relevant term I can thing of, and still can't find it. 
I am

sorry, Could you possibly sent that again? I think you guys were
using

glib routines.  If possible, I'd like to include something in
SWORD more

generic, possibly using native Win32 calls.  I've done something
similar

for a couple projects in the past and need to find all that code. 
The

only one I keep thinking of off the top of my head is swordreader's

wince layer, which I believe is similar to win32 methods, but
might need

some adapting.

http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/

The Xiphos code would be very helpful, if not just for finding

everyplace you needed to make a modification.  Thanks for any help

finding it,

Troy

___

sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>

http://www.crosswire.org/mailman/listinfo/sword-devel

Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org 
<mailto:sword-devel@crosswire.org>

http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Tom Sullivan]

If you are able to use Python, it does a good job of making file 
operations universal. For example, it converts /x/y/z.txt/n to 
x\y\z.txt\r\n for Windows.


On 7/18/20 2:34 PM, David Haslam wrote:
Paths and filenames may in theory include all manner of characters from 
non-Roman scripts.
AFAIK, Only a few special characters are not allowed in the various file 
systems.


We ought to avoid a systemic bias to the English language or even the 
Latin script when we design software.


Easy to agree in principle but not so easy to implement successfully.

Localisation of the UI is only part of the task.

I wish you every success, Tobias.

Best regards,

David


Sent from ProtonMail Mobile


On Sat, Jul 18, 2020 at 18:53, Tobias Klein <mailto:cont...@tklein.info>> wrote:


Thanks Greg & Troy for pointing out these potential issues. No, I have 
not tested my code properly with non-ascii characters in paths / file 
names.


I suppose this would particularly be an issue if the username has 
certain characters that cause issues? (applicable for the ~/.sword 
directory). And then also, when arbitrary folders are added to SWMgr?!


I’ll do some testing in this area!

I wonder whether libraries like Qt or Boost have solved these kind of 
issues somehow …


Best regards,
Tobias

*From: *Greg Hellings <mailto:greg.helli...@gmail.com>
*Sent: *Samstag, 18. Juli 2020 15:58
*To: *SWORD Developers' Collaboration Forum 
<mailto:sword-devel@crosswire.org>

*Subject: *Re: [sword-devel] Win32 FileMgr Subclass

Tobias,

Has this been tested with file paths that contain characters outside 
of the basic ASCII code range? That's where current Sword fails. Not 
in fetching the data for the paths themselves, but the actual calls to 
fopen and friends, on Windows, do not understand non ASCII data.


It looks like your code would suffer similar to other Sword code, 
which eventually passes through the library's fopen calls.


On Sat, Jul 18, 2020, 08:24 Tobias Klein <mailto:cont...@tklein.info>> wrote:


Maybe not a full-fledged FileMgr class, but at least everything I
need in Ezra Project at the moment:


https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp


https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp

It works on Windows, macOS and Linux.

Best regards,
Tobias

*From: *Troy A. Griffitts <mailto:scr...@crosswire.org>
*Sent: *Samstag, 18. Juli 2020 14:42
*To: *SWORD Developers' Collaboration Forum
    <mailto:sword-devel@crosswire.org>
*Subject: *[sword-devel] Win32 FileMgr Subclass

I know Greg has sent me a link to the patch you guys apply to get
Xiphos

to run well on Win32, but I have searched through all my past emails

with every relevant term I can thing of, and still can't find it. 
I am


sorry,  Could you possibly sent that again? I think you guys were
using

glib routines.  If possible, I'd like to include something in
SWORD more

generic, possibly using native Win32 calls.  I've done something
similar

for a couple projects in the past and need to find all that code. 
The


only one I keep thinking of off the top of my head is swordreader's

wince layer, which I believe is similar to win32 methods, but
might need

some adapting.

http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/

The Xiphos code would be very helpful, if not just for finding

everyplace you needed to make a modification.  Thanks for any help

finding it,

Troy

___

sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>

http://www.crosswire.org/mailman/listinfo/sword-devel

Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org 
<mailto:sword-devel@crosswire.org>

http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page





__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

Thanks Greg & Troy for pointing out these potential issues. No, I have not 
tested my code properly with non-ascii characters in paths / file names.

I suppose this would particularly be an issue if the username has certain 
characters that cause issues? (applicable for the ~/.sword directory). And then 
also, when arbitrary folders are added to SWMgr?!

I’ll do some testing in this area!

I wonder whether libraries like Qt or Boost have solved these kind of issues 
somehow …

Best regards,
Tobias

From: Greg Hellings
Sent: Samstag, 18. Juli 2020 15:58
To: SWORD Developers' Collaboration Forum
Subject: Re: [sword-devel] Win32 FileMgr Subclass

Tobias,

Has this been tested with file paths that contain characters outside of the 
basic ASCII code range? That's where current Sword fails. Not in fetching the 
data for the paths themselves, but the actual calls to fopen and friends, on 
Windows, do not understand non ASCII data.

It looks like your code would suffer similar to other Sword code, which 
eventually passes through the library's fopen calls.

On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:
Maybe not a full-fledged FileMgr class, but at least everything I need in Ezra 
Project at the moment:

https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
 
https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
 
It works on Windows, macOS and Linux.
 
Best regards,
Tobias
 
From: Troy A. Griffitts
Sent: Samstag, 18. Juli 2020 14:42
To: SWORD Developers' Collaboration Forum
Subject: [sword-devel] Win32 FileMgr Subclass
 
I know Greg has sent me a link to the patch you guys apply to get Xiphos 
to run well on Win32, but I have searched through all my past emails 
with every relevant term I can thing of, and still can't find it.  I am 
sorry,  Could you possibly sent that again? I think you guys were using 
glib routines.  If possible, I'd like to include something in SWORD more 
generic, possibly using native Win32 calls.  I've done something similar 
for a couple projects in the past and need to find all that code.  The 
only one I keep thinking of off the top of my head is swordreader's 
wince layer, which I believe is similar to win32 methods, but might need 
some adapting.
 
http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
 
The Xiphos code would be very helpful, if not just for finding 
everyplace you needed to make a modification.  Thanks for any help 
finding it,
 
Troy
 
 
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
 
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

Tobias,

Has this been tested with file paths that contain characters outside of the
basic ASCII code range? That's where current Sword fails. Not in fetching
the data for the paths themselves, but the actual calls to fopen and
friends, on Windows, do not understand non ASCII data.

It looks like your code would suffer similar to other Sword code, which
eventually passes through the library's fopen calls.

On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:

> Maybe not a full-fledged FileMgr class, but at least everything I need in
> Ezra Project at the moment:
>
>
> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>
>
>
>
> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>
>
>
> It works on Windows, macOS and Linux.
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Troy A. Griffitts 
> *Sent: *Samstag, 18. Juli 2020 14:42
> *To: *SWORD Developers' Collaboration Forum 
> *Subject: *[sword-devel] Win32 FileMgr Subclass
>
>
>
> I know Greg has sent me a link to the patch you guys apply to get Xiphos
>
> to run well on Win32, but I have searched through all my past emails
>
> with every relevant term I can thing of, and still can't find it.  I am
>
> sorry,  Could you possibly sent that again? I think you guys were using
>
> glib routines.  If possible, I'd like to include something in SWORD more
>
> generic, possibly using native Win32 calls.  I've done something similar
>
> for a couple projects in the past and need to find all that code.  The
>
> only one I keep thinking of off the top of my head is swordreader's
>
> wince layer, which I believe is similar to win32 methods, but might need
>
> some adapting.
>
>
>
> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>
>
>
> The Xiphos code would be very helpful, if not just for finding
>
> everyplace you needed to make a modification.  Thanks for any help
>
> finding it,
>
>
>
> Troy
>
>
>
>
>
> ___
>
> sword-devel mailing list: sword-devel@crosswire.org
>
> http://www.crosswire.org/mailman/listinfo/sword-devel
>
> Instructions to unsubscribe/change your settings at above page
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

Thanks Tobias,

Looking at your code, I suspect you might be running into the same issues that 
SWORD runs into with those similar functions in FileMgr. Different compilers 
seem to supply different compatibility for full Unicode supposed for standard C 
functions, for example, getenv. The string input seems often to be the problem. 
SWORD generally supports UTF-8 everywhere, but Windows seems to support a 
variety of character encodings for different method calls and often never 
UTF-8. So strings need to be converted to UTF-16 to call native Win32 methods 
which support broader Unicode, or else the standard libs provided with your 
compiler need to do something smart with C function calls. On Linux these 
smarts are usually set with a locale env variable causing the standard lib 
calls to change behavior accordingly.

Bottom line, I would test putting your modules on a path with Greek letters and 
maybe also a space in a folder name somewhere. And see if, when you provide 
that path with SWORD_PATH, that the engine can open your modules.

Troy

On July 18, 2020 3:23:48 PM GMT+02:00, Tobias Klein  wrote:
>Maybe not a full-fledged FileMgr class, but at least everything I need
>in Ezra Project at the moment:
>
>https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>
>https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>
>It works on Windows, macOS and Linux.
>
>Best regards,
>Tobias
>
>From: Troy A. Griffitts
>Sent: Samstag, 18. Juli 2020 14:42
>To: SWORD Developers' Collaboration Forum
>Subject: [sword-devel] Win32 FileMgr Subclass
>
>I know Greg has sent me a link to the patch you guys apply to get
>Xiphos 
>to run well on Win32, but I have searched through all my past emails 
>with every relevant term I can thing of, and still can't find it.  I am
>
>sorry,  Could you possibly sent that again? I think you guys were using
>
>glib routines.  If possible, I'd like to include something in SWORD
>more 
>generic, possibly using native Win32 calls.  I've done something
>similar 
>for a couple projects in the past and need to find all that code.  The 
>only one I keep thinking of off the top of my head is swordreader's 
>wince layer, which I believe is similar to win32 methods, but might
>need 
>some adapting.
>
>http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>
>The Xiphos code would be very helpful, if not just for finding 
>everyplace you needed to make a modification.  Thanks for any help 
>finding it,
>
>Troy
>
>
>___
>sword-devel mailing list: sword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Tobias Klein]

Maybe not a full-fledged FileMgr class, but at least everything I need in Ezra 
Project at the moment:

https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp

https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp

It works on Windows, macOS and Linux.

Best regards,
Tobias

From: Troy A. Griffitts
Sent: Samstag, 18. Juli 2020 14:42
To: SWORD Developers' Collaboration Forum
Subject: [sword-devel] Win32 FileMgr Subclass

I know Greg has sent me a link to the patch you guys apply to get Xiphos 
to run well on Win32, but I have searched through all my past emails 
with every relevant term I can thing of, and still can't find it.  I am 
sorry,  Could you possibly sent that again? I think you guys were using 
glib routines.  If possible, I'd like to include something in SWORD more 
generic, possibly using native Win32 calls.  I've done something similar 
for a couple projects in the past and need to find all that code.  The 
only one I keep thinking of off the top of my head is swordreader's 
wince layer, which I believe is similar to win32 methods, but might need 
some adapting.

http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/

The Xiphos code would be very helpful, if not just for finding 
everyplace you needed to make a modification.  Thanks for any help 
finding it,

Troy


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Sat, Jul 18, 2020, 07:42 Troy A. Griffitts  wrote:

> I know Greg has sent me a link to the patch you guys apply to get Xiphos
> to run well on Win32, but I have searched through all my past emails
> with every relevant term I can thing of, and still can't find it.  I am
> sorry,  Could you possibly sent that again? I think you guys were using
> glib routines.  If possible, I'd like to include something in SWORD more
> generic, possibly using native Win32 calls.  I've done something similar
> for a couple projects in the past and need to find all that code.  The
> only one I keep thinking of off the top of my head is swordreader's
> wince layer, which I believe is similar to win32 methods, but might need
> some adapting.
>

Here is the existing patch which applies pretty cleanly on 1.8.1.
https://src.fedoraproject.org/rpms/mingw-sword/blob/master/f/xiphos_sword.patch

I attempted, once, to wrap the Sword calls the way you propose, but at the
time my knowledge of UTF-16 and file pointers was woefully inadequate to
get it right. The Windows native file calls only speak UTF-16, while their
standard "open" methods only speak CP-1252.

Thanks for tackling this!

--Greg


> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>
> The Xiphos code would be very helpful, if not just for finding
> everyplace you needed to make a modification.  Thanks for any help
> finding it,
>
> Troy
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Win32 FileMgr Subclass

[Troy A. Griffitts]

I know Greg has sent me a link to the patch you guys apply to get Xiphos 
to run well on Win32, but I have searched through all my past emails 
with every relevant term I can thing of, and still can't find it.  I am 
sorry,  Could you possibly sent that again? I think you guys were using 
glib routines.  If possible, I'd like to include something in SWORD more 
generic, possibly using native Win32 calls.  I've done something similar 
for a couple projects in the past and need to find all that code.  The 
only one I keep thinking of off the top of my head is swordreader's 
wince layer, which I believe is similar to win32 methods, but might need 
some adapting.


http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/

The Xiphos code would be very helpful, if not just for finding 
everyplace you needed to make a modification.  Thanks for any help 
finding it,


Troy


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page