Introduction to OS APIs

---

An extended version of this outline is also available on-line. It includes more examples and many of the additional comments I made in class.

---

Modular Structure of Software

There are two techniques for successfully writing large programs:

1. Use a language that accomplishes more per "line of code." (Admiral Grace Hopper's COBOL being among the first.)

2. Program in functional modules, each of which is small enough for a person to grasp.
   • Limit the interactions between the functional modules.

   • Permits much more effective teamwork.

   • Emphasizes the value of analysis at the start of a project.

Interaction Between Modules

There are several different ways in which a supposedly modular program can still be very difficult for a programmer to cope with:

1. Which modules invoke which other modules?

2. What are the possible sequences of execution of the various modules?

3. What are the methods by which information passes between modules?

Local and Global Scope of Variables

• A "global variable" can be used or modified by code in any module.

• A "local variable" can be used or modified only by the one module it is part of.

• A typographical error might result in using a local variable where a global one was intended, or vice versa.

• The compiler cannot catch this logic mistake, because all the program statements are legal, they just do not have the intended effects!

• Good practice for large software projects calls for the modules to use local variables and to communicate by arguments and return values.

Arguments and Return Values

• The code that starts execution of a module can also provide initial values for one or more specific local variables. These variables are known as the "arguments" of the module.

• When modules complete their work, information can be returned to the module that invoked them.
  • One numerical value may be returned.

  • Multiple values may be returned by letting specified arguments pass data out of a module.

  • Multiple values may be returned by permitting one or more arguments to pass data both into and out of the module.

• Some programming languages support more than one of these mechanisms.

Operating System Services

• Software developers have demonstrated that many different programs can take advantage of a number of similar modules.
  For example: file opening dialogs.

  Software developers writing application programs do not have to write their own module that performs such functions. Instead, they write their software to use the operating system's module.

  Some operating systems provide modules that support graphical user interfaces, other operating systems provide modules that support command line user interfaces, some provide both.

Application Programming Interfaces

• Application Programming Interfaces (APIs, for short) are the specifications of the operating system modules that are intended to be used by people developing application software.

• Often they will also be used by some of the utility programs that are provided with the operating system, or for the internal functions of the operating system.

• By definition, APIs must include a description of the functions accomplished by the module and the mechanisms used to pass information into and back from the module. Typically this will include specification of
  • the number and order of the arguments;

  • for each argument, the type of variable;

  • for each argument, whether the argument is "passed by value" or "passed by reference";

  • for each argument, whether the argument passes information into the module, out of the module, or both;

  and so on.

Undocumented Modules

• Operating systems always include modules that are not documented as APIs. Modules may be undocumented because
  • the operating system developers do not believe those modules will be useful to application software developers, or

  • the operating system developers are not sure that the current form of those modules is the best design.

• Once an API is published, the operating system developers will be obliged to keep it working in all future versions of that operating system.

• Conspiracy theorists believe that another reason for undocumented operating system modules in Windows is to permit Microsoft applications to be "better" than applications from other software vendors.

Trusting vs. Careful Code Design

• When a module is invoked, one of the first things it may do is to verify that its arguments appear to be proper.

• Such careful code will make it easier to identify mistakes in the code that invokes the module.

• It will also make the program run more slowly and occupy more memory.

• Windows (all versions, including NT) is notorious for the absence of such careful design.

• This is partly a result of the fact that so much competition in the PC industry revolves around system performance.

• Sometimes this will simply result in the system freezing or crashing. Other times it will result in bad data being written to disk, where it will come back to haunt the user at some later time.

Notes

J. M. Fenster, 1998, "Amazing Grace." American Heritage of Invention & Technology, Fall, 1998, Volume 14, Number 2, pages 24-31.

Return to MIS 300 Page

Please E-Mail comments or suggestions to "piccard@ohio.edu".

© Copyright 1998 Richard D. Piccard