Michael Jung <[EMAIL PROTECTED]> writes:
> Thinking about it again, there probably is no such thing as an ELF wrapped PE?
No, the ELF linker cannot support everything we need, so parts of the
PE header need to be generated at load time. So there's no way to
access a real PE header without loading
On Thursday 25 August 2005 09:56, Michael Jung wrote:
> Would it be ok to look for an ELF header and then for an enclosed PE header
> in USER32_GetResourceTable (and then return IMAGE_NT_SIGNATURE and the
> correct pointer)? Where can I find informations about the format of ELF
> wrapped PEs?
T
Robert Shearman <[EMAIL PROTECTED]> writes:
> Anything that uses SearchPath is similarly broken when needing to find a
> builtin dll or exe. We should add a hack^H^H^H^Hextension to that
> function to make it be able to find installed .so files with a similar name.
That won't really help, becau
Hi Rob,
On Thursday 25 August 2005 06:50, you wrote:
> Anything that uses SearchPath is similarly broken when needing to find a
> builtin dll or exe. We should add a hack^H^H^H^Hextension to that
> function to make it be able to find installed .so files with a similar
> name.
I think that's just
on code of the 'Shell Icon Cache' (starting from line 372 in
'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at
initialization time, and later returns them from the cache without having to
access the file (which would'nt work).
This seems to b
'Shell Icon Cache' (starting from line 372 in
'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at
initialization time, and later returns them from the cache without having to
access the file (which would'nt work).
This seems to be a principal problem (Loading r
