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. From what this ".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:33:00 by zedd
Hi zedd, This is a very interesting question, I was wondering about it as well.... Since this is quite a sophisticated area and leads to the heart os PE files and linking objects I suggest to learn more about the topic on the following page: http://msdn.microsoft.com/library/techart/msdn_peeringpe.htm This is so far the best explanation I've found about the structure of PE files. It also contains detailed exlpanation for your question. (Take a look at the 'Common sections' and 'PE file imports' paragraphs.) Regards, Bela
Posted on 2001-02-02 12:02:00 by banyos
A lib file is basically just a collection of obj files strung together. It is prefaced with two headers; the first is ignored, the second contains a list of pointers to the various obj records in the file. Library files that are statically linked contain obj files with actual compiler-generated code; the linker accesses the asm code from the object record with the matching function name entry, and packages it into the exe. Many lib files (those created by the VC IDE from a def file, for instance) do not contain actual code, though; instead, the object files in them contain only a function name and an address (RVA) in the exe file. These addresses (relocs) have to be patched by the Windows loader, and only after this is done can the exe actually be run. The loader does this by using the HintNameArray and FirstThunkArray structures to get the information it need to patch in the "actual" addresses of the functions in the loaded dll's. (I've put "actual" in quotes, because there's some system memory-mapping magic involved -- just one dll is loaded for all apps, and the addresses have to be mapped into the address space of each calling process). The best way to understand this is to use a Hex editor to print out the various obj, lib, dll, and exe files from something you've written yourself. Then using your knowledge of the coff obj, lib, and PE formats (documented on the Web, and also in Matt Pietrek's book Windows 95 System Programming Secrets), go through the files with a magic marker, various colored pens, and pencil (so you can erase your mistakes!) and study them carefully. Some people (like me!) find this very interesting. If you have a good debugger, you should also compare the image of the exe in memory (after the loader is done with it) with the original exe; this will show the patches clearly. Hope this little lecture was helpful.
Posted on 2001-02-02 17:47:00 by Xmas
zedd, Libraries are built from modules that you write in asembler and sometimes other languages. If you write a procedure in the right way, you can assemble it into an object module and use the LIB utility to build it into a library. You normally build a collection of object modules into a library. If you are using MASM32, it has an option that calles a small DLL that will write a blank library module so that you can have a look at the format. If you have a look at the m32lib dir in MASM32, it uses a batch file to build the asm files into object modules then runs the LIB utility to build the library. Libraries are very useful and not hard to build so it is worth the effort to learn how to build them. Regards, hutch@pbq.com.au
Posted on 2001-02-02 19:11:00 by hutch--