Laurent Pinchart <[EMAIL PROTECTED]> writes:
> Is someone working on DLL separation for ntdll.dll / kernel32.dll ? It seems
> that there's a lot of work to be done.
Quite a lot yes. But I think it makes more sense to first separate
properly all the dlls that depend on kernel/ntdll before attack
On Friday 31 May 2002 19:42, Alexandre Julliard wrote:
> Laurent Pinchart <[EMAIL PROTECTED]> writes:
> > I tried the code described above, but it unfortunately doesn't work for
> > all dlls. It returns a correct value in some cases (for small dlls it
> > seems), and a huge negative value around 0
Laurent Pinchart <[EMAIL PROTECTED]> writes:
> I tried the code described above, but it unfortunately doesn't work for all
> dlls. It returns a correct value in some cases (for small dlls it seems), and
> a huge negative value around 0xc000 in other cases (for bigger dlls).
Most likely the
On Wed, 29 May 2002, Laurent Pinchart wrote:
> SafeDisc implements GetProcAddress internally, and verifies that the returned
> address lies between ImageBase and ImageBase + SizeOfImage. It fails if it
> doesn't.
A warning: if I remember right, once you pass this hurdle, you'll
encounter a ch
Laurent Pinchart <[EMAIL PROTECTED]> writes:
> SafeDisc implements GetProcAddress internally, and verifies that the returned
> address lies between ImageBase and ImageBase + SizeOfImage. It fails if it
> doesn't.
In that case the easy way would be to take the highest address from
the export ta
> > I then checked the assembly code generated by gcc, and found out that
> > _end - pe_header is computed by reading 2 valus in the .got section and
> > substracting them.
> >
> > Could anyone help me ?
> >
> > Should I try with a linker script ?
>
> Maybe you should tell us why you need a correc
Laurent Pinchart <[EMAIL PROTECTED]> writes:
> I then checked the assembly code generated by gcc, and found out that _end -
> pe_header is computed by reading 2 valus in the .got section and substracting
> them.
>
> Could anyone help me ?
>
> Should I try with a linker script ?
Maybe you sho
On Wednesday 29 May 2002 22:40, Eric Pouech wrote:
> > I thought about modifying winebuild to add
> >
> > char _end[];
> > nt_headers->OptionalHeader.SizeOfImage = pe_header - _end;
> >
> > in the library initialisation function. This is small, fast and probably
> > more accurate.
> >
> > Does any
Eric Pouech <[EMAIL PROTECTED]> writes:
> don't you mean extern char _end[] instead ?
> there's nothing currently which ensures that pe_header is at the start
> of the code (it relies on the fact it's the first on gcc/ld link option,
> and that ld allocates slots for compilation units in the orde
> I thought about modifying winebuild to add
>
> char _end[];
> nt_headers->OptionalHeader.SizeOfImage = pe_header - _end;
>
> in the library initialisation function. This is small, fast and probably
> more accurate.
>
> Does anyone have any comment about that ?
don't you mean extern char _end
>
>
>>Hi everybody,
>>
>>I noticed that, when a builtin dll (.so) is loaded, the SizeOfImage field in
>>the OptionalHeader is not updated and stays equal to page_size (see
>>winebuild, spec32).
>>
>>I need to get the correct value in SizeOfImage.
>>
>>I thought about updating that field in map_d
On Tue, May 28, 2002 at 12:08:46AM +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> I noticed that, when a builtin dll (.so) is loaded, the SizeOfImage field in
> the OptionalHeader is not updated and stays equal to page_size (see
> winebuild, spec32).
>
> I need to get the correct value in
Hi everybody,
I noticed that, when a builtin dll (.so) is loaded, the SizeOfImage field in
the OptionalHeader is not updated and stays equal to page_size (see
winebuild, spec32).
I need to get the correct value in SizeOfImage.
I thought about updating that field in map_dll@library/loader.c, b
13 matches
Mail list logo
