Just found out about your new release
on bttr forum. From the short discussion
there, I've found out that pdos/386 can
run gcc (djgpp? or what kind of gcc?) and
can't run any classic DOS program without
recompiling them.
Let me introduce the fdpp project to you: https://github.com/dosemu2/fdpp
In short, fdpp is "the thing" that adds a
full DOS compatibility to any 32 or 64bit
kernel, in an exchange of the v86 services.
I.e. the host kernel needs to provide the
call-backs to fdpp to call real-mode code
in v86, and fdpp does the rest, turning
any modern kernel into a plain DOS. :)
Currently I use it on linux. We look for
new kernels, maybe pdos/386 can be
the one?
The project is very mature, most DOS
titles are running w/o any problems.
Is there any interest in running fdpp on
pdos/386?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just found out about your new release
on bttr forum. From the short discussion
there, I've found out that pdos/386 can
run gcc (djgpp? or what kind of gcc?) and
It requires a custom-built version of GCC
and binutils designed to produce a.out
format executables.
In short, fdpp is "the thing" that adds a
full DOS compatibility to any 32 or 64bit
kernel, in an exchange of the v86 services.
I.e. the host kernel needs to provide the
call-backs to fdpp to call real-mode code
in v86, and fdpp does the rest, turning
any modern kernel into a plain DOS. :)
I looked at your website, but I still don’t
understand the above. Note that PDOS/386
does not use v86. It does however support
INT 21H with a number of DOS functions,
but provides a 32-bit interface to them.
If FDPP can assist in getting 16-bit DOS
programs to run under PDOS/386, that
would be of interest.
Just found out about your new release
on bttr forum. From the short discussion
there, I've found out that pdos/386 can
run gcc (djgpp? or what kind of gcc?) and
It requires a custom-built version of GCC
and binutils designed to produce a.out
format executables.
OK, I understand.
That sounds good.
However fdpp requires clang+nasm+objdump.
Any possibility of a clang port?
In short, fdpp is "the thing" that adds a
full DOS compatibility to any 32 or 64bit
kernel, in an exchange of the v86 services.
I.e. the host kernel needs to provide the
call-backs to fdpp to call real-mode code
in v86, and fdpp does the rest, turning
any modern kernel into a plain DOS. :)
I looked at your website, but I still don’t
understand the above. Note that PDOS/386
does not use v86.
But I thought you do use v86 internally
for a bios calls? So at least you have a way to call to v86? If so - this is all that
is needed.
It does however support
INT 21H with a number of DOS functions,
but provides a 32-bit interface to them.
If FDPP can assist in getting 16-bit DOS
programs to run under PDOS/386, that
would be of interest.
That's the whole point of it, and let me
say, it does so exceptionally well. We use
automated CI testing to avoid regressions,
and many other things unheard in a DOS
world, and that helped to reach the very
high compatibility level. Much better than
the one of FreeDOS or most other known
DOS clones.
Last edit: Stas Sergeev 2020-05-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However fdpp requires clang+nasm+objdump.
Any possibility of a clang port?
Yes, I can look into that.
But I thought you do use v86 internally
for a bios calls? So at least you have a
way to call to v86? If so - this is all that
is needed.
I don’t use v86, I use actual real mode. ie
I drop from protected mode to real mode
in order to execute the BIOS calls.
BFN. Paul.
However fdpp requires clang+nasm+objdump.
Any possibility of a clang port?
Yes, I can look into that.
Thanks!
I am still hoping one day the gcc port will
be possible, but for now gcc devs are not
interested in fdpp.
But I thought you do use v86 internally
for a bios calls? So at least you have a
way to call to v86? If so - this is all that
is needed.
I don’t use v86, I use actual real mode. ie
I drop from protected mode to real mode
in order to execute the BIOS calls.
Hmm, any hopes this will change one day?
With real mode there are a few problems,
we explored that in the past and failed.
The main problem is that you can no longer
trap and fake the instructions like cli, pushf,
popf. Some DOS programs take that as an
indication that they can freely write to cr0
to switch to PM. Some will simply hang your
system by disabling interrupts forever. So
at best, with real-mode you can only count
on a "well-behaved" subset of DOS programs,
and sacrifice the stability of the entire system
by the mere fact that you allow the DOS progs
to run.
Another problem is that fdpp requres the
trampoline from host kernel to switch back
to PM, as all the work is done in PM. With
v86 such trampoline is just a hlt instruction:
it immediately switches the CPU to PM and
raises an exception. I am sure with RM such
trampoline is a bit more work.
So overall, I believe you can still get some
(very limited) use of fdpp even w/o v86 support.
Of course on linux there is no limit of
opportunities, like getting v86 under VTx,
or just using the CPU emulator. But I believe
these options are too difficult for pdos/386,
while v86 is very light-weight, and is sufficient.
If you also enable cr4.VME, then you even
get an internal v86 monitor for free, so there
is not too much work remains.
Last edit: Stas Sergeev 2020-05-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi pdos developers.
Just found out about your new release
on bttr forum. From the short discussion
there, I've found out that pdos/386 can
run gcc (djgpp? or what kind of gcc?) and
can't run any classic DOS program without
recompiling them.
Let me introduce the fdpp project to you:
https://github.com/dosemu2/fdpp
In short, fdpp is "the thing" that adds a
full DOS compatibility to any 32 or 64bit
kernel, in an exchange of the v86 services.
I.e. the host kernel needs to provide the
call-backs to fdpp to call real-mode code
in v86, and fdpp does the rest, turning
any modern kernel into a plain DOS. :)
Currently I use it on linux. We look for
new kernels, maybe pdos/386 can be
the one?
The project is very mature, most DOS
titles are running w/o any problems.
Is there any interest in running fdpp on
pdos/386?
Hi Stas. Thanks for your email.
I looked at your website, but I still don’t
understand the above. Note that PDOS/386
does not use v86. It does however support
INT 21H with a number of DOS functions,
but provides a 32-bit interface to them.
If FDPP can assist in getting 16-bit DOS
programs to run under PDOS/386, that
would be of interest.
BFN. Paul.
Hi!
16.05.2020 04:28, Paul Edwards пишет:
OK, I understand.
That sounds good.
However fdpp requires clang+nasm+objdump.
Any possibility of a clang port?
But I thought you do use v86 internally
for a bios calls? So at least you have a
way to call to v86? If so - this is all that
is needed.
That's the whole point of it, and let me
say, it does so exceptionally well. We use
automated CI testing to avoid regressions,
and many other things unheard in a DOS
world, and that helped to reach the very
high compatibility level. Much better than
the one of FreeDOS or most other known
DOS clones.
Last edit: Stas Sergeev 2020-05-16
16.05.2020 12:40, Paul Edwards пишет:
Thanks!
I am still hoping one day the gcc port will
be possible, but for now gcc devs are not
interested in fdpp.
Hmm, any hopes this will change one day?
With real mode there are a few problems,
we explored that in the past and failed.
The main problem is that you can no longer
trap and fake the instructions like cli, pushf,
popf. Some DOS programs take that as an
indication that they can freely write to cr0
to switch to PM. Some will simply hang your
system by disabling interrupts forever. So
at best, with real-mode you can only count
on a "well-behaved" subset of DOS programs,
and sacrifice the stability of the entire system
by the mere fact that you allow the DOS progs
to run.
Another problem is that fdpp requres the
trampoline from host kernel to switch back
to PM, as all the work is done in PM. With
v86 such trampoline is just a hlt instruction:
it immediately switches the CPU to PM and
raises an exception. I am sure with RM such
trampoline is a bit more work.
So overall, I believe you can still get some
(very limited) use of fdpp even w/o v86 support.
Of course on linux there is no limit of
opportunities, like getting v86 under VTx,
or just using the CPU emulator. But I believe
these options are too difficult for pdos/386,
while v86 is very light-weight, and is sufficient.
If you also enable cr4.VME, then you even
get an internal v86 monitor for free, so there
is not too much work remains.
Last edit: Stas Sergeev 2020-05-16
Hi,
I updated the readme:
https://github.com/dosemu2/fdpp/blob/master/README.md
to state more explicitly that it runs DOS
programs, and also added the description
of pdos/386. Hope I described it properly.