> almost every function that expects
> a file path seems to have been renamed in GTK+'s Win32 backend.
Umm, are you referring to the functions that have been #defned in some
headers to actually have an _utf8 appended? That is an implementation
detail to handle some old backward compatibility isses that you should
not care about.
Use just the "normal" name of the function without any _utf8 suffix in
your own code, pass just UTF-8 file names to GLib and GTK+ functions,
and expect them to return UTF-8 file names, and don't worry.
(The long story is that way back in time, GLib and GTK+ on Windows
wanted file names to be in the "system codepage", but a policy
decision was then made to just use UTF-8 everywhere instead. To avoid
breaking existing binaries which expected the old behaviour, existing
entry points kept the old behaviour, and instead new functions with
_utf8 appended, and the #defines, were added so that freshly built
code would use the UTF-8 API. New API that has been introduced since
don't have any backward compatibility versions, they always use UTF-8
on Windows, and don't need any such #defines.)
> This got me
> wondering whether (if I changed to MinGW) I'd also need to rewrite programs
> to use DOS-style paths - e.g. (case insensitive) "C:\\Documents and
> Settings\\john\\some_file") as opposed to the Unix-style paths that Cygwin
> favours - e.g. (case sensitive) "/home/john/some_file".
You are now confusing three mostly unrelated things: 1) the UTF-8 vs.
system codepage issue already explained above, 2) backslashes vs.
forward slashes, and 3) pathnames as visible in some Unix emulation
environment like Cygwin. Also, please don't use "DOS", just say
If you write code that will run on Windows (and not Cygwin, which
really is a different operating system, even if it happens to run on
top of Windows), then yes, you can obviously not use pathnames that
are implemented by Cygwin, like /home. (Sure, you can have a top-level
folder on your current drive in Windows called \home (or equivalently,
/home), but let's assume that is not the case now.)
As for the UTF-8 vs. system codepage issue, just be aware that
pathnames (and all other strings, to be displayed in the GUI etc) you
pass to GLib and GTK+, and that are returned from them, should be in
This matters for non-ASCII characters only, of course. This is
different from the C runtime, where functions like fopen() expect file
names in system codepage, and thus can't access all possible file
names. (Like file names containing Greek characters on an English
Windows machine. Being able to handle any possible file name *is* an
important point in GLib and GTK+.) In the C runtime (and the Win32
API), one needs to use the so-called wide character versions of the
API to handle any possible file name. Those use UTF-16.
Note that this issue has no direct equivalence on Unix, where file
names are always just strings of bytes. Any interpretation as UTF-8 or
ISO8859-1 or whatever is totally up to user code. Compare to Windows,
where the actual file names as stored in the file system are in
If you read documentation for C or C++ programming in old-fashioned
Microsoft style, you might see talk about TEXT and TCHAR and tstrcpy()
etc, and building in "Unicode mode" or "ANSI mode". Most of that is
historical garbage that you really need not know these days especially
if you use GTK+. Win9x is dead, there is no reason to bother with
"non-Unicode" "modes". If using GTK+, you must use UTF-8. And when
using the Win32 API, ideally just use the "W" versions of the API and
wide character strings explicitly . Ditto when using the Microsoft C
library, use the wide character versions of file-related functions
explicitly. (But in a GTK+ program you should instead just use the
wrappers from <gstdio.h> that take UTF-8.)
> I wrote a small app that does very little, apart from including these lines
> that worked previously when I was using the x11 backend:-
> gdk_pixbuf_new_from_file("/usr/local/share/icons/fader_belt.png", &error);
> With the Unix-style path, this function fails with error:- 0xea1a90 whereas
> if I change to a DOS-style path, it fails with error - 0xea1a50 (the file
> does exists, BTW).
What exactly was the "DOS-style" path you passed to the function?
Hopefully not something like
"C:\\usr\\local\\share\\icons\\fader_belt.png" unless you really have
a "usr" folder at the top level of you current drive? You should pass
a path that is valid in Windows. Whether you use backslashes or
(forward) slashes is mostly irrelevant.
What are those strange error codes? Pointer values! ;)
> where can I find a list of GErrors
A GError is a struct:
the message field should contain a plain text error message. The
domain and code fields are "codes", but there can't be any exhaustive
list of them as any software that returns error information in the
form of GError can use whatever codes they like. You will have to
refer to the documentation for the API you are calling to see if it
specifies the possible values for domain and code.
> Can anyone tell me which style of path they'd be using if they were building
> with MinGW?
There is no choice. Use paths that are valid Windows paths. In UTF-8.
Whether you use backslashes or (forward) slashes is mostly a matter of
taste. You can even use both in the same file name, like:
which might happen especially if you construct the file name at run-time.
More important than worrying about whether to use backslashes or
slashes is to realize that if you write software that you intend to
distribute to others, you can not hard-code locations in the file
system in your code. Except in very restricted environments, you can't
know where some end-user is going to install your software. So if your
code wants to open some file that is part of its installation at
run-time, you can't hard-code the pathname to that file. You should
determine at run-time where the software has been installed (typically
based on the location of an .exe or .dll file of your software), and
then construct the pathname to the file to be opened based on that.
The GetModuleFileName function helps here.