[shae]

I just found out "dir /s /a" will not recurse hidden subdirectories. I don't know how I missed it until now. Maybe because hidden dirs just aren't very common. I looked for a solution and found the obscurely named DOS FIX utility, that patches COMMAND.COM to fix it. It's appears to be a generic patcher, and works for Win98SE even though it's not mentioned in the docs.

It changes the flags passed to DOS's FindFirst and FirstNext functions. For Win98SE the patched bytes are at offsets 0xA2B2 and 0xA2BE. In both cases the byte 0x10 (directories) is changed to 0x16 (directories, system, hidden).

This post has been edited by shae: 05 September 2012 - 03:38 PM

[submix8c]

?

Quote

/A Displays files with specified attributes.
D Directories R Read-only files
H Hidden files A Files ready for archiving
S System files - Prefix meaning not

e.g. DIR /S /AH

This "bug" must appear in CMD.EXE as well...
edit - see next post - (xp) DIR x:\WINDOWS /s /a /on /p
yields the hidden $HF_MIG$ and subfolders (hidden) and sub-subfolders/files (not hidden).

This post has been edited by submix8c: 06 September 2012 - 02:16 AM

[allen2]

But at least for windows XP:

Dir /s /a-

Works.
Edit: Even dir /s /a works on XP.

This post has been edited by allen2: 06 September 2012 - 01:11 AM

[jds]

Great find, shae!

Joe.

[CharlotteTheHarlot]

Yeah, this is an old problem with COMMAND.COM. I just downloaded the above linked file for DOS-FIX and can confirm this is identical to the last and only version that I have from this author, John Augustine, dated 1999-05-12, version 1.1.

It is a smart patcher, that sniffs for the necessary byte string in COMMAND.COM and patches them as necessary, just two bytes in total. The two (non-consecutive) bytes each get changed from hex 10 to hex 16.

I did some research on this sometime after WinXP SP2 came out to see if it was still needed. What I found out is that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until that very day ( Windows XP SP2 ) required this patch. ( NOTE: I just now checked Windows XP SP3 and found that the file wasn't updated from SP2.)

I never did get around to checking the COMMAND.COM that comes with 32-bit versions of Vista/7 but I will bet they also require it. So I believe it is safe to say that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until the present day requires this patch.

Here is the DOC file from the DOS-FIX v1.1 distribution ...

Spoiler

Dos Fix V1.1

by John Augustine

DF (Dos Fix) was written in Assembly for MS Dos systems.

A "bug" in MS-Dos's "COMMAND.COM" prevents you from searching hidden
directories for a file/s. Example: If you use the command (without quotes)
"DIR/S *.INI" to locate all ".INI" files in the current directory, including
"all" sub-directories to the current directory (directory you are in), if
there is a hidden sub-directory/s, it/they will be bypassed. Note: Hidden
sub-directories are common in the "WINDOWS" (95/98) directory.

The directory "search" bug involves not setting the proper attribute to
include hidden directories! It is possible that this "bug" was intentional,
allowing users to hide files in a hidden directory?

IMPORTANT NOTE:

You MUST "fix" every "COMMAND.COM" in the hard drive/disk, otherwise, it is
possible to get a system halt with the "invalid command.com" message. All the
"COMMAND.COM" files must match. Sometimes, when you exit certain
applications, the checksum of the "transient" portion of Command.com (the part
of Command.com that was relocated in high memory) will not match because the
application used that upper memory. Therefore, "COMMAND.COM" must be
reloaded. If the checksum still doesn't match, then the system halt occurs
and the error message appears. The checksum is created during startup of the
computer and remains unmodified. Another way of looking at it, the first
"COMMAND.COM" installed when the computer is turned on, becomes the
"reference".

BEFORE AND AFTER TEST, FIRST BEFORE:

At the root directory, type (without quotes) "DIR/S/A *.*" and press Enter.
When finished, write down the total number of files found.

GETTING READY:

If you are a very cautious person (I don't blame you), create an emergency
"Startup" disk ("FORMAT A: /S"), which will contain the original
"COMMAND.COM".

In the hard drive/disk, you must be in the directory where "COMMAND.COM" is
located. There is a minimum of two "COMMAND.COM" files. One is always in the
root directory and one is in the "Windows" (95)(98?) or "DOS" directory on PCs
with Windows 3.1 or Dos only systems.

TIP: I recommend you start at the root directory and type (without quotes)
"DIR/S/P COMMAND.COM" ("/P" will pause when the screen is full) in order to
see which directories have "COMMAND.COM". Make a note of those directories.

FIXING "COMMAND.COM":

1. Starting at the Root directory, simply execute (without quotes) "DOS-FIX"
and press Enter. If "DOS-FIX.EXE" is in a different directory, which does not
have a preset path ("DOS" or "COMMAND" directories), use a path. Example: If
DF is in the "UTYS" directory, type (without quotes) "\UTYS\DOS-FIX".

2. Enter every directory with "COMMAND.COM" and repeat the "DOS-FIX". NOTE:
The original "COMMAND.COM" will be renamed to "COMMAND.BAK".

If you want to verify that the "bug" is fixed, run DF the second time in the
same directory and you will see a message that the bug pattern was not found.
NOTE: If the "bug pattern not found" message occurs the first time you
execute DF, then it may be a Dos version with a different pattern or maybe,
without the bug!

3. Restart your computer after you have fixed all the "COMMAND.COM" files.

AFTER TEST:

Go to the root directory and again type (without quotes) "DIR/S/A *.*" and
see what the total number of files are. Compare that total to what you wrote
down. If you have a PC with Windows 95/98, you will see a noticeable
difference. If you don't see any difference, then your disk (hard drive) does
not have any hidden directories or does not have any files in them. Note:
"/A" specifies all files including hidden and system files.

DIRECTORY WITH THE "SYSTEM" ATTRIBUTE SET:

The fixed "COMMAND.COM" will also "search" a directory with the system
attribute set. There is one sub-directory in the "Windows" (95) directory
with such a setting.

NOTE:

I have fixed "COMMAND.COM" on five computers. Note: Four have Dos 6.2, two
are Dos only PCs, two have Windows 3.1, and one has Dos 7.1 with Windows 95.
If you are using an older or newer version of Dos, I don't know if the bug
pattern is the same. If DF doesn't find the bug pattern, it will let you
know.

FINAL COMMENT:

DF is FREE. Comments or complaints are welcomed. If you use "Snail Mail"
and expect a reply, please include a S.A.S.E.

E-Mail: jaugust@bellatlantic.net

John Augustine N3AOF
3129 Earl St.
Laureldale, Pa 19605

EDIT: as Jaclaz rightly points out below, this DIR display bug that skips certain hidden directories is part of COMMAND.COM, the command interpretor for DOS. It has nothing to do with CMD.EXE which is the NT counterpart.

This post has been edited by CharlotteTheHarlot: 07 September 2012 - 02:36 PM

[PROBLEMCHYLD]

This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too?

[jaclaz]

PROBLEMCHYLD, on 07 September 2012 - 10:49 AM, said:

This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too?

No.
IMHO there is some confusion in this topic.

There are TWO command interpreters.

• COMMAND.COM
  
• CMD.EXE

CMD.EXE has a slightly different syntax, but AFAIK it worls allright and needs NO patches (at least the "original" one in NT/2K/XP).

In any case this patch is for COMMAND.COM and NOT for *any* CMD:EXE (if you prefer if *any* CMD.EXE is suffering from this or a similar issue this patch won't do anything about it, as it targets COMMAND.COM and NOT CMD.EXE - the "COMMAND.COM" is hardcoded in the DOS-FIX.EXE)

jaclaz

[PROBLEMCHYLD]

You are right jaclaz The Win95cmd does not have this problem. I was too lazy to test, but I just did it now.

[jaclaz]

CharlotteTheHarlot, on 06 September 2012 - 05:40 AM, said:

EDIT: as Jaclaz rightly points out below, this DIR display bug that skips certain hidden directories is part of COMMAND.COM, the command interpretor for DOS. It has nothing to do with CMD.EXE which is the NT counterpart.

Yes and no.

CMD.EXE is the DEFAULT command interpreter in NT and later but (at least up to XP/2003, cannot say about Vista and later) there is ALSO COMMAND.COM in the OS.

Using under NT COMMAND.COM instead of CMD.EXE is possible (though mostly senseless).

Questions are:

• is the COMMAND.COM in the various NT affected by this "bug"?
  
• does the patch work also on these "later" COMMAND.COM's?
  
• does it make *any* sense, even if it works, to patch something that *noone* ever uses?

OR, we could do a poll:

Quote

Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why.

jaclaz

This post has been edited by jaclaz: 08 September 2012 - 04:19 AM

[CharlotteTheHarlot]

jaclaz, on 08 September 2012 - 04:18 AM, said:

Questions are:

• is the COMMAND.COM in the various NT affected by this "bug"?
  
• does the patch work also on these "later" COMMAND.COM's?
  
• does it make *any* sense, even if it works, to patch something that *noone* ever uses?

OR, we could do a poll:

Quote

Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why.

I can answer for several of them ( NT versions ) from this computer I am on.

• Windows 2000 SP4 has COMMAND.COM of size 50,620 bytes and the patch works OK.
  
• Windows XP Sp0-Sp1-Sp2-Sp3 ( all have identical COMMAND.COM, but not identical to Win2k ) is also 50,620 bytes and the patch works OK.

The fact that the patcher works only means that the byte string was successfully located and that two bytes were changed from 10 to 16. However this does not mean it was necessary. To determine this an experiment needs to be run. I just did a quick test with a hidden folder on WinXP SP3 and sure enough, the bug is both reproduceable and is corrected by the patch. Follow these steps ...

- go to C:\Temp
- create a subfolder called "Test", make this the current directory.
- copy original COMMAND.COM to "Original.com"
- copy patched COMMAND.COM to "Patched.com"
- create a subfolder called "Visible", copy a file into it.
- copy the subfolder called "Visible" to "Invisible"
- Enable the Hidden attribute for the folder called "Invisible"

The test structure looks like this ...
C:
= Temp
=== Test
----- Original.com
----- Patched.com
===== Visible
------- Readme.txt
===== Invisible <- Hidden Attribute set
------- Readme.txt

Now from within the folder called "Test" open CMD.EXE prompt (rather than pipe the output to file I captured the CMD window to preserve the executed command string.
- execute: DIR /A /S
- execute: ORIGINAL.COM /c DIR /A /S
- execute: PATCHED.COM /c DIR /A /S

Here are the results seen using CMD.EXE ...

Spoiler

C:\Temp\Test>DIR /A /S

Volume in drive C is xxxxxxxxxxx
Volume Serial Number is xxxx-xxxx

Directory of C:\Temp\Test

2012-09-08 09:03 <DIR> .
2012-09-08 09:03 <DIR> ..
2001-08-17 13:32 50,620 Command.com_Winxp(Sp0)(Sp1)(Sp2)(Sp3)_[Original]
2001-08-17 13:32 50,620 Command.com_Winxp(Sp0)(Sp1)(Sp2)(Sp3)_[Patched-Dos-Fix]
2001-08-17 13:32 50,620 Original.com
2001-08-17 13:32 50,620 Patched.com
2012-09-08 08:50 <DIR> Invisible
2012-09-08 08:50 <DIR> Visible
4 File(s) 202,480 bytes

Directory of C:\Temp\Test\Invisible

2012-09-08 08:50 <DIR> .
2012-09-08 08:50 <DIR> ..
2003-07-03 11:53 45 Readme.txt
1 File(s) 45 bytes

Directory of C:\Temp\Test\Visible

2012-09-08 08:50 <DIR> .
2012-09-08 08:50 <DIR> ..
2003-07-03 11:53 45 Readme.txt
1 File(s) 45 bytes

Total Files Listed:
6 File(s) 202,570 bytes
8 Dir(s) 94,182,002,688 bytes free

Here are the results seen using COMMAND.COM unpatched ...

Spoiler

C:\Temp\Test>ORIGINAL.COM /c DIR /A /S

Volume in drive C is xxxxxxxxxxx
Volume Serial Number is xxxx-xxxx

Directory of C:\TEMP\TEST

. <DIR> 09/08/12 7:40a
.. <DIR> 09/08/12 7:40a
COMMAN~1 COM 50620 08/17/01 1:32p
COMMAN~2 COM 50620 08/17/01 1:32p
ORIGINAL COM 50620 08/17/01 1:32p
PATCHED COM 50620 08/17/01 1:32p
INVISI~1 <DIR> 09/08/12 8:05a
VISIBLE <DIR> 09/08/12 8:50a
8 file(s) 202480 bytes

Directory of C:\TEMP\TEST\VISIBLE

. <DIR> 09/08/12 8:05a
.. <DIR> 09/08/12 8:05a
README TXT 45 07/03/03 11:53a
3 file(s) 45 bytes

Total files listed:
11 file(s) 202525 bytes
1023932928 bytes free

Here are the results seen using COMMAND.COM patched ...

Spoiler

C:\Temp\Test>PATCHED.COM /c DIR /A /S

Volume in drive C is xxxxxxxxxxx
Volume Serial Number is xxxx-xxxx

Directory of C:\TEMP\TEST

. <DIR> 09/08/12 7:40a
.. <DIR> 09/08/12 7:40a
COMMAN~1 COM 50620 08/17/01 1:32p
COMMAN~2 COM 50620 08/17/01 1:32p
ORIGINAL COM 50620 08/17/01 1:32p
PATCHED COM 50620 08/17/01 1:32p
INVISI~1 <DIR> 09/08/12 8:05a
VISIBLE <DIR> 09/08/12 8:50a
8 file(s) 202480 bytes

Directory of C:\TEMP\TEST\INVISI~1

. <DIR> 09/08/12 8:05a
.. <DIR> 09/08/12 8:05a
README TXT 45 07/03/03 11:53a
3 file(s) 45 bytes

Directory of C:\TEMP\TEST\VISIBLE

. <DIR> 09/08/12 8:05a
.. <DIR> 09/08/12 8:05a
README TXT 45 07/03/03 11:53a
3 file(s) 45 bytes

Total files listed:
14 file(s) 202570 bytes
1023932928 bytes free

NOTE-1: The unpatched COMMAND.COM does indeed fail to traverse the HIDDEN subfolder, so patching of COMMAND.COM on NT is necessary ( if you intend to ever use it ). This can be seen in the directory output capture. NOTE-2: Several quirks of COMMAND.COM are also visible. Obviously the ~tilde~ laden short file and folder names denote the 8.3 DOS file system convention. We also see that the free space on that HDD as shown by CMD.EXE is over 94 GB but it is shown by COMMAND.COM as 1023932928 bytes free which is 1,023,932,928 bytes or 1 GB. NOTE-3: It is important to remember that DOS-FIX.EXE changes the COMMAND.COM file date/time to current when patching. If you care about preserving the original date/time you will need to 'TOUCH' the file with a utility that can read it from one file and apply it to another. I did do this when I patched COMMAND.COM and this is why in those directory listings you see identical date/time for both files.

To answer Jaclaz's final question, well, that disk size bug and the non-LFN awareness is a huge reason why most people like myself rarely use COMMAND.COM. I was working on some experiments to utilize a parallel batch file interpretor by assigning COMMAND.COM to .BAT and CMD.EXE to .CMD. The idea was to allow perfect reproduction of the way batch files worked on Win9x ( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files ) but it was not fruitful and remains on the back burner. So my answer to "Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why." is yes I have, but I have been happier without it.

EDIT: wording

This post has been edited by CharlotteTheHarlot: 08 September 2012 - 07:52 AM

[jaclaz]

CharlotteTheHarlot, on 08 September 2012 - 07:51 AM, said:

To answer Jaclaz's final question, well, that disk size bug and the non-LFN awareness is a huge reason why most people like myself rarely use COMMAND.COM. I was working on some experiments to utilize a parallel batch file interpretor by assigning COMMAND.COM to .BAT and CMD.EXE to .CMD. The idea was to allow perfect reproduction of the way batch files worked on Win9x ( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files ) but it was not fruitful and remains on the back burner. So my answer to "Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why." is yes I have, but I have been happier without it.

JFYI :
http://support.micro...kb/100394/en-us
http://support.micro...kb/101875/en-us

http://www.nthelp.com/40/ansiNT.htm
http://www.windowsne...nsisupport.html

EDIT:
And OT , but not much:
http://support.micro...kb/102901/en-us

So a new question arises:

• do the above mentioned MS keyb's apply to later than DOS 5.0 versions (and on later NT based OS's)?

EDIT2: Added a couple of links and an almost completely OT one:
http://reboot.pro/10122/

EDIT3: This wasn't an "easy" one, but Hey, I'm still The Finder :
http://web.archive.o...ovide/ansi.html


jaclaz

This post has been edited by jaclaz: 08 September 2012 - 08:33 AM

[CharlotteTheHarlot]

jaclaz, on 08 September 2012 - 07:56 AM, said:

JFYI :
http://support.micro...kb/100394/en-us
http://support.micro...kb/101875/en-us

http://www.nthelp.com/40/ansiNT.htm
http://www.windowsne...nsisupport.html

Thanks. Frustratingly I learned this independently and much to my chagrin that we have the Hobson's choice or more accurately, the Morton's fork of CMD.EXE working nicely but in 2-color, or else using COMMAND.COM with all it's bugs in glorious 16-color BBS beauty. ~sigh~ ( oops, there's those tildes again). Why Microsoft just didn't port the Win9x COMMAND.COM back to WinXP+ is a mystery to me, they broke a huge amount of batch files when the Win9x fork was shut down. I never researched it but I wonder if with enough patching the Win9x version would run in NT. At least LFN would be returned along with ANSI, not to mention being able to launch Windows apps.

Of course if you can just find a link to the official source code to CMD.EXE and COMMAND.COM ( both NT and Win9x ) we can fix it and then recompile the sucker ourselves.

[bphlpt]

CharlotteTheHarlot, on 08 September 2012 - 07:51 AM, said:

( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files )

FWIW, I have used ANSI.COM - http://www.robvander...nsi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used)

EDIT: - See my next post below - It ends up that I have not used this particular solution, but www.robvanderwoude.com is very reliable.

Cheers and Regards

This post has been edited by bphlpt: 09 September 2012 - 10:32 AM

[CharlotteTheHarlot]

bphlpt, on 08 September 2012 - 05:05 PM, said:

CharlotteTheHarlot, on 08 September 2012 - 07:51 AM, said:

( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files )

FWIW, I have used ANSI.COM - http://www.robvander...nsi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used)

Cheers and Regards

I could swear that I tried the all the ( PCMag ) ANSI.COM variations on WinXP and 7 ( btw, not x64? ). Your post greatly intrigues me.

We should probably take this off topic thing elsewhere. Let me know if you have another thread in mind.

[bphlpt]

Another option is ANSICON - http://adoxa.3eeweb.com/ansicon/ - and yes there are versions for both x86 and x64. Source is available and it has been updated as recently as June 12, 2012.

EDIT: Sorry for the previous post, this is the one that I personally used, not the previous one. But http://www.robvanderwoude.com hardly ever steers you wrong.

Cheers and Regards

This post has been edited by bphlpt: 08 September 2012 - 07:53 PM

[PROBLEMCHYLD]

CharlotteTheHarlot, on 08 September 2012 - 07:51 AM, said:

It is important to remember that DOS-FIX.EXE changes the COMMAND.COM file date/time to current when patching. If you care about preserving the original date/time you will need to 'TOUCH' the file with a utility that can read it from one file and apply it to another. I did do this when I patched COMMAND.COM and this is why in those directory listings you see identical date/time for both files.

Thanks for the heads up. I prefer for files to have their original timestamp.