* It's unfortunate to have to use program introspection so heavily like
this (perhaps there should be a GL-specific shader reflection structure
like DXBC where these locations and strides could be cached), but it's
not too bad and handles any arbitrary layout
* For APIs where the shader namespace/bindpoint (which may be arbitrary
like 'the Nth texture resource' can be mapped, at each event, to the
actual API bind point where the object is.
* On D3D11 this is pass-through, on GL this returns the value of each
uniform.
* This also means GL shader reflection structures are properly immutable
and the variance in the uniform values is handled elsewhere.
* In future this might need to be expanded to support more complex binding
methods, where the mapping returns the resource rather than just mapping
to an integer bind ponit.
* Bail if we find an IAT entry already hooked as it means this module has
been processed already.
* Avoid allocations/std::string in the ApplyHooks function.
* We can't use the uniform locations from our separable program as that's
not guaranteed to be the same in the real program (could end up reading
a completely different uniform value).
* This avoids going into VirtualProtect changing the page access while code
may potentially be executing these areas of memory (since the module is
hooked, and may have returned to user code)
* Need to find a better way of solving the non-immutable-shader-reflection
given baked in uniform values. Probably expose the uniform values mapping
to the user, and for D3D it just becomes trivial and unchanging.
* Also I need to create separable programs per-shader for use for
reflection in that case, but thanks to the stupid gl_PerVertex
redeclaration that becomes a nightmare.
* This might be a more serious problem in future...
* We only hook all loaded modules once, at init time, in Win32_IAT_EndHooks
* If a LoadLibrary call afterwards implicitly loads some modules we don't
see them. Potentially we should rehook all loaded modules again each time
LoadLibrary is called but then there would be a lot of redundant work
unless we tracked module unload/loads to see if a module has been hooked
before or not. For now assume we don't need to hook these modules and
get away with just updating module handles
* Seen in the wild some HMODULEs come back pointing 2 bytes after the real
module base address, and so without the magic number. I don't know why
but I can't assume anything about the behaviour so I ignore these modules
to avoid crashes.
baldurk