OR, we could do a poll:
- 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?
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:
===== Invisible <- Hidden Attribute set
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 ...
Here are the results seen using COMMAND.COM unpatched ...
Here are the results seen using COMMAND.COM patched ...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:
Edited by CharlotteTheHarlot, 08 September 2012 - 07:52 AM.