[AD] a study of command line handling under dos and windows.

[Henrik Stokseth <hensto@xxxxxxxxxx>]

the subject line says it all. here are my findings on the size 
limitations of the command line:

the size of the command line is:

- not directly limited by DOS int 0x21, function 0x4b (execute), but 
limited indirectly by PSP UPA (program segment prefix, unformatted 
parameter area) which is where DOS EXE and COM programs get their 
command line parameters from. the UPA is 127 bytes large and contains an 
ASCIIZ string.
- directly limited on ms-dos (or win9x) shell (command.com) to 126 bytes.
- not limited on nt shell (cmd.exe), but indirectly through int 0x21 
when running DOS apps. it also seems like the first argument 
(application name aka. argv[0]) passed on the nt shell command line has 
a size limitation of 254 bytes. i do not know if this is including or 
excluding file path. (filenames can be max 254 bytes on VFAT or NTFS)

on windows the command line can be any size but can be limited by int 
0x21 when passing command line to or from dos apps.
win32api calls CreateProcess() and GetCommandLine() have a limit of 32K 
on the command line.

on older unixes or older win32 operating systems, the max size of the 
commandline may be as low as 1K, or at least so i have heard.



so what does that mean for allegro?

using only windows tools during compile means only command.com can lay 
limitations on the command line. a nice workaround for that is to 
redesign runner so that we can set the $SHELL environment variable to 
$RUNNER during make. this means that all commands are executed using 
runner.exe (must be win32 console app) and not the shell. the runner 
utility can get the commandline directly this way and run the tools, it 
could also pass through shell internal commands to the $COMSPEC shell or 
act as an emulation layer for missing bourne shell commands. this in 
turn will allow us to clean up the makefiles a lot. using response files 
are unneccessary if the compiler is a win32 console application.

gnu apps has a nice black magic way of passing long command lines which 
i havent looked at yet.

on non-gnu compilers where the allegro build readme lists gnu make as a 
prerequisite, a win32 variant should be advised. using a dos variant of 
make means it will not be able to pass long command lines to the tools 
using my described method. this assumes the tools are win32 console apps 
which is able to receive long command lines and that command.com is not 
used as subshell. calling dos tools with response files will still work 
using the new runner scheme.

provided one runs windows and not pure dos, win32-make can always be 
used, which means that we *can* redesign runner and use win32 long 
command lines and not rely on gnu magic.

the only problem left will then be users running pure DOS. it can't be 
many people running *pure* dos. eliminating the dependancy on gcc IMHO 
far outweights not beeing able compile allegro *from* pure dos. djgpp is 
an exception in this case, but watcom is not.

note: one possibility of passing long commandlines from dos-make to (the 
new) runner that comes to mind, is putting the commandline in an 
environment variable and export it. then RUNNER could use that. i have 
not examined if there are size limitations on environment variables 
under older dos versions though. i don't like this idea at all since the 
makefiles that uses it will get ugly.

comments are very welcome...

--
One OS to rule them all,
one OS to find them,
one OS to bring them all
and in the darkness bind them.