Hi,
The question was about the file handling wrappers, from the answer I gather that we could go for GTK+ 2.6
on Windows without any probles (with those at least), I supose we could use g_fopen and the like if we want
by wrapping them in ifdefs.
Best regards
Anders
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Guy Harris
Sent: den 6 juli 2005 06:11
To: Ethereal development
Subject: Re: [Ethereal-dev] GTK 2.6 on Windows
Anders Broman (AL/EAB) wrote:
> Is the following comment an issue?
>
> "For software developers I would suggest that unless you need to use
> 2.6-only features, you continue to build against GLib and GTK+ 2.4
> headers and libraries, even if the run-time environment will be 2.6.
> Only if you use 2.6-only API build against 2.6, and in that case,
> remember to use the gstdio wrappers: replace all fopen() calls with
> g_fopen(), etc."
Which part of the comment are you concerned about?
The first part is probably just "build against 2.4 so that your binary
will work with 2.4 and 2.6".
The second part is "if you need 2.6 features, build against 2.6" (a
no-brainer) followed by the note about the wrappers.
The wrappers appear to exist to allow an application to handle non-ASCII
file names on Windows as well as on UN*X systems set up to use UTF-8 for
file names (although, unless they've fixed Pango, that's only UN*Xes
that use UTF-8 with *precomposed* characters, not those that use
*decomposed* characters, so it would have problems on OS X):
http://developer.gnome.org/doc/API/2.0/glib/glib-File-Utilities.html
"There is a group of functions which wrap the common POSIX functions
dealing with filenames (g_open(), g_rename(), g_mkdir(), g_stat(),
g_unlink(), g_remove(), g_fopen(), g_freopen()). The point of these
wrappers is to make it possible to handle file names with any Unicode
characters in them on Windows without having to use ifdefs and the wide
character API in the application code.
The pathname argument should be in the GLib file name encoding. On POSIX
this is the actual on-disk encoding which might correspond to the locale
settings of the process (or the G_FILENAME_ENCODING environment
variable), or not.
On Windows the GLib file name encoding is UTF-8. Note that the Microsoft
C library does not use UTF-8, but has separate APIs for current system
code page and wide characters (UTF-16). The GLib wrappers call the wide
character API if present (on modern Windows systems), otherwise convert
to/from the system code page.
Another group of functions allows to open and read directories in the
GLib file name encoding. These are g_dir_open(), g_dir_read_name(),
g_dir_rewind(), g_dir_close()."
In theory, they'd be nice routines to use, as they'd make Ethereal
handle non-ASCII file names better, but, unfortunately, they require
GTK+ 2.6.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
