lib exe dependence ???

[Sam111]

ok , say I have a dll
questions

1) I know I can call functions in a dll but say I want to compile only the functions I am using in that dll into my program so it is a standalone application. How do I do it , what is the compiler/linker options I needed to use???

Basically how can I convert the functions in a dll not to do dynamic linking but to do static linking i.e copying the functions directly into my program.

2) what is the difference between a regular dll and a multithreaded dll (like the ones used in MFC)
I am just curious about what the difference in their structure's are and how to make a multithereaded dll. If this is just a dll that uses threads then their really isn't any difference between the two other then one having threads in it.

[Gigasoft]

You can't. A DLL does not contain information needed by a linker to extract individual modules.

The multithreaded version of MFC is designed to be reentrant and can be used in a multithreaded application, while the singlethreaded version is not, and assumes that all invocations come from the same thread. That's the difference.

[Sam111]

You can't. A DLL does not contain information needed by a linker to extract individual modules.

Questions 1)
So then their is no way to using functions in a dll and have your program .exe a standalone program. Their is no way you can manual copy in those function you need from the dll you would have to have the source .c .cpp files of all the dll functions used and then recompile into .o files ,...etc etc? Correct me if I am wrong. Then __declspec(dllexport) , __declspec(dllimport) in your code doesn't copy the function into your code it just does the equivalent of loadlibrary functions where it is just a global pointer to a pointer which points at the function in the dll...etc. Their is no microsoft/linux c/c++ keyword that informs the compiler/linker to static link (copy in) functions in a dll instead of dynamic linking ???? Correct me if I am wrong.

Question 2)
Also in visual studio's I have some libraries I link against like glut32.lib glu32.lib opengl32.lib ...etc

I am wondering why I include the .lib files on the include library path but I don't have to include the glut32.dll on the library path? Or why I even have to include the .lib file at all and just include the .dll and use the header file for. Or just use __declspec(dllexport) in my code and include the .dll when linking.

Basically why the need to go thru a .lib file to get the .dll functions?

Alot of things I have noticed on Microsoft machines go thru .lib's to get to the .dll's is this really necessary? On linux you just have .so files to link against , so basically .so takes the place of .lib's and their .dll's all in one.

Curious

[Sam111]

Well , I am trying to find away to use functions in a dll such that when I use them in my program they don't depend on the dll actually being their.

Basically I want to static link (copy in the functions to my program so it doesn't depend on anything outside my program)

I know if these where in a .a archived .o ,.obj files then they are static linked (copied in by the linker)

But I don't have the source code ,.cpp files of the dll functions so I wanted to know if their was away to static link a dll's functions into my code.
Basically if I am interperting you correctly the answer would be NO. Not without have the dll source code and recompiling to .o files then linking into an exe instead of a dll.

As for the need for .lib files.
If I am understanding you correctly it is just because of name mangling ,...etc because in theory I can dumpbin the dll and see what the import/export functions are and then should beable to call them directly by loading the .dll ...etc NOT USING THE LIB FILE AT ALL.

dllimport and dllexport declspecs do the equivalent of .def files except with a def file you can specify the naming symbols and not use the internal name symbols conventions ...etc

And I have been reading alot on the subject.
Just wondering what the point is for a .lib file it really just is a middle man that goes to the dll... so why have it in the first place.
And also wondering about if their was away without the dll source code that you could copy the functions directly into your program so it doesn't have any dependences.

Thats all

And I know that dll , exe files use the same file format they all are .o .obj ,..etc object files (i.e use the object file format) the only difference is at linking time when the linker resolves references , set's entry points ,...etc the structure/principle of these files are all the same just a few tweeks here and their.

[Owen]

First of all - which DLLs? ...

In general, if its distributed only as a dynamic library, there is a reason behind this.

[Sam111]

First of all - which DLLs? ...

In general, if its distributed only as a dynamic library, there is a reason behind this.

Does it matter.
Say I just have a random dll and I want to use some functions in it but I don't want my Application to depend on the dll. I want it to be standalone.

For example if I wanted to take the ntkernel dll's of microsoft and add on to their OS my stuff.
So I want to not go thru newlib ,...etc (which gives you the .cpp files so that you can make a standalone application or binary)
But wanted to use microsofts OS /kernel functions and add on to it in my OS. Or at least use their kernel memory allocator functions in my OS without having to write them from scratch or use open source libraries like newlib...etc

[NickJohnson]

There's really no way you're going to be able to use large pieces of Windows in your OS. It's not like they magically would work even if you could link with them.

[Sam111]

so your telling me their is really only 2 options write stuff from scratch for your os.
Or use open source libraries that don't depend on any dll's and give all the .h , .cpp files so you can recompile/tweek them into your kernel with no dependences. Such as porting newlib.

If that is it then ok to bad though really would have like to copy functions statically from a dll at compiler/linker time and all it's dependences without having the .cpp code files

Thanks for your help in understanding this stuff.

The lib question
Still a little shake on why you need the .lib files when you could directly look up / load the .dll functions using loadlibrary / dumbbin and call them directly thru your program without a .lib file though.
This at least should be possible because I don't see some applications being shipped with a .lib file on the .dll file's.

[NickJohnson]

so your telling me their is really only 2 options write stuff from scratch for your os.
Or use open source libraries that don't depend on any dll's and give all the .h , .cpp files so you can recompile into your kernel with no dependences. Such as porting newlib.

Well, not even that - things like newlib are not designed for use in kernel space. If you want to write a kernel, you pretty much have to write it totally from scratch. There aren't many kernels in the world, and there are effectively no frameworks for building them. For user space (which I expect you haven't gotten to yet since you still believe that you can somehow copy-paste part of Windows' kernel heap into your project), yes: you can either write the C library from scratch or port an open source one.

As for the questions about Windows .lib and .dll files, I suggest you RTFM as previously mentioned.

[gerryg400]

Well, not even that - things like newlib are not designed for use in kernel space.

That's true, it's not designed for kernel space. However, large parts of it can be used in kernel space. Most of the str*, mem* and ctype funcs can be used. The newlib documentation tells you which functions rely on the OS. The parts that you probably shouldn't use are malloc because it's not as efficient for kernel work as a slab allocator and the stdio because it uses malloc and the posix primitives (open, read etc.). Therefore you need your own kprintf and kmalloc.

[Brynet-Inc]

You want to use functions from a (closed source..) dynamic library, something you didn't write, and want to link the resulting executable so it doesn't depend on said dynamic library? attempting to hide the fact you're using it?

It kind of seems like you might be approaching this all wrong, and I can't really understand why you would want to do this.

* Link dynamically.
* Write a replacement, disassemble the function if you must, or find an open source equivalent.

A function in a library might rely on other functions in the library, and other globals, and even symbols from other libraries.

What you're asking for really makes no sense, think about it, laugh a little.. and come back if you really must (..once you've determined what you want).