Before you get too involved with a 32 bit DOS-like operating system can you
update us on your progress with FreeDOS 1.2? I thought you were working on
that too.
On Jun 17, 2015 11:07 AM, Mercury Thirteen mercury0x0...@gmail.com
wrote:
I think there's been sufficient time for everyone who is
Indeed, the package compilation has been available for two weeks now. You
can find it here http://mercurycoding.com/FreeDOS/FreeDOS-1.2.zip.
I posted it to get everyone's feedback, so take a look and see if you find
anything which should be removed or added. I'm fairly certain I didn't yet
catch
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.
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.
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
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
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
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 -
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
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
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.
--
Hi,
On Fri, Jun 5, 2015 at 5:10 PM, Steve Nickolas usots...@buric.co wrote:
A port of DOS to ARM would not be bound to any existing API and would not
need to be compatible with any existing DOS implementations, while still
being a port of DOS.
I know this might be stating the obvious, but
Hi,
On Jun 5, 2015, at 6:10 PM, Steve Nickolas usots...@buric.co wrote:
A port of DOS to ARM would not be bound to any existing API and would not
need to be compatible with any existing DOS implementations, while still
being a port of DOS.
That’s technically incorrect. The reason that
A port of DOS to ARM would not be bound to any existing API and would not
need to be compatible with any existing DOS implementations, while still
being a port of DOS.
-uso.
--
I agree, a 32-bit kernel would open up worlds of possibilities for the DOS
platform.
Also, just to clarify, I wasn't asking anyone's permission, just probing to
see what kind of interest there is out there.
I used to follow DOSCore and Aura closely back in the day when I was
working (off and on,
I am considering starting a test project to determine the feasibility of
implementing a 32-bit FreeDOS kernel. If I decide to do so, who else is
interested in contributing?
Said contributors could assist in coding, help with testing, establish and
evolve standards for the project, create
To see it on the arm architecture I think would be a good long term goal
for a 32 bit kernel.
Raspberry pi and other small arm boards are cheap and affordable and would
breathe life into the dos platform.
You don't need the freedos community approval or help as such for a
project. Just do it.
Low end *nix apps could be ported in place of over dos apps hell we could
just make a Linux distro and slap a freedos sticker on it lol.
Problem is there are two arguments here.. why and why not.
If you build it they will come. If you don't then be happy carrying your
xt's on your back.
On
Doesn't matter, Mac os power pc applications dont work on new Mac os but
it's still the same os.
(rosetta comparability layer aside)
I see this as more of a chance for a new generation of dos. Freedos 1.x has
accomplished the needs for the existing replacement or clone requirements
of a dos with
On Sat, 6 Jun 2015, Chelson Aitcheson wrote:
Doesn't matter, Mac os power pc applications dont work on new Mac os but
it's still the same os.
(rosetta comparability layer aside)
I see this as more of a chance for a new generation of dos. Freedos 1.x has
accomplished the needs for the
Nothing is impossible if it was the case we would all still be using reel
to reel and tape decks lol.
Lots of ideas and spit balling here but hey why not write it up and if
people wana contribute then they will if not keep using old trusty xt
On 06/06/2015 8:39 am, Steve Nickolas
Hey,
On Jun 5, 2015, at 6:49 PM, Chelson Aitcheson chelson.aitche...@gmail.com
wrote:
Nothing is impossible if it was the case we would all still be using reel to
reel and tape decks lol.
Lots of ideas and spit balling here but hey why not write it up and if people
wana contribute
Eric,
It’s involved, but so was writing an MS-DOS clone almost 17 years ago that is
able to run 98% of all DOS software natively factoring in the quirks and
undocumented and partially documented structures that had to be clean room
implemented to avoid infringement.
You and I were around for
Haha I got laughed at and criticized for these ideas.
Just make it don't worry about the community.
On 29/05/2015 6:47 am, Antony Gordon cuzint...@gmail.com wrote:
I was re-reading some emails and I think I have an idea of how this would
work.
The goal is existing compatibility so that older
On Mon, Jun 1, 2015 at 3:16 PM, Chelson Aitcheson
chelson.aitche...@gmail.com wrote:
Haha I got laughed at and criticized for these ideas.
+1
Just make it don't worry about the community.
+10
--
Hi Antony,
if the goal is only to use Windows driver, then writing
a clone of Windows is a high price. Plus it already has
been paid, by the ReactOS project. Note that DOS windows
in Windows often do not gain from Windows drivers: For
example if your soundcard comes with a Windows driver,
your
Eric,
It’s simple. Every piece of computer hardware comes with a Windows driver.
Depending on the age of the device, you may have the older Windows drivers, or
the newer Windows Driver Model driver. The reality is that to the major
manufacturers of hardware, DOS is dead. No one is using a
...@gmail.com
To: Technical discussion and questions for FreeDOS developers.
freedos-devel@lists.sourceforge.net
Sent: Thursday, May 28, 2015 10:47 PM
Subject: [Freedos-devel] 32-bit FreeDOS
I was re-reading some emails and I think I have an idea of how this would
work.
The goal is existing
Eric,
I only mentioned the Windows portion because it would tie in compatibility
on the Microsoft side of things for classic software, not necessarily to
re-invent Windows 3.x or Windows 9x.
I'll try to elaborate more.
If you strip the GUI from MS Windows, you have 3 important parts that run
to
Hi Anthony,
please explain in which way Windows WITHOUT a GUI would be
something that we want to add to FreeDOS: There already are
really good, free and open DPMI based DOS extenders for DOS.
FreeDOS itself is not running in protected mode, but every
EMM386 style software must use protected
, May 28, 2015 10:47 PM
Subject: [Freedos-devel] 32-bit FreeDOS
I was re-reading some emails and I think I have an idea of how this would
work.
The goal is existing compatibility so that older DOS applications will run.
Obviously, moving to 32-bit will eliminate most of the older processors
I was re-reading some emails and I think I have an idea of how this would work.
The goal is existing compatibility so that older DOS applications will run.
Obviously, moving to 32-bit will eliminate most of the older processors,
HOWEVER. by implementing a Windows 9x like model and build a
Here’s one possibility:
1. Start FreeDOS (16-bit mode)
2. Start FreeDOS-32 via a separate executable (it would only be installed if it
detected a 32-bit capable processor), perhaps call it FD32. It would switch to
protected mode and spawn a protected mode shell.
The other possibility
During
On Thu, 28 May 2015, Antony Gordon wrote:
Here’s one possibility:
1. Start FreeDOS (16-bit mode)
2. Start FreeDOS-32 via a separate executable (it would only be installed if it
detected a 32-bit capable processor), perhaps call it FD32. It would switch to
protected mode and spawn a protected
Agreed, that was my exact line of thinking.
However, the folks here seem to have come to the conclusion that FreeDOS
will not evolve into the 32-bit realm.
On Thu, May 28, 2015 at 4:47 PM, Antony Gordon cuzint...@gmail.com wrote:
I was re-reading some emails and I think I have an idea of how
Hi :-)
1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate
executable (it would only be installed if it detected a 32-bit
capable processor), perhaps call it FD32. It would switch to
protected mode and spawn a protected mode shell.
http://freedos-32.sourceforge.net/ already
On Friday, May 29, 2015, Eric Auer wrote:
FD32 runs more parts in 32-bit, but the advantages compared to using a
classic DOS together with a DPMI compatible DOS extender are minimal.
Exactly.
--
37 matches
Mail list logo