Bridging GIS: Developing system independent applications
Handling Diverse Functionality of Operating Svstems
When developing application code the developer must understand the strengths and weaknesses
of different operating systems. S/He must realize that seemingly simple things like directory and
file names can become difficult when developing code that is to be used across operating system
platforms. The way in which the file system is handled in NT, Unix and VMS is not necessarily
the same. Unix, for example, uses the forward slash ("/") character to reference the system root
directory; VMS has no universal root (the top directory for any device is denotted as "000000" as
in "gis: [000000];"2 NT uses the backward slash ('l") with a drive designation as in "C:\V'.
Developers will typically handle situations that arise in which code must differ because of
operating system differences with "if' logic. For example:
strOS = system.os_name
if strOS = "window" then
... do this
elseif strOS = "vms" then
... do this
elseif strOS = "solaris"
.... do this
else
... do this
endif
Other methods that are also available for handling differences between systems include directives
and environment variables. Directives are used to direct the compiler or system to take certain
actions based on other information. One such situation may be in which multiple dynamic link
libraries (DLLs) are used to read information. Only one DLL is used by the application at any
given time and each reads information from a separate distinct source, perhaps each supporting
their own proprietary format. Information can be gathered during application initialization to
determine which formats are being used, then directives can be given as to which .DLL to use.
Environment variables are good for gathering limited information without utilizing configuration
files, which requires disk 1/0.
Using Building Blocks
Using multiple DLLs through use of directives is a good example
of application building blocks. Each DLL contains a complete set
of functionality that is needed by the overall application. The
concept is that the application is broken down into smaller blocks
of functionality that can provide a standard interface to the main
application, while communicating in a custom or specific way to
other sources. This figure to the right gives an overview of how
the application developer would, in the common interface, make
a standard request, such as a SQL call. Each object in this
middle layer is responsible for interpreting this request, passing it
to the database and returning the information to the common
interface.
This second figure offers a similar diagram for the discussion
and pseudocode given in the preceding section titled, "Third
Party Relationships". In this discussion, the developer gives the
end user the ability to view and manipulate various types of
images and drawings. In the common user interface block the
developer makes fi.mction calls similar to szFilename =
Img.LoadFile(type), which are sent to the lower .DLL. In this
example, the .DLL will, in turn, access one of its own DLLs to
open, read and translate the drawing. For the developer, it
doesn't matter how the middle blocks communicate or translate
the files only that 1) they do, 2) they return the required
information to the common user interface and 3) there is a
published standard for how the image.dll communicates with the
common user interface.
A common example of this approach is through use of Active-X controls in Visual Basic (VB).
The VB developer uses a third party control, which is usually a DLL or OCX file, in her/his
application. This developer then accesses this DLL or OCX through methods made public by its
programmer. What actually occurs inside the DLL or OCX need not be the concern of the
developer, so long as it yields correct data.
