Alexey1994 wrote:
kerravon wrote:
Well I've spent 30 years doing PDOS, and I didn't have a life before that anyway, so I don't have high expectations.
Have you implemented all your ideas and are no longer predicting the emergence of new ones? Going into commerce? Are you leaving for a desert island? Maybe something else? Are you done creating?
Every time I think "that's it - everything I wanted to prove has been proven", I have a new idea. And it's been non-stop for the last few years. A few hours ago I got the ability to build and execute arbitrary C90 ELF executables (makefile.lnp).
There are a couple of structural things I haven't quite proven. Currently in my pseudo-bios I use setjmp and have a special exit so that programs don't close down the pseudo-bios itself. I believe that that can now be done cleanly using the new "runnum" in start.c in PDPCLIB. It's being proven a bit at a time.
And then there's another revamp.
For a long time I've been using PosOpenFile, PosReadFile etc APIs - inspired by OS/2 functions called DosRead etc.
However, I'm planning on changing those APIs to - fopen, fread etc
pdos-generic has an __os.h file containing the C library (some things are still missing, but they will be added in due course). My plan is to have some defines so that I can import and export that C library.
The OS (PDOS-generic) will import a C library from the pseudo-bios, as well as using a different C library for its internal use, and then export that C library - via multiple inclusion of __os.h governed by different defines.
The C library that PDOS-generic uses will need to import from PDOS.
But PDOS itself will also use it.
So anyway, one full C library (with fprintf etc) will import from a basic C library (only fwrite etc to "wb" files). Everything will use __os.h but in some cases the extra functions (fprintf) simply won't exist (and you will crash if you try to execute them). So a full C library needs to devolve to just the essential C functions.
It will be neat/compact.
If it works at all. I may be missing something.
I've started proving it already with the implementation of OS/2 doscalls.c. OS/2 programs call the C library which calls the low-level functions (DosRead etc), but I simply turn them straight around (in src/doscalls.c) to use fread instead.
After that is done, maybe things will finally stop.
But some of these things are triggered by people sending me code (like pdld), opening up a new branch.
Sector C did that too. It triggered me to create Multisector C.
Oh yeah - and the mainframe hasn't been properly fleshed out yet. I don't support FBA disks yet. Nor do I support FAT overlaid on CKD disks. Nor have I proven FAT on EBCDIC.
So yeah - scratch that "finally stop" thing.
Oh yeah - and then there's the replacement of PDOS/86 to finally move away from the MSDOS API and on to the OS/2 1.x API and NE executables (even for RM16 - and not family API with dual paths).
And the ARM (PdAndro) doesn't do text to speech properly, so blind people will probably get irate. I need to find someone who knows someone. I tried contacting a blind programmer but he broke contact.
And my 2 year old daughter is already saying "keyboard skills" when she wants to play on PDOS/386. She used to say "milk bottle" (I tried to get her to type "MILK" which is phonetically correct (very difficult to find such English words)) because I put a picture of her milk bottle (when someone from Slovakia added limited graphics support to PDOS/386) on PDOS/386, and I kept asking her "do you want to drink real milk or do keyboard skills?" so that's how she picked that up.
She doesn't really use "MILK" or "A" (a.bat to display a big A). She just likes typing on the command line until it fills up and I need to press enter to get a fresh line.
Yeah, doesn't sound like I'm going to stop after all.