one last ? on dll's

[Sam111]

Ok , most of the win32 api is in a dll and most of the functions MFC are in dll's basically any , alot of microsoft function is in some dll....etc

So why do you not have to do a loadlibrary call each time you access the function.

Seems as though if you have compiled your program with the lib file for that dll. It must add the equivalent to your code that loadlibrary /getprocess ,...etc do.

Correct me if I am wrong if you don't have a .lib file for the .dll then the only way to call the dll's functions is thru a loadlibrary /getprocess type of deal.

If that is true what is the .lib file putting in the .exe file so it knows which .dll it is going to load automatically.


Question 2
if your on a linux machine you only have .so (instead of .dll ,lib ,exp ,def). Can you call functions in .so without using a loadlibrary /getprocess statements....?

Basically I know I can just use a static linking .a archive file of .o files but I was wondering
if their is an equivalent to what .lib does in windows on linux.
Thanks

[fronty]

Linking can happen on compile time, load time or run time. Archives and single object files are linked on compile time, shared objects can be linked on load time or run time. From program's point of view it doesn't matter if something is linked compile or load time.

I can't say anything sure about Windows, but it wouldn't make any sense to me if you had to have archive to use shared object.

[Sam111]

no what I am saying is.

If you have a dll and not the .lib file associated with it then you must use loadlibrary ,...etc to call functions in it at runtime.

I wanted to know if you can link in functions from a library at compile time. I think .lib allows you to do this since I never have to use a loadlibrary call to use a dll function provided I include the header file and include the .lib file to the linker libs path.

With .so since their is no equivalent .lib file you can only use these functions with a loadlibrary statement at runtime.

correct me if I am wrong

[NickJohnson]

ELF shared libraries (.so) are almost exclusively loaded at load time, so you don't need anything special in the code to make them work. On Linux at least, the loading of shared libraries is done by ld-linux.so, the system loader, before main() is run. AFAIK, you can't statically link shared libraries to executables on an ELF system, only prefer static (.a) libraries using -static, but I don't have much experience with ELF shared libraries; the same may or may not apply to Windows/PE.

Edit: also, please don't use colors!

Also also, this may be useful: http://www.linux.org/docs/ldp/howto/Pro ... aries.html
Also also also, "foo's" != "foos"; one is possessive, one is plural.

[gerryg400]

I wanted to know if you can link in functions from a library at compile time. I think .lib allows you to do this since I never have to use a loadlibrary call to use a dll function provided I include the header file and include the .lib file to the linker libs path.

There are articles, including some at msdn for creating .lib files from just dll files. And there are tools available for converting dll files to static .lib files.

[fronty]

If you have a dll and not the .lib file associated with it then you must use loadlibrary ,...etc to call functions in it at runtime.

I wanted to know if you can link in functions from a library at compile time. I think .lib allows you to do this since I never have to use a loadlibrary call to use a dll function provided I include the header file and include the .lib file to the linker libs path.

Could you post link to some documentation about this? This seems so rediculous to me that I want to read official docs about this.

With .so since their is no equivalent .lib file you can only use these functions with a loadlibrary statement at runtime.

You are completely wrong. Shared objects are mostly linked on load time. Of course there is POSIX API for dynamic linker (dlfcn.h) for linking on run time, but it is used very rarely, for things like plugin system.

Example: Sun removed all archives from Solaris 10. If your statement was true, you couldn't use any functions from system libraries without going through dlsym et. al. Oh, those come from system libraries too, so you can't call them. That means every program should have own statically linked implementation of the API.

I repeat myself: For programs point of view in normal cases shared object and archive are not different. You can call normally functions from both type sof libraries.

[Sam111]

no still not what I mean.
I know how to create lib's ,...etc
I want to know if given a dll. I know I can use loadlibrary/getprocess ,...etc to call the functions inside the dll. I was wondering why I don't have to use them for the win32 function
Like when I include windows.h aren't those functions in a dll somewhere? If they are why is it that I don't have to use loadlibrary ,...etc to call these functions. Seems though the compiler automatically puts in the code for me.
I want to know how the compiler/linker knows how to do this from the standard dll's but if you want to call a random function in some dll you have to load it at run time.

Would it be different if I took a random dll and created a lib for it. Then could I not use loadlibrary and just link it at compile/link time instead???

[Hangin10]

The compiler is set up to know what LIB files are necessary for typical programs on a given platform.
So I guess the answer to your question is yes that's the whole point of a .LIB file.

Also, some compilers (ie microsoft's) provide non-standard in-code methods of telling the compiler a particular library
is required (IIRC #pragma lib). In that particular case, I find it odd that windows.h doesn't at least do this for
kernel32 and user32.

There's nothing automatical about the standard windows DLLs.

fronty:
On Windows, it seems you don't link with the dynamic library (the DLL file) directly. The compiler
insists on having a library file. Often the static one has the letter 's' appended to the name so you
know it is the static library. I actually had trouble building Boost today, as the install step wouldn't
copy the static libs to the build directory even though they had, in fact, been built.

[Sam111]

ok , so you need the library lib files for a given dll in order not to use loadlibrary functions/ at runtime stuff.
I think we are all in agreement here.

But it is not true that you need the lib files if you are going to use loadlibrary...etc at runtime for a random dll.

And you can always create the lib file for the dll after the fact. Correct me if I am wrong.
Given a random dll their is aways a way to generate it's lib file ....etc

Thanks this is a major help

[Gigasoft]

When you use LoadLibrary, no import library (.lib) is needed.

To create an import library for an existing DLL, using Visual Studio, you first need to create a .def file. Here's an example:

Code: Select all

LIBRARY mydll
EXPORTS
MyFunction1
MyFunction2
MyFunction3

If the names of the exported symbols don't correspond to the calling convention used, you must create an .obj file that defines. For example, if MyFunction3 uses the __stdcall convention and takes 3 arguments, compile the following so that you have an .obj file that defines _MyFunction3@12.

Code: Select all

void __stdcall MyFunction3(int arg1,int arg2,int arg3)
{
}

Then run the following command:
LIB /DEF:deffile.def /OUT:library.lib objfile.obj