Operating System Subsystem Extension via Dynamic Link Library
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing operating systems face challenges in migrating applications between different implementations, such as UNIX flavors, due to incompatible APIs and resulting unexpected behavior, which can lead to multiple incompatible versions and loss of standard operating system benefits.
Innovation Solution
The solution involves extending operating system subsystems by using a dynamic link library (DLL) that implements additional API functions, allowing pre- and post-processing steps to be executed at specific insertion points, and dynamically adding system call numbers and ports, enabling seamless integration of extended functionality without modifying the underlying operating system.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the operating system subsystem is modified to emulate another flavor of UNIX, then the application can run on the new flavor, but multiple incompatible versions of the operating system are created
Solution Approach 1:
The operating system subsystem is segmented into a base subsystem and extendable functionality modules. The base subsystem provides standard POSIX APIs, while flavor-specific functionality is provided by separate extendable modules that can be loaded dynamically. This segmentation allows applications to be adapted to different UNIX flavors without modifying the core operating system, thus maintaining compatibility while avoiding version complexity.
Solution Approach 2:
An intermediary layer is introduced between the base operating system subsystem and the application. This intermediary layer provides flavor-specific API implementations that translate between different UNIX flavors and the standard POSIX interface. The intermediary acts as a mediator that enables application compatibility across different flavors without requiring modifications to the base operating system or creating multiple incompatible versions.
2Adaptability or versatility
If the operating system subsystem is modified to support multiple UNIX flavors, then application migration is enabled, but standard operating system benefits are lost
Solution Approach 1:
The base operating system subsystem is designed with universality to support multiple UNIX flavors through a common interface. The subsystem provides standardized POSIX APIs that work across all flavors, while flavor-specific behaviors are achieved through extendable functionality. This universal design maintains the reliability and dependability of the base operating system while enabling multi-flavor compatibility, allowing applications to migrate without sacrificing standard OS benefits.
Solution Approach 2:
The operating system subsystem incorporates dynamic loadable modules that can be loaded or unloaded based on the required UNIX flavor. This dynamic architecture allows the system to adapt to different flavors at runtime without modifying the core subsystem, maintaining the reliability of the base system while providing flavor-specific functionality through dynamically loaded components.
3Ease of operation
If a dynamic link library is used to extend subsystem functionality, then seamless integration is achieved, but the system requires dynamic loading mechanisms
Solution Approach 1:
The extendable functionality modules are pre-compiled and prepared in advance, but their loading is deferred until needed. The system maintains a registry or index of available extendable modules, allowing the base subsystem to dynamically load the appropriate module when a specific UNIX flavor is required. This preliminary preparation simplifies the dynamic loading process, as the system only needs to load pre-prepared modules rather than compiling or configuring them at runtime, thus achieving seamless integration without excessive complexity.
Data Source
AI summary
Techniques for extending operating system subsystems are provided. The techniques involve using a subsystem of an operating system having a set of insertion points that identify points in the program logic of the subsystem where logic extensions may be added. The subsystem may receive a library that has functions comprising program logic for extending the subsystem and a list that provides a correspondence between the insertion points and the functions. When the subsystem receives a request to perform an action that has a corresponding insertion point for which the list provides an associated function, the subsystem may perform the function. The function may be indicated to be performed at various points in the program logic of the subsystem, including before or after the requested action.