For a list of supported header and library files, see Overview to supported file types below.
Headers and libraries are the static interfaces of a published API. They define the layout of data structures and functions, but not the functionality of the API.
Analysing headers helps to easily find areas in which the programming interface promise has been broken. One example of in which analysis can help detect compatibility issues is adding more data members to a class definition. For example, if the modifications to class data members violate the BC rules, data may become corrupted. This may be hard to detect but can result as unwanted side effects.
In addition, modifications to the virtual table or virtuality of functions can typically result in incompatible functionality to be called at application runtime. Usually, all changes reported after header analysis must be manually verified for a confirmation of a break.
A removed library means that dependent components can no longer be compiled. If an application has a static dependency to a DLL and the DLL is no longer available in the device, the application in question will not launch at all. The Launcher tool can be used to verify that all DLLs and resource files are available on the device. The tool is available in platform releases.
If the function ordinals in the library have moved or have been removed, then the components built using this library will exhibit changes in behaviour and will most possibly crash during execution. Modification of function signatures can also be detected in library analysis. Such modifications may mean that originally intended behaviour is no longer preserved.
Changes in the UID, SID or Capabilities of a library/DLL can also be detected in library analysis.
You can analyse the following file types with Compatibility Analyser. For library files, there are specific requirements regarding the use of GCCE and RVCT toolchain.
For more information on file usage with different types of projects, see File handling in EXE and DLL projects.
.h, .hpp |
C++ header file. A header (or |
.hrh |
Common header file for resources and C++ programs. Contains enumerations that are used in .rss, .h and .cpp files. The typical content of such a file is the list of commands that are defined in the application menus, toolbars, and so on. |
.mbg |
Generated bitmap header file. Generated by the toolchain when creating the Symbian OS multi bitmap file (.mbm) file. |
.pan |
A user-defined panic code file. In .pan files, you can define your own panic codes. The use of custom panics makes it easier to find bugs in your application. |
.rsg |
Generated resource header file. Created at compile time by the resource compiler. These files should be included by .cpp files to handle resources. |
.dll |
A dynamic link library file. A function library that can be loaded into memory once and called by one or more applications so that the operating system dynamically resolves the entry points, or the addresses of the called routines, at run time. |
.lib |
Import library file. An archive file created from stubs generated for each of the exported symbols. A library file represents the exported interface of the DLL. This allows other programs to use the DLL, by linking against the import library at build time. Preconditions: see GCCE and RVCT toolchain. |
.dso |
Dynamic shared object file. The .dso file has all the associated sections required for an Executable and Linking Format (ELF) object, such as the symbol table, string table, and so on. It also has the information required for the linker to link to the correct ordinals to the DLL. Preconditions: see GCCE and RVCT toolchain. |