Bernt
asked on
GetProcAddress with index not name
I fail load proc addresses...
I've never used index to load them before, but this time I need it. Win32 SDK say's that the I must specify the number in a low order value, and the high part should be 0...
I try this now, and it fails:
FDLLHandle := GetModuleHandle('kernel32'
if FDLLHandle = 0 then
FDLLHandle := LoadLibrary('kernel32');
if FDLLHandle <> 0 then
begin
@FLoadLibrary16 := GetProcAddress(FDLLHandle,
if @FLoadLibrary16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FLoadLibrary16');
@FFreeLibrary16 := GetProcAddress(FDLLHandle,
if @FFreeLibrary16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FFreeLibrary16');
@FGetProcAddress16 := GetProcAddress(FDLLHandle,
if @FGetProcAddress16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FGetProcAddress16');
end;
---
And this fails to:
var
p1,p2,p3: Pointer;
begin
FDLLHandle := GetModuleHandle('kernel32'
if FDLLHandle = 0 then
FDLLHandle := LoadLibrary('kernel32');
if FDLLHandle <> 0 then
begin
p1 := GetProcAddress(FDLLHandle,
if p1 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p1');
p2 := GetProcAddress(FDLLHandle,
if p2 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p2');
p3 := GetProcAddress(FDLLHandle,
if p3 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p3');
end;
end;
---
There's no problems with "direct" declaretion, eg;
function LoadLib16(Lib: PChar): THandle; stdcall; external kernel32 index 35;
I've never used index to load them before, but this time I need it. Win32 SDK say's that the I must specify the number in a low order value, and the high part should be 0...
I try this now, and it fails:
FDLLHandle := GetModuleHandle('kernel32'
if FDLLHandle = 0 then
FDLLHandle := LoadLibrary('kernel32');
if FDLLHandle <> 0 then
begin
@FLoadLibrary16 := GetProcAddress(FDLLHandle,
if @FLoadLibrary16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FLoadLibrary16');
@FFreeLibrary16 := GetProcAddress(FDLLHandle,
if @FFreeLibrary16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FFreeLibrary16');
@FGetProcAddress16 := GetProcAddress(FDLLHandle,
if @FGetProcAddress16 = nil then
ShowMessage('NIL !!!' +#13#10+ '@FGetProcAddress16');
end;
---
And this fails to:
var
p1,p2,p3: Pointer;
begin
FDLLHandle := GetModuleHandle('kernel32'
if FDLLHandle = 0 then
FDLLHandle := LoadLibrary('kernel32');
if FDLLHandle <> 0 then
begin
p1 := GetProcAddress(FDLLHandle,
if p1 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p1');
p2 := GetProcAddress(FDLLHandle,
if p2 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p2');
p3 := GetProcAddress(FDLLHandle,
if p3 = nil then
ShowMessage('NIL !!!' +#13#10+ 'p3');
end;
end;
---
There's no problems with "direct" declaretion, eg;
function LoadLib16(Lib: PChar): THandle; stdcall; external kernel32 index 35;
ASKER
Hi there "inter", it fails with MakeWord() to...
But thanks a million for that one, I didn't know the MakeWord existed.
Somehow I think I'm into a bug, but if it's me that creating it or something else I dont have a clue. the "regular" declaration, eg "...;cdecl; external 'kernel32' index 35;" works without problems, I really scratching my head.
But thanks a million for that one, I didn't know the MakeWord existed.
Somehow I think I'm into a bug, but if it's me that creating it or something else I dont have a clue. the "regular" declaration, eg "...;cdecl; external 'kernel32' index 35;" works without problems, I really scratching my head.
ASKER
Edited text of question.
No, that's no bug... :-)
It's a so called "feature". Microsoft doesn't want you to call GetProcAddress on those hidden kernel functions, so they manipulated the GetProcAddress call.
Believe me, this is the wicked truth!!
One solution is declaring it with external ... like you did in your last comment. The other possibility is to build your own GetProcAddress by parsing the PE header of the kernel dll.
Regards, Madshi.
It's a so called "feature". Microsoft doesn't want you to call GetProcAddress on those hidden kernel functions, so they manipulated the GetProcAddress call.
Believe me, this is the wicked truth!!
One solution is declaring it with external ... like you did in your last comment. The other possibility is to build your own GetProcAddress by parsing the PE header of the kernel dll.
Regards, Madshi.
ASKER
Hi Madshi!
woav...
I think I drop it, I wanted to test if NT was loaded and then "know" if I could load it or not from a TObject that should handle it.
This "build" my own GetProcAddress and read the PE header is something I know NIL of, so I going to not use it.
{****.......}
;-)
woav...
I think I drop it, I wanted to test if NT was loaded and then "know" if I could load it or not from a TObject that should handle it.
This "build" my own GetProcAddress and read the PE header is something I know NIL of, so I going to not use it.
{****.......}
;-)
Hi Bernt,
don't give it up so fast. The correct syntax to load the addresses is:
GetProcAdress(DLLHandle, '#37');
where 37 is the index of the function to import. I have used this approach to make a little joke if someone does a "QuickView" on a DLL I've written. He gets only to see:
Index Name
1 You
2 shall
3 not spy
4 (c) blah blah
then I use the approach given above to actually import the functions.
Ciao, Mike
don't give it up so fast. The correct syntax to load the addresses is:
GetProcAdress(DLLHandle, '#37');
where 37 is the index of the function to import. I have used this approach to make a little joke if someone does a "QuickView" on a DLL I've written. He gets only to see:
Index Name
1 You
2 shall
3 not spy
4 (c) blah blah
then I use the approach given above to actually import the functions.
Ciao, Mike
Mike, according to the documentation it should look like this:
GetProcAddress(dllHandle, pchar(37));
If you say that, I believe you, that your approach works, too. But it doesn't matter. "pchar(37)" works well for all dlls - except kernel32.dll. So I'm quite sure that '#37' will behave exactly the same way.
Regards, Madshi.
GetProcAddress(dllHandle, pchar(37));
If you say that, I believe you, that your approach works, too. But it doesn't matter. "pchar(37)" works well for all dlls - except kernel32.dll. So I'm quite sure that '#37' will behave exactly the same way.
Regards, Madshi.
Here comes a little text:
"Win32 code to import by ordinal from KERNEL32.DLL in Windows 95
Andrew Schulman
Senior editor, O'Reilly & Associates (Sebastopol CA)
August 1995
After I wrote Unauthorized Windows 95 (IDG Books, 1994), KERNEL32.DLL
stopped exporting undocumented Win32 functions such as VxDCall() and
GetpWin16Lock() by name. The functions discussed in *Unauthorized*
continue to be exported by ordinal (for example, VxDCall is
KERNEL32.1 and GetpWin16Lock is KERNEL.93). However, KERNEL32 does
not allow imports by ordinal (Message from debug version:
"GetProcAddress: kernel32 by id not supported").
This module provides GetK32ProcAddress() to support import by ordinal
from KERNEL32. There's nothing undocumented in here, except for the
ordinal numbers themselves. GetModuleHandle() returns the address of
the executable image (see Matt Pietrek in *Microsoft Systems Journal*,
September 1995, p. 20), and the image is documented in the PE (Portable
Executable) file format."
"Win32 code to import by ordinal from KERNEL32.DLL in Windows 95
Andrew Schulman
Senior editor, O'Reilly & Associates (Sebastopol CA)
August 1995
After I wrote Unauthorized Windows 95 (IDG Books, 1994), KERNEL32.DLL
stopped exporting undocumented Win32 functions such as VxDCall() and
GetpWin16Lock() by name. The functions discussed in *Unauthorized*
continue to be exported by ordinal (for example, VxDCall is
KERNEL32.1 and GetpWin16Lock is KERNEL.93). However, KERNEL32 does
not allow imports by ordinal (Message from debug version:
"GetProcAddress: kernel32 by id not supported").
This module provides GetK32ProcAddress() to support import by ordinal
from KERNEL32. There's nothing undocumented in here, except for the
ordinal numbers themselves. GetModuleHandle() returns the address of
the executable image (see Matt Pietrek in *Microsoft Systems Journal*,
September 1995, p. 20), and the image is documented in the PE (Portable
Executable) file format."
I've also a unit that belongs to this text (which implements GetK32ProcAddress). I can't post it here. EE is telling me Internal Server Error all the time, if I try to post this code.
So if anyone is interested, give me your eMail address, then I'll send it to you.
So if anyone is interested, give me your eMail address, then I'll send it to you.
Ooops, I never heard that a specific DLL behaves differently than the other ones in this regard and you know I've done a lot lately with DLLs, thunking and such (which works btw. beautyful now :-)).
The problems you encounter when posting the unit result from one or more characters not being in the range #32..#7F. So we can't even talk with german's s-umlaut etc. :-)
Ciao, Mike
The problems you encounter when posting the unit result from one or more characters not being in the range #32..#7F. So we can't even talk with german's s-umlaut etc. :-)
Ciao, Mike
ASKER
Woav, how about my new forum;-)
----
Lischke, what you wrote:
Date: Wednesday, November 17 1999 - 01:59 PM CET
---
I jumped right up and become happy and tryed it right away. Hu! The return from it is nil anyway, eg;
@FLoadLibrary16 := GetProcAddress(FDLLHandle,
@FFreeLibrary16 := GetProcAddress(FDLLHandle,
@FGetProcAddress16 := GetProcAddress(FDLLHandle,
Seems that this was not easy at all. I give it one more shot and increase the point, maybe is a million point issue;-).
----
Lischke, what you wrote:
Date: Wednesday, November 17 1999 - 01:59 PM CET
---
I jumped right up and become happy and tryed it right away. Hu! The return from it is nil anyway, eg;
@FLoadLibrary16 := GetProcAddress(FDLLHandle,
@FFreeLibrary16 := GetProcAddress(FDLLHandle,
@FGetProcAddress16 := GetProcAddress(FDLLHandle,
Seems that this was not easy at all. I give it one more shot and increase the point, maybe is a million point issue;-).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I meant the API hook stuff under Win9x and WinNT.
Ah... :-)
ASKER
Madshi
Date: Thursday, November 18 1999 - 07:20AM
---
Ahh, was a bit lost in this end...
my email: levin@ulricehamn.mail.teli
a http if you have nothin to do:
http://w1.321.telia.com/~u32102551/
Date: Thursday, November 18 1999 - 07:20AM
---
Ahh, was a bit lost in this end...
my email: levin@ulricehamn.mail.teli
a http if you have nothin to do:
http://w1.321.telia.com/~u32102551/
ASKER
Code sent to me as email, coolness...
Experts Exchange, check your character translation for posting code!!!
Experts Exchange, check your character translation for posting code!!!
what about
GetProcAddress(FDLLHandle,
regards, igor