U.S. patent application number 10/985807 was filed with the patent office on 2005-05-12 for application program interfaces and structures in a resource limited operating system.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Ginsberg, Michael, Hullender, Gregory, Johnson, Bruce, Mathur, Sharad, Miller, Mark.
Application Number | 20050102687 10/985807 |
Document ID | / |
Family ID | 22147177 |
Filed Date | 2005-05-12 |
United States Patent
Application |
20050102687 |
Kind Code |
A1 |
Mathur, Sharad ; et
al. |
May 12, 2005 |
Application program interfaces and structures in a resource limited
operating system
Abstract
A set of Application Program Interfaces (APIs) for a
resource-limited environment are disclosed. The APIs provide a
mechanism for a computer application to interface with various
components and modules of an operating system for a
resource-limited environment. The APIs further provide a mechanism
to interface with input/output devices commonly found in embedded
systems running in a resource-limited environment.
Inventors: |
Mathur, Sharad; (Redmond,
WA) ; Hullender, Gregory; (Kirkland, WA) ;
Miller, Mark; (Kirkland, WA) ; Johnson, Bruce;
(Woodinville, WA) ; Ginsberg, Michael; (Redmond,
WA) |
Correspondence
Address: |
WORKMAN NYDEGGER/MICROSOFT
1000 EAGLE GATE TOWER
60 EAST SOUTH TEMPLE
SALT LAKE CITY
UT
84111
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
22147177 |
Appl. No.: |
10/985807 |
Filed: |
November 11, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10985807 |
Nov 11, 2004 |
|
|
|
09560546 |
Apr 28, 2000 |
|
|
|
6832381 |
|
|
|
|
09560546 |
Apr 28, 2000 |
|
|
|
09273592 |
Mar 22, 1999 |
|
|
|
6671745 |
|
|
|
|
60078946 |
Mar 23, 1998 |
|
|
|
Current U.S.
Class: |
719/328 |
Current CPC
Class: |
G06F 9/4843 20130101;
Y10S 707/99952 20130101; G06F 9/54 20130101 |
Class at
Publication: |
719/328 |
International
Class: |
G06F 009/46 |
Claims
What is claimed is:
1. A set of application program interfaces embodied on a
computer-readable medium for execution on a computer in conjunction
with an application that manages at least one voice command menu,
comprising: a first interface that receives a handle of a window
associated with the at least one voice command menu and a flag
indicating when the menu should be active in relation to a speech
recognition status; a second interface that receives a list of
command structures, each of said command structures describing a
voice command, and that returns a number associated with a first
voice command added to the at least one voice command menu; a third
interface that deactivates the at least one voice command menu; and
a fourth interface that receives a number corresponding to a first
voice command, a number of voice commands to remove and that
removes the number of voice commands from the at least one voice
command menu, said removal starting with the number corresponding
to the first voice command.
2. A set of application program interfaces embodied on a
computer-readable medium for execution on a computer in conjunction
with an application that manages a voice command menu, comprising:
a first interface that receives an enablement parameter from an
application, said enablement parameter operative to cause a voice
recognition component to enable voice recognition when the
enablement parameter has a first value and to disable voice
recognition when the enablement parameter has a second value; and a
second interface that returns a second parameter to the
application, said second parameter operative to indicate that voice
recognition is enabled when the second parameter has the first
value and that voice recognition is disabled when the second
parameter has the second value.
3. A set of application program interfaces embodied on a
computer-readable medium for execution on a computer in conjunction
with an application that manages a voice command menu, comprising:
a first interface that receives a first voice command structure
identifying a voice menu and a command string, said voice command
structure having an association with a second application; a second
interface that receives an identifier of a recognized voice
command, a second voice command structure identifying a voice menu
associated with the recognized voice command, a verification
required flag, an action data string, a list containing at least
one recognized phrase of the recognized voice command, and a
command string corresponding the recognized command; a third
interface that is called when a spoken phrase is detected by a
voice command component; and a fourth interface that receives a
type of interference detected by the voice command component.
4. A set of application program interfaces embodied on a
computer-readable medium for execution on a computer in conjunction
with an application that manages a voice command menu, comprising:
a first interface that receives a menu identifier structure, said
menu identifier structure comprising an application name and a
state name, a language identifier structure and a mode flag from an
application that causes a voice recognition system to create a
voice command menu identified by the menu identifier structure; and
a second interface that receives the menu identifier structure from
an application and that causes the voice recognition system to
delete the voice command menu identified by the menu identifier
structure.
5. A computer system comprising: a computer comprising a processor
and a memory operatively coupled together; an operating system
executing in the processor, said operating system having a voice
recognition component; and an application program running under the
control of the operating system; application program interfaces
associated with the voice recognition component, said application
program interfaces operative to receive data from the application
and send data to the application, the application program
interfaces comprising: an interface that receives a handle of a
window associated with the at least one voice command menu and a
flag indicating when the menu should be active in relation to a
speech recognition status; an interface that receives a list of
command structures, each of said command structures describing a
voice command, and that returns a number associated with a first
voice command added to the at least one voice command menu; an
interface that deactivates the at least one voice command menu; and
an interface that receives a number corresponding to a first voice
command, a number of voice commands to remove and that removes the
number of voice commands from the at least one voice command menu,
said removal starting with the number corresponding to the first
voice command.
6. The computer system of claim 5, wherein the application program
interfaces further comprise: an interface that receives an
enablement parameter from the application, said enablement
parameter operative to cause the voice recognition component to
enable voice recognition when the enablement parameter has a first
value and to disable voice recognition when the enablement
parameter has a second value; and an interface that returns a
second parameter to the application, said second parameter
operative to indicate that voice recognition is enabled when the
second parameter has the first value and that voice recognition is
disabled when the second parameter has the second value.
7. The computer system of claim 5, wherein the application program
interfaces further comprise: an interface that receives from the
application a first voice command structure identifying a voice
menu and a command string, said voice command structure having an
association with a second application; an interface that receives
an identifier of a recognized voice command, a second voice command
structure identifying a voice menu associated with the recognized
voice command, a verification required flag, an action data string,
a list containing at least one recognized phrase of the recognized
voice command, and a command string corresponding the recognized
command; an interface that is called when a spoken phrase is
detected by the voice recognition component; and an interface that
receives a type of interference detected by the voice recognition
component.
8. The computer system of claim 5, wherein the application program
interfaces further comprise: an interface that receives a menu
identifier structure, said menu identifier structure comprising an
application name and a state name, a language identifier structure
and a mode flag from an application that causes a voice recognition
system to create a voice command menu identified by the menu
identifier structure; and an interface that receives the menu
identifier structure from an application and that causes the voice
recognition system to delete the voice command menu identified by
the menu identifier structure.
9. In a computing system that includes an application for
responding to voice commands in a limited resource environment, a
method for allowing the application to interface with voice
recognition components, the method comprising: an act of receiving
a handle of a window associated with the at least one voice command
menu and a flag indicating when the menu should be active in
relation to a speech recognition status; an act of receiving a list
of command structures, each of said command structures describing a
voice command, and thereafter returning a number associated with a
first voice command added to the at least one voice command menu;
an act of deactivating the at least one voice command menu; and an
act of receiving a number corresponding to a first voice command
and a number of voice commands to remove and thereafter removing
the number of voice commands from the at least one voice command
menu, said removal starting with the number corresponding to the
first voice command.
10. A method as recited in claim 9, the method further comprising:
an act of receiving an enablement parameter from the application,
said enablement parameter operative to cause the voice recognition
component to enable voice recognition when the enablement parameter
has a first value and to disable voice recognition when the
enablement parameter has a second value; and an act of returning a
second parameter to the application, said second parameter
operative to indicate that voice recognition is enabled when the
second parameter has the first value and that voice recognition is
disabled when the second parameter has the second value.
11. A method as recited in claim 9, the method further comprising:
an act of receiving from the application a first voice command
structure identifying a voice menu and a command string, said voice
command structure having an association with a second application;
an act of receiving an identifier of a recognized voice command, a
second voice command structure identifying a voice menu associated
with the recognized voice command, a verification required flag, an
action data string, a list containing at least one recognized
phrase of the recognized voice command, and a command string
corresponding the recognized command; calling an interface when a
spoken phrase is detected by the voice recognition component; and
an act of receiving a type of interference detected by the voice
recognition component.
12. A method as recited in claim 9, the method further comprising:
an act of receiving a menu identifier structure, said menu
identifier structure comprising an application name and a state
name, a language identifier structure and a mode flag from an
application that causes a voice recognition system to create a
voice command menu identified by the menu identifier structure; and
an act of receiving the menu identifier structure from an
application and that causes the voice recognition system to delete
the voice command menu identified by the menu identifier
structure.
13. A computer program product for use in a computing system that
includes an application for responding to voice commands in a
limited resource environment and for implementing a method for
allowing the application to interface with voice recognition
components, the computer program product comprising one or more
computer-readable media having computer-executable instructions for
implementing the method, the method comprising: an act of receiving
a handle of a window associated with the at least one voice command
menu and a flag indicating when the menu should be active in
relation to a speech recognition status; an act of receiving a list
of command structures, each of said command structures describing a
voice command, and thereafter returning a number associated with a
first voice command added to the at least one voice command menu;
an act of deactivating the at least one voice command menu; and an
act of receiving a number corresponding to a first voice command
and a number of voice commands to remove and thereafter removing
the number of voice commands from the at least one voice command
menu, said removal starting with the number corresponding to the
first voice command.
14. A computer program product as recited in claim 13, wherein the
method further comprises: an act of receiving an enablement
parameter from the application, said enablement parameter operative
to cause the voice recognition component to enable voice
recognition when the enablement parameter has a first value and to
disable voice recognition when the enablement parameter has a
second value; and an act of returning a second parameter to the
application, said second parameter operative to indicate that voice
recognition is enabled when the second parameter has the first
value and that voice recognition is disabled when the second
parameter has the second value.
15. A computer program product as recited in claim 13, wherein the
method further comprises: an act of receiving from the application
a first voice command structure identifying a voice menu and a
command string, said voice command structure having an association
with a second application; an act of receiving an identifier of a
recognized voice command, a second voice command structure
identifying a voice menu associated with the recognized voice
command, a verification required flag, an action data string, a
list containing at least one recognized phrase of the recognized
voice command, and a command string corresponding the recognized
command; calling an interface when a spoken phrase is detected by
the voice recognition component; and an act of receiving a type of
interference detected by the voice recognition component.
16. A computer program product as recited in claim 13, wherein the
method further comprises: an act of receiving a menu identifier
structure, said menu identifier structure comprising an application
name and a state name, a language identifier structure and a mode
flag from an application that causes a voice recognition system to
create a voice command menu identified by the menu identifier
structure; and an act of receiving the menu identifier structure
from an application and that causes the voice recognition system to
delete the voice command menu identified by the menu identifier
structure.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation application of
commonly-assigned U.S. patent application Ser. No. 09/560,546 filed
Apr. 28, 2000, entitled "Application Program Interfaces and
Structures in a Resource Limited Operating System". That patent
application is a divisional application of U.S. Pat. No. 6,671,745
entitled "Application Program Interfaces and Structures in a
Resource Limited Operating System" issued Dec. 30, 2003, and claims
priority to U.S. provisional patent application Ser. No. 60/078,946
also entitled "Application Program Interfaces and Structures in a
Resource Limited Operating System" filed Mar. 23, 1998, and which
are incorporated herein by reference.
COPYRIGHT NOTICE/PERMISSION
[0002] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever. The following notice
applies to the software and data as described below and in the
drawing hereto: Copyright @ 1998, 1999, Microsoft Corporation, All
Rights Reserved.
BACKGROUND OF THE INVENTION
[0003] 1. The Field of the Invention
[0004] This invention relates generally to computer operating
systems, and more particularly to application program interfaces
for resource limited operating systems.
[0005] 2. Background and Relevant Art
[0006] The rapid evolution of personal computer technology
continues to produce personal computers (PCs) that are smaller,
cheaper and faster than their predecessors. Where computers once
occupied entire rooms, they are now small enough to fit in the palm
of a user's hand, hence the name "Palm-size PCs". In addition, PCs
are now small enough to be placed in environments outside of the
home or office, such as an automobile. Further more, the new PCs
may be embedded in a variety of consumer devices and specialized
industrial controllers. For the purposes of this application, all
of the above-referenced PCs will be referred to collectively as
"embedded systems."
[0007] The reduced size of embedded systems means that certain
sacrifices need to be made. For example, a typical embedded system
does not have fixed or removable disk drives such as hard disk,
floppy disk, CD-ROM or DVD-ROM drives, with the persistent storage
of a typical embedded system comprising flash memory or volatile
memory with a battery refresh. In addition, the amount of RAM in
the typical embedded system is also limited.
[0008] In addition, output resources typical to a desktop PC may be
missing or severely limited in an embedded system. For example, the
display for a typical embedded system may comprise a small LCD
screen with limited resolution and capable of displaying only
grayscale or a limited number of colors. In certain environments,
such as the automobile, the display may be an LCD screen with a
limited number of fixed icons and text areas. The display may be
augmented with a computerized speech facility.
[0009] Similarly, input resources may be limited or adapted for use
in embedded systems. For example, many embedded systems do not have
a mouse or other pointing device. In addition, some hand-held
devices do not have a physical keyboard. Such embedded devices may
use a touch sensitive display in conjunction with a virtual
keyboard placed on the display. In addition, embedded devices may
employ speech recognition for input.
[0010] As a result of the above, specialized operating systems
capable of running in the resource-limited environment of the
embedded system have been developed. An example of such an
operating system is the Windows CETM operating system from
Microsoft Corporation.
[0011] Applications running on the embedded system must also be
capable of running in the resource limited environment described
above. In embedded systems comprising Palm-size PCs, these
applications are typically specialized versions of applications
available on the bigger siblings of the Palm-size PC, such as
calendar programs, personal information managers, calculators,
dictionaries and the like.
[0012] In other environments, the applications running on the
embedded system may be more specialized. For example, in an AutoPC,
the applications may comprise applications that interface with an
audio system, applications that report and use position and
navigation information, and applications that monitor the condition
and state of various other systems present in the automobile.
[0013] In order to accommodate a large number of different
application needs, operating systems typically provide APIs
(Application Programming Interfaces) to a wide variety of
functionality that is common to many differing applications. Anyone
application generally uses only a small subset of the available
APIs. Providing a wide variety of APIs frees application developers
from having to write code that would have to be potentially
duplicated in each application. However, in the resource limited
environment of the embedded system, there is typically a much more
limited set of APIs available. This is because there is generally
insufficient persistent and non-persistent memory available to
support a large number of different APIs. Thus, a developer writing
an application for an embedded system may find that he or she must
develop code that would ordinarily be provided by the operating
system in a desktop's or other larger computer's operating
system.
[0014] As a result of the above, there is a need in the art for an
operating system capable of running in the resource limited
environment of an embedded system. Such an operating system should
be customizable and adaptable to the wide variety environments that
system designers may choose to place embedded systems, allowing
developers to include only those components and modules that are
necessary for a particular environment. In addition, the operating
system should include APIs to operating system provided components
in order prevent applications designers from having to duplicate
commonly needed code. Finally, the operating system should provide
APIs for components and modules that meet the unique input and
output needs of an embedded system.
BRIEF SUMMARY OF THE INVENTION
[0015] The above-mentioned shortcomings, disadvantages and problems
are addressed by the present invention, which will be understood by
reading and studying the following specification.
[0016] A system is presented that includes a set of Application
Program Interfaces (APIs) for a number of software modules and
components for resource limited environments. One example of a
resource limited environment is the embedded system, which
comprises a variety of consumer devices and specialized industrial
controllers, along with hand-held, or palm-size personal
computers.
[0017] One aspect of the system is that the combination of
components and modules included in an operating system for resource
limited environments is customizable and flexible. This allows an
embedded system designer -to include only those components and
modules that are necessary for a particular environment. As a
result, scarce memory is not consumed by unneeded components,
allowing more memory to be devoted to applications and other
modules and components that are needed in the embedded system.
[0018] Another aspect of the system is that APIs are provided that
meet the unique input and output needs of the typical embedded
system. For example, many embedded systems do not provided a
keyboard or mouse for input. The system provides APIs to components
and modules that provide alternative mechanisms of providing input.
These alternative mechanisms include APIs to handwriting
recognition engines that "read" strokes on a touch sensitive
screen, and APIs to voice input components that allow a user to
issue spoken commands to the system. Further, the system provides
APIs to components that output audible speech for those
environments where a display monitor is impractical.
[0019] Another aspect of the system is that the handling of "out of
memory" conditions is customizable by an embedded system designer.
This is important to systems with limited resources, because out of
memory conditions are more likely to occur.
[0020] A further aspect of the system is that an API to a position
and navigation component is provided. This is useful for embedded
system environments that are mobile, such as automobiles, trucks,
and boats.
[0021] The APIs summarized above, and various other APIs, will be
described in detail in the next section and in the attached
appendices.
[0022] The present invention describes systems, clients, servers,
methods, and computer-readable media of varying scope. In addition
to the aspects and advantages of the present invention described in
this summary, further aspects and advantages of the invention will
become apparent by reference to the drawings and by reading the
detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0023] In order to describe the manner in which the above-recited
and other advantages and features of the invention can be obtained,
a more particular description of the invention briefly described
above will be rendered by reference to specific embodiments thereof
which are illustrated in the appended drawings. Understanding that
these drawings depict only typical embodiments of the invention and
are not therefore to be considered to be limiting of its scope, the
invention will be described and explained with additional
specificity and detail through the use of the accompanying drawings
in which:
[0024] FIG. 1 shows a diagram of the hardware and operating
environment in conjunction with which embodiments of the invention
may be practiced;
[0025] FIG. 2 is a diagram illustrating a system-level overview of
exemplary embodiments of an operating system for a resource limited
environment; and
[0026] FIG. 3 is a diagram further illustrating the relationship of
modules, components and APIs according to an embodiment of the
invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0027] In the following detailed description of exemplary
embodiments of the invention, reference is made to the accompanying
drawings and the appendices on CD-ROM that form a part hereof, and
in which is shown by way of illustration specific exemplary
embodiments in which the invention may be practiced. These
embodiments are described in sufficient detail to enable those
skilled in the art to practice the invention, and it is to be
understood that other embodiments may be utilized and that logical,
mechanical, electrical and other changes may be made without
departing from the spirit or scope of the present invention. The
following detailed description is, therefore, not to be taken in a
limiting sense, and the scope of the present invention is defined
only by the appended claims.
[0028] The detailed description is divided into four sections. In
the first section, the hardware and the operating environment in
conjunction with which embodiments of the invention may be
practiced are described. In the second section, a system level
overview of the invention is presented. In the third section,
various APIs are presented allowing applications to interface with
various modules and components of an operating system. Finally, in
the fourth section, a conclusion of the detailed description is
provided.
Hardware and Operating Environment
[0029] FIG. 1 is a diagram of the hardware and operating
environment in conjunction with which embodiments of the invention
may be practiced. The description of FIG. 1 is intended to provide
a brief, general description of suitable computer hardware and a
suitable computing environment in conjunction with which the
invention may be implemented. Although not required, the invention
is described in the general context of computer-executable
instructions, such as program modules, being executed by a
computer, such as a personal computer, a hand-held or palm-size
computer, or an embedded system such as a computer in a consumer
device or specialized industrial controller. Generally, program
modules include routines, programs, objects, components, data
structures, etc., that perform particular tasks or implement
particular abstract data types.
[0030] Moreover, those skilled in the art will appreciate that the
invention may be practiced with other computer system
configurations, including hand-held devices, multiprocessor
systems, microprocessor-based or programmable consumer electronics,
network PCS, minicomputers, mainframe computers, and the like. The
invention may also be practiced in distributed computing
environments where tasks are performed by remote processing devices
that are linked through a communications network. In a distributed
computing environment, program modules may be located in both local
and remote memory storage devices.
[0031] The exemplary hardware and operating environment of FIG. 1
for implementing the invention includes a general purpose computing
device in the form of a computer 20, including a processing unit
21, a system memory 22, and a system bus 23 that operatively
couples various system components including the system memory to
the processing unit 21. There may be only one or there may be more
than one processing unit 21, such that the processor of computer 20
comprises a single central-processing unit (CPU), or a plurality of
processing units, commonly referred to as a parallel processing
environment. The computer 20 may be a conventional computer, a
distributed computer, or any other type of computer; the invention
is not so limited.
[0032] The system bus 23 may be any of several types of bus
structures including a memory bus or memory controller, a
peripheral bus, and a local bus using any of a variety of bus
architectures. The system memory may also be referred to as simply
the memory, and includes read only memory (ROM) 24 and random
access memory (RAM) 25. A basic input/output system (BIOS) 26,
containing the basic routines that help to transfer information
between elements within the computer 20, such as during start-up,
is stored in ROM 24. In one embodiment of the invention, the
computer 20 further includes a hard disk drive 27 for reading from
and writing to a hard disk, not shown, a magnetic disk drive 28 for
reading from or writing to a removable magnetic disk 29, and an
optical disk drive 30 for reading from or writing to a removable
optical disk 31 such as a CD ROM or other optical media. In
alternative embodiments of the invention, the functionality
provided by the hard disk drive 27, magnetic disk 29 and optical
disk drive 30 is emulated using volatile or non-volatile RAM in
order to conserve power and reduce the size of the system. In these
alternative embodiments, the RAM may be fixed in the computer
system, or it may be a removable RAM device, such as a Compact
Flash memory card.
[0033] In an embodiment of the invention, the hard disk drive 27,
magnetic disk drive 28, and optical disk drive 30 are connected to
the system bus 23 by a hard disk drive interface 32, a magnetic
disk drive interface 33, and an optical disk drive interface 34,
respectively. The drives and their associated computer-readable
media provide nonvolatile storage of computer-readable
instructions, data structures, program modules and other data for
the computer 20. It should be appreciated by those skilled in the
art that any type of computer-readable media which can store data
that is accessible by a computer, such as magnetic cassettes, flash
memory cards, digital video disks, Bernoulli cartridges, random
access memories (RAMs), read only memories (ROMs), and the like,
may be used in the exemplary operating environment.
[0034] A number of program modules may be stored on the hard disk,
magnetic disk 29, optical disk 31, ROM 24, or RAM 2S, including an
operating system 3S, one or more application programs 36, other
program modules 37, and program data 38. A user may enter commands
and information into the personal computer 20 through input devices
such as a keyboard 40 and pointing device 42. Other input devices
(not shown) may include a microphone, joystick, game pad, satellite
dish, scanner, touch sensitive pad, or the like. These and other
input devices are often connected to the processing unit 21 through
a serial port interface 46 that is coupled to the system bus, but
may be connected by other interfaces, such as a parallel port, game
port, or a universal serial bus (USB). In addition, input to the
system may be provided by a microphone to receive audio input.
[0035] A monitor 47 or other type of display device is also
connected to the system bus 23 via an interface, such as a video
adapter 48. In one embodiment of the invention, the monitor
comprises a Liquid Crystal Display (LCD). In addition to the
monitor, computers typically include other peripheral output
devices (not shown), such as speakers and printers.
[0036] The computer 20 may operate in a networked environment using
logical connections to one or more remote computers, such as a
remote computer 49. These logical connections are achieved by a
communication device coupled to or a part of the computer 20; the
invention is not limited to a particular type of communications
device. The remote computer 49 may be another computer, a server, a
router, a network PC, a client, a peer device or other common
network node, and typically includes many or all of the elements
described above relative to the computer 20, although only a memory
storage device 50 has been illustrated in FIG. 1. The logical
connections depicted in FIG. 1 include a local-area network (LAN)
51 and a wide-area network (WAN) 52. Such networking environments
are commonplace in offices, enterprise-wide computer networks,
intranets and the Internet.
[0037] When used in a LAN-networking environment, the computer 20
is connected to the local network 51 through a network interface or
adapter 53, which is one type of communications device. When used
in a WAN-networking environment, the computer 20 typically includes
a modem 54, a type of communications device, or any other type of
communications device for establishing communications over the wide
area network 52, such as the Internet. The modem 54, which may be
internal or external, is connected to the system bus 23 via the
serial port interface 46. In a networked environment, program
modules depicted relative to the personal computer 20, or portions
thereof, may be stored in the remote memory storage device. It is
appreciated that the network connections shown are exemplary and
other means of and communications devices for establishing a
communications link between the computers may be used.
[0038] The hardware and operating environment in conjunction with
which embodiments of the invention may be practiced has been
described. The computer in conjunction with which embodiments of
the invention may be practiced may be a conventional computer an
hand-held or palm-size computer, a computer in an embedded system,
a distributed computer, or any other type of computer; the
invention is not so limited. Such a computer typically includes one
or more processing units as its processor, and a computer-readable
medium such as a memory. The computer may also include a
communications device such as a network adapter or a modem, so that
it is able to communicatively couple other computers.
System Level Overview
[0039] A system level overview of the operation of an exemplary
embodiment of the invention is described by reference to FIGS. 2
and 3. The concepts of the invention are described as operating in
a multiprocessing, multithreaded operating environment on a
computer, such as computer 20 in FIG. 1. The exemplary operating
environment comprises what is known in the art as an operating
system. In this environment one or more applications, such
application 226, interface with various modules and components of
the operating system. In addition, the various modules and
components of the operating system interface with each other.
Finally, the modules, components and applications interface with
hardware 202 present on the computer through what is known in the
art as a device driver module, and through an Original Equipment
Manufacturer (OEM) adaptation layer 208. In one embodiment of the
invention, there are two types of device drivers, built-in drivers
206 and installable drivers 204. The various modules will now be
described in further detail.
[0040] The core system interface 220 is the module through which
applications can access the operating system. The core system
interface 220 includes functions to transfer API calls to the
appropriate operating system server process. In addition to
including or exporting the APIs selected, the core system interface
220 includes components to support the following:
[0041] Localization
[0042] Local heap and memory allocation
[0043] Serial port device driver thunks
[0044] Telephony API (T API)
[0045] The shell module 222 manages the user interface and handles
such tasks as launching software applications. In one embodiment of
the invention, the operating system provides shell components that
enable an embedded system designer to develop a customized shell
222 that satisfies the requirements of the target platform.
Included in these components are:
[0046] A Control Panel with applets familiar to desktop Windows
users. The following applets are included: Communications; Display;
Keyboard; Network; Owner; Password; Power; Regional Settings,
Remove Programs; Pointing Device Settings (Stylus); Sounds and
Volume.
[0047] A Notification API that lets an application register its
name and an event with the system. When the event occurs, the
kernel will automatically start the named application. The API also
allows an application to register a specific date and time at which
the application should start.
[0048] Common controls and common dialogs, which are designed to
provide to the user clear, simple, and meaningful information and a
means to furnish input to the system and applications as
needed.
[0049] A command line processor (that is, a console application)
that supports a set of standard input and output API calls.
[0050] Connectivity components (for example, to support remote
application programming calls) between the development workstation
and the embedded system target platform.
[0051] In conjunction with a desktop, the shell module 222 also
includes a desktop and task manager component that can be
optionally included or replaced. The task manager component
includes the following basic functionality:
[0052] An Active Tasks list of all the currently running, top-level
applications;
[0053] A Run button that allows a user to launch a software
application;
[0054] A Switch To button that allows a user to switch to an
application selected in the Active Tasks listbox.
[0055] An End Task button that allows a user to terminate an
application selected in the Active Tasks listbox.
[0056] A Cancel button that allows a user to close the Task-Manager
window.
[0057] Monitors the level of main battery and backup battery power
(for battery-operated target platforms) and displays an appropriate
warning dialog box.
[0058] Monitors system memory usage in the system and sends a
message to all top-level windows when the available system memory
drops below a specific threshold. This allows applications to
respond to the message by reducing their memory usage as much as
possible.
[0059] The Add-on Technologies module 224 allows an embedded system
developer to optionally include components such as OLE/COM
automation that supports development of ActiveX-based applications,
an active desktop shell and an Internet browser. Other components
that can be included are Visual Basic run-time and Java script, and
a subset of the Microsoft Foundation Classes (MFC). A further
optional component that can be provided is a handwriting
recognition engine with associated APIs. In one embodiment of the
invention, handwriting applications interface with a touch
sensitive input device through a component providing a software
interface to the touch sensitive device.
[0060] The kernel module 214 represents the base operating system
functionality that must be present on all platforms. The kernel
module includes memory management, process management, exception
handling, and support for multitasking and multithreading.
[0061] In one embodiment of the invention, the kernel 214 is
designed specifically for small, fast, embedded devices. In this
embodiment, the kernel supports a single 4GB address space (a 2GB
virtual address and a 2GB physical address range). In an embodiment
of the invention, this 4GB address space is divided into 33
"slots", each of which has a size of 32MB. The kernel protects each
process by assigning each process to a unique, open slot in memory.
The invention, however, is not limited to any particular physical
or virtual address space or slot size, and other sizes may be
chosen as those of skill in the art will recognize.
[0062] The kernel 214 protects applications-from accessing memory
outside of their allocated slot by generating an exception.
Applications can check for and handle such exceptions by using the
try and except Windows CE functions. In one embodiment of the
invention, the system is limited to 32 processes, but the number of
threads running in a process is limited only by the amount of
available memory. Those of skill in the art will appreciate that
other values for the maximum number of processes could be
chosen.
[0063] The file system module 218 contains the functions that
support persistent storage on the embedded system target platform.
This storage is referred to as the "object store" and includes
three different ways to store user data:
[0064] The file system. The file system typically supports common
file manipulation functions, such as functions to create files and
directories, read and write to files, and retrieve file and
directory information.
[0065] The registry. The system registry is similar to the
registries of the Windows 95 and Windows NT operating systems. The
registry for all applications, including the applications bundled
in ROM, is stored in the object store.
[0066] The Database API. The operating system, in one embodiment of
the invention, has its own structured storage to offer an
alternative to exposing user and application data in files or the
registry. For example, a database is useful for storing raw data
that an application will process before displaying to the end-user.
Hand-held PC applications typically store schedule and contact
information in databases.
[0067] In one embodiment of the invention, the file system managed
by file system module 218 is a transactioned system to reduce the
possibility that data will be lost due to a critical failure, such
as loss of power. Additionally, in one embodiment of the invention,
the file system module 218 implements a scheme (transactioned) of
"mirroring" to mirror or track file system operations (not
transactioned). The purpose for this implementation is to be able
to restore a file system volume in the case that power is lost
during a critical sequence of operations being performed on the
volume.
[0068] In one embodiment of the invention, the operating
environment combines the Win32 User and GDI (Graphics Device
Interface) libraries into a GWES (Graphics, Windowing, and Events
Subsystem) module 212. The event manager and window manager are
analogous to Win32 User, and the Win32 GDI is replaced with a
smaller GDI more suitable to embedded systems. The GWES module 212
includes multiplatform GDI components (supporting an associated
display driver) that support color and grayscale display, palette
management, True Type fonts, Raster fonts, cursors, and printer
device contexts (DCs).
[0069] The GWES module 212 also supports a window management
component that provides API functions tailored for the smaller
display sizes typical of embedded operating systems.
[0070] The operating environment of various embodiments of the
invention is event-driven. GWES module includes components to
handle events, which in one embodiment of the invention are
implemented as messages.
[0071] Communications module 216 includes a variety of
communications component options to support communications
hardware. This includes serial, parallel, and network (wired and
wireless) communications. Communications module 216 includes the
following selectable communications features:
[0072] Serial I/O support
[0073] Networking support including:
[0074] NDIS 4.0 for local area networking
[0075] PPP and SLIP for serial link and modem networking
[0076] Client-side Remote Access server (RAS)
[0077] Internet protocols
[0078] Telephony API (T APO)
[0079] PC Card support
[0080] Infrared transceiver support
[0081] In one embodiment of the invention, an embedded systems
designer must develop the OEM adaptation layer 208 to create the
platform specific kernel module 214. The OEM Adaptation Layer (OAL)
module 208 allows an embedded system developer to adapt the
operating system for a specific target platform by creating a thin
layer of code that resides between the kernel module 214 and the
target platform hardware 202. The OAL module 208 is specific for a
particular CPU and target platform.
[0082] The OAL module 208 includes interfaces such as the
following:
[0083] Interrupt service routine (ISR) handlers to support device
drivers
[0084] Real-time clock (RTC)
[0085] Interval timer (used for the scheduler operation)
[0086] In one embodiment of the invention, the RTC and interval
timer does not need to be adapted because it is provided on the
CPU. In this case, these interfaces are implemented in the kernel
module 214 rather than in the OAL 208.
[0087] In addition to managing such functions as timing and power,
the primary purpose of the OAL is to expose the target platform's
hardware 202 to the kernel module 214. That is, each hardware
interrupt request line (IRQ) is associated with one interrupt
service routine (ISR). When interrupts are enabled and an interrupt
occurs, the kernel calls the registered ISR for that interrupt.
[0088] Built in drivers 206 are device drivers that are linked with
GWES module 212 when building the operating system. Examples of
such drivers are the notification LED driver or the battery driver.
These drivers are called "built-in device drivers" because they
ultimately form part of the same executable image as the rest of
the operating system. Built-in device drivers each have a custom
interface to the rest of operating system.
[0089] Device Manager module 210 is a module that handles
installable device drivers. In one embodiment of the invention, The
Device Manager 210 performs the following tasks:
[0090] Initiates the loading of a driver at system start up, or
when it receives a notification that a third-party peripheral has
been attached to the target platform. For example, when a PC Card
is inserted, Device Manager 210 will attempt to locate and load a
device driver for that PC Card.
[0091] Registers special filesystem entries with the kernel that
map the Stream I/O Interface functions used by applications to the
implementation of those functions in an installable device
driver.
[0092] Finds the appropriate device driver by obtaining a Plug and
Play ill or by invoking a detection routine to find a driver that
can handle the device.
[0093] Loads and tracks drivers by reading and writing registry
values.
[0094] Unloads drivers when their devices are no longer needed. For
example, Device Manager 210 will unload a PC Card device driver
when the card is removed.
[0095] In one embodiment of the invention, Installable Device
Drivers 204 exist as standalone DLLs (Dynamic Link Library) that
are managed by the Device Manager 210. Installable device drivers
204 support some types of native devices, any peripheral devices
that can be connected to the target platform, and any special
purpose devices that are added to the platform. This covers devices
such as modems, printers, digital cameras, PC Cards (also known as
PCMCIA cards), and others.
[0096] In one embodiment of the invention; installable device
drivers 204 use a common interface by which their services are
exposed to applications. This interface is the Stream I/O
Interface.
[0097] A description of the relationships between components,
modules and the APIs they expose to applications is presented with
reference to FIG. 3. A module 308 is a major functional block of an
operating environment such as operating system 200 of FIG. 2.
Module 308 exposes an API 302 to applications such as application
226 of FIG. 2 that allows the application to interface and call
methods or functions implemented by the module 308.
[0098] Modules may optionally include one or more components 306.
Components 306 are groups of functions and data that provide
capabilities on a smaller scale than modules 308. Like a module
308, a component 306 also exposes an API 304 that other
applications, modules, and components may use to call methods or
functions implemented by the component 306.
[0099] As can be seen from the discussion above, the various
embodiments of the invention provide advantages over prior systems.
One benefit is that the operating system is modular. This allows an
embedded system designer to create an operating environment that is
optimized for their unique hardware development platform and
application. The developer can select varying combinations of the
above-described modules and components for inclusion in the
operating environment. For example, a developer can build an
embedded operating system that contains the kernel and a selected
set of communications but does not provide a graphical user
interface. Thus, the invention is not limited to any particular
combination of modules and components.
[0100] The various embodiments of the invention also provides a
mechanism for developers to conserve the limited memory resources
of a typical embedded system, because only those modules and
components having APIs that are necessary for the operating
environment need be included.
APIs in a Resource Limited System
[0101] The previous section presented a system level overview of
modules and components included in a typical operating system for a
system with limited resources. This section, along with the
attached appendices on CD-ROM, present novel APIs and data
structures related to the modules and components described above.
The APIs detailed below and in the attached appendices on CD-ROM
are described in terms of the C/C++ programming language. However,
the invention, is not so limited, and the APIs may be defined and
implemented in any programming language, as those of skill in the
art will recognize. Furthermore, the names given to the API
functions and parameters are meant to be descriptive of their
function, however other names or identifiers could be associated
with the functions and parameters, as will be apparent to those of
skill in the art. Six sets of APIs and data structures will be
presented: Handwriting Recognition APIs, Position and Navigation
APIs, Speech related APIs, Out of Memory APIs, Database APIs and
Active Synch Data Structures.
[0102] 1. Handwriting Recognition APIs
[0103] A handwriting recognition component is available in the
Add-On Technologies module 224 (FIG. 2). The handwriting
recognition component implements a handwriting recognition engine.
In one embodiment of the invention, the engine receives "ink" in
the form of a plurality of strokes on a touch sensitive screen. The
strokes are then sent from applications to the engine using a
variety of APIs. The engine then attempts to interpret the strokes
as alphanumeric characters. The interpreted characters are returned
to the application via an API. In one embodiment of the invention,
the characters are interpreted as English language characters. In
alternative embodiments of the invention, the characters are
interpreted in other languages.
[0104] The handwriting recognition component is particularly useful
in embedded systems that have a touch sensitive display, but no
keyboard. Applications that require alphanumeric input can use the
characters received from the engine as if they had been typed at a
keyboard.
[0105] Further details on the APIs used by applications that
interface with a handwriting recognition engine are presented in
Appendix G on CD-ROM.
[0106] 2. Position and Navigation APIs and Data Structures
[0107] A Position and Navigation component is available in the
Add-On Technologies module. The Position and Navigation component
allows an application to interface with a positioning device (also
referred to as a positioning and navigation device) such as an
Apollo GPS system. Such an interface is useful when the embedded
system is located in a mobile article such as an automobile or
truck. In one embodiment of the invention, the embedded system is
the AutoPC.
[0108] Further details on the APIs for the Position and Navigation
module are found in Appendix E on CD-ROM. Also, further details on
data structures used by the Position and Navigation Module and
related APIs are found in Appendix F on CD-ROM.
[0109] 3. Speech Related APIs
[0110] The Add-On Technologies module contains several
speech-related components that expose APIs for application use.
These components include a text-to-speech component, a
voice-to-text component, and a voice command component. In general,
these components are intended for environments where input and
output devices are limited, and where a user's interaction with the
embedded system is via speech. An example of such an environment is
the AutoPC. Because the driver must use their hands in the
operation of the automobile, interaction with the AutoPC is via a
speech interface, where input commands are spoken by the user, and
output from the PC is converted from text to speech.
[0111] Further details on the text-to-speech APIs are presented in
the Appendix H on CD-ROM. Further details on the voice command and
speech to text APIs are presented in Appendices I, J and K on
CD-ROM.
[0112] 4. Out of Memory API
[0113] The Out of Memory API is a component of the OWES module.
This component allows an embedded system developer to replace the
default action that occurs when the operating system detects that
the system is running out of available memory in which to run
applications or place data.
[0114] The Out of Memory component is significant to an operating
system intended for limited resource environments, because the
condition is more likely to occur in an embedded system than in a
desk-top system. The API exposed provides a standardized way for
the operating system to call customized software that meets the
specific needs of an embedded system developer.
[0115] Further details on the out of memory API are presented in
Appendix L on CD-ROM.
[0116] 5. Database API
[0117] As discussed above in reference to FIG. 2, the file system
module 218 may optionally include a database component. The
database component allows applications to create and maintain
databases as file system objects. Applications make calls to
various API functions that maintain the database. These functions
include functions that create new databases, open existing
database, delete databases, seeks particular records in databases,
read records from databases and write records to databases. In
addition, the Database API includes functions that navigate through
a list of databases of a given type. Further details regarding the
Database API are presented in Appendix C on CD-ROM.
[0118] 6. ActiveSync Data Structures
[0119] ActiveSync is a component available in the Add-On
Technologies module. The ActiveSync component provides a service
that allows applications to compare two objects to determine if one
of the objects needs to be updated in order for the objects to be
"synchronized", that is, the same. Typically the objects are file
system objects containing application data. ActiveSync is
particularly useful when applied to hand-held PCs. This is because
the user often will update data maintained in a file system object
on the hand-held PC, and then need to update a file on a desk-top
PC so that the two files contain the same data. For example,
hand-held PCs typically provide an application such as a Personal
Information Manager that maintains a database of information,
including telephone numbers. If a user maintains a similar database
of telephone numbers on both their hand-held PC and their desk-top
PC, it is desirable that the two telephone directories reflect
updates made to either the hand-held PC or desk-top PC database.
ActiveSync allows a user to accomplish this.
[0120] In one embodiment of the invention, several data structures
are employed that enable ActiveSync to correctly compare and
perform updates to corresponding objects. The first data structure
is the CONFINFO data structure. This data structure is used to
retrieve information about two potentially conflicting items. In
one embodiment of the invention, an ActiveSync Server presents the
information in the CONFINFO data structure to a user via a dialogue
box to allow the user to choose an option for resolving the
conflict. Further details regarding the CONFINFO data structure are
presented in Appendix A on CD-ROM.
[0121] A second data structure used by the. Active Synch component
is the OBJNOTIFY structure. The OBJNOTIFY data structure is used to
notify the ActiveSync service provider that an object in the file
system has changed or been deleted. Further details regarding the
OBJNOTIFY data structure are presented in Appendix A on CD-ROM.
Conclusion
[0122] APIs for modules and components of a resource-limited
operating system have been described. The APIs provide access to
specialized hardware and software that is desirable in such
limited-resource systems.
[0123] Although specific embodiments have been illustrated and
described herein, it will be appreciated by those of ordinary skill
in the art that any arrangement which is calculated to achieve the
same purpose may be substituted for the specific embodiments shown.
This application is intended to cover any adaptations or variations
of the present invention.
[0124] For example, those of ordinary skill within the art will
appreciate that while the embodiments of the invention have been
described as being implemented in a resource-limited environment,
the principles of the invention are applicable to other
environments. For example, the voice command APIs can be adapted to
standard desk-top operating system to aid user's who have
difficulty using a conventional keyboard and mouse to provide input
to a system.
[0125] Furthermore, while some examples in the detailed description
above are discussed in terms of the Windows CE operating system,
the systems, methods and APIs of the invention may be applied to
any operating system.
[0126] The terminology used in this application is meant to include
all of these environments. Therefore, it is manifestly intended
that this invention be limited only by the following claims and
equivalents thereof.
* * * * *