Sv: mmap()-like functionality in Win32

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>Ok, letīs see. I donīt have much time (my first - and hardest - exam
>this semester is already on tuesday), but Iīll try to build an
>intermediate PFile version, with the VFS system in place but without Pak
>writing support. You could take this version, fiddle around with it, add
>the Win32 specific things, debug it (grin) and when I have the next
>revision working (i.e. with PakFile writing + ppfMkDir () etc) we merge
>the versions.
>
We couldn't have you getting bad grades because of PenguinFile, and
certainly not becuse of me... :)  If you need to study, I'd do that instead
(study).

I actually wouldn't mind doing a little debugging (increases understandment
of the system), however, I haven't actually gotten the thing to compile on
Win32 yet, so I would need to find the incompatibility bugs that does that
before I could look at any new features (except, of course, if they too had
incompatibility bugs that caused the thing to compile, which I sincerely
hope not :).

>Also donīt bother too much about the mmapping now - Iīm still not
>completely sure whether it really would be good in all situations.
>
I had a somewhat more comprehensive search of the documentation and found
that there are actually several ways to do this.

If you do decide to implement this, then when making up your mind, there are
some issues I need to have you be very clear on before I can decide on how I
want to implement this:

1- Will it be possible to write to memory mapped files?
2- should these changes be mirrored in the memory buffer, or only on the
harddisk? If they should be mirrored in the memory buffer, at what time
should the changes be reflected on the harddisk? At time of change? At time
of unmapping?
3- What kind of file-sharing will memory mapped files have? Will we allow
other processes to write to the file? Only read access for other processes?
Neither read nor write access for other processes?
4- If they *are* granted write access, what if another processes suddenly
decides to change the memory mapped file? Should this be mirrored in the
memory buffer? When? At time of change? At some kind of regular update?
5- Should it be possible only to memory map part of files? What about pak
files? Should it be possible to only memory map one file in a pak file? Must
the client memory map the complete pak file?
6- how will we be storing the data? Singly dimensioned arrays? What type of
data? const char? char? const ppByte? ppByte?
7- What about out-of-memory situations? Is it ok to "memory" map to harddisk
space faking it as memory?
8- How much of a say should the client have of a say in these issues? How
much should the client be told of how the memory mapping mechanism is
faring? Complete black-out of all information? Failure/success reports only?
Detailed reports on everything? Should we give the client a choice in how
much informatio he wants?

Of course, the less I need to do, the faster and neater the code will be.
Doing things in different ways when dealing with format 0 pak files than
when dealing with format 1 ones might be an idea.

> Well, having one function
> void *ppf_MMap (const char *filename, int flags);
> that encapsulates both POSIX and Win32 versions would be fine.
>
Depends on how much functionality you want me to implement. If you want to
implement all the features I mention above, this will certainly not do. If
you don't want to implement all the features, but inly a subset, then this
might be sufficient. If you do chose to implement memory mapping, you'll
have give me some feedback on this issue.

>Not like that. Two seperate #ifdefs are better (because POSIX and Win32
>donīt 100% overlap).
>
Don't overlap? What do you mean?

>And - letīs do it as I described above. Iīll add no Win32 things to the
>main code yet - add it to your personal copy for now and weīll merge it
>when my current code update is done (which will be before my holiday
>unless something serious happens).
>
Fine with me :)