In Howell
& Woods eds., (1995) The Eight White House Papers:
Graduate Research in the Cognitive and Computing Sciences at Sussex. University of Sussex, School of
Cognitive and Computing Sciences, Brighton U.K. Research Paper CSRP 390
An Application of Artificial
Intelligence Techniques to a Consumer Software Product
Ian Cullimore
ianc@cogs.susx.ac.uk
School of Cognitive and Computing
Sciences
University of Sussex
Brighton
BN1 9QH
Abstract An
implementation is discussed where the application of Artificial Intelligence
techniques leads to improved performance in a consumer PC software product,
with benefit to both the end-user and the development company.
Introduction
It is all too easy for Cognitive &
Computing Science students and researchers to forget that there may be
real-life application for their endeavours; perhaps one of the few fortunate
side-effects of my being a part-time PhD researcher working in the PC computing
industry for the remainder of my working day is that I have been able to inject
some of my indirect research and learning into some of the commercial products
in which I have been involved. In this case I was faced with the problem of
easing the installation issues for end-users when attempting to install
software to drive the new popular PCMCIA PC Card [7] type of Ethernet and modem
cards in portable laptop and notebook computers.
2 The
Problem of Installation
PCMCIA cards (now more properly known as
“PC Cards”) have become very popular with portable notebook
computer manufacturers and end-users alike; although originally intended as a
new style of solid state memory storage, their acceptance really came as
peripheral devices such as modems, LAN cards, and rotating disks became
popular. Even though the PCMCIA organisation set up a technical committee and
software subcommittees (in which I was involved) to architect software
abstraction layers (known as Socket Services and Card Services [7]) to ease the
problem of software drivers and applications interacting with PC Cards, the
legacy nature of the PC architecture [4, 5] from its inception in the early
1980s by IBM has lead to many problems when trying to install software drivers
for such cards.
Typically a device such as a modem or
Ethernet card requires resources such as an available hardware interrupt (IRQ),
and an open memory and I/O address range. Unfortunately the original IBM PC
architecture allowed for little standardisation for the allocation of such
resources (people in the universities, generally using the architecturally purer
Apple Macintosh, may not be aware of such problems), it being done in an ad hoc
manner by the end-user, in a trial and error style using DIP switches on the
plug-in hardware boards and modifying installation parameters for the software
drivers. The problem of resource allocation has been compounded with
Microsoft’s Windows architecture [8] often sitting on top of the DOS
operating system and the underlying PC hardware architecture.
3 An
Example of an Ethernet PC Card
Until recently, an end-user (whether novice
or expert) would have to attempt to install a driver for an Ethernet PC Card in the following type of
manner, in the case of, say, installing for a Novell network. An ODI driver [6]
is required to interface to the Ethernet card; this hardware interfacing
ultimately has to be accomplished by communicating with the card through either
I/O ports or a memory region. Also, a hardware interrupt is required for the
card to be able to signal events (such as message reception) to the driver.
Unfortunately, the IBM PC’s I/O and
memory maps are far from well defined, and although many areas are generally
understood to be reserved for certain types of devices or uses, the holes are
usually a free-for-all and prone to conflicts. For example, the famous bottom
640K of memory for an IBM PC in real mode is reserved for RAM, the top 64K is
reserved for the ROM BIOS, and some parts in between are regarded as reserved
for ROM BIOS extensions and video controllers, but the usage of the areas
remaining (generally between hexadecimal memory addresses 0xC0000 and 0xEFFFF)
is not well controlled. In the same way the allocation of IRQs and I/O ports,
although also partly adhering to some convention (such as I/O ports 0x3F8-3FF
being reserved for COM port 1), is also not well controlled.
Pity the poor end-user who would thus,
typically, have to manually edit a Novell-defined text file net.cfg containing configuration information for
the driver’s setup, on a trial-and-error basis until a working solution
had been found (and having to load and unload device drivers at the same time
as each new configuration was tried). Here is an example of such a net.cfg
file:
link
driver pccard
frame ethernet_802.2
int 5
port 320
mem d2000
4 A
First Pass at Easing the Installation Problem
I was involved in architecting a new system
for easing the installation problem [9]. Not only is this problem a significant
one for experienced Information Systems personnel who historically have been
responsible for installing such new hardware and software devices, but even
more so now with PC Cards becoming popular consumer products, and thus
purchased by novice end-users.
Our first version used the basic principle
of the core installation code, hidden behind either a modern Windows or DOS
graphics front-end, procedurally (in ‘C’) examining system
resources and attempting to make informed procedural decisions about their
availability or otherwise. This method was extremely successful, but prone to
the expected problem of difficulty of maintainability.
5 A
Second Attempt, Using AI Techniques
We decided to attempt to separate the two
areas of (a) resource allocation analysis and (b) free resource analysis, and
abstract out the task of a rules based system which had previously been too
embedded in conventional procedural code. We found that resource allocation
analysis could be performed very effectively using conventional C or C++
techniques [2], albeit still with much embedded understanding of PC hardware
and operating system architectures and resource usage. We also discovered a
very effective way of attempting to ascertain a free set of required resources:
the resource allocation analysis system would create a set of applicable rules
(e.g. a file containing a set of Prolog [1, 3] predicates) for the chosen
rules-based Expert System (e.g. Prolog), which was then fed into the Expert
System engine along with our own set of precompiled rules-based constraints,
again based on an understanding of PC hardware and operating system
architectures and resource usage. In this manner we found that the Expert
System had an extremely high success rate of determining correct resource
parameters, with the added bonus of being much easier to maintain (and not just
by the original development team, as it turned out). The rest of the
installation software could then automatically create configuration files (such
as net.cfg) for the end-user, there being very little or no end-user
interaction at all in the whole process.
Conclusions
I hope to have shown that techniques from
AI, which has perhaps been waning in its acceptability of late, can be applied
to real-life consumer software applications problems resulting in the twin
benefits of ease of use for the end-user, and better quality and
maintainability of code by the development company.
References
[1] Amzi!
Inc. Cogent Prolog 3.0 Interactive Development Environment. 1994.
[2] Borland
International, Inc. Borland C++ for Windows. 1994.
[3] Ivan
Bratko. Prolog Programming for Artificial Intelligence. Addison-Wesley, 1986.
[4] Thom
Hogan. The Programmer’s PC Sourcebook. Microsoft Press, 1988.
[5] Peter
Norton. The Programmer’s Guide to The IBM PC. Microsoft Press, 1985.
[6] Novell,
Inc. ODI Developer’s LAN Driver Toolkit guide for DOS Workstation HSMs. 1992.
[7] Personal
Computer Memory Card International Association. PCMCIA Standards. 1992.
[8] Andrew
Schulman, David Maxey & Matt Pietrek. Undocumented Windows. Addison-Wesley, 1992.
[9] Xircom,
Inc. CreditCard Ethernet+Modem 28.8 Installation Software. 1995.