Hallo Herr Bernd Böckmann via Freedos-devel, am Mittwoch, 19. Februar 2025 um 21:05 schrieben Sie:
> I agree with Tom that changing the EXE header should be to way to go. > I did a quick test by patching the COMMAND.COM header by hand with a hex > editor. > When I patch offset 0x0A to be 0x400 (16k additional memory), total initial > allocation size becomes ~80K. > That patched binary works, as it does not fit into the 69K UMA bytes, and > thus is loaded low. > However, I am not sure to which value the minimum additional paragraph value > should be set to. As the ptchsize as part of the build process uses some > fixed values, I am questioning myself if these values were determined by > proper reasoning, i.e. determining the amount of RAM actually needed, or > merely by some "this value SHOULD fit" approach. > As the executable certainly works with the 87K UMA mem, this at least > provides us with an upper bounds (for this specific v0.86 build). Even that isn´t necessarily true. Requiring minimum load size of 87K makes it load low, where it (at least theoretically) can dynamically extend itself further. COMMAND has worked for ages with required heap size of 6K, so making this 8K is probable a safe bet. To determine this scientifically, leave the field at 6K (or even 0K), run COMMAND without XMS (to avoid swapping), then run MEM /D to see what it expanded to and is required. I don't remember commands that malloc() memory (COPY and DIR /S use dos_alloc()), but if they exist they should run before MEM memory reporting. Note: the additional memory required not only provides protection against loading into a memory area that is too small, but also the case where you load a TSR right after COMMAND, and COMMAND can no longer expand it's memory. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
