Interstate Robotics, Inc - Software Development and Web Appliance Solutions

Direct Device Interfaces_â

Overview

A Direct Device Interface (DDI) is an Application Program Interface (API) and device driver hybrid providing multiple clients with direct, language- and hardware-independent access to a physical device without the restrictions, complexity, and overhead of popular desktop operating systems. Clients include applications programs, applets, threads, and Dynamically Linked Libraries (DLLs). The DDI is implemented as a self-contained DLL which is linked to the client at runtime and does not require a complementary device driver. Note that a statically linked library which is linked to the client at compile time may also used to expose the functionality of the physical device. Using DLLs, however, has many advantages:

The API does not have to originate from the operating system manufacturer, thereby providing the development community at large with a means of extending operating system services. This feature allows applications development based on non-proprietary, commodity operating systems. Historically, non-proprietary, commodity systems have always banished proprietary systems from the market place.
DDIs enable Device-to-Device (D2D) and Business-to-Business (B2B) networks which communicate applications as well as information.
Direct access optimizes real-time performance in terms of the speed of execution and latency.
Code sharing reduces system resource utilization as required for low cost PCs and web appliances.
DLLs are a critical technology required for the development of visual programming tools whereby application programs may be created by drawing box-and-wire diagrams. Visual programming tools provide fast prototyping capability and eliminate the tedious and arcane tasks associated with traditional development methods.

Background

Windows and Linux are layered operating systems. Operating system layers include application, Application Program Interface (API), kernel, device driver, and physical device as shown in the figure below. Executable programs and threads run in the application layer.

The basic goal of layering is to partition the problems involved in providing operating system services into manageable pieces. The partition exists on an implementation level so that layers may be implemented, tested, optimized, and replaced separately. The partition also exists on an conceptual level so that layers may be understood and analyzed separately from each other and the uses to which they are put. According to the client server model, each layer is regarded as a server that waits to be asked by clients in the layer above to provide a specific service. Servers exploit the functionality of the layer below to provide higher level system services to clients in the layer above. Usually, there is a standard interface and clients only have to conform to the peculiarities of this interface without regard to implementation details of requested services.

With reference to the figure below, typical communication between layers as required to provide Windows 3.X/9.X/NT applications with access to physical devices is indicated by black lines. Applications utilize an API in order to request services that require access to the device. In response to such service requests, the API incorporates a hardware independent representation of the device to generate a sequence of abstract device operations. The kernel relays abstract device operations to the appropriate device driver. Finally, the device driver translates abstract device operations into actual device operations which are hardware dependent and specific to the particular physical device in use.

Performance analysis of this scheme takes the form of a queuing system with probabilistic arrival and service times. Arrival time corresponds to the random event that an executable program or thread invokes an API routine in order to access a device. Service time is the period of time required by the API, kernel, and device driver to collectively provide device access. It equals the sum of API, kernel, and device driver scheduling delay and execution time. Scheduling delay is the time spent by the API, kernel, or device driver waiting for shared resources, to include CPU instruction cycles, in order to complete a task. Execution time is the time required to complete a task assuming the necessary resources are available. In contrast to execution time, scheduling delay is unpredictable in detail since the scheduled duration and order of API, kernel, and device driver activity may not correspond to actual execution time and sequence of execution, respectively.

Blue lines in the above figure show that DirectX APIs communicate directly with the device driver in order to improve performance by eliminating kernel service time. Red lines in the above figure show that DDIs communicate directly with the physical device in order to maximize performance by minimizing service time. Utilization of computer resources is also minimized based on Little's Theorem (waiting area decreases with service time).

Available Direct Device Interfaces

Existing DDIs from Interstate Robotics extend Win16S/32S services by exposing the functionality of graphics, timer chip, DMA bus master, and video data acquisition devices. Win16S and Win32S are the subset of the Win16 and Win32 API, respectively, which are available from second sources and may be utilized without the restrictions, complexity, and overhead of Windows. They are non-proprietary, user extendible, communally defined, and shared by a world-wide network of developers without belonging to anyone. Please note that DDIs to the video graphics adapter and timer chip are protected by United States Patent No. 6,078,747. An HTML version of the original patent application contains HTML links to figures.

Impact On Markets

Companies which develop software for the x86 family of computers rely heavily on enhancements and modifications to Windows in support of new applications development. Problems stemming from this reliance are as follows:

Windows is a proprietary operating system and Microsoft has privatized the standards by which companies develop software. With every refinement and new embodiment of Windows, Microsoft gains more market share for its own applications at the expense of applications developed by its competitors.
Operating systems released during the past fourteen years include Windows 1.0, Windows 2.0, Windows 386, Windows 3.0, Windows 3.1, Windows 3.11, Windows for Workgroups, Windows NT, Windows NT 3.5, Windows NT 4.0, Windows NT 5.0, Windows 2000, Windows 95, Windows 98, Windows CE 1.0, and Window CE 2.0. This shotgun approach to marketing operating systems has created a very unstable development environment.
Microsoft has a reputation for publishing incomplete operating system specifications. Over 250 Windows 3.X Application Program Interfaces (APIs), for example, were left undocumented or reserved by Microsoft.
Beta program privileges, which in some cases require steep license fees, has created a country club atmosphere in which members are given exclusive access to operating system specifications prior to its release. Early access provides a time-to-market lead in which to initiate product development and marketing programs. Non-members are sometimes able to regain competitive status by upgrading their product line, only to find their efforts invalidated with the release of a subsequent, incompatible version of Windows.
Windows does not support the development of applications for Real-Time and Embedded (RT&E) systems providing deterministic, predictable response times.
The core of Microsoft's business strategy is to exclude competition which would commoditize the operating system. The flip side is that this makes it difficult for developers to innovate with Microsoft OS products.

The instability of Windows combined with Microsoft's business practices has prompted a world-wide network of developers to adopt Win16S/32S as a non-proprietary, commodity operating system. Evidence is given by hundreds of web sites to include:

www.xraylith.wisc.edu/~khan/software/gnu-win32
www.geocities.com/SiliconValley/Bay/3437.
www.pharlap.com
www.tenberry.com
www.tmt.com

These web sites indicate the beginning of a market trend similar to when proprietary computer hardware gave way to commodity computer hardware. Prior to the early 1980s, computer companies produced proprietary hardware and operating systems which were incompatible with that of their competitors. IBM did the opposite and hardware vendors responded by innovating with the PC rather than inventing their own proprietary platforms. The effect was to commoditize the PC hardware market and ultimately kill the proprietary hardware personal computer.

DDIs extend Win16S/32S services. This allows Win16S/32S to be treated as a user extendible commodity which scales in order to satisfy a broad spectrum of requirements. If history repeats itself, impact on markets and corresponding benefits to the consumer will be similar to when non-proprietary hardware (the IBM PC) banished proprietary systems (Amega, Commodore, DEC) from the marketplace.