MZ_FillPSP() in dlls/winedos/module.c
I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP() if(length > 126) { ERR("Command line truncated! (length %d > maximum length 126)\n", length; length = 126; } is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126? Afaict having more than 126 characters may exceed some command.com default. Can someone shed more light on the historical reasons behind this code and whether more intelligent truncation can be performed? Thanks, Chris
On Tue, 24 Sep 2002 chrismorgan(a)rcn.com wrote:
I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP()
if(length > 126) { ERR("Command line truncated! (length %d > maximum length 126)\n", length; length = 126; }
is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126?
Yes, it's an intrinsic DOS limitation from the early DOS days. The PSP is a fixed-length structure of 256 bytes, half of which is reserved for the command line; the layout of it is the same as the PDB16 structure (which is the Win16 version of the PSP) in include/task.h. There's no way to fit a longer command line into it; even trying to make the PSP larger won't help for long since the first byte is the command-line length, so it can't be made longer than 255 characters this way anyway. So apps that need unlimited command lines must use a different protocol to pass them. One way could be to use environment variables - for example, I've noticed before that NT's cmd.exe puts the last command line in the "_" environment variable when invoking apps, so I can imagine that apps that take advantage of this look something like cmd = dos_cmdline(); env_cmd = getenv("_"); if (strncmp(cmd, env_cmd, strlen(env_cmd)) == 0) cmd = env_cmd; main(cmd); This is only a guess, though, I don't know to what extent something like this is supported by DOS or Windows itself, nor what protocol they really use.
On Wed, 25 Sep 2002, Ove Kaaven wrote:
On Tue, 24 Sep 2002 chrismorgan(a)rcn.com wrote:
[...]
I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement).
[...]
is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126?
Yes, it's an intrinsic DOS limitation from the early DOS days. [...] This is only a guess, though, I don't know to what extent something like this is supported by DOS or Windows itself, nor what protocol they really use.
Note that this limitation should only be in effect when calling Dos applications. Win32 console applications can receive command lines of up to 32KB on NT and any size on Win9x. So maybe the problem is that you are using command.com as the COMSPEC. Does this happen with wcmd.exe (or the native cmd.exe)? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
On Wednesday 25 September 2002 06:13 pm, Francois Gouget wrote:
On Wed, 25 Sep 2002, Ove Kaaven wrote:
On Tue, 24 Sep 2002 chrismorgan(a)rcn.com wrote:
[...]
I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement).
[...]
is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126?
Yes, it's an intrinsic DOS limitation from the early DOS days.
[...]
This is only a guess, though, I don't know to what extent something like this is supported by DOS or Windows itself, nor what protocol they really use.
Note that this limitation should only be in effect when calling Dos applications. Win32 console applications can receive command lines of up to 32KB on NT and any size on Win9x. So maybe the problem is that you are using command.com as the COMSPEC. Does this happen with wcmd.exe (or the native cmd.exe)?
I haven't tested this with wcmd.exe. I'm also not using command.com as my comspec, I'm using 4nt, a command.com replacement. The real question is how to know if the version of dos is old enough to limit the command line to 126 characters in this case. I would argue that we can go to the full 256 characters at this point. I'm not sure how support of 32kb+ long command lines would be implemented or if many apps even use such long command lines. Chris
On Wed, 25 Sep 2002, Chris Morgan wrote: [...]
I haven't tested this with wcmd.exe. I'm also not using command.com as my comspec, I'm using 4nt, a command.com replacement.
So it is really a dos application. In that case, according to Ove's email it seems there is no way past the 128 character limit (can we increase the PSP size without breaking binary compatibility?). So the big question is: * does this work in real dos? * how does it pass the arguments?
I'm not sure how support of 32kb+ long command lines would be implemented or if many apps even use such long command lines.
I believe 32KB long command lines are already supported... but for Win32 applications, not Dos applications. Just checked and it does work for Win32 applications (at least up to 1500 chars, I don't have the patience to copy/paste more ;-). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
On Wednesday 25 September 2002 07:47 pm, Francois Gouget wrote:
On Wed, 25 Sep 2002, Chris Morgan wrote: [...]
I haven't tested this with wcmd.exe. I'm also not using command.com as my comspec, I'm using 4nt, a command.com replacement.
So it is really a dos application. In that case, according to Ove's email it seems there is no way past the 128 character limit (can we increase the PSP size without breaking binary compatibility?). So the big question is: * does this work in real dos? * how does it pass the arguments?
I suppose I meant more of a shell replacement than a complete command.com replacement. It is a PE executable. Chris
participants (4)
-
Chris Morgan -
chrismorgan＠rcn.com -
Francois Gouget -
Ove Kaaven