It's odd.

I get a strange mix of feedback. Some from people who call me a jerk etc., and if they go into detail, that usually means they did not understand what I wrote. And the rest says "thank you for writing this. So few people understand. We are really glad someone does."

I work hard on _not_ being hostile, confrontational, and rude.

But, to quote Bill Hicks:

'I don't mean to sound bitter, cold, or cruel, but I am, so that's how it comes out.'

The thing is that XMS is only for data. A real mode DOS binary can't put code there: the addresses are out of range. Only the 64kB of the HMA could hold executable code: 1024-1088kB.

XMS allows a DOS app running on a 286 or 386 to store blocks of data above 1088kB, but the programmer gets no more space for their executable at all.

While EMS _also_ gave you lots more storage, but was much longer established, and it worked on an 8088/8086 and didn't need a 286.

If you wanted bigger *programs* then they had to run in protected mode. To do that and access DOS services meant using a DOS extender, and that did mean paying, but it allowed you to have (a theoretical max of) 16MB programs on a 286 PC and 4GB programs on a 386 PC.

(Not that anyone had 4GB of RAM in an x86 PC in the 20th century.)

So, the choice was:
* EMS: runs on anything, highly compatible, only gets you more data
* XMS: only runs on >= 80286, less compatible, only gets you more data
* DOS Extender: only runs on >= 80286, less compatible, but you get up to 25x bigger programs and almost all the restrictions of plain old DOS go away.

Not a tough choice.

If you used Watcom C, you got Tenberry DOS/4G (or DOS/16) for free.

https://web.archive.org/web/20...

The point is that XMS was next to no use to DOS apps.

"Please, help me, I am so thirsty... I have not had any water in 2 days."
"Certainly, sir, welcome to our petrol station. Feel free to drink as much petrol as you want."

Still not convinced you're not using an LLM bot to come up with this. :-)

Things like:

> I made a mistake in my previous comment. Contrary to what I wrote, DOS programs running under Windows on a 8086 or 80286 cannot use DPMI

Are _exactly_ the sort of thing I expect from ChatGPT or similar when told it's wrong. I could not write a better pastiche of LLM bot output.

Your claims about Windows are still all over the shop.

Yes, it could pre-empt DOS VMs. No, that does not mean they could be swapped. They couldn't. No, it does not mean they had their own memory spaces. They didn't. Pre-386 versions of Windows had to run all DOS apps in the same memory space, and that was the same space as Windows itself.

No, they could not use any API to give more memory to DOS apps.

No, before Windows 3.0, Windows apps could not be kept in XMS or run in XMS.

There is a good history here published a few days ago:

https://www.ninakalinina.com/n...

Yes you can run DOS in a VM. That is not the same as V86 mode.

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

V86 mode was not a hypervisor. Significantly, V86 mode made it easier for an OS to communicate with its DOS apps. They all shared the samefilesystem, for instance. That's harder with a hypervisor.

Now, this matters less because software can just emulate a whole DOS PC, like DOSbox does. You don't need clever bypasses when you can emulate the entire hardware and software and just do whatever you can program.

> I made a mistake in my previous comment. Contrary to what I wrote, DOS programs running under Windows on a 8086 or 80286 cannot use DPMI. DPMI is available only to the Windows kernel itself in Windows 3.x Standard mode. Sorry for that, my memory is getting fuzzy. But XMS is still available, so the point stands.

This sounds like the output of an LLM bot.

As such, I think I'm trying to argue with a machine acting as a spammer.

> There is yet another thing I can't remember clearly (but can learn again by some testing). I'm not sure that the total memory footprint of all loaded DOS apps under real or standard mode Windows 3.x can't be more than 640Kb. It could be true, or not. Windows real/standard mode can swap out the memory belonging to an inactive DOS app to a disk file and restore it on task switch, as far as I can recall.

What is the point of this?

Only Windows 2/386 or 3.x in 386 Enhanced mode has multiple virtual DOS boxes, can swap, etc.

> There is a hacked "NTVDM" for 64-bit Windows, called NTVDMx64. AFAIK, it can run DOS apps under 64-bit Windows using one of two methods - a limited CPU emulator from Insignia that was used in the old non-Intel versions of Windows NT, or using HAXM, which to my limited understanding means using the Intel virtualization extensions to achieve the same result as the V86 mode.

I have written about this:

https://www.theregister.com/20...

For anyone else reading, I think @vbdasc is a software bot, and this looks exactly like "AI" bot slop: a jumbled mess of inconsistent fragments ofthe bot's input data.

That's true.

FWIW I wrote about it:L

https://www.theregister.com/20...

Not really, no, to any of this.

> Windows 3.1 on a 80286 allowed DOS programs to use XMS and DPMI, which allowed them vastly more memory than 640Kb.

Few DOS apps supported XMS, and indeed, back in the era when DOS was current, not many supported DPMI either... but in the era when Windows 3.x was starting to take over, DOS Extenders started to become more common.

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

Quite a few games used DOS extenders, such as Phar Lap:

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

But that does not help ordinary DOS software, the vast majority of which was limited to what would fit into the base 640kB,

So, no, I do not accept your point.

1. Apps had to be specially developed to use this.
2. Those apps wouldn't run on machines that didn't support the tech.
3. There was a per-copy cost for the extenders, so the app vendors had to accept that cost.
4. Different DOS extenders were incompatible with different DOS memory managers. So, for instance, one of the biggest non-game apps, Lotus 1-2-3 R3, used a DOS extender that turned out to be incompatible with HIMEM.SYS and thus Windows 3.x. DOS predated most PCs having internet connections. Before mass use of the Internet, distributing updates was nearly impossible and very *very* expensive.

As a result, it was generally preferable to go without DOS extenders unless absolutely required. You saved money _and_ got wider compatibility.

So, no.

Much the same applies to EMS, except that it was even more limited because everything had to go through the page frame. Also see things like 16MB DMA limits, double-buffering, etc.

> Virtualization extensions from AMD and Intel bring back the V86 mode

No, they do not.

> or something very similar.

Only conceptually similar but incompatible and zero use for running DOS apps under a 64-bit OS.

> AmigaOS was a 32bit OS, and could run a multitasking gui in 0.5mb of ram.

I'd call the classic Amiga and AmigaOS a 16-bit OS myself. Fully 32-bit 680x0 chips did not arrive until later (the 68020) and memory management hardware until later still (68030) -- and AmigaOS cannot use any of those extra features.

[Disclaimer: I own an A1200 with a 68030 accelerator in it, but I am no Amiga expert.]

> There is nothing inherent in a 32bit os that makes it require 4mb of ram

Very true.

But other x86 OSes were as small and multitasked. Concurrent DOS could multitask on an 8086 in 640kB of RAM. QNX could too and was smaller. MWC Coherent was tiny and offered small-memory-model Unix-like multitasking in different variants for 8086, 80286 (Coherent 3) and 80386 in Coherent 4, which is now FOSS:

https://github.com/gspu/Cohere...

https://computeradsfromthepast...

https://www.abortretry.fail/p/...

[Article author here]

> Windows 3.1 had preemptive multitasking too, for DOS programs. In fact, its predecessor Windows/386 2.01 had it too in 1987.

And 3.0, and Windows 2 on all platforms, 8086 and 80286 and 80386.

The thing is that on 8086 and 80286, all your DOS apps had to fit into the same shared 640kB -- which meant it wasn't much use.

> As for backward compatibility, current OS/2 still can run DOS and Win16 applications, with excellent compatibility. Current Windows can't do that.

A very good point.

Of course this is because OS/2 and eComStation and ArcaOS are all 32-bit OSes for x86-32. Sadly x86-64 does not include Virtual86 mode any more, so they can't easily run DOS and DOS apps without emulation.

Intel PAE is a kludge, but I do suspect that a version of ArcaOS with PAE support would do most of what I need from a desktop OS. Sadly I do not think it will ever happen.

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

> Unmentioned in the article is how OS/2 was IBM,

I wrote the article.

I did not mention this because it was not true.

OS/2 was not an IBM product. It was _both_ an IBM _and_ a Microsoft product. Both wrote it, both marketed it.

Allegedly, in v1.x, MS did most of the work and IBM paid. But I can't prove that. If anyone can, let me know.

P.S. There was no "conversion utility" of any kind.

Windows 98 had theability to upgrade an existing copy of Windows. That was the first version that could convert a FAT16 drive to FAT32.

You could not officially upgrade to 95A, 95B or 95C. It was in fact possible to install them over the top _if you deleted C:\WINDOWS\WIN.COM and it would do an in-place upgrade, but there was no way to get from FAT16 to FAT32 without 3rd party tools such as PartitionMagic. I reviewed PartitionMagic 2.0 in PC Pro in 1996 and a reader wrote in and accused it of being an April Fool article, pointing out that my name was an anagram of APRIL VENOM.

I missed the bit about the conversion utility before. This is conclusive proof. You are thinking of Windows 98, *not* Windows 95.
     

Original Win95 absolutely,categorically, with no wiggle room _whatsoever_ did NOT have FAT32.

There were 4 main releases of Win95 and some minor ones:

1. The first release, 14 July 1995

2. Win95A, AKA OEM Service Release 1, Valentine's Day 1996

https://news.microsoft.com/199...

Note: no mention of FAT32.

3. Win95B, AKA OEM Service Release 2, 30 August 1996

This version has the first shipping version of FAT32.

4. OEM Service Release 2.1, one year later (27 Aug 1997)

This version has the first shipping USB support.

5. Windows 95C, OSR 2.5, 27 November 1997

This version bundles IE4 and Active Desktop. You don't want it.

[Article author here]

> Um, wasn't FAT32 introduced in Windows 95 in 1995

No. Windows 95 at release only had FAT16 and Windows NT 3.1 through to the final service pack for NT 4.0 never supported FAT32.

It first appeared in Windows 95 OSR2 and as an end-user option in Windows 95, and for the NT family, in Windows 2000.

But the real point here is thatthe release of Windows 95 marked the end of development for actual original MS-DOS -- and almost completely for DR-DOS as well. Since DOS was bundled in with Win95, that meant no more standalone DOS and no more DOS sales -- and so no more R&D.

It was added to DR-DOS 7.01by Udo Kuhnt as part of the DR-DOS Enhancement after Caldera briefly open-sourcedDR DOS. (It then changed its mind and closed sourced it again. DR-DOS 7.02 -- 7.05 were closed source, as was DR DOS 8.x which only existed very briefly, as it contained FreeDOS code without source and so was a GPL violation.)
   

Never seen it, never heard of it. A bit of Googling revealed it is some US government thing.

Not all the world is America or cares. Not all the English-speaking world is America.

The other 95% of the world neither knows nor cares.