LIB File Documentation

Summary

A LIB (Microsoft linker input library) file is a build-time archive that a C/C++ linker consumes, not a file you open or run. It is an ar-format archive holding COFF object members, and comes in two kinds: a static library (compiled OBJ code copied into your program at link time) and an import library (stubs telling the linker which functions a matching DLL provides at run time). Its MIME type is application/octet-stream. Inspect one with lib /list or dumpbin.

Technical details

FeatureValue
Full nameStatic / Import Library (COFF archive)
File extension.lib
MIME typeapplication/octet-stream
Format typeArchive of COFF object files or import descriptors
Container formatUnix ar archive
Member formatCOFF (Common Object File Format)
DeveloperMicrosoft (with Unix ar lineage)
IntroducedCOFF from Unix (1980s); MSVC .lib early 1990s
Magic number (hex)21 3C 61 72 63 68 3E 0A (“!<arch>\n”)
Byte orderLittle-endian (x86/x64 COFF members)
Two kindsStatic library; import library (pairs with a DLL)
Created byMicrosoft lib.exe (Library Manager); also emitted with a DLL
Inspect withlib /list, dumpbin /symbols, ar t, nm
Unix counterpart.a static library (same ar format, ELF members)
Runnable?No — has no entry point; it is linked, not executed
Open standardPartial — COFF/PE documented by Microsoft
Related extensions.a, .obj, .o, .dll, .exe, .h, .pdb
Specificationlearn.microsoft.com/windows/win32/debug/pe-format
File signature (magic bytes)
21 3C 61 72 63 68 3E 0A

Offset 0, 8 bytes. In ASCII this is !<arch> followed by a newline (0x0A), the standard Unix ar archive signature — the same family as a Unix .a static library. What follows is a sequence of archive members, each with a 60-byte header, whose payloads are COFF object files. An unrelated game or app that reuses the .lib extension for its own data will not begin with this signature.

What is a LIB file?

A .lib file is a library archive consumed by the linker when building native programs, most often on Windows with the Microsoft Visual C++ toolchain. It is not a document, not a program, and nothing double-clicks it open. It is an input to the link stage of a build: the compiler turns source into object files, and the linker pulls code and symbols out of .lib files to produce a finished EXE or DLL. Under the hood a Windows .lib is a Unix-style ar archive (it begins with !<arch>) whose members are COFF, the Common Object File Format that also underpins Windows object files and PE executables.

The COFF lineage goes back to Unix System V in the 1980s; Microsoft adopted the ar/COFF pairing for its C/C++ tools in the early 1990s. The single .lib extension covers two genuinely different things, and confusing them is the source of most .lib questions.

Static library versus import library

A static library is a bundle of compiled object files. When you link against it, the linker copies the object code your program actually references directly into the final binary. After that the library file is no longer needed: the program has no run-time dependency on it, because the code now lives inside the executable. This makes deployment simple at the cost of a larger binary and no shared updates.

An import library contains almost no real code. Instead it records which exported symbols live in a companion DLL and generates the thunks and Import Address Table entries the linker needs so your program can call into that DLL at run time. The DLL must still be present when the program runs. Microsoft’s toolchain produces an import .lib automatically alongside any DLL that exports functions, which is why an SDK ships a .dll to redistribute and a matching .lib to link against. Both kinds share the same ar/COFF container, so you cannot always tell them apart by the header alone — you inspect the members.

The ar archive layout and its special members

After the eight-byte !<arch>\n signature, an ar archive is a flat list of members. Each member has a 60-byte ASCII header giving its name, modification time, owner, mode and size (in decimal text), padded so members start on even offsets. A Microsoft .lib places several special members first, before the ordinary object members:

!<arch>\n                     8-byte archive signature
├─ "/"   (1st linker member)  symbol -> member-offset index (big-endian)
├─ "/"   (2nd linker member)  the MSVC symbol index (sorted, faster lookup)
├─ "//"  (longnames member)   table of long member/object file names
├─ member 1                   a COFF .obj (or import descriptor)
├─ member 2                   a COFF .obj
└─ ...

The first linker member is a symbol table mapping every exported symbol name to the archive offset of the member that defines it, so the linker can resolve a symbol without scanning every object. The second linker member is Microsoft’s own sorted index that speeds that lookup further. The longnames member (//) stores member names too long for the 16-character field in the member header; those headers then reference a name by its offset into this table. Everything after these is the payload: the COFF object files for a static library, or the small import descriptors for an import library.

Inside a COFF member: sections and symbols

Each ordinary member is a COFF object file, the same format the compiler emits as an OBJ. A COFF object opens with a header naming the target machine (for example 0x8664 for x64, 0x14c for x86), a section count and a pointer to the symbol table. It then holds sections such as .text (machine code), .data and .bss (initialised and zero-filled data), .rdata (read-only data), plus relocation entries that record addresses the linker must fix up, and a symbol table with a string table for names. Because the machine field is stamped into every member, a .lib built for x64 will not satisfy an x86 link, which is the usual cause of “unresolved external symbol” or architecture-mismatch errors.

Creating and inspecting a LIB

Microsoft’s lib.exe (the Library Manager) builds and edits these archives: lib /out:mylib.lib a.obj b.obj packs object files into a static library, and lib /list mylib.lib prints the member names. To see the exported symbols, dumpbin /symbols mylib.lib or dumpbin /headers mylib.lib reads the COFF structures directly. Because the container is plain ar, cross-platform tools work too: GNU binutils ar t mylib.lib lists members, nm mylib.lib lists symbols, and 7-Zip will open a .lib as an archive so you can browse or extract the object members. Extracting the objects (lib /extract or ar x) is the only genuine “unpacking” of a static library.

One thing you cannot do is convert a .lib into a DLL or EXE. Those are different build outputs with an entry point and a loader; a library has neither. If you need a DLL, you rebuild the source as a DLL, and if the .lib is an import library the DLL already exists beside it. Renaming a Windows .lib to a Unix .a also does not make it usable on Linux: the container matches but the members are COFF, not ELF, so the object code must be recompiled for the target platform.

References