Re: Virtual memory under Win95

[Alexandre Julliard]

"Dmitry Timoshkov"  writes:
> From http://msdn.microsoft.com/library/psdk/winbase/filemap_79wn.htm
>
> --- cut ---
> "To fully close a file-mapping object, an application must unmap all mapped views
> of the file-mapping object by calling UnmapViewOfFile, and close the file-mapping
> object handle by calling CloseHandle. The order in which these functions are called
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> does not matter. The call to UnmapViewOfFile is necessary because mapped views of
> ^^^^^^^^^^^^^^^
> a file-mapping object maintain internal open handles to the object, and a file-mapping
> object will not close until all open handles to it are closed."
> --- cut ---
>
> My patch is WRONG. MSDN says that until both CloseHandle and UnmapViewOfFile are called
> the file-mapping object still exists. This is wrong for NT but true for Win9x.

Why do you say it's wrong for NT?  It seems perfectly correct: the
mapping object exists as long as you have a handle to it, or some view
of it is mapped (which keeps a handle internally, just like we do
under Wine).

Do not confuse the file mapping object with mapped views; the doc only
talks about the mapping object. Specific views of the object are
unmapped by UnmapViewOfFile (at least under NT), even if this may not
cause the mapping object to be deleted. This doesn't contradict the
doc at all.

Virtual memory under Win95

[Ulrich Weigand]

Alexandre Julliard wrote:
> Why do you say it's wrong for NT?  It seems perfectly correct: the
> mapping object exists as long as you have a handle to it, or some view
> of it is mapped (which keeps a handle internally, just like we do
> under Wine).
>
> Do not confuse the file mapping object with mapped views; the doc only
> talks about the mapping object. Specific views of the object are
> unmapped by UnmapViewOfFile (at least under NT), even if this may not
> cause the mapping object to be deleted. This doesn't contradict the
> doc at all.

I think the cause for the behaviour observed by Dmitry might be the
strange implementation of mapped views in Win9x:  as I recall, there's
on the one hand a list of mapped views per process maintained by 
KERNEL32, but on the other hand the actual address space management
is done by VMM, which has *also* something like a list of mapped
regions per address space.

UnmapViewOfFile in Win95 does remove the view from the KERNEL32 list
of views per process.  However, it then only calls the _PageFlush VMM 
service on the address range, which does not actually remove the pages
from VMM's lists, but only flushes all dirty pages to their backing
store ...

VirtualQuery in Win95, however, appears to completely ignore the 
KERNEL32 list of views, but always calls the _PageQuery VMM service
and returns VMM's opinion on the status of the pages.  This explains
why VirtualQuery shows the pages still present after UnmapViewOfFile.

Bye,
Ulrich

Virtual memory under Win95

[Dmitry Timoshkov]

"Ulrich Weigand"  wrote:
> VirtualQuery in Win95, however, appears to completely ignore the 
> KERNEL32 list of views, but always calls the _PageQuery VMM service
> and returns VMM's opinion on the status of the pages.  This explains
> why VirtualQuery shows the pages still present after UnmapViewOfFile.

Perhaps applications which use assumptions about Win95 virtual memory
management should be considered as broken? Or it is worth to support them?

In my case installer works very well with -winver nt40 switch, but certainly
there are other applications written for Win9x in mind only...