TechECE

Should I ask what prg langunage? What kind of dll is that - Win32 or COM?

If it's a Win32 dll, you need to load/import the library first. Also, check if your code uses any fn/variables that requires referencing any lib/header files (static linking thou)!!

If it's a COM dll, you need to do lot of stuffs before calling those functions?!

 

no machi it is not COM dll. It is in an OS platform specific to STB. But, i am talking in general terms.
Even in case of having some library headers, u again say only the declarations. While linking, will not ask for definition? or i am going wrong somewhere ??

 

You could get such linker errors even when u try including dlls (Win32 not COM) compiled with different compilers!!

If u r using a Win32 C-library in C++, then u have to declare extern "C" (to avoid name-mangling done by Cpp compilers to support fn overloading)!! But, i am sure that ur error doesn't fall into this category (inferring from the error message in ur post).

 

Moms, Iam not sure if you are looking for an answer like this.

In general, there are two types of linking da...

1) Static - Use header files and the lib files (in VC++ u have include and libs section) for the same. Header files help u to know what fns it has and the lib files contain the code.

2) Dynamic - You just call loadlibrary of the dll, then getprocAddress of the functions and call them. In this case, it is not necessary to ref any of the libs/header files.

 

machi i am also aware only 2 ways which u said.
this is somewhere in the middle. there is a fn in the dll and u try to call in the exe. So, when linking ur code to get the exe, it is saying there is undefined symbol and this too is warning in my case which means that my exe is ready.
May be it is compiler dependent. one compiler believes the coder that this guy is probably using some fn. in dll.
another compiler throws error saying undefined symbol.
am i rite??

 

Cool... I got the picture. In my prev project, we normally get n number of such warnings. Traditionally people don't care abt those warnings. It may be bcoz of trivial reasons... like few compilers enforce strict type checking, ur compiler settings may be different, etc.

Recently, Sunil worked in a porting project that deals with libs, dlls and I remember he posed few qns in the similar lines. He should be a seasoned critic in this context.

 

Ram, this is the funda. be it com or win32 or any dll in general.... say if you have th function int fun(int) defined in your dll, you obviously can't have function calls in your executable since it won't link...what you should do is:
declare a function pointer
int (*ptrfun) (int)
use loadlibrary or whatever api you use to load the dll into memory
use getprocaddress or some api like that which will give you pointer to the function int fun(int) in the dll (after it is loaded)...
assign that pointer to ptrfun

in your code use ptrfun to call the function

 

Got it.

 

What did u get new from Sunil's comment da? I said the same funda before and u said that u know them?!
Isn't Sunil's comment a expansion of the line - " You just call loadlibrary of the dll, then getprocAddress of the functions and call them."?!

 

I was expecting something different. something which i didn't imagine. but it isn't. thats the point i got.

 

@ Sunil: In case of COM, u cannot straight get the proc address and call the fns. u need to do ref counting et al before that (QueryInterface)?! u could get the interface ptr only thru a queryinterface.
In any case, u need to route ur calls via the interface ptr and cannot call the fns directly (the get proc way?!)?!

 

correct me if i'm wrong:

from dll perspective all the functions that are exported are available through your get proc address.

in com your implementation is in a way that you will export queryinterface and couple of other functions. The rest are objects and methods. Since there is no way to expose an object via dll (as dll concept is built around functions), you get the pointer through queryinterface function.

COM is just a specification (of course made a standard) and how you implement it is dictated by the rules and limitations of a dll. I hope you get what I'm saying. I'm talking from the perspective of dlls and dont care about what the functions do.

 

Cool da...i agree that the COM libraries should inturn call getprocaddress to get the fn address.

Generally, we tend to use Abstract-Factory pattern (defacto standard), so we call CreateInstance (of the factory class) which inturn should call the getprocAdd.

But since it returns the interface pointer, should we use getprocAdd to call the interface methods? I think we don't?! In other words, it is necessary to call getprocadd only for global methods (C-style APIs). Though we export the interface methods (dll export), we don't call getprocadd but rather we call them by interface pointer?!

Am I wrong somewhere?!

 

i was slightly wrong abt the exports (.def file) da, we export only the "CreateInstance" method.

All other fns (including queryinterface) are available thru interface ptrs where u don't call getproc address.

So, I was rite!! :-)
Check This

 

Let's talk in simple terms.
A library can expose to types of entities. Functions and Data (Objects). A dll by design is meant for exposing functions. The support API on windows is available for getting function address and it enables us to call the function. No standard API exists as I know that exposes data, be it an integer or object. So when you want to share an object like you do in COM or any hypothetical model you can think of, you need to do it throught functions. You need to implement your own functions that gives back pointers to objects or primitive data members.

For COM:
A COM component implements interfaces which means it creates objects matching the abstract class definition. IUnkown is the basic interface that must be implemented which has the function QueryInterface. QueryInterface can return pointers to objects of other interfaces supported by the component. But to expose the IUnknown object we use a function QueryInterface. I don't remember te name of the interface but there is one standard interface which we can implement to expose variables by names. And they recommend to use get set functions to read / write a variable and not the pointer.

PS1: I hope my explanation was clear. My previous explanations had been confusing and I decided to rephrase and make it more understandable.
PS2: Any guesses why they don't return pointers to data in a dll? And they advise us to do it through get / set function?

 

1) Agreed!! My argument was fns in COM dll can't be called the same way, thou the same dll funda holds true. I hope u remember there are other ways of creating COM objects using ProgID? CreateInstance("ProgID")??!! This doesn't hold good for win32 dlls. From the obj u could call the COM fns.

2) "there is one standard interface which we can implement to expose variables by names" - Do you want to call it IDispatch interface (IDispatch + IUnknow = Dual interface)?

3) PS2: I am not sure if there is such a standard? I know lots of projects where the dll fns return pointers ?! Returning pointers would pose problems only when it crosses process boundaries (marshalling issues). In case of dll, it is inproc, so can't think of anything straight away?!

 

2) I didn't read ur question properly, IDispatch = interface for scripting languages. Since they don't have VTable structures, you use fn names and get their dispIDs and then call using the dispID.
But, i am not aware of the interface that is used to expose variables by name?!!