Regarding your question about the communication between CPI (Config.sys Protected-mode Interface) and the OS2KRNL:
CPI provides an interface for the configuration system (config.sys) during boot time and passes information to the kernel before the actual session management (like PM, DOS boxes, etc.) starts. This communication follows a well-defined structure that is processed by the loader—typically involving memory areas, flags, and structured parameter blocks.
The interaction is mostly asymmetrical: CPI delivers startup parameters to the kernel (e.g., via the "init-table" or system objects), but the kernel does not actively call CPI in return. Some modules (such as drivers or IFS components) make use of the provided information via DevHelp or other internal OS/2 APIs, which may be indirectly influenced by CPI.
Relationship between Loader, CPI, and OS2KRNL:The Loader (OS2LDR) is the first component activated during the boot process.
It loads the kernel (OS2KRNL) as well as other protected-mode modules such as CPI, BASEDEV, IFS, etc.
CPI (Config.sys Protected-mode Interface) is loaded and initialized by the loader.
CPI processes the CONFIG.SYS entries and creates structured information that is essential during system startup.
These pieces of information are passed from CPI to the kernel in the form of:
SysInitData structures Memory blocks / flags / initialization tables
Environment variables and startup parameters (e.g. PROTSHELL, RUN, DEVICE, etc.)
The kernel (OS2KRNL) uses this data to:
Continue system initialization
Properly load drivers and services
Launch the graphical or text-based user environment (e.g., Presentation Manager, DOS sessions)
The communication is one-way – CPI passes data to the kernel, but not the other way around.
References:
IBM Redbook: OS/2 Version 2.1 – Volume 1: Control Program, Chapter 3 – "System Initialization"
https://www.os2museum.com/wp/redbooks/gg243376.pdfOS/2 Warp Kernel – Theory and Practice by Gary Urban (summary)
https://www.os2museum.com/wp/?p=1906OS/2 Museum Blog – deep insights into CPI, boot process, kernel internals
https://www.os2museum.com/wp/IBM OS/2 Warp 4 Device Driver Kit (DDK), includes SysInitData and DevHlp examples
Archived version:
https://web.archive.org/...
Alternative approach (modern design principle):
Instead of keeping CPI permanently available, one could introduce a new modular architecture, where a kind of “boot service” or “initialization manager” takes over certain CPI-related functions — but operates in user space, for example under PROTSHELL.
Advantages of a Boot Service in User Space instead of Classic CPI:
Modularity & Extensibility A user-space boot service can be updated or extended more easily, without modifying the kernel or OS2LDR.
New features (such as network initialization or dynamic device management) could be added as loadable modules.
Runtime Intelligence
While CPI only operates during boot time, an initialization service could monitor, adjust, or log system states at runtime.
Improved Error Handling
Errors in CPI often lead to boot failure.
A user-space service can handle such issues more gracefully, write logs, or provide notifications without compromising system stability.
User Interface Capability
A modern initialization service could offer a graphical configuration interface, similar to tools like systemd-analyze on Linux.
This is especially useful for systems like ArcaOS or OS/2 still used in production.
Bidirectional Communication with the Kernel
Using defined APIs, shared memory, or message channels, the service could communicate with the kernel in a controlled way.
This would allow dynamic changes to system parameters or runtime analysis of kernel responses.
Security through Separation
The boot service does not run in kernel mode, which means that any faults or attacks have a lower risk of destabilizing the entire system compared to kernel-level CPI modifications.
I hope I understood the information correctly. I'm no technical genius.
Thanks everyone and for the additions.