RPG is probably the very worst language ever written.

[Jonathan de Boyne Pollard]

It's interesting that all of your criticisms here — language design
that encourages bad code, a great deal of code in the wild, and
writing without regard to maintenance — also apply to the command
scripting languages of IBM's/Microsoft's command interpreters for
PC/MS-DOS, OS/2, and Windows.

True (assuming by "command interpreters" here we mean command.com and
cmd.exe, and not things like Powershell or JScript running under WSH).

Yes.

While cmd.exe has finally reached the point of moderate capability,
it's still a painful mess, particularly for anyone who's written
scripts in something like ksh or bash.

On the gripping hand, how much of that is because those criticisms
are in fact general ones is also something interesting to think about.

Agreed. Coding without regard to maintenance is clearly a general
problem, for one; some languages try to encourage readability
(culminating in the literate-programming languages — though ironically
WEB's use of arcane TeX macros makes its source torturous to read),
but a programming environment can't enforce readable code.

Yes. The old "Real Programmers can write FORTRAN in any language." adage.

In the case of these command interpreter languages, we also need to
look at the limitations of the environment, for command.com, and the
effects of backward compatibility on its successors. Those help
explain some of the problems with quoting in cmd.exe, for
example,though they do nothing to justify, say, the bizarre range of
features in the "for" command.

The limitations of the environment had some part to play in COMMAND,
although command interpreters like 4DOS showed that not all of them were
environment limitations. By far the greater part, however, has been
played by Microsoft's strong adherence to backwards compatibility. One
example of this is the "ECHO." command. Originally an undocumented
quirk of the parsing mechanism (which allowed for characters other than
space to separate commands from their arguments, so one really could
write "PATH=C:\" and it would work), it became promoted to feature by
widespread use, to the extent that it is now the officially documented
mechanism for echoing a blank line.

The quoting problems are down less to backwards compatibility than to
piecemeal improvement, with new features being bolted on in various
places over the years without regard to the coherence of the whole. The
FOR command is the prime example of this, but there are others. Here's

The blank is actually syntactically _required_, both under COMMAND.COM
and 4DOS. However, the undocumented (bug? feature?) behavior under
COMMAND.COM is that the blank is not required for CD, though it _is_
required for all of the other internal commands. Since so many people
discovered & grew accustomed to COMMAND.COM's CD behavior, 4DOS had to
duplicate that. (4DOS uses a single parser for every command;
COMMAND.COM has a mini-parser built into each command, so
COMMAND.COM's syntax tends to vary wildly from command to command.)
It gets more complicated with filename completion though — without a
*LOT* of extra processing there's no way for 4DOS to know whether
you're trying to complete an argument to CD (remember, you might have
aliased CD to something else!) or a filename that happens to begin
with CD. It gets even worse with 4OS2 or 4NT, because on HPFS or NTFS
drives a filename with multiple embedded .'s is perfectly valid.

I discuss these in my documentation, too. I also discuss the
differences between the official syntax as documented and the
side-effects and quirks of the original COMMAND parser that have passed
into folklore.

It's interesting to note that pretty much no serious command interpreter
author advocates replication of all of these quirks. Rex Conn
implemented some of them, but (as far as I can see) takes and took the
view that the officially documented 4DOS/4OS2/4NT/TC syntax is always
preferable to an undocumented quirk, when there's a choice. Microsoft,
of course, advocates that serious script writers switch to something
like PowerShell. I myself favour having a regular syntax, uniform
across all commands, over exact duplication of undocumented quirks.

[Rugxulo]

Hi, :-)

On Mar 27, 8:32 pm, Jonathan de Boyne Pollard <J.deBoynePollard-

Post by Jonathan de Boyne Pollard

It's interesting that all of your criticisms here — language design
that encourages bad code, a great deal of code in the wild, and
writing without regard to maintenance — also apply to the command
scripting languages of IBM's/Microsoft's command interpreters for
PC/MS-DOS, OS/2, and Windows.

True (assuming by "command interpreters" here we mean command.com and
cmd.exe, and not things like Powershell or JScript running under WSH).

Yes.

I don't think most people would consider COMMAND.COM to be a real
scripting language. It doesn't have proper support for a lot of things
(e.g. arithmetic, loops), so it's only really good for very minimal
stuff. CMD has been extended a bit, but I personally don't see a lot
of general-use programs written in it. (I never did attempt to write a
Freecell in it yet, but I thought that would be a good example.)

Post by Jonathan de Boyne Pollard

While cmd.exe has finally reached the point of moderate capability,
it's still a painful mess, particularly for anyone who's written
scripts in something like ksh or bash.

I personally disagree that POSIX sh is somehow less arcane. Take a
look at GNU Autoconf if you don't believe me. ;-) It's probably
more of what you're used to than any inherent superiority, IMHO.

Post by Jonathan de Boyne Pollard
The limitations of the environment had some part to play in COMMAND,
although command interpreters like 4DOS showed that not all of them were
environment limitations.  

I saw a screenshot of some really really old DOS on Wikipedia.
Apparently, COMMAND.COM was only like 4 kb! So surely you can't pack a
lot of features in there (unless really really dedicated and using
assembly, of course). All the modern-day versions of COMMAND.COM
aren't even .COM files, they exceed 64k (even compressed!), just
renamed .EXEs for compatibility. Blame compilers or HLLs or lazy
programmers. ;-)

Post by Jonathan de Boyne Pollard
By far the greater part, however, has been
played by Microsoft's strong adherence to backwards compatibility.  

Microsoft's only strength (besides ubiquity) IS backwards
compatibility due to the closed nature of the platform. And they've
gotten a lot less attached these days for various reasons (XBox 1
[x86] -> XBox 360 [PPC], XP's NTVDM -> Vista no-gfx NTVDM w/ DPMI
limit, etc). And surely x86-64 doesn't help (no V86, no 16-bit stuff).

For the record, there's a difference between reasonable compatibility
and imitating every obscure misfeature.

E.g. "copy zero-byte-file blah" won't work on XP's CMD or FreeDOS'
FreeCOM or in 4DOS. However, according to Timo's FAQ, it's a useful
feature. It still works in other places (DR-DOS, MS-DOS, even the old
WinME COMMAND.COM included in XP) but is not to be relied upon.

Post by Jonathan de Boyne Pollard
One example of this is the "ECHO." command.  Originally an undocumented
quirk of the parsing mechanism (which allowed for characters other than
space to separate commands from their arguments, so one really could
write "PATH=C:\" and it would work)

Well how else would you properly echo a blank line?? I don't know of
any other method.

"PATH c:\blah" is just shorthand to save a few bytes of the 126(?)-
byte cmdline limit (since it's shorter than "set PATH=c:\blah").

Post by Jonathan de Boyne Pollard

The blank is actually syntactically _required_, both under COMMAND.COM
and 4DOS.  However, the undocumented (bug? feature?) behavior under
COMMAND.COM is that the blank is not required for CD, though it _is_
required for all of the other internal commands.  Since so many people
discovered & grew accustomed to COMMAND.COM's CD behavior, 4DOS had to
duplicate that.

You mean "cd.." vs. "cd ..", perhaps?? My main complaint is that even
4DOS doesn't support wildcards with CD (a la Bash) unlike CMD which
does.

Post by Jonathan de Boyne Pollard
I discuss these in my documentation, too.  I also discuss the
differences between the official syntax as documented and the
side-effects and quirks of the original COMMAND parser that have passed
into folklore.

Sorry, where is this documentation? I have my own wimpy list of
incompatibilities for various DOSes. ;-)

Post by Jonathan de Boyne Pollard
It's interesting to note that pretty much no serious command interpreter
author advocates replication of all of these quirks.  Rex Conn
implemented some of them, but (as far as I can see) takes and took the
view that the officially documented 4DOS/4OS2/4NT/TC syntax is always
preferable to an undocumented quirk, when there's a choice.  Microsoft,
of course, advocates that serious script writers switch to something
like PowerShell.  I myself favour having a regular syntax, uniform
across all commands, over exact duplication of undocumented quirks.

PowerShell isn't even included in Vista by default, not sure about Win
7 though. So that alone makes it less attractive for anyone trying to
write a script that will "just work" by default. (Besides, it looks
unwieldy to me. Of course, so does Bash, but at least I might learn a
drop of that some day ... maybe.)

For example, even a widespread alternative like REXX probably isn't a
perfect solution either, mainly because you have to have lots of
testers if you really intend to write portable stuff (else just stick
to publically-available interpreters like Regina). However, REXX is
certainly more capable than COMMAND.COM (and arguably equally as
capable as 4DOS or CMD).

[Jonathan de Boyne Pollard]

Post by Rugxulo

Post by Jonathan de Boyne Pollard

It's interesting that all of your criticisms here — language design
that encourages bad code, a great deal of code in the wild, and
writing without regard to maintenance — also apply to the command
scripting languages of IBM's/Microsoft's command interpreters for
PC/MS-DOS, OS/2, and Windows.

True (assuming by "command interpreters" here we mean command.com
and cmd.exe, and not things like Powershell or JScript running under
WSH).

Yes.

I don't think most people would consider COMMAND.COM to be a real
scripting language. It doesn't have proper support for a lot of things
(e.g. arithmetic, loops), so it's only really good for very minimal
stuff. CMD has been extended a bit, but I personally don't see a lot
of general-use programs written in it. (I never did attempt to write a
Freecell in it yet, but I thought that would be a good example.)

I reintroduce you to the newsgroups that you clearly thought would

Post by Rugxulo

Post by Jonathan de Boyne Pollard
The limitations of the environment had some part to play in COMMAND,
although command interpreters like 4DOS showed that not all of them
were environment limitations.

I saw a screenshot of some really really old DOS on Wikipedia.
Apparently, COMMAND.COM was only like 4 kb! So surely you can't pack a
lot of features in there (unless really really dedicated and using
assembly, of course).

That size wasn't a limit. It's just the size that the command
interpreter happened to have. Environment limitations are things like
the 8.3 filename syntax.

Post by Rugxulo
"copy zero-byte-file blah" won't work on XP's CMD or FreeDOS' FreeCOM
or in 4DOS. However, according to Timo's FAQ, it's a useful feature.
It still works in other places (DR-DOS, MS-DOS, even the old WinME
COMMAND.COM included in XP) but is not to be relied upon.

When did 4DOS start having a problem copying zero-length files? It has
no such problem, to my knowledge. Indeed, when did Windows NT 5.1's
COMMAND (which isn't from DOS-Windows ME, by the way) stop having this
problem? It most definitely does have it.

Post by Rugxulo

Post by Jonathan de Boyne Pollard
One example of this is the "ECHO." command. Originally an
undocumented quirk of the parsing mechanism (which allowed for
characters other than space to separate commands from their
arguments, so one really could write "PATH=C:\" and it would work),
it became promoted to feature by widespread use, to the extent that
it is now the officially documented mechanism for echoing a blank line.

Well how else would you properly echo a blank line??

The obvious way to most people is the way that one does it on other
systems: ECHO with a blank line as its arguments. "ECHO." only arose
because that didn't work, and someone found an undocumented quirk in the
parsing mechanism that could be taken advantage of, which was promoted
to feature by widespread use, to the extent that it is now the
officially documented mechanism for echoing a blank line.

Post by Rugxulo
"PATH c:\blah" is just shorthand to save a few bytes of the
126(?)-byte cmdline limit (since it's shorter than "set PATH=c:\blah").

I wrote "PATH=C:\", not that. The equals sign is important to the point.

[Rugxulo]

Hi,

On Mar 31, 3:55 pm, Jonathan de Boyne Pollard <J.deBoynePollard-

Post by Jonathan de Boyne Pollard
I reintroduce you to the newsgroups that you clearly thought would

That's fine, I just got a little freaked the other day in another
group when I almost replied some very off-topic stuff due to unknown
"cc". (alt.lang.asm -> microsoft.*, comp.lang.delphi ... huh? Not a
lot similar there.)

Post by Jonathan de Boyne Pollard

Post by Rugxulo
I saw a screenshot of some really really old DOS on Wikipedia.
Apparently, COMMAND.COM was only like 4 kb! So surely you can't pack a
lot of features in there (unless really really dedicated and using
assembly, of course).

That size wasn't a limit.  It's just the size that the command
interpreter happened to have.  Environment limitations are things like
the 8.3 filename syntax.

Well, I mainly meant that a 4 kb COMMAND.COM probably lacks a *lot* of
things we take for granted these days. But I don't have access to
that, so I can't say for sure.

Post by Jonathan de Boyne Pollard

Post by Rugxulo
"copy zero-byte-file blah" won't work on XP's CMD or FreeDOS' FreeCOM
or in 4DOS. However, according to Timo's FAQ, it's a useful feature.
It still works in other places (DR-DOS, MS-DOS, even the old WinME
COMMAND.COM included in XP) but is not to be relied upon.

When did 4DOS start having a problem copying zero-length files?  It has
no such problem, to my knowledge.  Indeed, when did Windows NT 5.1's
COMMAND (which isn't from DOS-Windows ME, by the way) stop having this
problem?  It most definitely does have it.

Not from ME? What's the diff? I just assumed since that's what boot
disk XP will make (mostly).

You misunderstood. 4DOS didn't "start" having the "problem" because
it's a "feature" that it doesn't support (i.e. it *does* copy 0-byte
files). COMMAND.COM does what people are used to, e.g. it won't copy
such files. One guy (perhaps quoted in Timo's FAQ) said, "I hope they
never fix that!" Well, sorry to say, it's not a universal fix! (Nor is
relying on FIND to return errorlevel in DR-DOS.)

Post by Jonathan de Boyne Pollard

Post by Rugxulo
Well how else would you properly echo a blank line??

The obvious way to most people is the way that one does it on other
systems: ECHO with a blank line as its arguments.  "ECHO." only arose
because that didn't work

Right, "echo" by itself will just say "ECHO is on". DR-DOS has a few
other variants: echoerr, echos, etc. (I forget exactly offhand since I
never use those).

Post by Jonathan de Boyne Pollard

Post by Rugxulo
"PATH c:\blah" is just shorthand to save a few bytes of the
126(?)-byte cmdline limit (since it's shorter than "set PATH=c:\blah").

I wrote "PATH=C:\", not that.  The equals sign is important to the point.

Yes, I understood the point. I just meant that there's an advantage to
using "PATH" without "set". :-)

[Jonathan de Boyne Pollard]

Post by Rugxulo

Post by Jonathan de Boyne Pollard

Post by Rugxulo
"copy zero-byte-file blah" won't work on XP's CMD or FreeDOS'
FreeCOM or in 4DOS. However, according to Timo's FAQ, it's a useful
feature. It still works in other places (DR-DOS, MS-DOS, even the
old WinME COMMAND.COM included in XP) but is not to be relied upon.

When did 4DOS start having a problem copying zero-length files? It
has no such problem, to my knowledge. Indeed, when did Windows NT
5.1's COMMAND (which isn't from DOS-Windows ME, by the way) stop
having this problem? It most definitely does have it.

Not from ME? What's the diff? I just assumed since that's what boot
disk XP will make (mostly).

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.

Post by Rugxulo
You misunderstood. 4DOS didn't "start" having the "problem" because
it's a "feature" that it doesn't support (i.e. it *does* copy 0-byte
files).

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

[Rugxulo]

Hi,

On Apr 15, 1:50 am, Jonathan de Boyne Pollard <J.deBoynePollard-

Post by Rugxulo
Not from ME? What's the diff? I just assumed since that's what boot
disk XP will make (mostly).

Don't assume that.  Microsoft has a decades-long history of making its
DOS programs highly version-specific, often for no really good reasons,

Yeah, MS-DOS 5 utils have a hardcoded version 5 check that won't work
on 6, for example. (Simple to patch, though, "jae" instead of "je".)

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.

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

Post by Rugxulo
You misunderstood. 4DOS didn't "start" having the "problem" because
it's a "feature" that it doesn't support (i.e. it *does* copy 0-byte
files).

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

"Won't work" if you expect it to fail on copying zero-length files
like MS-DOS did (see TSBAT*.ZIP). Like I said, this is pretty obscure,
so I can't really fault JPsoft here, but it IS an
incompatibility. ;-)

[Jonathan de Boyne Pollard]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:328bf1bd-eeec-41eb-b1b8-***@k36g2000yqn.googlegroups.com"
type="cite">
<blockquote type="cite">
<p>Don't assume that. &nbsp;Microsoft has a decades-long history of
making its DOS programs highly version-specific, often for no really
good reasons, remember. &nbsp;Assume, if you assume anything, that Windows
NT's <code>COMMAND</code> is specific to Windows NT. &nbsp;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 <code>BOP_CMD</code> (<code>0xc4 0xc4 0x54</code>)
the command-interpreter bop. &nbsp;Such bops will of course will not work
outside of NTVDM.</p>
</blockquote>
</blockquote>
<p>I was reminded, after I posted that, of the reason for <code>BOP_CMD</code>.&nbsp;
It is the undocumented mechanism whereby <a
href="http://technet.microsoft.com/en-us/library/cc723564.aspx#XSLTsection123121120120"><code>COMMAND</code>
invokes <code>CMD</code> under the covers to execute commands in
interactive mode</a>.</p>
<blockquote
cite="mid:328bf1bd-eeec-41eb-b1b8-***@k36g2000yqn.googlegroups.com"
type="cite">
<p>NTVDM is such a weird animal. But it's much faster than full
emulation.</p>
</blockquote>
<p>Not really.&nbsp; NTVDM is fairly run of the mill when it comes to
Virtual DOS Machines that make use of v8086 mode.&nbsp; They all have a
"bop" mechanism of one sort or another.&nbsp; OS/2 VDMs (and VMBs) use the <code>HLT</code>
instruction to trap into the VDM manager, for example.</p>
<p>The fuss made over "paravirtualization" some years ago was rather
amusing.&nbsp; A lot of people thought it was a new idea.&nbsp; In fact, it was
just a trendy name for an old idea.&nbsp; As can be seen, VDMs on OS/2 and
Windows NT had been doing this for about 15 years beforehand.&nbsp; (And
even they weren't the first with this.)&nbsp; Both OS/2's VDMs/VMBs and
NTVDM use these mechanisms to push tasks out of the virtual machine and
into the VM monitor.&nbsp; The handing off from <code>COMMAND</code> to <code>CMD</code>
is a case in point.&nbsp; The tailored DOS kernel in an OS/2 VDM, <code>DOSKRNL</code>,
contains quite a few traps to hand off DOS system API functions to the
OS/2 API.</p>
<p>The "paravirtualized" <code>COMMAND</code> 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.&nbsp; Just as <code>DOSKRNL</code> in OS/2 won't run
as a standalone DOS operating system.</p>
<blockquote
cite="mid:328bf1bd-eeec-41eb-b1b8-***@k36g2000yqn.googlegroups.com"
type="cite">
<blockquote type="cite">
<p>You did say that copying zero-length files "won't work [...] in
4DOS".</p>
</blockquote>
<p>"Won't work" if you expect it to fail [...]</p>
</blockquote>
<p>In English, we call that <em>working</em>.</p>
<p>I recently came across Thomas
R. Nicely's WWW page on Windows Vista's DPMI server.&nbsp; It's pretty
confused.&nbsp; (<a
href="http://justlinux.com./forum/showthread.php?p=866737">These people</a>
have some quite sensible things to say on the matter of M. Nicely's
page.)&nbsp; And no wonder that it is, if this was how you explained things
to M. Nicely, as xe claims you did.&nbsp; (-:</p>
<p></p>
<p>This
DPMI server limit is another case in point, as a matter of fact.&nbsp; M.
Nicely presents this as some sort of mysterious conspiracy against
gcc.&nbsp; 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.&nbsp; M.
bwakaz points to <a
href="http://ptgmedia.pearsoncmg.com./images/9780321440303/samplechapter/Chen_bonus_ch02.pdf">an
article by Raymond Chen</a> that anyone wanting to understand this
should read.</p>
<p></p>
<p>This
<code>DpmiLimit</code> setting that you mentioned is in fact nothing
new.&nbsp; It's simply <em>undocumented</em> on Windows NT 6.&nbsp; OS/2 VDM's
have had a <em>documented</em> DPMI memory limit setting for almost
two decades.&nbsp; The setting is <code>DPMI_MEMORY_LIMIT</code>.&nbsp; 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.&nbsp; On an OS/2
system one can open up a VDM settings notebook, and obtain on-line help
describing the setting.&nbsp; </p>
<p></p>
<p>Raymond
Chen singles out DOS games as some of the particular offenders when it
comes to abusing DPMI, and <a
href="http://faqs.org./faqs/os2-faq/dos-games/">there's a whole FAQ
for running DOS games under OS/2</a> that lists the various different <code>DPMI_MEMORY_LIMIT</code>
(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.</p>
<p></p>
<p>Again,
NTVDM isn't being "weird", at all.&nbsp; It's implementing a setting, and a
limit, that is par for the course in Virtual DOS Machines.&nbsp; Even the
default of 32MiB isn't unusual.&nbsp; The default for <code>DPMI_MEMORY_LIMIT</code>
in OS/2 VDMs was (in recent versions of OS/2, if memory serves) 64MiB.&nbsp;
If you read Raymond Chen's article all of the way to the end, there's
even an explanation of <em>why</em> such values are the defaults: It's
to cope with the <em>broken extended DOS programs</em> that measure
available DPMI memory in KiB using 16-bit integers.&nbsp; (NTVDM's default
assumes signed 16-bit integers.&nbsp; OS/2's VDM default assumes unsigned
16-bit integers.)</p>
<p>All
of these things &#8212; be they traps into the VM monitor from inside
the VDM, or DPMI server limits to control badly written DOS programs
&#8212; 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.&nbsp; They're simple long-standing practice
for VDMs, and run-of-the-mill stuff for virtual machine technology that
goes back for decades.</p>
</body>
</html>

[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?

[Jonathan de Boyne Pollard]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:hqqc1r$9hh$00$***@news.t-online.com" type="cite">
<p>and what, pray, has all this to do with 4DOS [...]?</p>
</blockquote>
<p>Given that <em>exactly one message back</em> in the thread we were
discussing how 4DOS differs from COMMAND in its ability to copy
zero-length files, I'd say <em>a lot more</em> than <em>your</em>
recent posts on the subjects of, say, altering the settings on
public-access computers in libraries.&nbsp; The best way to topic police is
by silent good example, M. Meinhard.&nbsp; Police your own topic drift
before you even think of looking to the topic drifts of others.<br>
</p>
</body>
</html>

[Klaus Meinhard]

Jonathan;

Post by 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.

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*

[Rugxulo]

Hi,

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

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.
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
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]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<blockquote
cite="mid:328bf1bd-eeec-41eb-b1b8-***@k36g2000yqn.googlegroups.com"
type="cite">
<p>NTVDM is such a weird animal. But it's much faster than full
emulation.</p>
</blockquote>
<p>Not really.&nbsp; NTVDM is fairly run of the mill when it comes to
Virtual DOS Machines that make use of v8086 mode.&nbsp; They all have a
"bop" mechanism of one sort or another.&nbsp; OS/2 VDMs (and VMBs) use the <code>HLT</code>
instruction to trap into the VDM manager, for example.</p>
</blockquote>
<p wrap="">I meant that using v86 mode (via NTVDM) is clearly much
faster than full emulation like QEMU or DOSBox.<br>
</p>
</blockquote>
<p>It's still not really a "weird animal", for the reasons already
explained.</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>The "paravirtualized" <code>COMMAND</code> 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.&nbsp; Just as <code>DOSKRNL</code> in OS/2 won't run
as a standalone DOS operating system.</p>
</blockquote>
<p wrap="">I'm pretty sure XP on up still allow you to make a
bootable MS-DOS floppy. I think that the above-mentioned <code>COMMAND.COM</code>
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.)</p>
</blockquote>
<p>Proof is easy and obvious, and right in front of one's nose.&nbsp; Use
the <code>VER</code> command.&nbsp; The <code>COMMAND</code> in Windows NT
5 says:</p>
<blockquote type="cite">
<p>MS-DOS Version 5.00.500</p>
</blockquote>
<p>Do you see any mention of the string that you get from the
DOS-Windows ME <code>COMMAND</code> on such a floppy disc ("<a
href="Loading Image...">Windows Millennium
[Version 4.90.3000]</a>")?&nbsp; No, you don't.&nbsp; And the reason is the
obvious one: The <code>COMMAND</code> that is put onto a bootable
floppy disc is not the ("paravirtualized") Windows NT <code>COMMAND</code>.&nbsp;
The Windows NT <code>COMMAND</code> program image file doesn't even
contain such a version string.&nbsp; What's on the floppy disc is a <em>different
command interpreter</em>.<br>
</p>
<p>One can figure this out <em>simply by looking at the files</em> on
such a boot disc (which you can do <a
href="http://theeldergeek.com./create_ms-dos_startup_disk.htm">even
without expending the effort of making such a disc</a>).&nbsp; There are
files there that don't exist in a Windows NT 6 installation proper,
such as <code>KEYB.COM</code>.&nbsp; 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.<br>
</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<p wrap=""></p>
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>I recently came across Thomas
R. Nicely's WWW page on Windows Vista's DPMI server.&nbsp; It's pretty
confused.&nbsp; (<a moz-do-not-send="true"
href="http://justlinux.com./forum/showthread.php?p=866737">These people</a>
have some quite sensible things to say on the matter of M. Nicely's
page.)&nbsp; And no wonder that it is, if this was how you explained things
to M. Nicely, as xe claims you did.&nbsp; (-:</p>
</blockquote>
<p>Those paltry comments from two misinformed Linux users are hardly
fair game, not even close.</p>
</blockquote>
<p>On the contrary, the people in that discussion thread are well
informed, and M. Nicely is not.</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>This
<code>DpmiLimit</code> setting that you mentioned is in fact
nothing
new.&nbsp; It's simply <em>undocumented</em> on Windows NT 6.&nbsp; OS/2 VDM's
have had a <em>documented</em> DPMI memory limit setting for almost
two decades.&nbsp; The setting is <code>DPMI_MEMORY_LIMIT</code>.&nbsp; 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.&nbsp; On an OS/2
system one can open up a VDM settings notebook, and obtain on-line help
describing the setting. </p>
</blockquote>
<p wrap="">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.<br>
</p>
</blockquote>
<p>That's nonsense.&nbsp; Of course it has a workaround.&nbsp; It's the one
that's just been mentioned.&nbsp; "Undocumented" is not the same as "not
present".&nbsp;&nbsp; And of course it is not new.&nbsp; As just explained, OS/2
VDMs/VMBs have had such a setting for almost twenty years.&nbsp; DOS-Windows
9x had a <span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;">"<a
href="http://technet.microsoft.com/en-us/library/cc751101.aspx#XSLTsection127121120120">MS-DOS
Protected Mode (DPMI) Memory</a>"</span></span> setting for setting a
cap on DPMI memory, which defaulted to 16MiB.&nbsp; This limit is nothing
new at all.&nbsp; It's par for the course and run-of-the-mill.&nbsp; NTVDM isn't
"weird" or unusual or new here.&nbsp; It's doing exactly what other VDMs
have been doing for years.<br>
</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<p wrap=""></p>
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>Raymond
Chen singles out DOS games as some of the particular offenders when it
comes to abusing DPMI, and <a moz-do-not-send="true"
href="http://faqs.org./faqs/os2-faq/dos-games/">there's a whole FAQ
for running DOS games under OS/2</a> that lists the various different <code>DPMI_MEMORY_LIMIT</code>
(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.</p>
</blockquote>
<p wrap="">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).<br>
<br>
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.<br>
</p>
</blockquote>
<p>If you think that Win32 applications by default <em>go and allocate
all memory present in the system</em>, 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.&nbsp; And you're
restricted to 32MiB <em>only</em> 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.&nbsp; <br>
</p>
<p>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.&nbsp; The
idea that there's some system-wide restriction that means that you'll
only ever use 3% of your RAM is nonsense.&nbsp; 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?&nbsp; That would be 2GiB consumed for every
such program run.&nbsp; Your virtual memory usage would exceed your laptop's
physical memory after running <em>one</em> such buggy pogram. <br>
</p>
<p>Every non-standalone DPMI host has this limit.&nbsp; OS/2 VDMs/VMBs do.&nbsp;
DOS-Windows 9x does.&nbsp; NTVDM does.&nbsp; It's there to protect the system
from runaway buggy extended DOS applications.&nbsp; The problem here really
is nothing more than that you're not used to having to
do this.&nbsp; DOS-Windows 9x users are.&nbsp; They know about the <span
class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;">"<a
href="http://technet.microsoft.com/en-us/library/cc751101.aspx#XSLTsection127121120120">MS-DOS
Protected Mode (DPMI) Memory</a>"</span></span> setting.&nbsp; OS/2 users
are.&nbsp; They have <a href="http://faqs.org./faqs/os2-faq/dos-games/">a
whole FAQ</a>
devoted to tweaking these settings, as well as an application migration
database that is supplied with the operating system itself (<code>%_BOOT%:\OS2\INSTALL\DATABASE.DAT</code>)
that supplies the individualized VDM settings tweaks out of the box for
DOS applications that IBM/Microsoft knew about.<br>
</p>
<p>This is not weird and novel and scary, nor is it some sort of
mysterious conspiracy by Microsoft to prevent you from running gcc.&nbsp;
It's old hat and humdrum, and something that's been around so long that
people have actually <em>forgotten</em> about these things.&nbsp; <br>
</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>Again,
NTVDM isn't being "weird", at all.&nbsp; It's implementing a setting, and a
limit, that is par for the course in Virtual DOS Machines.&nbsp; Even the
default of 32MiB isn't unusual.&nbsp; The default for <code>DPMI_MEMORY_LIMIT</code>
in OS/2 VDMs was (in recent versions of OS/2, if memory serves) 64MiB.&nbsp;
If you read Raymond Chen's article all of the way to the end, there's
even an explanation of <em>why</em> such values are the defaults: It's
to cope with the <em>broken extended DOS programs</em> that measure
available DPMI memory in KiB using 16-bit integers.&nbsp; (NTVDM's default
assumes signed 16-bit integers.&nbsp; OS/2's VDM default assumes unsigned
16-bit integers.)</p>
</blockquote>
<p wrap="">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.</p>
<p>No, it's because Windows is transitioning. They barely (if at
all)&nbsp; 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.) :-(</p>
</blockquote>
<p>That's entirely backwards.&nbsp; The limit clearly exists to ameliorate a
problem that would have previously allowed runaway extended DOS
programs to gobble vast amounts of virtual memory.&nbsp; That's in part what
it's there for in OS/2 and DOS-Windows 9x, after all.&nbsp; This is clearly
something that is there to <em>fix</em> NTVDM problems.&nbsp; As such, it
gives lie to your idea that Microsoft is ignoring DOS applications.&nbsp;
(Microsoft expends a fair amount of effort in maintaining compatibility
with old applications, more indeed than other people would have it
spend.&nbsp; <a
href="http://blogs.msdn.com/oldnewthing/archive/2004/03/01/82103.aspx">Just
ask Raymond Chen</a>.)&nbsp; After all, if it were ignoring DOS
applications, it <em>wouldn't have changed NTVDM</em> so that buggy
extended DOS applications have reduced impact upon the system.</p>
<blockquote
cite="mid:15f23015-a46d-48e8-9d65-***@z11g2000yqz.googlegroups.com"
type="cite">
<blockquote
cite="mid:***@J.de.Boyne.Pollard.localhost"
type="cite">
<p>All
of these things &#8212; be they traps into the VM monitor from inside
the VDM, or DPMI server limits to control badly written DOS programs
&#8212; 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.&nbsp; They're simple long-standing practice
for VDMs, and run-of-the-mill stuff for virtual machine technology that
goes back for decades.</p>
</blockquote>
<p wrap="">If it were configurable from the start, I'd agree.
However, Server 2003 is receiving no more service packs from MS, and it
<em>still</em> 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?)<br>
</p>
</blockquote>
<p>Not configurable from the start?!&nbsp; It has been configurable, across
a range of VDMs, for <em>almost twenty years</em>. <span
class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;"></span></span>
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.&nbsp; OS/2 users
are, and DOS-Windows 9x users are.&nbsp; Welcome to the reality of DOS
applications in VDMs.&nbsp; You've almost finally caught up with the
mid-1990s.&nbsp; (-:<br>
</p>
<p><span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;"></span></span></p>
</body>
</html>

[Rugxulo]

Hi again,

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

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

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. :-)

[Jonathan de Boyne Pollard]

Post by Rugxulo

Post by Jonathan de Boyne Pollard
I discuss these in my documentation, too. I also discuss the
differences between the official syntax as documented and the
side-effects and quirks of the original COMMAND parser that have
passed into folklore.

Sorry, where is this documentation?

Bundled with the command interpreter. It comes in the package.