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: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
