[Libguestfs] Patch to build hivex lib on Windows

[Richard W.M. Jones]

On Tue, Sep 06, 2011 at 07:19:32PM +0200, Gillen Daniel wrote:
> On 09/06/2011 02:51 PM, Richard W.M. Jones wrote:
> >On Sat, Sep 03, 2011 at 10:46:30PM +0200, Gillen Daniel wrote:
> >>mmap is exactly the problem. I didn't find it in gnulib or somewhere else.
> >>
> >>I did some more research on how it could be done and I came up with
> >>the following. Definitely less invasive :) and full_read and
> >>full_write can be used again.
> >>
> >>What do you think about that one?
> >
> >The way to do this [mmap] patch less invasively is to use an autoconf
> >replacement function.  (Well actually a better way would be to add the
> >needed features to gnulib, but I'll assume that you don't want to do
> >that).
> >
> >It's all documented here:
> >
> >https://www.gnu.org/s/hello/manual/autoconf/Generic-Functions.html
> >https://www.gnu.org/s/hello/manual/automake/LIBOBJS.html
> >
> >(see AC_LIBOBJ, AC_REPLACE_FUNCS etc).
> >
> > From upstream (ie. our) point of view, it means the replacement is
> >stuffed into another file that is only used on Windows and that we
> >don't have to worry about.  From your point of view the advantage is
> >that you can [in the replacement file] go wild with whatever Windows
> >specific includes and Win32 APIs you want.
> >
> 
> Ok, thx for pointing me in that direction. I'm willing to do it like
> that but I have two further questions.
> 
> 1. This damn windows MapViewOfFile function needs a handle to a file
> map object that has to be saved somewhere to be able to close it
> when calling munmap. The only way I currently see to save it would
> be in your hive_h structure. But this would incorporate that on
> windows, when calling mmap and munmap, an additional parameter would
> have to be passed. Would that be ok for you or do you have an idea
> how this could be solved nicer?

It's fine to store a few extra things in the hive_h struct.  That
would not be too invasive.

> 2. What do you request from the mmap / munmap replacement? Should it
> only support the functionality currently used in the lib or should
> it implement as far as possible all features from the libc mmap /
> munmap functions?

For replacement functions, you only need to support just enough to
make the hivex library work.  Anything above that is actually bad --
more code == more maintenance :-(

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw