On Jun 1, 2024, at 7:46 PM, Wolf Bergenheim via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote:


On Sat, Jun 1, 2024 at 8:57 PM Bernd Böckmann via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote:

On 15.05.2024 16:01, Wilhelm Spiegl via Freedos-devel wrote: 
> [...]
> I hope that this behaviour is reproducable.

Some details: cursor positioning algorithm is broken if scrolling is
involved, because it does not correctly keep track of the screen
coordinates the command line starts. Further, the routines were never
meant to function with command lines longer than 127 characters, failing
if the command line spans over more than two lines. Now that FreeCOM
supports commands of up to 254 characters, this breaks.


Interesting. How does FreeCom do this?

At least in the exec_blk[1] struct the member cmd_line is a FAR ptr to a CommandTail[2] struct which defines a 127 max characters for the command tail.
If you go over that, you might have an overflow? Or does FreeCom handle this in some other way?

Historically, I think this limit is why many DOS programs have the option to either read arguments from a file or from STDIN.
I've had DOG be at 200 characters but I've never really tried pushing the limit... I tried but get an ugly crash, but FreeCom doesn't crash, how does it make the command tail > 127 bytes?


-Wolf

-- 

  |\_
  | .\---.
 /   ,__/


_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

FreeCOM copies the first 126 bytes to the new PSP terminated by 0xd. Then it creates an environment variable “CMDLINE” with the entire command line. 




_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to