By: rwessel (robertwessel.delete@this.yahoo.com), August 16, 2014 8:36 pm
Room: Moderated Discussions
Ricardo B (ricardo.b.delete@this.xxxxx.xx) on August 16, 2014 7:17 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on August 16, 2014 6:35 pm wrote:
> > Ricardo B (ricardo.b.delete@this.xxxxx.xx) on August 16, 2014 5:43 pm wrote:
> >
> > > There's no support for 286 mode. 286 protected mode, fortunately, did not carry on to the 80386.
> > >
> >
> > So are you saying that I could not just run OS/2 on a modern Intel CPU? When did
> > that become true? Your answer suggests that it was true even with the 386, but that
> > surely can't be right. Didn't IBM have OS/2 running on the 386 based PS/2's?
>
> OS/2 ran on a 386, but not by treating it as a 286. It had different code paths for the 2 cases.
>
> DOS/Windows, of course, had 3: 8086, 80286 and 80386.
No it/they didn't. 386 p-mode is a pretty strict superset of 286 p-mode. Other than the wider registers and some additional registers, all of the same segment types are supported, but if you wan't to do a 32 bit system there are some new segment types (TSS, gates) that extend the function of the 16-bit versions (but the 16 bit versions still exist, although you'd usually not use both at the same time in a system).
Real (8086) mode is, of course different.
In any event, OS/2 1.x ran on both 286s and 386s. Later versions of 1.x did (slightly) support the 386 by improving the real-mode support and properly saving the extended registers. Windows is similar. If we look a Win3.0, you could run Windows in three modes: real, standard and 386Enh. The real mode support largely is a minor enhancement of the pseudo-virtual memory segmentation done in Win1.x and 2.x (which is where all the oddities with segment addressing an locking come from). The major enhancement in 3.0 was that there was a new 286 p-mode version, which was pretty (source) compatible real-m ode operation. Ignoring the real mode support in 3.0, Win 3.x could be started in either standard or 386Enh mode with a command line switch. The major difference being which DOS extender was loaded - the major portion of Windows itself was identical in the two modes (although you could use additional APIs in the 386 mode).
Obviously later versions of Windows (95 and later, anything in the NT branch, as well as 3.x in 386Enh mode), and OS/2 2.x required a 386.
Even now, on 64-bit x86s, there's full support for application level 16 bit segments in compatibility mode (and you'd just use the 32 bit system segment types, so the missing 16 bit system segments don't matter).
> Maynard Handley (name99.delete@this.name99.org) on August 16, 2014 6:35 pm wrote:
> > Ricardo B (ricardo.b.delete@this.xxxxx.xx) on August 16, 2014 5:43 pm wrote:
> >
> > > There's no support for 286 mode. 286 protected mode, fortunately, did not carry on to the 80386.
> > >
> >
> > So are you saying that I could not just run OS/2 on a modern Intel CPU? When did
> > that become true? Your answer suggests that it was true even with the 386, but that
> > surely can't be right. Didn't IBM have OS/2 running on the 386 based PS/2's?
>
> OS/2 ran on a 386, but not by treating it as a 286. It had different code paths for the 2 cases.
>
> DOS/Windows, of course, had 3: 8086, 80286 and 80386.
No it/they didn't. 386 p-mode is a pretty strict superset of 286 p-mode. Other than the wider registers and some additional registers, all of the same segment types are supported, but if you wan't to do a 32 bit system there are some new segment types (TSS, gates) that extend the function of the 16-bit versions (but the 16 bit versions still exist, although you'd usually not use both at the same time in a system).
Real (8086) mode is, of course different.
In any event, OS/2 1.x ran on both 286s and 386s. Later versions of 1.x did (slightly) support the 386 by improving the real-mode support and properly saving the extended registers. Windows is similar. If we look a Win3.0, you could run Windows in three modes: real, standard and 386Enh. The real mode support largely is a minor enhancement of the pseudo-virtual memory segmentation done in Win1.x and 2.x (which is where all the oddities with segment addressing an locking come from). The major enhancement in 3.0 was that there was a new 286 p-mode version, which was pretty (source) compatible real-m ode operation. Ignoring the real mode support in 3.0, Win 3.x could be started in either standard or 386Enh mode with a command line switch. The major difference being which DOS extender was loaded - the major portion of Windows itself was identical in the two modes (although you could use additional APIs in the 386 mode).
Obviously later versions of Windows (95 and later, anything in the NT branch, as well as 3.x in 386Enh mode), and OS/2 2.x required a 386.
Even now, on 64-bit x86s, there's full support for application level 16 bit segments in compatibility mode (and you'd just use the 32 bit system segment types, so the missing 16 bit system segments don't matter).
