On Tue, 03 Jan 2006 22:58:19 GMT, Cool_X
Because modern hardware meets NT's requirements and the
need for DOS and Win16 support has faded away, development of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Win9x family ceased and NT was re-positioned to replace it as XP.
Really?
"Doctor DOS' DOS Site" (not my site) is the most popular site at my ISP:
http://www.chebucto.ns.ca/~ak621/DOS/index.html[/QUOTE]
I can think of three aspects to "DOS":
1) Running legacy apps written for DOS
This is what I wasreferring to above. In Win9x DOS apps run each in
thier own VM with Win9x asthe kernel, and that means the DOS app gets
(deep breath): native XMS, EMS, DPMS (but not UMB) memory management
including virtual memory, native LAN, mouse, CD-ROM, VESA and sound
support, dynamic disk caching and fileshare management, ability to
shell Windows apps, LFN support if the "DOS" app supports that (rare
unless it's part of Win9x DOS file set) and...er, other stuff that
I've listed before but can't remember now.
It can be suprising how well this works! Sometimes I have DOS games
that crash or don't have sound in DOS mode, that work in Win9xGUI
mode, and I could run DOS games that "need 8M RAM" in Win9x GUI with
8M RAM while leaving apps like Word open. Yes, this probably worked
by flushing everything else to disk and scaling down the dynamic disk
cache, but in DOS mode I'd have had to manually parameter SmartDrv to
use a lower memory allocation or the game would not work.
Another mind-boggling example from the first days of Win95; I ran
Terminate, which was a DOS terminal emulator that allowed arbitrary
DOS apps to be shelled while swapping itself out via its own
proprietary paging-to-disk scheme. This locked uphard in Win3.yuk,
but in Win95 it not only ran, but I could hotkey-launch Windows apps
like Excel fromwithin the DOS app, as well as choose whether to launch
DOS apps within the same window or in separate windows (and thus
seperate VMs that Win95 would pre-emptively multi-task.
But all of this beautiful compatibility also meant allowing the DOS
app to access hardware directly, and that could lock up the system,
even when the same DOS app worked in DOS mode (e.g. Lap Link 3 when
used to transfer data via parallel port). This is the stability gain
that NT enjoys, at the expense of affected DOS apps (including almost
all games) silently aborting when run within NT/W2000/XP.
When computational power and resources become n times stonger than an
old environment that is to be supported, as is the case with DOS and
XP, it may be better to emulate the environment (as if it was an alien
one, like aZX Spectrum) rather than support it directly. Not only
does this avoid the stability/compatibility (pick one) problem, the
extra power can be used to pad timings so that old apps that would
crash because timing loops overrun or RAM is "too big" and wraps
around, would be more likely to work.
2) Command Line Interface
This is what your URL is all about. The strength of the CLI is that
if you know how to do something interactively, you also know how to do
it programmatically (i.e. via a batch file). The strength of the GUI
is that if you don't know how to do something, you can bluff along
asyou go by clicking on what is offered to you.
The trouble with GUI is that if you want to automate something
programatically, nothing you have learned will help you at all. Yes,
there are "visual" macro recorders etrc. but while this approach is
great for UI design, it doesn't help with coding logic.
There are three sets of free scripting languages in modern Windows.
First, there are the WSH scripting languages, which I bounced off as
being tough to learn. You can't just jump in and do stuff, without
defining objects and blah blah blah first, and that's a learning curve
that normal batch skills do not not help you climb.
Second, there's the NT-enhanced batch language, which really goes
quite far to make this into something you can really do things with.
You can derive poath segments of an object, do string slicing, input
values from the command line and so on...but only in NT/W2000/XP.
Third, there's the original DOS batch language as implimented in
Win9x, and while this has a few nice additions (Long File Names, the
Start and Start /W commands, etc.) it's still quite limited.
CLI is alive and well in NT/W2000/XP, for all three of these languages
as well as for interactive use. When the shell gets bloated, polluted
or is just plain buggy (Win9x + IE 6), a CLI window is where you can
get things done interactively, often faster than the GUI.
3) Maintenance OS (mOS)
This is my primary concern, and the only one that requires DOS to run
asan OS, rather than as a process under Windows with Windows as the
(superior) underlying kernel.
As an OS, DOS (mode) is dying because current hardware is either
invisible to it (optical writers, USB sticks, Windows printers, NTFS)
or is dangerously incompatible with it (HD > 137G, Long File Names).
The only reason we still seek to use it, is because nothing better
exists as provided with XP. Today's premier mOS is Bart PE, but it's
non-trivial to walk someone through setting this up, along with
RunScanner and plugins for the Windows tools they'd want to use.
http://cquirke.mvps.org/whatmos.htm covers that; it was written before
I really grokked Bart, so it understates how useful Bart really is.
As OS versions evolved and users were assumed to be less and less
tech-savvy, I've watched the maintainability of Windows get
progressively worse, until it is all but unsalvangeable.
From being able to spawn bootable diskettes at will, we now have no
non-HD bootable OS at all. From interactive Scandisk we have
descended to auto-fixing AutoChk and "trust me" ChkDsk, with an UI
dating from the DOS 5 stone age. Even the paltry ability to
re-install the OS (complete with incompitencies in creating large
FAT32 violumes) is broken as soon as Service Pack is installed,
because you cannot generate a replacement up-to-date installation CD.
And when it comes to salvaging data or a complete installation, it
gets worse - XP can't survive a file-level copy from one HD to
another, PnP's itself to death if the mobo changes, will probably
refuse to work (Product Activation) in such circumstances, and there
is a dearth of data recovery and manual repair tools for NTFS.
Finally, the very common need to exclude and manage active malware is
not addressed at all. Safe Mode is less safe (i.e. runs more
integrations) than it was in Win9x, and there's no mOS to host formal
virus scanning and cleanup procedures.
By now, we have Bart, but it's not a no-brainer and is seldom
recommended here because it's "too difficult". It's like "well, you
really need surgery to remove that malignant melanoma, but that's 'too
difficult' to explain from the cosmetics counter, so try this
skin-color cream that will hide it instead".
When Vista comes out, one expects Bart to be no longer compatible;
NTFS will have grown new and structurally-undocumented "features", for
one thing. One truly hopes this time the hood won't be welded shut,
and we will have a spare wheel in the trunk - i.e. a non-HD-booted mOS
---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
