Re: [Freedos-user] command.com and long commands
Hi Jeremy. I just realized that the bug fix you have already committed is enough to unblock what I am doing. All I need to do is run “pdmake –n” to produce a batch file, and then I don’t need command.com to accept a long parameter. It would certainly be nice if it did, but it is not necessary. I was successfully able to rebuild my version of binutils 2.14a on Freedos+HX+doslfn with the freecom beta. This now provides me with a replacement Windows environment independent of Linux. Results so far are reasonable, I can produce a viable “as”, but the binaries are not identical and I need to do more thorough testing, and then perhaps hope that the difference is some unimportant uninitialized data or something. Also I need to see if I can build my GCC 3.2.3. Hopefully this is the end of Windows 10, because all I need to do is run Bochs under Linux instead of Win 10. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
Resending – I think it didn’t get through ... Hi Jeremy. I just realized that the bug fix you have already committed is enough to unblock what I am doing. All I need to do is run “pdmake –n” to produce a batch file, and then I don’t need command.com to accept a long parameter. It would certainly be nice if it did, but it is not necessary. I was successfully able to rebuild my version of binutils 2.14a on Freedos+HX+doslfn with the freecom beta. This now provides me with a replacement Windows environment independent of Linux. Results so far are reasonable, I can produce a viable “as”, but the binaries are not identical and I need to do more thorough testing, and then perhaps hope that the difference is some unimportant uninitialized data or something. Also I need to see if I can build my GCC 3.2.3. Hopefully this is the end of Windows 10, because all I need to do is run Bochs under Linux instead of Win 10. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands: command.com, SET and detection
> Hi Jeremy, while you are at it: > > Wondering how Jerome could test whether the current shell > is FreeCOM without needing temp files, ... FWIW, at one time I was trying to > figure out a way to automatically determine whether my executable program was > being called from the commend line (any command line -- FreeCOM or > COMMAND.COM or whatever) or whether I was being EXEC'd from another program. > I could never figure out a reliable way to do that. The best I could do was > go back through the MCB chain and glean the name of my parent and compare it > to a list of known command shell names (COMMAND, 4DOS, etc. -- there are > several of them including the Windows & OS/2 command shells, and IIRC DOSBox > doesn't show any parent at all). That turned out to be so unreliable and > convoluted that I abandoned the idea. I know you're not trying to do the > exact same thing, but it may be similar enough that it could give you some > ideas. I'd be interested if you can figure anything out.___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
FWIW, in my programs (written in ASM) what I do while parsing the command line is look at the length stored at PSP:80h. If it is less than 126, I use the data stored at PSP:81h up to the first 0Dh (Carriage Return) character. If the length is 126 or more, I look for the CMDLINE environment variable and use it (if it exists). If I can't find a CMDLINE environment variable, I go back and use what is stored at PSP:81h up to the first 0Dh character. I never actually use (or trust) the value stored at PSP:80h to provide the actual length, but simply use it as a flag to tell me whether or not I should bother looking for a CMDLINE environment variable. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands: command.com, SET and detection
Hi Jeremy, while you are at it: Wondering how Jerome could test whether the current shell is FreeCOM without needing temp files, I found out that half of the SET options are not yet listed in SET /? help. The currently available actual options of SET would be: SET test=one results in TEST=one SET /C test=one results in test=one (keep case of variable name) SET /U test=one results in TEST=ONE (uppercase variable value) SET /P test=one shows "one:" as prompt, TEST = user entered value SET /E test=one runs command "one", uses 1st returned line as value SET /I displays information about environment size and memory usage Note that SET /E requires a temp file, so it has the same problem as pipelines: It only works with writeable temp dir. You usually want to add a space after the prompt, for example: "SET /P test=please enter a value " with " " after "value". Also note that while SET /E test=vol sets TEST to the message which VOL produces about your volume label (which will depend on which language your FreeCOM has) you cannot SET /E test=ver because VER always first displays one EMPTY line before starting to show version information, so it behaves like "SET test=" and deletes the varible TEST instead of setting it to anything ;-) Maybe you could update the help messages. Thanks! Do you have suggestions for easy, temp-file-free detection of FreeCOM in BAT which works even with older versions of FreeCOM? Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
> Yes, I had hoped to get a release out already but ran > into build issues getting all compilers to build which > was just fixed*. I will look into the cmdline issue, > already filled a bug for it. Then post the release. Hi Jeremy. Thanks for filing the bug report. Could you please hold off doing a formal release until I’ve had a chance to test it? I have a good test environment, and Japheth is active, so hopefully we can put this to bed. Thanks. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
Yes, I had hoped to get a release out already but ran into build issues getting all compilers to build which was just fixed*. I will look into the cmdline issue, already filled a bug for it. Then post the release. * More improvements are needed, but that's a different issue. Jeremy ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
IMO it's a bug in FD command.com. If a command line exceeds 126 bytes, the value at [PSP:80h] "should" be 0x7Fh ( and a 0x0D "should" be placed at [PSP:FFh] ) - that's at least what COMMAND.COM of Win95/98 does. The environment variable CMDLINE will then contain the full command line. It's documented in RBIL. A bit more information from Japheth: freecom sets the length byte of the command tail at PSP:80h to the "true" value of the commandline length. If the command line is 130 chars, this value will be 82h. However, since the PSP has a size of 256 only, just the first 127 bytes are copied to PSP:81h-ffh. Note that Eric has replied now, and I have to digest that. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
Hi Paul,
> When I run a long command, e.g.
>
> pdptest ... (to exceed 126
> characters), and it is a Win32 executable so HX
> gets involved, I get a crash.
You write that Japheth writes:
> IMO it's a bug in FD command.com. If a command
> line exceeds 126 bytes, the value at [PSP:80h]
> "should" be 0x7Fh ( and a 0x0D "should" be placed
> at [PSP:FFh] ) - that's at least what COMMAND.COM
> of Win95/98 does. The environment variable
> CMDLINE will then contain the full command line.
> It's documented in RBIL.
In FreeCOM, MAX_EXTERNAL_COMMAND_SIZE is 125, because
for normal command lines, psp_cmdlineLength is max that,
followed by psp_cmdline with trailing \r AND \0 chars.
Note that FreeCOM unfortunately never uses psp_... so
the code is harder to read.
Now when you have a LONG command line, two areas of
the C code become relevant:
shell/init.c is what received the command line when
you start a new instance of FreeCOM, which probably
is what HX does to start a Windows program, although
I am not sure why it does it like that.
https://github.com/FDOS/freecom/blob/master/shell/init.c
int initialize(void)
{
...
/* Aquire the command line, there are three possible sources:
1) DOS command line @PSP:0x80 as pascal string,
2) extended DOS command line environment variable CMDLINE,
if peekb(PSP, 0x80) == 127,&
3) MKS command line @ENV:2, if peekb(ENV, 0) == '~'
&& peekb(ENV, 1) == '='
Currently implemented is version #1 only
*/
cmdlen = peekb(_psp, 0x80);
if(cmdlen < 0 || cmdlen > 126) {
error_corrupt_command_line();
cmdlen = 0;
}
...
This would show, if you are using the English version:
Corrupt command line. This is an internal error and is related to
the system COMMAND.COM runs in. Please report this error.
The other part is that when you already have FreeCOM running
and want to execute some other app, via lib/exec.c
https://github.com/FDOS/freecom/blob/master/lib/exec.c
int exec(const char *cmd, char *cmdLine, const unsigned segOfEnv)
{
...
assert(cmd);
assert(cmdLine);
assert(strlen(cmdLine) <= 125);
...
as well as shell/command.c, bad indent caused by tab size 8
in my viewer while apparently the file assumes tab size 4:
https://github.com/FDOS/freecom/blob/master/shell/command.c
void execute(char *first, char *rest, int lh_lf)
{
...
if(strlen(rest) > MAX_EXTERNAL_COMMAND_SIZE) {
char *fullcommandline = malloc( strlen( first ) + strlen( rest )
+ 2 );
error_line_too_long();
if( fullcommandline == NULL ) return;
sprintf( fullcommandline, "%s%s", first, rest );
if( chgEnv( "CMDLINE", fullcommandline ) != 0 ) {
free( fullcommandline );
return;
}
free( fullcommandline );
}
...
This displays "Commandline longer than 125 characters."
and leaves it up to the user to wonder whether that is
a problem. Actually it cannot know which apps support
long command lines, so thata probably is OK.
Also note: CMDLINE is only used for com and exe, not for bat.
Unfortunately, the above part is the ONLY place which uses
MAX_EXTERNAL_COMMAND_SIZE, while the assert above hardcodes
125 and init.c hardcodes "negative or above 126" and fails
to to anything about long command line used when it is
started with one itself, by some outside caller.
shell/cswapc.c contains this:
https://github.com/FDOS/freecom/blob/master/shell/cswapc.c
DoExec(char *command,char *cmdtail)
{
...
len = strlen(cmdtail);
if (len >= 127) len = 127; SEE BELOW
dosCMDTAIL[0] = len;
dosCMDTAIL[1+ len] = '\r';
...
Because dosCMDTAIL is ((char far*)MK_FP(_psp, 0x80))
this would actually overflow the buffer by 1 byte :-p
Japheth's description implies that 127 has to be used
as magic length, together with injecting an early \r
into the PSP and not bothering to put an \0 after it.
So proper code without long command line support was,
only changing the SEE BELOW line:
if (len > MAX_EXTERNAL_COMMAND_SIZE) len = 126;
But proper code for long command line support would
make a case distinction for long versus short lines.
Note that the assembly language parts of FreeCOM do
not process long command lines at all, they simply
assume that the C parts have already limited the PSP
command line in a sensible way and do not care whether
or not the environment contains any CMDLINE variable.
This probably is OK.
You could probably change SHELL or COMSPEC to let HX use
for example DJGPP BASH instead of FreeCOM to see whether
HX itself works okay, but that will have big side effects
and BASH does not use the same "command.com /C command"
style syntax as command.com, while /C likely is hardcoded
into HX when it invokes programs.
In short, the CMDLINE support of FreeCOM looks sketchy
at best, in spite of having been added at 0.84pre7 and
me looking at https://github.com/FDOS/freecom today,
not 17 months ago when CHANGED got the 0.84-pre7 info.
Jeremy and Bart seem
[Freedos-user] command.com and long commands
Hello. When I run a long command, e.g. pdptest ... (to exceed 126 characters), and it is a Win32 executable so HX gets involved, I get a crash. Japheth has debugged it and reported his findings. Could someone please confirm that his analysis below is correct and it is a Freecom bug? Or is more information required? Thanks. Paul. IMO it's a bug in FD command.com. If a command line exceeds 126 bytes, the value at [PSP:80h] "should" be 0x7Fh ( and a 0x0D "should" be placed at [PSP:FFh] ) - that's at least what COMMAND.COM of Win95/98 does. The environment variable CMDLINE will then contain the full command line. It's documented in RBIL. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
