OWL_Static_Library_Sectioning

• Introduction
• Static libraries
• Borland's workaround
• Pros and cons
• Sectioned source files in OWLNext 6.32 and earlier

Introduction

In OWL and OWLNext, prior to version 6.34, much of the library source code files were divided into sections (delimited by preprocessor #if directives), in order to circumvent a flaw in the Borland linker, i.e. its inability to do function level linking and hence producing relatively large executables. The sectioning allowed the the library makefiles to compile only parts of each source file at a time, thus creating a number of smaller object files for each source code file. Since the Borland linker was able to eliminate unused object files, this created smaller executables.

With increasing memory capacity, as well as modern compilers with support for function level linking, the need for sectioning has diminished, and since OWLNext 6.34 sectioning has been removed from the source code, thereby cleaning it up and easing maintenance.

The rest of this article pertains to OWLNext 6.32 and earlier.

Static libraries

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

When a program calls one of these methods the linker has to get the object file and link it to the program. Now, the 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.

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

Borland's workaround

To fix this situation in the OWL framework, Borland's solution is to compile 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 object file name. For example, "applicat.cpp" results in the files "applica1.obj", "applica2.obj", and so on up to "applica32.obj", each of them containing only a subset of the functions in the source.

This solution leads to a decrease in the size of the application. The "aclock" example built with sectioned OWLNext static library is about 600 KiB is size. With unsectioned library the size grows to over 800 KiB.

Pros and cons

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

The linker in Visual C++ will link only the necessary functions from the OWLNext library, which will result in a smaller executable size anyway, so sectioning is not used when building with VC++.

The main disadvantage is in library maintenance. The sectioning leads to more complex source files, makefiles and build process.

Sectioned source files in OWLNext 6.32 and earlier

• 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