DOS ain't dead

> Yes. NE binaries support both real-mode and protected-mode apps.

Probably because Windows 3.0 (1990) still (partially) supported 8086.

> > NE executables didn't exist except on MSDOS 4.0,
> > which may or may not buy something. Is that what
> > they are advertising?
>
> Yes. NE binaries support both real-mode and protected-mode apps. The 1 GB
> of virtual memory, I guess that's just the theorectical limit of 8192 LDT
> and 8191 GDT descriptors, each with limit -1, meaning 64 kB.

Ok, thanks.

So - there were compilers/linkers capable of building
NE executables in the late 1980s.

MSDOS 4.0 was not available for purchase as far as I know.

Windows 3.0 on an 8086 could execute NE executables I think,
but you couldn't do an INT 21H to write to stdout.

So - as a law abiding citizen, who wanted to follow
Intel's 8086 rules so that I would be in pole position
when the IBM PC AT came out - how exactly was I supposed
to write an MSDOS application in say Dec 1983 (when
MSDOS 2.0 was available, and the 80286 was available,
but before the IBM PC AT had actually shipped), so
that as soon as I got my hands on an IBM PC AT
(in 1984), I could whip up a protected mode 16-bit OS
and run my *existing* MSDOS binaries (that followed
the rules)?

Or if not Dec 1983 - WHEN could I do ANYTHING sensible?

What's the point of spending all that effort to follow
the rules if it buys me NOTHING?

Or rather - what needed to happen so that law-abiding
citizens got rewarded for all their effort?

Can you create a timeline or game plan that would
benefit those who spent the effort to follow rules?

Thanks. Paul.

> multiple of 16 bytes. Being able to use 32-bit offsets directly is much
> better.
>
> You can either stay away from protected mode or use a VM86 host for that.

Neither of those things existed on the 80286.

My question is restricted to the 80286, if that
wasn't clear.

I will digest the rest of your message though to
see if that is what Intel expected to happen.

BFN. Paul.

I think we are talking cross-purposes.

Wikipedia says:

> > In reality, almost all DOS application programs violated these rules

As opposed to:

Because no DOS-extenders existed, it doesn't make
any difference whether a DOS program
followed Intel's rules or not, because any code that
was written needed to be recompiled into the
DOS extender format or to some other OS format.
In fact, everyone here at Wikipedia thinks that
Intel must have been on the wacky weed when they
wrote their irrelevant (as opposed to difficult
to follow and rarely followed) rules.

> With a DOS Extender or by using any protected mode operating system of your
> choice.

Which, as above, makes the rules irrelevant.

BFN. Paul.

> > Writing to a code segment
>
> This also is configurable:
> https://en.wikipedia.org/wiki/Segment_descriptor
>
> As far as I remember, write-protected code segments became the default for
> Windows much later than Win9x, because app writers were used to overwriting
> code :-p

If you would reference the descriptor format you would notice that the "WR" bit means "writeable" for data descriptors but "readable" for code descriptors. You cannot execute from a data descriptor loaded as CS, only a code descriptor. So you cannot ever write with a cs: segment override prefix in Protected Mode, because CS must be loaded from a code descriptor and you cannot write to segments loaded from a code descriptor.

(Loading the selector in CS to another segment register will still load the code descriptor so even that doesn't suffice to write. You need a writeable data descriptor instead. This, of course, can have the same base as the code descriptor, aliasing the same memory.)

More generally on the topic of this thread, following the rules makes it easier to port a program to also run in Protected Mode. A good example is the original Debug/X as well as lDebug/X and its Extensions for lDebug. Most of their code is bimodal, it can run either in Real/Virtual 86 Mode or in a 16-bit CS in Protected Mode.

Following the rules in this case means not writing with the CS override / not using the selector in CS to try to write to the application's code segment. (Instead of pushing/moving CS to get the code segment into a data segreg, the original Debug/X was adjusted to push/mov SS instead. In lDebug/X this is needed in 86 Mode as well because even then SS != CS as we now use a stack/data/entry segment at another base address than the code segment(s).)

Also, using special purpose functions like setes2dx to address 86 Mode segments, which assembles to just mov es, dx in non-DPMI lDebug, but will set a scratch selector to address this 86 Mode segment while lDebugX is in PM. All segment arithmetic must be done using such filters and not depending on segregs holding Real Address Mode segment addresses. Some interrupt and function calls must go through Protected Mode int 31h functions to call down to the 86 Mode handlers. There are functions like selector_to_segment which must operate on a variable in memory or in a non-segreg register because segregs in PM can only hold valid selectors or 0000h. (This function will retrieve the segment base from the descriptor and return the 86 Mode segment that corresponds to this base. For this to be valid the selector must be referring to a 86 Mode segment base address, ie have a base of linear 0 to linear 0FFFF0h on a paragraph boundary.)

The AMIS common functions are easy to work with calling down from PM because they pass all segment values in non-segreg registers, so they need less special setup in the PM caller. For instance, the AMIS detection callout passes the segment in DX so the relatively simple call_int2D function can be used. In some of the AMIS private functions of lDebug I also followed this example. The notable exception is function 30h which consequently requires more setup to call from PM, involving the selector_to_segment function.

---
l

> > This was not without its limitations. If an application utilized or
> relied
> > on any of the techniques below, it would not run:
> >
> > ...
> > Use of BIOS functions, due to the BIOS interrupts being reserved by
> > Intel[31]
>
> I would classify "Would not run" as a vast overstatement. Specifically
> regarding the BIOS functions, that is not actually a DOS problem -- it is a
> BIOS problem. And even then, the only BIOS interrupt problem I've come
> across that has any practical effect is INT 05, which used by both the BIOS
> PrintScreen function and by the CPU BOUND instruction (which didn't even
> exist until the 80286).

You can do BIOS calls from PM16?

ie read a disk?

edit: and into memory above 1 MiB?