Environments

Although the License Service API is targeted for a number of operating system platforms, each platform has its own set of requirements which the software developer must deal with. For example, differences can be found in the language calling convention, reentrancy, the linking method, etc. This section summarizes how LSAPI is utilized by applications in each environment.

If all Service Providers cannot satisfy a LSRequest(), then the handle associated with the last successful Service Provider response is returned.

Dynamic Linking Environment

In an operating environment which supports dynamic (run-time) linking, the LSAPI architecture allows multiple, concurrent license system service providers. Furthermore, the application program is not bound to any particular license system.

It is important that the Provider Management Layer provides the arguments unmodified to the service provider. The handle that the Provider Management Layer provides is an exception to this. The methodology in which the Provider Management Layer enables this is implementation specific.

In non-preemptive environments, care should be taken not to block the environment.

The function of the license system management layer is to coordinate the interaction between licensing-enabled applications and the individual license system service providers. This layer provides no licensing services itself. Rather, it is responsible for mapping each function call to the appropriate service provider.

Not every operating system supports dynamic linking. In some environments (such as DOS), support for multiple concurrent service providers might be through some other means.

Static Linking Environment

At minimum, LSAPI provides source level compatibility across license systems. In environments which do not support dynamic linking (either natively or emulated), then the application is statically linked with a vendor-specific license module.

Note that this is only one possible example of static linking and may be done differently on different platforms.

Windows® Applications

An MS-Windows application calls the License Service API functions using the Pascal Far calling convention (similar to other Windows DLLs). The Dynamic Link Library (DLL) named LSAPIxx.DLL* is used. The LSAPIxx.LIB* file (created from LSAPIxx.DEF*) is used to describe the DLL entry points. The LSAPIxx.DLL* contains the service provider management layer, which manages the interaction between applications and license system services. Applications need only follow the DLL binding and calling conventions.

Note Where xx = 16 or 32; depending on platform

Source code may be license system independent?	YES
Executable may be license system independent?	YES
Dynamic Linking native to operating system?	YES
Reentrant Operations	As permitted by service provider (reentrant operation may block)

DOS Applications

DOS application calls the License Service API functions using the C language calling convention. The resulting application is then compiled and statically linked with the LSAPI.LIB library. This library implements a service provider management layer to access the license system providers (which are implemented as TSRs under MS-DOS). Thus, DOS applications need not be statically linked to a specific license system at compile time.

Source code may be license system independent?	YES
Executable may be license system independent?	YES
Dynamic Linking native to operating system?	NO†
Reentrant Operations	NO

† Run-time license system independence is provided by a library which is statically linked to the application.

Apple Macintosh® Applications

Macintosh Applications call the License Service API functions using the Pascal calling convention. Applications link to the LSAPI.o library, which implements a portion of the service provider management layer to access the license system providers. Users must also install a system extension in their System Folder. The library and system extension can be obtained from Sassafras Software. Macintosh applications do not need to be statically linked to a specific license system at compile time; providers are loaded dynamically as they become available.

Source code may be license system independent?	YES
Executable may be license system independent?	YES
Dynamic Linking native to operating system?	NO
Reentrant Operations	as permitted by the service provider

† Run-time license system independence may be provided by a library which is statically linked to the application.

OS/2® Applications

This information was not available at time of publication. Contact International Business Machines's Systems Management Group in Austin, TX.

Source code may be license system independent?	YES
Executable may be license system independent?	YES
Dynamic Linking native to operating system?	YES
Reentrant Operations

OpenVMS™ and ULTRIX™ Applications

This information was not available at time of publication. Contact Digital Equipment Corporation via FAX at (508) 486-6100.

Source code may be license system independent?	YES
Executable may be license system independent?
Dynamic Linking native to operating system?
Reentrant Operations

HP/UX™ and Domain/OS™ Applications

This information was not available at time of publication. Contact Hewlett-Packard at (508) 256-6600 for further information.

Source code may be license system independent?	YES
Executable may be license system independent?
Dynamic Linking native to operating system?

Unix® Applications

There are many dialects of Unix available. Contact the particular Unix vendor for further information. Additional information may be available from the license system vendors.

Source code may be license system independent?	YES
Executable may be license system independent?	†
Dynamic Linking native to operating system?	†

† Some Unix implementations may provide for run-time linking..