Prior posts referred to KB q133442 to resolve unable to start in Safe Mode.
This is a workaround that will get you into safe mode, but apparently has to
be done every time. Is there a fix for a comp that will not go into an
error mode re:unable to load himem.sys? One of the many things I don't
understand is why it hangs on himem.sys, when safe mode bypasses the
config.sys file it's in.

Could really use some help here. Thx
DaveB

1-when loading your comp., as soon as you see the words
starting Windows ,click the F8 key a couple of times.
this will take you to start menu. Chose "command mode".
hit enter.
you should see a c:\> on the screen.
2-type the following without the " marks: "type
config.sys" ,enter
this will show you what is written in the config.sys file.
3-the first 2 lines must be the following:
DOS=HIGH,UMB
DEVICE=C:\WINDOWS\HIMEM.SYS
4-if they are not there you'll have to get them there
using an editor.
4a-back at C:\> , type: edit.com ,enter,navigate to the
config.sys file using the arrow keyson the keyboard
4b-once you in the config.sys file, place the corsor to
the very top click enter (this will create a blank line).
4c-write there: DOS=HIGH,UMB
DEVICE=C:\WINDOWS\HIMEM.SYS
4d-goto the File tab and select save
4e-goto File tab and select exit
5-back at C:\> type: cd\windows ,enter.
6-type : dir /o/p ,enter.
7- look for a HIMEM.SYS file.
8-if it is there good,if not your Emergency Startup
Diskette has this file.
9-copy the file HIMEM.SYS from a: to c:\windows
10-remove the diskette
11-resart your computer.
Good luck.

When Config.sys does not exist or is not run, then Himem.sys will run
anyway. It will run because IO.sys will load it during boot, under that
circumstance. Apparently, your Win95 computer requires a "machine-switch
parameter" on the Himem.sys line, such as

device=c:\windows\himem.sys /m:1

Unfortunately, the line that IO.sys supplies (in the absence of
Config.sys) does not contain any such parameter. That is why you must do
as the article says-- & every time.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"Dave B" <djbahb@dcwis.com> wrote in message
news:Oq8AAhJUDHA.2200@TK2MSFTNGP11.phx.gbl...
| Prior posts referred to KB q133442 to resolve unable to start in Safe
Mode.
| This is a workaround that will get you into safe mode, but apparently
has to
| be done every time. Is there a fix for a comp that will not go into
an
| error mode re:unable to load himem.sys? One of the many things I
don't
| understand is why it hangs on himem.sys, when safe mode bypasses the
| config.sys file it's in.
|
| Could really use some help here. Thx
| DaveB
|
|

"Dave B" <djbahb@dcwis.com> wrote in message news:<Oq8AAhJUDHA.2200@TK2MSFTNGP11.phx.gbl>...
The main problem is likely to a messed up path statement, if
the path does not include C:\Windows;C:\Windows\Command then
DOS can't find a slug a files needed to load windows,
himem.sys being just the first one. Adding to the confusion,
IO.sys is loading ifshlp.sys and dblbuff.sys along with checking/
creating tmp and temp directory if not in existance all according
to the path statement. The path statement comes from msdos.sys
lines, in particular these.

[Paths]
WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS
HostWinBootDrv=C

If you have a zero instead of a C on the last line, you've found
your troubles? If there is junk ahead of [Paths], delete it.

Himem.sys is one of the files loaded by IO.sys without you having
a line in config.sys for that - perhaps that's where some confusion
comes from. To find out what DOS mode thinks is your path along
with all your other environment variables just type in 'set' at the
commant prompt. Post what you see for more help from me.

On Wed, 23 Jul 2003 00:04:02 -0400, "PCR" <pcrrcp@netzero.net> wrote:

Also will explain why Safe Mode will fail. Safe Mode ignores
Config.sys and thus defaults to DOS=Auto, with one difference;
HiMem.sys's RAM test is not skipped.

Lee,
Thanks for a great post - I really needed that. Before I get into your
points, I've been trying to think when this all of a sudden started to
happen. Only thing I can think of is I added a second HD for backup
purposes recently. I don't know EXACTLY when the current problem started;
don't go into SM with any regularity.

To your points (questions - hope format isn't going to be a problem - could
try html???)


msdos.sys -
;sys
[Paths]
WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS
HostWinBootDrv=C
UninstallDir=C:\

[Options]
BootMulti=0
BootGUI=1
DoubleBuffer=1
AutoScan=1
WinVer=4.10.2222

Set at the C:\ prompt gets the following:
TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP
PROMPT=$p$g
WINBOOTDIR=C:\WINDOWS
PATH=C:\WINDOWS;C:\WINDOWS;C:\WINDOWS\COMMAND
COMSPEC=C:\WINDOWS\COMMAND.COM
CLASSPATH=C:\PROGRA~1\PHOTOD~1.1\ADOBEC~1
WINDIR=C:\WINDOWS
BLASTER=A220 I3 D3 T4


Hope there aren't any typos. I'm no typist.

Thx again
Dave B

"Dave B" <djbahb@dcwis.com> wrote in message news:<eVFQvf7UDHA.1928@TK2MSFTNGP12.phx.gbl>...
Format fine, works for me. Only thing wrong with msdos.sys is minor
point and that would be the ;sys line, which you can easily remove
with notepad once you change the read only attributes. Right click,
Properties, check boxes at the bottom - don't forget to set it back
to hidden and read only when done, if you boot without them you will
screw the pooch good.

It appears that you may have the dreaded 'double path' problem, I
had it once and only a clean install got rid of it - but my path
was

C:\Windows;C:\WINDOWS;C:\WINDOWS\COMMAND;C:Windows \Command

note the odd all caps in the middle which seems to be a tad
different than what you posted. I have no solution to the above
path other than to add a set path line to your autoexec.bat file
which won't get run in safe mode anyway so is not much help for
you. I'm just guessing but I suspect that perhaps some non-alpha
characters have invaded your msdos.sys file such that they appear
to be spaces when veiwed with notepad but can be seen to be other
than hex 20 (space) using a hex editor. Just checking mine and
no spaces are to be found but a non-alpha could take up residence
at the end of line and not be noticed just the same? Again, just
guessing. Is there any difference in DOS environment variables
when booting to just DOS VS a Windows DOS box? In other words
type 'set' at a boot to DOS prompt, compare that to typing 'set'
into a DOS box opened in Windows.

Add this line to autoexec.bat to correct path statement if desired

Set Path=C:\Windows;C:\Windows\Command

Put at the begining of autoexec.bat if you can.

Somethings up with that double path, but I've never found the
culprit or the cure, sorry. I also never thought about being
locked out of safe mode with it either - wish I had of when I
had that double path problem even if it would have been just to
verify that it screws up safe mode. I keep hoping double path
will return now that I am better able to snoop such things out.
But no joy so far.

I have a screwed Path, which I've corrected in Autoexec.bat, with...

Path ;
SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND

It wouldn't fix w/o that first "Path ;". However, as you say,
Autoexec.bat does not execute going to Safe Mode. And I do get there.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"Lee" <melee5@my-deja.com> wrote in message
news:a57ea28d.0307272034.5b82b7e1@posting.google.c om...
| "Dave B" <djbahb@dcwis.com> wrote in message
news:<eVFQvf7UDHA.1928@TK2MSFTNGP12.phx.gbl>...
| > Lee,
| > Thanks for a great post - I really needed that. Before I get into
your
| > points, I've been trying to think when this all of a sudden started
to
| > happen. Only thing I can think of is I added a second HD for backup
| > purposes recently. I don't know EXACTLY when the current problem
started;
| > don't go into SM with any regularity.
| >
| > To your points (questions - hope format isn't going to be a
problem - could
| > try html???)
| >
| >
| > msdos.sys -
| > ;sys
| > [Paths]
| > WinDir=C:\WINDOWS
| > WinBootDir=C:\WINDOWS
| > HostWinBootDrv=C
| > UninstallDir=C:\
| >
| > [Options]
| > BootMulti=0
| > BootGUI=1
| > DoubleBuffer=1
| > AutoScan=1
| > WinVer=4.10.2222
| >
| > Set at the C:\ prompt gets the following:
| > TMP=C:\WINDOWS\TEMP
| > TEMP=C:\WINDOWS\TEMP
| > PROMPT=$p$g
| > WINBOOTDIR=C:\WINDOWS
| > PATH=C:\WINDOWS;C:\WINDOWS;C:\WINDOWS\COMMAND
| > COMSPEC=C:\WINDOWS\COMMAND.COM
| > CLASSPATH=C:\PROGRA~1\PHOTOD~1.1\ADOBEC~1
| > WINDIR=C:\WINDOWS
| > BLASTER=A220 I3 D3 T4
| >
| >
| > Hope there aren't any typos. I'm no typist.
| >
| > Thx again
| > Dave B
|
| Format fine, works for me. Only thing wrong with msdos.sys is minor
| point and that would be the ;sys line, which you can easily remove
| with notepad once you change the read only attributes. Right click,
| Properties, check boxes at the bottom - don't forget to set it back
| to hidden and read only when done, if you boot without them you will
| screw the pooch good.
|
| It appears that you may have the dreaded 'double path' problem, I
| had it once and only a clean install got rid of it - but my path
| was
|
| C:\Windows;C:\WINDOWS;C:\WINDOWS\COMMAND;C:Windows \Command
|
| note the odd all caps in the middle which seems to be a tad
| different than what you posted. I have no solution to the above
| path other than to add a set path line to your autoexec.bat file
| which won't get run in safe mode anyway so is not much help for
| you. I'm just guessing but I suspect that perhaps some non-alpha
| characters have invaded your msdos.sys file such that they appear
| to be spaces when veiwed with notepad but can be seen to be other
| than hex 20 (space) using a hex editor. Just checking mine and
| no spaces are to be found but a non-alpha could take up residence
| at the end of line and not be noticed just the same? Again, just
| guessing. Is there any difference in DOS environment variables
| when booting to just DOS VS a Windows DOS box? In other words
| type 'set' at a boot to DOS prompt, compare that to typing 'set'
| into a DOS box opened in Windows.
|
| Add this line to autoexec.bat to correct path statement if desired
|
| Set Path=C:\Windows;C:\Windows\Command
|
| Put at the begining of autoexec.bat if you can.
|
| Somethings up with that double path, but I've never found the
| culprit or the cure, sorry. I also never thought about being
| locked out of safe mode with it either - wish I had of when I
| had that double path problem even if it would have been just to
| verify that it screws up safe mode. I keep hoping double path
| will return now that I am better able to snoop such things out.
| But no joy so far.

Dave,

Though the double entry of C:\WINDOWS in the PATH variable is not a
normal entry (and the cause of it isn't found yet, as I know; BTW, don't
you have Winboot.ini file in the root of C: drive?) -- I don't think it
is a problem.

Would you please give the *exact* error message? What is the message on
the screen close to it? It may be the cause is the faulty RAM module.
--
Mikhail Zhilin (MS MVP - Win9x)
http://www.aha.ru/~mwz
Sorry, no technical support by e-mail.
Please reply to the newsgroups only.
======
On Sat, 26 Jul 2003 15:52:38 -0500, "Dave B" <djbahb@dcwis.com> wrote:

On 27 Jul 2003 21:34:21 -0700, melee5@my-deja.com (Lee) wrote:

I bet you were one of those CompSci 101 tutors who'd "help"
programming students by pointing out spelling errors in comments :-)

Winboot.ini and MSDOS.sys both use .ini syntax, in which any line
starting with ; is ignored as a ;comment (the "; as comment" syntax
tradition dates from assembly language).

That initial ;FORMAT or ;SYS is merely there to record what process
originally created the file, which is then fleshed out by Win9x Setup.

That's easy to fix, and is usually a side-effect of Win9x's
modification to the handling of the Path in Autoexec.bat
(specifically, the first Path statement retains the original Path as
if it was phrased Path=%Path%;whatever)

Path starts from Winboot.ini (should this exist, it usually doesn't)
or MSDOS.SYS (more typical). If there's a Set Path= in Config.sys,
this replaces whatever was set in these earlier files.

Thereafter the first Path statement in Autoexec.bat appends to the
original Path, and subsequent lines replace the Path.

Unlike Config.sys, Autoexec.bat supports %Path%, and this is typically
used to retain the existing Path value and add to it. Stupid or
greedy software prepends to the Path, i.e. C:\My\Bossy\App;%Path%,
while clueful software appends e.g. %Path%;C:\Clueful\App

My generic approach is to either delete Autoexec.bat entirely (if I
don't need anything in there) and Set Path= in Config.sys, or to use a
dummy line to clear append-or-not ambiguity before setting Path, e.g.

@Echo Off
Set Path=C:\Some\Fictitious\Path
Set Path=C:\Windows;C:\Windows\Command;C:\Addon1;C:\Ad don2etc

See above. Your example would give rise to that problem, as it may
append your explicit path to the implicit path unless it recognises
the duplication (may be letter-case sensitive on matching).

This would work...

Set Path=C:\Windows;C:\Windows\Command
Set Path=C:\Windows;C:\Windows\Command

....as the 2nd Path statement is accepted without any editorialising.
This works better (i.e. is more portable)...

Set Path=C:\Some\Junk
Set Path=%WinBootDir%;%WinBootDir%\Command

....i.e. works where Windows is not installed in C:\Windows

Final tip: Whenever your changes to MSDOS.SYS seems to be ignored or
overridden, look for two things:

1) A (hidden, etc.) C:\WINBOOT.INI
2) Extra lines added after the padding comment string lines

I guess I'll have to do it again to be sure, cquirke. But I seem to
recall one experiment to cure my screwed Path was to remove the Path
statement altogether from my Autoexec.bat. (There is none in Config.sys.
And MSDOS.sys is normal. There is no Winboot.ini, nor a Winstart.bat.)

With no Path in Autoexec.bat, I can almost swear I still had a double
Path. That goes against your explanation, which is that it happens
because the first Path statement in Autoexec.bat has an implicit %path%
in front. I'm sure I went through all the possibilities, & only the
following cured me. I guess I'll have to try again, though-- to remove
those Path statements & see what happens.

@ECHO ON


C:\PROGRA~1\COMMON~1\NETWOR~1\VIRUSS~1\40~1.XX\sca n.exe c:\
@IF ERRORLEVEL 1 PAUSE
rem TShoot: LoadHigh C:\WINDOWS\Command\DOSKey
rem TShoot: mode con lines=50
SET PROMPT=$p$g
path ;
SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
SET WINPMT=$e[s$e[f$e[0;30;46m$e[K DOS Session In Windows
98$e[16CAlt+Tab to switch; type Exit to close$_$e[0;40;37;1m$e[K$e[u$P$G
@IF EXIST W:\CPQS\XQR.* CALL W:\CPQS\XQR.EXE
rem TShoot: C:\ESSAUDIO.COM

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"cquirke" <cquirke@iafrica.com> wrote in message
news:62s9ivc1ijtj29r7l1oqvmpd1ct7keq2i3@4ax.com...
| On 27 Jul 2003 21:34:21 -0700, melee5@my-deja.com (Lee) wrote:
|
| >Only thing wrong with msdos.sys is minor point and that would
| >be the ;sys line, which you can easily remove with notepad
|
| I bet you were one of those CompSci 101 tutors who'd "help"
| programming students by pointing out spelling errors in comments :-)
|
| Winboot.ini and MSDOS.sys both use .ini syntax, in which any line
| starting with ; is ignored as a ;comment (the "; as comment" syntax
| tradition dates from assembly language).
|
| That initial ;FORMAT or ;SYS is merely there to record what process
| originally created the file, which is then fleshed out by Win9x Setup.
|
| >It appears that you may have the dreaded 'double path' problem, I
| >had it once and only a clean install got rid of it - but my path was
|
| >C:\Windows;C:\WINDOWS;C:\WINDOWS\COMMAND;C:Window s\Command
|
| That's easy to fix, and is usually a side-effect of Win9x's
| modification to the handling of the Path in Autoexec.bat
| (specifically, the first Path statement retains the original Path as
| if it was phrased Path=%Path%;whatever)
|
| Path starts from Winboot.ini (should this exist, it usually doesn't)
| or MSDOS.SYS (more typical). If there's a Set Path= in Config.sys,
| this replaces whatever was set in these earlier files.
|
| Thereafter the first Path statement in Autoexec.bat appends to the
| original Path, and subsequent lines replace the Path.
|
| Unlike Config.sys, Autoexec.bat supports %Path%, and this is typically
| used to retain the existing Path value and add to it. Stupid or
| greedy software prepends to the Path, i.e. C:\My\Bossy\App;%Path%,
| while clueful software appends e.g. %Path%;C:\Clueful\App
|
| My generic approach is to either delete Autoexec.bat entirely (if I
| don't need anything in there) and Set Path= in Config.sys, or to use a
| dummy line to clear append-or-not ambiguity before setting Path, e.g.
|
| @Echo Off
| Set Path=C:\Some\Fictitious\Path
| Set Path=C:\Windows;C:\Windows\Command;C:\Addon1;C:\Ad don2etc
|
| >Add this line to autoexec.bat to correct path statement if desired
|
| >Set Path=C:\Windows;C:\Windows\Command
|
| >Put at the begining of autoexec.bat if you can.
|
| >Somethings up with that double path, but I've never found the
| >culprit or the cure, sorry.
|
| See above. Your example would give rise to that problem, as it may
| append your explicit path to the implicit path unless it recognises
| the duplication (may be letter-case sensitive on matching).
|
| This would work...
|
| Set Path=C:\Windows;C:\Windows\Command
| Set Path=C:\Windows;C:\Windows\Command
|
| ...as the 2nd Path statement is accepted without any editorialising.
| This works better (i.e. is more portable)...
|
| Set Path=C:\Some\Junk
| Set Path=%WinBootDir%;%WinBootDir%\Command
|
| ...i.e. works where Windows is not installed in C:\Windows
|
| Final tip: Whenever your changes to MSDOS.SYS seems to be ignored or
| overridden, look for two things:
|
| 1) A (hidden, etc.) C:\WINBOOT.INI
| 2) Extra lines added after the padding comment string lines
|
|
| >--------------- ----- ---- --- -- - - -
| Error Messages Are Your Friends
| >--------------- ----- ---- --- -- - - -

I had the dreaded double path once. IIRC mine was one set of
uppercase and the other lower.
C:\WINDOWS;c:\windows;C:\WINDOWS\COMMAND;c:\window s\command
Or a mixed up variation.

The "fix" was to delete the %path% completely in autoexec.bat
path;

I also found that if I did a "step by step" at boot and answered "N" to
"Process system registry [Y,N]"? the %path% would be normal.
Try that. (Undocumented tip: A for (A)ll after you are past the registry
prompt (N)o, will run through the rest of the prompts, giving (Y)s.

I never did find what caused it and couldn't find anything in the registry. I
even poked through IO.SYS and command.com looking for lower case
strings. No extraneous startup files here either.

AFAIK it is an "undocumented" bug and I've never seen an explanation.



"PCR" <pcrrcp@netzero.net> wrote in message news:Ooz#1qUVDHA.2164@TK2MSFTNGP10.phx.gbl...

| The "fix" was to delete the %path% completely in autoexec.bat
| path;

You mean to put "Path;" in, or to remove the Path statements altogether?
I certainly works the first way. I doubt the other will, but I've taken
them out of Autoexec.bat & have yet to reboot.

| C:\WINDOWS;c:\windows;C:\WINDOWS\COMMAND;c:\window s\command
| Or a mixed up variation.

Can't remember mine. Will know soon enough, maybe
"C:\WINDOWS;C:\WINDOWS\COMMAND;c:\windows;c:\windo ws\command", or vica
versa.

I guess you have proven it is something in the Registry does it. I will
not go nuts over it, more than I already had developing the workaround.
I certainly wasn't going to let it search each folder twice, when the
command was in neither.

I guess cquirke has come up with a second "fix", though. That would be
to move the "SET PATH" from Autoexec.bat into Config.sys, where he says
%Path% would not attach.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message
news:urlEWVWVDHA.1680@tk2msftngp13.phx.gbl...
| I had the dreaded double path once. IIRC mine was one set of
| uppercase and the other lower.
| C:\WINDOWS;c:\windows;C:\WINDOWS\COMMAND;c:\window s\command
| Or a mixed up variation.
|
| The "fix" was to delete the %path% completely in autoexec.bat
| path;
|
| I also found that if I did a "step by step" at boot and answered "N"
to
| "Process system registry [Y,N]"? the %path% would be normal.
| Try that. (Undocumented tip: A for (A)ll after you are past the
registry
| prompt (N)o, will run through the rest of the prompts, giving (Y)s.
|
| I never did find what caused it and couldn't find anything in the
registry. I
| even poked through IO.SYS and command.com looking for lower case
| strings. No extraneous startup files here either.
|
| AFAIK it is an "undocumented" bug and I've never seen an explanation.
|
|
|
| "PCR" <pcrrcp@netzero.net> wrote in message
news:Ooz#1qUVDHA.2164@TK2MSFTNGP10.phx.gbl...
| > I guess I'll have to do it again to be sure, cquirke. But I seem to
| > recall one experiment to cure my screwed Path was to remove the Path
| > statement altogether from my Autoexec.bat. (There is none in
Config.sys.
| > And MSDOS.sys is normal. There is no Winboot.ini, nor a
Winstart.bat.)
| >
| > With no Path in Autoexec.bat, I can almost swear I still had a
double
| > Path. That goes against your explanation, which is that it happens
| > because the first Path statement in Autoexec.bat has an implicit
%path%
| > in front. I'm sure I went through all the possibilities, & only the
| > following cured me. I guess I'll have to try again, though-- to
remove
| > those Path statements & see what happens.
| >
| > @ECHO ON
| >
| >
| > C:\PROGRA~1\COMMON~1\NETWOR~1\VIRUSS~1\40~1.XX\sca n.exe c:\
| > @IF ERRORLEVEL 1 PAUSE
| > rem TShoot: LoadHigh C:\WINDOWS\Command\DOSKey
| > rem TShoot: mode con lines=50
| > SET PROMPT=$p$g
| > path ;
| > SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| > SET WINPMT=$e[s$e[f$e[0;30;46m$e[K DOS Session In Windows
| > 98$e[16CAlt+Tab to switch; type Exit to
close$_$e[0;40;37;1m$e[K$e[u$P$G
| > @IF EXIST W:\CPQS\XQR.* CALL W:\CPQS\XQR.EXE
| > rem TShoot: C:\ESSAUDIO.COM
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| > pcrrcp@netzero.net
| > "cquirke" <cquirke@iafrica.com> wrote in message
| > news:62s9ivc1ijtj29r7l1oqvmpd1ct7keq2i3@4ax.com...
| > | On 27 Jul 2003 21:34:21 -0700, melee5@my-deja.com (Lee) wrote:
| > |
| > | >Only thing wrong with msdos.sys is minor point and that would
| > | >be the ;sys line, which you can easily remove with notepad
| > |
| > | I bet you were one of those CompSci 101 tutors who'd "help"
| > | programming students by pointing out spelling errors in comments
:-)
| > |
| > | Winboot.ini and MSDOS.sys both use .ini syntax, in which any line
| > | starting with ; is ignored as a ;comment (the "; as comment"
syntax
| > | tradition dates from assembly language).
| > |
| > | That initial ;FORMAT or ;SYS is merely there to record what
process
| > | originally created the file, which is then fleshed out by Win9x
Setup.
| > |
| > | >It appears that you may have the dreaded 'double path' problem, I
| > | >had it once and only a clean install got rid of it - but my path
was
| > |
| > | >C:\Windows;C:\WINDOWS;C:\WINDOWS\COMMAND;C:Window s\Command
| > |
| > | That's easy to fix, and is usually a side-effect of Win9x's
| > | modification to the handling of the Path in Autoexec.bat
| > | (specifically, the first Path statement retains the original Path
as
| > | if it was phrased Path=%Path%;whatever)
| > |
| > | Path starts from Winboot.ini (should this exist, it usually
doesn't)
| > | or MSDOS.SYS (more typical). If there's a Set Path= in
Config.sys,
| > | this replaces whatever was set in these earlier files.
| > |
| > | Thereafter the first Path statement in Autoexec.bat appends to the
| > | original Path, and subsequent lines replace the Path.
| > |
| > | Unlike Config.sys, Autoexec.bat supports %Path%, and this is
typically
| > | used to retain the existing Path value and add to it. Stupid or
| > | greedy software prepends to the Path, i.e. C:\My\Bossy\App;%Path%,
| > | while clueful software appends e.g. %Path%;C:\Clueful\App
| > |
| > | My generic approach is to either delete Autoexec.bat entirely (if
I
| > | don't need anything in there) and Set Path= in Config.sys, or to
use a
| > | dummy line to clear append-or-not ambiguity before setting Path,
e.g.
| > |
| > | @Echo Off
| > | Set Path=C:\Some\Fictitious\Path
| > | Set Path=C:\Windows;C:\Windows\Command;C:\Addon1;C:\Ad don2etc
| > |
| > | >Add this line to autoexec.bat to correct path statement if
desired
| > |
| > | >Set Path=C:\Windows;C:\Windows\Command
| > |
| > | >Put at the begining of autoexec.bat if you can.
| > |
| > | >Somethings up with that double path, but I've never found the
| > | >culprit or the cure, sorry.
| > |
| > | See above. Your example would give rise to that problem, as it
may
| > | append your explicit path to the implicit path unless it
recognises
| > | the duplication (may be letter-case sensitive on matching).
| > |
| > | This would work...
| > |
| > | Set Path=C:\Windows;C:\Windows\Command
| > | Set Path=C:\Windows;C:\Windows\Command
| > |
| > | ...as the 2nd Path statement is accepted without any
editorialising.
| > | This works better (i.e. is more portable)...
| > |
| > | Set Path=C:\Some\Junk
| > | Set Path=%WinBootDir%;%WinBootDir%\Command
| > |
| > | ...i.e. works where Windows is not installed in C:\Windows
| > |
| > | Final tip: Whenever your changes to MSDOS.SYS seems to be ignored
or
| > | overridden, look for two things:
| > |
| > | 1) A (hidden, etc.) C:\WINBOOT.INI
| > | 2) Extra lines added after the padding comment string lines
| > |
| > |
| > | >--------------- ----- ---- --- -- - - -
| > | Error Messages Are Your Friends
| > | >--------------- ----- ---- --- -- - - -
| >
| >
|
|

C:\>path
PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND

That's it. So, I need that "Path ;" in Autoexec.bat. Or perhaps just a
"SET PATH" in Config.sys.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"PCR" <pcrrcp@netzero.net> wrote in message
news:%23YUuVSYVDHA.1984@TK2MSFTNGP11.phx.gbl...
| | The "fix" was to delete the %path% completely in autoexec.bat
| | path;
|
| You mean to put "Path;" in, or to remove the Path statements
altogether?
| I certainly works the first way. I doubt the other will, but I've
taken
| them out of Autoexec.bat & have yet to reboot.
|
| | C:\WINDOWS;c:\windows;C:\WINDOWS\COMMAND;c:\window s\command
| | Or a mixed up variation.
|
| Can't remember mine. Will know soon enough, maybe
| "C:\WINDOWS;C:\WINDOWS\COMMAND;c:\windows;c:\windo ws\command", or vica
| versa.
|
| I guess you have proven it is something in the Registry does it. I
will
| not go nuts over it, more than I already had developing the
workaround.
| I certainly wasn't going to let it search each folder twice, when the
| command was in neither.
|
| I guess cquirke has come up with a second "fix", though. That would be
| to move the "SET PATH" from Autoexec.bat into Config.sys, where he
says
| %Path% would not attach.
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| should things get worse after this,
| PCR
| pcrrcp@netzero.net
| "Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message
| news:urlEWVWVDHA.1680@tk2msftngp13.phx.gbl...
| | I had the dreaded double path once. IIRC mine was one set of
| | uppercase and the other lower.
| | C:\WINDOWS;c:\windows;C:\WINDOWS\COMMAND;c:\window s\command
| | Or a mixed up variation.
| |
| | The "fix" was to delete the %path% completely in autoexec.bat
| | path;
| |
| | I also found that if I did a "step by step" at boot and answered "N"
| to
| | "Process system registry [Y,N]"? the %path% would be normal.
| | Try that. (Undocumented tip: A for (A)ll after you are past the
| registry
| | prompt (N)o, will run through the rest of the prompts, giving (Y)s.
| |
| | I never did find what caused it and couldn't find anything in the
| registry. I
| | even poked through IO.SYS and command.com looking for lower case
| | strings. No extraneous startup files here either.
| |
| | AFAIK it is an "undocumented" bug and I've never seen an
explanation.
| |
| |
| |
| | "PCR" <pcrrcp@netzero.net> wrote in message
| news:Ooz#1qUVDHA.2164@TK2MSFTNGP10.phx.gbl...
| | > I guess I'll have to do it again to be sure, cquirke. But I seem
to
| | > recall one experiment to cure my screwed Path was to remove the
Path
| | > statement altogether from my Autoexec.bat. (There is none in
| Config.sys.
| | > And MSDOS.sys is normal. There is no Winboot.ini, nor a
| Winstart.bat.)
| | >
| | > With no Path in Autoexec.bat, I can almost swear I still had a
| double
| | > Path. That goes against your explanation, which is that it happens
| | > because the first Path statement in Autoexec.bat has an implicit
| %path%
| | > in front. I'm sure I went through all the possibilities, & only
the
| | > following cured me. I guess I'll have to try again, though-- to
| remove
| | > those Path statements & see what happens.
| | >
| | > @ECHO ON
| | >
| | >
| | > C:\PROGRA~1\COMMON~1\NETWOR~1\VIRUSS~1\40~1.XX\sca n.exe c:\
| | > @IF ERRORLEVEL 1 PAUSE
| | > rem TShoot: LoadHigh C:\WINDOWS\Command\DOSKey
| | > rem TShoot: mode con lines=50
| | > SET PROMPT=$p$g
| | > path ;
| | > SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| | > SET WINPMT=$e[s$e[f$e[0;30;46m$e[K DOS Session In Windows
| | > 98$e[16CAlt+Tab to switch; type Exit to
| close$_$e[0;40;37;1m$e[K$e[u$P$G
| | > @IF EXIST W:\CPQS\XQR.* CALL W:\CPQS\XQR.EXE
| | > rem TShoot: C:\ESSAUDIO.COM
| | >
| | > --
| | > Thanks or Good Luck,
| | > There may be humor in this post, and,
| | > Naturally, you will not sue,
| | > should things get worse after this,
| | > PCR
| | > pcrrcp@netzero.net
| | > "cquirke" <cquirke@iafrica.com> wrote in message
| | > news:62s9ivc1ijtj29r7l1oqvmpd1ct7keq2i3@4ax.com...
| | > | On 27 Jul 2003 21:34:21 -0700, melee5@my-deja.com (Lee) wrote:
| | > |
| | > | >Only thing wrong with msdos.sys is minor point and that would
| | > | >be the ;sys line, which you can easily remove with notepad
| | > |
| | > | I bet you were one of those CompSci 101 tutors who'd "help"
| | > | programming students by pointing out spelling errors in comments
| :-)
| | > |
| | > | Winboot.ini and MSDOS.sys both use .ini syntax, in which any
line
| | > | starting with ; is ignored as a ;comment (the "; as comment"
| syntax
| | > | tradition dates from assembly language).
| | > |
| | > | That initial ;FORMAT or ;SYS is merely there to record what
| process
| | > | originally created the file, which is then fleshed out by Win9x
| Setup.
| | > |
| | > | >It appears that you may have the dreaded 'double path' problem,
I
| | > | >had it once and only a clean install got rid of it - but my
path
| was
| | > |
| | > | >C:\Windows;C:\WINDOWS;C:\WINDOWS\COMMAND;C:Window s\Command
| | > |
| | > | That's easy to fix, and is usually a side-effect of Win9x's
| | > | modification to the handling of the Path in Autoexec.bat
| | > | (specifically, the first Path statement retains the original
Path
| as
| | > | if it was phrased Path=%Path%;whatever)
| | > |
| | > | Path starts from Winboot.ini (should this exist, it usually
| doesn't)
| | > | or MSDOS.SYS (more typical). If there's a Set Path= in
| Config.sys,
| | > | this replaces whatever was set in these earlier files.
| | > |
| | > | Thereafter the first Path statement in Autoexec.bat appends to
the
| | > | original Path, and subsequent lines replace the Path.
| | > |
| | > | Unlike Config.sys, Autoexec.bat supports %Path%, and this is
| typically
| | > | used to retain the existing Path value and add to it. Stupid or
| | > | greedy software prepends to the Path, i.e.
C:\My\Bossy\App;%Path%,
| | > | while clueful software appends e.g. %Path%;C:\Clueful\App
| | > |
| | > | My generic approach is to either delete Autoexec.bat entirely
(if
| I
| | > | don't need anything in there) and Set Path= in Config.sys, or to
| use a
| | > | dummy line to clear append-or-not ambiguity before setting Path,
| e.g.
| | > |
| | > | @Echo Off
| | > | Set Path=C:\Some\Fictitious\Path
| | > | Set Path=C:\Windows;C:\Windows\Command;C:\Addon1;C:\Ad don2etc
| | > |
| | > | >Add this line to autoexec.bat to correct path statement if
| desired
| | > |
| | > | >Set Path=C:\Windows;C:\Windows\Command
| | > |
| | > | >Put at the begining of autoexec.bat if you can.
| | > |
| | > | >Somethings up with that double path, but I've never found the
| | > | >culprit or the cure, sorry.
| | > |
| | > | See above. Your example would give rise to that problem, as it
| may
| | > | append your explicit path to the implicit path unless it
| recognises
| | > | the duplication (may be letter-case sensitive on matching).
| | > |
| | > | This would work...
| | > |
| | > | Set Path=C:\Windows;C:\Windows\Command
| | > | Set Path=C:\Windows;C:\Windows\Command
| | > |
| | > | ...as the 2nd Path statement is accepted without any
| editorialising.
| | > | This works better (i.e. is more portable)...
| | > |
| | > | Set Path=C:\Some\Junk
| | > | Set Path=%WinBootDir%;%WinBootDir%\Command
| | > |
| | > | ...i.e. works where Windows is not installed in C:\Windows
| | > |
| | > | Final tip: Whenever your changes to MSDOS.SYS seems to be
ignored
| or
| | > | overridden, look for two things:
| | > |
| | > | 1) A (hidden, etc.) C:\WINBOOT.INI
| | > | 2) Extra lines added after the padding comment string lines
| | > |
| | > |
| | > | >--------------- ----- ---- --- -- - - -
| | > | Error Messages Are Your Friends
| | > | >--------------- ----- ---- --- -- - - -
| | >
| | >
| |
| |
|
|

On 28 Jul 2003 23:42:59 -0700, melee5@my-deja.com (Lee) wrote:
Ah, OK. I mostly use DOS Edit rather than Notepad for such things (I
like being able to load multiple files at once into an MDI, be able to
search across these easily, use wilcards, etc.) and control characters
are easier to manage there (also, less risk of Wordpad effects)

Hadn't seen ;EBD, but then I haven't used Win9x's EBD creation thing.
I find if I just copy the relevant files to a diskette, it works - not
what I'd have expected from MSDOS experience!

Now that you mention it, I don't remember seeing that first
"originating process" ;comment every time... I wonder if it depends on
whether Setup.exe is run after a Win9x Format /s or Sys (which would
create an otherwise-empty MSDOS.SYS) or over an MS-DOS or unformatted
HD (where Setup would find no existing text MSDOS.SYS to add to)?

I looked through the first 25 of the 36 MSDOS.SYS I could Find on my
PC (I have a large E: volume full of various recovered HDs). There
were some ;W98EBD and ;FORMAT stubs, several full 9x files without any
;originator line, and several with ;FORMAT as the first line.

The latter makes sense as I typically use FDisk and Format /S to prep
HDs before installing the OS, and seldom use Sys C:

Odd. I haven't tested this extensively enough to answer several
questions that come to mind (and which my carefully-phrased reply
danced around), such as:

1) Does the "original" Path include additions from Config.sys?

Say your MSDOS.SYS [Paths] defines WinBootDir as C:\Windows, so that
the initial Path would be C:\WINDOWS;C:\WINDOWS\COMMAND

You have a Set PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\TOOLS line in
Config.sys - does interpretation of the first Path statement in
Autoexec.bat use that, or C:\WINDOWS;C:\WINDOWS\COMMAND ?

2) How (well) does Autoexec.bat first-Path logic detect duplicates?

Generally AFAIK the logic is supposed to detect and avoid
duplications, but I'm not sure how well it does so. Is this
letter-case sensitive? Catches redundant %Path%? IOW, if the initial
Path was C:\WINDOWS;C:\WINDOWS\COMMAND, what would be the result if
the first Path statement in Autoexec.bat was each of the following...

Set Path=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something
Set Path=C:\windows;C:\WINDOWS\COMMAND;C:\Something
Set Path=C:\Windows;C:\Windows\Command;C:\Something
Set Path=C:\Something;C:\WINDOWS;C:\WINDOWS\COMMAND
Set Path=C:\WINDOWS;C:\Something;C:\WINDOWS\COMMAND
Set Path=C:\WINDOWS\COMMAND;C:\WINDOWS;C:\Something
Set Path=%Path%;C:\Something
Set Path=%Path%;C:\WINDOWS\COMMAND;C:\Something

3) Does the first-Path logic apply to all Path syntaxes?

IOW, would each of these be treated as that "first Path statement"?

Path C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something
Path=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something
Set Path=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something

4) Does "first" take into account the GoTo flow of the file, e.g...

@Echo Off
GoTo Later
:Earlier
Set Path=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something
GoTo End
:Later
Set Path=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\Something\El se
:End

....which of the two Path statements is "first"?

There are certain things that make me doubt whether the answers are as
one would expect. For example, the match logic used by "Specify a
new..." boilerplate matching (to avoid duplication) does fail to match
the same content differing only in letter case, and several aspects of
Config.sys parsing disregard statement order.

Lost the context there a bit. With processing of Path in pre-Win9x
MS-DOS, or any other environment label names in Win9x, there's no
automatic old-value retention at all; IOW...

Set Path=C:\Kill\Old\Path

....as first Path statement in a pre-Win9x MSDOS Autoexec.bat would
lose the pre-existing C:\DOS or whatever and give you just
C:\Kill\Old\Path, nothing else.

If you did this in Win9x Config.sys...

Set ArbLabel=SomeValue

....and this in Win9x Autoexec.bat...

Set ArbLabel=OtherValue

....you'd lose SomeValue in %ArbValue%. When things are this
predictable, it's easy; you use %Label% syntax to preserve existing
value at that point, and you know exactly what you will get, i.e.

Set ArbLabel=%ArbLabel%;OtherValue
Set Path=%Path%;C:\Some\thing\added

But because Win9x is trying to "help" by taking steps to preserve
Win9x's dirs in the Path (else risk of path failures etc.) it's a lot
harder to know what's going on.

My suggestions aimed to reduce this uncertainty by avoiding the "first
interpreted Path statement" altogether; either by having no such
statement (setting Path explicitly in Config.sys) or following a dummy
first Path statement with one that overrides it completely. As in...


If a C:\Winboot.ini exists, it's used instead of C:\MSDOS.SYS

In the normal course of events, it doesn't exist - which is why when
one does, it can really catch you out :-)

Good Qs... I think OS installation processes may use it as a
"handbrake" to override an existing MSDOS.SYS, without having to
disturb the original file. I think that's the only time I've seen it
spontaneously exist, and I've used it in that way myself.

I don't think it would be a Win3.x thing, as that didn't use textual
MSDOS.SYS, nor did it autoboot as an OS, nor was the automatic
settings for Config.sys and Autoexec.bat extended to include code
files such as HiMem.sys, IFSHlp.sys etc. needed for Windows.

"PCR" <pcrrcp@netzero.net> wrote in message news:erxgZWgVDHA.1948@TK2MSFTNGP11.phx.gbl...
Just another comment. That's the first time I've ever seen the "duplicate
%path% problem" without both dirs being duplicated.

"PCR" <pcrrcp@netzero.net> wrote in message news:#HgDXrjVDHA.1072@TK2MSFTNGP12.phx.gbl...
Sure. I guess if you want to do it that way-

set path=coffecup
after IO.SYS prepends
%path%=C:\WINDOWS;C:\WINDOWS\COMMAND;coffecup
set path=C:\WINDOWS;C:\WINDOWS\COMMAND
%path%=C:\WINDOWS;C:\WINDOWS\COMMAND
then let third parties add.
set path=%path%;c:\newprogram
%path%=C:\WINDOWS;C:\WINDOWS\COMMAND;c:\newprogram

but nullifying the %path% works without the extra step of having to reset
the defaults-


PATH probably calls SET PATH. It's a convienence is all, but PATH doesn't
work in config.sys.
?


Every one after the first is definitive. You must include %path%, if that's
what you want.


It is_ a word. ..It'll be listed in the standards soon. It was difficult to prepend
text before computers.

Uh..huh... All I said was
"if I did a "step by step" at boot and answered "N" to
"Process system registry [Y,N]"? the %path% would be normal."

That doesn't mean it's in the registry, but it would be a good place to
look. I don't even know what that entails really. Process system registry?
The whole system regisrty? System.dat? Answer no and everything seems
normal. All devices are enumerated.

But searching through the reg, I found no mention of any
"C:\WINDOWS;C:\WINDOWS\COMMAND" strings. It is a bug after all. It could be
something else. Bad pointer, re-entrant call to the "default Path" routine,
stack overflow (i doubt), something living under the N key (possible)...

And!, I'm the only one, that I know, that tried the "step by step" test..
It's a rare bug, and I couldn't get anybody else to check it out..
Usenet and all..

This is how it went on my Compaq 7470, Win98SE.

(1) I put "SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND" into Config.sys.
(There is no Winboot.ini, nor a Winstart.bat) No other file has a PATH
statement, unless you call these of MSDOS.sys a Path statement (as
perhaps one should):

[Paths]
WinDir=c:\windows
WinBootDir=c:\windows
HostWinBootDrv=c

(2) I boot directly to DOS. Path was perfect:
"C:\WINDOWS;C:\WINDOWS\COMMAND"

(3) I "Edit Config.sys" & REMed the Path statement. Boot again directly
to DOS. Lo & behold, I now had a screwed Path. This goes counter to your
belief that the processing of the Registry is what causes it. Path was
"C:\WINDOWS;c:\windows;c:\windows\COMMAND", the full screw up.

(4) I Edited Config.sys & activated the Path statement back to situation
in (1). I boot to Windows.

C:\>path
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND

So, cquirke was right about that. Putting it into Config.sys is a "fix".

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net
"PCR" <pcrrcp@netzero.net> wrote in message
news:%23HgDXrjVDHA.1072@TK2MSFTNGP12.phx.gbl...
| "Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message
| news:uZBvX1iVDHA.1748@TK2MSFTNGP12.phx.gbl...
| | "PCR" <pcrrcp@netzero.net> wrote in message
| news:erxgZWgVDHA.1948@TK2MSFTNGP11.phx.gbl...
| | > C:\>path
| | > PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND
| | >
| | > That's it. So, I need that "Path ;" in Autoexec.bat. Or perhaps
just
| a
| | > "SET PATH" in Config.sys.
| |
| | set path;
| | removes the variable from the DOS master environment block, and
| creates a "null path".
|
| That is the one I ended up with, after extensive muss & fuss. Now, I
| see, I did not need a space between Path & semi-colon.
|
| C:\>path
| PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
|
| C:\>path;
|
| C:\>path
| No Path
|
| C:\>PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
|
| C:\>path
| PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
|
| |
| | set path=""
| | sets %path% equal to an empty string. An "empty path". (though a
null
| string
|
| I guess, for the purpose in question, any value would do. It is a
matter
| of getting to the second Path statement, which will not automatically
| append %Path%, by virtue of being second in Autoexec.bat...
|
| Path;
| SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
|
| |
| | (I'm almost sure PATH w/o SET will be the same. I always use SET,
| 'cause
| | it's "more correct"
|
| I do recall, it would not work w/o "SET" in the second Path statement.
|
| |
| |
| | Create a "null" %path% to avoid any (to quote cquirke) "first
| interpreted Path
| | statement" problems.
|
| Well, cquirke said one may create any Path in the first statement. It
| will be wiped with the second.
|
| |
| |
|
| | > C:\>path
| | > PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND
| |
| | Just another comment. That's the first time I've ever seen the
| "duplicate
| | %path% problem" without both dirs being duplicated.
|
| Weird, but that is it. I didn't remember it that way. I thought it
would
| have both twice each. Looks like what comes out of MSDOS.sys is...
well,
| it's all of that-- unless, as you show, the Registry is involved. Yes,
| the Registry musses (somehow) whatever has come out of MSDOS.sys. I
| guess that would be: "c:\windows;c:\windows\COMMAND". I guess the
| Registry processing prepends "C:\WINDOWS".
|
| (By the way, there appears to be no such word as "prepends".)
|
| |
| | > I guess you have proven it is something in the Registry does it.
| |
| | Not really proof, but it could be a chain of events triggered by a
| setting.
|
| Whatever.
|
| |
| | > I will
| | > not go nuts over it, more than I already had developing the
| workaround.
| | > I certainly wasn't going to let it search each folder twice, when
| the
| | > command was in neither.
| |
| | Yup. Me either. You lose valuable micro-seconds. And, there is a
| %path%
| | string size limit. But, I've never come close to that.
|
| Uhuh. Those considerations too.
|
| |
| |
| | > I guess cquirke has come up with a second "fix", though. That
would
| be
| | > to move the "SET PATH" from Autoexec.bat into Config.sys, where he
| says
| | > %Path% would not attach.
| |
| | I don't remember if I tried that or not, but my system has since
been
| purged.
| | Try it, and report back.
|
| Fine. It's in Config.sys now (& out of Autoexec.bat), awaiting a
reboot.
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| should things get worse after this,
| PCR
| pcrrcp@netzero.net
|
|

"Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message
news:%23R5KMzkVDHA.2268@TK2MSFTNGP11.phx.gbl...
| "PCR" <pcrrcp@netzero.net> wrote in message
news:#HgDXrjVDHA.1072@TK2MSFTNGP12.phx.gbl...
| > "Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message
| > news:uZBvX1iVDHA.1748@TK2MSFTNGP12.phx.gbl...
| > | "PCR" <pcrrcp@netzero.net> wrote in message
| > news:erxgZWgVDHA.1948@TK2MSFTNGP11.phx.gbl...
| > | > C:\>path
| > | > PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND
| > | >
| > | > That's it. So, I need that "Path ;" in Autoexec.bat. Or perhaps
just
| > a
| > | > "SET PATH" in Config.sys.
| > |
| > | set path;
| > | removes the variable from the DOS master environment block, and
| > creates a "null path".
| >
| > That is the one I ended up with, after extensive muss & fuss. Now, I
| > see, I did not need a space between Path & semi-colon.
| >
| > C:\>path
| > PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| >
| > C:\>path;
| >
| > C:\>path
| > No Path
| >
| > C:\>PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| >
| > C:\>path
| > PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| >
| > |
| > | set path=""
| > | sets %path% equal to an empty string. An "empty path". (though a
null
| > string
| >
| > I guess, for the purpose in question, any value would do. It is a
matter
| > of getting to the second Path statement, which will not
automatically
| > append %Path%, by virtue of being second in Autoexec.bat...
|
| Sure. I guess if you want to do it that way-
|
| set path=coffecup
| after IO.SYS prepends
| %path%=C:\WINDOWS;C:\WINDOWS\COMMAND;coffecup
| set path=C:\WINDOWS;C:\WINDOWS\COMMAND
| %path%=C:\WINDOWS;C:\WINDOWS\COMMAND
| then let third parties add.
| set path=%path%;c:\newprogram
| %path%=C:\WINDOWS;C:\WINDOWS\COMMAND;c:\newprogram
|
| but nullifying the %path% works without the extra step of having to
reset
| the defaults-

Fine. But "Path;" is the nullification I do, not -SET Path=""-

By the way, see in my other post done offline that cquirke was right
about Config.sys. Put it in there & no nullification is required.

|
|
| > Path;
| > SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
| >
| > |
| > | (I'm almost sure PATH w/o SET will be the same. I always use SET,
| > 'cause
| > | it's "more correct"
| >
| > I do recall, it would not work w/o "SET" in the second Path
statement.
|
| PATH probably calls SET PATH. It's a convienence is all, but PATH
doesn't
| work in config.sys.
| ?

That's the way I recall it. I am one who would not include the word
"SET" if unnecessary. I recall puzzling over it, thinking that "SET"
would create an environment variable named PATH, i.e., %PATH%. I thought
PATH w/o the word SET would create the Path but not set the variable.
Whatever. The fact is, it would not work, w/o the word SET-- as I
recall.

|
|
| > | Create a "null" %path% to avoid any (to quote cquirke) "first
| > interpreted Path
| > | statement" problems.
| >
| > Well, cquirke said one may create any Path in the first statement.
It
| > will be wiped with the second.
|
| Every one after the first is definitive. You must include %path%, if
that's
| what you want.

That is the way I now understand it.

|
|
| > | > C:\>path
| > | > PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND
| > |
| > | Just another comment. That's the first time I've ever seen the
| > "duplicate
| > | %path% problem" without both dirs being duplicated.
| >
| > Weird, but that is it. I didn't remember it that way. I thought it
would
| > have both twice each. Looks like what comes out of MSDOS.sys is...
well,
| > it's all of that-- unless, as you show, the Registry is involved.
Yes,
| > the Registry musses (somehow) whatever has come out of MSDOS.sys. I
| > guess that would be: "c:\windows;c:\windows\COMMAND". I guess the
| > Registry processing prepends "C:\WINDOWS".
| >
| > (By the way, there appears to be no such word as "prepends".)
|
| It is_ a word. ..It'll be listed in the standards soon. It was
difficult to prepend
| text before computers.

By the way, see my other post (done offline) to see my Path was screwed
booting directly to DOS. It didn't take Registry processing to do it. I
guess it could be machine specific-- Compaq 7470, Win98SE.

|
| >
| > |
| > | > I guess you have proven it is something in the Registry does it.
| > |
| > | Not really proof, but it could be a chain of events triggered by a
| > setting.
| >
| > Whatever.
|
| Uh..huh... All I said was
| "if I did a "step by step" at boot and answered "N" to
| "Process system registry [Y,N]"? the %path% would be normal."
|
| That doesn't mean it's in the registry, but it would be a good place
to
| look. I don't even know what that entails really. Process system
registry?
| The whole system regisrty? System.dat? Answer no and everything seems
| normal. All devices are enumerated.
|
| But searching through the reg, I found no mention of any
| "C:\WINDOWS;C:\WINDOWS\COMMAND" strings. It is a bug after all. It
could be
| something else. Bad pointer, re-entrant call to the "default Path"
routine,
| stack overflow (i doubt), something living under the N key
(possible)...
|
| And!, I'm the only one, that I know, that tried the "step by step"
test..
| It's a rare bug, and I couldn't get anybody else to check it out..
| Usenet and all..

Well, you've got me wondering whether to believe my own eyes, now. I
just did it, & my Path was screwed directly booting to DOS. Geez, don't
tell me I have to do it again?

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcrrcp@netzero.net

cquirke <cquirke@iafrica.com> wrote in message news:<20rdivk43jo349ah4m4bfb558mcnagdr7k@4ax.com>. ..
My bad on ;EBD, it may be ;W98EBD as you state below that I was
remembering with full faults applied as normal. Originating process
snipet is added to the begining of msdos.sys such that sysing C:
drive would add ;SYS to msdos.sys, installing to a format /sysed C:
drive would have the ;FORMAT tag.

You're telling me...

Nope, nothing to do with path in Config.sys

think or hope for though.

Just what you say below - Set Path sets the path and no old path
was retained on my machine - but you may find it to be otherwise,
and if so please elaborate, I'm all ears.

I can certainly believe that, any hints as to it's contents
when it does exist?