Re: RPG is probably the very worst language ever written.

[Jonathan de Boyne Pollard]

Don't assume that.  Microsoft has a decades-long history of making its DOS programs highly version-specific, often for no really good reasons, remember.  Assume, if you assume anything, that Windows NT's COMMAND is specific to Windows NT.  According to Andrew Schulman et al. it is, containing as it does various "bops" (invalid processor opcodes used to trap out of v8086 mode and back into NTVDM), specifically BOP_CMD (0xc4 0xc4 0x54) the command-interpreter bop.  Such bops will of course will not work outside of NTVDM.

I was reminded, after I posted that, of the reason for BOP_CMD.  It is the undocumented mechanism whereby COMMAND invokes CMD under the covers to execute commands in interactive mode.

NTVDM is such a weird animal. But it's much faster than full emulation.

Not really.  NTVDM is fairly run of the mill when it comes to Virtual DOS Machines that make use of v8086 mode.  They all have a "bop" mechanism of one sort or another.  OS/2 VDMs (and VMBs) use the HLT instruction to trap into the VDM manager, for example.

The fuss made over "paravirtualization" some years ago was rather amusing.  A lot of people thought it was a new idea.  In fact, it was just a trendy name for an old idea.  As can be seen, VDMs on OS/2 and Windows NT had been doing this for about 15 years beforehand.  (And even they weren't the first with this.)  Both OS/2's VDMs/VMBs and NTVDM use these mechanisms to push tasks out of the virtual machine and into the VM monitor.  The handing off from COMMAND to CMD is a case in point.  The tailored DOS kernel in an OS/2 VDM, DOSKRNL, contains quite a few traps to hand off DOS system API functions to the OS/2 API.

The "paravirtualized" COMMAND in Windows NT won't run (unless it is carefully coded with alternative code paths, which I highly doubt, given that there's no need to make the thing capable of running outside of NTVDM) outside of the VDM that it is "paravirtualized" for.  Just as DOSKRNL in OS/2 won't run as a standalone DOS operating system.

You did say that copying zero-length files "won't work [...] in 4DOS".

"Won't work" if you expect it to fail [...]

In English, we call that working.

I recently came across Thomas R. Nicely's WWW page on Windows Vista's DPMI server.  It's pretty confused.  (These people have some quite sensible things to say on the matter of M. Nicely's page.)  And no wonder that it is, if this was how you explained things to M. Nicely, as xe claims you did.  (-:

This DPMI server limit is another case in point, as a matter of fact.  M. Nicely presents this as some sort of mysterious conspiracy against gcc.  In actual fact, as pointed out by M. bwakaz, it's simple defence against all of the stupid and broken things that DPMI-based extended DOS applications are known to do, such as allocating all of the memory that is available at program startup, because they are badly written.  M. bwakaz points to an article by Raymond Chen that anyone wanting to understand this should read.

This DpmiLimit setting that you mentioned is in fact nothing new.  It's simply undocumented on Windows NT 6.  OS/2 VDM's have had a documented DPMI memory limit setting for almost two decades.  The setting is DPMI_MEMORY_LIMIT.  You can read on Usenet and the WWW hundreds of discussions of this, going back to about 1994, and the reasons for tweaking it up and down.  On an OS/2 system one can open up a VDM settings notebook, and obtain on-line help describing the setting. 

Raymond Chen singles out DOS games as some of the particular offenders when it comes to abusing DPMI, and there's a whole FAQ for running DOS games under OS/2 that lists the various different DPMI_MEMORY_LIMIT (and other) settings for getting such games to play nicely with the operating system and not chew up memory unnecessarily, just because the DPMI server in the VDM would otherwuse allow them to.

Again, NTVDM isn't being "weird", at all.  It's implementing a setting, and a limit, that is par for the course in Virtual DOS Machines.  Even the default of 32MiB isn't unusual.  The default for DPMI_MEMORY_LIMIT in OS/2 VDMs was (in recent versions of OS/2, if memory serves) 64MiB.  If you read Raymond Chen's article all of the way to the end, there's even an explanation of why such values are the defaults: It's to cope with the broken extended DOS programs that measure available DPMI memory in KiB using 16-bit integers.  (NTVDM's default assumes signed 16-bit integers.  OS/2's VDM default assumes unsigned 16-bit integers.)

All of these things — be they traps into the VM monitor from inside the VDM, or DPMI server limits to control badly written DOS programs — aren't NTVDM being "weird" or unusual, or secret conspiracies by Microsoft against people who think that compiling with gcc means that one is compiling extended DOS programs.  They're simple long-standing practice for VDMs, and run-of-the-mill stuff for virtual machine technology that goes back for decades.

[Klaus Meinhard]

Hi Jonathan,

< lengthy sermon omitted>

and what, pray, has all this to do with 4DOS, since you continue to
crosspost to com4? Do you really think your words of wisdom have to be
received everywhere? Or could you please adhere to netiquette and stear
your post to a relevant group (preferably one) only?

--
Herzliche Grüße,

Klaus Meinhard

[Jonathan de Boyne Pollard]

and what, pray, has all this to do with 4DOS [...]?

Given that exactly one message back in the thread we were discussing how 4DOS differs from COMMAND in its ability to copy zero-length files, I'd say a lot more than your recent posts on the subjects of, say, altering the settings on public-access computers in libraries.  The best way to topic police is by silent good example, M. Meinhard.  Police your own topic drift before you even think of looking to the topic drifts of others.

[Klaus Meinhard]

Jonathan;

I have criticised your crossposting over several unrelated newsgroups.
I'd now criticize your setting "Followup-To: news.newusers.questions",
and your complete misrepresentation of the thread about fullscreen
consoles, but I have realized that you are in need of always having the
last word, you need the feeling to have "won" even if resorting to the
most absurd means, and are basically to be commiserated with because you
seek your fun in such sad ways. In other words: you're just a troll, and
I won't feed you any more.

*PLONK*

--
Best Regards,

* Klaus Meinhard *
<www.4dos.info>

[Rugxulo]

Hi,

On Apr 22, 8:30 am, Jonathan de Boyne Pollard <J.deBoynePollard-

newsgro...@NTLWorld.COM> wrote:
>
> NTVDM is such a weird animal. But it's much faster than full emulation.
>
> Not really.  NTVDM is fairly run of the mill when it comes to Virtual DOS Machines that make use
> of v8086 mode.  They all have a "bop" mechanism of one sort or another.  OS/2 VDMs
> (and VMBs) use the HLT instruction to trap into the VDM manager, for example.

I meant that using v86 mode (via NTVDM) is clearly much faster than
full emulation like QEMU or DOSBox.

> The "paravirtualized" COMMAND in Windows NT won't run (unless it is carefully coded with
> alternative code paths, which I highly doubt, given that there's no need to make the thing
> capable of running outside of NTVDM) outside of the VDM that it is "paravirtualized" for.

I'm pretty sure XP on up still allow you to make a bootable MS-DOS
floppy. I think that the above-mentioned COMMAND.COM is the one it
uses. If you have proof otherwise, I'd be glad to hear it. (And yes,
4DOS is superior, so there, back on topic, heh.)

(somewhat off-topic below)

> I recently came across Thomas R. Nicely's WWW page on Windows Vista's DPMI server. 
> It's pretty confused.  (These people have some quite sensible things to say on the matter of
> M. Nicely's page.) 

Those paltry comments from two misinformed Linux users are hardly fair
game, not even close.

> And no wonder that it is, if this was how you explained things to M. Nicely, as he claims you did.  (-:

I only told him possible two solutions, neither of which works in all
cases. But it's far better than nothing.

> This DPMI server limit is another case in point, as a matter of fact.  M. Nicely presents this as
> some sort of mysterious conspiracy against gcc.  In actual fact, as pointed out by M. bwakaz,
> it's simple defence against all of the stupid and broken things that DPMI-based extended DOS
> applications are known to do, such as allocating all of the memory that is available at program startup,
> because they are badly written. M. bwakaz points to an article by Raymond Chen that anyone wanting
> to understand this should read.

I've seen that before. That's an old list of bugs for DOS games
running in Win95. That was back when MS cared about DOS. Nowadays you
can't even run any of those games due to lack of graphical support
(Vista, 7).

> This DpmiLimit setting that you mentioned is in fact nothing new. It's simply undocumented on Windows NT 6. 

No, it's definitely new. While everything wasn't perfect in XP, it was
somewhat acceptable. When Vista came around, no DOS gfx support and a
hardcoded 32 MB DPMI limit with no workaround made things much worse.

> Raymond Chen singles out DOS games as some of the particular offenders when it comes to
> abusing DPMI,

There are a few buggy extenders, but some work okay. However, Windows'
own DPMI (0.9 only) is far from perfect, and the Quake guys (even with
CWS helping) had a hard time getting it to work due to bugs. MS even
refused to fix certain bugs in NT, so it never ran there (at least,
not as a DOS app).

> and there's a whole FAQ for running DOS games under OS/2 that lists the various different
> DPMI_MEMORY_LIMIT (and other) settings for getting such games to play nicely with the
> operating system and not chew up memory unnecessarily, just because the DPMI server
> in the VDM would otherwuse allow them to.

I have no problems with limits. It's just when they are insanely low
or arbitrarily set without workaround. I can't help but point out that
32 MB is barely 3% of 1 GB of RAM (which this laptop has). Why am I
restricted to 3%? If you think most DOS apps are buggier than Win32
apps by default, you're wrong.

> Again, NTVDM isn't being "weird", at all.  It's implementing a setting, and a limit, that is par for the course
> in Virtual DOS Machines. 

The limit was not present in XP and its NTVDM. Besides, GCC (esp. 4.x
series) needs a fair bit of RAM, e.g. compiling C++ with optimizations
(e.g. Dungeon Crawl: Stone Soup). I clocked "gpp -O2" as using over
120 MB at one point recently.

> Even the default of 32MiB isn't unusual.  The default for DPMI_MEMORY_LIMIT in OS/2 VDMs
> was (in recent versions of OS/2, if memory serves) 64MiB.  If you read Raymond Chen's article
> all of the way to the end, there's even an explanation of why such values are the defaults:
> It's to cope with the broken extended DOS programs that measure available DPMI memory
> in KiB using 16-bit integers.  (NTVDM's default assumes signed 16-bit integers. 
> OS/2's VDM default assumes unsigned 16-bit integers.)

No, it's because Windows is transitioning. They barely (if at all)
test DOS apps, a "bug" (or mistake) crept it with Server 2003, and
nobody removed it. The registry workaround didn't even exist until
Vista SP1. With AMD64 not having v86 mode, they have the perfect
excuse to dump all 16-bit support. So I expect Windows 8 to not
support anything besides 64-bit. (PAE must not be viable to
them.) :-(

Did you know that CWS had to come back and tweak the DJGPP libc so
that it would work on Win2k and up? It's because MS never fixed the
leaking selectors in NTVDM. The tweaks were eventually backported to
2.03 (hence now called 2.03p2). Plus, a lot of apps are forced to
migrate to Win32 (e.g. Wolf4GW -> Wolf4SDL) because even things like
VDMsound don't work anymore in Vista (or so they say).

> All of these things — be they traps into the VM monitor from inside the VDM, or DPMI server limits
> to control badly written DOS programs — aren't NTVDM being "weird" or unusual, or secret conspiracies
> by Microsoft against people who think that compiling with gcc means that one is compiling extended
> DOS programs.  They're simple long-standing practice for VDMs, and run-of-the-mill stuff for virtual
> machine technology that goes back for decades.

If it were configurable from the start, I'd agree. However, Server
2003 is receiving no more service packs from MS, and it *still* has
the hardcoded (untweakable) DPMI limit. Even Vista didn't get the fix
until SP1, and yes, it was undocumented, so I had to kinda nag one guy
just to look it up for me. I even tested my brother's Win7 laptop, and
it's still broken by default (32 MB only), which is ridiculous. Who
the heck wants to have to edit the registry just to make simple apps
work? (Who knew that 16-bit was a dirty word?)

No, it's no conspiracy against GCC, but yes, MS keeps bugs in NTVDM.
Too bad DOSBox is dirt slow like a real 486 DX2 (but otherwise good),
QEMU is slightly better but still slow, and VirtualBox is fast but
buggy (no SB emulation, some other 16-bit bugs). Booting to FreeDOS
(or DOSEMU) is more and more useful these days.

[Jonathan de Boyne Pollard]

NTVDM is such a weird animal. But it's much faster than full emulation.

Not really.  NTVDM is fairly run of the mill when it comes to Virtual DOS Machines that make use of v8086 mode.  They all have a "bop" mechanism of one sort or another.  OS/2 VDMs (and VMBs) use the HLT instruction to trap into the VDM manager, for example.

I meant that using v86 mode (via NTVDM) is clearly much faster than full emulation like QEMU or DOSBox.

It's still not really a "weird animal", for the reasons already explained.

The "paravirtualized" COMMAND in Windows NT won't run (unless it is carefully coded with alternative code paths, which I highly doubt, given that there's no need to make the thing capable of running outside of NTVDM) outside of the VDM that it is "paravirtualized" for.  Just as DOSKRNL in OS/2 won't run as a standalone DOS operating system.

I'm pretty sure XP on up still allow you to make a bootable MS-DOS floppy. I think that the above-mentioned COMMAND.COM is the one it uses. If you have proof otherwise, I'd be glad to hear it. (And yes, 4DOS is superior, so there, back on topic, heh.)

Proof is easy and obvious, and right in front of one's nose.  Use the VER command.  The COMMAND in Windows NT 5 says:

MS-DOS Version 5.00.500

Do you see any mention of the string that you get from the DOS-Windows ME COMMAND on such a floppy disc ("Windows Millennium [Version 4.90.3000]")?  No, you don't.  And the reason is the obvious one: The COMMAND that is put onto a bootable floppy disc is not the ("paravirtualized") Windows NT COMMAND.  The Windows NT COMMAND program image file doesn't even contain such a version string.  What's on the floppy disc is a different command interpreter.

One can figure this out simply by looking at the files on such a boot disc (which you can do even without expending the effort of making such a disc).  There are files there that don't exist in a Windows NT 6 installation proper, such as KEYB.COM.  Clearly the format utility is unpacking a dedicated set of files from an archive somewhere, not copying across the files that Windows NT itself uses.

I recently came across Thomas R. Nicely's WWW page on Windows Vista's DPMI server.  It's pretty confused.  (These people have some quite sensible things to say on the matter of M. Nicely's page.)  And no wonder that it is, if this was how you explained things to M. Nicely, as xe claims you did.  (-:

Those paltry comments from two misinformed Linux users are hardly fair game, not even close.

On the contrary, the people in that discussion thread are well informed, and M. Nicely is not.

This DpmiLimit setting that you mentioned is in fact nothing new.  It's simply undocumented on Windows NT 6.  OS/2 VDM's have had a documented DPMI memory limit setting for almost two decades.  The setting is DPMI_MEMORY_LIMIT.  You can read on Usenet and the WWW hundreds of discussions of this, going back to about 1994, and the reasons for tweaking it up and down.  On an OS/2 system one can open up a VDM settings notebook, and obtain on-line help describing the setting.

No, it's definitely new. While everything wasn't perfect in XP, it was somewhat acceptable. When Vista came around, no DOS gfx support and a hardcoded 32 MB DPMI limit with no workaround made things much worse.

That's nonsense.  Of course it has a workaround.  It's the one that's just been mentioned.  "Undocumented" is not the same as "not present".   And of course it is not new.  As just explained, OS/2 VDMs/VMBs have had such a setting for almost twenty years.  DOS-Windows 9x had a "MS-DOS Protected Mode (DPMI) Memory" setting for setting a cap on DPMI memory, which defaulted to 16MiB.  This limit is nothing new at all.  It's par for the course and run-of-the-mill.  NTVDM isn't "weird" or unusual or new here.  It's doing exactly what other VDMs have been doing for years.

Raymond Chen singles out DOS games as some of the particular offenders when it comes to abusing DPMI, and there's a whole FAQ for running DOS games under OS/2 that lists the various different DPMI_MEMORY_LIMIT (and other) settings for getting such games to play nicely with the operating system and not chew up memory unnecessarily, just because the DPMI server in the VDM would otherwuse allow them to.

There are a few buggy extenders, but some work okay. However, Windows' own DPMI (0.9 only) is far from perfect, and the Quake guys (even with CWS helping) had a hard time getting it to work due to bugs. MS even refused to fix certain bugs in NT, so it never ran there (at least, not as a DOS app).

I have no problems with limits. It's just when they are insanely low or arbitrarily set without workaround. I can't help but point out that 32 MB is barely 3% of 1 GB of RAM (which this laptop has). Why am I restricted to 3%? If you think most DOS apps are buggier than Win32 apps by default, you're wrong.

If you think that Win32 applications by default go and allocate all memory present in the system, which is one of the bad behaviours exhibited by extended DOS applications that this limit is designed to ameliorate, then it is you that is wrong.  And you're restricted to 32MiB only if you don't explicitly do something about it, just like OS/2 users are restricted to 64MiB (if memory serves) only unless they do something about it. 

You seem not to have realized, too, that this is a limit per NTVDM instance, not a system-wide limit across all virtual DOS machines.  The idea that there's some system-wide restriction that means that you'll only ever use 3% of your RAM is nonsense.  Morever: Would you prefer that every such buggy extended DOS application that you run consume 100% of available DPMI memory, with no cap at all on the virtual memory providable by the DPMI server?  That would be 2GiB consumed for every such program run.  Your virtual memory usage would exceed your laptop's physical memory after running one such buggy pogram.

Every non-standalone DPMI host has this limit.  OS/2 VDMs/VMBs do.  DOS-Windows 9x does.  NTVDM does.  It's there to protect the system from runaway buggy extended DOS applications.  The problem here really is nothing more than that you're not used to having to do this.  DOS-Windows 9x users are.  They know about the "MS-DOS Protected Mode (DPMI) Memory" setting.  OS/2 users are.  They have a whole FAQ devoted to tweaking these settings, as well as an application migration database that is supplied with the operating system itself (%_BOOT%:\OS2\INSTALL\DATABASE.DAT) that supplies the individualized VDM settings tweaks out of the box for DOS applications that IBM/Microsoft knew about.

This is not weird and novel and scary, nor is it some sort of mysterious conspiracy by Microsoft to prevent you from running gcc.  It's old hat and humdrum, and something that's been around so long that people have actually forgotten about these things. 

Again, NTVDM isn't being "weird", at all.  It's implementing a setting, and a limit, that is par for the course in Virtual DOS Machines.  Even the default of 32MiB isn't unusual.  The default for DPMI_MEMORY_LIMIT in OS/2 VDMs was (in recent versions of OS/2, if memory serves) 64MiB.  If you read Raymond Chen's article all of the way to the end, there's even an explanation of why such values are the defaults: It's to cope with the broken extended DOS programs that measure available DPMI memory in KiB using 16-bit integers.  (NTVDM's default assumes signed 16-bit integers.  OS/2's VDM default assumes unsigned 16-bit integers.)

The limit was not present in XP and its NTVDM. Besides, GCC (esp. 4.x series) needs a fair bit of RAM, e.g. compiling C++ with optimizations (e.g. Dungeon Crawl: Stone Soup). I clocked "gpp -O2" as using over 120 MB at one point recently.

No, it's because Windows is transitioning. They barely (if at all)  test DOS apps, a "bug" (or mistake) crept it with Server 2003, and nobody removed it. The registry workaround didn't even exist until Vista SP1. With AMD64 not having v86 mode, they have the perfect excuse to dump all 16-bit support. So I expect Windows 8 to not support anything besides 64-bit. (PAE must not be viable to them.) :-(

That's entirely backwards.  The limit clearly exists to ameliorate a problem that would have previously allowed runaway extended DOS programs to gobble vast amounts of virtual memory.  That's in part what it's there for in OS/2 and DOS-Windows 9x, after all.  This is clearly something that is there to fix NTVDM problems.  As such, it gives lie to your idea that Microsoft is ignoring DOS applications.  (Microsoft expends a fair amount of effort in maintaining compatibility with old applications, more indeed than other people would have it spend.  Just ask Raymond Chen.)  After all, if it were ignoring DOS applications, it wouldn't have changed NTVDM so that buggy extended DOS applications have reduced impact upon the system.

All of these things — be they traps into the VM monitor from inside the VDM, or DPMI server limits to control badly written DOS programs — aren't NTVDM being "weird" or unusual, or secret conspiracies by Microsoft against people who think that compiling with gcc means that one is compiling extended DOS programs.  They're simple long-standing practice for VDMs, and run-of-the-mill stuff for virtual machine technology that goes back for decades.

If it were configurable from the start, I'd agree. However, Server 2003 is receiving no more service packs from MS, and it still has the hardcoded (untweakable) DPMI limit. Even Vista didn't get the fix until SP1, and yes, it was undocumented, so I had to kinda nag one guy just to look it up for me. I even tested my brother's Win7 laptop, and it's still broken by default (32 MB only), which is ridiculous. Who the heck wants to have to edit the registry just to make simple apps work? (Who knew that 16-bit was a dirty word?)

Not configurable from the start?!  It has been configurable, across a range of VDMs, for almost twenty years. As stated earlier, the problem here is that you're simply not used to having to tweak VDM DPMI settings differently for different DOS applications, according to their bugs and idiosyncrasies.  OS/2 users are, and DOS-Windows 9x users are.  Welcome to the reality of DOS applications in VDMs.  You've almost finally caught up with the mid-1990s.  (-:

[Rugxulo]

Hi again,

(somewhat off-topic, esp. since 4DOS never used DPMI)

On Apr 23, 11:02 am, Jonathan de Boyne Pollard <J.deBoynePollard-

newsgro...@NTLWorld.COM> wrote:
>
> This DpmiLimit setting that you mentioned is in fact nothing new.  It's simply undocumented on Windows NT 6.
>

> No, it's definitely new. While everything wasn't perfect in XP, it was somewhat acceptable. When Vista came
> around, no DOS gfx support and a hardcoded 32 MB DPMI limit with no workaround made things much worse.
>
> That's nonsense.  Of course it has a workaround.  It's the one that's just been mentioned.  "Undocumented" is not
> the same as "not present".   And of course it is not new. 

The limit was not enabled by default in XP! It was always enabled in
Vista (originally carried over from 2k3). But you cannot override the
limit in Vista unless you have SP1 (or newer) *and* set the DpmiLimit
entry in the registry.

> As just explained, OS/2 VDMs/VMBs have had such a setting for almost twenty years.  DOS-Windows 9x had a
> "MS-DOS Protected Mode (DPMI) Memory"setting for setting a cap on DPMI memory, which defaulted to 16MiB. 
> This limit is nothing new at all.  It's par for the course and run-of-the-mill.

No, because it wasn't fixable until after SP1. All of the normal
methods (.PIF settings) didn't work, so you had to go to the backdoor
(registry). And you can't do that unless someone tells you, which is
why being undocumented hurts badly.

> I have no problems with limits. It's just when they are insanely low or arbitrarily set without workaround. I can't
> help but point out that 32 MB is barely 3% of 1 GB of RAM (which this laptop has). Why am I restricted to 3%?
> If you think most DOS apps are buggier than Win32 apps by default, you're wrong.
>
> If you think that Win32 applications by default go and allocate all memory present in the system, which is one
> of the bad behaviours exhibited by extended DOS applications that this limit is designed to ameliorate, then it
> is you that is wrong. 

I've seen many Win32 programs use way way way too much RAM. Sure, DOS
apps can in theory use a lot too, but Win32 is far worse in general,
and that's on purpose! They expect that much RAM. You aren't even
supposed to use Vista or 7 with less than 1 GB (though they usually
recommend 2).

I have not tested most of the hundreds of DOS games, so I can't say
which are buggy or not. If you know of any, please mention them (and
especially what extender, if any). The simple truth is that DOS in
general gets a bad rap for a handful of programs. I wouldn't blame
DJGPP for somebody's buggy third-party Watcom sound library, for
example.

Raymond Chen tried hard not to embarrass anyone in his buglist, so he
kept names anonymous. Worse is that none of them will run on modern
Windows, so that market is almost dead (only barely alive thanks to
DOSBox and GoG ... and FreeDOS, DOSEMU, etc). If you think running 0%
of DOS games nowadays is caring about compatibility, you're mistaken!!

> And you're restricted to 32 MiB only if you don't explicitly do something about it, just like OS/2 users are

> restricted to 64MiB (if memory serves) only unless they do something about it. 

It's fine now that a fix works. But it was painful before. The truth
is that some misguided person figured "32 MB should be enough for any
DOS app", which is foolish. Even DOSBox only goes up to 64 MB (and
defaults to 16), but at least they're somewhat honest, targeting only
old games.

> You seem not to have realized, too, that this is a limit per NTVDM instance, not a system-wide limit across
> all virtual DOS machines.  The idea that there's some system-wide restriction that means that you'll only
> ever use 3% of your RAM is nonsense.  Morever: Would you prefer that every such buggy extended DOS
> application that you run consume 100% of available DPMI memory, with no cap at all on the virtual memory
> providable by the DPMI server?  That would be 2GiB consumed for every such program run.  Your virtual
> memory usage would exceed your laptop's physical memory after running one such buggy pogram.

Windows does this all the time. It's a GB world now, so you'd better
stock up! You can't expect to use all the favorite apps without using
a fair amount of RAM these days. None of the DOS apps I use eat up all
my RAM (unless I tell them to, heh). Of course, I'm mostly using DJGPP
and OpenWatcom, which are pretty stable.

Anyways, it doesn't matter about running several NTVDMs if one app in
one NTVDM tries using 37 MB (ahem, paq8o8) and can't run. Virtual
memory or no VM (which I personally doubt exists anymore for DOS
apps), it still wouldn't run, which was frustrating.

> That's entirely backwards.  The limit clearly exists to ameliorate a problem that would have previously allowed
> runaway extended DOS programs to gobble vast amounts of virtual memory.  That's in part what it's there for in
> OS/2 and DOS-Windows 9x, after all.  This is clearly something that is there to fix NTVDM problems.  As such,
> it gives lie to your idea that Microsoft is ignoring DOS applications.  (Microsoft expends a fair amount of effort
> in maintaining compatibility with old applications, more indeed than other people would have it spend. 
> Just ask Raymond Chen.) 

That link is from 2004, and even then I would highly doubt they cared
about DOS apps. They only added some tiny fixes since they forced XP
on home users and dropped WinME. With Vista, they dropped even more
internal compatibility stuff, breaking various apps.

There are still various bugs in the DOS subsystem. MS does know about
them, and they still haven't fixed them (and admittedly won't). Win64
is their future, whether you like it or not. (PAE is shunned due to
"driver bugs".)

> Not configurable from the start?!  It has been configurable, across a range of VDMs, for almost twenty years.

Please install Server 2k3 or Vista RTM (no SPs), and try configuring
it. I'll wait. :-)