tags:

views:

85

answers:

4

Hi -

A colleague of mine, whilst trying to figure out the memory useage of our 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 useage. 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.

This is not desperate, but I would be very interested in any suggestions as to why some DLLs are loaded as mapped file

Thanks,

Mark Bertenshaw

+1  A: 

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.

Hans Passant
Good suggestion. You can use a project setting to toggle between P-Code and native code. Perhaps most of the DLLs are set to native compilation but those few others are set to P-Code.
MarkJ
Nice idea! However, none of our projects are set to P-Code. Also, I have deliberately set a DLL to P-Code, and the P-Code is definitely contained in just the Image - there's no file mapping going on.
Mark Bertenshaw
It's kind of funny everyone here is guessing ;) Where are the rugged, dyed-in-the-wool Windows programmers who can answer this question and then hit us on the head repeatedly with a copy of _Windows Programming_ for being unworthy?
Mike Spross
Hmm, they read it and know that it doesn't say anything at all about VB6 or P-code interpreters.
Hans Passant
P-code can be faster at times. This is almost entirely due to the "smaller is better" factor in terms of load times and cache capacity. It can be even more important in high-concurrency server scenarios.
Bob Riemersma
A: 

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.

MarkJ
Mark - Well, we do have DLLs with global variables declared, but those that do so only overlap with those DLLs which have file mapping, not coincide. As for rebasing - I wondered that myself, but again it doesn't seem to have a bearing on this situation.
Mark Bertenshaw
@Mark B Oh well, I thought I would try some guesses.
MarkJ
A: 

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.

Mike Spross
Good idea, Mike, and I originally wondered if it was something like that. Unfortunately, only one of our components use resources, and that isn't exhibiting this behaviour.
Mark Bertenshaw
A: 

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.

Bob Riemersma