Penguin

Differences between current version and revision by previous author of Library.

Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History

Newer page: version 6 Last edited on Wednesday, March 24, 2004 11:39:19 am by StuartYeates
Older page: version 5 Last edited on Wednesday, March 24, 2004 9:34:41 am by AristotlePagaltzis Revert
@@ -1,7 +1,11 @@
 ''Note: if you are looking for books, software etc to borrow, see WlugLibrary.'' 
  
-A [Library] is basically a piece of pre-compiled code, usually a set of functions, used by many programs. It is therefor made available as a separate entity so the code can be reused between them. [BinaryExecutable]s can be linked against a library either statically or dynamically
+A [Library] is basically a piece of pre-compiled code, usually a set of functions, used by many programs. It is therefor made available as a separate entity so the code can be reused between them. 
  
-Static linking means that the library is bound to the executable at [CompileTime ] (or more precisely, link time) , and the library is embedded in the BinaryExecutable. This has a number of drawbacks: the memory footprint of the program both on disk and in memory increases , because statically linked libraries cannot be shared, and it has to be relinked (which usually means it needs to be recompiled) for bug fixes in a library to propagate to the programs using it. However, some programs like the [Kernel ] and the linker must be statically linked since the dynamic linker is not available at the time of their execution. Also, static linking also reduces load time of an executable and hardens executables against a cracker using library preload to tamper with their operation. It may therefor be wise to link a select set of binaries statically, at least on exposed hosts
+In the library model used by [C ], [C++] and most systems in the [UNIX] world , [BinaryExecutable ]s can be linked against a library either statically or dynamically
  
-Dynamic linking on the other hand happens at [RunTime] and is the common form of linking. It requires the [Library] to take a special form, called SharedLibrary for obvious reasons on most systems, and commonly stored in files named __lib''foo''.so.''m.n.o''__ where ''foo'' is the name of the SharedLibrary and ''m.n.o'' is an optional version number. Only [Windows] invents its own terminology and calls them [DLL]s. 
+# Static linking means that the library is bound to the executable at [CompileTime] (or more precisely, link time), and the library is embedded in the BinaryExecutable. This has a number of drawbacks: the memory footprint of the program both on disk and in memory increases, because statically linked libraries cannot be shared, and it has to be relinked (which usually means it needs to be recompiled) for bug fixes in a library to propagate to the programs using it. However, some programs like the [Kernel] and the linker must be statically linked since the dynamic linker is not available at the time of their execution. Also, static linking also reduces load time of an executable and hardens executables against a cracker using library preload to tamper with their operation. It may therefor be wise to link a select set of binaries statically, at least on exposed hosts.  
+  
+# Dynamic linking on the other hand happens at [RunTime] and is the common form of linking. It requires the [Library] to take a special form, called SharedLibrary for obvious reasons on most systems, and commonly stored in files named __lib''foo''.so.''m.n.o''__ where ''foo'' is the name of the SharedLibrary and ''m.n.o'' is an optional version number. Only [Windows] invents its own terminology and calls them [DLL]s.  
+  
+There are other model of how to organise libraries, such as the [Java] model which has no static linking but jars for dynamic linking and interfaces for dynamic code generation of glue classes