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).
Bernd On 19.02.2025 15:44, tom ehlert via Freedos-devel wrote:
According to EXEHDR, my (somewhat older) 0.85 version needs 63K to even start executing. Heap is allocated behind this, up to all available memory (here 69K). So a maximum of 6 K is available for allocation. I know that COMMAND allocates a couple of memory for history, ALIAS, etc. So it is possible (and after so much failure to work probable, that COMMAND just starts, but can't allocate 40 Byte for command line, making it completely useless. 2 possibilities a) convert SHELLHIGH= to SHELL= not such a big loss given that COMMAND has a resident size of ~3K b) (better) get EXEHADR from the internethttps://ecsoft2.org/system/files/repository/exehdr_exe-20040105.zip (and I have not the faintest idea what they do in these 40K) EXEHDR /MIN:8192 command.com requires a minimum additional load requirement of 8192 byte available for heap. This should become part of the build process. So this loads high if at least ~71KB are available, low if not. While that's fine for experimenting, EXEHDR is not open source. most likely tools\patchsize command.com +6K does the same, but should be changed to tools\patchsize command.com +8K I don't have VMWARE to reproduce the bug
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
