[syslinux] Reports from 5.00

[H. Peter Anvin]

On 01/16/2013 04:30 AM, Matt Fleming wrote:
>
>> E_ Under FreeDOS, SYSLINUX.COM doesn't seem to install ldlinux.*
>> (specially when used with "--directory"), and there are no ([error])
>> messages; not even when executed with no parameters, or with
>> "--help", or with "--version". The messages disappeared _after_
>> 5.00-pre7.
>
> Right, as Peter pointed out on IRC, it seems unreasonable to expect
> 5.00's 496K syslinux.com to be loaded under real-mode DOS (-pre7 is when
> we started installing ldlinux.c32 automatically instead of requiring the
> user to manually copy it).
>
> At this point I'm leaning towards marking real-mode DOS as Not Supported
> from Syslinux-5.00 onwards since 5.x's execution revolves around
> ldlinux.c32, which at 428K, is unlikely to ever execute in 1MB of RAM.
> Even if we compress ldlinux.c32, it has to be uncompresed in RAM at some
> point so that we can execute it, unless we only uncompressed chunks of
> ldlinux.c32 as and when it was needed. But partial decompression would
> be a major project.
>

There is actually two other ways to do it which would be easier, 
however, it would really help if someone who cares about DOS could do 
the work.

Alternative #1:

DOS allows the filename of the running executable to be discovered by 
looking at the environment pointer in the PSP; the environment block is 
a series of null-terminated strings followed by a null string (similar 
to Unix systems); *after* the null string is the full pathname of the 
executable itself as a full pathname; this is what MS-DOS C compilers 
provide as argv[0].

One can then open the file and seek to an offset from the end of the 
file, alternatively (probably more robust) read the header and look at 
the _exe_edata_low and _exe_edata_blocks fields to find the end of the 
EXE data proper and then seek to that offset.

At that point, the data beyond the end of the file is simply handled 
like a normal file under DOS, which one can read with the normal read 
system call and write out to the target file.  It also means this data 
is *not* compressed by UPX; until we compress modules this will create a 
large installer.

Alternative #2:

Use DJGPP as the compiler and compile the DOS installer as an "extended 
DOS" (32-bit executable.)

The downside there is additional tools dependencies and the need for a 
DPMI provider (such as cwsdpmi.exe) in order to run.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.