File:  [OS/2 SDKs] / os2sdk / demos / examples / dynlink / readme
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs
Thu Aug 9 12:25:13 2018 UTC (7 years, 9 months ago) by root
Branches: msft, MAIN
CVS tags: os2sdk-1988, os2sdk-1987, HEAD
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.

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.