Re: gio on win32 (was Re: Announce: gio merged)

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:

> > 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.
> > 
> The thing needed than would be the DLL name or the HANDLE of the DLL to
> resolve the relative path against. I'm not sure though how the
> responsibilities need to be split for loading some gio-modules.
> Is an application supposed to deliver it's own extension modules for gio?

There are two things here. Modules loaded by libgio, which are installed
(atm) in $libdir/gio/modules (or as specified by --with-gio-module-dir).
These are used for things that extend libgio. For instance, gvfs
installs its GVfs implementation there so that gio suddenly supports
uris. We also install e.g. the fam implementation of file monitoring and
the HAL based volume monitor there. 

Secondly GIOModule is an easy way for apps to load modules, which e.g.
gvfs uses to load its modules. You just point it to a directory and it
loads the modules there. 

I'm thinking maybe the second use case isn't that important. We can make
the first case work pretty nice on win32 if the GIOModule loading API is
internal, right? Then for the second case gvfs could just duplicate this
small piece of code.

Opinions?

> >>>> 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've started something of this, but not commited yet. (I'm getting too old
> for all these ifdefs ;)) See attahed patch.

Looks good to me.

> > 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". 
> > 
> This sounds like the application again must be unix/win32 specific. Or who
> is supposed to interpret the unix:uid key? Could some of this be abstracted
> away?

Some keys are unix specific, some are specific to other types of
storage. This isn't a "glib is build on unix" type of thing either. Some
filesystems store a unix uid, some don't. For instance, on a unix
machine you don't get a unix:uid when you get file info for a file on a
smb share. You might get a dos:is_archive though, as smb can hand you
that.

There are also common keys, including some that are more abstracted. For
instance, "owner:user" gets you the username of the user owning the file
and "owner:user_real" the full name. These are calculated from the uid
on unix backends, but can be calculated in other ways on other backends.
Similarily things like "access:can_read" is an abstraction of the
results of the permissions, which can be unix permissions or some other
form.

However, you can't really abstract away e.g. the unix permissions
totally. If you want to modify the permissions you can't work on the
abstracted fields, but must handle the specific details of the storage
format.

> > 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.
> > 
> Again I alread started a win32 specific implementation, not commited yet
> but attached for review.

Looks good. Does it also work for the root dir, or does
g_path_get_dirname() fail in that case?

> > 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.
> > 
> At the moment I'm concentrating on getting gio to work at all. At some
> points there still is working implmentation missing. My current unresolved
> externals (i.e. some of the stuff that compiles still requires functions
> not compiled) :
> 
> glocalfile.obj : error LNK2001: unresolved external symbol _g_unix_mount_free
> glocalfile.obj : error LNK2001: unresolved external symbol
> _g_unix_mount_is_readonly
> glocalfile.obj : error LNK2001: unresolved external symbol _g_get_unix_mount_at
> glocalfile.obj : error LNK2001: unresolved external symbol
> _g_unix_mounts_changed_since
> glocalfile.obj : error LNK2001: unresolved external symbol _localtime_r
> glocalfile.obj : error LNK2001: unresolved external symbol
> __g_local_directory_monitor_new
> glocalfileinfo.obj : error LNK2001: unresolved external symbol
> _get_groupname_from_gid
> glocalfileinfo.obj : error LNK2001: unresolved external symbol
> _get_realname_from_uid
> glocalfileinfo.obj : error LNK2001: unresolved external symbol
> _get_username_from_uid

All this should be possible to just ifdef out.
The unix mount stuff is just to set the G_FILE_ATTRIBUTE_FS_READONLY
attribute, which is not that important and done completely different on
windows.

The localtime_r stuff is part of the implementation of the
freedesktop.org trash spec in g_local_file_trash(). We should have a
completely different implementation on windows. Just stub it for now.

the _get_username_from_uid etc calls are just to implement owner:user
etc. This makes no sense on windows, as the statbuf.st_uid field is some
generated thing that is not really useful anyway. Long term it would be
nice to get ownership info from e.g. NTFS and put that in, but for now,
just stub it out.

> >> 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.
> > 
> AssocQueryStringW is not available with the original SDK delivered with
> msvc6. With more recent SDKs it seems to be part of some "Internet Explorer
> SDK". I'll try to look into replacing with some less critical API.

Oh, I wasn't aware of that. I think all these calls do is sniff around
in the registry anyway, so one can probably implement it using raw
registry calls.