API Namespace Virtualization via Dynamic Loader Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional computer systems face inefficiencies in loading and managing software components due to the rigid coupling of interface contracts with specific dynamically linked libraries, leading to resource wastage and compatibility issues when dealing with different hardware environments and software versions.

Innovation Solution

A loader that maps API namespaces to components, allowing flexible implementation of functions based on runtime conditions and versioning, enabling decoupling of interface contracts from component packaging and efficient resource allocation, while supporting dynamic reconfiguration of the operating system framework.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If interface contracts are rigidly coupled with specific dynamically linked libraries, then implementation is straightforward, but system flexibility and adaptability to different environments deteriorate

Engineering Contradiction:
Improvesystem flexibilityVSAvoidloader complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary mapping layer between interface contracts and dynamically linked libraries. The loader uses mapping information to resolve namespace references to actual library implementations, allowing flexible coupling without direct binding. This intermediary mechanism enables the system to adapt to different environments while maintaining a clear separation between interface definitions and implementation details.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Loss of energy

If software components are dynamically loaded based on runtime conditions, then resource efficiency improves, but loading time and system complexity increase

Engineering Contradiction:
Improveresource wastageVSAvoidloading time
Core Design Contradiction:
Loss of energyVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-defining mapping information that associates namespace references with specific dynamically linked libraries under different runtime conditions. This mapping information is prepared in advance, allowing the loader to quickly resolve namespace references without extensive searching or decision-making at load time, thus reducing actual loading time while maintaining dynamic adaptability.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If interface contracts are decoupled from component packaging, then adaptability to different environments improves, but system complexity and difficulty of management increase

Engineering Contradiction:
Improveenvironment compatibilityVSAvoidmaintenance ease
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent segments the system into distinct components: interface contracts (namespace definitions), mapping information (association rules), and dynamically linked libraries (implementations). This segmentation allows each component to be independently managed and modified. The mapping information acts as a configuration layer that can be adjusted to support different environments without changing the core interface contracts or library implementations, thereby maintaining ease of operation while improving adaptability.

Inventive Principle:
Principle #1Segmentation

4Adaptability or versatility

If multiple components implement the same API namespace, then system versatility improves, but determining which component to load becomes more complex

Engineering Contradiction:
Improveimplementation flexibilityVSAvoidcomponent selection difficulty
Core Design Contradiction:
Adaptability or versatilityVSDifficulty of detecting and measuring

Solution Approach 1:

The system uses parameter changes in the mapping information to determine which component to load. The mapping information includes parameters such as namespace identifiers, library names, and runtime condition specifications. By changing these parameters based on the current runtime environment, the loader can automatically select the appropriate component implementation without complex decision logic, thus maintaining simplicity while supporting multiple implementations.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS10089119B2API namespace virtualization
Publication Date: 2018.10.02 MICROSOFT TECHNOLOGY LICENSING LLC
  • US10089119B2 patent drawing
  • US10089119B2 patent drawing
  • US10089119B2 patent drawing

AI summary

A computer operating system with a map that relates API namespaces to components that implement an interface contracts for the namespaces. When an API namespace is to be used, a loader within the operating system uses the map to load components based on the map. An application can reference an API namespace in the same way as it references a dynamically linked library, but the implementation of the interface contract for the API namespace is not tied to a single file or to a static collection of files. The map may identify versions of the API namespace or values of runtime parameters that may be used to select appropriate files to implement an interface contract in scenarios that may depend on factors such as hardware in the execution environment, a version of the API namespace against which an application was developed or the application accessing the API namespace.