Xref: utzoo comp.windows.ms.programmer:1105 comp.windows.ms:9842
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!usc!trwind!venice!press
From: press@venice.SEDD.TRW.COM (Barry Press)
Newsgroups: comp.windows.ms.programmer,comp.windows.ms
Subject: Re: Installation Problem
Message-ID: <1021@venice.SEDD.TRW.COM>
Date: 1 Mar 91 17:39:47 GMT
References: <1388@ssp18.idca.tds.philips.nl>
Reply-To: press@venice.sedd.trw.com (Barry Press)
Organization: TRW Systems Engineering & Development Division, Redondo Beach, CA
Lines: 21

In article <1388@ssp18.idca.tds.philips.nl> mm@idca.tds.PHILIPS.nl (M. Molenaar) writes:
>Well, I have found that the problem arises if the environment
>variable COMSPEC specifies that the COMMAND.COM is present in
>a SUBdirectory of the root, e.g. SET COMSPEC=c:\dos\command.com.
>So COMMAND.COM MUST be specified in the root. If not, the dos-

No cigar.  I've setup a lot of machines running Windows, and each and every
one of them has DOS in a subdirectory, a SHELL command in the config.sys,
and comspec pointing to command com in the subdir.  None of them have
command.com in the root.  All run Windows and DOS sessions just fine.

I don't know if the config.sys setup matters, but I use this sort of
thing:

	shell=c:\dos\command.com c:\dos /p /e:xxx

The c:\dos parameter has to do with telling it where to reload from.  I usually
force comspec in the autoexec as well.

-- 
Barry Press                                 Internet: press@venice.sedd.trw.com