The Winux System is aiming to make a new standard in compatibility between operating systems by making it possible to add new semi-native API modules that will convert a foreign API to the native Winux API. These modules are called API Converters because they do not emulate an API, but rather convert API commands from one system to another by making the necessary calls to the native API to provide the same services, and providing wrappers where necessary. API Converters exist in a more intimate relationship with the kernel than a program that emulates an API, like the famous WinE project. The part of the Winux System that handles all of this is the Winux API Controller, whose responsibiilty it is to manage the API Converter modules and ensure the correct one is called in response to events.
Additionally, through providing a emulated CPU in the Winux HAL, the system can also run software that is non-native to the local hardware, thus creating a new level of compatibility and abstraction between computer systems.
Finally, because the API Converters work with the user applications the Winux API Controller will be part of the Winux Userland (a.k.a. Actual OS) system. Through this relationship to the Winux Kernel, the Winux Micro-Kernel, and the user applications the ability of the API Converter system should yield a higher performance gain than doing the same thing via emulators, at least in theory, since (a) the API is made nearly native to the system being far more intimate with the kernel than an emulator is, and (b) the ability of the system to use foreign API's is designed in from the beginning, where as most operating systems to not plan on running multiple API's.Requirements Home Table of Contents
The API Converter system is first encountered during a task switch. At each task switch, a value is loaded into a special variable associated with the current task from the Program Controller Block (PCB). These values are assigned to the PCB when the program's PCB is initially created and cannot be changed during the run of the program.
In the case where the call is a Software Interrupt or Software API call, the interrupt checks with the API Controller to determine what API to use as a responder, and the calls the appropriate API Converter module. The module then does the conversion process, and returns the appropriate information to the program as per the design of the API it is converting to. If the calling program is no longer in memory but has been switched out with another program, a task switch is then performed to reinstantiate the program so that it may get the data. If necessary, a task switch back to the previous program may then be performed on the condition that the previous program needed to have such an action taken and that it does not prohibit other programs from running.
In the case where the call is a Hardware Interrupt or API call, the response is similar to that of the Software Interrupt or API call. However, when Hardware Interrupt triggers the device driver, which enters into the Device I/O Queue. When the information may then be returned, it is checked against the API Controller, and returned to the program as appropriate to the API being used.Requirements Home Table of Contents
The Winux API Controller is responsible for maintianing the list of API Converters. There is one converter for each API that is being made accessible to user applications, and each application may receive its own instance of the converter, with the exception of the native converter. That is to say, each converter module that is making a conversion from a foreign API will be able to keep information about the program it is serving, thus each program will have its own instance of the API Converter that it is using. Since the native API is not doing any conversion process, it does not need to store information about the program and thereby one instance of the module will be able to serve all the applications that are using the native API.Requirements Home Table of Contents