View unanswered posts | View active topics It is currently Fri Dec 06, 2019 11:58 pm



This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Non-ANSI filename support for Windows + GZ, ZIP and JMA 
Author Message
Reply with quote
Post Non-ANSI filename support for Windows + GZ, ZIP and JMA
Okay, so I support non-ANSI for everything else. But support for the compressed archives on Windows involves re-writing the fopen() calls to pass UTF-16 names to _wfopen().

All of these changes would be encapsulated with #ifdef _WIN32, and the old code left as-is for other platforms.

For zlib, this looks easy enough.

GZ:
Edit gzio.c, line 181. Replace F_OPEN(), which is a simple #define wrapper for fopen(), with _wfopen().

ZIP:
Edit ioapi.c, line 85, update direct call to fopen().

JMA:
Edit jma.cpp, line 176, convert stream.open() call to take FILE* handle from _wfopen().

zlib license should allow these changes. JMA, being GPLv2, technically allows it, but Nach only gave me direct permission to use what he sent me, as my license is not GPL-compatible.

Nach, would you mind if I make the above small change to jma.cpp? You can use those changes as PD, if you like; though I imagine you'll have a more eloquent way to handle this yourself. My idea is to just make all libraries take UTF-8, and convert as-needed inside the libraries.

Also, I doubt these changes will allow Unicode filenames inside the archive to be loaded ... not even sure if the containers themselves support Unicode file names, but I guess we'll see. Nothing much I can do about that, if it's a file format limitation. Nach's JMA seems to be the most likely to support Unicode, as most / all of his apps do already.


Wed Sep 24, 2008 7:39 pm
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post Re: Non-ANSI filename support for Windows + GZ, ZIP and JMA
byuu wrote:
Okay, so I support non-ANSI for everything else. But support for the compressed archives on Windows involves re-writing the fopen() calls to pass UTF-16 names to _wfopen().

All of these changes would be encapsulated with #ifdef _WIN32, and the old code left as-is for other platforms.

For zlib, this looks easy enough.

GZ:
Edit gzio.c, line 181. Replace F_OPEN(), which is a simple #define wrapper for fopen(), with _wfopen().

ZIP:
Edit ioapi.c, line 85, update direct call to fopen().

You can achieve UTF-16 support without modifying zlib for gzip and possibly for zip too.
Instead of using gzOpen(), use _wopen(), and pass the return value to gzdOpen().

The zip library may have something similar.

byuu wrote:
JMA:
Edit jma.cpp, line 176, convert stream.open() call to take FILE* handle from _wfopen().

That would depend on which C++ library is being used. Not all of them allow opening a FILE * into an fstream.

byuu wrote:
Nach, would you mind if I make the above small change to jma.cpp? You can use those changes as PD, if you like; though I imagine you'll have a more eloquent way to handle this yourself. My idea is to just make all libraries take UTF-8, and convert as-needed inside the libraries.

If you send me changes which work with both MSVC and MinGW, and I'll clean it up and give you back source you can use.

byuu wrote:
Also, I doubt these changes will allow Unicode filenames inside the archive to be loaded ... not even sure if the containers themselves support Unicode file names, but I guess we'll see. Nothing much I can do about that, if it's a file format limitation. Nach's JMA seems to be the most likely to support Unicode, as most / all of his apps do already.

I support UTF-8 names inside JMA.

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding


Thu Sep 25, 2008 3:43 am
Profile WWW
Hazed

Joined: Tue Dec 07, 2004 10:24 am
Posts: 68
Reply with quote
Post 
Hi! Does zlib require any changes to support non-ansi file names on Linux? I'm asking because the stalled review of bsnes for RPM Fusion (add-on package repository for Fedora) seems to have resumed.
As you remember, the package policy requires using external libs (don't ask me why ;) )and you gave me the permission to patch bsnes to do that, but I would not like to cripple the functionality.
Also, someone has offered to look for a possibility of using external snes_ntsc (of course for the purpose of packaging only, I know you are unwilling to merge such patches). I hope that once that gets solved we will finally see bsnes in RPM Fusion :)
For reference, the review request is here, feel free to add comments if you wish:
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15


Sun Nov 23, 2008 4:32 pm
Profile
Display posts from previous:  Sort by  
This topic is locked, you cannot edit posts or make further replies.   [ 3 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.