It must be true I read/heard it in the news!

[Garrett Goebel]

I really shouldn't post... Oh well. Consider it a parting broadside...

Brian Densmore wrote:
> Garrett Goebel wrote:
> >
> > Let he who is without sin cast the first stone...
> >
> > On Windows NT there are 2 command shells: CMD.EXE AND
> > COMMAND.COM.
> >
> > CMD.EXE is the NT native command shell and sports new features
> > and syntax in each successive windows OS, and has worked under
> > all supported architectures.  CMD.EXE is ***NOT*** DOS, or what
> > is left of it. No 16-bit virtual DOS machine is invoked when
> > CMD.EXE is launched. CMD.EXE is no more DOS than Bash is Linux.
> >
> > COMMAND.COM was the attempt at a DOS backward compatible shell.
> > If you started COMMAND.COM and checked the process list, you'd
> > notice it ran inside the NTVDM process. NTVDM was the NT Virtual
> > DOS Machine which provided backward support for 16-bit DOS
> > programs so long as they didn't attempt direct access to
> > hardware.
> ...
> Well yes and no.
>
> Yes there are a lot of features added, but they are not anything
> new under the Sun.

Few things are. Under the same reasoning you might say DOS is CP/M is
TOPS-10 is ... ad nauseum.

I believe the crux of our argument is that you are unable or unwilling to
differentiate between the self-hosting DOS operating system and things that
bear a resemblance to its command shell.

If the article talks about a windows native command shell, it is most
certainly not talking about the DOS in a virtual machine COMMAND.com. It is
most likely talking about the NT native command shell CMD.exe, and there's
the slim possibility that an alternative "native" shell exists or is being
developed. Or perhaps they've seen the light, and they're really talking
about a pending release of bash for NT...

But I can see you're going to stick to your position come hell or high
water. So consider the rest of my response directed at anyone else who might
be reading... Personally, I'd recommend moving to higher ground.

> These are things you didn't see in some of the stock DOS manuals.
> Some of these things were there, but undocumented. Some were
> utilities the M$ bought/stole from other DOSes.

And some of it is new code. The size of CMD.EXE on NT40 is 208KB. On XP it
is 376KB.

> M$ DOS isn't the only DOS in existence.

Yes, I think I've used nearly all of them: IBM PCDOS, MSDOS, DRDOS, and
FreeDOS. I have never used the QDOS that MSDOS is derived from.

> I used to run a 32 bit version of DOS that had all/most of the
> capabilities of cmd.exe and command.com.

Someone at AdTI was recently ranting that Linux has all the capabilities of
Minix. Does that mean it must be derived from it?

> What has happened is M$
> has added some utility programs that are accessible to this new
> "shell". If you look at the actual code that lies underneath it's
> still the old DOS code.

I've never had the opportunity to look at the source for MSDOS and CMD.exe.
Have you? Show me the offending lines of code. Or is this an unsupportable
claim along the lines of our friends at SCO?

Even if some code were reused, that is neither here nor there. -It doesn't
transform a usermode shell into an operating system. You seem grudgingly
willing to grant that CMD is a new shell, but unwilling to recognize that it
is not an operating system.

> Even Windows 286 (do you remember Windows
> 286, I do) launched a "Virtual DOS Machine".

CMD.exe does _not_ launch a "Virtual DOS Machine". It will run on non-x86
platforms without a virtual machine. DOS can't do that...

DOS doesn't run on non-x86 platforms without a virtual machine. CMD.exe
does. I.e., no DOS x86 or virtual machine... no DOS. Because DOS assumes
direct access to hardware, if you really must have DOS on NT you run
COMMAND.COM which executes the NTVDM.exe (NT Virtual DOS Machine) process.
On the other hand, CMD.EXE is a shell that executes as a native process. It
is not DOS.

> Don't believe everything M$ tells you about their technology.
> They are pathological liars.

Dont' you think that is a bit harsh. Sure there's stacker, but not everyone
at Microsoft works in Sales and Marketing ;) -They actually have some very
good engineers, developers, and researchers. And I'm pretty sure the vast
majority of them don't deserve this blanket libel.

> NT wasn't a "complete" rewrite of
> Windows. There is DOS code in there. Windows 9x still does one
> DOS hardware call. Windows 95 also took control of the hardware

Windows 9x is not NT.

Do you really think the ex-VMS developers who wrote NT threw out all their
knowledge and experience and started over with DOS? Besides a reasonable
assumption of sanity, there's a settlement Microsoft made with DEC based on
the similarities between VMS and WNT which says otherwise.

NT's lead designer was David Cutler. At Digital, he'd worked on OS's for the
much beloved PDP-11 and also RSX-11M. He was one of the lead designers of
VMS. In 1981 he was given 200 hardware and software engineers and charged
with designing a new cpu architecture and os. When Digital cut his funding
in 1988, Microsoft scored a coup by hiring him and 20 of his fellow digital
engineers to design a new OS with the OS/2 API as its primary interface to
succeed OS/2. With the relative success of Windows 3.0 and the falling out
with IBM in 1990, NT was retargeted to support the Win32 API as its primary
interface and provide a migration path from the Win16 API. On a lower
priority was support for portions of DOS, OS/2, and POSIX. All these API's
were ported to the undocumented native nt api and are used and executed in
user mode. They can't access hardware directly, another process' memory, or
kernel memory except via calls to the underlying NT native api.

Factoid: If you increment the ASCII value of each letter in VMS you get WNT
(Windows New Technology).

As I've already said, NT may not have sprung fully formed like Athena from
the mind of Zeus... but it isn't derived from DOS/Win16. If anything it's
derived from VMS.

> in the "DOS shell". I guess it really all depends on how you
> want to define DOS. I define DOS based on the actual codebase
> and not the functionality.

DOS stands for Disk Operating System. It is a self-hosting operating system
that runs on x86 platforms. If it isn't an operating system it isn't DOS.
CMD.exe isn't an operating system. CMD.exe is the implementation of an NT
native command shell which is remniscent of DOS' command shell. But it is
not DOS.

I don't know what code you think you've examined, but NT is not derived from
DOS.

> The latest "cmd/command" shell is no
> stranger to me, nor is more powerful than the last DOS version I
> ran. So I say cmd.exe or command.com whichever one you want to
> refer to is not a far cry from old DOS. I may be a Linux guy, but
> I make my living on Windows machines utilizing extensive "DOS"
> functionality, dating back to 3.1 and NT 3.5. By the way you
> won't find cmd.exe stock on 98, but it can be installed. I still
> find M$'s version of "DOS" lacking.

You won't find CMD.EXE on 95 or 98 because they are not self-hosting
operating systems. I.e., they run on top of DOS. This is not the case for
NT, XP, W2K, or W2K3. The latter are all self-hosting OS's derived from the
NT codebase.

I've recently had to write an update mechanism to allow my employer to
automate the application of service packs, patches, and hotfixes to customer
machines we support in the field using only the software that was already
installed. I've written batch scripts as way back as MSDOS 3.3, and I have
to say it is much easier to write cleaner batch scripts with greater ease
and functionality than it ever was under DOS.

--
Garrett Goebel
IS Development Specialist

ScriptPro                   Direct: 913.403.5261
5828 Reeds Road               Main: 913.384.1008
Mission, KS 66202              Fax: 913.384.2180
www.scriptpro.com          garrett at scriptpro dot com