AFAIK, .dll is in PE format, what about .lib?
There is 2 kind of files with .lib extension :
the static library (for static linking)
The import library (for dynamic linking)
Both are an archive of COFF files. The format of this archive is an 'ar archive'.
The unix (cygwin/mingw) command ar can parse this file like the tar command does.
If you want to see the archived file in a .lib, you can do:
ar tv <name>.lib
Generally, if you see .obj file, it means that it is a static library.
If you see .dll then it is an import library.
I always though they were COFF format
See here for more info: http://support.microsoft.com/?id=121460 (archive)
Common Object File Format (COFF)
Article ID: Q121460
Creation Date: 05-OCT-1994
Revision Date: 12-OCT-1994
The information in this article applies to:
Microsoft Windows NT operating system version 3.1
Microsoft Windows NT Advanced Server version 3.1
Microsoft Windows NT Workstation version 3.5
Microsoft Windows NT Server version 3.5
SUMMARY
Windows NT uses a special format for the executable (image) files and object files. The format used in these files are referred to as Portable Executable (PE) or Common Object File Format (COFF) files. The name Portable Executable refers to the fact that executable files can run on more than one platform. This article describes in detail the internal features of PE/COFF file formats and its parameters.
MORE INFORMATION
The PE/COFF file headers consist of a MS-DOS stub, file signature, COFF Header, and Optional Header. An object file contains only the COFF Header, but an image file contains all the headers described above. The most important of these headers is the COFF header. The table below describes the information stored in the COFF header.
Offset Size Field Description
0 2 Machine Number identifying type of target machine.
2 2 Number of Sections Number of sections; indicates size of the
Section Table, which immediately follows
the headers.
4 4 Time/Date Stamp Time and date the file was created.
8 4 Pointer to Symbol Offset, within the COFF file, of the symbol
Table table.
12 4 Number of Symbols Number of entries in the symbol table.
This data can be used in locating the
string table, which immediately follows
the symbol table.
16 2 Optional Header Size of the optional header, which is
Size included for executable files but not
object files. An object file should have a
value of 0 here.
18 2 Characteristics Flags indicating attributes of the file.
Windows NT Software Development Kit (SDK) provides a utility called
DUMPBIN. DUMPBIN is a 32-bit tool that displays information about 32-bit
Common Object File Format (COFF) binary files. DUMPBIN runs only from a
command prompt. You can use DUMPBIN to examine the following kinds of COFF
files: object files, standard libraries of COFF objects, executable files,
and dynamic-link library (DLL) files.
To run DUMPBIN, use the following syntax:
DUMPBIN [options] [files]
The following are options parameters and definitions for DUMPBIN:
/ALL
/ARCHIVEMEMBERS
/DISASM
/EXPORTS
/HEADERS
/IMPORTS
/LINENUMBERS
/LINKERMEMBER[:{1|2}]
/OUT:filename
/PDATA
/RAWDATA[:{NONE|BYTES|SHORTS|LONGS}[,#]]
/RELOCATIONS
/SECTION:name
/SUMMARY
/SYMBOLS
Options Definition
/ALL Setting this option causes DUMPBIN to display all
available information except code disassembly.
/ARCHIVEMEMBERS Setting this option causes DUMPBIN to display minimal
information about member objects in a library.
/DISASM Setting this option causes DUMPBIN to show disassembly
of code sections, using symbols if present in the file.
/EXPORTS This option causes DUMPBIN to list all definitions
exported from an executable file or DLL.
/HEADERS Setting this option causes DUMPBIN to display the file
header and the header for each section. When used with a
library, displays the header for each member object.
/IMPORTS This option causes DUMPBIN to list all definitions
imported to an executable file or DLL.
/LINENUMBERS Setting this option causes DUMPBIN to show COFF line
numbers. Line numbers exist in an object file if it was
compiled with /Zi. An executable file or DLL contains
COFF line numbers if it was linked with /DEBUG and
/DEBUGTYPE:COFF option.
/LINKERMEMBER [[:{1|2}]]
Setting this option causes DUMPBIN to list public symbols
defined in a library. Specify the 1 argument to display
symbols in object order, along with their offsets. Specify
the 2 argument to display offsets and index numbers of
objects, then list the symbols in alphabetical order along
with the object index for each. To get both outputs,
specify /LINKERMEMBER without the number argument.
/OUT:<filename> This option specifies a filename for the output.
/RAWDATA [[:{BYTES|SHORTS|LONGS|NONE}[[,number]]]]
Setting this option causes DUMPBIN to display the raw
contents of each section in the file. The arguments
control the format of the display, as follows:
Argument - Result
BYTES - The default. Contents are displayed in hexadecimal bytes,
and also as ASCII if they have a printed representation.
SHORTS - Contents are displayed in hexadecimal words.
LONGS - Contents are displayed in hexadecimal longwords.
NONE - Raw data is suppressed. This is useful to control the
output of /ALL.
number - Displayed lines are set to a width that holds number
values per line.
/RELOCATIONS Setting this option causes DUMPBIN to display any
relocations in the object or image.
/SECTION: <section>
This option restricts the output to information on the
specified section.
/SUMMARY Setting this option causes DUMPBIN to display minimal
information about sections, including total size. This
option is the default if no other option is specified
in a DUMPBIN command.
/SYMBOLS Setting this option causes DUMPBIN to display the COFF symbol
table. Symbol tables exist in all object files. A COFF symbol
table appears in an image file only if it is linked with
/DEBUG /DEBUGTYPE:COFF
Some compilers (eg. Microsoft) use COFF format and some (eg. Borland/Codegear) use OMF format.
Here's description of microsoft's Lib file (same content, working link) format.
Examining a lib file in a hex editor (Visual Studio 2010), the data seems to be the same as an .a file on unix... an ar archive. It has two special files (with empty names) in the beginning that are some sort of symbol list.
EDIT: found a duplicate question Which format does static library (*.lib) files use? Where can I find "Official" specifications of *.LIB file structure/format? - it has a link that confirms this.
If you're interested in actually viewing the contents:
Wayne J. Radburn's PEView can decode it
and 7-zip can also give limited view of it
Related
I am generating some .lib(eg- libcef_dll_wrapper.lib) files and later after some steps using this .lib file in myCustomApp. I am getting below error in Visual Studio debug build only.
LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in customfile.obj
There are many steps between creation of this .lib file and using it in my custom application. Is there any way so that i can check ITERATOR_DEBUG_LEVEL value just after creation of this .lib file? Please help.
I am afraid, how this information is stored in a .lib archive file is not well documented.
A compiler stores the value with the name "_ITERATOR_DEBUG_LEVEL" got by _STRINGIZE(_ITERATOR_DEBUG_LEVEL).
#define _STRINGIZEX(x) #x
#define _STRINGIZE(x) _STRINGIZEX(x)
You may parse a .lib archive and .obj files in an archive and look for "_ITERATOR_DEBUG_LEVEL" value.
The code bellow from yvals.h detects the value mismatch while linkage, see #pragma detect_mismatch
#pragma detect_mismatch("_ITERATOR_DEBUG_LEVEL", _STRINGIZE(_ITERATOR_DEBUG_LEVEL))
When you link the project, the linker throws a LNK2038 error if the project contains two objects that have the same name but each has a different value. Use this pragma to prevent inconsistent object files from linking.
Both name and value are string literals and obey the rules for string literals with respect to escape characters and concatenation. They are case-sensitive and cannot contain a comma, equal sign, quotation marks, or the null character.
I have a model in Modelica language (platform: Dymola). Dymola creates a binary file of model during compiling/translation (dymosim.exe). If binary code export licence is available then a binary file which is standalone representative of original dymola model is created. This can be run on any computer without Dymola licence.
Now, My question is how can I create Gui for around this executable file with following requirements:-
1. It should be able to change in some input parameter values.
2. It should be able to get some output parameter values.
Now as background:-
dymosim.exe takes parameter values as input from text file (dsin.txt) and writes output in another text file (dsres.txt)
Specifically, if one has such binary executable which takes input from a text file and writes output in specific format (of which rules are known) to another text file; then what are some tools to create gui for it?
Look into Dymola's embedded server support (DDE/OPC). Since you are using dymosim.exe, I believe you are using Windows so Dymola's restriction on only Visual Studio 32-bit code for embedded servers will be acceptable. (Most Modelica tools have similar embedded servers, but I don't think they are compatible.)
Dymola dymosim.exe exports its time series results as *.mat files, you should be able to find tools/libraries to handle *.mat format in your GUI.
Also, dsin.txt has its own format, you can try to understand it first (try to find its comments) and then parse it, it's not a text file with random string and number columns.
To use FMI standard is worth to consider in the co-simulation mode which means that a solver is included. Dymola allows to export model as FMU package (in Windows platform it is single DLL with some metadata, in Linux platform it is .SO library) and provides these functions worth to do your steps:
fmiSetReal() will set a parameter value
fmiDoStep()
fmiGetReal() will get the variable value
You can call these functions directly, just unzip FMU package and find the DLL inside and link it directly to your application.
Or recommended way (we did it in our app): use FMI Library providing general C API interacting with a FMU package and controling temporal structures the way you need.
I was inspecting the preprocessed output generated by GCC, and I see a lot of these in the .i file that I generated using the -save-temps flag:
# 8 "/usr/include/i386-linux-gnu/gnu/stubs.h" 2 3 4
What do the numbers before and after the absolute path of stubs.h mean? It seems to be some kind of debugging information that is inserted by the preprocessor and allows the compiler to issue error messages referring to this information. These lines do not affect the program itself, but what specifically is each number for?
Based on the documentation the number before the filename is the line number. The numbers after the file name are a flag and mean the following:
1 indicates the start of a new file.
2 indicates returning to a file (after having included another file).
3 indicates that the following text comes from a system header file, so certain warnings should be suppressed.
4 indicates that the following text should be treated as being wrapped in an implicit extern "C" block.
According to this article http://msdn.microsoft.com/en-us/library/ms809762.aspx?ppud=4
we can name the PE sections with custom names.
So in a PE file which its creator has replaced the sections names with his own names,
now if the ".pdata" section for example isn't called ".pdata" anymore so I can't find it by its name.
how can I find the ".pdata"?
Correct, according to the Windows Portable Executable specification and other source like the ones of Matt Pietrek, sections Names are made for the humans! Typically compilers set "standard" names for specific types of sections content (e.g. ".text" for code, etc..). But, these names are fully ignored by the loader. These sections names can be modified using different methods (using pragma or other tools e.g Peid, etc..). The section of interest (.pdata) is associated the IMAGE_DIRECTORY_ENTRY_EXCEPTION directory.
To find the .pdata section (which is BTW an indicator that the image is 64bit) when it has been renamed, all you need to do is to search for the IMAGE_DIRECTORY_ENTRY_EXCEPTION directory, and based on its content, retrieve the section it is located in (as you can do for all directories).
I have a Mac OS X command-line tool that would benefit from having some data embedded in the binary file itself.
I know mach-o files support multiple segments, some of which can be used for storing arbitrary data. But I can't find a command-line tool to do that.
While I know there are other, probably simpler ways (e.g. convert the data file into C source code and have it get linked in by gcc) to get the data into my binary this problem has piqued my interest. Anyone know the magic?
The linker, ld, takes an argument -sectcreate.
From the man page,
-sectcreate segname sectname file
The section sectname in the segment segname is created from
the contents of file file. The combination of segname and
sectname must be unique there cannot already be a
section (segname,sectname) from any other input.
GCC also has a section attribute that can be applied to a variable to say that it belongs in a non-standard section.