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.johns...@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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list