If my memory serves me well, that limit was also DOS'.

Yes it is, but there is a way in the config.sys to increase it, but it doesn't work on DosBox (there is no config.sys), or there it is?

You can boot genuine MS-DOS in DOSBox if you need a config.sys, but you might want to try 4DOS first.

I'm doing that right now, the only drawback is there is no way to get the mount drives working on the MSDOS 6.22, so basically no direct communication between the guest and the host and that is important for me.
I'm trying bosch in the meanwhile with windows 98.

My hope is still on DosBox, everything was perfect until I try the linker. I hope that someone knows how to increase the command line limit

127 characters limit for parameters-length were derived from how memory for .COM file execution allocated.

Dos will allocate 256 bytes for PSP segement, the first 128 bytes were used for various purposes as FCBs and stuff,
bytes at PSP:80 used for command-parameter-length, and the rest 127 bytes used for the parameter string.

Usually linker would accecpt a list file,
or... some compiler/linker package borrowed shell from unix, excecuting the shell,
then running the linker with very long parameter inside that shell. (this the approach that i've seen for some freeware GBA-dev compiler, gcc based)

I was using an external file to load the file list but the os seems to be adding an special character on each line and the linker return an error with file not found.

You can see it in my first post

does the linker react to character '&' ?
the way i see it, the linker think the '&' as a file.

was dos actually understand the '&' characters?
under NTVDM, the '&' means next command.

1dir&ver&ver

that works on NTVDM, i don't think it would works on real dos, though i can't verify it as I have no ms-dos around..

This is the command using an external file with the list (see image)

The result is the error FILE NOT FOUND

LFILES.L content is:
init.obj,sched.obj,timer2.obj,rser.obj,fire.obj,&
srout.obj,comg.obj,comw.obj,comc.obj,comr.obj,house.obj,&
trout.obj,hinp2.obj,hout2.obj,plm51.lib,util51.lib to ssmm

this command execute successfully in DOS 6.22 and up (I tested it)

The difference here is the error and this break line in the list just after executing the command rl51 ...
In DOS 6.22 and up, after executing the command the file list is show right after the >> characters, without the break lines, I think this is the reason why it show the file not found error

ok I found the problem:
the carrier return in the file is CR LF
in regex is \r\n

I changed it to CR only, in regex to \r

AND WORKS!

Anyone have an idea why this file works on MSDOS and not in DosBox, Why DosBox need only the CR and not CR LF???

There is a way to have the same behavior than MSDOS???

dosbox its \r\n handling is not really complete. So there can be bugs in it.
you speak about a regex. where is that located ? (as the problem can be in be in reading files in text mode (no support for that), or the bat file parser or in the shell))

Hi Qbix, I used the regex character just to point out the equivalent characters in regex, because I used notepad++ to search and replace the line breaks in this file from CR LF to CR with regex (\r\n to \r).

All my text files are in Windows ANSI and all of them use the CR LF line breaks.

Batch fines works perfect like this.

The only problem is when you try to redirect a text file content to the command line using a command like this:
rl51 & < SOMEFILE.TXT
If the file contains CR LF line breaks DOSBox handle it as a double line break, so I need to replace only in this fle the CR LF to CR and it works.

I think this would be some kind of bug in the shell parser. The reason why is when I execute this command (rl51 & < SOMEFILE.TXT), I can see a line in the DOSBox status windows with the following text:
SHELL:Redirect input from SOMEFILE.TXT
So I think it's a SHELL problem, maybe in the redirect file parse, if something like that exists in DosBox.

If you need anything to diagnose this let me know. I will be happy to contribute to the project (and solve this 😉 )

it is somewhat of a complex problem.
Of course the shell would need to put the redirected input in "text" mode, but dosbox itself doesn't support textmode in its file reading routines. (Surprisingly (virtually) no game needs it. They all use files in binary/raw mode).

😉
mogollonster, it seems you may be running a version of Archimedes C51.

My version of that 8051 compiler supports:
L51 @filename
to put your large pile of filenames in a file of whatever length you may need.

And, of course, it broke under Win7, just installed this week.

So, my question for the DOSBOX developers is:
Since you are primarily interested in games, and I and Wollonster are primarily interested in running some really old command line stuff, like 1995 time frame in 16-bit mode, (I think with FCBs, since all filenames are 8.3) where would you send us?

P.S. Regular expressions (Regex) are an extremely powerful method of finding strings in text, significantly more powerful than ? and *. Do a "man grep" on your linux box for more information.

P.P.S. My problem is a decade and a half and 150 versions of commercial embedded software built using this tool that I don't wish to re-test.