US20050102687A1 - Application program interfaces and structures in a resource limited operating system - Google Patents

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• 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
• 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
• 1. The Field of the Invention
• This invention relates generally to computer operating systems, and more particularly to application program interfaces for resource limited operating systems.
• 2. Background and Relevant Art
• 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.”
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification.
• 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.
• 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.
• 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.
• 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.
• 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.
• The APIs summarized above, and various other APIs, will be described in detail in the next section and in the attached appendices.
• 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
• 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:
• FIG. 1 shows a diagram of the hardware and operating environment in conjunction with which embodiments of the invention may be practiced;
• FIG. 2 is a diagram illustrating a system-level overview of exemplary embodiments of an operating system for a resource limited environment; and
• 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
• 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.
• 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
• FIG. 1 is a diagram of the hardware and operating environment in conjunction with which embodiments of the invention may be practiced. The description ofFIG. 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.
• 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.
• The exemplary hardware and operating environment ofFIG. 1 for implementing the invention includes a general purpose computing device in the form of acomputer20, including aprocessing unit21, asystem memory22, and asystem bus23 that operatively couples various system components including the system memory to theprocessing unit21. There may be only one or there may be more than oneprocessing unit21, such that the processor ofcomputer20 comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment. Thecomputer20 may be a conventional computer, a distributed computer, or any other type of computer; the invention is not so limited.
• Thesystem bus23 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 thecomputer20, such as during start-up, is stored inROM24. In one embodiment of the invention, thecomputer20 further includes ahard disk drive27 for reading from and writing to a hard disk, not shown, amagnetic disk drive28 for reading from or writing to a removablemagnetic disk29, and anoptical disk drive30 for reading from or writing to a removableoptical disk31 such as a CD ROM or other optical media. In alternative embodiments of the invention, the functionality provided by thehard disk drive27,magnetic disk29 andoptical disk drive30 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.
• In an embodiment of the invention, thehard disk drive27,magnetic disk drive28, andoptical disk drive30 are connected to thesystem bus23 by a harddisk drive interface32, a magneticdisk drive interface33, and an opticaldisk drive interface34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for thecomputer20. 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.
• A number of program modules may be stored on the hard disk,magnetic disk29,optical disk31,ROM24, or RAM2S, including an operating system3S, one ormore application programs36,other program modules37, andprogram data38. A user may enter commands and information into thepersonal computer20 through input devices such as akeyboard40 andpointing device42. 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 theprocessing unit21 through aserial port interface46 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.
• Amonitor47 or other type of display device is also connected to thesystem bus23 via an interface, such as avideo adapter48. 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.
• Thecomputer20 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer49. These logical connections are achieved by a communication device coupled to or a part of thecomputer20; the invention is not limited to a particular type of communications device. Theremote computer49 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 thecomputer20, although only amemory storage device50 has been illustrated inFIG. 1. The logical connections depicted inFIG. 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.
• When used in a LAN-networking environment, thecomputer20 is connected to thelocal network51 through a network interface oradapter53, which is one type of communications device. When used in a WAN-networking environment, thecomputer20 typically includes amodem54, a type of communications device, or any other type of communications device for establishing communications over the wide area network52, such as the Internet. Themodem54, which may be internal or external, is connected to thesystem bus23 via theserial port interface46. In a networked environment, program modules depicted relative to thepersonal computer20, 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.
• 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
• A system level overview of the operation of an exemplary embodiment of the invention is described by reference toFIGS. 2 and 3. The concepts of the invention are described as operating in a multiprocessing, multithreaded operating environment on a computer, such ascomputer20 inFIG. 1. The exemplary operating environment comprises what is known in the art as an operating system. In this environment one or more applications,such application226, 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 withhardware202 present on the computer through what is known in the art as a device driver module, and through an Original Equipment Manufacturer (OEM)adaptation layer208. In one embodiment of the invention, there are two types of device drivers, built-indrivers206 andinstallable drivers204. The various modules will now be described in further detail.
• Thecore system interface220 is the module through which applications can access the operating system. Thecore system interface220 includes functions to transfer API calls to the appropriate operating system server process. In addition to including or exporting the APIs selected, thecore system interface220 includes components to support the following:
• • Localization
  • Local heap and memory allocation
  • Serial port device driver thunks
  • Telephony API (T API)
• Theshell module222 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 customizedshell222 that satisfies the requirements of the target platform. Included in these components are:
• • 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.
  • 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.
  • 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.
  • A command line processor (that is, a console application) that supports a set of standard input and output API calls.
  • Connectivity components (for example, to support remote application programming calls) between the development workstation and the embedded system target platform.
• In conjunction with a desktop, theshell module222 also includes a desktop and task manager component that can be optionally included or replaced. The task manager component includes the following basic functionality:
• • An Active Tasks list of all the currently running, top-level applications;
  • A Run button that allows a user to launch a software application;
  • A Switch To button that allows a user to switch to an application selected in the Active Tasks listbox.
  • An End Task button that allows a user to terminate an application selected in the Active Tasks listbox.
  • A Cancel button that allows a user to close the Task-Manager window.
  • Monitors the level of main battery and backup battery power (for battery-operated target platforms) and displays an appropriate warning dialog box.
  • 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.
• The Add-onTechnologies module224 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.
• Thekernel module214 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.
• In one embodiment of the invention, thekernel214 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.
• Thekernel214 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 to32 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.
• Thefile system module218 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:
• • 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.
  • 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.
  • 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.
• In one embodiment of the invention, the file system managed byfile system module218 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, thefile system module218 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.
• 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)module212. 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. TheGWES module212 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).
• TheGWES module212 also supports a window management component that provides API functions tailored for the smaller display sizes typical of embedded operating systems.
• 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.
• Communications module216 includes a variety of communications component options to support communications hardware. This includes serial, parallel, and network (wired and wireless) communications.Communications module216 includes the following selectable communications features:
• • Serial I/O support
  • Networking support including:
    • NDIS 4.0 for local area networking
    • PPP and SLIP for serial link and modem networking
    • Client-side Remote Access server (RAS)
    • Internet protocols
    • Telephony API (T APO)
    • PC Card support
    • Infrared transceiver support
• In one embodiment of the invention, an embedded systems designer must develop theOEM adaptation layer208 to create the platformspecific kernel module214. The OEM Adaptation Layer (OAL)module208 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 thekernel module214 and thetarget platform hardware202. TheOAL module208 is specific for a particular CPU and target platform.
• TheOAL module208 includes interfaces such as the following:
• • Interrupt service routine (ISR) handlers to support device drivers
  • Real-time clock (RTC)
  • Interval timer (used for the scheduler operation)
• 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 thekernel module214 rather than in theOAL208.
• In addition to managing such functions as timing and power, the primary purpose of the OAL is to expose the target platform'shardware202 to thekernel module214. 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.
• Built indrivers206 are device drivers that are linked withGWES module212 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.
• Device Manager module210 is a module that handles installable device drivers. In one embodiment of the invention, TheDevice Manager210 performs the following tasks:
• • 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 Manager210 will attempt to locate and load a device driver for that PC Card.
  • 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.
  • 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.
  • Loads and tracks drivers by reading and writing registry values.
  • Unloads drivers when their devices are no longer needed. For example,Device Manager210 will unload a PC Card device driver when the card is removed.
• In one embodiment of the invention,Installable Device Drivers204 exist as standalone DLLs (Dynamic Link Library) that are managed by theDevice Manager210.Installable device drivers204 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.
• In one embodiment of the invention;installable device drivers204 use a common interface by which their services are exposed to applications. This interface is the Stream I/O Interface.
• A description of the relationships between components, modules and the APIs they expose to applications is presented with reference toFIG. 3. Amodule308 is a major functional block of an operating environment such asoperating system200 ofFIG. 2.Module308 exposes anAPI302 to applications such asapplication226 ofFIG. 2 that allows the application to interface and call methods or functions implemented by themodule308.
• Modules may optionally include one ormore components306.Components306 are groups of functions and data that provide capabilities on a smaller scale thanmodules308. Like amodule308, acomponent306 also exposes anAPI304 that other applications, modules, and components may use to call methods or functions implemented by thecomponent306.
• 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.
• 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
• 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.
• 1. Handwriting Recognition APIs
• A handwriting recognition component is available in the Add-On Technologies module224 (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.
• 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.
• Further details on the APIs used by applications that interface with a handwriting recognition engine are presented in Appendix G on CD-ROM.
• 2. Position and Navigation APIs and Data Structures
• 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.
• 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.
• 3. Speech Related APIs
• 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.
• 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.
• 4. Out of Memory API
• 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.
• 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.
• Further details on the out of memory API are presented in Appendix L on CD-ROM.
• 5. Database API
• As discussed above in reference toFIG. 2, thefile system module218 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.
• 6. ActiveSync Data Structures
• 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.
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.

Claims (16)

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 ofclaim 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 ofclaim 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 ofclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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.

Images