On Thu, 12 Jul 2018, Thomas Mueller wrote:
Snippet from Eric Auer:
OS/2 was a very sensible evolution of the MS DOS
API spirit. So that could be part of the answer.
And there are probably free open OS/2 clones :-)
There is a free open OS/2 clone-attempt at osfree.org .
They even now have a
Snippet from Eric Auer:
> OS/2 was a very sensible evolution of the MS DOS
> API spirit. So that could be part of the answer.
> And there are probably free open OS/2 clones :-)
There is a free open OS/2 clone-attempt at osfree.org .
They even now have a github site:
On Thu, 12 Jul 2018, Eric Auer wrote:
OS/2 was a very sensible evolution of the MS DOS
API spirit. So that could be part of the answer.
And there are probably free open OS/2 clones :-)
If only, but maybe the recently-started "2ine" project would be useful to
such a thing.
-uso.
Hi Paul,
> Hi. About 30 years ago, someone made a comment
> on a group saying "until DOS is made 32-bit, DOS
> extenders are just a kludge".
Actually fd32 tries to be better than DOS + extender
by having a protected mode kernel, but it has been
a while since there was news from them and
> as you don't have plans to execute MSDOS binaries, please
I do have plans to one day run 16-bit MSDOS
applications under the 32-bit operating
system. But I have no idea how long that
will take to happen. Meanwhile running
32-bit apps is ready to roll. Also note that
I have a PDOS/86 which does
Hi Paul,
> PDOS uses a relocatable a.out format for the
> executables. I used a.out format because that
> is what EMX 0.9d uses internally. But PDOS
> will not even run a DOS-extended EMX
> executable. It is only capable of running
> a.out format, so everything needs to be
> recompiled for the
> Can PDOS run programs that are run with
> CWSDPMI (for example DJGPP)?
Hi Ercan.
PDOS uses a relocatable a.out format for the
executables. I used a.out format because that
is what EMX 0.9d uses internally. But PDOS
will not even run a DOS-extended EMX
executable. It is only capable of running
On July 8, 2018 1:42 PM, Ercan Ersoy wrote:
> Hello,
>
> Can PDOS run programs that are run with CWSDPMI (for exmaple DJGPP)?
>
> Can NightDOS run programs that are run with CWSDPMI (for exmaple DJGPP)?
>
> Best regards,
>
> Ercan
Hi Ercan,
The Night kernel will eventually have its own
Hello,
Can PDOS run programs that are run with CWSDPMI (for exmaple DJGPP)?
Can NightDOS run programs that are run with CWSDPMI (for exmaple DJGPP)?
Best regards,
Ercan
--
Check out the vibrant tech community on
On Fri, Jul 6, 2018 at 8:51 PM, Mercury Thirteen via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:
> Interesting you should mention this; I and a few others have been working
> on a 32-bit Protected Mode DOS-style kernel (see the Night group forum
> here
> Interesting you should mention this; I and a few others have been working on
> a
> 32-bit Protected Mode DOS-style kernel (see the Night group forum
> [here](https://groups.google.com/forum/?hl=en#!forum/night-dos-kernel) for
> more
> info) for a while now. While I never got too deep into
Interesting you should mention this; I and a few others have been working on a
32-bit Protected Mode DOS-style kernel (see the Night group forum
[here](https://groups.google.com/forum/?hl=en#!forum/night-dos-kernel) for more
info) for a while now. While I never got too deep into DPMI (and
Hi. About 30 years ago, someone made a comment
on a group saying "until DOS is made 32-bit, DOS
extenders are just a kludge".
I didn't know much about DOS-specifics back then
to even understand the comment.
Microsoft abandoned the MSDOS API, but what
would a 32-bit version of the MSDOS API look
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.
--
On Fri, 15 Sep 2006, Blair Campbell wrote:
I personally much prefer Debian, which is free in every form, easy to
install, and easy to use.
Yeah. Debian, or Ubuntu which is pretty much the same thing.
-uso.
-
Using
Hi,
I like Ubuntu, but if I want to develope or to play with a computer, I
am using DOS. Else, I have to use WinXP, because of the drivers and of
compatiblity of some programs... ^^
bye
Flo
On Sat, 16 Sep 2006 09:18:22 +0200, Lyrical Nanoha
[EMAIL PROTECTED] wrote:
On Fri, 15 Sep
Subject: Re: [Freedos-devel] 32 bit
You are talking of our sister project FreeDOS-32:
http://freedos-32.sourceforge.net/
No actually I was talking about starting another 16bit compiler project.
I believe that FreeDOS 32 has a big problem: they have to do it all from
scratch.
I believe
-Original Message-
From: Alain M. [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 07:45 PM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] 32 bit
Imre Leber escreveu:
Well I for one think that FreeDOS should move into the 32bit realm after
version 1
Imre Leber escreveu:
Well i strongly prefer reactos in that case, because i don't want to
pay more money to novell (the same company mentioned above) for using
linux then to microsoft for using windows.
You don have to pay Novell for using Linux!!! And I don't even think
that their's is
Hi!
15-Сен-2006 15:35 [EMAIL PROTECTED] (Alain M.) wrote to
freedos-devel@lists.sourceforge.net:
Well i strongly prefer reactos in that case, because i don't want to
pay more money to novell (the same company mentioned above) for using
linux then to microsoft for using windows.
AM You don
I personally much prefer Debian, which is free in every form, easy to
install, and easy to use.
On 9/15/06, Arkady V.Belousov [EMAIL PROTECTED] wrote:
Hi!
15-Сен-2006 15:35 [EMAIL PROTECTED] (Alain M.) wrote to
freedos-devel@lists.sourceforge.net:
Well i strongly prefer reactos in that
Well I for one think that FreeDOS should move into the 32bit realm after
version 1.
All the 32bit stuff was written by the DJGPP project. But it didn't make any
sense philosophicaly as long as it did not run on a free DOS operating system.
Now that we did the time and have a free operating
Imre Leber wrote:
Well I for one think that FreeDOS should move into the 32bit realm after
version 1.
All the 32bit stuff was written by the DJGPP project. But it didn't make any
sense philosophicaly as long as it did not run on a free DOS operating system.
Now that we did the time
-Original Message-
From: Roberto Mariottini [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 10:37 AM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] 32 bit
Imre Leber wrote:
Well I for one think that FreeDOS should move into the 32bit realm after
Imre Leber escreveu:
Well I for one think that FreeDOS should move into the 32bit realm after
version 1.
I agree, but for a different reason: not even here on the FreeDOS list
could we find any real 16 bit machine just for testing...
IMHO DOS has to remain DOS. That is definite. But modern
You are talking of our sister project FreeDOS-32:
http://freedos-32.sourceforge.net/
No actually I was talking about starting another 16bit compiler project.
I believe that FreeDOS 32 has a big problem: they have to do it all from
scratch.
I believe further that a different aproach could
Hi!
14-Сен-2006 14:45 [EMAIL PROTECTED] (Alain M.) wrote to
freedos-devel@lists.sourceforge.net:
AM Today thare is a discussion about making a full modern compiler for
AM either C++ or Pascal. It simply will not *fit* in 16 bit memory!!!
Because many current compilers are 32-bit programs,
The compiler itself can work in 32-bit protected mode but the generated
programs should work in 16-bit real.
- Original Message -
From: Arkady V.Belousov [EMAIL PROTECTED]
To: freedos-devel@lists.sourceforge.net
Sent: Thursday, September 14, 2006 9:04 PM
Subject: Re: [Freedos-devel] 32
Hi!
14-Сен-2006 21:46 [EMAIL PROTECTED] (Ladislav Lacina) wrote to
freedos-devel@lists.sourceforge.net:
LL The compiler itself can work in 32-bit protected mode but the generated
LL programs should work in 16-bit real.
AM Today thare is a discussion about making a full modern compiler for
AM
65 matches
Mail list logo
