Hi
<snip>
>
> I'd suggest using 0xC3 0x00 as a magic number for any non-8086 executable.
> Or, for preference, using a 4-byte magic number: 0xC3 0x00 0x00 followed by
> a byte giving the supported CPU architecture. Then the logic in the loader
> would be:
>
> 0xC3 0x00 0x00 <suitable architecture> -> run as native EXE
> 0xC3 0x00 0x00 <unsuitable architecture> -> return an error
> 0x4D 0x5A (or 0x5A 0x4D) -> run in emulator as x86 EXE
> anything else -> run in emulator as x86 COM
>
The only problem I see is that to make an executable file that DOS recognizes
according to the API, it has to follow this structure (in C for clarity)
struct EXE {
unsigned short signature; /* == 0x5a4D */
unsigned short bytes_in_last_block;
unsigned short blocks_in_file;
unsigned short num_relocs;
unsigned short header_paragraphs;
unsigned short min_extra_paragraphs;
unsigned short max_extra_paragraphs;
unsigned short ss;
unsigned short sp;
unsigned short checksum;
unsigned short ip;
unsigned short cs;
unsigned short reloc_table_offset;
unsigned short overlay_number;
};
struct EXE_RELOC {
unsigned short offset;
unsigned short segment;
};
To maintain compatibility with MS-DOS and FreeDOS, we are constrained by the
loader. The signature has to be first. Here are some additional signatures
that can appear in a DOS .EXE file
Values for the executable types understood by various environments:
MZ old-style DOS executable (see #01594
<http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html>)
ZM used by some very early DOS linkers, and still supported as an
alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS
NE Windows or OS/2 1.x segmented ("new") executable (see #01596
<http://www.delorie.com/djgpp/doc/rbinter/it/96/15.html>)
LE Windows virtual device driver (VxD) linear executable (see #01609
<http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html>)
LX variant of LE used in OS/2 2.x (see #01609
<http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html>)
W3 Windows WIN386.EXE file; a collection of LE files
W4 Windows95 VMM32.VXD file
PE Win32 (Windows NT and Win32s) portable executable based on Unix COFF
DL HP 100LX/200LX system manager compliant executable (.EXM)
MP old PharLap .EXP (see #01619
<http://www.delorie.com/djgpp/doc/rbinter/it/19/16.html>)
P2 PharLap 286 .EXP (see #01620
<http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html>)
P3 PharLap 386 .EXP (see #01620
<http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html>)
Retrieved from http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html
<http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html>
Obviously we can add to the loader code in FreeDOS so it can recognize a
FreeDOS non x86 architecture EXE file, or we can extend after offset 0x1C with
architectural information as the EXE header is 512 bytes IIRC. This extension
can be back ported to the 16-bit version, so at the very least it can say “This
program requires FreeDOS 32” or something to that effect similar in function to
the Windows PE executables.
> The reason for using 0xC3 0x00 as the magic number is that no useful
> DOS COM file will start with those bytes (0xC3 is x86 for RET). The extended
> sequence 0xC3 0x00 0x00 also rules out CP/M-80 COM files, which might start
> with 0xC3 but won't follow that with two zeroes.
>
> --
> John Elliott
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freedos-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
