Message-ID: <12683@sri-arpa.UUCP>
Date: Sat, 29-Sep-84 16:21:02 EDT
Article-I.D.: sri-arpa.12683
Posted: Sat Sep 29 16:21:02 1984
Date-Received: Sun, 7-Oct-84 21:32:03 EDT
Lines: 260

From:  STERNLIGHT 

The following was obtained from a public bulletin board system in Florida
and subsequently edited by several hands:
 
                       Soft-SHARE (tm)
 
                             by
 
                       James P. Morgan
 
                   1749 AMERICANA BLVD, APT 23-G
                       ORLANDO FLA, 32809
 
                         (305) 826-7297
 
 
*******************************************************************************
 
This is a first attempt to check out DOS 3.0 and compare known bugs
and fixes that were in DOS 2.X
 
*******************************************************************************
 
 
 
1). COMSPEC DID NOT WORK.
    ---------------------
 
Hey !!! the 'COMSPEC' command now appears to work, for DOS 3.0.
 
  EXAMPLE : >SET COMSPEC=C:\COMMAND.COM
 
Then when DOS needs to reload COMMAND.COM it will go to C:\
 
 
 
2). TREE.COM HAD ROOT BUG  - DOS 2.0
    ---------------------
 
************************************************************************
 
THIS IS AN UPDATED VERSION  FOR DOS 3.0 - THEY STILL DIDNT FIX THE BUG!!
 
************************************************************************
 
TREE WITH ROOT BUGS
--------------------
 
Having a Tallgrass 20 meg hard disk with over 50 sub-directories,
I have come to depend on the DOS utility TREE.COM to help me control
the sub-directorys.

Well, one day to my surprise, I could no longer list any sub-directorys past
the first root sub-directory, 'DATABASE.DIR'.  "Oh No!, My hard disk has
problems", I said.  After some cussing and sweating and several long nights and
days, I had isolated the problem to the TREE.COM utility program.
 
    THE PROBLEM READS LIKE THIS:
        -------
 
    1). IF YOU HAVE A ROOT SUB-DIRECTORY ENTRY THAT IS ELEVEN (11)
       CHARACTERS LONG
 
      AND
 
    2). YOU HAVE AT LEAST ONE (1) SUB-DIRECTORY WITHIN THE ROOT DIRECTORY
 
 
       TREE.COM STOPS LOOKING FOR ANY OTHER DIRECTORYS.
 
     THE SOLUTION READS AS :
         --------
 
     1). DEBUG TREE.COM
 
     2). E 3D4 0D        'FOR DOS 2.X ONLY
     2). E 81A 0D        'FOR DOS 3.0 ONLY
 
     3). W
 
     4). Q
 
       NO MORE ROOT BUGS, SO NOW WE HAVE A HEALTHY TREE.COM AGAIN.
 
 
TREE.COM, for DOS 2.1, is the same as DOS 2.0. I have reported the
bug and fix to IBM. TREE.COM for DOS 3.0 is a different size.
 
 
3). FIX COMP.COM FOR MORE THAN 10 MISMATCHES
    ----------------------------------------
 
                    WHEN '10' IS NOT ENOUGH
                   -------------------------
 
 Probably one of the most annoying DOS 2.0 and 3.0 utilities is 'COMP.COM'. By
annoying I mean that even though it wont let you compare unequal length files,
it will stop after finding 10 unequal compares.
 
  Well many times I modify system utilities or patch other programs
or files to get better or different results, and more often than not
, more than 10 bytes get changed, and at a later date I might want
to compare the original with the changed, to get a listing of the
differences.
 
 Im not going to do anything about the unequal length situation,
but I will tell you where to patch COMP.COM to let you set your own
'stop after unequal compare' count.
 
1) DEBUG COMP.COM
 
   ENTER -L
   *************** DOS 2.X
 
   ENTER -U CS:396
 
          YOU SHOULD SEE : CMP BYTE PTR [07E9],0A
 
          ALSO THE INSTRUCTION PRIOR TO CS:396 IS THE INSTRUCTION
        THAT INCREMENTS (ADDS +1) TO [07E9].
 
   ENTER -E CS:39A XX   (WHERE XX IS THE NEW HEX COUNT LIMIT, INSTEAD OF 'OA')
 
          ALSO THE MESSAGE "10 Mismatches" IS AT CS:809, YOU MAY WANT TO
        CHANGE THE MESSAGE TO BETTER SUIT YOURSELF.
   *****************
 
 
 
   ***************** DOS 3.0
 
   ENTER -U CS:879
 
          YOU SHOULD SEE : CMP BYTE PTR [0568],0A
 
          ALSO THE INSTRUCTION PRIOR TO CS:879 IS THE INSTRUCTION
        THAT INCREMENTS (ADDS +1) TO [0568].
 
   ENTER -E CS:879 XX   (WHERE XX IS THE NEW HEX COUNT LIMIT, INSTEAD OF 'OA')
 
          ALSO THE MESSAGE "10 Mismatches" IS AT CS:B51, YOU MAY WANT TO
        CHANGE THE MESSAGE TO BETTER SUIT YOURSELF.
   ******************
 
 
   ENTER -W
 
   ENTER -Q
 
 
2) You should now have a copy of COMP.COM that stops only
  after you want it to.
 
 
****************************************************************************
 
NOTE: THE UNEQUAL COUNTER IS A BYTE, SO THE MAXIMUM NUMBER OF UNEQUAL COMPARES
     COULD NOT BE GREATER THAN 255.
 
 
4). DEBUG.COM PROBLEM WITH SEGMENT REGISTERS  (IN DOS 2.X)
    ----------------------------------------
 
   **********************************************************
 
    NOTE !!!!!!  NOTE !!!!!!!! NOTE !!!!!!!! NOTE !!!!!!
 
    DOS 3.0 DEBUG.COM SEEMS TO HAVE CORRECTED THIS PROBLEM
 
    *********************************************************
 
 
                     OH, DEM-BUGS, DEM-BUGS IN DEBUG
                     ---------------------------------
 
 We all know that fleas have fleas, don't we. Well now we know debug
has bugs. I am referring to the DOS utility 'DEBUG.COM' supplied on the
DOS 2.X supplemental program disk for IBM PC-DOS.
 
 There exists a very severe bug in DEBUG.COM. The symptoms are not unlike
cold symptoms, each persons are a little different. Well this 'bug'
exhibits different symptoms that at first are hard to diagnose.
 
 These symptoms can be caused by entering anyone of the DEBUG.COM commands,
such as 'D CS:100' AS 'D CS;100'. Notice that the character following
the segment register is not a colon but a semi-colon. This character does
not have to be a semi-colon; it could be any character including a space.
 
 If you enter the 'DUMP' command with the semi-colon your machine will
either scream at you and/or lock up. It will also in some cases immediately
return to PC-DOS without so much as a good-bye. Try it with different debug
commands and different segment registers. You may or may not be amused. 
I wasn't.
 
  After over any hour into tracing a program and single stepping, I lifted my
finger off the shift key to fast and the ":" was entered as ";" and my PC went
off into pc-limbo. Again the moans and groans and cussing, as was with the
bug that turned up in TREE.COM, but thats another bug story.
 
  I will save you a great deal of heart ache and give you the fix for the
problem.
 
 FIRST DEBUG DEBUG.COM
 
       ENTER >DEBUG DEBUG.COM
 
       ENTER -U 5D6
 
 YOU SHOULD SEE THE FOLLOWING CODE
 
       XXXX:5D6 D1E1     SHL  CX,1
            5D8 8BD9     MOV  BX,CX
            5DA FFB7F22A PUSH [BX+2AF2]
            5DE 803C3A   CMP  BYTE PTR [SI],3A  'CHECK FOR ":"
            5E1 75BD     JNZ  05A0
            5E3 EBD7     JMP  05BC
 
  THIS IS THE OFFENDING CODE, THE CODE TO FIX THE PROBLEM IS AS FOLLOWS :
 
     ENTER -E 5D6 80 3C 3A 75 C5 D1 E1 8B D9 FF B7 F2 2A
 
       XXXX:5D6 803C3A   CMP  BYTE PTR [SI],3A  'CHECK FOR ":"
            5D9 75C5     JNZ  05A0
            5DB D1E1     SHL  CX,1
            5DD 8BD9     MOV  BX,CX
            5DF FFB7F22A PUSH [BX+2AF2]
            5E3 EBD7     JMP  05BC
 
 
      ENTER -W
 
      ENTER -Q
 
 You will be returned to PC-DOS. As always you should be working from a
backup copy of DEBUG.COM. To test out the new DEBUG.COM, just execute
DEBUG.COM and try the same test. Hopefully you should see an error message,
 '^ ERROR' displayed at the point in the command.
 
 For you unenlightened, DEBUG.COM was pushing a word onto the stack even
if the check for the ":" (hex 3A) was not successful and branching to a routine
that did not clear the stack of this value. So when a return (RET) was
executed ( which pops the stack for the return address) the wrong return
point was entered and what would happen is anyones guess.
 
 All the fix does is check for a ":" first and if found, then pushes the stack.
This should save you midnight hackers a couple of extra hours sleep, from
having to recover from a locked up machine. Also if you don't want to use
the shift key to get the colon, change hex 3A, say to hex 3B, a semi-colon.
 
5). DOS EXTENDED FUNCTION CALL 'GET FIRST' BUG  (DOS 2.X CALL)
    ------------------------------------------

DOS INT 21 function call 4E would not return the volumn label if it was the
first or only catalogued disk file.
 
  DOS 3.0 APPEARS TO HAVE FIXED THIS BUG. **************
 
 
-------