Author Topic: native mainframe mini-clone  (Read 2056 times)

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
native mainframe mini-clone
« 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #1 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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #2 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #3 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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #4 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #5 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
« Last Edit: September 09, 2025, 10:32:42 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #6 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #7 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)?

I know these projects that tried to replicate the OS/2 API that are incomplete.
- OS2Linux - Common Public License
- 2Ine - BSD alike and some others.
- OSFree - Also a liberal license.

I even tried to make a comparison on this page, 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
« Last Edit: September 10, 2025, 04:39:31 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #8 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #9 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. 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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #10 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.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #11 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.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #12 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).

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #13 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?

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5469
  • Karma: +49/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: native mainframe mini-clone
« Reply #14 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" that OS/2 has.  But I prefer that someone with more knowledge answer that.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.