[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mmap()-like functionality in Win32



Peter Burns is indeed correct: Win32 *does* implement mmap()-like behavior.
In fact, Win32 does things almost the exact same way. The only difference is
that Win32 requires that first a file-mapping object be created, and then
views (read: mappings) can be made on the file in exactly the same way as
mmap() does. I *think*: I'm not yet sure if several, different views can be
created from the same file-mapping object, but as anything else would be
kind of pointless (why then have two seperate objects, file-mapping and
views, if this was not possible?), I assume that it is possible. I'll get
this issue cleared by tomorrow.

I'm still not positive what the different parameters should be to the
functions which implement this behavior, but I'll make a little test-program
to find out tomorrow (it's 4 in the morning here).

Well, Christian, it seems that everything is a-ok on the Win32 portability
issues of using mmap(). I think I will need some Win32-specific variables
inserted in some structs:

A file-mapping handle in ppf_PakFile, for enabling the creation of views

A view (read: mapping) handle in ppf_PakFileFile. This would only allow
mapping of files contained in pak files, however. The class responsible for
normal files I have not been able to track down (is there even one?).

I will not be able to implement the mmap() function in terms of Win32 as I
have with the other POSIX functions you've been using. Well, it would be
possible, but it wouldn't be effecient (I'll ībe sure to tell you if I do
come up with a way to do this efficiently; I'm not sure it can't be done,
but that's mostly because I haven't thought about for very long at this
point (couple of minutes)).

This means you (Christian Reiniger) will most likely (if I do not find some
other way to do it)  have to do a bit of #ifdef'ing for the symbols
_PP_POSIX and _PP_WIN32, calling different functions based on which is
defined (don't make it so that the absense of the one automaticly makes the
code look as if the other is not absent, though, that would make porting to
yet another platform harder).

btw, I would appreciate it if you could could change this specific bit of
PenguinPlay.h:

#ifdef HAVE_UNISTD_H
#  define _PP_POSIX
#  include <unistd.h>
#else
#  error "POSIX functionality currently needed"
#endif

to this:

#ifdef HAVE_UNISTD_H
#  define _PP_POSIX
#  include <unistd.h>
#elif defined(WIN32)
#  define _PP_WIN32
#else
#  error "POSIX or Win32 functionality currently needed"
#endif

I would appreciate that :)