Well, i'm a beginner too, and i believe i've understood the basic of programming, but this is one topic that i haven't yet (and i've not found documentation on the web). From what those ".lib"s are built? If they are built from the ".dll"s , why the link could not just get this kind of 'information' directly from the ".dll"s.
Posted on 2001-01-24 12:36:00 by zedd
Libraries come in two flavors: static linked, and dynamically linked. Dynamic linking is our old friend the dll. It's a compiled nad linked module of code. A library for static linking is one step back. It is compiled code, but it is not linked. ML.exe generates objects, and the library manager lib.exe can take one or more of these objects and place them in a .lib file. When your program is being linked, if you specfied a lib file, the linker will look there for any unsatisfied references, be they procedures, data variables, etc. Then this code is extracted from the lib and added into your .exe. You can generate your own libs like so: \masm32\bin\ml /nologo /c /coff *.asm \masm32\bin\lib *.obj /out:%1.lib Anything you wish to export from this lib must be marked PUBLIC (data or procedures), anything data the lib needs from the outside must be marked exterdef with name and data size. Dynamic linking shares code while keeping it seperate, linking it at run time. Static linking shares code at compile (link) time, making a larger (but hopefully faster) .exe.
Posted on 2001-01-24 13:43:00 by Ernie
If the MS linker is used to generate the .LIB file, the information comes from a maximum of three sources: 1) a .DEF file, 2) the command line arguments, and 3) the .OBJ files used to build a DLL. In normal development mode, the .LIB file is generated at the same time as the DLL. From the point of view of developing a DLL, building the .LIB file AFTER the DLL is made...that's an extra step.
Posted on 2001-01-24 18:37:00 by tank