osRe Posted September 5, 2012 Share Posted September 5, 2012 (edited) 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). Edited September 5, 2012 by shae Link to comment Share on other sites More sharing options...
submix8c Posted September 6, 2012 Share Posted September 6, 2012 (edited) ? /A Displays files with specified attributes.D Directories R Read-only filesH Hidden files A Files ready for archivingS System files - Prefix meaning note.g. DIR /S /AHThis "bug" must appear in CMD.EXE as well...edit - see next post - (xp) DIR x:\WINDOWS /s /a /on /pyields the hidden $HF_MIG$ and subfolders (hidden) and sub-subfolders/files (not hidden). Edited September 6, 2012 by submix8c Link to comment Share on other sites More sharing options...
allen2 Posted September 6, 2012 Share Posted September 6, 2012 (edited) But at least for windows XP:Dir /s /a-Works.Edit: Even dir /s /a works on XP. Edited September 6, 2012 by allen2 Link to comment Share on other sites More sharing options...
jds Posted September 6, 2012 Share Posted September 6, 2012 Great find, shae!Joe. Link to comment Share on other sites More sharing options...
CharlotteTheHarlot Posted September 6, 2012 Share Posted September 6, 2012 (edited) 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 ... 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 hiddendirectories 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), ifthere is a hidden sub-directory/s, it/they will be bypassed. Note: Hiddensub-directories are common in the "WINDOWS" (95/98) directory. The directory "search" bug involves not setting the proper attribute toinclude 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 ispossible to get a system halt with the "invalid command.com" message. All the"COMMAND.COM" files must match. Sometimes, when you exit certainapplications, the checksum of the "transient" portion of Command.com (the partof Command.com that was relocated in high memory) will not match because theapplication used that upper memory. Therefore, "COMMAND.COM" must bereloaded. If the checksum still doesn't match, then the system halt occursand the error message appears. The checksum is created during startup of thecomputer 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" islocated. There is a minimum of two "COMMAND.COM" files. One is always in theroot directory and one is in the "Windows" (95)(98?) or "DOS" directory on PCswith 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 tosee 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 nothave a preset path ("DOS" or "COMMAND" directories), use a path. Example: IfDF 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 thesame 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 youexecute 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 *.*" andsee what the total number of files are. Compare that total to what you wrotedown. If you have a PC with Windows 95/98, you will see a noticeabledifference. If you don't see any difference, then your disk (hard drive) doesnot 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 systemattribute set. There is one sub-directory in the "Windows" (95) directorywith such a setting. NOTE: I have fixed "COMMAND.COM" on five computers. Note: Four have Dos 6.2, twoare 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 bugpattern is the same. If DF doesn't find the bug pattern, it will let youknow. 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 19605EDIT: 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. Edited September 7, 2012 by CharlotteTheHarlot Link to comment Share on other sites More sharing options...
PROBLEMCHYLD Posted September 7, 2012 Share Posted September 7, 2012 This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too? Link to comment Share on other sites More sharing options...
jaclaz Posted September 7, 2012 Share Posted September 7, 2012 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.COMCMD.EXECMD.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 Link to comment Share on other sites More sharing options...
PROBLEMCHYLD Posted September 7, 2012 Share Posted September 7, 2012 You are right jaclaz The Win95cmd does not have this problem. I was too lazy to test, but I just did it now. Link to comment Share on other sites More sharing options...
jaclaz Posted September 8, 2012 Share Posted September 8, 2012 (edited) 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:Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why.jaclaz Edited September 8, 2012 by jaclaz Link to comment Share on other sites More sharing options...
CharlotteTheHarlot Posted September 8, 2012 Share Posted September 8, 2012 (edited) 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: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.txtNow 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 /SHere are the results seen using CMD.EXE ...C:\Temp\Test>DIR /A /S Volume in drive C is xxxxxxxxxxx Volume Serial Number is xxxx-xxxx Directory of C:\Temp\Test2012-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.com2001-08-17 13:32 50,620 Patched.com2012-09-08 08:50 <DIR> Invisible2012-09-08 08:50 <DIR> Visible 4 File(s) 202,480 bytes Directory of C:\Temp\Test\Invisible2012-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\Visible2012-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 freeHere are the results seen using COMMAND.COM unpatched ...C:\Temp\Test>ORIGINAL.COM /c DIR /A /S Volume in drive C is xxxxxxxxxxx Volume Serial Number is xxxx-xxxxDirectory of C:\TEMP\TEST. <DIR> 09/08/12 7:40a.. <DIR> 09/08/12 7:40aCOMMAN~1 COM 50620 08/17/01 1:32pCOMMAN~2 COM 50620 08/17/01 1:32pORIGINAL COM 50620 08/17/01 1:32pPATCHED COM 50620 08/17/01 1:32pINVISI~1 <DIR> 09/08/12 8:05aVISIBLE <DIR> 09/08/12 8:50a 8 file(s) 202480 bytesDirectory of C:\TEMP\TEST\VISIBLE. <DIR> 09/08/12 8:05a.. <DIR> 09/08/12 8:05aREADME TXT 45 07/03/03 11:53a 3 file(s) 45 bytesTotal files listed: 11 file(s) 202525 bytes 1023932928 bytes freeHere are the results seen using COMMAND.COM patched ...C:\Temp\Test>PATCHED.COM /c DIR /A /S Volume in drive C is xxxxxxxxxxx Volume Serial Number is xxxx-xxxxDirectory of C:\TEMP\TEST. <DIR> 09/08/12 7:40a.. <DIR> 09/08/12 7:40aCOMMAN~1 COM 50620 08/17/01 1:32pCOMMAN~2 COM 50620 08/17/01 1:32pORIGINAL COM 50620 08/17/01 1:32pPATCHED COM 50620 08/17/01 1:32pINVISI~1 <DIR> 09/08/12 8:05aVISIBLE <DIR> 09/08/12 8:50a 8 file(s) 202480 bytesDirectory of C:\TEMP\TEST\INVISI~1. <DIR> 09/08/12 8:05a.. <DIR> 09/08/12 8:05aREADME TXT 45 07/03/03 11:53a 3 file(s) 45 bytesDirectory of C:\TEMP\TEST\VISIBLE. <DIR> 09/08/12 8:05a.. <DIR> 09/08/12 8:05aREADME TXT 45 07/03/03 11:53a 3 file(s) 45 bytesTotal files listed: 14 file(s) 202570 bytes 1023932928 bytes freeNOTE-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 Edited September 8, 2012 by CharlotteTheHarlot Link to comment Share on other sites More sharing options...
jaclaz Posted September 8, 2012 Share Posted September 8, 2012 (edited) 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.microsoft.com/kb/100394/en-ushttp://support.microsoft.com/kb/101875/en-ushttp://www.nthelp.com/40/ansiNT.htmhttp://www.windowsnetworking.com/kbase/windowstips/windows2000/usertips/miscellaneous/commandinterpreteransisupport.htmlEDIT:And OT , but not much:http://support.microsoft.com/kb/102901/en-usSo 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.org/web/20071222191504/http://home.tiscali.dk/8x305617/provide/ansi.htmljaclaz Edited September 8, 2012 by jaclaz Link to comment Share on other sites More sharing options...
CharlotteTheHarlot Posted September 8, 2012 Share Posted September 8, 2012 JFYI :http://support.microsoft.com/kb/100394/en-ushttp://support.microsoft.com/kb/101875/en-ushttp://www.nthelp.com/40/ansiNT.htmhttp://www.windowsnetworking.com/kbase/windowstips/windows2000/usertips/miscellaneous/commandinterpreteransisupport.htmlThanks. 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. Link to comment Share on other sites More sharing options...
bphlpt Posted September 8, 2012 Share Posted September 8, 2012 (edited) ( 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.robvanderwoude.com/ansi.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 Edited September 9, 2012 by bphlpt Link to comment Share on other sites More sharing options...
CharlotteTheHarlot Posted September 8, 2012 Share Posted September 8, 2012 ( 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.robvanderwoude.com/ansi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used)Cheers and RegardsI 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. Link to comment Share on other sites More sharing options...
bphlpt Posted September 9, 2012 Share Posted September 9, 2012 (edited) 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 Edited September 9, 2012 by bphlpt Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now