OK, what's going on here:

1) something about my fix for a lack of environment space is causing a major bug that is sooo weird it should be the new definition for weirdness. All the fix does is add the following line to CONFIG.SYS

SHELL=COMMAND.COM /E:4096 /P

2) if i install this fix on a totally clean newly installed OS it works fine with no problems. When i run AP on it to fully patch it, there are still no problems afterwards (which is how i was testing).

3) if i install this fix on a totally patched system i get the following error: Can't find COMMAND.COM


4) a fix for this problem is simply adding

SET PATH=%PATH%

to AUTOEXEC.bat and the problem goes away. Even just adding a REM statement to AUTOEXEC.bat fixes this problem !!!!

I have been testing exactly what 'fixes' this problem and it seems that if the size of the AUTOEXEC.BAT file is zero the problem is there, but if AUTOEXEC.BAT is even 1 byte in size or over then the problem is NOT there. All i did was add a space to AUTOEXEC.BAT and the problem is fixed. The problem also goes away if i change the line added to CONFIG.SYS to

SHELL=C:\WINDOWS\COMMAND.COM /E:4096 /P

But this means that if the user has COMMAND.COM in a different directory its not going to work. And i can't use:

SHELL=%windir%\COMMAND.COM /E:4096 /P

which would avoid the different directory issue. You can't use environment variables in CONFIG.SYS

WHAT IS GOING ON ???????????? .... far out this AP project is giving me gray hairs before my time !!!

Thanks in advance for any comments or help.

Hmmm,
I guess it should be the other way round.

I mean, a "valid"

statement in config.sys, should have the full path to the shell, like in:

or

since COMMAND.COM is one of the three boot files, together with MSDOS.SYS and IO.SYS, it should reside on the root of the boot disk, and, on the other hand, CONFIG.SYS should also be there, so:

should work as well, as long as the CONFIG.SYS that has that line is on the same (root) directory of the booted drive, if COMMAND.COM is anywhere else, a FULL path or an updated %PATH% variable is needed.

The "strange" fact is that the presence of AUTOEXEC.BAT with length >0 changes, from what you report as second example, the behaviour, in the case COMMAND.COM is on the root directory, just as if the mere presence of AUTOEXEC.BAT would make it "root" to it correctly.

So, if I get what you report correctly, it seems like in one case the "root" is (as it should) C:, whilst in the second is somehow "undefined".

Since we are talking about DOS7.1 here, could the above be somehow connected with changes (if any) in the contents of the MSDOS.SYS file?
http://www.computerhope.com/msdossys.htm

jaclaz

This post has been edited by jaclaz: Jun 6 2007, 07:22 AM

thanks for the info .... i never noticed that you could have more than one COMMAND.COM on your system. I knew about the one in the Windows directory but it never occurred to me it could be in two locations. So, it looks like i can just use like you pointed out. The way i've gone with is to add a REM line to AUTOEXEC.BAT which is totally harmless to do which also fixes the problem. But i will probably change it if we get to the bottom of this saga!

I'm still interested in hearing more on this subject though. Anyone?

Why that error I'm unsure.

If it were a boot disc the shell line would look like this:
SHELL=\COMMAND.COM
With a backslash.
(plus any switches you would add)

%COMSPEC% would end up holding the boot drive letter

In your case, since the OS is already booted, is it possible
to simply use the %COMSPEC% environment variable ?
Like this:

ECHO SHELL=%COMSPEC% /E:4096 /P >> CONFIG.SYS

After all, you would not be able to do much if
%COMSPEC% was wrong. ??

This post has been edited by sleffing: Jun 6 2007, 05:50 PM

Eureka !! Why i didn't think of that .... i need to take a break !!! Thanks for that ...