Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Removable Application Programming Interface

IP.com Disclosure Number: IPCOM000038844D
Original Publication Date: 1987-Mar-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 1 page(s) / 12K

Publishing Venue

IBM

Related People

Jeffries, LM: AUTHOR [+2]

Abstract

A method is described for implementing a removable Application Programming Interface (API). An API is an interface allowing a user-written application to communicate with another application. The link between the programs is established through an address stored in an interrupt vector pointing to the API interrupt handler. The unique characteristic described in this method is the ability to remove the API without initial program loading the system. To remove the API, the API code (interrupt and request handlers) has to be removed, and two special situations have to be allowed for. The first special situation is the removal of the API code while the interrupt handler is still waiting for a request to complete.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 1

Removable Application Programming Interface

A method is described for implementing a removable Application Programming Interface (API). An API is an interface allowing a user-written application to communicate with another application.

The link between the programs is established through an address stored in an interrupt vector pointing to the API interrupt handler.

The unique characteristic described in this method is the ability to remove the API without initial program loading the system. To remove the API, the API code (interrupt and request handlers) has to be removed, and two special situations have to be allowed for. The first special situation is the removal of the API code while the interrupt handler is still waiting for a request to complete. Simple deletion of the interrupt handler would not handle this situation as control would never return to the application issuing the API request. The second special situation is the handling of new API requests that are issued during and after the API removal. Simple deletion is not sufficient as new requests would attempt to access code no longer available. One way to solve the problems is to document the restrictions and leave the burden of avoidance to the operator. This type of a solution would prove troublesome for an operator who does not always have detailed knowledge of how all the programs interact with each other. Even a knowledgeable operator may make a mistake. The preferred technique handles the probl...