The z/PDOS-generic OS executable, seen here (350k in
size - partly because of the current lack of BSS making it
bigger):
D:\zpg\tapes>dir pdos.exe
...
Directory of D:\zpg\tapes
2025-09-07 03:49p 353,866 pdos.exe
as an IEBCOPY unload (see offset 4) with RDWs added
(see offset 0):
D:\zpg\tapes>hexdump pdos.exe 0 100
000000 00380000 00CA6D0F 02001800 0000C000 .8....m.........
000010 00001814 3050200B 00004A7D 0230001E ....0P ...J}.0..
000020 4B36010B 52080200 00000000 00000000 K6..R...........
000030 00000000 00000000 01180000 01000000 ................
000040 FF000000 8F0B6644 049470E8 500072A0 ......fD..p.P.r.
000050 00000001 0000000A 001D012C 00000000 ...........,....
000060 00000000 ....
D:\zpg\tapes>
now supports (certain) OS/2 LX executables too (again - this
is all z/Arch (also S/370) instructions):
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
I believe IBM ported OS/2 to environments other than 386,
but I don't think z/Arch or S/390 or S/370 was one of them.
So z/Windows is also z/OS2 or z/OS/2 or whatever. It's the
same OS - same executable (pdos.exe), supporting multiple
APIs.
Note that part of the drive to do this was to force abstraction.
If I can get something to run on the mainframe, it shows you
what is possible with a particular executable format - or even
concept.
OS/2 executables are bigger because the C library is linked
in, and the DLL is doscalls.dll. Note that I don't use a real
DLL, the OS just has that DLL internally (so you can't add
new DLLs, currently, but there is no barrier to adding that).
So my pdptest.exe ("hello world" sort of) is 84k for OS/2.
Compared to only 14k for z/Arch Win32 using msvcrt.dll.
Now the C compiler I have (gccmvs) only does 32-bit z/Arch
(S/370) code generation.
I do also have a gcc390 available from the same source
base, which is what z/Linux uses. However, that's not
z/OS calling convention.
I am reluctant to spend the effort to modify it (or modify
gccmvs) to produce 64-bit z/Arch code. Because I am
not a fan of the GNU Virus License or other virus
licenses. I only believe in no-strings-attached public
domain, which can be incorporated into a commercial
closed-source (or open source - it's up to the you to
make that choice) product if someone sees a market
opportunity. No need to credit the original author
either, if you think that is bad for marketing (your choice).
Unfortunately writing a C90 compiler has proven beyond
the reach of any of the people who have tried, with the
intention of making their work public domain. Multiple
talented people have tried and fallen flat on their face.
However, we do have the makings of one. Someone with
compiler expertise took a look at it and said there was
about 2 months work remaining on it. But you need
someone with the skills and willingness first.
So here is the 64-bit z/Arch target:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/zarch/asgen.c
The generated code isn't great, e.g. a hello world:
BAL 2,@@T57
@@S57 EQU *
DC X'88'
DC X'85'
DC X'93'
DC X'93'
DC X'96'
DC X'6B'
DC X'40'
DC X'A6'
DC X'96'
DC X'99'
DC X'93'
DC X'84'
DC X'15'
DC X'00'
*
DS 0H
@@T57 EQU *
STG 2,176(,13)
LA 1,176(,13)
BAL 14,@@T56
DS 0D
@@T56 EQU *
NOPR 0
NOPR 0
BAL 15,@@U56
DC V(printf)
DC A(0)
DS 0H
@@U56 EQU *
LG 15,0(,15)
BALR 14,15
L 15,=F'0'
* }
LG 13,128(,13)
LG 14,8(,13)
LMG 0,12,24(13)
BR 14
LTORG
DROP 12
END
But that, plus a tool to create a msvcrt.lib even though we
can't compile the C library itself, gives a 2k executable:
D:\devel\pdos\world>pdmake -f worldz.mak
pdccz -D__MF32__ -D__WIN32__ -D__NOBIVA__ -D__NODECLSPEC__ -D__SHORTNAMES__
-D__NOBIVA__ -I../p
dpclib -I../src -fno-common -o world.s world.c
as370 -mhlasm -mebcdic -o world.tmp world.s
rm -f world.s
forc4to8 world.tmp world.obj
rm -f world.tmp
pdlde --64 --oformat coff --emit-relocs --no-insert-timestamp -s -nostdlib -o
world.exe world.obj
../pdpclib/zarch.lib
D:\devel\pdos\world>dir world.exe
Volume in drive D is PAULDATA
Volume Serial Number is DAB2-6E30
Directory of D:\devel\pdos\world
2025-09-07 05:50p 2,048 world.exe
(note that you can compile on the PC or mainframe)
You can see the 020B signature (ie 64-bit)
D:\devel\pdos\bios>grep -i 20b pecoff.h
pecoff.h: #define MAGIC_PE32PLUS 0x20B
at x'58':
000000 D4E90000 00000000 04000000 00000000 MZ..............
000010 00000000 00000000 00000000 00000000 ................
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 40000000 ............ ...
000040 D7C50000 00000300 00000000 00000000 PE..............
000050 00000000 F0002202 0B02000F 00020000 ....0...........
000060 00020000 00000000 00100000 00100000 ................
But I can't actually test it, because my OS is only 32-bit,
because I only have a 32-bit C compiler for the mainframe.
Only a 32-bit i370 assembler too.
Unless I put in a series of hacks, obviously ...
enter a command
win64
about to call app at address 04ED0000
hello, world
return from app is hex 0
enter a command
The hacks/glue will only work for functions with fixed parameters,
like fputs, not printf.
It works for printf anyway, because I simply declared that printf
only takes a single parameter, which will get a hello world
operational.
And so far I've only added glue to support printf with a single
parameter.
This software, ie z/Windows, really needs to be recompiled with
a 64-bit z/OS C compiler in order to sensibly run 64-bit software.
There are existing C compilers that can presumably do the job,
but I don't have access to them and have not tried them.
If anyone is interested in working with me to utilize them, please
let me know.
If anyone is interested in getting pdcc operational - even
unoptimized/not commercial quality - please let me know.
Any advance on what we have is welcome.
All published as https://pdos.org/zpg.zip plus source code
is in the same place as the above sourceforge link.
BFN. Paul.
P.S. Here's another one of the goals (I'm just mentioning
this because someone asked here why I was doing it -
I'm not after a political debate - happy to have one via
email though). Ideological warfare. To be in the position
to do this. Chat from a couple of days ago:
Who do you consider yourself to be on a political scale?
Communist
Centrist
Nationalist
Monarchist
Militarist
Neutral
Let us know by commenting the flag that represents your ideology, we will be
creating a chart
Someone replied:
Communist
I replied:
So as a communist, you believe in "from each, according to your ability"? would
you like to work with me on PDOS, to the limit of your ability? (see pdos dot
org)
(crickets - it's always crickets)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
