[MPlayer-dev-eng] Re: [PATCH] [RFC] fix GetModuleHandle(0)

[Martin Simmons]

>>>>> On Mon, 19 Mar 2007 07:40:21 -0700, Alan Nisota said:
> Martin Simmons wrote:
> >>>>>> On Sun, 18 Mar 2007 14:23:12 -0700, Alan Nisota said:
> >> Do you know if this is supposed to 
> >> be mapped to a structure?
> > 
> > The memory contains bytes from the start of the EXE file, but the handle is
> > opaque so code shouldn't depend on the memory contents or any particular
> > non-zero value.
> > 
> > I wonder why the old value 1 didn't work?  It might be worth trying 0x129
> > (i.e. the next value like MODULE_HANDLE_winmm).
> The code definitely expects some sort of structure it does:
> (eax is the return value)
> esi = eax+[eax+0x3c]
> eax = [esi+0x14]
> if([esi+6] == 0) ...
> (I didn't look any further than that)
> 
> so it looks like it expects:
> a)eax is a pointer to a struture
> b)eax+0x3c points at a different structure
> So maybe it should be opaque, but it's not to CoreAVC.  I'm guessing it 
> is looking for a PE header.  I'm not sure it cares what is in it, but it 
> seems to want some value stored within it.  Since feeding CoreAVC it's 
> own memory pointer works, I assume it can't be too picky about what it 
> finds there (besides the relevant structures it's looking for)

Yes, it would be the PE header.

I suppose returning the module of some other loaded DLL is the next best thing
to making a fake module for the main program.  Rather than hardwiring the
address, I would pick one from the existing module list.

__Martin