Calling API functions dynamically?

  • Thread starter Thread starter Usenet User
  • Start date Start date
Karl E. Peterson said:
You seem quite confused. But then again, what else is new?

I was only attempting to help you view what you saw to be off-limits.

No moral or technical judgements were offered.

Sorry karl, I didn't look at the link. Going by the sh1t you've been posting
lately I just assumed it was another one of your insults.

Michael
 
mr_unreliable said:
Right. But microsoft's advice in this situation is to
allocate memory with both data and execute privileges
turned on, and put your assembly in that.

Fortunately, this is not hard to do, and with that
modification Arkadiy Olovyannikov's code will work
successfully on xp -- even with dep turned on --
until microsoft comes up with some other hurdle
to jump over.

From memory I think Matt's code handled this issue.

Michael
 
Michael said:
Sorry karl, I didn't look at the link. Going by the sh1t you've been
posting lately I just assumed it was another one of your insults.

I see no need to be redundant. You "speak for" yourself quite clearly.
 
I can think of two ways:

a) Build and use a standard DLL (C(++)) which redirects the function call
to the respective DLL.

That's what I ended up doing. So far so good.
b) Add a declare statement with a - more or less :-) - unique library file
name. Then, before calling the library function, make a copy of the
original library and name it with this unique file name. The copy of the
library of course has to be located somewhere where the OS can find it.

Was thinking of this, but decided no to pursue this path...

Thanks!
 
Why would you do this? Are you trying to create some sort of "plugin"
architecture? Do you have control over the .dll you are trying to call
or are they 3rd party?

Yes, we have a bunch of DLL from different vendors that implement the
same methods.
Perhaps you could create a single class in which you pass the name of
the .dll as a string and then inside the class, call the api method
based on that string.

Well, I am not quite sure what you have in mind. I would still need a
static Declare with the hardcoded DLL name. No?

Thanks!
 
If your dlls have the same name but diff dir just use LoadLibrary and
FreeLibrary with the standard vb6 declare, eg

Declare Function Whatever Lib "MyDLL" ....
Sub DoIt()
lib = LoadLibrary("C:\abc\MyDll.dll")
WhatEver(....)
FreeLibrary(lib)
End Sub

because a library of name MyDLL is already loaded vb6 will just use that.
Just make sure you match the no of loadlib calls with freelib and don't call
your function without calling LoadLibrary at least once somewhere in code.

Well, the names are different, unfortunately. Also, I'm talking about
VB.NET (i.e., read - CLR), not VB6.

Thank you!
 
mr_unreliable said:
Right. But microsoft's advice in this situation is to
allocate memory with both data and execute privileges
turned on, and put your assembly in that.

Where can I find this advice?
How is this done in VB6?
Fortunately, this is not hard to do, and with that
modification Arkadiy Olovyannikov's code will work
successfully on xp -- even with dep turned on --
until microsoft comes up with some other hurdle
to jump over.

Any chance of showing us how this is done?
 
Usenet User said:
Well, the names are different, unfortunately. Also, I'm talking about
VB.NET (i.e., read - CLR), not VB6.

Then you aren't talking about VB no matter how misleadingly MS has named
their product
 
Michael C said:
From memory I think Matt's code handled this issue.

It does if you use the C++ VBoost helper DLL but doesn't if you want avoid
that and use the bas module instead. Problem with the VBoost DLL is that it
doesn't load in a COM+ environment. I was able to circument this issue by
using some loader code.

Sadly the loader code used CallFunction techniques which lands us right back
into DEP problems anyway.
 
Michael said:
Sorry karl, I didn't look at the link. Going by the sh1t you've been posting
lately I just assumed it was another one of your insults.



Best kettle pointer I've dereferenced all day. Nice job, pot.
 
Usenet User,
In addition to all the other comments, you should be able to use LoadLibrary
& GetProcAddress. The "trick" is converting the IntPtr that GetProcAddress
returns to a Delegate.

Luckily In .NET 2.0 the System.Runtime.InterpoServices.Marshal class has a
GetDelegateForFunctionPointer method that will convert the IntPtr to a
Delegate.

http://msdn2.microsoft.com/en-us/library/zdx6dyyh(vs.80).aspx

For an example of how to use the above see:
http://www.pinvoke.net/default.aspx/kernel32/GetProcAddress.html

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|I need to be able to call the same API function from VB, which will
| reside in different DLLs. While all of the functions have the same
| signature and name, DLL file names are not known at compile time.
| Therefore, my assumption that using Declare statement or DllImport
| attribute is NOT an option in such a case.
|
| I can use LoadLibrary() and GetProcAddress() from Kernel32 to get the
| addreses, but is there a way to actually call an API method by its
| address from VB? Or can anyone suggest anything else?
|
| TIA!
 
¤ ¤ > Well, the names are different, unfortunately. Also, I'm talking about
¤ > VB.NET (i.e., read - CLR), not VB6.
¤
¤ Then you aren't talking about VB no matter how misleadingly MS has named
¤ their product

It's certainly not VB 6.0, no, despite the fact that it still uses a version of the BASIC language.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
Funny *you* should say that bob. Still think With is faster?

Michael

He would not be alone.
Letting VB have to follow a long list of
"Thing.anotherThing.yetAnotherThing." waste time cycles that can be
replaced with one With./ end With.

Besides, it does make for clearer code, no ?
 
bitshifter said:
He would not be alone.
Letting VB have to follow a long list of
"Thing.anotherThing.yetAnotherThing." waste time cycles that can be
replaced with one With./ end With.

Here we go again :-) This is a myth. With is *not* faster. This has been
discussed at length here and many tried to prove me wrong but no one could.
Bob in particular tried very hard but once he realised I was correct went
very quiet. Try this code: http://mikesdriveway.com/misc/with.zip
Besides, it does make for clearer code, no ?

No, it's ugly imo. In very rare cases it could be ok, eg:

With A.B.C.D.MyControl
.Width = 100
.Height = 100
.Text = "ABC"
etc
End with

but what happens when you need to add some code to calculate width, height
and text, do you delete the with block or just stick this code inside it?

Michael
 
Back
Top