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, PChar(35));
    if @FLoadLibrary16 = nil then
      ShowMessage('NIL !!!' +#13#10+ '@FLoadLibrary16');
    @FFreeLibrary16 := GetProcAddress(FDLLHandle, PChar(36));
    if @FFreeLibrary16 = nil then
      ShowMessage('NIL !!!' +#13#10+ '@FFreeLibrary16');
    @FGetProcAddress16 := GetProcAddress(FDLLHandle, PChar(37));
    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, PChar(MakeWord(0,35)));
    if p1 = nil then
      ShowMessage('NIL !!!' +#13#10+ 'p1');
    p2 := GetProcAddress(FDLLHandle, PChar(MakeWord(0,36)));
    if p2 = nil then
      ShowMessage('NIL !!!' +#13#10+ 'p2');
    p3 := GetProcAddress(FDLLHandle, PChar(MakeWord(0,37)));
    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;
BerntAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

interCommented:
Hi,
what about
 GetProcAddress(FDLLHandle,PChar(MakeWord(0,37)));

regards, igor
0
BerntAuthor Commented:
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.
0
BerntAuthor Commented:
Edited text of question.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

MadshiCommented:
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.
0
BerntAuthor Commented:
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.

{****.......}
;-)
0
LischkeCommented:
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
0
MadshiCommented:
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.
0
MadshiCommented:
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."
0
MadshiCommented:
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.
0
LischkeCommented:
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
0
BerntAuthor Commented:
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, PChar('#35'));
@FFreeLibrary16 := GetProcAddress(FDLLHandle, PChar('#36'));
@FGetProcAddress16 := GetProcAddress(FDLLHandle, PChar('#37'));

Seems that this was not easy at all. I give it one more shot and increase the point, maybe is a million point issue;-).
0
MadshiCommented:
Well, Bernt, as I said, I do have code. Simply give me your eMail address. If you don't like to post it here, write to

madshi@gmx.net

Mike, well, that's quite bad with the character restrictions...  :-((  The old EE accepted all that crap.
Ehhm... What is it, that works beautifully now?  :-)

Regards, Madshi.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
LischkeCommented:
I meant the API hook stuff under Win9x and WinNT.
0
MadshiCommented:
Ah...  :-)
0
BerntAuthor Commented:
Madshi
Date: Thursday, November 18 1999 - 07:20AM  
---

Ahh, was a bit lost in this end...
my email: levin@ulricehamn.mail.telia.com

a http if you have nothin to do:
http://w1.321.telia.com/~u32102551/
0
BerntAuthor Commented:
Code sent to me as email, coolness...
Experts Exchange, check your character translation for posting code!!!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Delphi

From novice to tech pro — start learning today.