Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

OS/2 extender (Developers)

posted by kerravon E-mail, Ligao, Free World North, 12.09.2025, 18:03

> It is an interesting thought experiment, but ultimately completely useless.
Why useless? It's somewhat similar to S/380.

https://mvs380.sourceforge.net/

It is nominally impossible to run 31-bit tasks under a 24-bit operating system.

But it was possible anyway, and enabled me to access large amounts of memory. And the executables I run on MVS/380 are able to be run on modern z/OS.

And what I'm now talking about is running Win64 executables. Similar but not identical to HX.

> In theory, it might just work. You just don't gain the privilege to switch
> modes so easily. I assume you would need a ring 0 kernel driver for this.
I would have thought any privileged executable could execute the instructions. Who's going to stand in the way? I have asked:

https://www.os2world.com/forum/index.php/topic,3980.0.html

> I envision the architecture like this: For every 64 bit task to run, there
> is a small, normal 32-bit OS/2 part that connects to and communicates with
> the kernel mode driver. It will continuously ask the kernel mode driver to
> run the 64 bit task until it exits, similar to how virtualized tasks are
> run today.
Yes.

> Long mode would have to have its separate set of page tables and interrupt
> descriptors. The kernel driver would have to act as a kernel for the 64 bit
> task and handle its synchronous interrupts like invalid instruction or
> arithmetic exception as well as syscalls.
Ok, first of all, I have the limited goal of running error-free programs. If there is a bug, I don't particularly care what happens.

In addition, there won't be any syscalls (I assume you mean INT instructions). It is the Win64 API that will be called, and that will have callback functions plugged in that naturally return to the 32-bit portion (ie switch from LM64 to PM32) to get executed.

> Youl would need to come up with
> some kind of syscall and API thunking scheme.
Yes, I already have that - I call it a pseudobios. And I make good use of that in mfemul where the mainframe code does a call into the pseudobios which is then resolved by native (e.g. 386) code.

> There would also need to be
> some kind of communication buffer that both the 32 bit and the 64 bit part
> can access. This could be allocated by the kernel driver in a way so that
> it will not be moved around by OS/2. Then it could be mapped into the 64
> bit address space.
Sure. I will need a way of knowing the real address for a PM32 virtual page.

> Whenever a hardware interrupt comes in that is intended for OS/2, it would
> need to quickly save the state of the 64 bit task, switch back to legacy
> mode and deliver the interrupt to OS/2 by manually interpreting its IDT. Or
> maybe you could get away with disabling interrupts,
Yes - disabling interrupts was what I had in mind. At least for proof of concept and to start running Win64 apps. Bells and whistles is an exercise for the reader (or a commercial vendor).

> but you would need to
> have a way to interrupt the running 64 bit task anyway to prevent it from
> stalling the OS indefinitely.
I don't mind buggy programs hanging the OS. There are already bugs in OS/2 that cause it to hang anyway.

> I could think of using a timer for this, but
> this would have to be stolen from OS/2 and put back into the state that
> OS/2 expects it to be in before returning control -- quite a mess!
I don't consider it a mess. I don't consider DOS extenders to be a mess either.

I'm only expecting one task to run, and like MSDOS, I'm expecting buggy apps to be able to hang/crash the system.

I simply debug buggy apps. Works fine for me - for decades.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 339 users online (2 registered, 337 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum