Why are some VB6 DLLs loaded as mapped files?

A colleague of mine, whilst trying to figure out the memory usage of o开发者_如何学Pythonur VB6 / C# 2.0 application noticed that a minority of VB6 DLLs have two entries in the SysInternals Process Explorer application.

All DLLs have an entry for Mapping = Image, and a specified base address. However, a few also have an entry for Mapping = Data, with a base address of zero, and a much smaller memory usage. I seem to remember something about using mapped memory files to share memory between processes, but we are definitely not doing something as interesting as this. All communication between EXEs is done via COM, and as far as I know, nobody has written a shared memory component.

Any suggestions as to why some DLLs are loaded as mapped file?

It's been too long ago, but I do remember that the native execution model for Visual Basic was interpreted P-code. Somewhere around the VB4 era, it started supporting compiling to native machine code. Mostly to stay competitive with Borland's Delphi, IIRC.

P-code will be loaded as data and is much more compact than machine code. And much slower. Machine code will be loaded like any DLL in Windows, a memory mapped file page-faults the code into memory.

Just a guess, but do any of your DLLs have Public or Global variables declared in BAS modules? If so, they are shared between all the objects in your DLL and they might be stored in a data area?

An even wilder guess. Are you using XP and are those DLLs getting rebased when the EXE loads them? (You can ask Process Explorer to highlight rebased DLLs in another colour). You can prevent rebasing by changing the base address. It'll make the DLLs load faster even if it doesn't explain the small memory area.

Could the memory-mapped DLL's be DLL's that have embedded resources in them? I'm not sure how Windows (or VB6, for that matter) normally deals with resources in DLL's, but I'm wondering if DLL's that were explicitly compiled with a .res file in VB6 are the ones that are showing up twice.

Maybe it does this so that when two EXE's load the same DLL, they can share a single copy of the DLL's resources. I'm completely guessing though.

Add another wild guess:

Is it possible some of these PE files were linked using a /SWAPRUN setting?

The /SWAPRUN option tells the operating system to first copy the linker output to a swap file, and then run the image from there. This is a Windows NT 4.0 (and later) feature.

If NET is specified, the operating system will first copy the binary image from the network to a swap file and load it from there. This option is useful for running applications over the network. When CD is specified, the operating system will copy the image on a removable disk to a page file and then load it.