OS/2, eCS & ArcaOS - Technical > Programming
Brainstorm: OS/2 on a Different Kernel
Martin Iturbide:
Hello
I was wondering what would be required to run OS/2 over a different kernel.
Let’s theorize, what if we want to have PC that boots Linux, gets to the command line and run something like “startwarp” and the full OS/2 desktop will boot. (Command line, PM, SOM, WPS) and you can run your OS/2 applications there. (Not the 100% of OS/2 applications, but at least start with some)
What would be required to make the OS/2 binaries believe they are running over the OS/2 kernel to run interpretated and not emulating a x86 machine.
From my limited knowledge point of view will be required:
1.- OS2KRNL: The OS/2 kernel has everything that you need on an OS kernel to talk to the hardware, but those will not be necessary since the Linux kernel already does this with the hardware. What would be needed is a layer with all the functions that OS2KRNL provides to DOSCALL1.DLL …. I guess.
As far was a I know OS2KRNL provides a lot of DosXXXX functions to DOSCALL1.DLL. I’m guessing all of this needs to be cloned over Linux (maybe with libc/gcc) to make believe DOSCALL1.DLL that is talking to the kernel.
But I think I’m only talking about the API here, what about the memory management? Where it should go?
Does it make sense?
2.- MOUSE$, KBD$, SCREEN$, CLOCK$. As far as I know this are called “Character Device Drivers”. These are drivers that DOSCALL1.DLL and CPI uses. Here I don’t have the details on how these talks to the CPI. Some layer (DRIVER$ to Linux) to mimic the responses of these driver will be required.
There are a lot more for specific driver like USB, LTP, etc. are also required for software that communicates to hardware, but it had to start with the basic ones to first have a full OS/2 desktop and later improve it with better compatibility.
What would be the vital Character Device Drivers to start with?
Where can I found more information on how CLOCK$ (or any other interacts) with CPI or with any other software that requires it?
3.- Binary compatibility. I don’t know if its completely required that Linux has the “Linear Executable” layer like it was done on the 2ine project. But I think I’m missing this part. I guess that the OS2KRNL provides the instruction to let know that an ,exe file is a “Linear Executable” file, right? Where should that go if we are running a OS2KRNL faked in Linux?
Yes, I know that this theorical version of OS/2 will not be 100% compatible with all software, specially with the software that interacts with hardware. All device driver for OS/2 will be useless, and some new technique will need to be created to grab the Linux drivers and show it on the OS/2 environment (Ex: Linux Audio to UNIAUD1$ bridge). 16 bits may be broken and maybe not required today, VDM will be broken and there will be not full API compatibility first. A proof concept will have an awful compatibility first but it has the potential to grow if it’s open source and if people believe in this kind of long-term strategy.
This will not be easy, because it requires developers with OS/2 and Linux development knowledge to obtain at least a minimum of compatibility to make it usable.
Beside these three components that I theorize, what other thing will be missing to run an OS/2 desktop interpreted in Linux? What do you think? Please correct me where my interpretations of the OS/2 architecture are wrong.
Regards
Dave Yeo:
Hi Martin, no expert but my take,
#1, a DosCall1.dll is a big part of the communicating with the kernel, which presents as DosCalls.dll or such. DosCall1.dll would have to communicate with whatever part of Linux manages memory amongst other things.
Also the kernel takes care of loading exe's and dll's, need something to do the same, including doing the fixups. Likely there is WINE code that could be repurposed as Win32 and OS/2 exe's and dll's aren't that different.
#2, guess need to hook into the Linux drivers and present the same stuff in the DLL's as is usual.
#3, I think should be able to load LX binaries, also LE and NE. Once again WINE does similar already, even supports NE binaries I believe.
As for 16 bit, there's still 16bit code in OS/2, especially the low level stuff including DosCall1.dll. WINE runs 16 bit Windows code, perhaps once again ideas from that?
While about it, can look at how WINE supports WIN terminal apps and maybe the same can be done for OS/2 VIO apps. We'd lose full screen support, not much uses it anyways. Linux has a VDM, though not as good as ours as well, or at least it did.
The Presentation Manager would mean mapping PM windows to whatever Linux is using, X11 or Wayland. WPS might be the hardest to support.
Dave Yeo:
Windows NT, up to W2K or even XP, could run 16 bit OS/2 binaries, text mode out of the box, I ran some. Also they had a Presentation Manager kit to run 16 bit PM applications.
It was interesting how they did it and perhaps some lessons.
Textmode OS/2 1.x ran in a Windows terminal. Other then not respecting the full screen bit, so always in a terminal window, they thought they were running on OS/2. You could do things like use tedit to open C:\config.sys (which only existed virtually) and do things like change the LIBPATH etc and other stuff I assume. Save the file and Windows would update the registry instead of actually writing config.sys.
Never used the PM kit but understand it worked fairly well too, use e.exe to edit the config.sys.
Saw a small article in Byte years ago that MS succeeded in doing the same thing with 32 bit OS/2, including the Presentation Manager. No WPS. As they had the source code and NT did start out as a version of OS/2, they had an advantage compared to us and it still sounded like it was a big job. Guess they were prepared if OS/2 won the OS war.
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.
Martin Iturbide:
--- 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
Dave Yeo:
--- 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.
Navigation
[0] Message Index
[#] Next page
Go to full version