DOS ain't dead

Another two articles by Julio Merino:

From 0 to 1 MB in DOS
A tour on how DOS was able to use most of the 1 MB address space of the 8086

Beyond the 1 MB barrier in DOS
Continuing the tour on how DOS apps used memory above the first MB

---
Forum admin

> Another two articles by Julio Merino:
>
> From 0 to 1
> MB in DOS
> A tour on how DOS was able to use most of the 1 MB address space of the
> 8086
>
> Beyond
> the 1 MB barrier in DOS
> Continuing the tour on how DOS apps used memory above the first MB

Thanks for that - it was interesting - especially seeing
what expanded (not extended) memory was, and an actual card.

One thing that wasn't covered though - they said there were
gaps in the memory above 640k that could be used. But no
mention of banking out even used memory, which I believe
was possible.

Although you would need a replacement for MSDOS to do
that I guess (still 8086 though).

So if you have a CGA at 0xb8000 - before you do the
BIOS call that writes to the screen, bank the CGA
back in.

That also required cooperation from the applications
though - to not manipulate the hardware directly.

So not very useful for existing programs, but something
I could potentially add to PDOS/86 to support applications
that "follow the rules".

I've only done very brief investigation - just to ask
the question of whether banking was possible, and got
an answer of "not impossible".

It would be good to have a cooperative BIOS that
minimized its footprint too, so that it could be
banked out itself.

Although to some extent it's all fairly pointless.
If you have a properly-written program it can run
on an 80286 using the Family API anyway. Or
something similar. Or what I was planning on doing -
OS/2 1.x for the 8086 to run the Family Mode
applications without the actual Family Mode code in
the executable.

BFN. Paul.

> So if you have a CGA at 0xb8000 - before you do the
> BIOS call that writes to the screen, bank the CGA
> back in.
>
> That also required cooperation from the applications
> though - to not manipulate the hardware directly.

And no higher prio interrupts (timeslicers) that could potentially interfere. So that means applications can't hook (certain?) hw interrupts either.

But since the whole dos compatibility essentially hung on the direct hardware access, without it would have been a different OS.

> > So if you have a CGA at 0xb8000 - before you do the
> > BIOS call that writes to the screen, bank the CGA
> > back in.
> >
> > That also required cooperation from the applications
> > though - to not manipulate the hardware directly.
>
> And no higher prio interrupts (timeslicers) that could potentially
> interfere. So that means applications can't hook (certain?) hw interrupts
> either.
>
> But since the whole dos compatibility essentially hung on the direct
> hardware access, without it would have been a different OS.

More - different applications - ones that conform to the rules.

The rules are actually here:

https://en.wikipedia.org/wiki/Protected_mode

If an application utilized or relied on any of the techniques below, it would not run:

Segment arithmetic
Privileged instructions
Direct hardware access
Writing to a code segment
Executing data
Overlapping segments
Use of BIOS functions, due to the BIOS interrupts being reserved by Intel

In reality, almost all DOS application programs violated these rules


But that to me is the fun thing - to start obeying the rules.

And for what I want to do (run microemacs) - I don't see a barrier to obeying the rules.

Although I wish to change the OS (to a combination of PDOS-generic and OS/2 1.x) for other reasons (mainly that "segment arithmetic" thing - I need something to provide AHINCR and AHSHIFT).

BFN. Paul.