It's mostly correct though we could always argue about what is "slow". For example the V86 mode on 386 does indeed incur some performance penalty but it's not huge, just a few % vs the real mode. I/O operations take pretty big performance hit but then again just how much of those do you have in a typical code? The EMS is emulated with paging so that's almost as fast as a hardware solution.

Also, compiler support or not, EMS is always a bit tricky to use since all operations have to be done through the mapping window. But at least the mapping is fast, just a write or two to a HW register to select which part of upper RAM is to be visible there. XMS requires the data to be copied, even if LOADALL is used. It's even worse if you use int15 BIOS functions that are almost always based on entering and exiting (through a reset on 286) protected mode.

On a 286, if the EMS window is 64kB long, then at least pointers mostly work as expected (assuming you remember to map the necessary part of memory). On 386 the flat mode is way, way more useful, not to mention faster.
Also, 286 in protected mode is not really any slower than real mode, the "frequent segment changes" are true either way due to 64kB limit of each segment. Sure, loading the segment register in protected mode is slower a bit but again, what code does it so often it actually matters? It's faster than XMS in real mode, unless your program needs to call DOS functions often so you get performance penalty from all those mode switches.

The way I see it, protected mode on 286 is fastest way to access all RAM but due various BIOS bugs, lack of extended addressing modes that 386 has, 64kB segment limit and costly DOS calls there just aren't many programs or even compilers+DOS extenders. The XMS is kinda slow so EMS is preffered, in real mode, even if takes extra libraries to use it.
On 386 protected mode is the king, be it a multi-tasking OS or just flat 4GB memory map via DOS extender. Any penalty calling DOS is well worth it. EMS is next to useless and XMS driver is only loaded to provide HMA - most DOS extenders can allocate all the memory using only BIOS. So it's completly opposite.

Interrupt handling is slow in protected mode both on 286 and 386, and V86 is a variant of protected mode.
Therefore, EMM386 doesn't always slow things down, but it does when there's a lot of interrupts.
Try eg. playing samples via PC Speaker - which requires frequent timer interrupts - on a 386 with EMM386.

why is ems useless on 386? i dont speak of emu - for example a memory card..

mrau wrote:

why is ems useless on 386? i dont speak of emu - for example a memory card..

EMS can be very useful on a 386, as in the 386 era there was still plenty of software using EMS.
But it can be efficiently provided in software, via eg. EMM386 - so, instead of spending money on an EMS card, it's better to add more extended memory.

Hardware EMS would be even worse than emulated. At least with EMM386 you get UMBs for DOS, and AFAIR you can swap in/out any part of the memory (so long it's at last one 4kB page and aligned to one) without having to sacrifice the upper memory for a fixed window. That's a very late version of the EMS standard, likely meant exactly for paging and emuation only.

A memory card gets you nothing except maybe a bit more memory than you can fit into RAM slots on the mobo while taking precious upper memory blocks for the transfer window. It's going to be slow due to ISA bus, way slower than what EMM386 can do. Oh and did I mention a memory card is uncacheable? Even if it was VLB based solution, and why would anyone even want a finnicky memory expansion card that might work or not, or worse yet randomly and silently glitch data because VLB was known to have it's issues.

Maybe, just maybe, if you had an early 386 system, possibly 386SX (but then these are not early!), and you wanted to expand the memory past the mobo/CPU bus limitation, then an EMS card would make some sense. Especially if it was a slow CPU (~16MHz) so the ISA would not bog it down that much. And yet, it would make even more sense to just get a better 386DX with cache and more memory slots, and/or higher density RAM SIMMs to overcome that.

EMS idea died the moment the CPU could address past 1MB without resorting to slow, dirty tricks. And that happened with 386. Even real mode DOS programs quickly moved to protected mode and DOS extenders, so it's not like there was a reason to keep this solution alive. I guess unless you wrote code for both solutions you just don't "get" it, it's not obvious how superior flat mode is on 386 to anything else. So let me maybe rephrase the question like this: Why is ISA useless on modern 64-bit multicore PCs? Why not keep a slot or two? It's the same with EMS.

Deunan wrote:

Also, 286 in protected mode is not really any slower than real mode, the "frequent segment changes" are true either way due to 64kB limit of each segment.

The 80286 supported variable segment sizes, 1KiB to 64KiB. In theory, it could also support modern day 4KiB blocks, if programmed accordingly.
Because of backwards compatibility, it was left to 64KiB, I think. That's why 16-Bit Windows applications stayed 64KiB in size, also, I believe.
That size was supported by all three operation modes of Windows (real, standard, enhanced). 😀
Edit: Segment sizes could be 1 Byte to 64KB ..
https://en.wikipedia.org/wiki/Protected_mode# … n_compatibility
https://en.wikipedia.org/wiki/Protected_mode#286

Funnily, Windows 3 in Standard Mode often, if not always, was quicker then in Enhanced Mode,
even though it had to move around 64KiB segments vs. slicing them nice and tidy into 4KiB blocks each "behind the curtain" in Enhanced Mode.
Edit: In Windows 3.1, I remember there also was an optional FasterModeSwitch for Standard Mode (286 machines only; disabled by default).

Edit: The 80286 also provided memory protection based on segmentation, even though it was rarely used sadly.
It wasn't until 20 years later, in the mid-2000s, when things like NX/XD bits were introduced as developers slowly realized how
flawed (edit: inferior) 32-Bit flatmode really was in terms of security and application insolation. 😉

Deunan wrote:

EMS idea died the moment the CPU could address past 1MB without resorting to slow, dirty tricks. And that happened with 386. Even real mode DOS programs quickly moved to protected mode and DOS extenders, so it's not like there was a reason to keep this solution alive.

OK, but not "quickly".
First 386 PCs came in 1986/87, but when were first DOS extenders released?
I reckon the first I saw came with Doom (1993), and some Watcom C/C++ compiler - which also supported Windows NT, so must be 1993 as well.
In the meantime, there was plenty of EMS-using software released...

Jo22 wrote:

The 80286 supported variable segment sizes, 1KiB to 64KiB. In theory, it could also support modern day 4KiB blocks, if programmed accordingly.

Segments can be anything from 1 byte to 64kB on 286. You get a 16-bit size field in the descriptor. So yeah, one could use smaller segments but there really isn't much use for those other than OS-managed structures. If you wanted more RAM to use, you'd always be asking for max size - exactly because doing otherwise would end with pretty pointless and costly segment register reloads. Oh and there were some OSes that did "paging" based on segments but this idea never took off.

As for NX bit, that's handy against OS/app bugs, sure, but nowdays we have the same mechanism enabled per-page - just like caching since 486 days. Even in 386 times the fact it's a more coarse (based on 4kB aligned blocks) than segments wouldn't have been an issue. Back then we aleardy moved to multi-MB memory sizes. I mean, we are considering 64k a limitation here after all, so 4kB seems plenty granular. Plus now we also have huge pages (2MB, 1GB) as well - segments are a thing of the past. This was always just a kludge to get a 16-bit 8086/8088 to address 1MB of memory.

Grzyb wrote:

First 386 PCs came in 1986/87, but when were first DOS extenders released?
I reckon the first I saw came with Doom (1993)

No offence but DOS4G was not the first extender, not by a long shot. There were 286 extenders as well, just not so popular since the CPU itself was limiting what you could do and how fast.
DOS4G got so popular exactly because of games and how recognizable the name has become, and the /W part at the end? That stands for Watcom, who integrated support for it into their compiler and that's when it took off.

I don't want to quote Wikipedia here, it's all on the net, I'm just going to point out that Japanese FM Towns system came out in February 28, 1989. It was based on 16MHz 386DX with customized DOS 3.3 (it was in fact closer to DOS 4) and all the apps used Phar Lap DOS extender. In fact you can't even address the video or sound memory on that system, outside a small window below 1MB to emulate text mode, unless you switch the CPU to protected mode to allow 32-bit addressing. This system had a CD-ROM and self-bootable CD games - in '89!

The only reason EMS lived as long as it has in PCs in the 386 era was backward compatibility with 286 systems for business apps. As you yourself noted games abandoned EMS first. Ultima Underworld came before Doom and used it's own DOS extender for example.

OK, so there were DOS extenders before 1993, but it took them years to become dominant.
Wolfenstein 3D (1992) still ran on a 286, in real mode.
Word Perfect 6.0 (about 1992, too) also ran on a 286, in real mode.
There was plenty of 16-bit real mode software still made in the 486 era, which kept EMS important.

BTW: the only 16-bit DOS extender I know is that "DPMI16BI.OVL" thing that came with BP 7.0, and probably with some other Borland products as well.
Were there any others?

Rational DOS/16M was quite popular in late 80s

Grzyb wrote:

OK, so there were DOS extenders before 1993, but it took them years to become dominant.

no, it was about marketshare.

it took years for prices to come down where people could afford them, also OEMS were not just selling 386 systems off the shelf to home users cheap. thats a lot of years get enough market share in the LOW END to sell a 386+ only software product.

so yea, you could buy a 386DX in 1985... but no home users had them.

Most people I know went from 286 to 486 (sx or dx, sx was popular for price), skipping 386 entirely.

Grzyb wrote:

There was plenty of 16-bit real mode software still made in the 486 era, which kept EMS important.

Only because of certain inertia, so to speak. SImply put that software was already in development or received minor updates before it was re-written to make use of 32-bit processors. And when it was, did it use EMS? No, not anymore.

So I stand by what I wrote, 386 arrival killed EMS for good. The fact that we are discussing DOS extenders and their rapid emergence at that point in time is the very proof of that. EMS was dead end, no new software used it, and the old one did so because there was no better choice for real mode DOS (and also to keep 286 machines useful tad bit longer).

I feel like I'm hijacking OP's thread so I'm just going to quickly reiterate: EMS is great for 286, certainly better than XMS, and useful even in form of ISA cards as the CPU itself is usually clocked at 12MHz at most so there isn't any huge bottleneck there. On 386, if you need EMS at all, you use EMM386. But mostly you'd run it with NOEMS option, only to provide UMBs. It's still faster than XMS, even emulated, but in general you want to avoid both by using 32-bit OS or flat memory model with DOS extender.

Deunan wrote:

As for NX bit, that's handy against OS/app bugs, sure, but nowdays we have the same mechanism enabled per-page - just like caching since 486 days.

Yes, perhaps. Segmentation also allowed to declare certain parts of memory as active/executable and data only.
In 32Bit flat mode, the segemention part of the MMU is still active, but made inoperable on purpose by turning the whole adress space into one big segement.
It didn't have had to be that way. OS/2 and other advanced OSes managed to handle segmentation quite well.
In theory, someone could have used 32-Bit Protected Mode with all rings and an intact segmentation. 😀

Phar Lap actually makes use of segments even though it's a flat mode extender. But rather than give you 4GB segments to cover all the memory space via physical addressing you run your code much like on modern OSes, from logical address zero. Program segments only span the available RAM (minus what the OS/extender take for themselves) and while at ring 0, you do get the usual attributes for CS (RX), DS (RW), SS (RW). Things like VRAM are mapped via separate descriptors that you have to load to use. This is way more advanced than what DOS4G did, and frankly just a step or two away from a multitasking OS. But I suppose it was confusing programmers who came from real mode and assumed they can just access all of the computer memory space now, with 32-bit pointers.

Anyway, rings other than 0 and 3 are now useless. Many later CPUs that came with MMU simply had a single user/supervisor bit and worked just fine (Dreamcast SH4 with WinCE, ARMs, etc). We don't use segments now except for some functionality tied to FS/GS segment registers and OS data structures. That could easily be done by having a special purpose address register for system use but nobody is going to re-write the x86 kernels now from scratch I suppose. Plus segment limits are useful for VMs but again, only because no other mechanisms exist in x86 CPUs. Other than that segmetation is gone, much like task switching. Really, everything can be done with a proper MMU and page attributes. It's way faster too as we need paging, and having two address translation mechanism between the program and memory is just waste of silicon and power.