Window kernel

Details Window kernel Window kernel

1998-01-21

2002-05-28

Courtenay, III, St. John (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S241000, C345S418000, C345S419000

Reexamination Certificate

active

06397262

ABSTRACT:

The present invention relates to a mechanism for implementing an efficient microkernel architecture for constructing graphical user interfaces capable of scalable embedded, desktop and network distributed applications. The invention disclosed broadly relates to graphical user interfaces (GUI's) and particularly relates to the software architectures used to implement them.
BACKGROUND OF THE INVENTION
Much like operating systems (OS's) of the 1980's and earlier, which used a monolithic kernel architecture, windowing systems or graphical user interfaces (GUI's) of the 1980's and 1990's have also been implemented with a monolithic kernel. Graphics drivers, input device drivers, and the other functionality of these GUI's all exist within the common address space of the GUI kernel.
In the 1990's, many OS vendors started experimenting with microkernel operating systems, recognizing that this architecture provided the best approach to delivering the new functionality demanded by their customers. For the same reasons that a microkernel architecture has been adopted in the OS community, the GUI community needs to also adopt a microkernel approach.
Description of a Microkernel OS:
The basic idea behind a microkernel architecture is to abstract out the core services or “primitives” from which the higher level functionality of the environment can be constructed. The resulting microkernel can be relatively simple. The “art” of microkernel design is in deciding which core services are essential to have within the kernel, and which should be implemented external to the microkernel. Engineering the architecture requires a constant analysis of conflicting trade-offs as pursuing certain design ideals will adversely impact other goals of the system (eg. performance, flexibility, etc).
Historically, OS functionality was implemented within a monolithic kernel to minimize the number of times time-consuming address space transitions were executed in the process of servicing an application request. Rather than having all of the functionality of the OS implemented in a single monolithic kernel that application processes call into, a microkernel OS is implemented as a tiny kernel that does only inter-process communication (IPC) and process scheduling. External processes then use these core services to implement the remainder of the OS functionality. The removal of complexity from the kernel allows a more efficient IPC implementation, which reduces the performance penalty incurred (from communicating with external service-providing processes) to the point that it becomes comparable in performance to the monolithic functional equivalent.
Splitting the monolithic kernel into separate processes also enables the easier implementation of new functionality. For example, by making the microkernel IPC network transparent, the service providing processes can be run on any node on a network, yet still be locally accessible to application processes. This serves to make all resources available to all processes, whether local or network remote. Monolithic kernels have a very difficult time attempting this functionality with efficiency because the “single component kernel” cannot be easily split across processor boundaries.
Problems With the Current State of the Art:
Network distributed computing environments and embedded GUI applications have become common due to increasing integration and decreasing hardware costs. Customer demands for even greater flexibility continue to increase. For example, the growing popularity of mobile hand-held computing devices or Personal Digital Assistants (PDA's). For reasons of cost sensitivity, battery life and physical size restrictions, the hardware resources of PDA's are significantly more limited than those of conventional desktop systems. As a result, there is a need for PDA software to make efficient use of these limited resources, which presents a number of challenges to developers. This is one example where many of the GUI development obstacles are satisfied by the inherent design flexibility of a microkernel architecture.
Since a desktop system can run a more complete version of the same software environment that will run on an embedded application platform, the desktop PC also becomes a natural development platform for the embedded application, rather than incurring the inconvenience of a cross-development environment. Being able to use visual and textual tools to directly create, compile and debug the PDA or embedded applications on a workstation or PC minimizes the development effort and reduces the “time to market”.
Rapidly evolving hardware capabilities also requires that the software environment be able to rapidly accommodate modifications to support that hardware, both as variations of common hardware devices, and as entirely new types of hardware, requiring more substantial changes to the underlying software environment's capabilities.
Existing GUI's cannot be scaled small enough to fit within the resource constraints of low-end PDA's and embedded systems. As a result, a need has been created for a GUI adaptable to both low-end, resource-constrained systems, and large-scale, network distributed systems. Existing monolithic GUI designs cannot simultaneously accommodate these requirements. As a result, vendors are forced to create multiple, completely distinct, GUI products to attempt to address the various markets, while their current monolithic product offerings still fail to address the distributed networking needs. This results in duplication of development and maintenance efforts relating to the GUI, as well as to required drivers, and raises compatibility concerns.
It is therefore desirable to create a microkernel GUI with many of the same attributes as a microkernel OS, using the approach of a tiny microkernel that implements only a few primitives. With such an approach, a team of external cooperating processes invoking those microkernel services could be used to construct a windowing system. An important aspect of such a design is to decide what those primitives should be, such that a high-performance, high-functionality, high-flexibility GUI can be built from the GUI microkernel. Inappropriate design decisions in the microkernel could result in a poor-performing system, due to additional overhead incurred from the IPC between the cooperating processes. A microkernel design would have to recover this IPC performance overhead through architectural and design performance advantages accrued from other aspects of the GUI, such as greater concurrency.
A microkernel GUI would have a number of advantages over monolithic kernel GUI's, advantages which equate directly to both better functionality and unique capabilities.
a) Scalability: Simply by including or excluding service-providing processes associated with the microkernel GUI, the functionality (and resource requirements) of the GUI could be scaled to address different application needs ranging from small embedded systems to high-end, high-functionality systems. The vendor would only have to create and maintain a single GUI product, rather than a family of products for different environments.
b) Extensibility: As new functionality requirements arise (eg. handwriting recognition, voice recognition, etc.) a microkernel GUI can easily be extended by adding specific service-providing processes. Moreover, these functionality enhancements can be readily accomplished by application developers, rather than requiring (or waiting for) the GUI vendor to implement them. To accommodate additions with a monolithic kernel GUI, the entire GUI would have to be replaced with a new, enhanced version by the GUI vendor. If a developer needs a unique extension, the microkernel approach lets the developer develop those extensions himself, rather than be bound by the original implementation limits.
c) Address protection: With the components of the GUI running in separate, MMU-protected (memory management unit) address spaces, coding errors in one section of the GUI wou

Affiliated with

Also associated with

Rating

Window kernel does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Window kernel, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Window kernel will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2832840