For the benefit of blind and deafblind users, the above pictures, which are in fact just text, as everything in PDOS is, can be found in text format here.
Certain things that would normally appear in the OS's own code have instead been put into/hidden in the C library.
Similar to how MSDOS used the IBM PC BIOS so that it was protected from the details of the hardware, I rely on this separation existing. Modern x64 systems have UEFI instead of a BIOS, but it's conceptually the same, just more "C-friendly". I have taken that "C-friendly" concept to a new-level. Instead of directly dealing with the UEFI "Read" function, I put that into the C library, and present it as a normal fread() function. Note that you get fread() and fwrite() - which have fixed parameters - you shouldn't expect to get fprintf(), with variable parameters. Depending on the implementation, you may get an entire C library - but don't depend on it. This layer allows a "nicer" interface to UEFI (e.g. they attempt to force UCS-16 - I convert it straight back to normal char), it allows turning a Linux system into nothing more than a "glorified BIOS" designed to run PDOS-generic - especially useful under Android, and the basis of PdAndro. And the same conversion of UCS-16 to char also allows conversion between EBCDIC and ASCII. The use of a pseudobios allowed the creation of PDOS-generic - a totally portable (quibbling aside) operating system. You "just" need to provide a pseudobios.
PDOS is written on the assumption that it may be running as a guest under some host. And IF that is the case, you MAY be able to access a file on the host system simply by adding a colon (":") to the beginning of a filename (anywhere). E.g. "hexdump :fred.dat" would (potentially) access a file called fred.dat on the host system. Not only that, but the host itself may be a guest under some other host, and export the same capability. And this could go on for multiple layers. So you can actually do "hexdump :::::fred.dat" to go up 5 layers of hosts, assuming each host follows the same "standard" (subject to change if ISO has a better suggestion).
I noticed the size of the main MSDOS executables - IO.SYS, MSDOS.SYS and COMMAND.COM. They are very small (33k, 37k and 38k respectively for MSDOS 4.00 for example). Was it possible to write the equivalent of that in C90? If it was written in C90, would that mean that a simple recompile would have converted it from a 16-bit OS to a 32-bit OS? The answer to that is a bit complicated, but PDOS/86 (16-bit) and PDOS/386 (32-bit) exist to answer this question. PDOS/386 remains the most advanced version of PDOS due to it being the oldest (work started in 1994), and can be found in pdos/src. The next flavor of PDOS was an attempt to get something working on the mainframe. This was basically a complete rewrite, and the result was called PDOS/370 or z/PDOS. This can be found in pdos/s370. Finally, while attempting to get PDOS operational on the Amiga, the concept of running PDOS under Amigados was conceived, with the pseudobios concept, and a third flavor was written - sort of from scratch - called PDOS-generic. This can be found in pdos/generic, main source files bios.c for the pseudobios and pdos.c for the OS proper. The first two OS flavors may be retired, or be used as glorified pseudobioses.
It was unclear to me when I started how much of an OS - and indeed applications - could be written in standard C90, and thus be portable. Surely something like accessing the serial port required system-specific code? But actually it turns out that the IBM PC BIOS has calls to access the serial port. Why can't that be just another file, and I use fopen of "COM1:" to open it? Why not indeed! And with control of the C library, I was indeed able to hide that away as "just another file". But it's bidirectional, right? C90 has that concept too - reading and writing to the same stream - just open with r+b or w+b. C90 requires you to do an fseek before switching modes - what is the equivalent concept there? Seek 0 bytes from SEEK_CUR. A hard disk - just another file. Just give it an appropriate name so that the C library knows what to do. Instead of the IBM PC BIOS call to access drive 0x80 (the C drive), you do something conceptually similar like fopen("0x80"). You have a C library - knock yourself out. Note that the PDOS-generic pseudobios (bios.c) currently has directory manipulations in it, but those too will likely be moved into the C library.
There was never any real plan for PDOS. I just thought it should exist. And exist as public domain too - so whatever market opportunity that MAY exist - there were zero restrictions imposed by the authors. I kept the focus on being able to run C90 applications at the command line. Just to try to match MSDOS's ability to do the same thing. C90 is portable - by definition - so what's preventing that MSDOS-equivalent from running on the mainframe? It took decades to answer that question, and the answer turned out to be "nothing". It didn't help that I was asking the wrong question for decades. I was willing to change peripherals, and replace the OS, but instead I was asking why I couldn't use a VT100 on MVS, and that was taken literally - plus I was only vaguely aware of my own goals - ie, nothing concrete. The previous website was a complete mess because there was constant breakthroughs, and I concentrated on capitalizing on them and just added yet another target to my website.
With the focus on C90 - every man and his dog had his own API to open and read a file. In Windows it is ReadFile. With PDOS-generic, I simply export the kernel's C library and allow that to be used. This is meant to be functional - enough function for you to be in a position to write a replacement OS. I'm not claiming this to be a good design that everyone should follow. But at some point I realized that that Windows ReadFile API could be written in terms of C90 itself. So ReadFile calls fread(). And then what is the underlying system that I am running on? OS/2? That uses DosRead(). So my fopen eventually calls DosRead(). So OS/2 can run Windows programs with an appropriate library and a recompilation. Or vice-versa. POSIX is defined in terms of library functions, not raw syscalls. So - the POSIX libraries - at least the file reading ones - can be written in terms of C90, and run on every other platform. So Windows becomes a POSIX subset. Linux becomes a Windows subset. Everything is everything, if you're only trying to run C90 applications. And if you put this functionality into the OS itself, instead of a library, then the OS itself turns into a Windows mini-clone, an OS/2 mini-clone - even at an executable level - ie you can take certain Properly-Written (TM) completely valid Windows programs and run them under PDOS/386 or PDOS-generic. A Linux mini-clone is a bit different. Those executables can contain interrupts, which may not be available under certain pseudobioses. For those, your PW (TM) program needs to be written to accept the *possibility* of an "interrupt override", where the OS provides something special to the application that allows it to know to do an int80() callback instead of executing a real INT 80H. This technique was conceived in an Atari forum during an attempt to create an Atari mini-clone that would run on e.g. an Amiga.
A complete list of downloads is available on the history page. Here are the main ones of interest:
PDOS/386 - first 32-bit attemptNow we switch to flavors of PDOS-generic.
z/PDOS-generic - mainframePdAndro for Android smartphones with supplementary executables for ARM32, ARM64, x86, x64 - noting that most of these are valid Win32/Win64 executables that run on the Microsoft equivalent (noting that Microsoft no longer supports ARM32, but when they did, they were valid). And associated Android apps Unzip Andro (useful for unzipping the above archives, especially if there is no unzip facility in your installed file manager, or it misbehaves) and Sign Your APK (useful if you choose to download (or build from source) the PdAndro APK yourself, and wish to replace the libbios.so/bios.exe using tools (gccerm.exe etc) on the Android itself - probably only possible with ARM32, x86 and x64 - and rezip it with the zip executable in the ARM32 distribution at least - and need to sign your development version).
Most discussion of PDOS now happens on either this Discord server (note that my Discord id is "kerravon") or this, message area.