Page 1 of 1

Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 1:03 am
by oldefoxx
I'm not here to preach on this subject. Rather, I am here to listen and read. I'm
finding this area particularly challenging, because it is nothing like I have used
before. That doesn't make it a bad thing, just hugely different. Help is requested.

I will say this. The Windows APIs are housed in DLLs, so being able to call them if
in Windows is vastly important if you intend to really go the Windows way.

The "D" in DLL stands for "Dynamic". Windows determines when and which DLLs to
load depending upon the current demand, this coming from the current programs
that are running.

That being said, the door is open for someone else to take the podium. Oh, I do
have a few links to share on the subject before I step down:

http://www.purebasic.com/documentation/ ... index.html
http://www.purebasic.com/documentation/ ... brary.html
http://www.purebasic.com/documentation/ ... types.html
http://www.purebasic.com/documentation/ ... brary.html
http://www.purebasic.com/documentation/ ... aryid.html
http://www.purebasic.com/documentation/ ... tions.html
http://www.purebasic.com/documentation/ ... tions.html
http://www.purebasic.com/documentation/ ... ction.html
http://www.purebasic.com/documentation/ ... nname.html
http://www.purebasic.com/documentation/ ... dress.html
http://www.purebasic.com/documentation/ ... nction.html
http://www.purebasic.com/documentation/ ... entry.html
http://www.purebasic.com/documentation/ ... nfast.html
http://www.purebasic.com/documentation/ ... nfast.html
http://www.purebasic.com/documentation/ ... brary.html

I think I got them all, and hopefully in the right order. It seems a bit complicated at
the onset. There is some embedded code to help, but it would be nice to know what
works for others.

Okay. Here are some I was not aware of at the time:
http://www.purebasic.com/documentation/ ... mport.html
http://implib.sourceforge.net/EN.HTM
http://www.purebasic.com/documentation/xml/index.html

For closure to this particular post, I think I will mention that the difference in the Standard
Call process and the C call process is the order in which the calling parameters are passed on
the stack. For one, it is right to left, or top to bottom. For the other, it is left to right, or
bottom to top. Make the wrong call, and you have the right parameters, just in the wrong
order.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 3:19 am
by jack
you can call a dll's functions using prototypes or you can use import, you can also use the dll importer that's included in the PB SDK.
here are some links giving examples on how call a dll function using prototype and import, remember Import is used for stdcall and ImportC for cdecl.

http://www.purebasic.fr/english/viewtop ... penlibrary
http://www.purebasic.fr/english/viewtop ... penlibrary
http://www.purebasic.fr/english/viewtop ... it=importc

look in the PureBasic SDK DLLImporter for an example on it's use

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 4:47 am
by oldefoxx
Thanks. that added information is much appreciated. My goal is to take a handful of
some of the APIs and rope them into PureBasic, but I am real shaky on how to go at
it. I will do with the examples in the Help file, but that only gets me so far. Microsoft
makes use of structures in lots of cases, which means passing pointers. I have the idea
down, but how it plays with PureBasic is mostly speculation right now.

What I was thinking when I started this thread was that there are likely others that are
as unsure as I am. I pulled most of the documentation together by links to serve as a
starting point, and you just provided some more. Some people will have been down
this road before, and others may be thinking of following the thread to see where it
leads. No matter. What I hope it does is serve to help everybody that is interested.

Interesting thing about PureBasic is it intense focus on doing things by functions. I like
it, having been exposed to it a bit now. You write your own Procedures, and it is almost
like you are extending the language because it blends right in. Can't argue with that.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 5:04 am
by oldefoxx
jack wrote: look in the PureBasic SDK DLLImporter for an example on it's use
I'm sorry, I am not sure where you are directing me to look. I've found no reference
to the PureBasic SDK DLLImporter. Could you be a bit more specific?

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 5:23 am
by oldefoxx
Okay, let's see if I have this much down right or not. You begin with an OpenLibary(),
then you can check out the functions in it and call them as you need to in your
program. If you use more than one library (say Kernel32.dll and User32.dll), you have
them both open and you have two different LibraryIDs, one for each. As long as you
are calling functions from one of the libraries, that library has to remain open. When
you are finished with the functions in a library, you can use CloseLibrary() to close it.
If you aren't sure you are through with a library, you only close it when your program
is ready to end. Now is this correct? Can't quite be sure from the writeups.

What I am doing here is comparing the library process with a process of working with
a file. There seems to be quite a few similarities in how you go at it. They aren't
identical, of course, but not that far apart in some ways either.

I also gather that prototype is the newer way of doing some things, and validates the
number and type of passed parameters. That ought to be good, but I've been leary of
the term "prototype" for a long time. Prototype in my mind is an untested concept that
predates what you hope will come to pass. Tell me I am wrong, and I will try to learn
to accept the name.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 5:37 am
by IdeasVacuum
It's in the PB install path, so something like: C:\Program Files\PureBasic461\SDK\DLL Importer

Note, a lot of the Windows API is supported directly by PB, there is nothing extra to load or reference, just enter the API command followed by an underscore.

For example, RegOpenKeyEx http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Code: Select all

Procedure OpenRegKey(iOpenKey.i, sSubKey.s, iFlags.i)
;----------------------------------------------------
       iResult = RegOpenKeyEx_(iOpenKey, sSubKey, 0, iFlags, @handle)
    If iResult = #ERROR_SUCCESS

                 ProcedureReturn handle
    EndIf

EndProcedure
Many API Structures are also supported and therefore do not have to be defined/declared.

For example INPUT http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Code: Select all

Global EscKeyDown.INPUT
       EscKeyDown\type = #INPUT_KEYBOARD
       EscKeyDown\ki\wVk = #VK_ESCAPE & 32768
       EscKeyDown\ki\dwFlags = 0 ;key down
       EscKeyDown\ki\time = 1
       ;EscKeyDown\ki\dwExtraInfo = 0

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 5:51 am
by Josh
Omg, the next spam thread from oldefoxx. What shell we do with this linklist? Everybody can find it easily in the PB help.
  • Do you have a concrete question to DLL's? Then please post it in less words in 'Coding Questions'
  • Do you habe a concrete question to Windows API's? Then pleasw post in less words in the OS specific forum 'Windows'
Otherwise please spare us with your excursus. And no, we also don't need a discussion thread about ASM, Power Basic, etc.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 6:33 am
by IdeasVacuum
There is an easy to follow OpenLibrary() example in the help: http://www.purebasic.com/documentation/ ... ry.pb.html

Note that the Windows example is calling a MessageBox, which you do not need for your real-world code as PB already has a function for that, MessageRequester()

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 3:22 pm
by Demivec
oldefoxx wrote:I also gather that prototype is the newer way of doing some things, and validates the number and type of passed parameters. That ought to be good, but I've been leary of the term "prototype" for a long time. Prototype in my mind is an untested concept that predates what you hope will come to pass. Tell me I am wrong, and I will try to learn to accept the name.
Another way to think of a prototype is that it is a "procedure type" or "function template".

The prototype describes the parameters and return value that are part of a function call, the only thing that is still needed is the address of a specific function. The address is stored in a variable that is declared to be of the named prototype using the same '.' notation as when declaring structured types.

The address of a function in a DLL can be obtained with OpenLibrary() and GetFunction(). Even though you are asking specifically about external libraries, the address could instead be of a procedure defined in the program's local source code (i.e. using the Procedure or ProcedureC keywords). Once the address of a valid function is assigned to the "prototyped" variable then it can be used to call the function with any necessary parameters.

Note prototypes also come in two flavors depending on a function's calling convention: Prototype and PrototypeC.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 8:10 pm
by oldefoxx
Wow, a ton of specific information and all on subject. This I like. With the execption
of one posting, of course.

Anyway, having pondered the matter a bit, I went looking online for something
related to Windows Libraries. I found this handy link:
http://en.wikipedia.org/wiki/Microsoft_ ... rary_files.
It gets right into identifying the DLL and Runtime libraries related to Windows.

I'm no expert at this (obviously), but this is my understanding of the nature of things:
You can lump external routines (subs and functions, or Procedures as they are known
under PureBasic) into five general groups, and this is listing them pretty much in the
order that they became established: BINary, OBJect, [static] LIBraries, Runtimes, and
Dyamic-Linked-Libraries (DLLs). Everything except BINary follows constructive rules
specific to that library type, and for Windows, these rules were set forth by Microsoft.

Now Binary libraries were the responsibility of the individual programmer to work with,
and were usually the result of ASM or Hex-coded low level programming. OBJ and LIB
files followed structuring rules and could come from many sources, and were actually
linked (made part of the final file) by a separate LINK program.

Runtimes were where certain computer languages (Visual C, Visual BASIC, etc.)
automatically called up the appropriate Runtime to access language-related functions
and subs needed by the programs they had created when the programs were run.

DLLs became an extension of the Runtime concept across a broad range of functions and
subs that became the Windows APIs, or Applications Programming Interfaces. A link
that may provide more insight: http://en.wikipedia.org/wiki/Windows_API.

While the focus is generally on the DLLs available today, some people still make use of the
other forms of libraries as they go about their business. It is just a question of what works
for you.

Having tried to make that clear before going forward, there is a question that I have:
Is there a breakdown somewhere of all the API calls that are incorporated into PureBasic
that can be accessed just by appending an underscore after the name? Or do I have to
play around and find out for myself?

My mistake, You were referring to structures that are already incorporated into PureBasic.
There is a lot going on and choosing which way to go is becoming a challenge. It's my job
to try and make sense of all this. I'm not doing very well at it so far.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Sep 28, 2012 10:51 pm
by oldefoxx
oldefoxx wrote:Runtimes were where certain computer languages (Visual C, Visual BASIC, etc.)
automatically called up the appropriate Runtime to access language-related functions
and subs needed by the programs they had created when the programs were run.

DLLs became an extension of the Runtime concept across a broad range of functions and
subs that became the Windows APIs, or Applications Programming Interfaces. A link
that may provide more insight: http://en.wikipedia.org/wiki/Windows_API.
The ImpLib SDK Guide also mentioned being able to access and use the C Runtime library.
I've wondered about the Runtime libraries, thinking that they should be usable independent
of the high level language which is based on them. This is the first reference I've come
across to this possibility. The Guide goes on to explain the advantages that might be involved.

The Guide also goes a bit into "stripping" out the specific functions you want to use from a DLL,
a process that can save some memory and time, and make the resulting program more
efficient. I think the "thunk" term is related to any portion of the initial DLL that you are
not going to use, because it is superflous to the needs of your program.

I just uncovered a download link related to ImpLib: http://implib.sourceforge.net/
Another one: http://sourceforge.net/projects/implib/ ... 20Release/

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Tue Oct 02, 2012 1:06 am
by blueb
oldefoxx wrote:....

there is a question that I have:
Is there a breakdown somewhere of all the API calls that are incorporated into PureBasic
that can be accessed just by appending an underscore after the name? Or do I have to
play around and find out for myself?
You might look in: \PureBasic\Compilers\ for a file named: APIFunctionListing.txt

I believe it contains all the Windows API calls that you can use directly with an underscore.
(Wow! 7250 functions)

Of course, it's your job to apply the correct parameters to each function call.

Re: Calling External Functions in DLLs, LIBs, and OBJs

Posted: Fri Oct 12, 2012 1:22 am
by void
blueb wrote:Of course, it's your job to apply the correct parameters to each function call.
That's what MSDN is for. :)