Re: [Freedos-devel] FreeDOS 2.0
If there were only retail copies of FreeDOS. On Fri, May 29, 2015, 10:25 AM JAYDEN CHARBONNEAU jcharbonnea...@cpsge.org wrote: If only there was a holographic FreeDOS (Like for the Samsung SMart window,or Microsoft's hololense).If there was a holographic FreeDOS,I would throw a party.(Think how cool that would be!). On Thu, May 28, 2015 at 10:30 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: Correction... FreeDOS 1.2. Not 2.0. On Thu, May 28, 2015 at 4:40 PM, Antony Gordon cuzint...@gmail.com wrote: Hi, If I were building the FreeDOS distribution, the only thing that would be included as a part of the official FreeDOS install would be the components that make up the OS depending on the MS/PC DOS version distribution we wanted to emulate. I would also supply these files as one complete ZIP file instead of individual files as they make up the core of what you expect to have available when using DOS. I think that is all the FreeDOS installer should install. Everything else should be separate. All the other stuff would be fluff, like GEM, NDN, and the developer tools. If the final line in the sand is that without source it can’t be included, I think a list of where to find stuff would be useful to find the tools or applications needed. On May 28, 2015, at 3:52 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: Although it is freeware, source code for NDN appears to be unavailable. Given this project's push towards 100% open software, I am inclined to exclude it from the FreeDOS 2.0 image. Any thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I've also been curious as to what the format is for .TOS binaries (since GEMDOS has such a similar API to MS-DOS). Grab one and run it through a hex editor. The API has no bearing on the executable file format. In addition, Atari computers were using Motorola processors and not Intel processors with a segmented memory model. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net mailto:Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. On Jun 8, 2015, at 8:55 PM, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. I was specifically referring to the specific magic number that would show up as ZM in a text editor. All the files I've seen have the number in the opposite order such that the magic number appears as MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
And I said MJ for Michael Jordan not Michael Jackson. On 09/06/2015 10:51 am, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, It’s all semantics. Most signatures are MZ, but some old linkers (not sure if they are even in use) used ZM according to RBIL 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 -T On Jun 8, 2015, at 9:16 PM, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. I was specifically referring to the specific magic number that would show up as ZM in a text editor. All the files I've seen have the number in the opposite order such that the magic number appears as MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
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
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, It’s all semantics. Most signatures are MZ, but some old linkers (not sure if they are even in use) used ZM according to RBIL 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 Right, that's what I was referring to. I've never seen the latter. -uso.-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Tue, 9 Jun 2015, John Elliott wrote: If you can mark the EXEs as something other than MZ, you could perhaps make a TSR loader stub that loads an x86 emulator on demand to run EXE files. COM... I think you're gonna be stuck with using only an EXE format because trying to detect a COM file by architecture is fraught with peril. 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 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. Do ZM EXEs actually exist? I've also been curious as to what the format is for .TOS binaries (since GEMDOS has such a similar API to MS-DOS). -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
