[sword-devel] Windows Unicode

[Troy A. Griffitts]

Greg and Karl,

Thank you for maintaining this patch.  I remember these issues from long
ago.  We also have a non-glib solution for the ancient Windows Mobile
which I think we can lift, along with your provided patch to show us
every place which needs adjusting, to build a solution for Windows. 
Reviewing your patch, I am a bit surprised how many places in the code
tree this touches.  The goal of FileMgr was originally to isolation all
file IO operations to one place for to help us port easier, exactly for
this purpose.  I will try to migrate all the points your patch touches
to inside FileMgr (even the getenv call, which isn't directly File IO
related, but I would rather keep all this isolated to one place even if
it means having a slight deviant to the primary purpose for FileMgr
living within.  I'll work on it and let you know what I come up with.

For reference, here is the Windows Mobile calls, which I think are
probably almost directly portable for the Windows overrides we'll have
in FileMgr:

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


On 1/6/20 7:31 PM, Greg Hellings wrote:
> A long, long time ago I took over building a MinGW Sword package build
> for Fedora in order to enable cross-compiling Xiphos for Windows machines.
>
> In so doing I also adopted a patch against Sword that Xiphos keeps in
> its tree. This is due to a bug (feature? Let's just go with
> "limitation") in the C APIs on Windows. The bug, if memory serves, is
> that calling basic file functions in C (fopen, etc) only supports
> arguments in cp1252/ASCII. So any users who have usernames with
> non-CP1252 characters are left unable to run Sword without custom
> pointing to a SWORD_HOME that is outside of their user directory. The
> solution is to use Windows API calls and pass in data in UTF-16, or
> whatever encoding is in vogue on Windows these days.
>
> Xiphos' solution was to just substitute out calls to the file
> functions with calls to the glib wrapped file functions. Glib is
> mature enough to have worked around this Windows quirk and can take
> the UTF-8/16 data and call the appropriate methods in the Windows API
> that are required for such paths (Linux handles non-ASCII characters
> in the path with fopen and its siblings without any hiccups. It's not
> a compiler bug, either - it lives somewhere deep inside of the system
> library in Windows itself). This solution works great for Xiphos,
> which already depends on Glib as part of the GTK stack but it results
> in my Windows editions of the utils being inflated by also carrying
> the full Glib/pango/etc stack just to work around this one small (but
> major) issue.
>
> The patch against 1.8.1 released code lives here:
> https://src.fedoraproject.org/rpms/mingw-sword/blob/master/f/xiphos_sword.patch
>
> Is there any chance we can get a mainline Sword solution to this bug
> so that Bible Time, The SWORD Project for Windows, and any others are
> not impacted by this going forward? With the talk about 1.9 going on,
> I figured this would be a good time to poke this bear. Also, it might
> be that Windows fixed this in Windows 10, but it was still in Windows
> 8.1 the last time I checked, and it dates back to the early days of
> Win32 APIs, so I doubt that.
>
> --Greg
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20200120/9a8daa69/attachment.html>