~ OWL Static Library Sectioning ~

Introduction

If you have examined closely some of the OWL/OWLNext source files, you may have found lines like these:

#if defined(SECTION) "" SECTION != 1

In case you are wondering what is the purpose of these lines, I will offer an explanation.

Static libraries

Static libraries are a collection of compiled source files. Usually one .c or .cpp file, containing several methods, compiles to one .obj file, which is then placed in the library.

When a program calls one of these methods, the linker has to get the .obj file and link it to the program. Now, Microsoft linker is smarter, it supports &function level linking& (/Gy option), meaning that only the code for the actually used function is linked in the application.

Borland linker does not have this functionality, and links the whole .obj file, usually resulting in larger application size.

Borland's workaround

To fix this situation in the OWL framework, Borland have implemented splitting large source files in smaller chunks. In the source code, lines like this:
#if !defined(SECTION) || SECTION == 31
are inserted and the library building process is modified, so theses files are compiled more than once, each time with different value for the define SECTION, and different .obj file name. For example, applicat.cpp results in the files applica1.obj, applica2.obj, ... up to applica32.obj, each of them containing only a subset of the functions in the source.

This solution leads to decrease in the size of the application - the aclock example built with sectioned OWLNext static library is about 600K is size, and with unsectioned library the size grows to over 800K.

Pros and cons

For programmers using Borland/Codegear development tools, and static linking to OWLNext libraries, there will be the advantage of a reduced application size. For those using dynamic linking, there is no effect, sectioning is not used when building the DLLs.

For programmers using Visual C++, it's linker will link only the necessary functions from the OWLNext library, which would result in smaller executable size in most cases - sectioning is not used when building with VC++.

The main disadvantage is for the library developers, as the sectioning leads to more complex makefiles and build process, especially if decided to add sectioning to more source files.

Sectioned source files in OWLNext

• animctrl.cpp
• applicat.cpp
• brush.cpp
• button.cpp
• checkbox.cpp
• combobox.cpp
• control.cpp
• decframe.cpp
• decmdifr.cpp
• dialog.cpp
• dib.cpp
• dibitmap.cpp
• docking.cpp
• docmanag.cpp
• doctpl.cpp
• document.cpp
• edit.cpp
• editfile.cpp
• editsear.cpp
• editview.cpp
• file.cpp
• filedoc.cpp
• filename.cpp
• filtval.cpp
• findrepl.cpp
• floatfra.cpp
• framewin.cpp
• fscroll.cpp
• glyphbtn.cpp
• groupbox.cpp
• hslider.cpp
• inputdia.cpp
• listbox.cpp
• listview.cpp
• lookval.cpp
• mdichild.cpp
• mdiclien.cpp
• mdiframe.cpp
• memcbox.cpp
• menudesc.cpp
• module.cpp
• opensave.cpp
• picker.cpp
• pictval.cpp
• printdia.cpp
• printer.cpp
• printout.cpp
• radiobut.cpp
• rangeval.cpp
• scrollba.cpp
• scroller.cpp
• slider.cpp
• static.cpp
• tinycapt.cpp
• treewind.cpp
• validate.cpp
• view.cpp
• vslider.cpp

Last updated: 10 April 2008