Re: gio on win32 (was Re: Announce: gio merged)
On 04.12.2007 09:30, Alexander Larsson wrote: On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote: [...] 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. 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? Still need to check the root dir case, but it should work given something like c:\, the c: has the special meaning of the current directory on the give drive which probably won't work with the API used. 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) : The list of unresolved is now empty meaning gio compiles an links with msvc6. 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. I've just commited the following: 2007-12-08 Hans Breuer [EMAIL PROTECTED] [gio compiles and links on win32, not sure how much already works] * glocaldirectorymonitor.c : ifdefed out inotify emulation for win32 * glocalfile.c : use HAVE_UNISTD_H; implement file system size info base on win32 API; prefer g_lstat() over lstat(); instead of localtime_r() use an all GLib implementation on win32; get_mount_info() still needs a win32 specifc implementation * glocalfileinfo.c : use HAVE_*_H; start of implementation of win32_get_file_user_info to get owner/group info without uid/gid * glocalfileinputstream.c : include io.h on win32 * glocalfileoutputstream.c : include io.h on win32 and some S_IS* definition, use g_win32_ftruncate() for G_OS_WIN32 * gwin32appinfo.c : optionalize a bunch on #ifdef AssocQueryString it is available with mingw/w32api but a mess with the M$ Platform SDKs see: http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00014.html * makefile.msc : updated [...] 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. Still need to take a closer look. Just #ifdefed for the moment. Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio on win32 (was Re: Announce: gio merged)
On Wed, 2007-12-05 at 22:13 +0100, Hans Breuer wrote: On 05.12.2007 12:19, Alexander Larsson wrote: On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote: On 03.12.2007 10:07, Alexander Larsson 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? I changed this so that _g_io_modules_ensure_loaded is a private function that only glib uses for its libs. It takes no arguments and could use whatever magic require on win32 to find the module directory. Instead I exported g_io_modules_load_all_in_directory, which is used in the implementation of _g_io_modules_ensure_loaded. It can be used in other libraries (such as in gvfs) to implement a similar thing. Is this ok for you? Looks good. So I guess someone needs to write the first gio-module working on windoze - maybe around FindFirstChangeNotification() ;) I don't think that needs to be a module actually. I've made the fam file monitor a module, so that gio doesn't link to libfam. However, the inotify monitor is built in, as that has no extra dependencies. (Loading modules is not free, as it causes an extra private dirty page.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio on win32 (was Re: Announce: gio merged)
On 05.12.2007 12:19, Alexander Larsson wrote: On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote: On 03.12.2007 10:07, Alexander Larsson 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? I changed this so that _g_io_modules_ensure_loaded is a private function that only glib uses for its libs. It takes no arguments and could use whatever magic require on win32 to find the module directory. Instead I exported g_io_modules_load_all_in_directory, which is used in the implementation of _g_io_modules_ensure_loaded. It can be used in other libraries (such as in gvfs) to implement a similar thing. Is this ok for you? Looks good. So I guess someone needs to write the first gio-module working on windoze - maybe around FindFirstChangeNotification() ;) Thank you, Hans Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio on win32 (was Re: Announce: gio merged)
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
gio on win32 (was Re: Announce: gio merged)
On 03.12.2007 10:07, Alexander Larsson wrote: On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: [...] 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. 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? 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. 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? 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. 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
