|
|
Microsoft OS/2 SDK 12-15-1987
This directory contains illustrations of the creation and use of dynamic link
libraries. The library itself is constructed in one of two different ways:
1. entirely in assembly code
2. nearly all in C, with an assembly stub module
The initialization entry point to the dynalink library must be defined in
an assembly module, which can contain all of its own code or can make
a call to a routine in a C module.
Your library can have several data segments, each which is global (SHARED)
to all applications using the library or is duplicated (NONSHARED) for each
application. An example would be a pseudo graphics driver. The
"per-instance" data could be structures representing windows owned by each
application. The global data could be semaphores used to serialize access to
the hardware.
-------------------------------------------------------------------------------
The application:
There are two methods of linking to a dynamic link library:
1. at load time
2. at run time
The first method is less complicated in that the system takes care of
all fixup and loading of the library. The second method is more
comprehensive in that it allows the application to determine if a library
exists, and make a choice of whether or not to use it.
The latter would be preferred in applications that need to run in environments
lacking in certain libraries. For example, a package could make good use of
a fancy high resolution graphics board. However, if the product wasn't
present the application could fall back to the standard VIO graphics (such as
they are).
There are two ways of linking an application so that it can link to a dynalink
library at load time:
1. the application can have a .DEF file which names the entry points
of the dynalink library used by it
2. IMPLIB can be used to create an IMPORTS library from the .DEF file
of the dynalink library
The second method does away with the need for the application to define
a .DEF file.
-------------------------------------------------------------------------------
readme this file
dynlink.cmd front end for "make dynlink"
Sets up the environment for constructing the dll either
from C modules ("dynlink c") or from the asm module
("dynlink asm"), then invokes "make dynlink".
dynlink makefile
NB - The LIB and INCLUDE environment variables must be
set correctly. LIB is the search path for LINK and
INCLUDE is the search path for CL.
NB - LIBPATH can be set (in CONFIG.SYS) to start in the
current directory. eg. LIBPATH=.;C:\;C:\LIB
dynlib.h defines calling conventions for the library routines
dynlib.def contains library information for the linker and loader
This file is used to create the import library for the dll.
dyninit.asm contains initialization routine entry point
dynlib.c data segment is per-instance
dynlib2.c data segment is global
near subdirectory with C modules where data is not declared far
far subdirectory containing the far-data versions of the C modules
NB - Both near & far assume small-model compilation.
dynlib3.asm assembly version
dynlink.def IMPORTs the entry points of the dll
dynlink1.c links to the dll at load time
dynlink2.c links to the dll at run time
dyngo.cmd brings up several copies of dyndemo2.exe
NB - LIBPATH must contain the root directory.
dyncvp.cmd brings up CodeView
NB - If you want to single-step the program, you must
(with the cvp I am using, MS cvp v.2.00.10) use the
right mouse button to execute to the next instruction,
immediately upon entering cvp. Then you can use F8
to single-step to your heart's content.
Also, for the time being, cvp requires that your
dll reside in the root directory of your boot disk.
This requirement will go away.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.