import libraries versus static libraries

[Shantanu Gadgil]

Hi hutch,
I have searched the forums a lot before finally posting it here.

The question is of import libraries versus static libraries.

Wanted to clarify if what I have understood is correct!!! (if I have understood anything AT ALL) :(

Here goes...

####
----
Import Library:
Will contain (suitable word like "pointer" or "reference" :) ) to the ACTUAL function call (in a DLL).
The EXE, when run, will request this function to be called, which Windows will supply from the specific DLL.

Static Library:
Will contain ACTUAL CODE of the function, so when linked with static library the EXE will contain the ACTUAL code too!
Hence, this will NOT require the SPECIFIC DLL on the target machine (a bit hazy on this one?, mostly I am wrong here :))

---
This confusion has arose after trying to link .obj created with VC2003 using VS.NET2005's linker (and obviously NOT succeeding at that) !!! Most likely I have muddled up mny different issues here!!!

What about the static libraries which ship with a compiler distro (VC++6.0 or latest version of he Platform SDK)

also...what is the msvcrt... thing, why do we never require that in our masm32 code? What exactly happens? :( :(

[zooba]

You are spot on with your definitions of import and static libraries :U Though I will note that static libraries don't actually have a matching DLL (unless the same code is distributed as a DLL which would come with it's own import library)

AFAIK, you shouldn't have any problems linking an object file between those two versions.

MSVCRT (which stands for Microsoft Visual C Runtime) is a library which ships with MS VC which contains a whole lot of useful functions (for dealing with strings and stuff). You don't need to use it (I don't think you even need to use it in C if you don't want to) but it will mean either writing your own code or using another library. There are quite a few examples here where people use MSVCRT but really it doesn't affect how you code.

Hope that helps, :U

Zooba

[hutch--]

shantanu,

The rough distinction between the two is an import library is there to tell the linker what DLL is used and if the required function is in the DLL. A static library is as you have said, a library made up of modules that contain code. The masm32 library is a normal STATIC library made of asm modules.

MSVCRT is a DLL that is found on almost all 32 bit Windows OS versions, it was an add iin on very early versions. The approach taken with the masm32 project was to produce an import library and an include file that used the EXTERNDEF format so that the name to call a MSVCRT function would not clash with some of the reserve words on masm32 and masm itself thus the "crt_" prefix on the names to be used.

[Mark Jones]

That CRT__ issue is very annoying. Usually I end up deleting the functions which use CRT__ and re-write them to work without the C runtime libs. Seems everyone has a different msvcrt.inc and .def also... :eek

[hutch--]

 :bg

I can't help you with what "everyone" does, the versions of MSVCRT lib and INC I supply in masm32 and in postings here work fine and you can use the functions that name clash with masm reserve words as well.

[Shantanu Gadgil]

zooba:
...that static libraries don't actually have a matching DLL (unless the same code is distributed as a DLL which would come with it's own import library

Thanks! Understood!!! The static .lib file will have ALL the code! :)

hutch:
went through the msvcrt.inc :) I presume, it will give us the functions which are listed under the "LOCATION" called "Visual C++ Programmer's Guide" (strcpy, strcat, etc)

(one more verification of clarification :) :) )
the msvcrt would be equivalent to the very old (TurboC (DOS) libraries) which gave us stuff like "strcpy", "strcat", etc (after including "string.h" of course) :)

I guess, I have it nailed down now !!!
Thanks !!!

One more thing...
I don't understand the Mark Jones' point about "Usually I end up deleting the functions which use CRT__ ..."

As long as there is a "msvcrt.dll" (or some other version msvcrt40.dll, etc) on the target machine, including "msvcrt.inc" and using "crt_strcpy" for Windows' "strcpy" should work, right ???

[Mark Jones]

I don't understand the Mark Jones' point about "Usually I end up deleting the functions which use CRT__ ..."

As long as there is a "msvcrt.dll" (or some other version msvcrt40.dll, etc) on the target machine, including "msvcrt.inc" and using "crt_strcpy" for Windows' "strcpy" should work, right ???

That's what I thought, but I couldn't compile Petroizki's new timing macros (http://www.masmforum.com/simple/index.php?topic=3724.0) because a few procs used crt__* naming convention. MSVCRT.INC tries to allow many different names for the C runtime procs (___func, __func, _func, func, etc) and AFAIK Huch invented the crt__ prefix to prevent naming conflicts with other functions. And to further complicate matters there are redundant procs inside msvcrt.lib itself... Anyways the problem is almost certainly due to upgrading files like MSVCRT.INC with tools like DLL2INC which apparently had no idea about crt__ pefixing. I suppose MASM32 could be reinstalled, but that isn't going to fix the inherent problems with msvcrt.dll. So, instead of working around all this mess, I simply use other functions. :)

[GregL]

Mark,

Just make sure the msvcrt.inc and msvcrt.lib you are using are the ones that use the 'crt_' prefix and it works great.