ultimate DOS emulator

[[e-mail]]

Also, is it possible to do that, or something close to
that, using 16-bit protected mode, with long mode
activated? So that I can use hardware instead of
software emulation.

Thanks. Paul.

[[e-mail]]

Actually, I'd like to support the 8086+ too.

I've been thinking more about that, and what I need
is a new MSDOS API that takes a 32-bit amount to
be allocated, and returns a far pointer. As applications
may be running on an 8086+ rather than an 8086 and
not even know it, as they don't need to know it.

But I want applications to detect the version of
MSDOS (or some other method - what?) being run,
so that they know if the new API is available. If it
isn't, then they use the old API which is restricted
to 1 MB allocations, and will only get the segment
returned, so must be on a segment boundary.

And "MZ" executables should be built "compact" as
if they are going to be run on an 8086. But if they
exceed 1 MB in size then they should use some
extension (similar to "PE") to say what the segment
shift value is that the linker used for this executable.

I am hoping Watcom C can be made to generate a
3 MB GCC 8086+ MSDOS+ executable. Using huge
pointers if necessary.

BFN. Paul.

[[e-mail]]

My tentative plan is that each MSDOS executable
gets a fresh 1 MB + 64k address space.

I was thinking that it also get another 1 MiB for
memory allocations, so that if the app trashes
the memory chains, it won't affect the OS that
scans them.

Basically suballocation would be done from the
extra 1 MiB, and then the address returned would
be something that resides in the proper 1 MiB.

I was also wondering if this would allow the gaps
between memory blocks to be reduced to 0. But
I can't think of any good way to do that.

Also, since the application will have its own address
space anyway, it doesn't really matter much if it
trashes its own memory chain.

BFN. Paul.