Regarding memory mapped files and usage in large file text editor

Question

I am currently working on a text editor that ideally should be able to handle very large files(theoretically 16 eb). I am planning to use memory mapped files for the file management part. I read some interesting examples in the book Windows via C/C++. My questions here are:

• Is it essential that the file offsets from which I need to map should be on 64k(or whatever the allocation granularity size) boundaries?
• My second question is that if yes(to the first question), then would it be viable to map 2 64k views in order to keep a continuous flow of text, when I encounter a situation when I require the contents of the file from either sides of the 64k boundary? for example, lets say that the user scolls across to a point in the file where I have data represented in (64k - 1) of the file and this point lies in the middle of the screen of my text editor, such that i need to display data that ranges from, let's say, (64k - x) to (64k + x). So i could make two mappings, 0 - 64k and 64k - 64k(i could form a smaller mapping but then i would require to resize the mapping later in any case, to 64k).

I wasn't quite sure how to frame the questions, so if you don't understand what I meant, I'll keep updating the questions according to the responses I get.

Answer 1

According to the documentation for MapViewOfFile, dwFileOffsetLow is:

A low-order DWORD of the file offset where the view is to begin. The combination of the high and low offsets must specify an offset within the file mapping. They must also match the memory allocation granularity of the system. That is, the offset must be a multiple of the allocation granularity. To obtain the memory allocation granularity of the system, use the GetSystemInfo function, which fills in the members of a SYSTEM_INFO structure.

So the answer to your first question is yes.

The answer to your second question also is yes. You can create multiple views of the same file.

The article Managing Memory Mapped Files may be of some use to you.

By the way, if you get your text editor to the point where it can be tested, I'd be quite interested in seeing it. I have long despaired at finding an editor or text file viewer that gracefully handles very large files. See Large Text File Viewers and Designing a better text file viewer for some thoughts.