[MPlayer-dev-eng] Re: [PATCH] [RFC] fix GetModuleHandle(0)
vyslnqaaxytp at spammotel.com
Mon Mar 26 01:20:28 CEST 2007
>>>>> 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.
More information about the MPlayer-dev-eng