OS/2, eCS & ArcaOS - Technical > Programming
Brainstorm: OS/2 on a Different Kernel
Martin Iturbide:
--- Quote from: Dave Yeo on March 26, 2025, 04:30:14 pm ---
--- Quote from: Martin Iturbide on March 26, 2025, 01:10:19 pm ---
--- Quote from: Dave Yeo on March 26, 2025, 04:26:35 am ---The Presentation Manager would mean mapping PM windows to whatever Linux is using, X11 or Wayland. WPS might be the hardest to support.
--- End quote ---
How does PM connects to the OS/2 kernel currently? Because I would think that PM only goes through CPI to the kernel, and maybe some other DRIVER$, but the idea will be to make PM run through a different kernel and not necessary linking it to other GUI like X11 or Wayland yet.
Regards
--- End quote ---
I don't really know but it has to connect to the video drivers to get access to the frame buffer to create the PM desktop and write/read the framebuffer. Doing things like seamless DOS/WinOS2 support must be tricky too and maybe kernel level.
--- End quote ---
On the very limited/little research I was able to do sometime ago, PMMERGE.DLL uses (or refers to) SINGLEQ$ and KBD$, so maybe SINGLEQ$ is also vital. But I got no reference to something related to video, maybe PMGPI.DLL has some connection to a DRIVER$ that I don't know.
Regards
Martin Iturbide:
Hello
I'm reading this: Inside the OS/2 Kernel by David C. Zimmerli.
It is from the OS/2 2.11 kernel. It is kind of interesting to see how this author was able to see which files of the kernel source code belongs to which component. (of course he does not has the source code, only the file names). I wonder how he did that, and it makes sense to make the same analysis on the latest ArcaOS kernel.
I still want to try to understand the communication between CPI and OS2KRNL. Just to try to theorize what parts of the OS2KRNL needs to be mimic so DOSCALL1.DLL does not complain (or stop working) because it is on a different kernel.
Regards
Martin Iturbide:
Hello
I'm trying the NotbookLM AI to explain me some basic things.
--- Quote ---**DOSCALLS1.DLL** is a **dynamic link library (DLL)** in OS/2 that appears to be a **core system component providing a wide range of kernel services and API entry points**.
Here's a breakdown of what the sources indicate about it:
* **Central System DLL:** Almost all programs utilize **DOSCALLS1.DLL**, suggesting its fundamental role in the OS/2 environment.
* **Initialization:** It seems to have **instance initialization routines**.
* **API Entry Points:** **DOSCALL1** contains **16-bit entry points that correspond to various OS/2 APIs**. It also appears to handle **32-bit APIs**, with examples like `Dos32FreeMem`, `DosGetMessage`, and `DosPutMessage` having associated trace events within this DLL.
* **Exception Handling:** The kernel calls the `Dos32R3ExceptionDispatcher` entry point within **DOSCALLS1.DLL** to **process all user exception handlers**.
* **Kernel Service Indirection:** Many kernel APIs are **indirected through DOSCALL1.DLL**. This means that calls to certain kernel functions might go through this DLL.
* **Thunking Layer:** **DOSCALLS1.DLL** includes **UniThunk** trace events, indicating it plays a role in **thunking between 16-bit and 32-bit code**.
* **Traceability:** The System Tracepoints Reference provides a comprehensive source for deriving API-related breakpoints, often with entry point names prefixed with `pre` or `post`, which is applicable to functions within **DOSCALLS1.DLL**. Numerous trace events are defined for various functions within **DOSCALLS1**, allowing for detailed tracing of API calls.
* **Relationship with other DLLs:** APIs from other DLLs, such as `QUECALLS.DLL` (queue management APIs), can be **indirected via DOSCALL1**.
In essence, **DOSCALLS1.DLL** serves as a crucial intermediary and provider of fundamental operating system services, handling API calls, managing exceptions, and facilitating communication within the OS/2 environment. Its central role is highlighted by its frequent use across applications and its involvement in various core system functionalities.
--- End quote ---
Which functions does the OS2KRNL provides that are used by DOSCALLS1.DLL?
--- Quote ---Based on the sources, particularly the trace event information, **OS2KRNL provides a variety of kernel functions that are used by or whose calls are indirected through DOSCALLS1.DLL**. The trace logs in `sg244640.pdf` detail many API calls, specifying a major code for `OS2KRNL` (0x0005) and various minor codes corresponding to specific kernel functions. Many of these APIs have tracepoints that indicate they are indirectly accessed via `DOSCALL1`.
Here are some examples of functions provided by **OS2KRNL** that are relevant to **DOSCALLS1.DLL**, based on the trace events:
* **Memory Management Functions**:
* `Dos32GiveSharedMem`
* `Dos32QueryMem`
* **File System Related Functions**:
* `DosBufReset`
* `DosCallNmPipe`
* `DosDevIoctl`
* `DosDisConnectMmPipe`
* `DosOpen`
* `DosOpen2`
* `DosPhysicalDisk`
* `DosQNmPipeState`
* `DosSetMaxFH`
* `DosSetNmPHandState`
* `DosSetVec`
* **Process and Thread Management**:
* `DosSystemService`
* `DosTimerAsync`
* **Dynamic Linking and Loading**:
* `DosGetModHandle`
* `DosGetModName`
* `Dos32QueryProcAddr`
* **Synchronization**:
* `DosSetSigHandler`
* **Handle Management**:
* `Dos32IQUERYFHSTATE`
* **Input/Output**:
* `Dos32IRead`
* **Other**:
* `Dos32SetFileLocks`
The "Kernel API Tracepoints Indirected Via DOSCALL1" section further confirms this indirection, although it doesn't list the specific kernel functions themselves but rather the tracepoints associated with the pre-invocation of APIs that are indirected.
In summary, **DOSCALLS1.DLL acts as an intermediary for a significant number of OS/2 kernel functions provided by OS2KRNL**, handling the transition and enabling applications to access these core system services. The trace logs provide concrete examples of this interaction by showing how calls to various kernel functions (residing in **OS2KRNL**) are traced with pre-invocation events often associated with **DOSCALLS1**.
--- End quote ---
Klafi:
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.pdf
OS/2 Warp Kernel – Theory and Practice by Gary Urban (summary)
https://www.os2museum.com/wp/?p=1906
OS/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.
Martin Iturbide:
--- Quote from: Dave Yeo on March 26, 2025, 04:42:32 am ---In a way ReactOS would be a better fit for a kernel then Linux. Otherwise extending WINE, which is not an emulator, might help a lot. The running OS/2 on NT does show it is possible to run our binaries on a different OS and WINE shows running Windows apps on Linux is doable. The WPS is perhaps too hard to run on Linux and maybe even NT.
--- End quote ---
On this case 2ine will be an interesting way to go, since it is like WINE but to interpret OS/2 and not Windows. But the issue with 2ine is that the developer tried to replace all possible functions with a cloned open alternative, which makes it a lot of developer work and this is why the project is incomplete (Like cloning all OS/2). What it may be interesting is to use 2ine to clone only the OS2KRNL and Driver$ only and use the IBM's OS/2 binaries for CMD, PM, SOM, WPS, to avoid cloning all OS/2, and find a way to boot the OS/2 desktop over a different kernel.
"Win-OS/2" runs virtualized / Interpreted on OS/2, right?, not emulated. It will be something like having "Warp-Linux VDM" sessions on Linux.
Regards
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version