How to create .lib and .dll files from a .h & .cpp file in VC++6 from the same project workspace ?

You will have to create a new project and then in the "Properties" section select either "Static Library" (for just a .lib) or "Dynamic Library" (for a .lib and .dll). Then add all the files and build it.

I use VC++ 2003 but I bet it's the same.

Anyone how to do it in VC6 without having to create a separate "win32 Static Library", "win32 dynamic link library" projects ?

Also can I use the .lib & .dll created using VC6 with VC++.NET ?

Quote:Original post by dimensionX
Anyone how to do it in VC6 without having to create a separate "win32 Static Library", "win32 dynamic link library" projects ?

By creating a .DLL project, you will make the .DLL and the .LIB, so you do not need to create the static library at all. Just make a new project in VC6 and choose for it to be a Dynamic Link Library. That's it

Quote:Also can I use the .lib & .dll created using VC6 with VC++.NET ?

No. You will need to recompile the library using VC++.net in order to link and run the code properly in that compiler.

what is the difference between .dll and .lib?

a static library (lib) is essentialy the compiled code with a small built in header telling the linker what to do. a dll is a dynamicaly loadable "module", which essentialy is loaded into the memory space, a little above, can be loaded/unloaded if you want (using loadlibrary), etc. Most dlls come with static librarys to link up to which contains the addresses to code in the dll, allowing you to use C++ name mangling in your DLL, and making loadlibrary calls and function prototyping for the library unnecessary.

the libraries may or may not work together, this particularly has to do with how they interact. understand that the compiled version of a dynamic library relies on a particular version of the msvc library to run. for instance the one shipped with VCexpress is MSVCR80.dll, and i believe MSVCR60.dll is for the 6.0 compiler (I dont remember though , sometimes they switch around their naming conventions). The reason it may not work is that the dll will run in the address space of the runtime it was built with, while your application would run in its. This is the same as having incompatable build types though (multi-thread dll combined with single thread would have identical behavior). If you are not using pointers, and only passing by value, it MAY work. You should be able to completly avert the problem by not creating pointers that you pass to the library, or visa-versa. For instance, some method of creating handlers. I have done this on a previous project before.

EDIT:

in visual studio you can use either dll definition files (I forget the name for these) , specifying the C or mangled name, cardnal, etc. or you can use the __declspec<dllimport> and declspec<dllexport> attached to the function prototypes to work with your DLL. Commonly you will want a switch in your global header file that will allow you to simply switch a single variable for compiling a dll or using it, as you must explictly tell the function prototypes whether they are importing and exporting.

SORRY FOR THE GENERAL RAMBLING, this is a topic that requires alot of information to really grasp, its best to find some tutorials, so please dont flame :).

thanks,
Richard

Quote:Original post by Anonymous Poster
what is the difference between .dll and .lib?

I'd also like to point out that there are 2 types of .lib files.

The first type which is a static library is what PaulCesar has described, a library with all the code compiled in.

The second type is the library that serves as a "prototype" for a dynamic linked library.

The only differnce between the two is that the lib file for a .dll does not contain the implementation of the functions, the .DLL does. Whereas the .lib in a static linked library does contain all the implementations.

actualy I did mention that aswell, in that garbled mess in the first paragraph.

As yes, sorry about that, I'm just tired I just missed it like I missed the main point in this thread [wink]

Quite fine drew! Your post made alot more sense then mine did, i just wanted to clairfy amoung the points that it is possiable to use them between compilers moreso (so long as you pay attention to details involving the creation of memory on the heap). Its a point many programmers dismiss, and caught my attention quickly.

the law:
each RUNTIME has its own heap. the heap your program uses is managed by the runtime that you link with. the heap for a dll is managed by the runtime that IT links with. if you link with the same runtime, all is well, as they will safely use the same heap. if you link with a seperate runtime, they will run on seperate heaps. keep that in mind.

edit: stack=heap in the first paragraph.

[Edited by - PaulCesar on September 9, 2005 4:26:17 PM]