MapViewOfFile

[Quell]

Hello.
I got question about the next code:

PBYTE g_pMappedFileBase = 0;
PIMAGE_DOS_HEADER dosHeader;
PIMAGE_FILE_HEADER pImgFileHdr;

Variables

g_pMappedFileBase = (PBYTE)MapViewOfFile(hFileMapping,FILE_MAP_READ,0,0,0);
dosHeader = (PIMAGE_DOS_HEADER)g_pMappedFileBase;
pImgFileHdr = (PIMAGE_FILE_HEADER)g_pMappedFileBase;

Okey.
I got a question about thw g_pMappedFileBase contains the adress of the start of the mapped file? Is that right?
and how exectly can we assign the dosHEader and pImgFileheader their values if g_pMappedFileBase is an adress only....it poits to the first offset and not the whole file?
Here is the MSDN reference to MapViewOfFile

   MSDN Home >  MSDN Library >  Win32 and COM Development >  System Services >  File Services >  File Systems >  File Management >  File Management Reference >  File Management Functions
 
Platform SDK: File Systems
MapViewOfFile

The MapViewOfFile function maps a view of a file mapping into the address space of a calling process.

To specify a suggested base address for the view, use the MapViewOfFileEx function. However, this practice is not recommended.

LPVOID MapViewOfFile(
  HANDLE hFileMappingObject,
  DWORD dwDesiredAccess,
  DWORD dwFileOffsetHigh,
  DWORD dwFileOffsetLow,
  SIZE_T dwNumberOfBytesToMap
);

Parameters

hFileMappingObject
    [in] A handle to an open handle of a file mapping object. The CreateFileMapping and OpenFileMapping functions return this handle.
dwDesiredAccess
    [in] The type of access to a file mapping object, which ensures the protection of the pages. This parameter can be one of the following values.
    Value 	Meaning
    FILE_MAP_WRITE 	Read/write access. The mapping object must be created with PAGE_READWRITE protection. A read/write view of the file is mapped.
    FILE_MAP_READ 	Read-only access. The mapping object must be created with PAGE_READWRITE or PAGE_READONLY protection. A read-only view of the file is mapped.
    FILE_MAP_COPY 	

    Copy-on-write access. The mapping object must be created with PAGE_WRITECOPY protection.

    The system commits physical storage from the paging file at the time that MapViewOfFile is called. The actual physical storage is not used until a thread in the process writes to an address in the view. At that time, the system copies the original page to a new page that is backed by the paging file, maps the page into the process address space, and changes the page protection to PAGE_READWRITE. The threads in the process can access only the local copy of the data, not the original data. If the page is ever trimmed from the working set of the process, it can be written to the paging file storage that is committed when MapViewOfFile is called.

    This process only allocates physical memory when a virtual address is actually written to. Changes are never written back to the original file, and are freed when the thread in your process unmaps the view.

    Paging file space for the entire view is committed when copy-on-write access is specified, because the thread in the process can write to every single page. Therefore, enough physical storage space must be obtained at the time MapViewOfFile is called.
    FILE_MAP_EXECUTE 	

    Execute access. Code can be run from the mapped memory. The mapping object must be created with PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_READ access.

        Windows Server 2003 and Windows XP:  This feature is not available until Windows XP SP2 and Windows Server 2003 SP1.

dwFileOffsetHigh
    [in] A high-order DWORD of the file offset where the view begins.
dwFileOffsetLow
    [in] A low-order DWORD of the file offset where the view is begins. The combination of the high and low offsets must specify an offset within the file that matches the memory allocation granularity of the system, or the function fails. 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.
dwNumberOfBytesToMap
    [in] The number of bytes of a file mapping to map to the view. If this parameter is 0 (zero), the mapping extends from the specified offset to the end of the section.

Return Values

If the function succeeds, the return value is the starting address of the mapped view.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.
Remarks

Mapping a file makes the specified portion of a file visible in the address space of the calling process.

For files that are larger than the address space, you can only map a small portion of the file data at one time. When the first view is complete, you can unmap it and map a new view.

To obtain the size of a view, use the VirtualQuery function.

Multiple views of a file (or a file mapping object and its mapped file) are coherent if they contain identical data at a specified time. This occurs if the file views are derived from the same file mapping object. A process can duplicate a file mapping object handle into another process by using the DuplicateHandle function, or another process can open a file mapping object by name by using the OpenFileMapping function.

A mapped view of a file is not guaranteed to be coherent with a file that is being accessed by the ReadFile or WriteFile function.

Do not store pointers in the memory mapped file; store offsets from the base of the file mapping so that the mapping can be used at any address.

To guard against EXCEPTION_IN_PAGE_ERROR exceptions, use structured exception handling to protect any code that writes to or reads from a memory mapped view. For more information, see Reading and Writing From a File View.

If a file mapping object is backed by the paging file (hFile is INVALID_HANDLE_VALUE), the paging file must be large enough to hold the entire mapping. If it is not, MapViewOfFile fails.

    Windows Me/98/95:  MapViewOfFile may require the swapfile to get larger. If the swapfile cannot get larger, the function fails.

To have a file with executable permissions, an application must call CreateFileMapping with either PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_READ, and then call MapViewOfFile with FILE_MAP_EXECUTE | FILE_MAP_WRITE or FILE_MAP_EXECUTE | FILE_MAP_READ.

Example Code

For an example, see Creating Named Shared Memory.
Requirements
Client 	Requires Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, or Windows 95.
Server 	Requires Windows Server 2003, Windows 2000 Server, or Windows NT Server.
Header 	

Declared in Winbase.h; include Windows.h.
Library 	

Link to Kernel32.lib.
DLL 	Requires Kernel32.dll.
See Also

CreateFileMapping, DuplicateHandle, File Management Functions, GetSystemInfo, MapViewOfFileEx, OpenFileMapping, SYSTEM_INFO, UnmapViewOfFile
  
  Last updated: March 2005  |  What did you think of this topic?  |  Order a Platform SDK CD
  © Microsoft Corporation. All rights reserved. Terms of use.

 

Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
© 2005 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks |Privacy Statement
	Microsoft

Thx in Advance

[SuperKoko]

g_pMappedFileBase points to the first byte of the file mapping.
dosHeader and pImgFileHdr will also points to the first byte of the file mapping.

You want probably to read an executable data loaded in a file mapping.
so, you must replace

pImgFileHdr = (PIMAGE_FILE_HEADER)g_pMappedFileBase;

by

pImgFileHdr = (PIMAGE_FILE_HEADER)&((PIMAGE_NT_HEADERS32)(dosHeader+1))->FileHeader;

With the IMAGE_NT_HEADERS32 defined like in this web page http://www.acm.uiuc.edu/sigmil/RevEng/ch08.html

I hope that it can help you!

[Quell]

Thx, but i will start from the dosheader, and then get all the PE info from there......
i can do that right?
i do not need the
pImgFileHdr = (PIMAGE_FILE_HEADER)g_pMappedFileBase;
becuase i can just use the address pointer from the dos heaader to get the PE structure and from that i can move on to the seciont....right?

[SuperKoko]

The correct code is:

pImgFileHdr=&((PIMAGE_NT_HEADERS)g_pMappedFileBase+dosHeader->e_lfanew)->FileHeader;

You can also check the signatures of DOS header, and PE header.

[Quell]

well the problem is that with my incorrect code stuff works....
well this is not my code and there is not a lot of explanation to it....
so any ideas on how it can actualy work?

[SuperKoko]

becuase i can just use the address pointer from the dos heaader to get the PE structure and from that i can move on to the seciont....right?

Yes, the MapViewOfFile function maps all the file into the memory.

if you use only one MapViewOfFile in only one process, it is equivalent to allocate memory with the size of the file, open the file, read all the file, and close the file.

Note that the real interest of MapViewOfFile if to allow different processes to share common physical memory, but it is not the only use.

[SuperKoko]

well the problem is that with my incorrect code stuff works....
well this is not my code and there is not a lot of explanation to it....
so any ideas on how it can actualy work?

Maybe the IMAGE_FILE_HEADER structure contains the IMAGE_DOS_HEADER as a first field.
But, after the IMAGE_DOS_HEADER, there is the MS-DOS 16 bit file content.
So, i don't understand how it can works.

But the most important thing, is that it works!