Re: Error in ntdll/module.c?

[Rolf Kalbermatter]

Christian Iversen [mailto:[e-mail]] wrote:
> According to:
>
> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/
> Executable%20Images/LdrGetProcedureAddress.html
>
> The parameter order for LdrGetProcedureAddress is (Handle, Function, 
> Ordinal, Address)
>
> The file dlls/ntdll/module.c has the order as (Handle, Ordinal, 
> Function, Address)

Ok. I took a look at the call sequence of this function in a native
kernel32.dll and the second parameter is initialized with RtlInitString.
So I guess the parameter order as on that web site would be correct.

Having looked at the particular assembly code obviously excludes me
from doing any work on this part anymore.

As to the current implemenation I'm not sure that makes any difference
since most undocumented APIs are unlikely to be used by applications.
And since ntdll and kernel32 are both also Wine specific and therefore
can't be replaced by Windows ones this won't matter either it would seem.

You can try to post a proper patch to both kernel32 and ntdll to
wine-patches and then let Alexandre decide if he wants to apply it.

Rolf Kalbermatter

Error in ntdll/module.c?

[Eric Pouech]

Rolf Kalbermatter a écrit :
> Christian Iversen [mailto:[e-mail]] wrote:
> > According to:
> >
> > http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/
> > Executable%20Images/LdrGetProcedureAddress.html
> >
> > The parameter order for LdrGetProcedureAddress is (Handle, Function, 
> > Ordinal, Address)
> >
> > The file dlls/ntdll/module.c has the order as (Handle, Ordinal, 
> > Function, Address)
>
> Ok. I took a look at the call sequence of this function in a native
> kernel32.dll and the second parameter is initialized with RtlInitString.
> So I guess the parameter order as on that web site would be correct.
>
> Having looked at the particular assembly code obviously excludes me
> from doing any work on this part anymore.
>
> As to the current implemenation I'm not sure that makes any difference
> since most undocumented APIs are unlikely to be used by applications.
> And since ntdll and kernel32 are both also Wine specific and therefore
> can't be replaced by Windows ones this won't matter either it would seem.
>
> You can try to post a proper patch to both kernel32 and ntdll to
> wine-patches and then let Alexandre decide if he wants to apply it.

googling LdrGetProcedureAddress gives the same conclusion
It's always a good idea to have APIs behaving like on windows
A+