Re: Announce: gio merged

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: 
> >>
> >> 	* gio/gcontenttype.c : use GDir instead of using <dirent.h>
> > 
> > Hmm? Why is that building on Win32? It should be picking the #ifdef
> > G_OS_WIN32 part of that file.
> > 
> You are right. I was just fooled by the unconditional #include <dirent.h>
> and mechanically translating to GDir (without testing if it compiles).
> But - given that there are two completely independent implementations in
> this file - wouldn't it be better to split it into gcontenttype-win32.c and
> gcontenttype-unix.c ?

Probably. I'm not sure why they ended up in the same file while e.g. the
appinfo stuff got split. Just happened I guess.

> >> gsocketinputstream.c gsocketoutputstream.c
> >> needs some reimplementation/porting to use winsock specific API.
> > 
> > This has been made Unix only. We'll probably need a winsock version of
> > this later though.
> > 
> >> g_io_modules_ensure_loaded (GIO_MODULE_DIR);
> >> It would be nice if this function would take no parameter to allow
> >> implementation of dynamic DLL placement resolvement in one place.
> > 
> > Hmm. This is also used by gvfs to load its modules. It then passes a
> > different location to the function ($(libdir)/gvfs/modules). Can you
> > describe in more detail what you want it to do?
> >
> On windows the location of DLLs is deduce at runtime. It depends on where a
> setup installed the DLLs, rather than fixed at compiled time.
> Thus we have established a pattern to resolve module placement from the DLL
> loading them. See for example gtk/gtkmodules.c.
> My first idea was taht the parameter to g_io_modules_ensure_loaded() was
> always the same. Thus it would have been possible to do the dynamic path
> calcualtion in just this one function. Of course GIO_MODULE_DIR can be
> defined to a function call on win32, to keep the other code like it is.
> _gio_win32_module_dir() will have to return a static string than.

Thats a way it can be made to work with the current use in libgio, but
it makes the API sort of weird for win32. How exactly is the dynamic
path calculated? Maybe its possible to make the API work in some
relative way? That way some other library on could also use
g_io_modules_ensure_loaded() to load its modules relative to its dll.

> >> glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test
> > 
> > g_file_test is pretty lame though. It does a new stat each time you call it and there are no ways to get more than a single piece of info for each call. This will just slaughter i/o performance. 
> > 
> > What exactly is it that you need it to do that g_file_test does? We need to move that into glocalfile.c instead.
> > 
> The first thing is the undefined statfs_buffer for !USE_STATFS and
> !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand
> the unknown API first to propose how to port it.
> On a quick glance the missing definition for S_ISDIR led me to propose
> g_file_test(). But of course this can be resolved differntly.

Maybe we should have a full alternative implementation of
g_local_file_query_info() using GetFileAttributes and similar calls. 

I think we can make the posix version mostly work for win32, but a
native implementation can get more information, like fat attributes
(hidden, archive, system) and NT ACLs.

I think the interesting parts for a native win32 implementation is (for
local files, i.e. in glocalfile.c):

g_file_query_info() - This returns information about a file, like size,
type, icon, last changed, etc. The return type is a GFileInfo which is a
key-value container where the keys are namespaced strings like
"std:type" or "unix:uid". 

g_file_query_filesystem_info() - Similar to the above, but gets
information about the filesystem the file is on. i.e. total diskspace,
diskspace left, type of filesystem.

g_file_enumerate_children() - This is readdir() + stat of each file
combined into one. I think Win32 has a better fit to this, where
FindNextFile actually returns stat info. On posix you need to make a
separate stat call for each filename readdir() returns. So, a native
win32 implementation of GFileEnumerator would be more efficient.

None of this is strictly necessary of course, so it all depends on how
much time the win32 developers want to spend on it.

> >> Finally gio.symbols should be added to make exporting of symbols (and what
> >> not;) as easy as for glib/gobject and gtk+
> > 
> > It also needs to set up the aliases work for unix... I'll take a look at it.
> > 
> >> Do you want me to commit the uncritical pieces?
> > 
> > Everything but the gcontenttype.c part (that should not build on win32)
> > looks good to me.
> > 
> Ok, revert that thing and just moved the #include <dirent.h> stuff into the
> !G_OS_WIN32 #else.

Did you commit your stuff? 

> In the first chunck I was also completely missing the gwin32appinfo.c
> thing. Now it is giving me a hard time by using somewhat unusual API - not
> available in my current Platform SDK installation. There are people
> claiming shlwapi.h to be "one of the worst designed libraries to come out
> of the Windows team"
> [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=203814&SiteID=1]
> So at least now I know why it was not installed on my computer :-)

Hmm. When I wrote the stuff I was just using MinGW. It had most of this
stuff, but lacked some and actually had some values wrong. Thats why
there are defines like ASSOCF_INIT_BYEXENAME and REAL_ASSOCSTR_COMMAND
at the top of the file.