I am writing a tiny TSR program, and I want it to take as little memory while installed as possible. The memory footprint of every loaded DOS process, including a TSR, includes a data structure known as the Program Segment Prefix, taking 256 bytes. But since I realised that I don’t actually need all the information in the PSP while my TSR is running, I can put my program’s code in the PSP area to save some memory, effectively shrinking the PSP.
In particular, I don’t need the command line buffer; this allows me to slash the size of the PSP in half. I don’t use FCBs for I/O either (in fact, I don’t do any I/O at all), so I can cut the default FCBs too, further shrinking the PSP to 92 bytes. I think I might be able to reuse the JFT as well, by reducing the file handle limit to zero with an appropriate syscall (or just reducing the limit in the PSP directly), earning me 20 bytes back. (Maybe 19, if I want to guard against the odd overflow or off-by-one bug.) But then there are fields I am much less sure about. From offset 0x4e, there are some fields RBIL claims are ‘unused by DOS versions <= 6.00’, so maybe I could get away with overwriting them too, but then there are some rather cryptically described as being used by Windows 3.
My question is: how low can I go? How much of the PSP area can I get away with reusing for my own purposes with impunity? At which point should I expect the system to start acting up? And while I recognise that this makes the question rather fuzzy, I don’t necessarily mean the vanilla MS-DOS kernel here, but also clones, emulators (including Windows), programs like MEM, MSD, or anything else that might want to walk the process list and read the contents of PSPs. (In fact, I wouldn’t be too surprised if the answer were ‘zero, as long as you don’t invoke any syscalls’ as far as the vanilla kernel itself is concerned.) Also, since I am pretty sure I am not the first one to come up with this technique, I’ll also welcome pointers to other software using this trick.