OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: kerravon on September 07, 2025, 12:59:53 pm

Title: native mainframe mini-clone
Post by: kerravon on September 07, 2025, 12:59:53 pm
I have previously posted here and mentioned that PDOS/386 from pdos.org supports the OS/2 API to a limited extent (enough to run C90-compliant programs).

I have 3 distinct (complete rewrites - sort of) versions of PDOS. One is PDOS-generic - which is portable.

So to put that "portable" claim to the test, I have it running on multiple environments, including the mainframe (z/Arch).

And because it turns out that the basic APIs can be written in terms of C90 (sort of), e.g. DosRead() calling fread() on another environment, it stands to reason that it should be possible to get OS/2 working on z/PDOS-generic.

It's not as simple as it sounds (mainly getting the tools
into shape), but it was indeed possible.

Here is what it looks like (not especially that the "LX" is
in EBCDIC, which is what the mainframe traditionally
uses):

enter a command
hexdump os2.exe 0 100
about to call app at address 04F0C680
000000  D4E90000 00000000 04000000 00000000  MZ..............
000010  00000000 00000000 40000000 00000000  ........ .......
000020  00000000 00000000 00000000 00000000  ................
000030  00000000 00000000 00000000 40000000  ............ ...
000040  D3E70000 00000000 02000100 00000000  LX..............
000050  00020000 13000000 01000000 14C80000  .............H..
000060  02000000                             ....
return from app is hex 0

enter a command
os2 abc def
about to call app at address 04F2D3E4
welcome to pdptest
main function is at 04F21ED0
allocating 10 bytes
m1 is 04ECE7E4
allocating 20 bytes
m2 is 04ECE834
stack is around 00080E78
printing arguments
argc = 3
arg 0 is <os2>
arg 1 is <abc>
arg 2 is <def>
return from app is hex 0

enter a command


Note that this is native z/Arch (or S/370) instructions, not 80386.

I also have the Windows API, including msvcrt.dll, for smaller executables.

Available at https://pdos.org/zpg.zip

You'll need an appropriate emulator (unless you have real hardware) - I provide Hercules/380 and mfemul.


I believe OS/2 was ported to other non-80836 environments, but not the mainframe.

If anyone is interested and wants more information, please let me know.

BFN. Paul.
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 07, 2025, 05:46:23 pm
Hello Paul

I'm sorry to be slow on this subject, but I want to make sure I understand it.

1) PDOS (Public Domain Operating System)  (https://www.pdos.org/)
It looks like DOS in the the command prompt and basic operating commands, but it is not DOS.
As far as I can read it runs on Mainframe hardware and some VMs.
The license is Public Domain, all source code is available.
PDOS comes in different flavors, and one is PDOS/386 which supports the OS/2 API (to a limited extent)

PDOS is created by you, right?

So, I guess I need to understand/learn more about PDOS first.

2) I guess you are trying to run (or accomplished to run) a small compiled OS/2 application made in C90 in z/PDOS, which is the PDOS running on the mainframe (maybe using the Hercules/380 emulator)?

3) You want to know if there is interest on this?
From the side of running OS/2 applications (even if they are small), and learning and documenting more about the OS/2 API, I have interest.
I can help with some basic testing and trying the VMs, but for the lower level development it is out of my league. But it opens up my curiosity.

Regards
Title: Re: native mainframe mini-clone
Post by: kerravon on September 08, 2025, 03:02:58 am
Hello Paul

I'm sorry to be slow on this subject, but I want to make sure I understand it.

1) PDOS (Public Domain Operating System)  (https://www.pdos.org/)
It looks like DOS in the the command prompt and basic operating commands, but it is not DOS.

That's actually a funny question. What exactly IS "DOS"? If Microsoft had produced a 32-bit version of DOS - what would it have looked like? If Microsoft had ported DOS to ARM - what would it have looked like? At what point is "DOS" no longer "DOS"? ARM uses different instructions, so INT 21H can't be used as-is. IF 8086 DR-DOS fails to reproduce a bug in 8086 MSDOS, does it cease being "DOS"? If you look at the MSDOS 4 source code, there is some code that calls a DosWrite(). This is similar but not identical to the OS/2 function of the same name. If you call DosWrite (a wrapper on the MSDOS INT 21H call) instead of calling the INT 21H yourself, does that mean that you are no longer writing a DOS program?

Quote
As far as I can read it runs on Mainframe hardware and some VMs.

There are 3 completely separate rewrites from scratch. So z/PDOS for the mainframe came before z/PDOS-generic. z/Windows is available for the latter.

Quote
The license is Public Domain, all source code is available.
PDOS comes in different flavors, and one is PDOS/386 which supports the OS/2 API (to a limited extent)
That was the case until yesterday. Now it's on the mainframe too.

Quote
PDOS is created by you, right?
Probably about 70% of the OS and C library are mine. None of the linker pdld is mine, but that's included in the source tree. Ditto pdas and pdmake.


Quote
So, I guess I need to understand/learn more about PDOS first.

2) I guess you are trying to run (or accomplished to run) a small compiled OS/2 application made in C90 in z/PDOS, which is the PDOS running on the mainframe (maybe using the Hercules/380 emulator)?
Yes - accomplished - correct.

Quote
3) You want to know if there is interest on this?
From the side of running OS/2 applications (even if they are small), and learning and documenting more about the OS/2 API, I have interest.
I can help with some basic testing and trying the VMs, but for the lower level development it is out of my league. But it opens up my curiosity.

Note that the applications don't need to be small. I have made gcc 3.2.3 C90-compliant. That's 400,000 lines of C code. So you can have an OS/2 application - 80386 or z/Arch - that is 2-3 MB in size. I think I already did that for the 80386. It's still called gccwin.exe for historical reasons, but it's an OS/2 application.

I just checked - yes I did:

D:\devel\gcc\gcc>grep LX os2.mak
os2.mak: # Produce OS/2 LX executable


I haven't done the same thing for z/PDOS-generic aka z/Windows aka z/OS2. But no technical barrier that I am aware of. I currently produce a native z/PDOS-generic executable. I'm more likely to switch to z/Windows COFF using msvcrt.dll than OS/2, but so far I haven't done either. It hasn't been a priority to do either.

BFN. Paul.
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 08, 2025, 10:36:40 pm
Hello Paul

What do you suggest me to try out PDOS and run an OS/2 binary executable to complete my test?

I have PCs (not mainframe hardware). Can I install PDOS on VirtualBox over Windows and boot PDOS, and from there run a command line OS/2 executable?

Regards
Title: Re: native mainframe mini-clone
Post by: kerravon on September 09, 2025, 02:28:30 am
What do you suggest me to try out PDOS and run an OS/2 binary executable to complete my test?

I have PCs (not mainframe hardware). Can I install PDOS on VirtualBox over Windows and boot PDOS, and from there run a command line OS/2 executable?

Hi Martin. Which OS/2 mini-clone do you want to run? The 80386 mini-clone or the mainframe mini-clone (noting that without some sort of original OS/2 on the mainframe, it's not really a clone).

With regards to the 80386 version, you can indeed run PDOS/386 (pdos.zip) under Virtualbox under Windows and run (certain) valid OS/2 80386 executables.

As you noted, you don't have mainframe hardware, so in order to run mainframe software you will need an emulator. You can either run Hercules/380 under Windows (ie download herc32.zip or herc64.zip), or you can run mfemul.exe, which is included on the PDOS/386 disk (in the "dos" directory). You then need zpg.zip, which is the mainframe version of PDOS-generic, and it already includes a test OS/2 executable, called os2.exe, so just type in "os2". There is also a "win32.exe" and "win64.exe" test programs. And you can recompile your own.

So let me know which of those things you wish to do and download the appropriate thing and tell me how far you got and I should be able to resolve any issue.
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 09, 2025, 10:25:55 pm
Ok, I have PDOS/386 running in VirtualBox. The pdos.zip vhd image did all the trick.

What OS/2 executables can I run just as testing? Is there another disk I have to mount?
What else do you recommend doing on PDOS just to play around and possible understand it better.

I run milk.bat just for testing, I see the picture, but I can not exit. Is there any trick?
What is similar to "dir /p" to see the longer directory list paused?

Regards
Title: Re: native mainframe mini-clone
Post by: kerravon on September 10, 2025, 12:43:00 am
Ok, I have PDOS/386 running in VirtualBox. The pdos.zip vhd image did all the trick.
Ok - good that you got it running.

Quote
What OS/2 executables can I run just as testing?
I don't think I ship a test OS/2 executable, but you can build a test program:

D:\devel\pdos\pdpclib>pdmake -f makefile.sos

...

gccwin -DXUSE_MEMMGR -U__WIN32__ -D__HAVESYS__=_System -O2 -fno-common -ansi -D__OS2__ -D__32BIT_
_ -D__NOBIVA__ -S -I. -I../src -o fpfuncsw.s fpfuncsw.c
pdas --oformat coff -o fpfuncsw.obj fpfuncsw.s
rm -f fpfuncsw.s
as86 -f coff -o winsupa.obj winsupa.asm
as86 -DOS220 -o needpdos.obj ..\src\needpdos.asm
..\src\needpdos.asm:8: warning: .stack unimplemented; ignored
ld86 -e top --oformat msdos-mz -o needpdos.exe needpdos.obj
rm -f pdpos2.lib
xar r pdpos2.lib os2strt.obj stdio.obj string.obj stdlib.obj
xar r pdpos2.lib start.obj time.obj errno.obj assert.obj signal.obj
xar r pdpos2.lib locale.obj ctype.obj setjmp.obj math.obj __memmgr.obj
xar r pdpos2.lib fpfuncsw.obj winsupa.obj
xar s pdpos2.lib
rm -f os2.lib
genimp doscalls.wat os2.lib
pdld -s --oformat lx --stub needpdos.exe -o pdptest.exe os2strt.obj pdptest.obj pdpos2.lib os2.li
b


And then run "pdptest abc def" to see.

(I did the above on my Windows 2000 system - but the same thing works on PDOS/386 - that's what being a mini-clone is all about)


Or verify it is LX with:

D:\devel\pdos\pdpclib>hexdump pdptest.exe 0 200
000000  4D5A6000 01000000 04000001 FFFF0600  MZ`.............
000010  00100000 00000000 40000000 00000000  ........@.......
000020  00000000 00000000 00000000 00000000  ................
000030  00000000 00000000 00000000 80000000  ................
000040  0E1FB409 BA1000CD 21B001B4 4CCD2100  ........!...L.!.
000050  54686973 2070726F 6772616D 206E6565  This program nee
000060  6473204F 532F3220 322E3020 6F722065  ds OS/2 2.0 or e
000070  71756976 616C656E 740D0A24 00000000  quivalent..$....
000080  4C580000 00000000 02000100 00000000  LX..............
000090  00020000 08000000 01000000 00000000  ................

Quote
Is there another disk I have to mount?
There is a pdoso.zip you can download that contains gccwin.exe etc as LX executables.

It was built with this:

D:\devel\pdospkg\misc>grep -i os2 *
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\gccwin.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\as86.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\genimp.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\ld86.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\pdas.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\pdcc.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\pdld.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\pdmake.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\rm.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\sccwin.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\uemacs.exe ::DOS\
final2.bat: mcopy -i pdoso.vhd --offset 504 \os2path\xar.exe ::DOS\


Those executables are not maintained though. But there are plans to mirror sourceforge to github and automatically sync and build everything. I'm not sure what the status of that is. Simon Kissane is the one driving that, with the assistance of Dat Nguyen (in Vietnam).

Quote
What else do you recommend doing on PDOS just to play around and possible understand it better.
There isn't anything to do, really. The focus was and is to have a self-hosting toolchain so that you are enabled to develop whatever it is you want to do - wherever you are. If you only have a mainframe - I have you covered. If you only have an Android smartphone - I have you covered. If you only have an Amiga with a 68000 - covered. If you're on an OS/2 machine for some reason - covered. If you like the OS/2 API for some reason, but want to use a mainframe - covered. I could  do the same for 68000 but haven't done so yet. It's more to prove the portability than anything else.

Quote
I run milk.bat just for testing, I see the picture, but I can not exit. Is there any trick?

Yep:

D:\devel\baby>type milk.bat
echo press x to exit
pfpwin milk.jpg

D:\devel\baby>


Note that I didn't write pfpwin - so I didn't create that interface. :-) Not that I would have done a better job.

Quote
What is similar to "dir /p" to see the longer directory list paused?

If you are desperate, you can do "dir a*" to list just things that start with "a", which looks undocumented to me. And there is a "type /p" (I think Simon added that), so I'm guessing that functionality could be copied across. I'll ask Dat to do both of those things. No idea what timeframe that might happen in.

Note that I have been working on PDOS for more than 30 years, and it has now reached the point where I want to make sure that a competent engineer can maintain it without needing my personal touch, so I deliberately try to get Dat to do things, and I just help him if required (essentially training).

Something like getting Windows and OS/2 APIs to work on z/Windows "requires" my personal touch though, so that's what I focus on.

Oh - in case you weren't aware, a VHD can be mounted on Windows too (since Win 7 I think), so you can use genuine Windows to do a "dir". Also the VHD that I ship is both 4k-aligned and cylinder-aligned, so that it can be mounted on an OS/2 machine too, so that you get a better "dir".

If you'd like to make suggestions, we can take that into consideration. There is no actual "master plan". The goal was just to make it exist, and prove some concepts, and that has already been done.

There are some things that have been proven to be outside our capability to date though. Like getting a basic public domain C90-compliant compiler to work. pdcc is there, and capable of compiling a "hello world", but not much else. SubC is there too, and more advanced, but not an appropriate base for a C90 compiler written in C90. So my gcc 3.2.3 fork is still the only real option. There is also cc64, but that is close to being executable-only (generated C code), and only x64.
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 10, 2025, 03:46:43 pm
Thanks Paul. I will try to check this tonight.

I have a question here:
.... If you're on an OS/2 machine for some reason - covered. If you like the OS/2 API for some reason, but want to use a mainframe - covered.
How much of the OS/2 API is covered? Is the API trying to cover what we call the Control Program Interface (CPI) (https://www.edm2.com/index.php/Control_Program_Functions_List)?

I know these projects that tried to replicate the OS/2 API that are incomplete.
- OS2Linux (https://github.com/OS2World/LINUX-SYSTEM-OS2Linux) - Common Public License
- 2Ine (https://github.com/OS2World/SYSTEM-OS-2ine) - BSD alike and some others. (https://www.osfree.org/doku/doku.php?id=en:legal)
- OSFree (https://github.com/osfree-project/) - Also a liberal license (https://github.com/OS2World/SYSTEM-OS-2ine/blob/master/LICENSE.txt).

I even tried to make a comparison on this page (https://www.os2world.com/wiki/index.php?title=CPI_Functions_Analysis_and_Comparison_(OS2Linux_/_2Ine)), but I didn't get far, since I'm not that technical savvy at that deep.

And projecting our needs as the OS/2 community, there is always around the idea of trying to create an OS/2 personality on a different kernel that can run OS/2 Presentation Manager, Workplace Shell and the native OS/2 software (at some extent, of course it will never be 100% perfect compatible)

Regards
Title: Re: native mainframe mini-clone
Post by: kerravon on September 10, 2025, 04:41:43 pm
I have a question here:
.... If you're on an OS/2 machine for some reason - covered. If you like the OS/2 API for some reason, but want to use a mainframe - covered.
How much of the OS/2 API is covered?
Only enough to stand up a C library so that to tools needed to create everything else (every other API you may wish to have) are available.

You can do it with perfectly valid OS/2 LX executables - all the way.

So here they are:

D:\devel\pdos\pdpclib>type doscalls.wat
++DosExit.DOSCALLS.DosExit.234
++DosOpen.DOSCALLS.DosOpen.273
++DosClose.DOSCALLS.DosClose.257
++DosRead.DOSCALLS.DosRead.281
++DosWrite.DOSCALLS.DosWrite.282
++DosDelete.DOSCALLS.DosDelete.259
++DosMove.DOSCALLS.DosMove.271
++DosExecPgm.DOSCALLS.DosExecPgm.283
++DosSetFilePtr.DOSCALLS.DosSetFilePtr.256
++DosGetDateTime.DOSCALLS.DosGetDateTime.230
++DosDevIOCtl.DOSCALLS.DosDevIOCtl.284
++DosAllocMem.DOSCALLS.DosAllocMem.299
++DosFreeMem.DOSCALLS.DosFreeMem.304
++DosScanEnv.DOSCALLS.DosScanEnv.227
++DosSetRelMaxFH.DOSCALLS.DosSetRelMaxFH.382
++DosGetInfoBlocks.DOSCALLS.DosGetInfoBlocks.312

D:\devel\pdos\pdpclib>


Quote
I know these projects that tried to replicate the OS/2 API that are incomplete.
And all copyrighted - so strings attached.

Quote
And projecting our needs as the OS/2 community, there is always around the idea of trying to create an OS/2 personality on a different kernel that can run OS/2 Presentation Manager, Workplace Shell and the native OS/2 software (at some extent, of course it will never be 100% perfect compatible)

Ok, well I have created the ability to create that starting with nothing other than PDOS and the OS/2 API. And that includes if you only have a mainframe, with no other OS available.

That's the theoretical scenario that interests me. If you only had xyz hardware, what could you do? You could run some other OS, including Linux, but if you were trying to do a clean room OS implementation, and wanted to be sure you no-one accused you of stealing copyrighted code, you can't just install Linux instead.

Or some other scenario that I haven't thought of.

Basically - there is presumably some reason why other people are copyrighting absolutely everything - even freeware. They insist that they can't make their work public domain, otherwise (something, apparently diabolical) will happen.

So I want to either make that (something) happen, or prove (at least to some extent) that that theory is incorrect.

Or to make something else happen - perhaps a commercial competitor to OS/2. Which I personally don't consider to be diabolical.

One other thing I have just thought of - since we have cc64 available, a 64-bit version of OS/2 could be created. And that can be pure public domain - even the compiler and assembler. Is that of interest? cc64 is like Microsoft C - pointers are 64-bit but "long" is 32-bit. But actually - that can be changed. We can make cc64 do 64-bit long for the OS/2 version. cc64 has bugs in it though, and those bugs can't really be fixed. However, the author of cc64 created an mm64 which may have those bugs fixed - I haven't investigated that. Maybe I can prioritize that.
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 10, 2025, 06:09:27 pm
That's the theoretical scenario that interests me. If you only had xyz hardware, what could you do? You could run some other OS, including Linux, but if you were trying to do a clean room OS implementation, and wanted to be sure you no-one accused you of stealing copyrighted code, you can't just install Linux instead.

Or some other scenario that I haven't thought of.

Basically - there is presumably some reason why other people are copyrighting absolutely everything - even freeware. They insist that they can't make their work public domain, otherwise (something, apparently diabolical) will happen.
I love Public Domain. I think that public domain helps innovation and I even get happy every January 1st when I see the list of things that turns public domain each year (https://publicdomainreview.org/blog/2025/01/public-domain-day-2025/). Eventually OS/2 will be public domain, but sadly I can not wait 60 more years for it  ;D

But I think the BSD license is flexible enough like public domain, (like the most close you can get to public domain inside the copyright law), where the author gives you a lot of freedom of what to do with the source code, derivative works can be open or close, so I'm not against it, and I don't feel that why that license there are string attached.

Since we have limited resources, I prefer to mix everything as long at does not give any legal problem, and when interest arrive, move to replace the things that are not open or even try to make every line of code public domain.

Just to explain myself better, if we can get on the "lab" (private environment), for PDOS to boot, imitate the OS/2 API, copy all the IBM OS/2 compiled binaries on it to run Presentation Manager and Workplace shell (I know it is a lot of work), that would demonstrate the experiment that an OS/2 personality was created under a different kernel, and give hope for the OS/2 future. At that moment if people want to replicate the experiment at home, they will have to own a license of OS/2 or ArcaOS to be legal.

That will be like an inflection point that will open up some eyes and gives hope, and from it, the efforts will be focused on opening / cloning more of the OS/2 IBM close source components as open source or public domain.  The full "OS/2 Freedom" can not be done in one shot, it has to be done in time with milestones.

But I'm sorry if I'm projecting my own hopes for the OS/2 community to have long term future on your PDOS project. I know you must have your own goals. I just dream away from time to time.

Quote
One other thing I have just thought of - since we have cc64 available, a 64-bit version of OS/2 could be created. And that can be pure public domain - even the compiler and assembler. Is that of interest? cc64 is like Microsoft C - pointers are 64-bit but "long" is 32-bit. But actually - that can be changed. We can make cc64 do 64-bit long for the OS/2 version. cc64 has bugs in it though, and those bugs can't really be fixed. However, the author of cc64 created an mm64 which may have those bugs fixed - I haven't investigated that. Maybe I can prioritize that.

An 64-bits version of OS/2 is what would everybody will like, since we are having limitations with the 32bits. But users will only use a 64's bit version of OS/2 only if everything that is running on their machines now gets working on the 64bits version of the OS. Similar to the migration of Windows to 64 bits. When Windows XP for 64 bits was released, nobody used until "WoW64" (Windows 32-bit on Windows 64-bit) was created, so user didn't have all their 32bits software broken.

Regards
Title: Re: native mainframe mini-clone
Post by: kerravon on September 10, 2025, 07:04:08 pm
But I think the BSD license is flexible enough like public domain
Try to convince anyone currently using the BSD license to simply make it public domain - no dice. They can apparently see a huge difference.

And if they can see something that they can sue me for (or some other constraint), that they wouldn't be able to do with public domain - that's exactly why I want nothing less than public domain.

If you ever find yourself in court about something that is BSD-licensed, you will need to face the UNDISPUTED copyright holder, with copyright law on his side.

With public domain, the person who put their code into the public domain theoretically at least has nothing at all on their side. There is no law to protect someone who isn't even the copyright holder.

Or at least - that's the best you can do. Make absolutely zero effort to copyright your code, and every effort to make it clear that you are no longer the copyright holder.

That's far from what the BSD people are doing. They know it. I know it. And that's enough for me.

Quote
That will be like an inflection point
I consider that the inflection point is already here. You have valid LX executables that have all the tools required to reconstruct not just OS/2, but the entire computer industry. Without needing to use assembler or machine code.

Quote
But I'm sorry if I'm projecting my own hopes for the OS/2 community to have long term future on your PDOS project. I know you must have your own goals. I just dream away from time to time.
My goals have always been fairly vague. It wasn't even my intention to create a Windows clone. An 18 year old girl from Slovakia called Alica Okano turned up and did that, amongst other things, and then vanished without a trace. Prior to that I only supported a.out executables, as was native to EMX 0.9d (which I used on OS/2 2.0 in fact).

Quote
An 64-bits version of OS/2 is what would everybody will like, since we are having limitations with the 32bits.
What limit do you have with 32-bit? I refused to do 64-bit for a very long time - and I'm still not thrilled about it today other than as a means of abstraction. If you need more than 4 GiB of memory, it's probably time to reevaluate your life choices. :-)

Quote
But users will only use a 64's bit version of OS/2 only if everything that is running on their machines now gets working on the 64bits version of the OS. Similar to the migration of Windows to 64 bits. When Windows XP for 64 bits was released, nobody used until "WoW64" (Windows 32-bit on Windows 64-bit) was created, so user didn't have all their 32bits software broken.

Users can have anything they are willing to pay for.

For free, what you can do is run Virtualbox under Linux or whatever, and then have a 32-bit OS/2 and a 64-bit OS/2 running separately. When you've completed the migration to 64-bit, you can then run it directly on a modern UEFI computer.

Assuming someone does the 64-bit OS/2 for free, anyway. Which may well happen. I'm currently making enquiries about the x64 compiler.
Title: Re: native mainframe mini-clone
Post by: kerravon on September 10, 2025, 07:23:54 pm
Actually, I have thought of something else you can have.

The way PDOS-generic works, ie under a pseudobios, it can actually run under other OSes. Something similar to Wine under Linux.

I could create an x64 OS/2 that runs under 32-bit OS/2. The executables would all be "64-bit ready", and they are in fact, genuine 64-bit executables, and use x64 instructions too, but when run under 32-bit OS/2 they would only ever have access to 4 GiB of memory.

And I can get those same executables to run under Win64 and have access to more than 4 GiB of memory.

You'll still need an x64 compiler though. But I should be able to get both cc64 and Visual C to do that. But if you use the more robust Visual C, it will need to be cross-compiled. Not sure what gcc is capable of, but I don't have something working properly for x64.
Title: Re: native mainframe mini-clone
Post by: kerravon on September 10, 2025, 07:36:11 pm
Actually, for it to work, I would need to change modes. I was thinking of the mainframe where that isn't necessary.

And if the pseudobios were to change modes, it would also have access to memory above 4 GiB which OS/2 doesn't use.

Basically the same as a "32-bit DOS extender", except it would be a "64-bit OS/2 extender".

Also, PE32+ format is already defined. Not sure if there is a 64-bit LX format. But even if there is - any reason not to use PE32+ instead? Not sure what the goal is. (not saying I have a goal myself).
Title: Re: native mainframe mini-clone
Post by: kerravon on September 12, 2025, 05:54:21 pm
Basically the same as a "32-bit DOS extender", except it would be a "64-bit OS/2 extender".
Question - can I have a normal executable (.exe), running at the OS/2 fullscreen prompt, that has the privilege required to disable interrupts and switch from PM32 to LM64? If so, what do I need to do to get such privilege on OS/2?
Title: Re: native mainframe mini-clone
Post by: Martin Iturbide on September 12, 2025, 11:16:36 pm
Basically the same as a "32-bit DOS extender", except it would be a "64-bit OS/2 extender".
Question - can I have a normal executable (.exe), running at the OS/2 fullscreen prompt, that has the privilege required to disable interrupts and switch from PM32 to LM64? If so, what do I need to do to get such privilege on OS/2?
This question is outside my knowledge.

I guess it is no, because of the "Protection ring (https://en.wikipedia.org/wiki/Protection_ring)" that OS/2 has.  But I prefer that someone with more knowledge answer that.

Regards
Title: Re: native mainframe mini-clone
Post by: Rich Walsh on September 13, 2025, 01:15:54 am
can I have a normal executable (.exe), running at the OS/2 fullscreen prompt, that has the privilege required to disable interrupts and switch from PM32 to LM64?

Can a Ring 3 executable execute a Ring 0 priveleged instruction that could blow up the entire system? Hell no!

Quote
If so, what do I need to do to get such privilege on OS/2?

You would need a device driver which operates at Ring 0.  In the UEFI version of ArcaOS, the bootloader stub which remains after the OS is running will switch to long-mode to read the machine's NVRAM variables, then will switch back. While doing so, all of OS/2 must stop because it is 100% *incompatible* with long-mode. Why? Because the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled.  You can have 16/32 code or 32/64 code but not 16/32/64.
Title: Re: native mainframe mini-clone
Post by: kerravon on September 13, 2025, 01:00:02 pm
You would need a device driver which operates at Ring 0.
Ok, in that case, I guess I am after the minimum device driver that's sole duty is to switch from ring 3 to ring 0 - callable from any ordinary app.

That would be enough to prove the concept of allowing me to create my own mini-Win64 that purely uses memory above 4 GiB.

Note that I am only interested in executing non-buggy programs, so I don't mind OS/2 crashing the same way that MSDOS crashed if you run a buggy program.

I simply debug the application.

Running everything privileged has worked fine for me for decades. I'm not trying to make a commercial quality product. Fleshing that out is left as an exercise for the reader or whoever sees a commercial opportunity for something more robust.
Title: Re: native mainframe mini-clone
Post by: Dave Yeo on September 13, 2025, 06:02:46 pm
There's some sample drivers at http://hobbesarchive.com/?path=%2fpub%2fos2%2fdev%2fsamples%2fdrivers (http://hobbesarchive.com/?path=%2fpub%2fos2%2fdev%2fsamples%2fdrivers) Perhaps the fastio driver, http://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/dev/samples/drivers/FastIO_A1-0.zip (http://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/dev/samples/drivers/FastIO_A1-0.zip) can be modified. From the blurb,
Code: [Select]
FastioA$ Device Driver for direct port I/O. Based on Holger Veits EDM/2 fastio driver. Modified for use with watcom. Includes watcom project files and example program. (FastIOA1.0.zip)
Title: Re: native mainframe mini-clone
Post by: kerravon on September 14, 2025, 05:47:22 am
Perhaps the fastio driver
Thanks - looking at that, there is something I didn't think of.

It does a far call into the I/O driver, which gives an opportunity for the cs to change, and I'm guessing that while in the driver, it has a privileged cs, but on return to the caller, the original cs is restored to an unprivileged cs. ie it's not that easy to simply say "go privileged".

I guess I can modify the GDT table to make the original cs privileged though. Not sure if ds needs a change too.
Title: Re: native mainframe mini-clone
Post by: Lars on September 14, 2025, 11:25:10 am
You might want to have a look at:

https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi

That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.

The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.

It uses the syscall/sysret instructions as the fastest way to enter Ring 0.
Title: Re: native mainframe mini-clone
Post by: kerravon on September 15, 2025, 06:59:48 am
You might want to have a look at:

https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi

That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.

The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.

It uses the syscall/sysret instructions as the fastest way to enter Ring 0.

Looks exactly what I need - thanks!

There are some competing priorities for what I should do next though - a strategy for this being the most interesting at the moment:

https://gcc.gnu.org/pipermail/gcc/2025-September/246666.html

(I need a solution different from the x32 solution which I now know is 0x67 override)
Title: Re: native mainframe mini-clone
Post by: Lars on September 15, 2025, 09:43:01 am
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)
Title: Re: native mainframe mini-clone
Post by: kerravon on September 21, 2025, 09:45:53 am
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)

Hi Lars.

I'm not sure if you've used the wrong terminology or I'm just confused.

x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).

So this is very different from x86, and that's why the different target exists. ie it isn't i386.

What you described above sounds like you are describing x86 (aka i386 aka 80386).
Title: Re: native mainframe mini-clone
Post by: Lars on September 22, 2025, 05:32:21 pm
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)

Hi Lars.

I'm not sure if you've used the wrong terminology or I'm just confused.

x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).

So this is very different from x86, and that's why the different target exists. ie it isn't i386.

What you described above sounds like you are describing x86 (aka i386 aka 80386).

Correct. The system stays in "protected 32-bit" mode, aka x86. It does not change to long mode.
Title: Re: native mainframe mini-clone
Post by: kerravon on October 13, 2025, 03:08:25 pm
You would need a device driver which operates at Ring 0.  In the UEFI version of ArcaOS, the bootloader stub which remains after the OS is running will switch to long-mode to read the machine's NVRAM variables, then will switch back. While doing so, all of OS/2 must stop because it is 100% *incompatible* with long-mode. Why? Because the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled.  You can have 16/32 code or 32/64 code but not 16/32/64.

I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?

https://bttr-software.de/forum/board_entry.php?id=22728

That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”). What you cannot have is VM86 mode. I verified PM16 on my current Linux installations last week (from a 32-bit task). One significant piece of functionality is missing, although this is just a limitation of Linux, not the machine architecture: having your own SIGSEGV handler intercept general protection faults from that 16-bit code segment. Unfortunately, the kernel does not understand this kind of code and will kill the faulting process directly instead of invoking its signal handler.


Thanks. Paul.
Title: Re: native mainframe mini-clone
Post by: Dave Yeo on October 13, 2025, 07:06:38 pm
Couple of things. There is a 64 bit LX format that NASM supports. Bird came up with the patch for VirtualBox.
Currently OS/2 can use PAE to a limited degree, mostly used as a ram disk. Things are setup by os2ldr before the kernel launches. Current os2ldr is based on QSINIT, from the latest blurb,
Code: [Select]
QSINIT - 2025-08-10

QSINIT had been updated (2025-08-10):

    Binary: ftp://212.12.30.18/public/QS/QS_LDR.ZIP
    Source Code and SDK:  ftp://212.12.30.18/public/QS/QS_SDK.ZIP

QSINIT is a small 32-bit something (you may call it an operating system, or a "small DOS"), that you can write applications for, and that may act as an OS/2 kernel bootloader.

The author of this software, Dmitry Zavalskov, has reserved the copyright to himself. The binary is released as freeware, the source code as freeware for non-commercial use.

Much of the kernel is actually 16 bit, with 16 bit code limited to 1 GB address space. OS/2 2.x before Warp V4 FP13 (Warp Server also supported high memory earlier) only supported 1 GB of address space with the kernel getting the upper half, so you'd have to work from the lower 512MBs (less as much is used by DLL's) and there are still API's that underneath are 16 bit and have to reside in low memory.
Title: Re: native mainframe mini-clone
Post by: kerravon on October 13, 2025, 07:27:51 pm
Much of the kernel is actually 16 bit, with 16 bit code limited to 1 GB address space. OS/2 2.x before Warp V4 FP13 (Warp Server also supported high memory earlier) only supported 1 GB of address space with the kernel getting the upper half, so you'd have to work from the lower 512MBs (less as much is used by DLL's) and there are still API's that underneath are 16 bit and have to reside in low memory.

I'm not sure if we're talking cross-purposes. In a DOS extender, the entire DOS nominally resides in the lower 640k too. That doesn't prevent you from getting access to 4 GiB of memory for your 32-bit program.

Ditto any 64-bit OS/2 extender I created would simply reside above 4 GiB to keep things simple. And the rest would reside wherever OS/2 loaded my executable - lower 512 MiB or whatever.

Note that there is work afoot to stand up a (better) public domain x64 compiler over here:

https://github.com/sal55/langs

(mcc.asm mainly, but also older mcc.c)

There is no public domain notice on either at the moment though. Still fixing bugs that affect my toolchain.
Title: Re: native mainframe mini-clone
Post by: Rich Walsh on October 15, 2025, 08:11:42 am
the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled.  You can have 16/32 code or 32/64 code but not 16/32/64.

I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?

https://bttr-software.de/forum/board_entry.php?id=22728

That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”).


The author of that posting missed an important point: to have code run in AMD64 compatibilty mode, the host OS must be 64-bit. Given that OS/2 is 32-bit, the CPU can only run in one of the legacy modes (i.e. 16 or 32-bit).



Title: Re: native mainframe mini-clone
Post by: kerravon on October 15, 2025, 07:13:25 pm
the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled.  You can have 16/32 code or 32/64 code but not 16/32/64.

I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?

https://bttr-software.de/forum/board_entry.php?id=22728

That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”).


The author of that posting missed an important point: to have code run in AMD64 compatibilty mode, the host OS must be 64-bit. Given that OS/2 is 32-bit, the CPU can only run in one of the legacy modes (i.e. 16 or 32-bit).

Hi Rich. But in what situation is 32/64 allowed (as per your original post), but not 16/32/64?

Perhaps you were considering Windows 10, where you need to choose between 16/32 or 32/64?

I think Windows 10 could have supported 16-bit PM programs (CM16), and CM32 and LM64 all at the same time, but since V8086 wasn't available, they just abandoned 16-bit completely.

But they didn't necessarily have to do that - they could have spent the effort to support Win16 PM16 programs.

Presumably that is not cost-justified though. But I'm just interested in the technical possibility.
Title: Re: native mainframe mini-clone
Post by: Lars on October 17, 2025, 11:00:34 am
I think Rich said it all and I am quoting the Intel Spec (where Intel Term "IA-32e mode" =  "AMD64 compatiblity mode"):

Chapter 6.2.1 "Code-Segment Descriptor in 64-bit Mode"

IA-32e mode uses a previously unused bit in the CS descriptor. Bit 53 is defined as the 64-bit (L) flag and is
used to select between 64-bit mode and compatibility mode when IA-32e mode is active (IA32_EFER.LMA = 1).
See Figure 6-2.
— If CS.L = 0 and IA-32e mode is active, the processor is running in compatibility mode. In this case, CS.D
selects the default size for data and addresses. If CS.D = 0, the default data and address size is 16 bits. If
CS.D = 1, the default data and address size is 32 bits.
— If CS.L = 1 and IA-32e mode is active, the only valid setting is CS.D = 0. This setting indicates a default
operand size of 32 bits and a default address size of 64 bits. The CS.L = 1 and CS.D = 1 bit combination is
reserved for future use and a #GP fault will be generated on an attempt to use a code segment with these
bits set in IA-32e mode.

That said, the Processor will only recognize the "CS.L" flag and treat it as such when it has already been placed into the "IA-32e mode".
Only then will "CS.L" make the difference (CS.L = 0 -> CS.D selects between 16-bit or 32-bit as the default data/address size, CS.L = 1 -> CS.D is ignored and even expected to be 0 and default data size of 32-bit and default address size is 64-bit)

As far as I understand, if you run the Processor in IA-32e mode you will have a code segment descriptor with "CS.L = 1" (in the global descriptor table). This descriptor is used for 64-bit protected mode programs by loading it into CS, it will never change, implicitely cover all of the address range and effectively disables segment protection (which is never used in IA-32e "native" mode).

In order to run 32-bit or 16-bit protected mode programs, you will add additional code segment descriptor with "CS.L = 0" (in the global descriptor table) which when CS is loaded with this segment selector will allow the distinction between 16-bit and 32-bit default data/address size with the Processor looking at the "CS.D" bit.

You should be able to verify this under "64-bit" Windows: if you run a 64-bit program under a debugger, it should have a different CS selector then if you run a 32-bit program under that debugger.