This has only just started working, so there may still be issues,
but the linker pdld.exe has now been proven to be able to
create an unloaded DOS/VS phase - offline - ie on Windows. The
code is C90-compliant so should work anywhere, including
VSE itself.
I am planning on using the minimal possible assembler to
get PDPCLIB operational - as a precursor to doing the same
on CMS and MVS.
And this is also the precursor to getting z/PDOS-generic to
operate as a mini VSE clone similar to how PDOS-generic
currently acts as a mini Amiga clone. That will require a
modification to sapstart.asm to allow forwarding of SVCs
to the C code. Although another way is to avoid doing the
SVC calls entirely and get the VSE program to detect that
it is running under an SVC-less environment and switch to
doing callbacks for the SVC routine is possible.
Regardless, going forward, almost everything will be in C
instead of assembler, unless I'm missing something
fundamental. Before you say - all the interfaces are designed
as assembler macros - you need to use assembler just like
on MSDOS - well - just like MSDOS, you can have C wrappers
for those APIs and they all end up as calls to int86x which is
the only thing that needs to be written in assembler. If you
look at the MSDOS 4 source that Microsoft released, you
can see that they actually did that for MSDOS - they created
functions like DosWrite() very similar but not identical to
OS/2 DosWrite() - but apparently didn't want people to have
this C interface to MSDOS and wanted them to use OS/2
instead.
To do it offline, you need an assembler too. That is from a
forked binutils 2.14a, ie gas, and I call it as370.exe. Both
pdld.exe and as370.exe are in the "dos" directory of the
VHD available from pdos.zip at (look
where it says "hard drive image"). They are both Windows
programs meaning you can run them under real Windows
or PDOS/386 (which is effectively a mini-clone of Windows
unless you want to quibble about the definition of "mini",
quibble about the definition of "clone", quibble about
the definition of "Windows", or quibble about the definition
of "of" - you know who you are and you have way too much
free time).
as370.exe produces ELF. pdld.exe accepts as input either ELF
or standard object code as produced by the DOS/VS
assembler (and then punched - that's why I was asking how
to punch object code). And you can mix them. The linker
will match lowercase hello_there in an ELF object to HELLO@TH
in DOS/VS object file.
Note that punching a phase for transportation (similar to doing
an IEBCOPY unload on MVS) produces a fully-resolved object file
and it is this that pdld outputs. In fact, pdld outputs for MVS too,
and it is in fact an IEBCOPY unload too (quibbling aside). So you
need to process that using LNKEDT to put it in the CIL (or some
equivalent for z/VSE or VSEn).
The assembler as370 is only semi-hlasm-compatible. You can see
what the assembler code looks like here:
and I test it by running this:
which runs on VSE/380 (note that the documentation is wrong
and the VSE380 environment variable should point to c:\vse380\run
or whatever - add the "run"), but it should be simple enough to
adjust for whatever VS or VSE environment you are using.
The program as it currently stands just has an assembler program
calling a C function that returns 6 in R15 and then the assembler
goes into a loop so that you can see that in Hercules by pressing ESC.
I'll switch it to do something WTO-like in the future and then
expand until I have a new version of PDPCLIB almost entirely
in C. And have z/PDOS-generic updated each step of the way.
Note that there is no barrier to making as370 more hlasm-compatible
and also I am thinking I might use the C preprocessor to have
conditional assembly so that both the DOS/VS assembler and
as370 can handle it while waiting for that to happen.
Note that I am having fun probing the "new" environment from
the safety of a C compiler and securing one thing at a time in C.
BFN. Paul.
