Re: Glib: a Win32 discussion

[Colin Walters <walters verbum org>]

I've never used GLib on windows really myself, just commenting from
the perspective of GNOME:

On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston <kean johnston gmail com> wrote:
>
> By avoiding the CRT altogether and using native Windows functions that use
> handles, and using a memory allocator other than malloc, all of these
> problems go away.

This sounds reasonable.

> Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc. There
> are other bits that are more problematic. The next easiest to solve is
> stat(). Gio already makes a token gesture at wrapping stat() but its
> wrapping is a bit TOO thin.

On the subject of this, along with "gstdio"; we should be pushing
people towards Gio's very extensive and nice I/O API rather than
reinventing it in GLib.

So for the limitations and weirdness of the random I/O wrappers in
GLib on different platforms - document and move on.
> Wrapping stat can also fix the problem of having the
> uid_t / gid_t types differ not only from system to system, but also change
> on the SAME system depending on defines. We can force these to always be
> 32-bit. Similarly, ino_t.

If your application deals with uids, I think you're going to end up
with platform-specific code; the complexities around identity are just
too high.  That goes doubly for inode numbers, which - why would you
care unless you're a backup app, and then you're *definitely* going to
get into platform specific stuff.

> Last, but by no means least, is the reliance on "compiled" files, like
> compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where
> things are installed in a universally-accessible location, this isn't a
> problem, but on Win32, where multiple applications could all include their
> own private copies of the DLL's, this is a problem. Fixing this is a bit
> tricky but very doable. Windows does provide two places that are predictable
> and universally accessible: the registry, and %ProgramData%.

So you're suggesting making them private to the app?  It's not clear
to me because I don't know the semantics of %ProgramData%.

I think it would be a good goal to make deploying these things per-app
work more easily.

> One last thing, since it has proven to be a source of considerable
> incompatibility, and that's the reliance on D-Bus. I think it should remain
> possible to use dbus if you want it, if your application really needs it,
> but to have relatively (from my position of ignorance) unrelated things like
> gapplication absolutely rely on it is a mistake, as far as I can see.

I only intended DBus to be used on GNOME; yes, GApplication needs a
Windows backend.