Non-ANSI filename support for Windows + GZ, ZIP and JMA

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
byuu

Non-ANSI filename support for Windows + GZ, ZIP and JMA

Post by byuu »

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.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Re: Non-ANSI filename support for Windows + GZ, ZIP and JMA

Post by Nach »

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
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

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
Locked