For example, DOS refuses to run any flat binary (COM format) bigger than 64Kb.
IMO there is no good reason for this. It was probably an early feeble attempt to enforce code separation but doesn't really even achieve that purpose. It also ignores the possibility that the code might want to access embedded data, so why shouldn't DS, ES etc be changed?

In FAMOS I have created flat binary applications which are over 30Mbytes in size and which would also run in DOS (with unreal mode) if DOS allowed it.

I have also created several COM files up to 512K in size which WILL run in plain DOS, but only if loaded and executed via DOS's own DEBUG utility!

You can have a MZ EXE for just 32 bytes supplement.

> so why shouldn't DS, ES etc be changed?

So go ahead. Any big problem encountered ?



Legacy I/O area from $0A'0000 to $0F'FFFF isn't a problem ?

> created several COM files up to 512K in size which WILL run in plain DOS,
> but only if loaded and executed via DOS's own DEBUG utility

Interesting, but MZ would also do the job.

Nevertheless, DOS indeed is a bit "dumb" - it fails to reject broken EXE's

If it did load such a program, what should it initialize the stack pointer to? A .COM file must be run with CS = DS = ES = SS at entry... so in a 64k program, no matter what the initial SP is, it'll be overwriting something.

Yes, another limitation! SP is usually set to something like FFFEh.