MS and security: good effort but no cigar

[mar]

MS and security: good effort but no cigar
By Mark Burnett, SecurityFocus
Published Wednesday 23rd February 2005 10:42 GMT
http://www.theregister.co.uk/2005/02/23/ms_security_issues/

Last week I watched the webcast of Bill Gates speaking at the RSA
conference in San Francisco. He talked about Microsoft's plans to
build upon the progress it's already made in security. These plans
included better protection against spyware and spam. Gates also
announced Microsoft's intention to release Internet Explorer 7,
complete with a number of security improvements, by the end of this
year.

Looking back, the company has indeed made notable progress in the
security of its software. Windows XP SP2 is a significant achievement,
and Gates reported that over 170 million people have downloaded the
update. The low-hanging fruit of millions of insecure Windows machines
is rapidly falling from the tree.


But we're not out of the woods yet. If you can gain any user access to
a Windows system, it is still surprisingly easy to completely own that
box. So far, these problems have been overshadowed by the countless
remote holes we've seen in recent years, but privilege escalation by
authorized users is an important issue today that is still too easy to
exploit.

Take, for example, the way that Windows handles file paths with
spaces. Suppose that you want to run the following command:

C:\Program Files\Internet Explorer\iexplore

One cool thing about Windows is that although the path contains a
space, it still runs the application fine, even if you don't place
quotes around the entire command and even if you don't use the
executable extension for iexplore.exe.

But how does Windows know where the program path ends and the
program's command line parameters begin? How does it know that the
user isn't trying to run a program named "C:\Program.exe" with the
parameter "Files\Internet Explorer\iexplore?"

The problem is that it doesn't know. It just starts at the beginning
and tries finding an executable until it finds a match. So in this
case, it will try these files every time you run the command:

C:\Program.exe
C:\Program Files\Internet.exe
C:\Program Files\Internet Explorer\iexplore.exe

You might see where I'm going with this: if you place an executable
named program.exe in the root directory, it will probably end up
running quite a bit. In fact, it will run anytime Windows launches a
Program Files executable that does not have quotes around the path.

Microsoft certainly is aware of this issue. In fact, it was probably a
design decision at some point. If you run Windows XP, try placing an
executable named program.exe and reboot your system. When it restarts,
Windows will warn you about the complications of having that file
there.

Here's the problem: there are thousands of paths in the registry that
do not have quotes around them, and many Windows systems have weak
NTFS permissions that allow any user to write to the root directory.
This is bad. As an experiment, I created a small program that simply
logged every time it ran and under what user context. I rebooted and
checked my Event Log. It turned out that on my system it ran eight
times, twice under the context of the SYSTEM account and the rest as
my own administrative account.

Of course, I got the message box warning of the file, so I made a
slight modification to my program.exe. It turns out there is a
registry key that you can set to turn off this warning. I simply
change that setting every time my program runs. Since the first couple
instances executed before I even logged in, there was no warning at
all. And of course, there are plenty other executable name variations
that Windows does not check.
Criminals get smarter

This could be a serious issue, and it's not the only one. Another
weakness is all the batch files and scripts that administrators use.
Sure, scripts are convenient, but you must take care to protect these
files. Too many administrators leaving them laying around in
directories where Everyone has write access to the files. All an
attacker with low-privileged access needs to do is add their code of
choice to the end of your script and it runs under your security
context the next time you use the script.

Fortunately, Windows allows you to enforce script signing policies,
but there is no way to enforce signing of a batch file. You must also
protect files such as .reg, and .inf that an attacker might exploit.
If you use scripts on your servers, make sure they have strong NTFS
permissions.

Then there's the issue of poorly secured server applications. In my
experience, third party Windows mail servers are particularly
vulnerable. Some let you run code based on an email message, use
executable auto-responders, and execute external virus and filtering
applications. But what happens if the user is able to run any
application of choice?

I have seen many, many mail server directories that allow all users
full control over the files in that directory. Sometimes it's the mail
server installer that does this and sometimes it is the
administrator's fault. Some mail servers even require loose
permissions for some user features to work properly.

This means that regular users can modify these settings and send
themselves an email to get executables running in the context of the
mail server's service - which is often the SYSTEM account. Obviously,
I'm oversimplifying what's involved here, but take a close look at the
file permissions for your server applications. Can users get the
server to run their code?

Depending on your server, you should even consider denying all access
to any account besides the service account. Too many server
applications store user passwords using weak encryption and all an
attacker might need is Read access to that file. Many of these flaws
are well known, and there are many more that are still not publicly
known. Most users do not need Read access to these files.

So far, I have only scratched the surface. There are problems with FTP
client apps storing passwords, browser issues, auto run issues, and of
course, the serious problems of physical server access. We have raised
the bar some, but we are nowhere near done. If you have any access to
a system, you can likely gain administrative access.

Sure, Microsoft is eliminating the low-hanging fruit. But what happens
when there is no more low-hanging fruit? Crime doesn't stop because it
is harder. Criminals get smarter. The question is, will we be ready
when that time comes?

Copyright © 2004,

Mark Burnett is an independent researcher, consultant, and writer
specializing in Windows security. He is the author of Hacking the
Code: ASP.NET Web Application Security (Syngress), co-author of the
best-selling book Stealing The Network: How to Own the Box (Syngress),
and co-author of Maximum Windows 2000 Security (SAMS Publishing). He
is a contributor and technical editor for Special Ops: Host and
Network Security for Microsoft, UNIX, and Oracle. Mark speaks at
various security conferences and has published articles in Windows IT
Pro Magazine (formerly Windows & .NET Magazine), Redmond Magazine,
Information Security, Windows Web Solutions, Security Administrator
and various other print and online publications. Mark is a Microsoft
Windows Server Most Valued Professional for Internet Information
Services.

 

[Dan]

The core of XP PRO is based upon a command.com (cmd.com) prompt within a DOS
(Disk Operating System) emulator that is encassed within a DOS shell.
Microsoft saved money by making NT (New Technology) without a new maintenance
operating system. The NT (Not There) according to Microsoft's own techs.
according to a history book on Microsoft said that it was "crazy" to do it
this way but they had orders and were not about to break them. As you can
see a true hacker can attack the false MS-DOS core because it is insecure.
At least 98SE based upon 9x source code has a true solid core that is based
upon real DOS but with less capabilities. Some commands were removed instead
of Microsoft updating them Microsoft saved money by just removing them.
Parts of the NT (New Technology) source code have already been leaked out
over the internet. This is not the case with 9x source code. It has not
been leaked and the core is more stable than NT (XPPRO, XPHOME, 2000, etc.)
Also, 98SE is easier to understand. Sure it does not have as many services
but that means less points of entry for hackers to attack. I do not
understand why people will not accept this. Microsoft XP PRO. is not secure.
Its foundation is built upon sand and not rock. Microsoft needs to build a
brand new maintenance operating system and stear clear of DOS with Longhorn
or successors. DOS and 9x must either continue as a Classics line that
Microsoft could continue to get revenue from or be sold or given to the
open-source community for the good of all mankind. Have a nice day and I
look forward to hearing from you.
: MS and security: good effort but no cigar
: By Mark Burnett, SecurityFocus
: Published Wednesday 23rd February 2005 10:42 GMT
: http://www.theregister.co.uk/2005/02/23/ms_security_issues/
:
: Last week I watched the webcast of Bill Gates speaking at the RSA
: conference in San Francisco. He talked about Microsoft's plans to
: build upon the progress it's already made in security. These plans
: included better protection against spyware and spam. Gates also
: announced Microsoft's intention to release Internet Explorer 7,
: complete with a number of security improvements, by the end of this
: year.
:
: Looking back, the company has indeed made notable progress in the
: security of its software. Windows XP SP2 is a significant achievement,
: and Gates reported that over 170 million people have downloaded the
: update. The low-hanging fruit of millions of insecure Windows machines
: is rapidly falling from the tree.
:
:
: But we're not out of the woods yet. If you can gain any user access to
: a Windows system, it is still surprisingly easy to completely own that
: box. So far, these problems have been overshadowed by the countless
: remote holes we've seen in recent years, but privilege escalation by
: authorized users is an important issue today that is still too easy to
: exploit.
:
: Take, for example, the way that Windows handles file paths with
: spaces. Suppose that you want to run the following command:
:
: C:\Program Files\Internet Explorer\iexplore
:
: One cool thing about Windows is that although the path contains a
: space, it still runs the application fine, even if you don't place
: quotes around the entire command and even if you don't use the
: executable extension for iexplore.exe.
:
: But how does Windows know where the program path ends and the
: program's command line parameters begin? How does it know that the
: user isn't trying to run a program named "C:\Program.exe" with the
: parameter "Files\Internet Explorer\iexplore?"
:
: The problem is that it doesn't know. It just starts at the beginning
: and tries finding an executable until it finds a match. So in this
: case, it will try these files every time you run the command:
:
: C:\Program.exe
: C:\Program Files\Internet.exe
: C:\Program Files\Internet Explorer\iexplore.exe
:
: You might see where I'm going with this: if you place an executable
: named program.exe in the root directory, it will probably end up
: running quite a bit. In fact, it will run anytime Windows launches a
: Program Files executable that does not have quotes around the path.
:
: Microsoft certainly is aware of this issue. In fact, it was probably a
: design decision at some point. If you run Windows XP, try placing an
: executable named program.exe and reboot your system. When it restarts,
: Windows will warn you about the complications of having that file
: there.
:
: Here's the problem: there are thousands of paths in the registry that
: do not have quotes around them, and many Windows systems have weak
: NTFS permissions that allow any user to write to the root directory.
: This is bad. As an experiment, I created a small program that simply
: logged every time it ran and under what user context. I rebooted and
: checked my Event Log. It turned out that on my system it ran eight
: times, twice under the context of the SYSTEM account and the rest as
: my own administrative account.
:
: Of course, I got the message box warning of the file, so I made a
: slight modification to my program.exe. It turns out there is a
: registry key that you can set to turn off this warning. I simply
: change that setting every time my program runs. Since the first couple
: instances executed before I even logged in, there was no warning at
: all. And of course, there are plenty other executable name variations
: that Windows does not check.
: Criminals get smarter
:
: This could be a serious issue, and it's not the only one. Another
: weakness is all the batch files and scripts that administrators use.
: Sure, scripts are convenient, but you must take care to protect these
: files. Too many administrators leaving them laying around in
: directories where Everyone has write access to the files. All an
: attacker with low-privileged access needs to do is add their code of
: choice to the end of your script and it runs under your security
: context the next time you use the script.
:
: Fortunately, Windows allows you to enforce script signing policies,
: but there is no way to enforce signing of a batch file. You must also
: protect files such as .reg, and .inf that an attacker might exploit.
: If you use scripts on your servers, make sure they have strong NTFS
: permissions.
:
: Then there's the issue of poorly secured server applications. In my
: experience, third party Windows mail servers are particularly
: vulnerable. Some let you run code based on an email message, use
: executable auto-responders, and execute external virus and filtering
: applications. But what happens if the user is able to run any
: application of choice?
:
: I have seen many, many mail server directories that allow all users
: full control over the files in that directory. Sometimes it's the mail
: server installer that does this and sometimes it is the
: administrator's fault. Some mail servers even require loose
: permissions for some user features to work properly.
:
: This means that regular users can modify these settings and send
: themselves an email to get executables running in the context of the
: mail server's service - which is often the SYSTEM account. Obviously,
: I'm oversimplifying what's involved here, but take a close look at the
: file permissions for your server applications. Can users get the
: server to run their code?
:
: Depending on your server, you should even consider denying all access
: to any account besides the service account. Too many server
: applications store user passwords using weak encryption and all an
: attacker might need is Read access to that file. Many of these flaws
: are well known, and there are many more that are still not publicly
: known. Most users do not need Read access to these files.
:
: So far, I have only scratched the surface. There are problems with FTP
: client apps storing passwords, browser issues, auto run issues, and of
: course, the serious problems of physical server access. We have raised
: the bar some, but we are nowhere near done. If you have any access to
: a system, you can likely gain administrative access.
:
: Sure, Microsoft is eliminating the low-hanging fruit. But what happens
: when there is no more low-hanging fruit? Crime doesn't stop because it
: is harder. Criminals get smarter. The question is, will we be ready
: when that time comes?
:
: Copyright © 2004,
:
: Mark Burnett is an independent researcher, consultant, and writer
: specializing in Windows security. He is the author of Hacking the
: Code: ASP.NET Web Application Security (Syngress), co-author of the
: best-selling book Stealing The Network: How to Own the Box (Syngress),
: and co-author of Maximum Windows 2000 Security (SAMS Publishing). He
: is a contributor and technical editor for Special Ops: Host and
: Network Security for Microsoft, UNIX, and Oracle. Mark speaks at
: various security conferences and has published articles in Windows IT
: Pro Magazine (formerly Windows & .NET Magazine), Redmond Magazine,
: Information Security, Windows Web Solutions, Security Administrator
: and various other print and online publications. Mark is a Microsoft
: Windows Server Most Valued Professional for Internet Information
: Services.

 

[SlowJet]

Well Dan, wishfull thinking isn't going to change the facts of life, and
even thou there is a full Moon in Virgo perfecting DOS and 9x is way down on
the list of needs from things like a longer lasting light buld (coz we all
known there the GE bulbs are designed to burn out easily so you need to by
more. Up on a Gov building on Vancover Is. they have bulds still burning
that are 130 years old. I bought some of those 10 years bulds from the
handicap people. I was impressed that they did last over a year.)

Aside from rewriting history in one's own likeness, lol, how about just
hammering on about the basics.

Secure strong passowords, run under a user account for regular work. Two way
Firewall with as many ports close as possible, to the point of a little
inconvience. AV software, two kinds, one for the input streem, one for files
system and e-mail. Aware and spyware blockers and scanners - run often.

And last but not least, no fat, no dos, no multiboot.

The beat goes on,

SJ

 

[Sam]

Apparently, _SlowJet_, on 23/02/05 15:29,typed:

And last but not least, no fat, no dos, no multiboot.

Why no multiboot?

Sam.

 

[Dan]

My guess is that it is more difficult to make a multiboot environment secure
but if the user has the time and expertise it is not a problem.

: Apparently, _SlowJet_, on 23/02/05 15:29,typed:
: <SNIP>
: >
: > And last but not least, no fat, no dos, no multiboot.
: >
:
:
: Why no multiboot?
:
: Sam.
:
: --
: Please remove the underscores ( the '_' symbols) from my email address
: to obtain the correct one. Apologies, but the fudging is to remove spam.

 

[Steve N.]

The core of XP PRO is based upon a command.com (cmd.com) prompt within a DOS
(Disk Operating System) emulator that is encassed within a DOS shell.

Sorry Dan, but this is wrong. For one thing it's CMD.EXE not CMD.COM.

XP is based on the NT kernel which is NOT any sort of DOS, never has
been, and there is no "DOS shell" in XP. Command.com (16-bit) and
cmd.exe (32-bit) are command line interfaces to NT, not DOS. They have
the equivalent of DOS-type file system commands that are applicable to
NT and maintain reporting of a DOS version to make them compatible with
DOS programs that query the OS for the DOS version prior to execution.
The only smidgen of actual DOS in XP is the ability to create an MS-DOS
startup floppy, which is Windows ME DOS, by the way.

Steve

 

[Dan]

Sorrry, Steve N. You have been falsely led astray. Here topic on
information for Chris Quirke, MVP, myself, PCR and Gary S. Terhune. Here is
the Truth and the Truth will Set you Free:

">For myself, in answer to your question, the Windows NT paradigm, as

defined by Microsoft, seems to be that you keep a lot of backups, and
use the tools provided, without providing low-level access of the sort
that allows detailed mucking about and user-control. Partly, or even
mostly, in the name of security. There are very few people that are
interested in spending a day or two rebuilding an NTFS file system bit
by byte. Most people prefer to let Windows attempt the fix, and if that
doesn't get it done, trash the system and restore from backup. I can't
say that I'm all that much against this paradigm.

I am, because NT fails to be maintainable in this way as well.

End users typically have 1 (one) PC that contains everything they
have. It's set up interactively on an ad-hoc basis. It's typically
budget hardware, and may have nil but a 1.44M drive for "backup".

For you to say "stuff maintenance, let the end user just wipe,
re-install and restore data backups", a number of things would have to
be in place - and as things are, they are not:

1) Working installation OS CD

OEMs often provide CDs that don't respect user's choice of
partitioning, installation paths etc. or they don't provide a CD at
all. As it is, the OS CD you get may be invalidated by SPs.

A properly installable OS CD, supporting custom installation that is
managed through a nice UI, is the starting point. Beyond that, one
would expect this CD to be updated with patches and hotfixes, but as
it is, you can install an SP that breaks the compatibility of the
installation CD, and doesn't offer to build a replacement.

Once you start talking about keeping installation CDs updated, you
open the door to malware infection. It's not a winnable scenario,
which is why I don't take it seriously as an alternative to
maintenance, but let's see howfar we can get with it.

2) Proper scoping of material

To "just" re-install and then restore data, you have to have clear
scoping between what is code and what is data. MS is groping towards
this (e.g. FAST and SR) but they are at the foot of the clue mountain.

How should content be scoped?
That is answered by: Why would you need to rebuild the system?

Hardware failure/replacement
- scope in OS code, user settings, data and external material
- scope out hardware-specific drivers etc.
Malware infestation
- scope in known-good original code (updates?)
- scope out all other code
- scope in user data (and settings?)
- scope out incoming material
Redeployment
- scope in code, hardware-specifics, ?baseline settings
- scope out user data and incoming material

MS has no clue on separating incoming material (that is likely to be
malware) from data; consider .PST, "My Recieved Files", advice to save
downloaded .EXE in "My Documents" to avoid SR activity, etc. not to
mention the pervasiveness of autorunning macros and scripts in "data"
such as document files and email "message text".

MS also routinely binds data to application version, and application
version to OS or other large-lump product version (OE and OS, Outbreak
and Office, even long-life databases get file-versioned with new
versions of Access). Even MS's Backup utility spawns backups that
often cannot be restored by other OS versions.

3) Rational data sets

Assuming there's enough clue for a data set to be identified that
contains no malware, version- or hardware-bound code, etc., it helps
if this data can be easily backed up. This is far from the case with
Windows, where large Music and Pictures objects are embedded in the
data set, and MSware data resides outside the data set (e.g. is it
Application Data, or Local Settings\Application Data, this time?)

If you were to try to dump everything in "Documents and Settings" to
CDRW (assuming you have a CDRW drive, assuming it would fit) then this
would fail, because MS nests the CD writing workspace within this
subtree, along with temp and hugely bloated web caches.

4) The mythical "Full System Backup"

Ignoring for a moment the likelyhood that whatever infected or messed
up the systrem, may also be present in the "full system backup",
there's the problem with *doing* a full system backup that will
actually restore. It has to fit on backup storage, for one thing, and
there has to be an app that can reate it (which XP Home lacks; OEM CDs
may not even have Backup at all), and there has to be a stub OS that
can restore it (said stub OS being so similar to a mOS, you may as
well dev a mOS and addrsess both roles at once).

5) Backup devices and capacities

Even today, many home systems do not come with a backup device capable
of backing up even a small data set that's scoped down to Office
documents alone. Where are these backups going to come from?


So, in summary: "Just wipe and rebuild" is NEVER an acceptable
substitute in consumerland. It only works in pro-IT land because
pro-IT has larger resources (e.g. data concentrated on servers) and
professional administration (i.e. it's someone's job to make backups
and to defend the server against attack).

In essence, this approach is basically saying "FOAD" to consumers, and
as consumers, we should reject it as such.

-------------------- ----- ---- --- -- - - - -

Hmmm... what was the *other* idea?

--------------------

You asked for it. LOL!!
















: Dan wrote:
: > The core of XP PRO is based upon a command.com (cmd.com) prompt within a
DOS
: > (Disk Operating System) emulator that is encassed within a DOS shell.
:
: Sorry Dan, but this is wrong. For one thing it's CMD.EXE not CMD.COM.
:
: XP is based on the NT kernel which is NOT any sort of DOS, never has
: been, and there is no "DOS shell" in XP. Command.com (16-bit) and
: cmd.exe (32-bit) are command line interfaces to NT, not DOS. They have
: the equivalent of DOS-type file system commands that are applicable to
: NT and maintain reporting of a DOS version to make them compatible with
: DOS programs that query the OS for the DOS version prior to execution.
: The only smidgen of actual DOS in XP is the ability to create an MS-DOS
: startup floppy, which is Windows ME DOS, by the way.
:
: Steve

 

[Dan]

I can't disagree that a better job should be done in backup sciences.
But backup really is the only way to *assure* personal data safety at a
reasonable cost. Yes, an expert can probably recover most data from a
messed up system, but at an extraordinary cost compared to a decent
backup solution, or even compared to a new system altogether. In
reality, the *cheapest* solution for home users with little knowledge of
low-level architecture and a desire to do it themselves is to make the
installed OS and applications set a throwaway item. Home users are
likely to prefer a few hours of their own time spent in reinstalling
OS\Apps from scratch and then restoring personal data if it's made
relatively painless. (Note that I do not include Settings in this
discussion--While certain "personal" settings might well be no problem
to backup and restore, I generally assume that settings themselves are
likely candidates for having caused whatever problem led to the decision
to trash. Thus, a return to defaults is preferable (granting that better
default choices are another arena where I see a need for substantial
rethinking.)

On that score, I agree that OEMs and MS itself could do a *much* better
job of organizing systems and storage with backup/restore capabilities
that functioned efficiently.

As evidenced by your description of an ideal "maintenance OS" in your
reply to Dan, anyone who is capable of making good use of such a tool
would necessarily be a pro. Heck, anyone with the ability to use MS-DOS
in a 9x system in order to seek and repair file system damage of any
great extent would necessarily be a pro. In the home PC arena, that
translates to a *lot* of money relative to their overall computer
budget..

I agree with much of what you've described, particularly if such specs
are developed into a true Safe Mode for NT-based systems. And, of
course, a true mOS such as you describe would be a great boon to pros
and users who hire pros, by providing more cost-efficient repair
procedures when trash/restore isn't the preferred option (or possible at
all.)

But bottom line best option for home users is to make a trash/restore
paradigm work well. If a system is that far gone that existing tools
can't repair it, it's either due to fried hardware or to a hopelessly
compromised operating code. Either one isn't likely to lend itself to
inexpensive repair.

--
Gary S. Terhune
MS MVP Shell/User
http://www.grystmill.com/articles/cleanboot.htm
http://www.grystmill.com/articles/security.htm

On Sat, 12 Feb 2005 19:51:39 -0800, "Gary S. Terhune"


I am, because NT fails to be maintainable in this way as well.

End users typically have 1 (one) PC that contains everything they
have. It's set up interactively on an ad-hoc basis. It's typically
budget hardware, and may have nil but a 1.44M drive for "backup".

For you to say "stuff maintenance, let the end user just wipe,
re-install and restore data backups", a number of things would have to
be in place - and as things are, they are not:

1) Working installation OS CD

OEMs often provide CDs that don't respect user's choice of
partitioning, installation paths etc. or they don't provide a CD at
all. As it is, the OS CD you get may be invalidated by SPs.

A properly installable OS CD, supporting custom installation that is
managed through a nice UI, is the starting point. Beyond that, one
would expect this CD to be updated with patches and hotfixes, but as
it is, you can install an SP that breaks the compatibility of the
installation CD, and doesn't offer to build a replacement.

Once you start talking about keeping installation CDs updated, you
open the door to malware infection. It's not a winnable scenario,
which is why I don't take it seriously as an alternative to
maintenance, but let's see howfar we can get with it.

2) Proper scoping of material

To "just" re-install and then restore data, you have to have clear
scoping between what is code and what is data. MS is groping towards
this (e.g. FAST and SR) but they are at the foot of the clue mountain.

How should content be scoped?
That is answered by: Why would you need to rebuild the system?

Hardware failure/replacement
- scope in OS code, user settings, data and external material
- scope out hardware-specific drivers etc.
Malware infestation
- scope in known-good original code (updates?)
- scope out all other code
- scope in user data (and settings?)
- scope out incoming material
Redeployment
- scope in code, hardware-specifics, ?baseline settings
- scope out user data and incoming material

MS has no clue on separating incoming material (that is likely to be
malware) from data; consider .PST, "My Recieved Files", advice to save
downloaded .EXE in "My Documents" to avoid SR activity, etc. not to
mention the pervasiveness of autorunning macros and scripts in "data"
such as document files and email "message text".

MS also routinely binds data to application version, and application
version to OS or other large-lump product version (OE and OS, Outbreak
and Office, even long-life databases get file-versioned with new
versions of Access). Even MS's Backup utility spawns backups that
often cannot be restored by other OS versions.

3) Rational data sets

Assuming there's enough clue for a data set to be identified that
contains no malware, version- or hardware-bound code, etc., it helps
if this data can be easily backed up. This is far from the case with
Windows, where large Music and Pictures objects are embedded in the
data set, and MSware data resides outside the data set (e.g. is it
Application Data, or Local Settings\Application Data, this time?)

If you were to try to dump everything in "Documents and Settings" to
CDRW (assuming you have a CDRW drive, assuming it would fit) then this
would fail, because MS nests the CD writing workspace within this
subtree, along with temp and hugely bloated web caches.

4) The mythical "Full System Backup"

Ignoring for a moment the likelyhood that whatever infected or messed
up the systrem, may also be present in the "full system backup",
there's the problem with *doing* a full system backup that will
actually restore. It has to fit on backup storage, for one thing, and
there has to be an app that can reate it (which XP Home lacks; OEM CDs
may not even have Backup at all), and there has to be a stub OS that
can restore it (said stub OS being so similar to a mOS, you may as
well dev a mOS and addrsess both roles at once).

5) Backup devices and capacities

Even today, many home systems do not come with a backup device capable
of backing up even a small data set that's scoped down to Office
documents alone. Where are these backups going to come from?


So, in summary: "Just wipe and rebuild" is NEVER an acceptable
substitute in consumerland. It only works in pro-IT land because
pro-IT has larger resources (e.g. data concentrated on servers) and
professional administration (i.e. it's someone's job to make backups
and to defend the server against attack).

In essence, this approach is basically saying "FOAD" to consumers, and
as consumers, we should reject it as such.



Hmmm... what was the *other* idea?

: Dan wrote:
: > The core of XP PRO is based upon a command.com (cmd.com) prompt within a
DOS
: > (Disk Operating System) emulator that is encassed within a DOS shell.
:
: Sorry Dan, but this is wrong. For one thing it's CMD.EXE not CMD.COM.
:
: XP is based on the NT kernel which is NOT any sort of DOS, never has
: been, and there is no "DOS shell" in XP. Command.com (16-bit) and
: cmd.exe (32-bit) are command line interfaces to NT, not DOS. They have
: the equivalent of DOS-type file system commands that are applicable to
: NT and maintain reporting of a DOS version to make them compatible with
: DOS programs that query the OS for the DOS version prior to execution.
: The only smidgen of actual DOS in XP is the ability to create an MS-DOS
: startup floppy, which is Windows ME DOS, by the way.
:
: Steve

 

[Dan]

Chris and Gary S. Terhune, I plan on writing to Microsoft about your
maintenace operating system for XP PRO. (NT -- New Technology)
based and would like your feedback if there is anything relevant that I
should mention. I love your idea about the maintenance operating system and
I feel that Microsoft took a short cut by using a DOS-Based emulator through
a command.com prompt and not developing a new maintenance operating system.

Prepare yourself for problems when you mentionthe word "DOS"
It's very easy to mis-mesh with the folks you'd be talking to.

For example, the moment you say "DOS", listeners will start thinking
about the things they will say when you stop talking; like "DOS is too
old to manage modern hardware" and so on. So they miss what you're
actually saying, and react to what they expected you to say.

Some folks want DOS because they want thier old DOS programs to work,
and if you mention "emulated DOS" (cmd.exe etc.) then you will raise
that expectation. But it's often the DOS apps themselves, rather than
the accuracy of the emulation, that fail on new systems. In fact, an
even more virtual emulation - right down to creating an artificially
slow processing speed with comparitive instruction timings similar to
earlier processes - may be required. Emulating a 40MHz 386DX
environment may almost be like emulating a ZX Spectrum, or Amiga.

OTOH, what I want is to be able to do the things I would normally have
used DOS to do. It's not "DOS" I want, such as a maintenance OS that
shares some of DOS's broad characteristics. I'd like that mOS to be
as similar to (and as familiar as) XP as possible, so a cut-down XP
would be fine. But if it uses Explorer at all, it would have to have
a lot of Explorer's functionality suppressed.


A maintenance OS has to be safe in adversity; both when running on
flaky hardware, and within a flaky or malicious software environment.

A mOS should never "move ahead" of the user who is doing the
maintenance. It should always be the user, not the OS, that initiates
first use of a hardware or software item. This is a crucial concept
for both hardware and software risks.


To cope with bad hardware, a mOS would depend upon a small subset of
everything that could be available. This also reduces driver issues,
the volume of code that has to run (which could be naturally
corrupted) and the possibility of running malware.

Not "moving ahead" of the user means not writing to HD *at all* except
when the user initiates a write. That implies the whole OS and
workspace has to fit in RAM, with no paging or Temp writes to disk.

It also means that the OS shouldn't access volumes that are not
accessed by the user. I might have a sick and dying HD, where C: is
so full of errors that any attempt to read the core file system will
wander off into endless retry loops, but all I want to do is read one
directory full of files from D:. The mOS should not touch C: at all
(unless I touch it - and I won't) and should only access D: as far as
I do; read the root to find the dir, and then read the files inside
only when I tell it to copy that dir off somewhere else.

The OS should also never "touch" the contents of files, unless I
explicitly initialte that via a copy or "open". It shouldn't even
pull icons out of shortcuts and executables that normally self-define
these. I may want to recover three files out of a dir full of 200,
and 37 of those 197 irrelevant files may contain bad sectors that bog
down with retries when they are examined to display icons etc.


If the OS applies the above discipline, it's already halfway to being
safer for malware management too. The OS may be exploitable at teh
raw code level, i.e. a defect in icon handling may allow an arbitrary
file to run as raw code when it's "listed". By not probing into
material ahead of the user, the OS reduces such risks.

For malware safety, the mOS should run no code off the HD at all - and
not only at boot, but during navigation of the HD's file systems as
well. It should only "touch" what the user explicitly tells it to. A
perfect mOS would be so HD-independent, that it would be able to boot
and run even if the HD was physically absent.

To manage malware, all file integrations should be editable by the
user, and no files should be barred from access. There's an obvious
trade-off with security and privacy here; many pro-IT installations
would not tolerate such open access. So this level of maintainability
may have to be peculiar to Home (where it's needed!).


Finally, the OS should be small and do very liitle gratuitious
automatic stuff, for another reason: This OS *has* to be fit for use
out of the box, unpatched. To patch a mOS on a regular basis is to
risk infecting it - so you want an initial known-good state that can
be cast in stone and used with confidence.


Much of what is learned in developing a mOS can be usefull ploughed
back into less extreme OS modes of operation. For example, we could
see a "Safe" mode that's considerably safer for malware management
than is currently the case, though still prone to intrafile code
infectors and malware core code "updates".

Even "normal" Windows could gain clue.

For example, new HD volumes might not be automatically read, indexed,
interpreted, have System Restore automatically enabled etc. until the
user has acknowledged the presence of the new volume(s) and indicated
they are (or are not) to be integrated as part of the system.

For another example, you might have a fast and safe "List" view that
becomes the fastest way to see the largest number of file names within
a given window area. No fussing about (x,y) position, or waiting for
icons to be painted in, etc. Just show the names, including the .ext

-- Risk Management is the clue that asks:

"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"

----------------------- ------ ---- --- -- - - - -

: Dan wrote:
: > The core of XP PRO is based upon a command.com (cmd.com) prompt within a
DOS
: > (Disk Operating System) emulator that is encassed within a DOS shell.
:
: Sorry Dan, but this is wrong. For one thing it's CMD.EXE not CMD.COM.
:
: XP is based on the NT kernel which is NOT any sort of DOS, never has
: been, and there is no "DOS shell" in XP. Command.com (16-bit) and
: cmd.exe (32-bit) are command line interfaces to NT, not DOS. They have
: the equivalent of DOS-type file system commands that are applicable to
: NT and maintain reporting of a DOS version to make them compatible with
: DOS programs that query the OS for the DOS version prior to execution.
: The only smidgen of actual DOS in XP is the ability to create an MS-DOS
: startup floppy, which is Windows ME DOS, by the way.
:
: Steve

 

[Sam]

Apparently, _Dan_, on 24/02/05 01:36,typed:

My guess is that it is more difficult to make a multiboot environment secure
but if the user has the time and expertise it is not a problem.

However, if one multiboots with non-Microsoft OSs, it won't be a
problem! I think oftentimes many people forget there are other operating
systems besides Windows.

Sam.

 

[Steve N.]

Sorrry, Steve N. You have been falsely led astray. Here topic on
information for Chris Quirke, MVP, myself, PCR and Gary S. Terhune. Here is
the Truth and the Truth will Set you Free:

That's all well and good but doesn't address what I was saying about DOS
vs. NT that I can see at all.

Steve

 

[Dan]

True, Sam but I am happy with 98SE and XPPRO in my dual-boot with a
customized boot environment. Linux, Unix, Apple are all good alternatives
but one must remember they do not have the market share as of yet. Maybe
someday in the future these companies will be able to challenge Microsoft
thus leading to more computer innovation and more technology for the world
and helping keep the States as a superpower. You can tell I am a techie.
<smile>

: Apparently, _Dan_, on 24/02/05 01:36,typed:
: > My guess is that it is more difficult to make a multiboot environment
secure
: > but if the user has the time and expertise it is not a problem.
:
: However, if one multiboots with non-Microsoft OSs, it won't be a
: problem! I think oftentimes many people forget there are other operating
: systems besides Windows.
:
: Sam.
:
:
: > : > : Apparently, _SlowJet_, on 23/02/05 15:29,typed:
: > : <SNIP>
: > : >
: > : > And last but not least, no fat, no dos, no multiboot.
: > : >
: > :
: > :
: > : Why no multiboot?
: > :
: > : Sam.
: > :
: > : --
: > : Please remove the underscores ( the '_' symbols) from my email address
: > : to obtain the correct one. Apologies, but the fudging is to remove
spam.
: >
: >
:
:
: --
: Please remove the underscores ( the '_' symbols) from my email address
: to obtain the correct one. Apologies, but the fudging is to remove spam.

 

[Dan]

Hopefully the following below will help you and it is which is more secure --
98SE or XPPRO at the core source code level.

: Dan wrote:
:
: > Sorrry, Steve N. You have been falsely led astray. Here topic on
: > information for Chris Quirke, MVP, myself, PCR and Gary S. Terhune. Here
is
: > the Truth and the Truth will Set you Free:
:
: That's all well and good but doesn't address what I was saying about DOS
: vs. NT that I can see at all.
:
: Steve
:
: >
: > ">For myself, in answer to your question, the Windows NT paradigm, as
: >
: >>defined by Microsoft, seems to be that you keep a lot of backups, and
: >>use the tools provided, without providing low-level access of the sort
: >>that allows detailed mucking about and user-control. Partly, or even
: >>mostly, in the name of security. There are very few people that are
: >>interested in spending a day or two rebuilding an NTFS file system bit
: >>by byte. Most people prefer to let Windows attempt the fix, and if that
: >>doesn't get it done, trash the system and restore from backup. I can't
: >>say that I'm all that much against this paradigm.
: >
: >
: > I am, because NT fails to be maintainable in this way as well.
: >
: > End users typically have 1 (one) PC that contains everything they
: > have. It's set up interactively on an ad-hoc basis. It's typically
: > budget hardware, and may have nil but a 1.44M drive for "backup".
: >
: > For you to say "stuff maintenance, let the end user just wipe,
: > re-install and restore data backups", a number of things would have to
: > be in place - and as things are, they are not:
: >
: > 1) Working installation OS CD
: >
: > OEMs often provide CDs that don't respect user's choice of
: > partitioning, installation paths etc. or they don't provide a CD at
: > all. As it is, the OS CD you get may be invalidated by SPs.
: >
: > A properly installable OS CD, supporting custom installation that is
: > managed through a nice UI, is the starting point. Beyond that, one
: > would expect this CD to be updated with patches and hotfixes, but as
: > it is, you can install an SP that breaks the compatibility of the
: > installation CD, and doesn't offer to build a replacement.
: >
: > Once you start talking about keeping installation CDs updated, you
: > open the door to malware infection. It's not a winnable scenario,
: > which is why I don't take it seriously as an alternative to
: > maintenance, but let's see howfar we can get with it.
: >
: > 2) Proper scoping of material
: >
: > To "just" re-install and then restore data, you have to have clear
: > scoping between what is code and what is data. MS is groping towards
: > this (e.g. FAST and SR) but they are at the foot of the clue mountain.
: >
: > How should content be scoped?
: > That is answered by: Why would you need to rebuild the system?
: >
: > Hardware failure/replacement
: > - scope in OS code, user settings, data and external material
: > - scope out hardware-specific drivers etc.
: > Malware infestation
: > - scope in known-good original code (updates?)
: > - scope out all other code
: > - scope in user data (and settings?)
: > - scope out incoming material
: > Redeployment
: > - scope in code, hardware-specifics, ?baseline settings
: > - scope out user data and incoming material
: >
: > MS has no clue on separating incoming material (that is likely to be
: > malware) from data; consider .PST, "My Recieved Files", advice to save
: > downloaded .EXE in "My Documents" to avoid SR activity, etc. not to
: > mention the pervasiveness of autorunning macros and scripts in "data"
: > such as document files and email "message text".
: >
: > MS also routinely binds data to application version, and application
: > version to OS or other large-lump product version (OE and OS, Outbreak
: > and Office, even long-life databases get file-versioned with new
: > versions of Access). Even MS's Backup utility spawns backups that
: > often cannot be restored by other OS versions.
: >
: > 3) Rational data sets
: >
: > Assuming there's enough clue for a data set to be identified that
: > contains no malware, version- or hardware-bound code, etc., it helps
: > if this data can be easily backed up. This is far from the case with
: > Windows, where large Music and Pictures objects are embedded in the
: > data set, and MSware data resides outside the data set (e.g. is it
: > Application Data, or Local Settings\Application Data, this time?)
: >
: > If you were to try to dump everything in "Documents and Settings" to
: > CDRW (assuming you have a CDRW drive, assuming it would fit) then this
: > would fail, because MS nests the CD writing workspace within this
: > subtree, along with temp and hugely bloated web caches.
: >
: > 4) The mythical "Full System Backup"
: >
: > Ignoring for a moment the likelyhood that whatever infected or messed
: > up the systrem, may also be present in the "full system backup",
: > there's the problem with *doing* a full system backup that will
: > actually restore. It has to fit on backup storage, for one thing, and
: > there has to be an app that can reate it (which XP Home lacks; OEM CDs
: > may not even have Backup at all), and there has to be a stub OS that
: > can restore it (said stub OS being so similar to a mOS, you may as
: > well dev a mOS and addrsess both roles at once).
: >
: > 5) Backup devices and capacities
: >
: > Even today, many home systems do not come with a backup device capable
: > of backing up even a small data set that's scoped down to Office
: > documents alone. Where are these backups going to come from?
: >
: >
: > So, in summary: "Just wipe and rebuild" is NEVER an acceptable
: > substitute in consumerland. It only works in pro-IT land because
: > pro-IT has larger resources (e.g. data concentrated on servers) and
: > professional administration (i.e. it's someone's job to make backups
: > and to defend the server against attack).
: >
: > In essence, this approach is basically saying "FOAD" to consumers, and
: > as consumers, we should reject it as such.
: >
: >
: >
: >
: >>-------------------- ----- ---- --- -- - - - -
: >
: > Hmmm... what was the *other* idea?
: >
: >>--------------------
: >
: >
: > You asked for it. LOL!!
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: >
: > : > : Dan wrote:
: > : > The core of XP PRO is based upon a command.com (cmd.com) prompt
within a
: > DOS
: > : > (Disk Operating System) emulator that is encassed within a DOS shell.
: > :
: > : Sorry Dan, but this is wrong. For one thing it's CMD.EXE not CMD.COM.
: > :
: > : XP is based on the NT kernel which is NOT any sort of DOS, never has
: > : been, and there is no "DOS shell" in XP. Command.com (16-bit) and
: > : cmd.exe (32-bit) are command line interfaces to NT, not DOS. They have
: > : the equivalent of DOS-type file system commands that are applicable to
: > : NT and maintain reporting of a DOS version to make them compatible with
: > : DOS programs that query the OS for the DOS version prior to execution.
: > : The only smidgen of actual DOS in XP is the ability to create an MS-DOS
: > : startup floppy, which is Windows ME DOS, by the way.
: > :
: > : Steve
: >
: >

 

[Sam]

Apparently, _Dan_, on 24/02/05 12:22,typed:

True, Sam but I am happy with 98SE and XPPRO in my dual-boot with a
customized boot environment. Linux, Unix, Apple are all good alternatives
but one must remember they do not have the market share as of yet. Maybe
someday in the future these companies will be able to challenge Microsoft
thus leading to more computer innovation and more technology for the world
and helping keep the States as a superpower. You can tell I am a techie.
<smile>

This is probably off topic now: IIRC, Windows used to insist on being
installed on C: drive and wouldn't install on any other. However, I have
seen Linux being installable on any hard drive's any paritition and
happily live there.

Are there any restrictions where I can install XP on a given hard disk?

Sam.

 

[Al Dykes]

Hopefully the following below will help you and it is which is more secure --
98SE or XPPRO at the core source code level.

"which is more secure -- >98SE or XPPRO at the core source code level"


That sentance doesn't make any sense.

 

[Steve N.]

Hopefully the following below will help you and it is which is more secure --
98SE or XPPRO at the core source code level.

Dan, I repeat, this has nothing to do with what I said.

Steve

 

[Dan]

Good Question! I know older Windows such as 98SE need to be installed on C:
drive. I think even with XP PRO. you need to install it on the C: drive but
I am not sure. You may repost as a new topic or hopefully someone who knows
can tell you.

: Apparently, _Dan_, on 24/02/05 12:22,typed:
: > True, Sam but I am happy with 98SE and XPPRO in my dual-boot with a
: > customized boot environment. Linux, Unix, Apple are all good
alternatives
: > but one must remember they do not have the market share as of yet. Maybe
: > someday in the future these companies will be able to challenge Microsoft
: > thus leading to more computer innovation and more technology for the
world
: > and helping keep the States as a superpower. You can tell I am a techie.
: > <smile>
:
:
: This is probably off topic now: IIRC, Windows used to insist on being
: installed on C: drive and wouldn't install on any other. However, I have
: seen Linux being installable on any hard drive's any paritition and
: happily live there.
:
: Are there any restrictions where I can install XP on a given hard disk?
:
: Sam.
:
:
:
:
: --
: Please remove the underscores ( the '_' symbols) from my email address
: to obtain the correct one. Apologies, but the fudging is to remove spam.

 

[Dan]

Okay you are right and I apologize. Thank you for showing me the error in my
ways. Have a great night!

: Dan wrote:
:
: > Hopefully the following below will help you and it is which is more
secure --
: > 98SE or XPPRO at the core source code level.
:
: Dan, I repeat, this has nothing to do with what I said.
:
: Steve
:
: >
: > : > : Dan wrote:
: > :
: > : > Sorrry, Steve N. You have been falsely led astray. Here topic on
: > : > information for Chris Quirke, MVP, myself, PCR and Gary S. Terhune.
Here
: > is
: > : > the Truth and the Truth will Set you Free:
: > :
: > : That's all well and good but doesn't address what I was saying about
DOS
: > : vs. NT that I can see at all.
: > :
: > : Steve
: > :
: > : >
: > : > ">For myself, in answer to your question, the Windows NT paradigm, as
: > : >
: > : >>defined by Microsoft, seems to be that you keep a lot of backups, and
: > : >>use the tools provided, without providing low-level access of the
sort
: > : >>that allows detailed mucking about and user-control. Partly, or even
: > : >>mostly, in the name of security. There are very few people that are
: > : >>interested in spending a day or two rebuilding an NTFS file system
bit
: > : >>by byte. Most people prefer to let Windows attempt the fix, and if
that
: > : >>doesn't get it done, trash the system and restore from backup. I
can't
: > : >>say that I'm all that much against this paradigm.
: > : >
: > : >
: > : > I am, because NT fails to be maintainable in this way as well.
: > : >
: > : > End users typically have 1 (one) PC that contains everything they
: > : > have. It's set up interactively on an ad-hoc basis. It's typically
: > : > budget hardware, and may have nil but a 1.44M drive for "backup".
: > : >
: > : > For you to say "stuff maintenance, let the end user just wipe,
: > : > re-install and restore data backups", a number of things would have
to
: > : > be in place - and as things are, they are not:
: > : >
: > : > 1) Working installation OS CD
: > : >
: > : > OEMs often provide CDs that don't respect user's choice of
: > : > partitioning, installation paths etc. or they don't provide a CD at
: > : > all. As it is, the OS CD you get may be invalidated by SPs.
: > : >
: > : > A properly installable OS CD, supporting custom installation that is
: > : > managed through a nice UI, is the starting point. Beyond that, one
: > : > would expect this CD to be updated with patches and hotfixes, but as
: > : > it is, you can install an SP that breaks the compatibility of the
: > : > installation CD, and doesn't offer to build a replacement.
: > : >
: > : > Once you start talking about keeping installation CDs updated, you
: > : > open the door to malware infection. It's not a winnable scenario,
: > : > which is why I don't take it seriously as an alternative to
: > : > maintenance, but let's see howfar we can get with it.
: > : >
: > : > 2) Proper scoping of material
: > : >
: > : > To "just" re-install and then restore data, you have to have clear
: > : > scoping between what is code and what is data. MS is groping towards
: > : > this (e.g. FAST and SR) but they are at the foot of the clue
mountain.
: > : >
: > : > How should content be scoped?
: > : > That is answered by: Why would you need to rebuild the system?
: > : >
: > : > Hardware failure/replacement
: > : > - scope in OS code, user settings, data and external material
: > : > - scope out hardware-specific drivers etc.
: > : > Malware infestation
: > : > - scope in known-good original code (updates?)
: > : > - scope out all other code
: > : > - scope in user data (and settings?)
: > : > - scope out incoming material
: > : > Redeployment
: > : > - scope in code, hardware-specifics, ?baseline settings
: > : > - scope out user data and incoming material
: > : >
: > : > MS has no clue on separating incoming material (that is likely to be
: > : > malware) from data; consider .PST, "My Recieved Files", advice to
save
: > : > downloaded .EXE in "My Documents" to avoid SR activity, etc. not to
: > : > mention the pervasiveness of autorunning macros and scripts in "data"
: > : > such as document files and email "message text".
: > : >
: > : > MS also routinely binds data to application version, and application
: > : > version to OS or other large-lump product version (OE and OS,
Outbreak
: > : > and Office, even long-life databases get file-versioned with new
: > : > versions of Access). Even MS's Backup utility spawns backups that
: > : > often cannot be restored by other OS versions.
: > : >
: > : > 3) Rational data sets
: > : >
: > : > Assuming there's enough clue for a data set to be identified that
: > : > contains no malware, version- or hardware-bound code, etc., it helps
: > : > if this data can be easily backed up. This is far from the case with
: > : > Windows, where large Music and Pictures objects are embedded in the
: > : > data set, and MSware data resides outside the data set (e.g. is it
: > : > Application Data, or Local Settings\Application Data, this time?)
: > : >
: > : > If you were to try to dump everything in "Documents and Settings" to
: > : > CDRW (assuming you have a CDRW drive, assuming it would fit) then
this
: > : > would fail, because MS nests the CD writing workspace within this
: > : > subtree, along with temp and hugely bloated web caches.
: > : >
: > : > 4) The mythical "Full System Backup"
: > : >
: > : > Ignoring for a moment the likelyhood that whatever infected or messed
: > : > up the systrem, may also be present in the "full system backup",
: > : > there's the problem with *doing* a full system backup that will
: > : > actually restore. It has to fit on backup storage, for one thing,
and
: > : > there has to be an app that can reate it (which XP Home lacks; OEM
CDs
: > : > may not even have Backup at all), and there has to be a stub OS that
: > : > can restore it (said stub OS being so similar to a mOS, you may as
: > : > well dev a mOS and addrsess both roles at once).
: > : >
: > : > 5) Backup devices and capacities
: > : >
: > : > Even today, many home systems do not come with a backup device
capable
: > : > of backing up even a small data set that's scoped down to Office
: > : > documents alone. Where are these backups going to come from?
: > : >
: > : >
: > : > So, in summary: "Just wipe and rebuild" is NEVER an acceptable
: > : > substitute in consumerland. It only works in pro-IT land because
: > : > pro-IT has larger resources (e.g. data concentrated on servers) and
: > : > professional administration (i.e. it's someone's job to make backups
: > : > and to defend the server against attack).
: > : >
: > : > In essence, this approach is basically saying "FOAD" to consumers,
and
: > : > as consumers, we should reject it as such.
: > : >
: > : >
: > : >
: > : >
: > : >>-------------------- ----- ---- --- -- - - - -
: > : >
: > : > Hmmm... what was the *other* idea?
: > : >
: > : >>--------------------
: > : >
: > : >
: > : > You asked for it. LOL!!
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : >
: > : > : > : > : Dan wrote:
: > : > : > The core of XP PRO is based upon a command.com (cmd.com) prompt
: > within a
: > : > DOS
: > : > : > (Disk Operating System) emulator that is encassed within a DOS
shell.
: > : > :
: > : > : Sorry Dan, but this is wrong. For one thing it's CMD.EXE not
CMD.COM.
: > : > :
: > : > : XP is based on the NT kernel which is NOT any sort of DOS, never
has
: > : > : been, and there is no "DOS shell" in XP. Command.com (16-bit) and
: > : > : cmd.exe (32-bit) are command line interfaces to NT, not DOS. They
have
: > : > : the equivalent of DOS-type file system commands that are applicable
to
: > : > : NT and maintain reporting of a DOS version to make them compatible
with
: > : > : DOS programs that query the OS for the DOS version prior to
execution.
: > : > : The only smidgen of actual DOS in XP is the ability to create an
MS-DOS
: > : > : startup floppy, which is Windows ME DOS, by the way.
: > : > :
: > : > : Steve
: > : >
: > : >
: >
: >

 

[Sharon F]

This is probably off topic now: IIRC, Windows used to insist on being
installed on C: drive and wouldn't install on any other. However, I have
seen Linux being installable on any hard drive's any paritition and
happily live there.

Are there any restrictions where I can install XP on a given hard disk?

Sam.

Boot files need a bit of space on C:, the rest of Windows can be directed
to another partition. This option is available in the initial XP setup
screens ("choose a partition" text screen).

Being able to install older versions of Windows somewhere other than C: was
available but not always apparent. Needed to run setup from a command line
to get the option.

 

[Dan]

Thanks Sharon F. I now will add this knowledge to my knowledge. I really
appreciate you responding and clearing this issue up for me. Have a super
day!

: On Thu, 24 Feb 2005 12:27:43 -0500, Sam wrote:
:
: > This is probably off topic now: IIRC, Windows used to insist on being
: > installed on C: drive and wouldn't install on any other. However, I have
: > seen Linux being installable on any hard drive's any paritition and
: > happily live there.
: >
: > Are there any restrictions where I can install XP on a given hard disk?
: >
: > Sam.
:
: Boot files need a bit of space on C:, the rest of Windows can be directed
: to another partition. This option is available in the initial XP setup
: screens ("choose a partition" text screen).
:
: Being able to install older versions of Windows somewhere other than C: was
: available but not always apparent. Needed to run setup from a command line
: to get the option.
:
: --
: Sharon F
: MS-MVP ~ Windows Shell/User