long command line crashing

[kerravon86]

I have a dummy Windows program that looks roughly like this:

void mainCRTStartup(void) { return;

And it works fine with a short parameter (first execution below), but execution with a long parameter crashes, and you can see from the 32-bit registers being printed that it must be in HX.

Note that command.com should be setting the CMDLINE environment variable when it encounters the long command line.

Any ideas?

Thanks. Paul.

C:\DEVEL\PDOS\SRC>pdptest abc C:\DEVEL\PDOS\SRC>pdptest abc dddddddddddddddddddddddddd eeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeee ffffffffffffffffffffffff gggggggggggggggggggggggggggggggggggg Commandline longer than 125 characters. Exception 0D EAX=00000280 EBX=0000549D ECX=00000001 EDX=00000274 ESI=00000100 EDI=00000100 EBP=00005898 ESP=00005702 EFL=00013246 EIP=000009FE CS=0097 (00111000,000058CF,00FB) SS=008F (00111000,000058CF,40F3) DS=009F (00025B60,0000010F,00F3) ES=00D7 (00025C80,000000FF,00F3) FS=0000 (****,****,) GS=0000 (****,****,) LDTR=0038 (FF80F000,00000FFF,0082) TR=0030 (0002B7E0,00000067,008B) ERRC=0000 (****,****,****) PTE 1. Page LDT=1FFEF467 GDTR=07FF:FF80E000 IDTR=07FF:FF80E800 PTE CR2=00000067 CR0=E0000031 CR2=00000000 CR3=1FFFF000 CR4=00000200 TSS:ESP0=00002828 DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400 LPMS Sel=0087(01) RMS=2DFD:0200 open RMCBs=0000/0000 ISR=0000 [EIP]=F3 67 A4 F7 C7 00 FF 75 03 B0 0D AA [ESP]=4A5D 0000 475A 0040 5898 0000 5722 0000 00005712=549D 0000 0274 0000 005B 0000 0204 0000 00005722=008F 008F 2875 00C7 5746 0000 0040 0040 00005732=5898 0000 574A 0000 F000 0000 572A 0000 00005742=0001 0000 0507 0021 00C7 4550 0000 014C 00005752=0006 6BC7 60B3 0000 0000 0000 0000 00E0

C:\DEVEL\PDOS\SRC>

[Baron-von-Riedesel]

I have a problem reproducing this error, because

• MS-DOS 7.1 command.com doesn't allow me to enter more than 126 chars

• the FreeCOM version that I have will set the length of the cmdline to max. 0x7E. That's not enough to make HX's dkrnl32.dll access the CMDLINE environment variable. The relevant source in dkrnl32\getcmdl.asm is:

    invoke GetDosCmdTail, addr cmdline, sizeof cmdline
    .if (edx > 7Eh)
        invoke GetEnvironmentVariableA, CStr("CMDLINE"), addr cmdline, sizeof cmdline
    .endif
    inc eax
    mov dwSize, eax
    invoke LocalAlloc, LMEM_FIXED, eax

So please supply your FreeCOM version for download!

[kerravon86]

Hi Japheth. Thanks for looking into this problem.

the FreeCOM version that I have will set the length of the cmdline to max. 0x7E. What version are you using? Mine is from 2006 but has this feature. So please supply your FreeCOM version for download!

Please find it here:

http://pdos.org/temp.zip

Thanks. Paul.

[kerravon86]

Another thing you should be aware of. When I use command.com I have this in my config.sys:

shell=c:\command.com /p /l:1024 /e:32766

command /? incorrectly says you can put /e up to 32768, but actually 32766 is the maximum.

Unless you have a reasonable /e command.com won't be able to create CMDLINE (and it reports an error) prior to executing HX programs.

[andrewbird]

command /? incorrectly says you can put /e up to 32768, but actually 32766 is the maximum.

That seems to have just been fixed, see https://github.com/FDOS/freecom/issues/47

[Baron-von-Riedesel]

Please find it here:

Ok, I got it. However, I might also need your executable "pdptest.exe". You told that it is a dummy "windows" program, but this is somewhat strange, because in this case you shouldn't get a hdpmi32 register dump when an exception 0x0D occurs - instead you should get a dkrnl32.dll register dump (which looks very different). Also, I can see ( from the dump that you provided ) that the crash occurred in dpmild32.exe. So please tell me what version of dpmild32 you are using.

[Baron-von-Riedesel]

btw, the crash happens in dpmild32 - file dpmildr.asm, SetCmdLine:

SetCmdLine proc public uses es ds

if ?32BIT
    pushad
else
    pusha
endif
    mov ds,cs:[wLdrDS]
    xor al,al
    xchg [fLoadMod],al
if ?32BIT
    lds esi,es:[ebx+0]  ;get dos command tail
  if _TRACE_
    movzx cx,byte ptr [esi]
  endif
    @printf <"SetCmdLine enter, es:ebx=%X:%lX cmdl=%X:%lX size=%X",lf>,es,ebx,ds,esi,cx
else
    lds si,es:[bx+2]
    @printf <"SetCmdLine enter, es:bx=%X:%X cmdl=%X:%X",lf>,es,bx,ds,si
endif
    mov es,cs:[wCurPSP]
    and al,al
    jz @F
    call strlen    ;get size of DS:E/SI into CX
    mov al,cl
    jmp scl_2
@@:
if ?32BIT
    lods byte ptr [esi]
else
    lodsb
endif
scl_2:
    mov cl,al           ;number of chars
    mov ch,00
    mov di,0080h
    stosb
if ?32BIT
    movzx ecx,cx
    movzx edi,di
    rep movs byte ptr [edi],[esi]                ;<<<<<<<<<<<<<<<<<< crashes HERE
else
    rep movsb
endif
    test di,0FF00h
    jnz @F
    mov al,cr
    stosb
@@:
if ?32BIT
    popad
else
    popa
endif
    @trace_s <"SetCmdLine exit",lf>
    ret

SetCmdLine endp

Register AL holds the original value of the command line length. It's 0x80, and dpmild32 doesn't expect such a value, it expects a max value of 0x7F.

[kerravon86]

Hi Japheth.

However, I might also need your executable "pdptest.exe". http://pdos.org/temp2.zip So please tell me what version of dpmild32 you are using. I’m using HX 2.18. My dpmild32 is dated 2018-10-13 and is 18,276 bytes in size. Thanks. Paul.

[Baron-von-Riedesel]

Ok, I can reproduce the crash.

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 workaround may be: set environment variable DPMILDR=8. This will cause HX to run the new program as a new DPMI client. The code causing the crash in dpmild32.exe isn't called in this case.

[kerravon86]

Thanks so much Japheth. Sorry you had to debug a problem that was someone else’s fault.

Let me report this to the freedos group and see if I can get it resolved and I’ll get back to you.

[kerravon86]

Hi Japheth. I have reported the problem, but no response yet. It occurred to me that it would be helpful if you could tell me what they are actually doing, instead of the correct thing that is documented.

Also, why were you not able to reproduce this problem yourself? You needed both my command.com and my "dummy" program. What is so special about my environment? Am I the first person to ever run a Windows program with a long command line?

[Baron-von-Riedesel]

... it would be helpful if you could tell me what they are actually doing, ...

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.

Also, why were you not able to reproduce this problem yourself?

I usually set environment variables DPMILDR=8 and HDPMI=32 ( this makes win32 programs run into separate address contexts ) - the error doesn't appear then. Your "dummy" program wasn't really necessary.

[kerravon86]

Hi Japheth.

The Freecom people have acknowledged a problem and seem to be in the process of fixing it. Can you please stand by so that I can test it with HX. I have a good test environment. Thanks.

https://github.com/FDOS/freecom/issues/51

[kerravon86]

Hi Japheth.

I was given a beta version of command.com to try, and it resolved the issue. Please email me (mutazilah at gmail) if you want a copy of it. I'd rather not make it publicly available because it doesn't identify itself as a beta, it identifies itself as the next release!

We can close this HX issue out if you want, or wait until Freecom formally announces, with a bug fix in the repository and maybe release, that the problem is entirely theirs.

Also note that although they can execute other programs properly, command.com cannot currently accept a long parameter, but they are planning on fixing that this weekend. Then I will retest the other open HX issue on long command lines.

[kerravon86]

This has been fixed in Freecom now and formally released:

https://github.com/FDOS/freecom/releases/tag/com085

And I have tested it and it works great.

Thanks for your assistance!